Re-triggering Computer Authentication without Restart

2017-08-30

Question

_{Wednesday, August 30, 2017 7:33 PM}

Good Afternoon,

Are there methods of re-triggering reliably computer authentication without a restart. An issue we're seeing with "PEAP-MSCHAPv2" with User or Computer authentication is for whatever reason randomly - a computer attempts computer authentication (times out during the EAP-PEAP process) - rolls over to User authentication. Restarting works most of the time to trigger the computer authentication - but there have been rare 2 or 3 situations where it takes 3 or 4 reboots for the machine to finally pass computer authentication and not timeout.

1. The behavior I used to see pre-Windows 10 where performing a "Switch User/Other User" doesn't appear to trigger computer authentication anymore.

2. I've also noticed that if an end-user is at the logon-screen - pulls up the Wi-Fi dialog, and manually selects our SSID and clicks Connect -> the computer will attempt to authenticate as the samAccountname "Domain\MachineName$" which fails. However, if the computer attempts to connect "automatically" (eventually happens if wifi is toggled a few times) -> the computer will authenticate as the servicePrincipalName "host\MachineName-FQDN" - which passes as expected.

All replies (12)

_{Friday, September 1, 2017 9:29 AM}

Hi,

The trigger of computer authentication is determined by the authentication mode.

• When select “computer authentication only”, there will be no user authentication. Thus, the computer authentication will be triggered at startup, resume from sleep or resume network connectivity.
• When select “User or computer authentication”, the computer authentication will only be triggered at start up, user log off. So if User logon, there is NO such way to do computer authentication more often, and it is by design.

So we can try this, but no guarantee : When user is logged off and disable the wireless NIC using the laptop switch and turn back on again.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Wednesday, September 6, 2017 8:48 AM}

Hi,

Was your issue resolved?

If yes, please mark the helpful reply as answer in order that other community members could find the helpful reply quickly.

If no, please reply and tell us the current situation in order to provide further help.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Tuesday, September 19, 2017 4:53 PM}

Hi Karen_Hu,

Thank your for your response. Toggling the Wi-Fi didn't seem to have the desired affect. However, it did help in a sense. This time when I manually clicked "Connect" after toggling, the laptop attempted to authenticate as samAccountName -> failed -> but then it triggered the laptop to attempt to machine authenticate every minute or so while at the login screen. So that does help in our case.

I guess my big question is if the computer is authenticating as itself when manually clicking "Connect" with the samAccountName (Domain\MachineName$)-> why it doesn't use the svcPrincipalName - (host\MachineName-FQDN)?

_{Monday, September 25, 2017 6:58 AM}

Hi GuardianDroid,

Normally svcPrincipalName should be used during authentication, SamaccountName is used for legacy purpose.

How did the you test and where did the you notice samAccountName?

For my local test, svcPrincipalName is used during authentication.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Monday, October 2, 2017 12:48 AM}

Hi Karen_Hu,

I'll put together my testing steps and reply back later. I've seen the samAcountName in the radius requests that are received by the Radius Server - as well as via packet-captures. There have also been other discussions about this type of behavior during wireless authentication at the Aruba Networks Community Forum - http://community.arubanetworks.com/t5/Security/Windows-using-domain-machinename-during-Computer-Authentication/td-p/286551

_{Thursday, October 5, 2017 8:29 AM}

Hi Guard,

Any update?

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Wednesday, October 18, 2017 5:06 PM}

Hi Karen_Hu,

Test "ssid-test"
Properties:

Security - WPA2-Enterprise with AES Encryption Type
Verify the server's identity by validating the certificate
Microsoft: Protected EAP (PEAP) - Secured Password (EAP-MSCHAP v2) - Automatically use my Windows logon name and password (and domany if any) enabled.

Advanced:

When the profile is set to "Computer authentication" - log-off the computer to the Windows Log-on screen - click the Wi-Fi Networks icon to bring up available networks -> click on "ssid-test" -> the computer authenticates as "svcPrincipalName"

When the profile is set to “User or computer authentication”- log-off the computer to the Windows Log-on screen - click the Wi-Fi Networks icon to bring up available networks -> click on "ssid-test" -> the computer attempts to authenticate as "samAccountName"

When the profile is set to "User authentication" - log-off the computer to the Windows Log-on screen - click the Wi-Fi Networks icon to bring up available networks -> click on "ssid-test" -> the computer attempts to authenticate as *"samAccountName"

