ISE 3.0 and WIFI integration (Authenticating network)

[JonathanAlmassi32499]

Hello all,

We're working on a deployment of ISE and will be using the NAM module for WIFI and wired connections. We're also pushing out a new WIFI network which will use machine (certificate) and user auth (AD creds). The NAM profile is currently set up with before logon and auths with the machine cert (the goal is for machines to still receive updates/gpos etc) and then user auth so we can see which user is using the machine.

The issue we're having is some client-side devices are not able to connect and some are. Unfortunately, this seems like it's more client-side, but hopefully, I can get some feedback.

The scenario/expectation is:

1. Laptop is docked with a Dell USB-C docking station.

2. User logs onto the machine and authenticates fine on wired.

3. When undocking, WIFI takes over.

In some cases, on older laptops, the laptop has no issue and connects without any issues. On newer laptops (one Windows 11), instead of connecting, we're getting a prompt for username and password, and even if credentials are correct, the NAM indicates that the auth failed. When looking at the logs, it shows that ISE is using the user auth policy. It's passing as anonymous in the authentication details (denying access), but shows the username in Other Attributes.

Has anyone run into this and found a fix or can provide feedback?

[Mike.Cifelli]

In relation to Windows 11 I cant say that I have had a similar experience.  However, with earlier versions of Windows clients I have seen issues with NAM where moving from wired to wireless and vice versa can present issue at times (usually a reboot helps).  What version of AC are you running? Have you attempted to run a DART bundle and check logs?

[JonathanAlmassi32499]

Hi Mike,

Thanks for responding.

I have looked at both the ISE live logs and the DART bundle that was created. I've attached the live logs here.

I'm a novice at this, but according to the ISE logs, I see the anonymous username in the authentication details and the AD username in Other Attributes. It's denying access because it appears to be unable to authentication the anonymous username against AD.

Looking at the DART bundle, it appears that the anonymous username is being sent as user auth and it's not passing my AD credentials, even from the password prompt. I've attached a snippet of the DART logs from NAM below. These messages are repeated multiple times.

60410: <machine name>: Nov 30 2021 16:21:47.982 -0700: %NAM-7-DEBUG_MSG: %[tid=17744]: Connection 03207910, incoming datagram: <SOAP-ENV:Body> <ssc:getUsernameAndPasswordResponse> <ssc:sequenceNumber>2817</ssc:sequenceNumber> <ssc:groupName>Local networks</ssc:groupName> <ssc:networkName><SSID></ssc:networkName> <ssc:passwordType>usernameAndPassword</ssc:passwordType> <ssc:username>AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAaG37XKbtpEWC01S4Fgko3AQAAAACAAAAAAADZgAAwAAA ABAAAACGT95MAwAHNZf4UUN7eFVtAAAAAASAAACgAAAAEAAAAHrODmYyayfeb+bz/D/dO4UQAAAA NhamKY1UBjViPxIsvdm4BRQAAABK8xN39wfvWqKV9CjoiHHwZ/mSfw==</ssc:username> <ssc:password>AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAaG37XKbtpEWC01S4Fgko3AQAAAACAAAAAAADZgAAwAAA ABAAAAAh6quPcLSk55vch6s24d7NAAAAAASAAACgAAAAEAAAAGmapYLzGhVZNMvjRJ72Jv0YAAAA I1s7g6VXMgsKdMwXLgxlPrxYMa6Qm9XVFAAAABPFnQ7r0cVtkFQ6nOecLX4Kn7rE</ssc:password> ...
60411: <machine name>: Nov 30 2021 16:21:47.982 -0700: %NAM-6-INFO_MSG: %[tid=4836]: User name and password received from user.
60412: <machine name>: Nov 30 2021 16:21:47.983 -0700: %NAM-7-DEBUG_MSG: %[tid=4836]: Auth[<SSID>:user-auth]: Received username/password response
60413: <machine name>: Nov 30 2021 16:21:47.984 -0700: %NAM-7-DEBUG_MSG: %[tid=4836]: Auth[<SSID>:user-auth]: ...resumed
60414: <machine name>: Nov 30 2021 16:21:47.984 -0700: %NAM-7-DEBUG_MSG: %[tid=4836]: Auth[<SSID>:user-auth]: Sending NOTIFICATION__RESUMED to subscribers
60415: <machine name>: Nov 30 2021 16:21:47.986 -0700: %NAM-7-DEBUG_MSG: %[tid=4836]: Auth[<SSID>:user-auth]: resuming credential request CRED_REQ_IDENTITY
60416: <machine name>: Nov 30 2021 16:21:47.986 -0700: %NAM-6-INFO_MSG: %[tid=4836]: EAP: Identity requested
60417: <machine name>: Nov 30 2021 16:21:47.986 -0700: %NAM-7-DEBUG_MSG: %[tid=4836]: Auth[<SSID>:user-auth]: Performing full authentication
60418: <machine name>: Nov 30 2021 16:21:47.987 -0700: %NAM-7-DEBUG_MSG: %[tid=4836]: Auth[<SSID>:user-auth]: Disabling fast reauthentication
60419: <machine name>: Nov 30 2021 16:21:47.987 -0700: %NAM-6-INFO_MSG: %[tid=4836]: Getting credentials from user.
60420: <machine name>: Nov 30 2021 16:21:47.989 -0700: %NAM-6-INFO_MSG: %[tid=4836]: Sending unprotected identity = anonymous.
60421: <machine name>: Nov 30 2021 16:21:47.989 -0700: %NAM-6-INFO_MSG: %[tid=4836]: EAP: Identity sent
60422: <machine name>: Nov 30 2021 16:21:47.991 -0700: %NAM-7-DEBUG_MSG: %[tid=4836]: EAP: identity sent: sync=82
60423: <machine name>: Nov 30 2021 16:21:47.991 -0700: %NAM-7-DEBUG_MSG: %[tid=4836]: EAP: credential request 82: state transition: PENDING -> RESPONDED
60419: : Nov 30 2021 16:21:47.987 -0700: %NAM-6-INFO_MSG: %[tid=4836]: Getting credentials from user.
60420: : Nov 30 2021 16:21:47.989 -0700: %NAM-6-INFO_MSG: %[tid=4836]: Sending unprotected identity = anonymous.
60421: : Nov 30 2021 16:21:47.989 -0700: %NAM-6-INFO_MSG: %[tid=4836]: EAP: Identity sent
60422: : Nov 30 2021 16:21:47.991 -0700: %NAM-7-DEBUG_MSG: %[tid=4836]: EAP: identity sent: sync=82
60423: : Nov 30 2021 16:21:47.991 -0700: %NAM-7-DEBUG_MSG: %[tid=4836]: EAP: credential request 82: state transition: PENDING -> RESPONDED

