I'm in a situation I've not seen before, but I'm sure someone else has so I'm hoping for some insight from the crowd here.
Working on a standard 802.1x setup using Clearpass with Windows 10 computers, and I setup the clients with Authentication mode: "User or computer authentication".
So normally I see host/fqdn when Windows Computers do their Computer Authentication, but in this case it's sending domain\machinename$. This results in a Reject from AD and a failed [Machine Authentication].
If I set the auth mode to only "Computer authentication" it always sends host/fqdn and all is well.
Customer says that in the previous 802.1x they tried several years ago, they had the same problem. That was with the same AD/GPO's etc, but Win 7 clients.
So - anyone else had this problem and found a way to fix this?
Hi John,I've seen this before when using EAP-TLS for authentication. What are you using?
EDIT: Ahhh nevermind, probably EAP-PEAP as you're doing user and computer.
So is it my topic headline that is not catchy enough, or has none of all the thousands here seen anything other than host/computer.fqdn during "computer authentication"?
That said - I've read a ton of papers and documentation and I'm unable to reproduce the issue in my lab.
domain\machinname$ is only used when the computer is setup with EAP-PEAP and authentication method = "user or computer authentication". In "Computer authentication" auth mode the correct host/machinname.fqdn is used and authentication works correctly.
@jsolb wrote:*bump* So is it my topic headline that is not catchy enough, or has none of all the thousands here seen anything other than host/computer.fqdn during "computer authentication"? That said - I've read a ton of papers and documentation and I'm unable to reproduce the issue in my lab. domain\machinname$ is only used when the computer is setup with EAP-PEAP and authentication method = "user or computer authentication". In "Computer authentication" auth mode the correct host/machinname.fqdn is used and authentication works correctly.
Hi John,Not sure if you're still chasing this problem. We just started doing machine authentication for a small building and are running into this problem now today for some individuals. Something that stuck in my mind shortly towards end of my shift - what build number of Windows 10 were you running into - and did it differ from you lab setup - I saw this on Version 1607 [Build 14393] (My recently updated work and test laptop) and Version 1703 [Build 15063] (affected population version ran in to) - and I hope to have the original version I tested this again shortly Version 1511 [Build 10586] - where I didn't have this problem - Enterprise Version Info - https://technet.microsoft.com/en-us/windows/release-info.aspx
Are you using PEAPv0/EAP-MSCHAPv2 or EAP-TLS?
Is the device configured for user, computer or computer + user?
Are you using the native Windows supplicant?
Hi Tim,Are you using PEAPv0/EAP-MSCHAPv2 or EAP-TLS? PEAPv0/EAP-MSCHAPv2
Is the device configured for user, computer or computer + user? computer + user
Are you using the native Windows supplicant? Yes
@cbjohns wrote:Hi Tim,Are you using PEAPv0/EAP-MSCHAPv2 or EAP-TLS? PEAPv0/EAP-MSCHAPv2Is the device configured for user, computer or computer + user? computer + userAre you using the native Windows supplicant? Yes
Almost forgot one more important detail. The machine passes authentication with "host/FQDN" - and then almost immediately fails with "domain\machinename$" - so this could be a separate issue from OPs.
Made some progress (ruled out Windows 10 versions) and happened to find a recent Aruba KB about this behavior - https://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Machine-authentication-fails-when-ssid-profile-pushed-via-GPO/ta-p/290978 - not sure what causes it though and why for some clients. Still trying to do more analysis.
Made some further progress. I was wondering if anyone could try replicating the issue I experienced in Windows 10 Version 1703 with an SSID (802.1x - PEAP-MSCHAPv2) deployed via GPO. In previous versions of Windows 10 - the OS will NOT and SHOULD not allow the creation of duplicate SSID Profiles. Feel free to PM if willing to test - I almost disregarded one person as not having the issue - till I realized a sneaky behavior that masked the issue.
In Version 1703 - the OS is allowing two profiles of the same name to be configured (The Original GPO "Added by Company Policy") and then a user-defined one (either through "Add a new network" - or possibly a by-product of an in-place upgrade) - testing this tomorrow. I suspect if one GPO is (User or Computer Authentication) and the other is (Computer Authentication Only or vice-versa) it's causing the client to machine authenticate as "host/FQDN" followed by immediate failure attempt of "Domain\MachineName$" - based on the various authentication methods if I'm been testing.
In case anyone else is still following this topic - additional behavior I've noticed with Windows 8.1/10 and the format of the computer authentication.
This is specific to profile set as "User or computer authentication" with native Windows Supplicant on a 802.1x WPA2Enterprise - PEAP-MSCHAPv2 SSID. If a user interactively brings up the Wi-Fi taskbar on the logon screen, selects the corporate ssid, and clicks "Connect" manually - then the laptop will attempt to authentcate as "Domain\MachineName$". If the Wi-Fi is "toggled" or it attempts to automatically connect (connect automatically setting) without user-interaction of the "Connect" button - the laptop will attempt to authenticate as "host\FQDN-MachineName".
I am having the same problem. Did you ever find a solution?
@brettmwill wrote:I am having the same problem. Did you ever find a solution?
If referring to me. I unfortunately was not able to find the solution. I've been meaning to finally sit down and open a ticket with Microsoft concerning this behavior. I had a lengthy discussion on the TechNet forums whom agreed the "samAccountName" is only for legacy purposes. They informed me last year that in their test lab they couldn't reproduce the specific behavior I was reproducing. I'm hoping to get some time once our third engineer returns and open a ticket with Microsoft -> which bore fruit last time concerning the "Duplicate Profile" issue I discovered last year.
We're facing the same problem.
We're using Windows 10 versions 1709 and 1803. I configured the wireless network profile manually, so no GPOs were involved.
We use EAP-TTLS with EAP-MsChapV2 and windows logon credentials.
The reason we use EAP-TTLS is because we need to use a specific realm in the outer identity and this can't be configured in EAP-PEAP.
The settings we used are as follows:
In the Security tab:
WPA2-Enterprise, AES, Microsoft: EAP-TTLS, tagged remember my credentials
tagged enable identity privacy: firstname.lastname@example.org, connect to these servers: radius.domain.tld, tagged only the correct CA, untagged don't prompt user, Eap method for authentication: EAP-MSCHAP v2.
EAP MSCHAPv2 properties:
tagged automatically use my windows logon name
Advanced Security settings:
tagged specify authentication mode: User or computer authentication, untagged delete credentials, tagged enable single sign on, selected after user logon, maximum delay: 10 seconds, tagged allow dialogs, tagged this network uses separate vlans
We reproduced the problem as follows:
- turn on the computer and it will succesfully authenticate as host/computer.fqdn
- log on as user and domain\user will succesfully authenticate
- disconnect the wireless network and log out from the computer
- at the logon screen connect to the wireless network again.
- It will now unsuccesfully try to authenticate as domain\computername$.
We haven't found a solution as of yet, but are keen to find one.
All you need to do to recreate the problem is go to the log on screen.
If the windows 10 client automatically connects it will use host/machine.fqdn.
If you connect the client manually it will use domain\machinename$ .
We deployed both wired and wireless profiles via GPO, with the same settings. Wired always uses host/fqdn, manual wireless connection at the logon screen always fails because of netbiosname\hostname$ fails to authenticate. Exactly as described above.
All computers are Windows 10 up to date.
Anybody had luck with Microsoft support tickets? As pushing the registry value of the servicePrincipalName (as described in here) via GPO s quite challenging.
Taking another crack at this again at TechNet finally. I'm curious what the difference is between their lab environment, the original posters, and everyone elses is. Since TechNet and OP couldn't reproduce this problem in their environment, but several other folks are.
Has anyone found a solution to this yet? Currently running into the same situation in my environment. Been searching the web trying to solve it myself before having to call support...
I haven't found a solution yet. I also found out that "Wired AutoConfig" 802.1x authentication reacts in the same way, so it's not only the wireless stack that suffers from this issue.
Microsoft Support confirmed what they saw in the netsh tracing of the samAccountName - and inquired about the "registry modification" that was referenced - although I changed it - reverted back (waiting to hear back from them now). In the meantime, looking back over everything with fresh set of eyes of my authentication failures. In regards to EAP-PEAP-MSCHAPv2 - What does it mean in ClearPass when the challenge computation doesn't have a "username referenced" (is clearpass generating a challenge incorrectly or an error with how client supplied the user-name in the tunnel?) - even though a user was located? Note - a domain was referenced correctly.
Never solved, but not actually a problem.
It happens only when you manually connect to network at the login screen. However, if single-sing on is enabled before user login, with "User or computer authentication", computer authentication is porcessed successfully immediately when the user attempts logging in.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.