Jinja2 and… Powershell? Automation(ish) Microsoft DHCP

Most of us have home labs, right?

I’m in the middle of doing some zero touch provisioning testing, and I had the need to create a bunch of DHCP scopes and reservations, some with scope specific options, and some with client specific options. As often as I’ve had to create a Microsoft DHCP server in the lab and set up some custom scopes, I decided I was going to figure out how to automate this as much as I could with a little effort as possible.

After taking a quick look around for a python library to help me out, python being my weapon of choice, I realized that I was going to have to get into some Powershell scripting. I’ve dabbled before, but I’ve never really take the time to learn much about Powershell control structures ( loops, conditionals, pipes, etc…).  I really didn’t want to spend the time getting up to speed on a new language, so I instead decided I was going to use the python skills I had to auto generate the scripts using a little jinja2 and some google-technician skills.

Figuring out the Powershell Syntax

This was the easy part actually, Microsoft has some pretty great documentation for Powershell CmdLets and there was more than a couple of blogs out there with examples, Unfortunately, I didn’t take notes on all the posts I went through… yeah, I suck, but I offer thanks to everyone

Creating the Scopes

The Jinja Template for Creating Scopes

Once I figured out the specific syntax that I needed to generate the DHCP scopes with the proper scope options, I dropped the syntax into a Jinja template using the For loop to run over multiple scopes as defined in the YAML file ( see the next GIST ).

The YAML file to define the Scopes

I chose to use YAML to define the inputs because well, that’s what I felt like working in at the time and it also allowed me to separate out the global Values from those specific to each scope. As I move forward in my full home lab automation project, I’m thinking I might use a single globals values YAML file to hold all the global values for everything in the entire infrastructure, but for now, I decided to keep things simple and just include it in the same YAML file.

If you take a look at the GIST below, you should be able to easily identify what each of the different elements are for.

The Python Script to Generate the Powershell Script

Nothing too complicated here, I load the variables, pass them into the jinga library and spit out a file with a PS1 extension.

Creating the Reservations

For my specific project, I need to set different DHCP option 67s for some of my clients. Although I could have manually created these as well, I decided that I would just take the same approach and template the whole thing.

The Jinja Template for Creating DHCP Reservations

Very similar to the approach above, I figured out the syntax for one, and then I created a Jinja template using a For loop.

The CSV file to define the DHCP Reservations

In this case, since I didn’t have to deal with anything more than the reservations, I decided on using a CSV file as the input format. Although YAML is what all the cool kids are doing, using a CSV file allows me to edit this in Excel which I found to be easier for this specific project. There are only a coupe of reservations in here right now, but I’ve got another 30 or so devices which I will need to perform this same step for, so having the ability to quickly add reservations into a CSV file is a good thing in the long run.

The Python Script to Generate the Powershell Script

Wrap up

To be honest, it’s a bit lazy and I wish I had more time to learn more things, but sometimes, you just use what you know to address a problem in a quick and dirty way. Hopefully, someone else will find these useful as well.

At the beginning of the year, I wrote a blog that said my major goal was to be able to automate the configuration of my entire lab with as little effort as possible. Considering how many times I’ve had to manually create DHCP Scopes and Reservations over the years, I think this one will be something that will definitely come in handy. Hopefully someone else will thing so to!

Questions, Comments? Feel free to post below!

@netmanchris

Advertisements

Adding Custom Device Fingerprints to the HPN BYOD Solution

So I was working on the new HP BYOD Solution in my lab and I just didn’t have enough wireless devices to really make it interesting.  So I decided to look for other devices in my house which I could connect to the HPN BYOD Controlled  MSM controller-based wireless networks.

I did find a Nintendo Wii, but we don’t have fingerprints in IMC to properly identify the Nintendo Wii.  I guess Nintendo didn’t make the cut.   ( They don’t even support WPA2 Enterprise!!! )

 

Anyways, the great thing about HP’s new BYOD solution, based on IMC and UAM, is the ability for operators to extend the default fingerprints to devices beyond what was shipped with the product. Although the process does require some knowledge of wireshark, it’s nothing that a little google-technician skills can’t get you through.  The adding of fingerprints was super easy. 

Creating the foundation

So before we actually get to creating the fingerprints, we need to create the custom vendor, endpoint type, and OS type that we’re going to assign to the DHCP and HTTP fingerprints we are going to create. If you’re doing this for a new smart phone, like the blackberry 10, you’ll probably be able to skip this step as RIM is already listed as a vendor. As you can imagine, Nintendo wasn’t 

So let’s look at what the process looks like. 

Add Vendor

As you can imagine, there’s no default vendor category for Nintendo, so I’m going to go into the Service>>User Access Manager>> Endpoint Identification Management>>Vendor screen and add a new vendor

NewImage

 

Add Endpoint Type

 

IMC ships with a bunch of endpoint types by default to cover all the normal devices you would see in a business environment. I don’t see that many Wii’s in offices these days though, so we’ll have to create this one too.

 

NewImage

 

Add OS type

Again, No love for Nintendo in the OS department.  Let’s add that too.

 

NewImage

 

 

 

Creating the fingerprints 

For those of you who don’t know, IMC uses digital fingerprints to be able to identify devices accessing the network. We use a combination of characteristics that are mostly unique to one specific type of device to be able to make an educated decision on the model, operating system, and type of the endpoint accessing the network. The three types of fingerprints we can use are

DHCP Fingerprint – In this option IMC uses the options requested in the DHCP client option 55 field to identify the device requesting an address. The specific sequence and number of options are considered to be unique to that specific operating system.  ie. All Nintendo Wii machines should request the same values in the same order in the option 55 field of the DHCP request packet. This is considered to be the most reliable of the fingerprinting techniques.

HTTP User-Agent – In this option IMC uses the User-agent portion of the HTTP request headers sent to the BYOD web server to be able to identify the device requesting the webpage. As most browsers will identify themselves through the use of HTTP User-Agent, this is a still a good method for making an educated decision.

 

MAC Address – In this option IMC uses the MAC address, obtained through the RADIUS server, to identify the vendor based on the MAC address OUI.  This is considered to be the weakest form of fingerprinting, but necessary as some devices do not use a unique DHCP signature, nor a web browser. An example of this might be an IP Telephone or Printer. 

 

So let’s get started here and setup our first fingerprint.

Capture the DHCP fingerprint

This is where the nerdiness starts. I have a Windows Active Directory Server that is serving up addresses for the network that my Wii connects to. So I just installed wireshark on the domain controller and start capturing packets. 

note:  I use the filter bootp.option.type == 53 which will get allow me to see just the DHCP traffic. Cuts down on the packets I need to look through. 

I turn on my Nintendo Wii and wait a few seconds for it to try and connect to the network

 

NewImage

Now that I’ve got the packet, I need to look a little closer for the Option 55 information.  INSERT SOME INFO ON OPTION 55 FROM WIKI

You can see in the packet capture above that the option 55 parameters list has a length of 6, and the values are 1,3,6,15,28, and 33.

 

Creating the DHCP Fingerprint

 

So now we go back to the IMC console and navigate to Service>>User Access Manager>> Endpoint Identification Management>> DHCP Character Identification Configuration

click the add button and input the values above

 

NewImage

 

Now that we’ve got the DHCP Fingerprint, let’s go after the HTTP Fingerprint.

 

Capturing the HTTP User-Agent Fingerprint

This time, I”m  running a packet trace from wireshark loaded on my IMC machine ( this is handy for a whole bunch of reasons)  I use the Internet Channel on my Wii and attempt to login to the IMC server. Now I check Wireshark again, this time using HTTP as the filter. I could also add the filter for the specific host 10.101.0.116, but in this case it’s just as easy to resort by the source server and get to the right packet.

NewImage

There it is… “Nintendo Wii”.

 

Now that I’ve got the HTTP User Agent Signature, I can now go back to IMC and add that in as well.

 

 

Creating the HTTP User-Agent Fingerprint

NewImage

 

Putting it all together

So, we created the DHCP Character Identification as well as the HTTP User Agent Feature Identification. Now we’re going to connect the wii to the BYOD-enabled wireless network and see what the  test this out and see what our work has gotten us. 

NewImage

 

Fingerprinting Successful.  As you can see, the Nintendo Wii was identified by the DHCP client identifier and has been successfully registered in the endpoint MAC address management list in UAM.

 

 

The one step other step which I did skip here was adding a MAC address finger print to identify devices which would allow you to identify the device by it’s MAC address. To be honest, that doesn’t require a packet trace, so I skipped that step. What fun is something that doesn’t require a packet trace?

 

@netmanchris