Puppet Apprentice

Puppeteer

As I move my career towards the world of DevOps and automation / orchestration, I feel I need to learn the latest tools of trade for these fields. So, to that end, I'm installing the free version of Puppet Enterprise as a proof of concept. I've heard many people tell me how fantastic a tool Puppet is but haven't actually played with it.

So here I go.

For those wondering, there isn't technically any difference between the enterprise version and the normal puppet version but there are plenty of add ons that require the enterprise version (so I believe). The enterprise version will allow control of up to 10 nodes for free which is more than enough for a proof of concept.

I'm also hoping to build Puppet into a larger story about automation and orchestration.

Just to clarify, if you don't know the difference between automation and orchestration or think they mean the same thing here's the useful definition:
Automation is like musicians in an orchestra, looking the music and following the instructions, the orchestrator is the person up the front conducting, making sure everyone is on the same page and working together as a team.

In other words, the musicians are like the scripts or tools we use in lots of place to do useful work, like puppet agents or like simple shell scripts whilst the orchestrator would be something that can connect lots of systems and coordinate their efforts into something more useful than individual automations.

Hopefully that makes sense. There's a definite distinction between these two terms and it's useful to have an understanding of both for forming a bigger picture.

I'll post again when I've had time to play with my new puppet installation and have managed to make it do useful work.

Cheers.

Hacking Active Directory

So here's the deal. I've been given the task of automating creating objects in active directory from outside the domain.

Being someone with a programming background I thought perhaps power-shell was the way to go. As it turns out, the ActiveDirectory powershell module is included when you made a Windows 2008 server into a domain controller by adding the feature 'Domain Services'.

Ok, so thats ok if you are running a script on the machine itself but that doesn't solve the problem of running from another machine.

Further research discovered Active Directory Web Services (ADWS) which export that powershell functionality over the network. These web services, whilst adhering to normal web services standards, are not meant to be consumed by a web application using WSDLs but by the ActiveDirectory powershell module.

This web service is installed by default in the same way the power shell module is and it listens on the port 9389. This gave me a nice simple test to see if it was running on a given domain controller.

A simple command you can run with the powershell command-lets is:

PS > Get-ADOrganizationalUnit -filter 'name -like "*"'

If you do not specify anything else, it will try to communicate with the ADWS running on the same domain as the machine that is executing the powershell. For a lot of use cases this is what you want and is quite the expected behaviour.

For me, I wanted to run this from a more distant machine. You can specify which machine to query using the server parameter. At this point you will also have to supply credentials for this new domain using the -credentials parameter.

How to create credentials for non-interactive scripts can be found here.

PS > Get-ADOrganizationalUnit -filter 'name -like "*"' -Credential $mycreds -server <servername>

Using this simple set of tools I can now manipulate active directory from outside the domain (given suitable credentials) and automate regular tasks like adding or deleting users or OU.

Hopefully this has been helpful to some.