Machine Account Password Process
Published Apr 04 2019 01:52 PM 156K Views
Microsoft

First published on TechNet on Feb 13, 2009


Hi, this is Manish Singh from the Directory Services team and I am going to talk about the machine account password process. Ever wondered what goes on with your machine account in Active Directory? Here is a brief set of question and answers to clear things up.

Question: How often does the machine password account change in AD (is it different for various Windows operating systems)?

Answer: The machine account password change is initiated by the computer every 30 days by default. Since Windows 2000, all versions of Windows have the same value. This behavior can be modified to a custom value using the following group policy setting in Active Directory.

Domain member: Maximum machine account password age

 

You can configure this security setting by opening the appropriate policy and
expanding the console tree as such:

Computer\Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Question: If a workstation does not change its password, will it not be allowed to log onto the network?

Answer: Machine account passwords as such do not expire in Active Directory. They are exempted from the domain's password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.

So if a computer is turned off for three months nothing expires. When the computer starts up, it will notice that its password is older than 30 days and will initiate action to change it. The Netlogon service on the client computer is responsible for doing this. This is only applicable if the machine is turned off for such a long time.

If the machine was down for a long time, that scavenger thread will not run and the password will not get out of sync in the local store and Active Directory.

If the machine was unable to communicate with a domain controller, the client doesn’t try to change its password. For example, if it was a laptop running at home with no VPN for 4 months, the laptop would never change its own machine password. 

The relevant Netlogon parameters that come into play and we can think about changing here are:

ScavengeInterval (default 15 minutes),
MaximumPasswordAge (default 30 days)
DisablePasswordChange (default off).

DisablePasswordChange would prevent the client computer from changing its computer account password.

Warning: If you disable machine account password changes, there are security risks because the security channel is used for pass-through authentication. If someone discovers a password, he or she can potentially perform pass-through authentication to the domain controller.

Here is the article that talks about disabling automatic machine account password change: KB154501

Key = HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Value = DisablePasswordChange REG_DWORD
Default = 0

Group policy setting:
Computer\Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Domain member: Disable machine account Password changes

ScavengeInterval controls how often the workstation scavenger thread runs - the workstation scavenger is responsible for changing the machine password if necessary.

HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Value: ScavengeInterval REG_DWORD, 60 to 172800 Seconds (48 hours)
Default : 900 (15 minutes)

MaximumPasswordAge determines when the computer password needs to be changed.

Key = HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Value = MaximumPasswordAge REG_DWORD
Default = 30
Range = 1 to 1,000,000 (in days)

Group policy setting:
Computer\Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Domain member: Maximum machine account Password age

To clear things up, it is 7 days on Windows NT by default, and 30 days on Windows 2000 and up.

The trust password follows the same setting. So Trust between two NT 4 domains is 7 days. Trusts between Windows 2000 and up and anything else is 30 days.

So what this means is if:

 

- 2000 and NT4 trust password is 30 days.
- 2000 to 2000 is 30 days.
- 2000 to 2003 is 30 days.
- 2003 to 2003 is 30 days.

After Netlogon service starts the Workstation service scavenger thread wakes up. If the password is not older than MaximumPasswordAge , the scavenger thread goes back to sleep and sets itself to wake up when the password will reach that age. Otherwise, the scavenger thread will attempt to change the password. If it cannot talk to a DC, it will go back to sleep and try again in ScavengeInterval minutes.

The ScavengeInterval setting can be modified to a custom value using the group policy setting in Active Directory.

Group policy setting:
Computer Configuration\Administrative Templates\System\Netlogon\Scavenge Interval

Further we have given the following clarification regarding the behavior described
in KB260575.  

Question: How do computers actually use passwords?

Answer: Each Windows-based computer maintains a machine account password history containing the current and previous passwords used for the account. When two computers attempt to authenticate with each other and a change to the current password is not yet received, Windows then relies on the previous password. If the sequence of password changes exceeds two changes, the computers involved may be unable to communicate, and you may receive error messages.

When a client determines that the machine account password needs to be changed, it would try to contact a domain controller for the domain of which it is a member of to change the password on the domain controller. If this operation succeeds then it would update machine account password locally.


The local copy of the machine password is stored under:

HKLM\SECURITY\Policy\Secrets\$machine.ACC

We store the current password and the previous password under CurrVal & OldVal Keys respectively.

In Active Directory, we store the password in unicodepwd and lmpwdHistory . We also store the timestamp in the pwdlastset attribute (the method to convert it into readable format is



Convert the value in the attribute from decimal to hex (using calc.exe)
Split the result into two equal parts (8 bits for each part)
Run nltest /time: rightsidehex leftsidehex

The resultant value is the date and time the password was set on this computer object in AD. The cases where in you could run into problems that the KB260575 describes would be:

If you use System Restore after the password change interval expired one time, and you restore the computer to a point before the password changes, the next password change may not occur when it is due. Instead, the operating system treats the restore as if the password was changed.

Now consider the scenario, when a machine is not connected to the network for a long period.

Supposing on the client:

Old password = null
Current password = A

New random password = B

And on the machine account in AD:


unicodePWD = A


After 30 days when the Scavenger thread runs, the value would be


Old Password = A

Current Password = B
At 60 th day the same process happens again. So now the newly generated password is C and the values are:

Old password = B

Current Password = C

Now when the client connects to AD, it will try the current password to authenticate. When that fails with the error, it can try the previous. Otherwise machine should be able to reset its password once it boots even after say 90 days.

 

Update April 2020: While the above scenario may have been possible when the article was originally written, Windows 7 SP1 clients and later will never reset the local registry LSA secret if it fails to reset the AD object’s corresponding UnicodePWD attribute -- in other words: Local password change will never occur unless a DC is able to process the change.



How to detect and remove inactive machine accounts

https://gallery.technet.microsoft.com/scriptcenter/Get-Active-Directory-df516533

https://gallery.technet.microsoft.com/scriptcenter/Get-Inactive-Computer-in-54feafde

I would recommend the following KB articles as good reads:

How to disable automatic machine account password changes

 
Effects of machine account replication on a domain
https://support.microsoft.com/en-us/help/175468/effects-of-machine-account-replication-on-a-domain

Domain member: Disable machine account password changes
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-...

Domain member: Maximum machine account password age
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-...

Account Passwords and Policies
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/passwor...

To wrap it up Machine account password are driven by Client computer not by Active directory. The Netlogon scavenger thread is responsible for changing the Machine password if necessary the same can be modified by group policy. We first change the password locally and then update it in Active Directory. It will not rollback the changes to the current password if it is unable to update it in Active Directory.


- Manish Singh
11 Comments
Copper Contributor

Nice!!

 

I got a problem with SQL Server and Kerberos Authentication.

The SQL Instance runs under the Virtual Account "NT SERVICE\MSSQLSERVER".  All possible SPN are correctly registered to the machine account.

 

When some client attempts authentication on SQL Server using Windows Authentication, the client gets the Kerberos Ticket succesffully (i can see it on output of klist).

 

But, when the client send its to the my SQL instance, it cannot decrypt the ticket, and client receives "Cannot generate SSPI". Looking at the kerberos log, on event viewer, i get the KRB_AP_ERR_MODIFIED error.

 

This can be triggered by a different machine account password on my SQL Server instance and the password stored on Active Directory?

Just more data: I've used the AdExplorer from sysinternals to look in some properties of machine account in AD and I noted that the attribute badPasswordTime keeps updated. In other servers, last value is from two years ago.

Copper Contributor

Thank you really for that post.

But all KB links are wrong. :(

Copper Contributor

Hi,

Could you explain more the line : "If the machine was unable to communicate with a domain controller for 60 days, then we have a secure channel issue" ?

Copper Contributor

Hello,

 

My question is a little bit similar to @webmantoine's question.

 

At the end of article you provide example "Now consider the scenario, when a machine is not connected to the network for a long period".

Based on all the article above, if machine is "not connected to the network", it does not change the password, because DC is not available. So how in your example this thing happens?

After 30 days when the Scavenger thread runs, the value would be
Old Password = A
Current Password = B

At 60 th day the same process happens again. So now the newly generated password is C and the values are:
Old password = B
Current Password = C 



Copper Contributor

Hi,

If this discussion still open, I want to share my issue...

Today in my organization we have lost huge number of Computer Objects from AD, still we don't have the exact numbers but the issue is getting worse as many of the users complaining that their computers are getting out of domain.

There was no such major change in our Infrastructure today which could have triggered this issue, but recently we have demoted few Domain Controllers as they were old Operating System and promoted new in replace for those.

I want to know...

1. What is triggering this issue?

2. How to fix this

3. How to rejoin back all those hundreds of Client PCs back to our domain?

 

Appreciate your help

 

Regards

Abdul

Copper Contributor

Abdul, We have the same issue as you and are also replacing older DC's. I am wondering if the issue is related to changes in Netlogon that are coming with secure channel updates. - see CVE-2020-1472 articles for reference.

Copper Contributor
The Computer Account password change (This happens automatically in the background) will check the domain controller every 30 days to change its password. When some of our users are coming back from extended periods of time working from home and they come back into the office, they cannot connect to the domain. What is happening is the computer connects to a domain controller to validate it is a domain computer object and if the computer object has a password older than 90 days it will not be allowed to connect. Does this sound right?
 
Thanks!
Copper Contributor

Hi,

What is when we restore the Active Directory environment to the older date than password expire age ? The client will loss the domain membership and need to re-join them manually? If this is the case, make sense to disable password reset for clients ?

 

Thanks in advance.

Copper Contributor

No clear answer to this behavior.

Did Microsoft changed this behavior during covid-19 ?

If the machine was unable to communicate with a domain controller for 60 days, then we have a secure channel issue

As I understand if the current password and the cached password didn't match with AD computer password (so 60 days without AD contact an PC was running outside the network) the message: The trust relationship between this workstation and the primary domain failed was thrown if the computer contacts a domain controller after 60 days.

now : 

Update April 2020: While the above scenario may have been possible when the article was originally written, Windows 7 SP1 clients and later will never reset the local registry LSA secret if it fails to reset the AD object’s corresponding UnicodePWD attribute -- in other words: Local password change will never occur unless a DC is able to process the change.

 

It seems that the PC doesn't initiate a password change if a DC is not available to process it.

 

Can someone confirm this behavior ?

 

Thanks

Copper Contributor

Thanks for such an amazing and detailed explanation.

Copper Contributor

Could someone from Microsoft update this article? It says If the machine was unable to communicate with a domain controller, the client doesn’t try to change its password. For example, if it was a laptop running at home with no VPN for 4 months, the laptop would never change its own machine password. 

 

Never mind, though I think I've seen the error like The trust relationship between the workstation and the domain has failed since 2020, I am not absolutely sure. https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/secure-channel-expired-machi... talks about this further.

Version history
Last update:
‎Apr 27 2020 07:16 AM
Updated by: