Computer account passwords
kaizi
Posted messages
20
Status
Member
-
kaizi Posted messages 20 Status Member -
kaizi Posted messages 20 Status Member -
Hello,
I am an intern in the IT department of a company. I am currently working on a security audit conducted by ANSSI on our information system. The point I am now focusing on is the computer password that has remained unchanged for several years… on our servers. I thought it was about local accounts on the machine, but I came across an article on this site:
https://forums.commentcamarche.net/forum/affich-36931925-debutant-mot-de-passe-des-comptes-ordinateur-active-directory
It is said that a common issue is that the machine fails to change its password, and it is explained how to help it reset this password. Currently, I am testing on our WSUS server, and I would like to know the main causes of this problem in order to minimize its frequency as much as possible.
Because if it were to happen on a print server on a Saturday afternoon, it wouldn't cause much trouble, but if it were a file server, it would be more impactful on our system.
Thank you for your attention to my request.
Sincerely,
SamSam
I am an intern in the IT department of a company. I am currently working on a security audit conducted by ANSSI on our information system. The point I am now focusing on is the computer password that has remained unchanged for several years… on our servers. I thought it was about local accounts on the machine, but I came across an article on this site:
https://forums.commentcamarche.net/forum/affich-36931925-debutant-mot-de-passe-des-comptes-ordinateur-active-directory
It is said that a common issue is that the machine fails to change its password, and it is explained how to help it reset this password. Currently, I am testing on our WSUS server, and I would like to know the main causes of this problem in order to minimize its frequency as much as possible.
Because if it were to happen on a print server on a Saturday afternoon, it wouldn't cause much trouble, but if it were a file server, it would be more impactful on our system.
Thank you for your attention to my request.
Sincerely,
SamSam
6 answers
Good evening,
1. How do you check if a machine's password has changed/has not changed?
2. It is also possible that the machine's password change has been disabled...
A great article on the subject: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/machine-account-password-process/ba-p/396026
Be careful not to make changes in production on a whim...
First, you need to gather information on whether all machines are affected or not, check the current settings, etc... so exporting computer accounts with PowerShell already allows you to see the extent of the issue.
--> no testing on a WSUS server... it would be a shame to mess up a machine that deploys updates.
--
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
1. How do you check if a machine's password has changed/has not changed?
2. It is also possible that the machine's password change has been disabled...
A great article on the subject: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/machine-account-password-process/ba-p/396026
Be careful not to make changes in production on a whim...
First, you need to gather information on whether all machines are affected or not, check the current settings, etc... so exporting computer accounts with PowerShell already allows you to see the extent of the issue.
--> no testing on a WSUS server... it would be a shame to mess up a machine that deploys updates.
--
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Good evening,
I expected it to be you who would respond, but not this quickly :). I tried to reach you via private message but without success (I have quite a few questions to ask you about AD). To be able to affirm that most servers have unchanged passwords for over 15 years, I look at the pwdLastSet attribute of my machine accounts (Active Directory Users and Computers module).
I implemented a password policy this year for users; none of them were changing it, and their passwords never exceeded 5 characters. I made a good number of changes in this IS, and before each change, I gather a lot of information.
Your article is very interesting for understanding all the parameters found in: Computer Configuration\Administrative Templates\System\Netlogon, but also the different scenarios for password change requests for machine accounts.
Indeed, on all servers, the machine account password change is disabled. Thanks to your article, I learned that the default domain policy does not affect machine account passwords; I checked the GPOs applied to my WSUS (Group Policy Management module), and none affect this server, so the deactivation must have been done manually.
I am used to working on our WSUS because I set it up this year, and I know how to roll back if necessary. Before its implementation, we had machines running W10 version 1809.
After changing this parameter on the WSUS, the pwdLastSet attribute of this server had today's date. However, I learned that there was no local admin account on the servers, only the default Windows Administrator account. And the password is not the same on the servers, and it's also impossible to get the one for my WSUS, so it's going to take me time to fully understand all the issues.
My question was whether there were any well-known reasons for password renewal issues for machine accounts, but apparently not. But I need to ensure that each server can be reached via a local account with admin rights to avoid being stuck at an "Incorrect password."
I expected it to be you who would respond, but not this quickly :). I tried to reach you via private message but without success (I have quite a few questions to ask you about AD). To be able to affirm that most servers have unchanged passwords for over 15 years, I look at the pwdLastSet attribute of my machine accounts (Active Directory Users and Computers module).
I implemented a password policy this year for users; none of them were changing it, and their passwords never exceeded 5 characters. I made a good number of changes in this IS, and before each change, I gather a lot of information.
Your article is very interesting for understanding all the parameters found in: Computer Configuration\Administrative Templates\System\Netlogon, but also the different scenarios for password change requests for machine accounts.
Indeed, on all servers, the machine account password change is disabled. Thanks to your article, I learned that the default domain policy does not affect machine account passwords; I checked the GPOs applied to my WSUS (Group Policy Management module), and none affect this server, so the deactivation must have been done manually.
I am used to working on our WSUS because I set it up this year, and I know how to roll back if necessary. Before its implementation, we had machines running W10 version 1809.
After changing this parameter on the WSUS, the pwdLastSet attribute of this server had today's date. However, I learned that there was no local admin account on the servers, only the default Windows Administrator account. And the password is not the same on the servers, and it's also impossible to get the one for my WSUS, so it's going to take me time to fully understand all the issues.
My question was whether there were any well-known reasons for password renewal issues for machine accounts, but apparently not. But I need to ensure that each server can be reached via a local account with admin rights to avoid being stuck at an "Incorrect password."
Hello,
I don't check my private messages; it's better that exchanges are open to everyone.
Looking for pwdlastset is the right method.
-
I implemented a password policy this year for users, none of them changed it and their password never exceeded 5 characters
A. Password policy: maxpasswordlenght
This is a very good thing. Well, let's not kid ourselves, it's difficult for users to change their passwords too often...
I generally recommend a minimum of 15 characters; however, it's not possible to go beyond 14 through the GPMC... since w2016 it has been possible to do this via GPMC beyond 14, but the settings do not apply to the domain (there may be a patch, but I haven't looked further).
You have to go through PSOs targeting users (or groups by the way) to indicate password policies beyond 14 characters.
Why 15? The way password hashing is managed by Lanman (LM/NTLM): it is based on 2 strings of 7 characters or 14 characters; and it is "more" vulnerable to cracking tools.
By exceeding 14 (so a minimum of 15), the password hash is set to NULL (but the password is not null...), which protects against brute force attacks on hashes.
https://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=762c7cbd-bc00-44b1-8d35-cf42bc7fe2e9&CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments
Well, after that, it needs to be validated and accepted... it's not simple.
B. Password policy: maxpasswordAge
Make rotations less frequent (like every 3 to 6 months) in the password policy (maxPasswordAge).
This prevents users from writing their passwords down on paper... and especially from making "predictable" passwords, based on the month of the year for example...
It's better to have a robust unpredictable password changed every 6 months than a password written down on paper and predictable, even if it's changed every month...
-
Indeed, on all servers, the password change for the machine account is disabled
You have to ensure that machines are properly stored in an OU (Organizational Unit) and not in the default container "computers".
This "computers" container does not allow linking GPOs... whereas an OU is made for that.
So you must apply a GPO on an OU containing the computers, which allows re-enabling password rotation for machine accounts. (so create a sub-OU to test on a batch of pre-prod machines for example...)
After knowing the cause, if it’s historical... it can be complicated to understand this technical choice...
You also need to look into the provisioning/installation part of the machines and see if this parameter is injected from the start.
-
However, I learned that there was no local admin account on the servers, only the default Windows Administrator account. And the password is not the same on the servers
Every Windows machine that is a member of a domain does indeed have local accounts (SAM database) that are unique to it, including the "administrator" account.
Only domain controllers are a special case; they do not have "local accounts," since they store domain accounts in the NTDS.dit database (and no longer have a SAM database).
It is very good that local admin accounts are different for each machine; this prevents lateral movements in case of an attack.
Maybe LAPS has been implemented? Otherwise, it's worth looking into, but watch out for prerequisites.
-
My question was whether there were well-known reasons for password renewal issues for machine accounts, but apparently not. But I need to make sure that each server can be reached via a local account with admin rights to avoid being blocked in front of an "Incorrect password"
There are indeed issues primarily around connectivity (firewall somewhere), sometimes DNS, where a machine cannot resolve the domain name with DNS and therefore cannot contact the domain.
I don't check my private messages; it's better that exchanges are open to everyone.
Looking for pwdlastset is the right method.
-
I implemented a password policy this year for users, none of them changed it and their password never exceeded 5 characters
A. Password policy: maxpasswordlenght
This is a very good thing. Well, let's not kid ourselves, it's difficult for users to change their passwords too often...
I generally recommend a minimum of 15 characters; however, it's not possible to go beyond 14 through the GPMC... since w2016 it has been possible to do this via GPMC beyond 14, but the settings do not apply to the domain (there may be a patch, but I haven't looked further).
You have to go through PSOs targeting users (or groups by the way) to indicate password policies beyond 14 characters.
Why 15? The way password hashing is managed by Lanman (LM/NTLM): it is based on 2 strings of 7 characters or 14 characters; and it is "more" vulnerable to cracking tools.
By exceeding 14 (so a minimum of 15), the password hash is set to NULL (but the password is not null...), which protects against brute force attacks on hashes.
https://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=762c7cbd-bc00-44b1-8d35-cf42bc7fe2e9&CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments
Well, after that, it needs to be validated and accepted... it's not simple.
B. Password policy: maxpasswordAge
Make rotations less frequent (like every 3 to 6 months) in the password policy (maxPasswordAge).
This prevents users from writing their passwords down on paper... and especially from making "predictable" passwords, based on the month of the year for example...
It's better to have a robust unpredictable password changed every 6 months than a password written down on paper and predictable, even if it's changed every month...
-
Indeed, on all servers, the password change for the machine account is disabled
You have to ensure that machines are properly stored in an OU (Organizational Unit) and not in the default container "computers".
This "computers" container does not allow linking GPOs... whereas an OU is made for that.
So you must apply a GPO on an OU containing the computers, which allows re-enabling password rotation for machine accounts. (so create a sub-OU to test on a batch of pre-prod machines for example...)
After knowing the cause, if it’s historical... it can be complicated to understand this technical choice...
You also need to look into the provisioning/installation part of the machines and see if this parameter is injected from the start.
-
However, I learned that there was no local admin account on the servers, only the default Windows Administrator account. And the password is not the same on the servers
Every Windows machine that is a member of a domain does indeed have local accounts (SAM database) that are unique to it, including the "administrator" account.
Only domain controllers are a special case; they do not have "local accounts," since they store domain accounts in the NTDS.dit database (and no longer have a SAM database).
It is very good that local admin accounts are different for each machine; this prevents lateral movements in case of an attack.
Maybe LAPS has been implemented? Otherwise, it's worth looking into, but watch out for prerequisites.
-
My question was whether there were well-known reasons for password renewal issues for machine accounts, but apparently not. But I need to make sure that each server can be reached via a local account with admin rights to avoid being blocked in front of an "Incorrect password"
There are indeed issues primarily around connectivity (firewall somewhere), sometimes DNS, where a machine cannot resolve the domain name with DNS and therefore cannot contact the domain.
Hello,
I don't look at my private messages; and it's better that exchanges be open to everyone.
I understand, these are just some technical questions I have left after researching topics like adminSDHolder, NTFRS and FDSR protocols for sysvol replication, krbtgt accounts, etc., especially when I have conflicting sources. It bothers me a bit to open a new topic just for small questions like these.
-
You need to go through PSOs targeting users (or groups by the way) to indicate password policies beyond 14 characters.
That's what I've used for password renewals for users. The minimum character count is 8 and a lifespan of 6 months. Keeping the last 3 passwords in memory to avoid reusing an old one, and with the complexity rules provided by the AD manager. It was already quite a struggle to enforce these conditions, and I can't imagine our users remembering a password of 15 characters or more.
Why 15? The way password hashing is managed by Lanman (LM/NTLM): it relies on 2 strings of 7 characters or 14 characters; and it's "more" vulnerable to cracking tools.
By exceeding 14 (thus at least 15), the password hash is set to NULL (but the password is not null...), which protects against brute force attacks on hashes.
That's very interesting, I thought all authentication in a domain or to access a domain was done via the Kerberos protocol. But apparently, the NTLM protocol is used for services on local accounts or access to a machine via its IP.
-
You need to ensure that the machines are properly stored in an OU (Organizational Unit) and not in the default "computers" container.
This "computers" container does not allow linking GPOs... whereas an OU is designed for that.
They are indeed all well organized, and I used the "redircmp" command so that when client or server machines arrive in the domain, they are placed in an OU (so that a GPO can be applied there).
-
It's a very good thing that local admin accounts are different for each machine; it prevents lateral movement in case of an attack.
Also, maybe LAPS has been implemented? Otherwise, it's worth looking into, but be mindful of the prerequisites.
A few months after I arrived, I discovered this tool (LAPS) and researched it to present it to my department, but it was rejected despite what it could have brought. I also presented the protected user group and proposed a more stringent password policy for IT accounts, but without success.
-
Only domain controllers are a special case; they don't have "local accounts" since they store domain accounts in the NTDS.dit database (and no longer have a SAM database).
...
There are indeed issues around connectivity mainly (firewall somewhere), sometimes DNS, where a machine cannot resolve the domain name with DNS and thus cannot contact the domain.
That's what I realized yesterday afternoon, so we should create local admin accounts ourselves to access these DCs in case of domain name resolution issues.
Thank you for your response and follow-up. As I said at the beginning of our discussion, before each change, I take the time to research what I'm doing and the impact it will have, even if of course we can't predict everything.
I don't look at my private messages; and it's better that exchanges be open to everyone.
I understand, these are just some technical questions I have left after researching topics like adminSDHolder, NTFRS and FDSR protocols for sysvol replication, krbtgt accounts, etc., especially when I have conflicting sources. It bothers me a bit to open a new topic just for small questions like these.
-
You need to go through PSOs targeting users (or groups by the way) to indicate password policies beyond 14 characters.
That's what I've used for password renewals for users. The minimum character count is 8 and a lifespan of 6 months. Keeping the last 3 passwords in memory to avoid reusing an old one, and with the complexity rules provided by the AD manager. It was already quite a struggle to enforce these conditions, and I can't imagine our users remembering a password of 15 characters or more.
Why 15? The way password hashing is managed by Lanman (LM/NTLM): it relies on 2 strings of 7 characters or 14 characters; and it's "more" vulnerable to cracking tools.
By exceeding 14 (thus at least 15), the password hash is set to NULL (but the password is not null...), which protects against brute force attacks on hashes.
That's very interesting, I thought all authentication in a domain or to access a domain was done via the Kerberos protocol. But apparently, the NTLM protocol is used for services on local accounts or access to a machine via its IP.
-
You need to ensure that the machines are properly stored in an OU (Organizational Unit) and not in the default "computers" container.
This "computers" container does not allow linking GPOs... whereas an OU is designed for that.
They are indeed all well organized, and I used the "redircmp" command so that when client or server machines arrive in the domain, they are placed in an OU (so that a GPO can be applied there).
-
It's a very good thing that local admin accounts are different for each machine; it prevents lateral movement in case of an attack.
Also, maybe LAPS has been implemented? Otherwise, it's worth looking into, but be mindful of the prerequisites.
A few months after I arrived, I discovered this tool (LAPS) and researched it to present it to my department, but it was rejected despite what it could have brought. I also presented the protected user group and proposed a more stringent password policy for IT accounts, but without success.
-
Only domain controllers are a special case; they don't have "local accounts" since they store domain accounts in the NTDS.dit database (and no longer have a SAM database).
...
There are indeed issues around connectivity mainly (firewall somewhere), sometimes DNS, where a machine cannot resolve the domain name with DNS and thus cannot contact the domain.
That's what I realized yesterday afternoon, so we should create local admin accounts ourselves to access these DCs in case of domain name resolution issues.
Thank you for your response and follow-up. As I said at the beginning of our discussion, before each change, I take the time to research what I'm doing and the impact it will have, even if of course we can't predict everything.
Hello,
I realized this yesterday afternoon, so we should create local admin accounts ourselves to access these DCs in case of domain name resolution issues.
A local account does not exist on a DC, as the NTDS.dit database replaces the SAM database.
A DC can authenticate without any problem because it contains the database of all domain accounts.
Furthermore, it also contains the DNS partitions, so there is little risk of losing DNS resolution.
(there are still some constraints though)
However, these cases can happen, for instance, if the AD services do not start, or if the DNS is managed by a third-party infrastructure and there is a network issue or a DNS resolution problem - and we would not be able to log in locally on the isolated DC...
But no worries! There is an account called "DSRM" that is configured during the installation of each DC.
That is the account to use in case of major issues by booting in "Directory Services Restore Mode"...
--
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
I realized this yesterday afternoon, so we should create local admin accounts ourselves to access these DCs in case of domain name resolution issues.
A local account does not exist on a DC, as the NTDS.dit database replaces the SAM database.
A DC can authenticate without any problem because it contains the database of all domain accounts.
Furthermore, it also contains the DNS partitions, so there is little risk of losing DNS resolution.
(there are still some constraints though)
However, these cases can happen, for instance, if the AD services do not start, or if the DNS is managed by a third-party infrastructure and there is a network issue or a DNS resolution problem - and we would not be able to log in locally on the isolated DC...
But no worries! There is an account called "DSRM" that is configured during the installation of each DC.
That is the account to use in case of major issues by booting in "Directory Services Restore Mode"...
--
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....