Using Microsoft PEAP 802.1x client on Windows XP SP2, if we enable machine authentication against a Windows Domain, the machine authentication is successful and the machine gets access to the network. However, when user logon occurs to the domain, contrary to the flow given in ACS and Windows documentation, no user authentication takes place.
We need to differentiate user access based on their identities. We need machine authentication only to allow users access to the domain controller and also GP implementation.
Any idea why user does not get prompted when they logon. 802.1x is configured in users profile and I have tried with both integrated and non-integrated with Domain logon (i.e. "use my windows logon name and password and domain (if any) option"
There is no record of any identity request/response in ACS after the initial machine authentication (which appears in successful authentication log)
We are using MS-CHAPv2.
The issue has been resolved by making a few registry entries for AuthMode and SupplicantMode (courtesy a few posts on the Internet).
This issue was first discovered in initial release of XP and is supposed to have been resolved in XP SP1 but I am using XP SP2 and I found these above entries to be missing in the registry and had to manually add them. Will probably need to configure a GPO to add them to all domain computers.
How can we ensure that windows XP always asks users for 802.1x credentials. Currently XP is using cache credentials for successful logons unless the network cable is removed, the NIC is disabled and enabled, or the machine is restarted. Simple logoff of user and logon with another user still does not prevent using of cached credentials.
Fast Reconnect option is disabled in both the XP and Cisco ACS. Also, "enable windows username and password (and domain if any)" is also unchecked.
XP does not prompt user. Any idea how we can force it to ask for user credentials each time....?
You cannot do this with the MSFT supplicant. Remember though, roaming on an 802.1x/EAP WLAN without this would be very difficult.
Forgot to metion. Machine-auth would help here, and can help address the logout scenario. When a logout happens, a machine-auth on behalf of the machien happens. This way, a new user could be validated against AD in addition to 1X.
We are using Machine authentication against AD to allow users to logon to the domain and also apply group policies prior to user logon.
Terminal Services are a problem on client devices. For troubleshooting purposes, support needs to remotely logon to client machines, however, when support person logon, predictably user authentication takes place and session is broken. Any fix to that? Would NAP help to resolve this?
Update...The problem of cached credentials in MS PEAP does not occur if "enable logon using Windows username and password (and domain if any) is checked. Using this option, MS PEAP always uses logged on users most current credentials.
However, using this option sends the username as "DOMAIN\USERNAME". Since we are using ACS internal database for user authentication (even though the ACS and Windows passwords are same - using an identity management system) ACS does not recognize the user.
I have tried proxy distribution with prefix stripping but it does not seem to work when it is pointing to the same ACS server on which proxy distribution is configured and which receives the request.
Any idea how the domain\ can be ignored by ACS?
I'm not sure how the issue of cahced credentials does not occur with that option. Also, is this the MSFT supplicant? There's no such option in it that reads like this.
If you're using the CiscoSecure local db, there's also no way to strip the domain name. It's not using AD, so it doesn't know that's a domain-name, or can't pre-suppose is it either. You could consider modifying you're user account in the Cisco-Secure db accordingly.
Hope this helps,
i'm going to enable 802.1x authen with ACS for remote domain user vlan and remote guest vlan. all ACS servers are in the main campus, many remote branches across the WAN connections. Guest id is on ACS local DB. Each branch has an AD server which is in the same domain as the main campus AD.
here is my question:
if i lost WAN connectivity between ACS in the main campus to the remote office network, will the domain user and guests still be able to access their local network?
If ACS is deployed centrally on the main campus, then for all authentication requests generated during lost connectivity will fail and users will not be able to gain access to the network.
Cisco has addressed this in its 12.2(25)SEE version of IOS for Catalyst switches but so far I have myself yet to make it work.
In case of integrated logon, the username and password is that of the current logged on user whereas in case of "prompt for username password" if user x has logged on to windows desktop but used user y's credentials for logon to the network, user y's credentials are cached in user x's desktop profile and each time user x logs on to the desktop, user y's ACS credentials are used to log on to the network.
We did modify our accounts in ACS to cater for this as there did not seem to be any other way to do it with MSFT supplicant and ACS. (although i did see "domain stripping" option in 12.2(25) catalyst IOS and it seem to take care of that...but that will not work with wireless APs.
Hi, is there any update to this case?
I am facing the exact situation "Using Microsoft PEAP 802.1x client on Windows XP SP2, if we enable machine authentication against a Windows Domain, the machine authentication is successful and the machine gets access to the network. However, when user logon occurs to the domain, contrary to the flow given in ACS and Windows documentation, no user authentication takes place. "
Even worse, if the user credential is cached, the deny dial-in of user in Windows AD and MAR aging time do not work.
I have to uncheck "Connect automatically when this network is in range" to make the MAR works more like expected.
I am using ACS 4.2, WLC 5.0 and Vista.
It is ok now. I think the problem occured when I was connected to a LAN and I used terminal services to test the WLAN at the same time.