The Moose and Squirrel Files

September 18, 2008

Re-Imaging Computers in 802.1x Networks – Part 1

Filed under: Code, Network — Tags: , , , , — networknerd @ 7:37 pm

Postings are a little slow lately because I’ve just been to my first Cisco Networkers conference.  I did meet a guy Paul at a techtorial and we were discussing 802.1x.  Paul’s problem was how to deal with re-imaging.

Fortunately I’d already tackled and documented that issue and was able to email my document to him.  Extrapolating from the fact that one person found it useful, I thought I might re-write as a series of blog posts here. At least google will index it for others to find.  If you can’t wait for the blog posts to finish, leave a comment with your email address (obfuscated) and I’ll send you the whole document.

802.1x Basics

Port-based network access control is defined by the dot1x standard as a means of authenticating
devices attached to the network edge, and preventing access to the port where authentication

Dot1x defines three roles within the port based access control system.

  • Authenticator – usually a switch port that is configured to require authentication before passing traffic.
  • Supplicant – the device that requires access to the network.  The supplicant function is performed by software, either as part of the operating system (windows xp), as an add-on provided by companies such as Juniper/Funk and Cisco/Meetinghouse, or open source such as X-supplicant.
  • Authentication Server – checks the credentials of the supplicant on behalf of the authenticator. The authentication is usually performed via radius.

Problem Definition

The preboot execution environment (PXE) is an essential part of the re-imaging process. PXE is
built into the computer BIOS to allow network boot and automatic download of software images
and configuration parameters. Unfortunately the PXE environment has no supplicant or
credentials with which to authenticate. The switch port will attempt to initiate authentication,
performing a number of retries before timing out and leaving the port in the unauthenticated
state. The computer can neither obtain a DHCP address nor perform boot server discovery to
obtain a boot image.

Possible Solutions

Our options at this point are:

  1. Move the computer to a port in a physically secure location with dot1x disabled.
  2. Have the network administrator disable dot1x on the port, and enable dot1x again when re-imaging is completed.

EDITED TO ADD: Kevin’s comment points out a third option, Mac Authentication Bypass. I write more on that after I have finished this series of posts.

Drawbacks of Option 1 – Computer relocations are extremely unpopular amongst helpdesk staff
charged with re-imaging computers. Also, this option doesn’t scale well when deploying a new
image across the whole organisation.
Drawbacks of Option 2 – Enabling and disabling dot1x on the port will almost certainly fail.
Ultimately someone will forget to enable dot1x on the port, and the number of unsecured ports
will increase over time. The dot1x security will eventually become like swiss cheese.

An automated method that is part of the re-image operations is required.  If your re-imaging program allows scripting (like Altiris in this example) then a completely automated solution is possible.

SNMP to the Rescue

The essence of the solution is to use altiris scripting to perform snmp operations during the reimaging
job. SNMP is used to temporarily disable dot1x authentication on the switch port until
the image is delivered. But the security versus utility tradeoff also comes in to play here.
Compromises made for this solution are listed below.

  1. SNMP must be enabled on the edge switches where the computers to be re-imaged connect.
  2. SNMP read and write access must be granted to the altiris deployment server.
  3. The SNMP read and write community names to the switches are stored in plain text in the altiris scripts.

The only protections we can apply are snmp access control lists to the switches, and ensuring
operating system and file system security is set appropriately on the altiris server. Re-imaging is
optionally performed in a vlan that has limited connectivity in the local network. This protects to
some extent against failure to re-enable dot1x on the switch port. Firewall rules or access control
lists on the switches are used to achieve this.

The process of configuring a port for re-imaging consists of five steps.

  1. Obtain a list of vlans on the switch.
  2. Use the mac address to identify the bridgeport number associated with the port.
  3. Use the bridgeport number to identify the interface index of the port to which the computer is connected.
  4. Use the interface index to set dot1x port control.
  5. Use the interface index to set the vlan. (Optional, only if re-imaging vlans are used)

The next series of posts will discuss each of these steps in depth. I’ll provide detail of the method used to acquire the information, as well as vbscript functions that can be used in re-imaging scripts.



  1. When planning an 802.1X rollout, you can also accommodate this situation by using the MAC auth bypass mechanism in conjunction with your radius server. To start with, you need to configure your switchports to support mac auth bypass. This will allow the switch to perform an 802.1X authentication *on behalf of the computer* if the computer does not respond to 802.1X packets in a timely manner. It will send the mac address as the username and something else (vendor dependent) as the password. More info is available at When configuring the switch, make sure your mac auth bypass timeout is lower than your pxe timeout.

    There are two approaches to handling the radius side. Essentially, you need to make sure your radius server knows what to do when it sees a mac address as a username.

    Option 1 (low maintenance/lower security) is to have your radius server REJECT all these requests. Then, have your switchports defined such that the AUTH FAIL vlan is assigned to a vlan/ACL with access only to the PXE resources. (This can also be done with the guest/default vlan functionality).

    Option 2 (higher maintenance/higher security) is to have your radius server ACCEPT these requests from only currently-reimaging machines. To do so, you will need to add the mac address to the radius userlist (along with ACCEPT and the appropriate VLAN if necessary). This is most easily done if you have a datastore (file, ldap server, etc) separate from your normal active directory store, though they can be combined. As you begin to reimage a machine, you will add the mac address to the bypass userlist and when you are done reimaging, you will remove it. Great Bay offers a commercial solution that is quite useful in this situation.

    When #2 is operational, here is what occurs:
    1. The reimaging begins by adding mac AA:BB:CC:DD:EE:FF to the reimaging userlist.
    2. The machine boots.
    3. The switch sends 802.1X packets to the computer but it does not respond.
    4 After [timeout] seconds, the switch sends an ACCESS_REQUEST to the radius server using the machine’s mac address as the user name.
    5. The radius server looks in the normal userlist and does not find the username. Then, it looks in the reimaging userlist and sees the mac address.
    6. The radius server sends an ACCESS_ACCEPT to the switch with a particular VLAN &/or ACL.
    7. The switch opens the switchport to the VLAN.
    8. At the end of the reimaging process, the mac address AA:BB:CC:DD:EE:FF is removed from the reimaging userlist such that future attempts to authenticate with the mac address fail.

    The benefit of this model is that the switch is never manipulated, thus if anything goes awry in the script, you know that the switch was not permanently configured to a VLAN.


    Comment by Kevin — September 20, 2008 @ 2:03 am

  2. Thanks for your comment Kevin. Option 1 doesn’t really work for me because we’re already using the guest and auth fail vlans for guest access.

    I started my deployment in 2005 and the Cat3750 switches were shipping with 12.2(25)SEB. The MAC Authentication bypass didn’t release until 12.2(25)SEE in 2006. I expect if I didn’t have a solution before then I would have been lynched.

    I was using the ciscosecure ACS when I first read about MAC Authentication bypass, and although I didn’t really spend too much time looking, it seemed a little too labour intensive.

    Now that you’ve prompted me I might just go and look at the Great Bay product and revisit this IOS feature.

    Comment by networknerd — September 20, 2008 @ 9:07 am

  3. […] to test the MAC authentication bypass mechanism as an alternative to switchport configuration using snmp when re-imaging computers in an 802.1x network.   According to the Cisco documentation that requires an LDAP server to hold the MAC addresses of […]

    Pingback by Configuring OpenLDAP for Client Certificate Authentication « The Moose and Squirrel Files — October 26, 2008 @ 12:30 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: