Running 802.1x on our wired network to authenticate domain computers and domain users to the network. This runs fine in most cases, but some users are reporting issues where Windows will accept the login, but 802.1x (the network login part of the login process) fails with invalid credentials.
If they cancel the network login prompt, authentication will eventually succeed in the background, I don't quite understand how and why.
The following is an excerpt from the debug logging:
2020-02-24 07:36:41,641 DEBUG [com.enterasys.tesNb.server.aaaapi.NacAAARequest] (EacAAARequestHandler (Client: 127.0.0.1:42185):) Not allowing username to be a MAC because the Calling-Station-Id: "A1-B1-C1-D1-E1-F1" does not match the username: "user.name@domain.com"
2020-02-24 07:36:41,642 DEBUG [com.enterasys.tesNb.server.aaaapi.NacAAAServerRequestProcessor] (EacAAARequestHandler (Client: 127.0.0.1:42185):) ESDMAC:9D-53-E1 processRequest NacAAARequest [isFallthroughOnAuthFail=false, prevAAARuleIndex=0, fromInnerTunnel=true, lastResponseCode=255, lastProxyAction=0, proxiedToIp=null, attributes=Client Request RADIUS Attrs:
Service-Type=2
Module-Failure-Message=mschap: Program returned code (1) and output 'The attempted logon is invalid. This is either due to a bad username or authentication information. (0xc000006d)'
Module-Failure-Message=mschap: External script says: The attempted logon is invalid. This is either due to a bad username or authentication information. (0xc000006d)
Module-Failure-Message=mschap: MS-CHAP2-Response is incorrect
There might be an issue with the way we mix UPN and sAMAccountName for authentication. Our LDAP configuration is set to use ‘sAMAccountName’ for ‘User Search Attribute’.
Users in our domain login using a mix of these. As NAC strips the domain this isn't really a problem (and Windows never cares anyway), but the actual problem might be not in all cases the UPN matches the sAMAccountName, for example:
DOMAIN\Usr1
User.One@Domain.com
The obvious solution is to change every useraccount to use a uniform login, but that's simply not an option right now. I do agree this should be a goal though.
Can anyone explain how this works? In the logfile above you can see credentials are denied for a login with their UPN, but eventually the user is authenticated in NAC with their sAMAccountName. Their UPN and sAMAccountName in this case do not match.
