Computer account reset, now won't authenticate wirelessly (wired OK)
Hello-
I have close to 500 wireless clients that were added to our domain prior to the default 30 day computer account password timeout being changed (now at 120). I've been getting autoenrollment, userenv, and userinit errors (can't remember event id's other than 15 on client and 5722 on DC's) since the beginning of September. Since the computer policy was applied initially and hasn't really changed there wasn't much need for concern because user policy was being updated but we've implemented a radius server so wireless policies need to be adjusted, as well as newer scripts need be run. Wired, every client I've tested applies the computer policy fine, all scripts are run and rsop gives no errors. Upon rebooting and connecting wirelessly computer policy is not applied and rsop returns core group policy error for computer config.
I have the whole domain to wait for network and all scripts be run prior to explorer being run. Every wireless client I add to the domain accepts all policy updates and runs all scripts, as did these clients initially. I've tried the steps described here: http://support.microsoft.com/kb/216393 , I've tried the network ID wizard on the client, which completes successfully but same thing happens after rebooting; can't authenticate. I am having zero issues with any other wireless clients, even those that I know haven't contacted AD in over 30 days but were added after changing that default setting.
What am I missing and is there any other info needed?
Answers
Hi,
I’ve checked the information. Based on the netlogon.log and the events, the root cause seems to be that the wireless connection was not ready when the computer started and tried to apply the policy.
Analysis:
The system CH****13560-04 started at 4:15:56 PM.
(System Event)
11/9/2009 4:15:23 PM 4 0 6006 EventLog N/A CH****13560-04 The Event log service was stopped.
11/9/2009 4:15:56 PM 4 0 6009 EventLog N/A CH****13560-04 Microsoft (R) Windows (R) 5.01. 2600 Service Pack 3 Uniprocessor Free.
11/9/2009 4:15:56 PM 4 0 6005 EventLog N/A CH****13560-04 The Event log service was started.
It tried to contact a DC and applied policies but failed.
(System Event)
11/9/2009 4:15:57 PM 1 0 5719 NETLOGON N/A CH****13560-04 No Domain Controller is available for domain ****NET due to the following: %%1311. Make sure that the computer is connected to the network and try again. If the problem persists, please contact your domain administrator.
(Application Event)
11/9/2009 4:15:57 PM 1 0 1054 Userenv NT AUTHORITY\SYSTEM CH****13560-04 The specified domain either does not exist or could not be contacted.
11/9/2009 4:15:58 PM 1 0 1000 UserInit N/A CH****13560-04 Could not execute the following script delXPSWriter.vbs. The system cannot find the file specified. .
11/9/2009 4:15:58 PM 1 0 15 AutoEnrollment N/A CH****13560-04 Automatic certificate enrollment for local system failed to contact the active directory (0x8007054b). The specified domain either does not exist or could not be contacted. Enrollment will not be performed.
The cause was that network was not ready:
(Client_Netlogon.log)
11/09 16:15:57 [SESSION] Winsock Addrs: (0) List is now empty.
11/09 16:15:57 [CRITICAL] Address list changed since last boot. (Forget DynamicSiteName.)
11/09 16:15:57 [SITE] Setting site name to '(null)'
…
11/09 16:15:57 [MISC] DsGetDcName function returns 1355: Dom:(null) Acct:(null) Flags: DS
11/09 16:15:57 [SESSION] ****NET: NlSetStatusClientSession: Set connection status to c000005e
11/09 16:15:57 [SESSION] ****NET: NlSessionSetup: Session setup Failed
The wireless connection was established at 4:16:22 PM
(System Event)
11/9/2009 4:16:22 PM 4 0 4201 Tcpip N/A CH****13560-04 \DEVICE\TCPIP_{FF3373B9-51AE-4511-966E-E87913BA14F0}
(Client_Netlogon.log)
11/09 16:16:05 [SESSION] Winsock Addrs: 10.27.17.88 (1) List used to be empty.
11/09 16:16:05 [SITE] DsrGetSiteName: Returning site name '(null)' from local cache.
After that, the secure channel was established successfully:
(Client_Netlogon.log)
…
11/09 16:16:40 [MISC] DsGetDcName function returns 0: Dom: ****net.****.net Acct:(null) Flags: DS DNS RET_DNS
…
According to the findings, the wireless connection was established successfully and the policy should be able to be applied if you run the command gpupdate after the Tcpip event 4201 appeared. The events occurred because the networking connection was not ready when the computer started up, but not because computer password expired/reset.
If there is anything unclear, please feel free to let me know.
Joson Zhou
This posting is provided "AS IS" with no warranties, and confers no rights.- Marked As Answer byJoson ZhouMSFT, ModeratorThursday, November 12, 2009 2:18 AM
- http://support.microsoft.com/kb/840669
GpNetworkStartTimeoutPolicyValue 60 did the trick.
Don't know why only this specific model was having issues but the laptops I've tested thus far seem to work.- Marked As Answer byEric Harman Tuesday, November 10, 2009 10:46 PM
All Replies
To clarify - are you having problems with a single wireless client only - and all others are working as expected? What OS are they running? What method do you use to join the domain and authenticate computer accounts (are you relying on IAS based certificate authentication - as described in http://technet.microsoft.com/en-us/library/cc776984(WS.10).aspx)?
If you are running Vista, have you considered using steps described in http://technet.microsoft.com/en-us/library/bb727033.aspx ?
hth
Marcin- No, the number is really not known. I'm estimating there's around 500 clients and they all run XP SP3 on a W2K3 domain. These were sysprepped images using WinPE and ghost so during mini-setup only thing need for me to do is rename machine. We have implemented IAS authentication but only recently. These clients haven't been authenticated since the 1st of September, exactly 30 days since they were originally joined. Only difference with how these 500 or so clients were added to the domain and how clients now are added is that I had created computer accounts first.
When I have a non-auth'd client after doing gpupdate /force while on wireless, I connect to new wireless assignment and client passes authentication and for various other policies I need to restart. Upon restarting computer policy is not applied and client reconnects to old wireless assignment. When using wired NIC, everything is OK. I don't have this problem with wireless clients added to the domain that have not had to negotiate a new computer password. These clients run all scripts, authenticate with AD and radius and get proper wireless assignment if assigned via group policy. Hi,
It sounds like a computer authentication issue. I would like to confirm what authentication method is being used. (EAP MSCHAP V2 or EAP-TLS?)
Meanwhile, please follow the steps below and check the result.
1. Connect a problematic wireless client to wired network and reboot the computer.
2. Refer to http://support.microsoft.com/kb/216393 to reset the computer account.
3. Disconnect the wired network and then reboot the computer. Does the same issue exist?When the expiration date is reached for the computer password, the Net Logon service may force the local computer credentials to expire while the computer is offline. Therefore, the computer password may not match the password on the domain. In addition, computer password could not automatically changed over wireless EAP MSCHAP V2 when the computer password expires. In this case, the computer authentication will fail. It is suggested to enable user authentication.
A computer password is not automatically changed during 802.1X authentication when you select the "Allow client to change password after it has expired" check box in Internet Authentication Service on a Microsoft Windows Server 2003-based computer
http://support.microsoft.com/?id=936626If the problem continues, please collect the following information for further troubleshooting:
Collect MPSReport on a Windows XP client:
-----------------------------------
1. Please download the Mpsrpt_network.exe package from the following website:
http://support.microsoft.com/kb/816819
2. Run the file on the computers.
3. After the tool finishes gathering the information, copy the cab file from the following folder:
C:\WINDOWS\MPSReports\DirSvc\cabEnable Logging in Windows XP client
---------------------------------
1. Run the following commands from an elevated CMD prompt. You may have to login to the computer using local administrator credentials.
netsh ras set tracing * enable
netsh wlan set tracing mode=yesEnable Logging in windows 2003 IAS server and collect logs
-------------------------------------------------------------------
1. From a command prompt in windows 2003 , type ‘netsh ras set tracing * enable’
2. Now from the windows XP computer, reproduce the issue.
3. Once the issue is reproduced, Turn off trace logging in XP using the following command in command prompt ‘netsh ras set tracing * disable’
4. Turn off Wlan tracing in XP using ‘netsh wlan set tracing mode=no’
5. Turn off tracing in Widows 2003 from a command prompt with ‘netsh ras set tracing * disable’
6. The logs are contained in the %SystemRoot%\Tracing folder
7. Please collect the log and upload to the following space:https://sftasia.one.microsoft.com/choosetransfer.aspx?key=4c856f30-6524-4bb7-9b24-670ae320e26e
Password: KLmOF-lpnkD@tAP
Joson Zhou
TechNet Subscriber Support in forum
If you have any feedback on our support, please contact tngfb@microsoft.com
This posting is provided "AS IS" with no warranties, and confers no rights.- I am using EAP MSCHAP V2.
As stated before, when I connect one of these clients with a wired connection and update group policy manually and reboot with the wired connection everything is OK. Once I reboot and use the wireless connection, whether it be a managed AP on RADIUS with IAS or the original AP not managed by IAS using WEP, the client doesn't authenticate with LDAP and AD, even after disjoining and rejoining the computer to the domain.
I've tried the tool you suggested and under the gpo log I got a 'LookupAccountSid failed with 1789 error', which prompted me to research and I found this: http://support.microsoft.com/kb/262958. Everything suggested in the document checks out for my domain controllers.
I was able to log ras via the command-line but am unable to run 'netsh wlan set tracing mode=yes' as this doesn't seem to be available under XP SP3, only Vista and Server 2008. I'm also not sure which logs you want me to upload.
I was also having an autoenrollment issue with a 2nd domain controller that I've since fixed by adding the Domain Controllers group to the CERTSVC_DCOM_ACCESS group, which also contains Domain Computers and Domain Users. Since this client I have in front of me right now seemed to be getting policy from the DC denied access I thought this might help the issue but doesn not. The errors I'm getting on this client are event id's 15, 1053, 1054.
I've been working on this since I came in this morning and I'm pretty much at a loss here. Nothing is working. Bump. Still looking for a solution...
Checked to make sure replication between DC's is happening without inconsistancies. Everything good.
dcdiag /test:dns passes on both DC's.
IAS is a non-factor I've concluded. Wireless assignments work and process all policies, successfully communicating with AD. As do all clients with credentials that never timed-out after 30 days on non-mananged and managed AP's.
As per this article: http://support.microsoft.com/Default.aspx?id=936626
"To work around this problem, enable the user authentication option in IAS. When you do this, computer authentication is unsuccessful. However, user authentication is successful. Therefore, a security channel is established, and the computer password is reset."
I cannot find any settings in IAS that explicitly says to enable user authentication. Can someone please point me to this information?
Thanks.Hi,
“Enable user authentication” is not an option in IAS. To enable user authentication, please confirm that
1. the groups that the wireless computer and the logon user are belonged to have been added in the policy condition of the Remote Access Policy.
2. Configure the client to “computer authentication with user re-authentication”.I notice that you have rejoined computers to the domain but the problem continues, please check the pwdLastSet attribute value of the computer object to verify that the password is reset properly. You can use the ldifde command to dump the information:
LDIFDE - Export / Import data from Active Directory - LDIFDE commands
http://support.microsoft.com/kb/555636In addition, please confirm whether the wireless connection can be established or not when the issue occurs.
Please also collect the following information for research:
1. Enable netlogon log on a problematic wireless client machine and both DCs:
Enabling debug logging for the Net Logon service
http://support.microsoft.com/kb/1096262. Access the original AP (not managed by IAS using WEP) to reproduce the issue.
3. After the issue occurs, Run MPSreport on the client.
4. Please upload netlogon.log, and MPSReport to the following space:
https://sftasia.one.microsoft.com/choosetransfer.aspx?key=4c856f30-6524-4bb7-9b24-670ae320e26e
Password: KLmOF-lpnkD@tAP
Thanks.
This posting is provided "AS IS" with no warranties, and confers no rights.Hi,
Please also capture the network traffic by using Netmon3.3 when you reproduce the issue:
Microsoft Network Monitor 3.3
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f
How to use Network Monitor to capture network traffic
http://support.microsoft.com/kb/812953Thanks.
This posting is provided "AS IS" with no warranties, and confers no rights.- Thanks for the info. I've completed all tasks and uploaded all files.
Hi,
“Enable user authentication” is not an option in IAS. To enable user authentication, please confirm that
1. the groups that the wireless computer and the logon user are belonged to have been added in the policy condition of the Remote Access Policy.
2. Configure the client to “computer authentication with user re-authentication”.
Just fyi, this is how I've had managed wireless access policies configured from the start.Hi,
I’ve checked the information. Based on the netlogon.log and the events, the root cause seems to be that the wireless connection was not ready when the computer started and tried to apply the policy.
Analysis:
The system CH****13560-04 started at 4:15:56 PM.
(System Event)
11/9/2009 4:15:23 PM 4 0 6006 EventLog N/A CH****13560-04 The Event log service was stopped.
11/9/2009 4:15:56 PM 4 0 6009 EventLog N/A CH****13560-04 Microsoft (R) Windows (R) 5.01. 2600 Service Pack 3 Uniprocessor Free.
11/9/2009 4:15:56 PM 4 0 6005 EventLog N/A CH****13560-04 The Event log service was started.
It tried to contact a DC and applied policies but failed.
(System Event)
11/9/2009 4:15:57 PM 1 0 5719 NETLOGON N/A CH****13560-04 No Domain Controller is available for domain ****NET due to the following: %%1311. Make sure that the computer is connected to the network and try again. If the problem persists, please contact your domain administrator.
(Application Event)
11/9/2009 4:15:57 PM 1 0 1054 Userenv NT AUTHORITY\SYSTEM CH****13560-04 The specified domain either does not exist or could not be contacted.
11/9/2009 4:15:58 PM 1 0 1000 UserInit N/A CH****13560-04 Could not execute the following script delXPSWriter.vbs. The system cannot find the file specified. .
11/9/2009 4:15:58 PM 1 0 15 AutoEnrollment N/A CH****13560-04 Automatic certificate enrollment for local system failed to contact the active directory (0x8007054b). The specified domain either does not exist or could not be contacted. Enrollment will not be performed.
The cause was that network was not ready:
(Client_Netlogon.log)
11/09 16:15:57 [SESSION] Winsock Addrs: (0) List is now empty.
11/09 16:15:57 [CRITICAL] Address list changed since last boot. (Forget DynamicSiteName.)
11/09 16:15:57 [SITE] Setting site name to '(null)'
…
11/09 16:15:57 [MISC] DsGetDcName function returns 1355: Dom:(null) Acct:(null) Flags: DS
11/09 16:15:57 [SESSION] ****NET: NlSetStatusClientSession: Set connection status to c000005e
11/09 16:15:57 [SESSION] ****NET: NlSessionSetup: Session setup Failed
The wireless connection was established at 4:16:22 PM
(System Event)
11/9/2009 4:16:22 PM 4 0 4201 Tcpip N/A CH****13560-04 \DEVICE\TCPIP_{FF3373B9-51AE-4511-966E-E87913BA14F0}
(Client_Netlogon.log)
11/09 16:16:05 [SESSION] Winsock Addrs: 10.27.17.88 (1) List used to be empty.
11/09 16:16:05 [SITE] DsrGetSiteName: Returning site name '(null)' from local cache.
After that, the secure channel was established successfully:
(Client_Netlogon.log)
…
11/09 16:16:40 [MISC] DsGetDcName function returns 0: Dom: ****net.****.net Acct:(null) Flags: DS DNS RET_DNS
…
According to the findings, the wireless connection was established successfully and the policy should be able to be applied if you run the command gpupdate after the Tcpip event 4201 appeared. The events occurred because the networking connection was not ready when the computer started up, but not because computer password expired/reset.
If there is anything unclear, please feel free to let me know.
Joson Zhou
This posting is provided "AS IS" with no warranties, and confers no rights.- Marked As Answer byJoson ZhouMSFT, ModeratorThursday, November 12, 2009 2:18 AM
- Hmm, weird. I have an all encompassing policy for every laptop in different buildings with 'Always wait for the network at computer startup and logon' enabled and scripts set to run synchronously and some wireless clients actually do wait for the network and some do not. The only other thing I can think of is the clients that work are either Dell D520's or HP 6510/6530/610 and those that do not are Lenovo R61/R500's.
What would you suggest? - Some more info...
The only laptops that seem to be affected are the Lenovo R61's. I dug up an R500 A17 and a Dell D520 that had not been logged into since early September. Of course, domain was unavailable for both as neither were connected wirelessly or wired. Logged into local admin, connected to wireless and rebooted. The login prompt came up almost immediately and I was able to login, at which time the machines recieved all policy like initial system startup including all scripts. RSoP returns success for all GPO's.
I need to test more R500's to confirm but this does not bode well for us as the R61 is the bulk of our mobile stock. - http://support.microsoft.com/kb/840669
GpNetworkStartTimeoutPolicyValue 60 did the trick.
Don't know why only this specific model was having issues but the laptops I've tested thus far seem to work.- Marked As Answer byEric Harman Tuesday, November 10, 2009 10:46 PM