*I see the authentication user names in the Access Tracker for our Radius Server (Clearpass) as well as in the Radius Request via Packet-Capture from the client. I've seen this behavior in Windows 8.1 and Windows 10 (1610, 1703, and 1709).

_{Friday, October 20, 2017 10:00 AM}

Hi,

The result of our test on lab machine is as below:

When the profile is set to "**User authentication" - **log-off the computer to the Windows Log-on screen - click the Wi-Fi Networks icon to bring up available networks -> click on "ssid-test" -> the computer attempts to authenticate as ***"samAccountName" ***Domain\UserName

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Monday, October 23, 2017 3:53 PM}

Hi Karen,

Thank you for testing that behavior.

1. Could you share the settings you used in your lab? The closets I've ever been able to get svcPrincipalName has been -> clicking on "ssid-test" -> computer attempts to authenticate as "samAccountName" -> fails -> followed by a successful connection (part of that machine authentication attempts every single minute).

2. Since samAccountName is "legacy" and you were able to replicate that as some degree - is there a way to disable that legacy setting on a client?

Thank you for your time.

_{Wednesday, October 25, 2017 7:39 AM}

Hi,

1. Could you share the settings you used in your lab?

<?xml version="1.0"?>

-<WLANProfile xmlns="http://www.microsoft.com/networking/WLAN/profile/v1">

<name>danapple</name>


-<SSIDConfig>


-<SSID>

<hex>64616E6170706C65</hex>

<name>danapple</name>

</SSID>

<nonBroadcast>false</nonBroadcast>

</SSIDConfig>

<connectionType>ESS</connectionType>

<connectionMode>auto</connectionMode>


-<MSM>


-<security>


-<authEncryption>

<authentication>WPA2</authentication>

<encryption>AES</encryption>

<useOneX>true</useOneX>

</authEncryption>


-<OneX xmlns="http://www.microsoft.com/networking/OneX/v1">


-<EAPConfig>


-<EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig">


-<EapMethod>

<Type xmlns="http://www.microsoft.com/provisioning/EapCommon">25</Type>

<VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId>

<VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType>

<AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId>

</EapMethod>


-<Config xmlns="http://www.microsoft.com/provisioning/EapHostConfig">


-<Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1">

<Type>25</Type>


-<EapType xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV1">


-<ServerValidation>

<DisableUserPromptForServerValidation>false</DisableUserPromptForServerValidation>

<ServerNames/>

</ServerValidation>

<FastReconnect>true</FastReconnect>

<InnerEapOptional>false</InnerEapOptional>


-<Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1">

<Type>26</Type>


-<EapType xmlns="http://www.microsoft.com/provisioning/MsChapV2ConnectionPropertiesV1">

<UseWinLogonCredentials>true</UseWinLogonCredentials>

</EapType>

</Eap>

<EnableQuarantineChecks>false</EnableQuarantineChecks>

<RequireCryptoBinding>false</RequireCryptoBinding>


-<PeapExtensions>

<PerformServerValidation xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV2">true</PerformServerValidation>

<AcceptServerName xmlns="http://www.microsoft.com/provisioning/MsPeapConnectionPropertiesV2">false</AcceptServerName>

</PeapExtensions>

</EapType>

</Eap>

</Config>

</EapHostConfig>

</EAPConfig>

</OneX>

</security>

</MSM>

</WLANProfile>

I attached the default setting which means “User or computer authentication” with command: netsh wlan export profile xxxx

2. Since samAccountName is "legacy" and you were able to replicate that as some degree - is there a way to disable that legacy setting on a client?

Could you let us know the content of samAccountName in your test is Domain\UserName or Domain\MachineName when the profile is set to “User or computer authentication”?

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Friday, October 27, 2017 1:06 AM}

1. Thank you Karen. I'll come that with our profile when I return to the office on Wednesday - Nov. 1

2. The conetent of samAccountName in our test is "Domain\MachineName**$**" .

_{Tuesday, February 19, 2019 4:06 PM}

Finally taking time to investigate this issue again.
I tried modifying the test-lab xml profile that Karen provided with our test ssid - but still the same behavior occurs as described below:

It's odd that some folks are able to reproduce the behavior, while others are not. I've been following in another thread concerning this same issue a couple years ago that a few others have been experiencing as well - https://community.arubanetworks.com/t5/Security/Windows-using-domain-machinename-during-Computer-Authentication/td-p/286551

Share via

Re-triggering Computer Authentication without Restart

Question

All replies (12)

Additional resources