Operating System Deployment in an 802.1x Environment

For those that have investigated, or deployed 802.1x port authentication on either a wireless or a wired network understand the benefits and additional security that such a solution offers. The ability to stop traffic at layer 2, at the port is a powerful security measure and one that has been tested by numerous customers, software and hardware engineers, and even yours truly at various plugfests and buried in the lab years ago as a Software Test Engineer in the team that did the first versions of our RADIUS server.

802.1x works, sort of....

The reason for the 'sort of' disclaimer is to address one very popular customer scenario where 802.1x can become a hindrance and that is in the area around operating system deployment (OSD).

Now, to scope this purpose of this blog a bit, I am going to address OSD with my network security guy hat on since there are many ways to deploy an OS (DVD, WIM, inline upgrade, OEM pre-install, etc...) I simply want to focus here on the ways that an enterprise would deploy an OS over the network. The most common methods of doing this would be via WinPE (Windows Pre-installation Environment), PXE (Pre-boot Execution).

Now, I know most of you who are still awake and reading this are going "what about all the other technologies used to deploy the OS like Windows Deployment Service (WDS), System Center Operation System Deploy, copying bits from a network share, etc... While these are important to understand, they are irrelevant if the machine that is trying to get the OS installed on it is unable to connect to the network, so for this discussion, let's focus on the chicken part of the chicken and egg problem here (or is it the egg part of the chicken and egg problem, I could never keep those straight!)

Understanding the basics of 802.1x

Before we move forward, it's worth a brief refresher on the simple flow of how 802.1x authentications works.

There are 3 requirements for 802.1x auth to work, they are (there is an assumption that you already have a user/machine account database of some kind):

- A supplicant

- An 802.1x capable hardware device (switch or AP)

- A RADIUS server

 

If a RADIUS Access-Accept is sent back to the switch, and then the PC is either put into a proper VLAN, or perhaps a permit ACL (Access Control List) is applied to allow it to talk on the network. It is at this point where we will start the discussion.

Chicken meet egg, egg meet chicken

By its very nature, 802.1x is designed to stop any and all traffic from machines that are either unauthenticated, unauthorized or non-compliant (in the case of those who are deploying Network Access Protection. Given this, what are you supposed to do with bare metal machines that neither have an operating system installed, or are using something like WinPE or PXE to boot to the network in hopes of connecting with a server that will be able to push down an OS image to it?

Fortunately there are a couple of options here when you have an 802.1x protected network and need to allow bare metal machines access to the network. I'll leave judgment as to the merits of these up to the reader.

Relying on physical security instead of network security

Let's start with what could be the easiest solution, and that is, take certain physical parts of the network and exempt them from 802.1x. What this means is that let's say you have a company that has 2 buildings (A and B), with 3 floors on each building.

Now let's say that your IT guys (or the guys who are responsible for putting the OS onto new machines) sit on the first floor in building B. When deploying 802.1x, you could configure all the switch ports on each floor in each building to be 1x enabled, except for the first floor in building B where your IT guys are. This would ONLY be advisable if you had additional security measures in place such as card key access, an armed guard at the door, etc.

Now when the company gets a new shipment of bare metal PC's they can now simply plug them into the wall to get onto the network and get access to their OS distribution servers and they are off and running.

This is obviously the least palatable solution from a network security standpoint, but it is worth mentioning as there are customers who do things this way today.

PXE Boot

PXE is an interesting case because the standard itself has been around since 1999 I believe, and yet, from a security perspective, very little has been done to address the interoperability issues with security standards such as 802.1x (which also became wildly popular in the mid to late 1990's).

Technet has a great explanation of the entire PXE process here.

While fairly rudimentary, PXE does allow for some basic forms of authentication in the form of a MAC address or GUID to be used as the identifier. The problem that this poses is that there is an assumption that the MAC address of this machine, or the GUID, is already sitting in Active Directory, or some database so that it can be verified. There is also the problem of relying on the MAC address since the device associated with the MAC address could easily be moved from machine to machine making the authorization by MAC address even less reliable.

So, can one do a secure PXE boot to an 802.1x protected network? Answer, not that I have found.

Cisco appears to have at least attempted to tackle the problem, but their solution is to simply interrogate the device first via 802.1x, and if that fails, then fail open (i.e. let the machine in). This is something call Pre-Authentication Open Access. As for other switch vendors, I really couldn't find anything to tackle this particular problem.

Basically, PXE is the ultimate chicken and egg problem in that the first step in PXE is to broadcast for an IP address via DHCP, but since the port is blocked by 1x, and there is no method for credential exchange in PXE, this scenario breaks.

WinPE

In December of 2009 Microsoft released a fix that allows both WinPE version 2.1 and 3.0 to be configured to do basic 802.1x authentication to the network. This fix can be found at https://support.microsoft.com/kb/972831. Note that you will have to click the link at the top of the page to request a separate e-mail with a link to download the actual package as this was released as a QFE.

This QFE allows you to create a custom 802.1x profile for the WinPE that allows you to do user based (MS-CHAPV2) authentication, or certificate based authentication (TLS). Unfortunately, since this was issued as a QFE I do not have a lot of information I can divulge on exactly how to do these things, or include examples, but this has been tested at some customer sites and is working.

The good news of this is that if you are using WinPE to do OS builds you now do not have to lower the security of your network by using any of the aforementioned methods of OS distribution!

Wrapping up

The good news about 802.1x is that it offers quite a bit of flexibility in this particular chicken and egg scenario, but more could certainly be done to address some of the shortcomings.

Just like everything else in the world of software, there is no magic bullet or perfect solution, but in this case, at least there are options, and that is really what is important. Not everyone will want to take the risk of not having a section of their corporate network's ports protected, and certainly not everyone has a list of every MAC address on their network in hopes of using PXE to authorize devices/machines on the network. We also have to realize as well that not everyone uses WinPE and even those that do may not want to (yet again) go and rebuild their images with 802.1x profiles and scripts to make 1x work.

For many customers, this particular issue isn't an issue since there is never an expectation that a machine without an OS would ever connect to their network (I know several customers in this situation) so the overall impact of this issue may be smaller than one thinks. It is also very common for customers who buy their machines from OEM's to have them re-installed with their corporate OS image already, so the only time this scenario would come into play would be if you needed to wipe the machine using a DVD and re-install that way.

Look for more network health and cloud security related topics in this space moving forward!

Comments

• Anonymous
  January 24, 2011
  Tough situation, only PXE is embraced by all and further developments made to remove the chicken and egg scenario, then it becomes a silverbullet. We are stuck too with failing to IP address because we cannot be authenticated.