06-04-2013 02:36 PM - edited 03-10-2019 08:30 PM
Hi folks,
Hoping some of you might be able to help out with an issue I'm seeing when using the Identity Privacy feature for PEAP-based WLAN authentication through ACS 5.4 and a Cisco WLC.
What we are seeing in the Clients section of the Monitor tab on the WLC is a number of systems showing up with a username of 'anonymous' rather than their proper AD username (see attached image).
On the client side (mostly Windows 7 laptops) in the WLAN profile, we have the "Enable Identity Privacy" option checked, and are specifiying a username of (you guessed it) 'anonymous'.
I fully understand the EAP establishment process, with the initial server certificate and TLS tunnel exchange, and it makes sense to me that once the tunnel is set up, the WLC cannot 'see' into the payload to pull the inner PEAP username out for session tagging. The only part the WLC can 'see' is the initial EAP identity access-request.
The RADIUS server can return the inner EAP username to the WLC as part of the access-accept message, and according to TAC, ACS apparently is supposed to do this without any specific configuration changes in the Authorization Profile.
The problem is that I'm seeing this 'work' intermittently; in that I am seeing some clients authenticated as 'anonymous', as if the ACS access-accept response did not actually contain the appropriate VSA.
This issue is troubling for two reasons:
1. It skews our user tracking in WCS / Prime Infrastructure
2. We either have to disable Identity Privacy on the client, or permit additional concurrent logins on a per-user basis on the WLC, neither of which I'm in favor of.
I'd be interested to know if any of you are using identity privacy with your WLAN deployments, and whether you have observe similar behaviour.
Thanks in advance for any feedback you can provide.
06-04-2013 04:39 PM
This is some new feature and we need to investigate its default behaviour.
EAP identity privacy is provided by certain EAP methods where an empty or an anonymous identity (different from the actual identity) is sent in response to the EAP identity request. PEAP method sends the identity twice during the authentication. In the 1st phase the identity is sent in plain text and this identity will be used for routing purposes and not for client authentication. The real identity is sent within a secure tunnel (established in the 1st phase) during the 2nd phase of the authentication.
http://blogs.msdn.com/b/eapteam/archive/2009/01/16/peap-identity-privacy-support-in-windows7.aspx
I'd like you to gather some information on this subject to understand the behaviour.
1.] Run following traces on the client: Start > Run and hit enter, type cmd and hit enter, then type
netsh ras set tracing * enabled
Now try to authenticate the client to record the traces. Once done authenticating, collect the traces. I guess, It generates the traces under installation drive>:\WINDOWS\tracing
Use "netsh ras set tracing * disable" to stop logging.
2.] generate the logs from ACS.
acs/admin# acs-config
Escape character is CNTL/D.
Username: acsadmin
Password: xxxxxxxx
acs/admin(config-acs)#
acs/admin(config-acs)# debug-log runtime level debug
we need to duplicate the issue with the identity privacy feature turned on.
acs/admin(config-acs)# exit
acs/admin# acs support TACBUNDLE repository MYREPOSITORY encryption-passphrase null include-debug-logs 5
Do provide me the username and time-stamp when you duplicate this issue.
My take away would be to see if ACS sent back cisco-av-pair:User-Name=
Jatin Katyal
- Do rate helpful posts -
06-05-2013 04:33 PM
Thanks Jatin, I'll work through the suggested steps tomorrow and post back with some results.
My TAC engineer also informed me that this issue is going to be addressed in a near release of WLC 8.0 code. While I'm not necessarily a fan of .0 releases, I may have to suck it up when it comes available, or potentially wait until the first point release is made available.
- Travis
06-06-2013 01:45 AM
sure, np.
Jatin Katyal
- Do rate helpful posts -
06-06-2013 09:22 AM
Good morning Jatin, I've collected the traces and ACS support bundle as requested.
Would you be able to access the support bundle if I attach it to my existing case?
The existing TAC case is 626163423.
Please let me know and I will attach the files right away.
- Travis
06-06-2013 03:06 PM
Sure...I'll download and review it tomorrow.
Sent from Cisco Technical Support Android App
06-07-2013 11:59 AM
Just a quick follow-up note, this issue has been raised in a separate TAC case. Previously, in ACS v5.3, the functionality to return the inner EAP username to the NAD in the Access-Accept was present, however this was discontinued / remove from the 5.4 code base for some reason.
The AAA BU will be discussing the issue next week, hopefully an agreement can be reached to add this funcitonality into a .4 or .5 patch release.
Jatin, thanks again for your efforts in this!
06-07-2013 01:03 PM
No worries, I will keep a close look on that issue. You never know when you need to work with some similar issue. something new
Jatin Katyal
- Do rate helpful posts -
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide