Today’s story is a short how-to on implementing 802.1x authentication for wired switch ports. In other words, workstations have to authenticate to be allowed on the wired network (just like your wireless network should be configured). I was actually surprised to see 802.1x as part of the CIS Critical Control #1, where you’d expect “hardware inventory” stuff to go – it’s actually CC 1.6, 1.7 and 1.8. But this does make sense, this not only controls where and when your gear can authenticate, but also controls the access that the “not your gear” stuff has (if any) when that stuff tries to connect.
So why do people want this, and why is it part of the Critical Controls? Because it really is about controlling both your known and unknown inventory. Known devices authenticate properly, and are given access to the network. Unknown devices (visitors, or unsanctioned gear of any kind) are either denied access or shuffled off to a jail or guest VLAN. Either way, the access requests for the “unknown” devices are all logged and can then be investigated if that’s the next step in your organization. Only known inventory is allowed access to the network.
Before we dive into this, 802.1x is a method for controlling the access of workstation inventory. I have never seen this deployed for servers. I'm sure that there's a corner case where it makes sense inside of a datacenter, but I haven't found one (please let us know via our comment form if you have). So this configuration is generally for workstations and workstation switches only.
The diagram below outlines the various systems components used in Network Authentication (802.1x) for both wired and wireless networks. The assumptions here are:
Authentication Sequences - Wired Networking
Domain Member Workstations (also anything that's been issued a Cert manually)
MAC Address Authentication / Bypass
Printers can be issued certificates and work exactly like workstations, but in many cases the printers are outsourced, or if they do own them, a majority of them will be so old (or so cheap) that they won't support 802.1x authentication. In those cases, often the client opts to use MAC Address Bypass (MAB) authentication to authenticate the printers. In this case:
The problem with this is that MAC address spoofing is not a challenge for most attackers. In fact, you could likely automate something like this with a Raspberry Pi (discover the printer address, and present it out a second Ethernet – or even just act as a transparent bridge).
The problem here is obvious, the handsets are simply trusted – and both CDP and LLDP are easily spoofed.
Wired handsets (Cisco in particular, but certainly most other major brands as well) can be issued certificates by their management application – the Cisco implementation uses “LSC” (Locally Significant Certificates). In some cases the management app can work as a subordinate CA to the enterprise CA (which in our fictitious company is a Microsoft Certificate Server). In other cases, the voip management app is a CA all on its own, in that design you’d need a separate policy in NPS, or maybe even a separate RADIUS host for the phones.
User and Computer Certificates
This GPO forces Users and Computers to request Certificates from the Certificate Authority. This process initiates a “CSR” (Certificate Signing Request). The CA automatically processes all CSRs from domain member workstations and users, and issues the requested certificate. Push this certificate out first, and ensure that most or (preferably) all workstations have their certs before you proceed on.
Wired Authentication GPO
This GPO governs authentication of wired workstations, using the 802.1x protocol.
The key points in this GPO are:
This GPO also needs to be pushed out with some “wait time” factored in, before you can configure your switches. This ensures that when you set the enforcement on the switch policy, the workstations are able to authenticate. This GPO starts a new service on the workstations, “Wired AutoConfig”. Checking for this service in a running state is a handy way to ensure that your workstations are “ready to roll” for 802.1x.
The fun part here is that if machines don’t reboot or cycle power after they get this GPO, the service won’t start. And with Windows 7 and 10, it’s really common now to see machines only reboot for patches – people just seem to lock, sleep or hibernate them anymore. You may need to enforce a reboot or manually start the service with a script to get this step completed.
RADIUS Server Configuration
Wired Authentication using 802.1x
The radius policy for wired 802.1x is set up with:
Not that you can also set a VLAN for non-compliant hosts, normally this is set on the switch port, and is set to some internet-only “guest” VLAN, or else a “jail” VLAN where there are just enough resources for the helpdesk to remediate your computer (see the switch section of this article for those settings)
MAC Address Bypass (MAB) - Printer Authentication
If you choose to implement MAB, you’ll need to define a group that the printer “accounts” will be in. Using Fine Grained Password Policy (FGPP), you’ll want to relax your password policy enforcement for these accounts. Also set those accounts so they can’t actually login to the domain.
The printers get the same policy as the workstations in NPS, except:
Printer Password Policy
The default domain policy enforces a password policy, which denies accounts the use of their account name as their password – for instance the user “Joe User”, with the userid of “juser”, cannot use “juser” as their password.
To make things work for MAC address authentication, use a “fine grained password policy” (FGPP) that relaxes this requirement for printer accounts, which use their MAC address for both userid and password in the MAB (MAC Address Bypass) implementation. This policy is illustrated below, and is applied only to the group “MAB Group for FGPP”, which is also shown:
Apply this policy to the OU or the AD Group that the printers are in.
Of course you can do 802.1x authentication on just about any name-brand switch. I chose a Cisco switch as an example for this story - all features are implemented, and the config is fairly simple. Other switch vendor configurations will be similar(ish) to this.
First, the switch configuration is set up to allow 802.1x authentication, and the authentication source is pointed to (at least) 2 RADIUS hosts.
radius server RADIUS01
radius server RADIUS02
aaa group server radius RADIUSGROUP
aaa authentication dot1x default group RADIUSGROUP
Next, the individual ports are configured. A typical workstation / phone / printer port is shown here:
Again, I did cover off the configuration for both MAC Address authentication and “trust the phones”. Neither is recommended if you are truly trying to secure things. However, in an open office environment with controlled access (visitor signin and locked doors), you can make the case that there are at least some compensating controls to hinder a physical pen-tester or on-premise attacker.
Given how hard the telephony and printer vendors make 802.1x, customers often take these two “shortcuts”. Just be sure that everyone knows what they’re giving up when they go there!
Do you have any success stories (or "down in flames" stories) of 802.1x authentication projects you've seen? Please, share using our comment form!
Jul 18th 2019
Jul 18th 2019
11 months ago
Nice article about 802.1x. I wasn't sure I could print it out but I was able to. Hope you don't mind my sharing with the AD admins.
Jul 18th 2019
11 months ago
A PDF Document would be great :)
Jul 18th 2019
11 months ago
Rob, another excellent write-up!
Yeah so, I remember helping with a 802.1x implementation at a small office a number of years back. I remember it being fairly tedius/time consuming to get done. The one memory that really stands out was a few old HP printers that we simply could not get to authenticate. Other than that, it worked well, allowing us to check off another important box in our compliance list. BTW - The mention of PAP brings back memories of dial-up days, i.e., PAP/CHAP
Jul 19th 2019
11 months ago