Machine account password procedure

Background: I am trying to diagnose a problem with laptops which are
connecting wirelessly via a PEAP setup and authenticating against IAS. This
uses the computer's account in AD to authenticate the PC. For the most part,
this works very well, but occasionally some laptops refuse to connect
wirelessly and need to be plugged in on the wire (only once) and they will
then work again. There is no security set up on the wired connection. This
seems to happen if the laptop hasn't been used in a while (weeks).

Clients (laptops) are XP Pro SP2; Servers are WS2003 SP2; Domain is at
WS2003 functional level

Hypothesis: I suspect this problem may be due to the computer account
expiring (currently it's at the default 30 days) and the computer refusing to
use the current password to authenticate to our RADIUS (IAS) server, but
being unable to change it without a working network connection. From what
I've read, the computer is in charge of determining when that 30 days is up
rather than the DC. My question is: does the computer wait until after the 30
days are up and then change its password, or does it change it at some point
before the 30 days are up (a la DHCP leases)?

If it only changes the password *after* the 30 days are up, then the cause
of the problem probably lies elsewhere. Unfortunately I can't find any
documentation which goes into sufficient detail to help me.

Hi
Last time I check, the computers request the password change and not the
DCs, even if they're disconnected for long periods of time, and rhey
shouldn't be bloqued for that.

Have the same problem with laptops running Windows XP SP3 and have done some investigation.
Downloaded and installed onto a healthy laptop the Windows XP Support Tools that contains nltest.exe (used to test the Netlogon service) from:

http://www.microsoft.com/downloads/d...displaylang=en

Ran "nltest /cdigest:MESSAGETOHASH /domain:domainname"
Results as follows:
Account RID: 0x71c7
New digest: 77c45d22d173...
Old digest: b504da907798...

The two digests are the machine account passwords that the laptop knows them to be. The Old digest is the previous password and is there encase the domain controllers are slow to replicate the new password between them. (If a domain controller has the old password for the computer account, the laptop can still authenticate with that domain controller using the previous password).

(I believe this to be the process:
1. Laptop authenticates and creates secure channel
2. Laptop initiates change of password
3. Laptop generates new password, old password stored and relegated to 'Old digest'
4. Laptop informs nearest Domain Controller, password changed on Computer Account in Active Directories
5. Domain Controllers replicate change)

On a Domain Controller, Ran:
"nltest /sdigest:MESSAGETOHASH /RID:0x71c7"

(The RID is the Computer Account ID and can be found by opening Active Directory Users and Computers, Properties of the Computer Account, Attributes Tab, objectSID. A number that looks like this:
S-1-5-21-270530305-1720780853-1746953603-29138
The RID is the last 5 numbers, 29138. Convert this decimal number into a hex number using calc.exe (29138=71c7) for use with nltest.)

Results as follows:

Account RID: 0x71c7
New digest: 77c45d22d173...
Old Digest: 77c45d22d173...

The digest is the machine account password the domain controller has for that particular laptop.

For a 'Broken' laptop (one that fails to connect through the wireless network and has yet to be plugged into the wired network)

First on the Domain Controllers, ran nltest /sdigest, using the correct RID for the 'broken' laptop. This revealed the password known by the Domain Controllers, as Follows:

Account RID: 0x71d3
New digest: 5a145e36d177...
Old Digest: 5a145e36d177...

On a 'broken' laptop ran "nltest /cdigest:MESSAGETOHASH /domain:domainname"
Fails because there is no connection to any domain controllers, however, connected the laptop to the wired network and ran the command again as soon as a connection was complete. Result as Follows:

Account RID: 0x71d3
New digest: e2146da6d7b5...
Old Digest: 5a145e36d177...

The Passwords between the Laptop and Domain Controller were found to be out of synch.

When the wireless tries to authenticate it only uses the New password and ignores the Old password, hence, authentication fails. When the laptop is connected to the wired network, the Old password is passed to the domain controllers and the laptop authenticates successfully, synching the passwords shortly afterwards.

On a Working Laptop ran the command:
nltest /sc_change_pwd:Domainname
Password changed successfully.

Ran nltest /cdigest to view passwords

Disabled All Network Connections, ran nltest /sc_change_pwd
Fails saying that no domain controllers could be found.

Ran nltest /cdigest to view passwords
Password has been changed!

Attempted to Enabled Wireless fails.

Ran nltest /sdigest on Domain Controllers shows passwords out of synch.

'Fixed' laptop, laptop working on wireless properly.
Disabled All Network connections.
Restarted Laptop
Logged in locally.
Ran nltest /cdigest to view passwords

Ran nltest /sc_change_pwd
Fails saying that no domain controllers could be found.

Ran nltest /cdigest to view passwords
No change to Passwords!

Conclusion
On Windows XP the computer accounts password on a laptop can be changed if a connection has first been made to a domain and yet the network connection lost. The password cannot be changed if no connection has been made to a domain. This appears to be a bug in Windows XP.
In Windows 7 it is not possible to change the password on the laptop if no domain controllers can be found.

Hopes this helps someone else.

Thank you for posting this procedure. I hope it helps others out there.

Please do keep in mind, you are responding to an expired post.

One thing if I may suggest in the future when posting such as great
procedure using Techarena, to quote the original post you are responding to.
Techarena's threads and posts are all based on the MIcrosoft Public
Newsgroups. Techarena pushes/pulls ALL of their posts from the free
Microsoft Public Technical Newsgroups. The newsgroups expire all posts in 90
days. Unfortunately without quoting the original issue when replying to an
expired post, all we see in the originating newsgroup is a reply ("Re:
<original subject>) and not the original post, so many using the newsgroups,
sometimes do not understand what you're replying to.

To see what I mean, setup a newsreader (like the free one in Windows), set
the news server to news.microsoft.com, and select any one of the over 2000
newsgroups that exist. This newsgroup you responded to is
"microsoft.public.windows.server.active_directory." No need to create a
profile or logon. Anonymous is allowed.

I hope that makes sense.

And once again, excellent procedure. :-)