Getting 802.1X to Work

[deanwebb]

While I firmly believe that 802.1X is *not* a complete NAC (Network Access Control) solution, I do believe that it can be part of a complete NAC strategy. Therefore, it is necessary to have some of it when building a network with the intention of keeping the baddies out and the good guys in.

The most important place to start with 802.1X is on the wireless network. There are three reasons for this:
1. The wireless network is the most available to people both inside and outside your building doors, far more so than the wired network.
2. Commercial wireless controllers are very ready to participate in an 802.1X environment.
3. It will be your first "big win" to show to your internal customers how NAC can help to regulate entry to the network.

Before I go any further, I want to mention that one way of referring to 802.1X that is less of a mouthful is to call it "dot-one-x", written as dot1x. It's also easier to type, so I'll use that from now on in this guide.

To perform dot1x properly, you'll need to have a RADIUS controller, a directory server, and a CA (certificate authority).

The CA is needed because you want something to exist on your company's devices that will identify them correctly. That's a company certificate. If your PCs don't already have a certificate installed on them, this is something you will want to coordinate with the appropriate staff. If the PCs do have that certificate, then that is what you want to check for when devices attempt to connect to the wireless network.

For a directory server, most companies use Microsoft Windows Active Directory. Your RADIUS server will need to bind to it either via unauthenticated or authenticated means, depending on your product. For an authenticated bind, you will need an account from that domain that the NAC system can use for logins. It should be a system account: if you use a user account, then should that user change passwords without updating the RADIUS server settings, you can have the entire dot1x environment go dark.

The CA needs to be connected to the directory server so that when the directory server is queried about a machine account, it can also pass along a request to the CA for certificate validation. This makes a Windows Server CA ideal for interoperating with the AD environment.

Your RADIUS server is most likely the NAC system itself. I've actually gotten competing vendors' products to act as proxied RADIUS servers for each other, so this is a technology that is pretty resilient and easy to set up. The RADIUS server will have credentials for querying the directory server, for machine account and certificate checking, as well as the IP addresses of all the switches and wireless controllers that it will be receiving RADIUS requests from. It will also have a shared secret that it uses with the switches to secure communications.

Set the RADIUS controller to check for a valid certificate from the internal CA. This will succeed if both the machine account for the device and the certificate for that machine are valid.

On the switches and wireless controllers, configure them to use the RADIUS server as per vendor guidelines. Note that for wired LAN switches, I strongly, STRONGLY recommend getting them upgraded to the latest code level possible to provide the best functionality for dot1x.

For Windows clients, you will want to push a WLAN profile for a PC that has logged on successfully to the dot1x SSID to all PCs. The reason is that this will help avoid a pop-up warning that Windows devices will throw up when they see a new RADIUS server whose information was not included in the profile settings. As for wired dot1x, I strongly, STRONGLY recommend using a vendor-supplied or third-party client piece (also known as a supplicant) because the native dot1x wired supplicant on Windows has had a poor performance history. Using a third-party client, you can have a much easier time of managing wired dot1x logons.

You will want that ease because a wired dot1x failure can result in some severe penalties, up to and including putting the switchport into an err-disable state. Even if you have a switch programmed to automatically resolve err-disable states, if the client issue is not corrected, it will go back into an err-disable state when the port is recovered.

This is why it's also strongly, STRONGLY recommended to run dot1x on the wired LAN in monitor mode first, so that you can get an idea of what machines need remediation prior to switching over to full enforcement mode.

[Fred]

I have a couple things to add:

If your PCs don't already have a certificate installed on them, this is something you will want to coordinate with the appropriate staff. If the PCs do have that certificate, then that is what you want to check for when devices attempt to connect to the wireless network.

It's worth noting that your 802.1x can be as weak as the protection of your CA. It's worth investing a little more in protecting that CA over just installing certificate services. I've seen straightforward CA installs collect literally millions of certificates in a few years time if not deployed correctly, so make sure you budget for some education/consultants to make sure you have a proper tiered architecture for your CA, or that you're restricting access to that CA appropriately.

You also need to figure out how to handle printers, phones, or other devices that can't do 802.1x correctly.  Microsoft's IAS (or whatever it's called now) doesn't handle this very well. An alternative RADIUS implementation adds flexibility, but requires some additional research/training. There are definitely tradeoffs here. If you choose to use mab or some other form of bypass, you may want to implement ACL's or firewalling to prevent those devices from having full access to your network.

I believe NAC is a big win for a more secure network, and 802.1x can likely be implemented with your existing switches and infrastructure.

[dlots]

If you go to http://www.dhimes.com I have documentation for how to do dynamic vlans with 802.1x where it will change the port's vlan depending on your AD credentials, letting you have what you could call a 802.1x DMZ vlan, maybe make that a private vlan or something, so if there are issues you can still get to windows update servers, the helpdesk's remote support vlan, etc.

For printers and such you can just use MAB (Mac address authentication) just make a user out of the mac address and stick it in the proper group.

The link to the file specifically is http://www.dhimes.com/Files/802.1x%20demo%20clean.zip

[deanwebb]

Some videos I just did on the topic:

https://youtu.be/55C-s-NmMOk 802.1X Troubleshooting

https://youtu.be/C2rp5HFDJho Communications with helpdesk and client guys before going full enforcement

https://youtu.be/t-93G4Za4sk RADIUS Status Messages and Troubleshooting

I plan to add one on MAC-Bypass soon.

[flipmode]

I did this on my equipment last week and did a wired 802.1x implementation. I struggled a bit but finally got it. Installed  NPS (RADIUS), a CA, AD along with DNS on Server 2012 and configured my 2960 to be the Authenticator, DHCP was on my 3550. I kept getting the error on my NPS logs that EAP type could not be processed by the server. Fix was to change the constraints on my NPS to do PEAP instead of EAP-MSChapv2, my Win7 client only does PEAP and several other flavors of EAP but not EAP-MSCHAPv2. I'm guessing this is why Dean recommends using a third party supplicant.

Anyway, I was finally able to authenticate to the network, grab an IP address and see in the NPS log that I was granted full access to the network. I'm going to assume I did it right since all these things happened LOL

Thanks Dean for creating this lab section. Helps newbies like me out a lot!

[deanwebb]

It's one of the reasons, yes. Also, EAP-MSCHAPv2 is deprecated in favor of PEAP or, better, EAP-TLS. Part of security is in keeping up with the phase-out of older protocols and methods and keeping current with the new.

[flipmode]

Edited: I'll do a little research before asking the question