802.1x with MAC based authentication

For end devices that are 802.1x compliant, RADIUS authentication on them would be performed using either username/password or certificate. What about devices that aren't 802.1x compliant, such as network printers? The next best authentication on them would be MAC based.

MAC based authentication aren't as secure, as MAC addresses can be easily spoofed. Cisco called this "MAC Authentication Bypass" (MAB) while Microsoft called this "MAC Address Authorization".

How can we make Cisco MAB works with Microsoft NPS server?

Step 1: Enable "mab" on every switch port
On Cisco switches, assuming that the usual dot1x configuration are already in-place, you'll just need to add the command "mab" on every 802.1x enabled switch port connecting to end-devices.

Step 2: Add new MAC-based connection request policy
On Microsoft NAP server, add another new connection request policy and enable PAP authentication. This new PAP policy should be placed after the main 802.1x policy, so that the 802.1x compliant devices can get authenticated in a more secure way first. As Cisco switches uniquely identify MAB requests by setting Attribute 6 (Service-Type) to 10 (Call-Check) in a MAB Access-Request message, add this condition to the MAC connection request policy.

Step 3: Tell the authenticating server to use Calling-Station-ID as MAC-based user name
Set the User Identity Attribute registry value to 31 on the NPS server. This registry value location is: HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy. If it doesn't exist, create a new DWORD value.

Step 4: Add a new AD user account for each MAC device
The new user account must be named (all lower case with no space or dash) exactly as the connecting MAC address for each non-802.1x device e.g. aa00bb11ccddeeff format. Its password must also be set as the same as MAC address. Hence, creating such accounts might fail due to domain-based complex password policy. The good news is we can use Fine-grained Password Policy to overcome it.

Step 5: Test it
Connect a non-802.1x device and test. Observe the outcome on the event viewer of the NPS server. Take note of any errors and troubleshoot accordingly.

Implementing NAP with 802.1x enforcement

In my earlier post, I've configured 802.1x with EAP-TLS. Now, I'm expanding the effort to Network Access Protection (NAP) with 802.1x enforcement. Machines that are validated compliant to the policy are able to access authorized network or VLAN. Otherwise, it would go into Guest VLAN for further remediation action. In NAP with 802.1x enforcement, clients would send Statement of Health (SoH) to the Windows NPS server for System Health Validation against the Health Policies on top of 802.1x authentication. The SoH would contain information pertaining to the Security Center of the Windows clients.

In this example, I would just configure the Health Policies to check the status of Windows Firewall. The Windows 7 client and the NPS (Windows Server 2008 R2) have been setup in a full AD environment with AD Certificate Services. All certificates have been issued and the network switch is configured with 802.1x settings.

On the NPS server, click on the "Configure NAP" to start the wizard. Follow the wizard instructions carefully. Go to the "Connection Request Policies" after the completion of wizard. Right-click on the NAP policy and click "Properties". Click on the "Settings" tab and edit on the "Microsoft Protected EAP (PEAP)". Read the below underlined description that you must configure the PEAP properties here.

Choose the correct server cert that is generated based on the "RAS and IAS Server" template as mentioned in my previous post. In addition, ensure that the below highlighted items are added and enabled. Edit on the "Smart Card or other certificate" to choose the correct cert and CA if you're using cert authentication.

On the client configuration, it would be more efficient to use Group Policy to configure and enable the NAP setting. On the computer configuration, create the "Wired Network (IEEE802.3) Policies" as shown below:

Ensure that the clients' PEAP authentication settings match the NPS server's. In addition, under the "Security Settings", edit the Startup of "Wired AutoConfig" and "Network Access Protection Agent" to "Automatic".  Next, go to "Network Access Protection" to enable "EAP Quarantine Enforcement Client". You may also like to configure other optional settings like "User Interface Settings".

Once the GPO is created, link it to the client OUs and run "gpupdate" on the Windows 7 client. Check the status on the event viewer. If everything runs well, try disabling the Windows firewall and it will be enabled back automatically for compliant. For more details and troubleshooting, refer to this NAP with 802.1x enforcement step-by-step guide.

A certificate could not be found that can be use with this EAP when configuring 802.1x on NPS

I was running the default 802.1x wizard to configure a new RADIUS server on Windows Server 2008 R2. I had an error that prompt "A certificate could not be found that can be use with this Extensible Authentication Protocol" as shown below:

But when I run the cert manager, I saw a computer certificate! So what's wrong?! It's the template. Most of the time, we configure auto-enrollment for machines based on Computer template. This time, you'll need the "RAS and IAS Server" template. Rather than auto-enrollment, you may want to perform a manual cert enrollment for the NPS server. Hence, I duplicate a new NPS server template from the "RAS and IAS Server". And yes, you'll also need to register the NPS server on AD using "netsh ras add registeredserver" command. Ensure that the NPS server is a member of the "RAS and IAS Server" security group on the AD.

