The environment consists of:
- Windows 10 domain-joined PCs (and some not domain-joined)
- VoIP phones
- Receipt printers
- Letter printers
- Barcode printers
- Credit card readers
- Windows Server running NPS for RADIUS authentication
That said, these screenshots and notes will all come out of my home lab. Here's a link to my syntax source.
Installed NPS on a test server and told it that my test switch would be a RADIUS client. Created a wildcard "Connection Request Policy" to accept the MAC address of a test Windows PC:
Told the switch what RADIUS server to use:
radius-server host 192.168.100.5 key "xxxxxx"
Configured ports 3 and 4 on the switch to require RADIUS authentication - and if RADIUS authentication doesn't happen for any reason, to drop a connected device onto VLAN 3:
radius-server host 192.168.100.5 key "xxxxxx"
Configured ports 3 and 4 on the switch to require RADIUS authentication - and if RADIUS authentication doesn't happen for any reason, to drop a connected device onto VLAN 3:
aaa authentication port-access eap-radius
aaa port-access authenticator 3-4 unauth-vid 3
aaa port-access authenticator 3-4 client-limit 2 #allows up to two devices per port
aaa port-access authenticator active
aaa port-access authenticator 3-4 client-limit 2 #allows up to two devices per port
aaa port-access authenticator active
The switch offers both chap-radius and eap-radius...these are simply frameworks for transporting authentication to the server...for chap-radius to work, the user/computer password in Active Directory needs to be stored with reversible encryption (not the default), so eap-radius seems preferable.
Next, I started the "Wired Autoconfig" service on the test Windows PC (you can do this via group policy in a production environment)...this service offers credentials to the switch for authentication by RADIUS...I learned (and you can see this in a Wireshark packet capture!) that when a computer boots up it'll try to authenticate with its computer account...and then after a user logs in, it re-authenticates with the logged-in user account. So cool, huh?
So far, no certificate was needed on the NPS server. However the Windows PC complained on its NIC that "Authentication Failed" (but it was still given the "authorized" VLAN due to the Connection Request Policy that I'd created).
So, how to fix this message? Created a Network Policy with an authentication method of PEAP:
Now the NIC was happy:
...and bear in mind that this is without any client-side certificates. I like that. Keeps it simple.
Next: get my VoIP phone working. However, when I plugged it into the switch, the switch never said a thing to the RADIUS server, instead it just dropped the phone into my unauthenticated VLAN (3).
The solution is to enable MAC authentication in the switch as a fall-back mechanism for when devices don't do 802.1x authentication. (Syntax source).
The first step of this was to disable something I'd done earlier:
no aaa port-access authenticator 3-4 unauth-vid
...then replace it with this:
aaa port-access mac-based 3-4 unauth-vid 3
This is because if 802.1x authentication fails on switch ports 3 or 4, then MAC address authentication will be tried...and if that fails, then the device will be dumped into VLAN 3 (my DMZ).
Let's support up to 2 devices per-port on ports 3 or 4 (e.g. a phone with a computer behind it):
aaa port-access mac-based 3-4 addr-limit 2
Now let's enable MAC address authentication for ports 3 and 4:
aaa port-access mac-based 3-4
Now we'll view status:
A VoIP phone was on port 4...disconnected / reconnected the phone's patch cable....it got a new IP from VLAN 3 and rebooted.
This was good. Now, how do I authorize it in NPS?
I'm using a wildcard MAC address here, and I got the format of the MAC address from a Wireshark packet capture:
So at this point I have a PC that authenticates via its computer account and a phone that authenticates via its MAC address. Yay!
The first step of this was to disable something I'd done earlier:
no aaa port-access authenticator 3-4 unauth-vid
...then replace it with this:
aaa port-access mac-based 3-4 unauth-vid 3
This is because if 802.1x authentication fails on switch ports 3 or 4, then MAC address authentication will be tried...and if that fails, then the device will be dumped into VLAN 3 (my DMZ).
Let's support up to 2 devices per-port on ports 3 or 4 (e.g. a phone with a computer behind it):
aaa port-access mac-based 3-4 addr-limit 2
Now let's enable MAC address authentication for ports 3 and 4:
aaa port-access mac-based 3-4
Now we'll view status:
A VoIP phone was on port 4...disconnected / reconnected the phone's patch cable....it got a new IP from VLAN 3 and rebooted.
This was good. Now, how do I authorize it in NPS?
I'm using a wildcard MAC address here, and I got the format of the MAC address from a Wireshark packet capture:
So at this point I have a PC that authenticates via its computer account and a phone that authenticates via its MAC address. Yay!