Client restarts authentication after Windows logon

[daan-ce]

Hello community

I'm trying to set up ISE to do dot1x authentication for Windows client using EAP-TLS and PEAP with MSCHAP-V2.

The client has both a computer certificate and a user certificate loaded. However, we only want to use the computer certificate for primary authentication and then Windows-credentials as secondary authentication.

I have configured the Policy set as follows:

1. ISE checks if the Radius Flow Type is dot1x (wired or wireless), then applies my certificate authentication sequence, which extract the SAN which hold the computer name from the PC cert. The sequence also includes Active Directory to perform lookup of the machine name.

2. The authorization sequence then applies a computer-auth ACL with limited access:

3. After Windows logon, the client should send its Windows credentials and the second auth rule should hit (with condition WasMachineAuthenticated set to True). Then a full-access ACL should be pushed. As you can see this rule gets never hit.

I see in the logs that computer authentication is performed as expected. The method used is EAP-TLS and the PC gets authenticated, the initial ACL gets pushed to the client.

Then after the user logins to Windows, the PC starts all over again, ignoring its previous authentication and pushing its user certificate with EAP-TLS. This fails as the user cert does not have a valid username in its SAN-field. It also hits the wrong authorization rule, the one that is configured for machine authentication.

The network adapter settings is configured as follows:

• Network authentication method is set to Microsoft Smart Card
• In additional settings, authentication mode is set to "User or computer authentication". According to the guide I'm following this should be all that needs to be done from the client perspective.

Any help would be very welcome

Thanks

Daan

[hslai]

@daan-ce If you are using Windows 802.1X native supplicants and if you are not using EAP-TEAP, then what you observed is expected. You may either switch to Cisco AnyConnect (aka Secure Client) NAM as the supplicant or switch to EAP-TEAP. For latter, see the articles on the net, e.g.

• TEAP for Windows 10 using Group Policy and ISE TEAP Configuration (Cisco Cummunity Security KB) 
• EAP Chaining with TEAP (Cisco ISE TechNotes) 

[daan-ce]

Hi Hslai

Thanks for your answer. However, shouldn't PC cert + user credentials (mschapv2) be possible without Anyconnect or TEAP?

I know PC cert + user cert and chaining those requires TEAP/Anyconnect, but that is not what we want to do. The client has user certificates but we don't want to use that one for authentication.

[hslai]

@daan-ce Until TEAP, the network authentication method in the Windows 802.1X native supplicant's profile applies to both the user and the machine. It might be over-kill but Windows 802.1X supplicants have no knob to control different authentication methods used by users and computers, other than for EAP Chaining.

[daan-ce]

Hi hslai

Thanks for the information. So where does the "wasmachineauthenticated" condition come into play? I thought ISE could check whether the PC was already authenticated and be able to do a different kind of authentication for the user? What we're seeing is that the wasmachineauthenticated condition is not met, although ISE did authenticate the PC before.

[hslai · Accepted solution]

@daan-ce wasmachineauthenticated is Machine Access Restrictions (MAR), which is one of the Active Directory features in ISE, so the computers have to authenticate through Active Directory, either through EAP-MSCHAPv2 or EAP-TLS with certificate binary compare against Active Directory.