I have a single use case where I edited the NAM profile to pass the [username] in the unprotected identity pattern which worked. I was able to dock and undock and windows was able to switch over without issue. My concern is, I'm not sure if the password is also passed

[Mike.Cifelli · Accepted solution]

EAP-FAST uses anonymous as the outer identity by default.  You can reconfigure this in the NAM profile via the NAM profile editor.  AnyConnect is sending the anonymous username as the unprotected identity (outer).  Your real user identity is provided in the inner method, which is the protected identity.  I would suggest taking a peek at the following: https://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/99791-eapfast-wlc-rad-config.html

HTH!

[JonathanAlmassi32499]

Hi Mike,

I've reviewed the article and we're doing some of what is mentioned. We're hesitant about making some of the changes to the NAM profile, and we're also doing machine and user auth. I've opened a TAC case on this and will share a response if a fix is provided. We're also thinking of foregoing the NAM and using TEAP.

Edit 12/10/2021:

This is a bit of an oddity, but I tested a different scenario.

1. Shut down the laptop while docked.

2. I undocked the laptop after a shutdown, then I connected an ethernet cable directly to the laptop's ethernet port.

3. I turned on my laptop and waited till I saw it connected to ethernet (it went from the globe to the ethernet icon).

4. I signed into the machine and waited a few minutes.

5. After a few minutes, I disconnected the ethernet cord, and a few seconds it successfully connected to our 802.1x WIFI.

When I looked at the logs, I noticed machine auth occurred about few minutes before user auth occurred. I'm curious because it's sending machine auth via WIFI, even though it's wired through its ethernet port. Any Windows gurus know how to get the WIFI card to attempt to connect even while docked? I've searched through the dock's realtek adapter settings and WIFI adapter settings but I'm not finding anything that stands out.

Thank you,

Jonathan

[thomas]

TEAP is a cleaner option for chaining user + machine in a single auth.

[JonathanAlmassi32499 · Accepted solution]

Hello all,

Cisco TAC found the issue and it was due to a misconfiguration in our ISE environment. A bit embarrassed I missed this as well.

Because we're doing user and machine auth, we're suppose to be doing EAP-Fast and chaining. The logs indicate that neither user nor machine were chaining under EAP-ChainingResult. Reviewing our settings under Policy -> Policy Elements -> Results, on the allowed protocols under EAP-Fast we didn't have Enable EAP-Chaining ticked. We've enabled the setting and docking/undocking has been resolved.

File this is the SMH category.