In the beginning, one of the biggest challenges with Cisco ISE was authenticating both an individual user and the machine they are using to login to the network. This was difficult due to a limitation with the Windows operating system. Simply, Windows was designed to authenticate the user or the machine, but not both simultaneously. During bootup or really any time the workstation was at a login screen, Windows sends the machine credentials. When the user logs in, Windows will then send the user credentials. The problem is, ISE or really any other NAC solution, sees these as two completely separate authentication events.
Machine and User Authentication - The Old Way
There were two ways to get around this limitation.
Machine Access Restrictions (MAR)
MAR is a method ISE uses to “join” the user and the machine authentications. When the workstation authenticates successfully, ISE records its MAC Address in a database. When the user logs in, ISE then checks the database to ensure the MAC Address they are using for the login is in the allowed database. This is easy to do, but has several drawbacks:
The machine authentication only happens when the workstation is logged out while attached to the right network (E.g., wired or wireless). Often users don’t actually logout of their workstations, even at night. Rather, they either lock the screen or let the PC go to sleep. Neither triggers machine authentication.
Security is an issue. Basically, after the machine authentication takes place, from that point forward, the machine is using MAC Address Bypass (MAB). MAB is okay when you don’t have any other option, but it is not true security as it is easy to spoof a MAC Address.
Timing. The length of time an endpoint stays in the MAR database is configurable. If you set the timer too short, users complain they must reboot too often. If you set the timer too long, you are effectively disabling 802.1x for the machine.
AnyConnect with a NAM Profile
The second option was to use AnyConnect (EAP-Chaining with EAP-FAST) and have it take over the Windows network login functionality. The AnyConnect supplicant does have the ability to send the user and machine credentials simultaneously. While this was certainly superior to MAR, it still had a few drawbacks:
Licensing cost was an issue for organizations that do not already have AnyConnect in production.
A relatively steep learning curve for the support organization. Of course, the service desk knows how to check network settings on a PC, but this process is completely different when you use the AnyConnect supplicant.
Several challenges related to users that travel to different sites or vendors.
Many strange little caveats that made the deployment for non-experienced engineers difficult.
TEAP to the Rescue!
Currently, TEAP (Tunnel-Based Extensible Authentication Protocol) is the only EAP method that allows a native Windows machine to send both user and machine authentication to ISE. The protocol came out in 2014 but was not supported by ISE and Windows until ISE v2.7.
TEAP is used for the tunnel establishment. This is good news as TEAP doesn’t really care what goes into the tunnel. For example, you can use traditional credentials (username/password) or certificates, or a combination of both. This makes the transition to TEAP simple as you do not have to change any underlying authentication mechanisms. Simply turn it on, update the endpoint supplicants (GPO) and off you go.
Finally, there is no need for a hard cutover. You can have TEAP and your legacy method (PEAP/EAP-TLS) up and running at the same time.
ISE TEAP Configuration
This blog post will not go over the basic ISE setup or the network access device configuration. We assume that is already in place and you are switching from a legacy method to TEAP. The good news is this is going to take 30 seconds. 😊
Turn on TEAP:
Navigate to: Policy --> Results --> Authentication --> Allowed Protocols --> Default Network Access (Or whatever you named your authentication policy)
Here we must enable TEAP, turn on EAP Chaining, and choose which inner methods we want allowed. We can choose EAP-TLS for certificate-based authentication or MSCHAPv2 for password-based authentication, or both.
ISE TEAP Policies
We won’t get into DACLs or VLAN changes or any other configuration you have in your authorization profiles, it is assumed this is already in place.
Typically, we want to create three policies for AD joined workstations.
User-Only: This policy will match when the user authentication is successful, but the machine authentication failed. You can either deny access or push a restricted DACL, if you prefer.
Machine-Only: As you guessed, this is the reverse. The machine is successful, and the user failed.
User and Machine: Of course, this is both the user and machine were both authenticated successfully.
These rules can replace your legacy policies or run alongside of them. I typically create the new policies and specify the EAP Tunnel (TEAP) to ensure the new policies will only match the new authentication mechanism.
I told you it was going to be easy. 😊
Windows Supplicant Configuration
This is typically completed with a GPO. Here I will show you how to do it manually, from there it is trivial to translate the configuration to the GPO:
Step 1: Turn on TEAP.
Step 2: Click “Settings” and configure Identity Privacy. Identity privacy sends a generic username when the actual username is not present.
Step 3: Still within settings, choose your certificate configuration. These settings will be the same as they were with the legacy method:
Step 4: Still within settings, choose/configure your authentication method:
Username/Password (MSCHAPv2)
Click configure and choose whether or not you would like to use the credentials of the logged in user/machine. I’m certain you do.
Certificate Authentication
Click configure and choose your certificate settings. Assuming you already have EAP-TLS in production, these settings will all be the same:
TEAP Testing
We have a very basic lab setup:
The FTD is not really in use and the switch is configured with the basics for 802.1x. The ISE Servers live in the Servers cloud. We’ll use the Bob-PC and its owner, as you guessed, Bob. Bob is going to authenticate via TEAP with MSCHAPv2 initially. His user account and machine account should be authenticated simultaneously.
Let’s look at the details:
A few more details…
Authentication Protocol: TEAP (EAP-MSCHAPv2)
Authentication Status: AuthenticationPassed
EAPChainingResult: User and machine both succeeded
Now we can run the same test, but this time we will use certificate authentication:
Authentication Protocol: TEAP (EAP-TLS)
Authentication Status: AuthenticationPassed
EAPChainingResult: User and machine both succeeded.
Using TEAP for user and machine authentication is certainly a slam dunk for a greenfield deployment or a replacement for MAR. If you already have AnyConnect/NAM in place and there are no troubles, there isn’t much benefit to replacing it.
Next Steps: Optimizing Your Network Security
While this blog post focused on a simplified setup, real-world deployments involve additional considerations. These might include pilot programs, user testing, Group Policy Objects (GPOs), and change control procedures.
Despite these additional steps, even this basic implementation can significantly improve the efficiency and streamline the management of your Network Access Control (NAC) environment. This paves the way for a more secure and manageable network infrastructure.
CDA understands that transitioning to a production NAC environment can involve complexities beyond the scope of this post. If you're considering implementing NAC or require assistance optimizing your existing solution, CDA's experienced network security professionals can help.