I apologize for the length of this, but more detail seemed to make more sense. The summary is that I'm testing upgrading Secure Client to version 5.1.4.74 NAM, and I've found that the supplicant shuts off when a user whose session is authenticated with machine and smart card removes the smart card. I'm trying to determine if this is a bug or expected behavior. If it's expected behavior I need a solution to deal with it. After I wrote up the following, I did more testing and determined that the change in behavior actually started in Secure Client 5.1.3.62, and so the working state described below is actually good up through Secure Client v5.1.2.42.
Context:
I have a wired network with ISE 3.3 as authentication server, and Catalyst 9300 access switches with IOS 17.9.4. I'm using C3PL for the dot1x PORT_ACCESS_POLICY.
My clients are Windows 10 running AnyConnect (NAM) 4.10.02, and my configuration is set to authenticate the clients with EAP-FAST chaining.
The machine cred is MSCHAPv2, and the user cred is Smart Card certificate, and these are pulled from the OS (ie Single Sign On)
Dot1x authentication is successful, as is reauthentication.
I also have some devices on the network that require MAB authentication.
MAB for those devices is also successful, as is reauthentication.
I DO NOT want any devices that should be doing Dot1x, to be allowed to authenticate via MAB.
The way I have achieved this is in the C3PL policy. The flow of this policy is as follows (truncated):
1. All devices are challenged for Do1x creds
2. If a device's supplicant does not respond (AGENT NOT FOUND), terminate dot1x, attempt MAB
2a. If MAB fails, restart authentication in 60 seconds
3. If a supplicant responds with credentials, but fails the ISE policy, terminate dot1x, restart authentication in 60 seconds
4. If dot1x times out on an authorized session, re-authorize the session, and apply a service template that allows only enough access for cyber to scan the device
5. If a device has authenticated with MAB, and a supplicant is sensed (AGENT FOUND), terminate MAB, authenticate using dot1x
This isn't the entire policy, but it is the relevant entries.
Scenario:
Windows is set via GPO to lock the workstation when a user removes their Smart Card. This works fine, and an authentication session will continue until it times out (1 hour), then the switch will attempt reauthentication.
When the switch sends the EAP Challenge to the endpoint, AnyConnect responds with the info that it has from the OS, which includes the machine creds, and I believe the certificate from the login session, but the Dot1x request times out. I believe (but don't know) this is because the PIN is not provided to AnyConnect by Windows when the Smart Card is not present. I do know that the Dot1x request times out.
Item number 4 in the C3PL policy was configured specifically for this scenario. I want the endpoint to be accessible for the Cyber team to be able to scan endpoints, even when users have left their machines locked for an extended period of time, and as I said above, the devices that can do Dot1x, must not be allowed to do MAB. Item number 5 was created as a safeguard to ensure this.
Problem:
This all works great with AnyConnect 4.10.08025, but that is outdated client software and we need to upgrade to Secure Client 5.1.4.
Unfortunately, what I've found testing Secure Client 5.1, is that when an authenticated user removes their Smart Card, and the session is eventually reauthenticated, the supplicant just stops responding altogether. There's no Dot1x timeout, because there's no response from the supplicant at all, and the only class-map setting that I've been able to get it to match is AGENT NOT FOUND. This causes the switch to fail over to MAB, which is what I don't want. Every permutation I've tried to identify that traffic brings me back to the same conclusion that in this state, the supplicant is not functional, and the Dot1x client is indecipherable from any MAB only device.
So the question is, in Secure Client 5 NAM, is the supplicant supposed to shut down when a Smart Card is removed, or is this a bug?
I've read through the "Cisco Secure Client (including AnyConnect) Administrator Guide, Release 5" and there is nothing about how to deal with Smart Card removal.
https://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/Cisco-Secure-Client-5/admin/guide/b-cisco-secure-client-admin-guide-5-0/configure_nam.html
I've also checked the release notes for AnyConnect 4.10, and Secure Client 5.0, and 5.1 and found no mention of this change.
There are only two things that seem to be somewhat related, though none of them answer my question:
1. In the release notes for AnyConnect 4.10.08025 there is line:
CSCur83728—When you have an EAP-FAST network and are authenticated by a certificate, choose Disconnect from Network for the Smart Card Removal Policy, so that the smartcard is removed when the network is disconnected.
What does it mean that the "smartcard is removed when the network is disconnected"? This doesn't seem relevant because we're not talking about the network being disconnected.
In the Secure Client 5 NAM Profile editor, there is a checkbox for "Smart Card Removal Policy: Disconnect from Network", but I've tried this both checked and unchecked and neither seems to make a difference.
2. I found a Cisco bug that seems to describe my issue, but the determination is the exact opposite of what seems to makes sense. The bug is CSCvo58544, and affects an earlier version of AnyConnect (v004.007(136)). The bug seems to have been closed in 2023, and it is not referenced in any release notes that I could find but the symptom is:
"
-- If NAM does not have credentials to send for certificate based authentication it should not respond to EAP Identity requests from the network device.
-- Currently NAM starts EAP authentication and does not send a response to the certificate request from the network device if no credentials are present. This causes the session on ISE to timeout, and the switch will not transition to passed or failed for the Dot1X session. As a result, the client is never able to gain any sort of connectivity using MAB authentication instead. Additionally, NAM will continue to issue EAP Start packets, which restarts the dot1x process on the switch causing a sort of "authentication loop".
-- By not sending credentials if none are present on the endpoint, this will allow MAB based network access in a situation where certificates have not yet been provisioned on an endpoint.
"
That last line doesn't seem to line up with switch config options. The supplicant does not need to shut down in order to fail over to MAB, that's what the policy on the switch is used for. By shutting the supplicant down, it removes the ability of the admin to be selective, and forces MAB.
Since I can't find documentation on this, I'm thinking it's a bug.
Please help if you have any information.