To further ensure that the NPS server is using the "correct" cert, click "edit" on the PEAP or EAP-TLS authentication method and verify the cert as follows:

In summary (click for detailed step-by-step guide):

1. Register the NPS server 
2. Enroll a new cert based on "RAS and IAS Server" template
3. Excellent link for NAP with 802.1x troubleshooting
4. Setting up & verifying NAP CA to issue health certificates

RADIUS and VRF

In my earlier post "Setting up RADIUS authentication for Cisco devices", there is a set of example Cisco IOS commands to define the RADIUS server for Cisco authentication. However, it can't work if you apply VRF, even if you use the "ip radius source-interface" command.

If you have Cisco devices using Multi-VRF and/or MPLS related commands, you have to define "aaa group server" instead. Other advantages include server load-balancing and grouping them for different purposes, such dot1x and login etc. Below are the example commands.

(config)# aaa authentication login NetworkLogin group NetworkRadius local
! group up the servers
(config)# aaa group server radius NetworkRadius
(config-sg-radius)# server 1.1.1.1 auth-port 1812 acct-port 1813

! define VRF and source interface
(config-sg-radius)# ip vrf forwarding YOUR_VRF
(config-sg-radius)# ip radius source-interface Loopback 0
! define the radius server
(config)# radius-server host 1.1.1.1 auth-port 1812 acct-port 1813 timeout 5 key ****
! apply the RADIUS authentication list
(config)# line vty 0 4
(config-line)# login authentication NetworkLogin

To verify the configuration, do "show radius server-group all" on the exec mode.

RADIUS Shared Key Template

In one of the comments in my earlier post "Setting up RADIUS authentication for Cisco devices", someone asked whether he should have all network devices having different radius keys. Don't get it wrong, this is the shared key between the RADIUS server and the client (e.g. Cisco or other network security devices), which is a RADIUS requirement. We are not referring to the individual user credential used to gain administrative access into the Cisco devices or the network resources. Note that the same RADIUS protocol is also commonly used for other applications, such IEEE 802.1x, WPA2, remote dial-in etc. These applications would also face similar issue of having shared secret between the security device and the RADIUS server. See this RADIUS overview on Wiki.

I felt that might poised another more serious security issue. Imagine there can be hundreds of devices under his care, what if he lost or accidentally leaked that long password list?

To strike a good balance between manageability and security, I would advise that those less critical devices can share a common key while applying another common key for more sensitive/critical devices (fewer in number). For highly sensitive/critical devices, a unique key may be applied.

Fortunately, Microsoft RADIUS or the Network Policy Server (NPS) in Windows 2008 R2 provides shared secret template feature to facilitate that. A group of devices belonging to similar security level can share a common shared secret template.

To create a new template, open up NPS server console, expand on "Template Management", right-click on "Shared Secret" and add "New". A small windows would pop up:



Give it a name and add in the shared secret. Click "Ok". On the properties of RADIUS client, select the relevant template on the drop-down box.

Setting up RADIUS authentication for Cisco devices

I know this is not new but would like to elaborate slightly further for my team. The "Network Policy Server" in Windows 2008 can serve as a central AAA mechanism for all Cisco logins. Furthermore, each network administrator can login using their individual credential (which is AD-integrated) instead of sharing a common set of local passwords, which is an administrative nightmare if these passwords are compromised.

This blog explained the initial setup. To continue adding more RADIUS client (i.e. Cisco devices), log on to the NPS server and fire up the Network Policy Server console.

1) Add RADIUS client
Right click on RADIUS client and click "New". Enter the name of device and the IP address. As a Cisco device may have multiple interfaces, I would prefer using the loopback address. Also, supply the pre-shared key between the server and the client.


Note: Both IP addresses and the key must match. If not, authentication would fail.

2) Cisco Configuration
Cautious: Make sure you have another running line or console before you do this.

aaa new-model
#use radius login 1st. when time-out, use local password
#you may want to define your own list. Make sure the list in red must match the login vty below
aaa authentication login RadiusList group radius local
#make sure it matches the client IP address in the NAP server earlier
ip radius source-interface Loopback0
#replace the below brackets with your values
radius-server host [server_IP] auth-port 1812 acct-port 1813 timeout 5 key [your_key]

#apply authentication method
line vty 0 4
access-class MGMT_ACL in
logging synchronous
login authentication RadiusList
transport input ssh

3) Verifying & Troubleshooting
Try ssh into the device. If unsuccessful, check network connectivity from the client using "ping [server_IP] source loopback0". Run "debug radius" command and go to the event viewer of the server. For easy viewing, open up the Server Manager console and click on the "Network Policy Manager" where the login events are filtered automatically for you.

4) Change the prompt (Optional)
How do you know which are the devices use RADIUS or local authentication? Simple, just change the login & password prompts.

aaa authentication banner ^CAccess to this device is protected by NAP^C
aaa authentication password-prompt "NAP password:"
aaa authentication username-prompt "Your NAP id:"