Have you ever logged into a domain-joined server and—for one reason or another—been greeted with one of the following error messages:
The trust relationship between this workstation and the primary domain failed.
Or
The security database on the server does not have a computer account for this workstation.
You start thinking about how you’ll need to log in with the local administrator account to even start investigating the issue, only to realize you have no idea what that administrator account’s credentials are.
Many organizations attempt to standardize their servers by setting the local administrator credentials via Group Policy. This makes it easier to log into servers locally in the event domain authentication fails for whatever reason. It also simplifies their life by giving IT admins a backdoor into all the computers under the control of the AD infrastructure. It sort of makes sense. After all, you can easily leverage Group Policy Preferences to deploy a standard set of administrator credentials to all of the machines in your domain, right?
…One caveat, though: even Microsoft says it’s a bad idea. (In fact, Microsoft recommends disabling the local administrator entirely, but that’s a whole other story.)
Anyway, back to the issue at hand. The problem lies in the way GPO settings are stored. Active Directory uses a share called SYSVOL to store policy settings. Any authenticated user on your network has access to this share (as required for deploying GPOs to your workstations/end users). Group Policy Preferences will then store the credentials in a value called “cpassword” which is saved to an XML file stored on the SYSVOL share.
You might think (and rightly so) that this is a pretty dumb thing to do. The good news is the cpassword value is encrypted in the XML file. The bad news is Microsoft has also provided the AES private key here to decrypt this value.
So yeah, this is a pretty dumb thing to do. Essentially, any authenticated user on your network can query the SYSVOL share for XML files that contain a “cpassword” value, decrypt the encrypted string in said XML file, and gain administrative access to any server in your domain.
Fortunately, there’s a simple command you can run to discover if this is the case in your AD environment:
findstr /S /I cpassword \\”DomainFQDN”\sysvol\”DomainFQDN”\policies\*.xml
This will list out the paths on the SYSVOL share of any XML files with a cpassword value. Note: only the GUIDs for the GPOs will be displayed, so you’ll need to use Get-GPO to query for the GPO name.
Get-GPO -Guid “GUIDofGPOwithoutCurlyBrackets”
From there, just delete the policies to remove them from SYSVOL.
So, what should you do if you need local admin access to your server infrastructure?
If your servers are running in Azure, there’s a helpful tool in the portal for each VM, under Support + Troubleshooting > Reset Password. This will reset the local administrator username and password on the server with values you supply in the portal. You can then log into the server using those credentials.
If your servers are on-premises or otherwise outside of Azure, you can leverage the Local Administrator Password Solution (LAPS) from Microsoft. This is a free tool that lets AD manage the local administrator credentials for your domain-joined machines. Since the LAPS database will contain the passwords for all the local admin accounts in your domain, you will want to be sure this is heavily restricted (treat it like a password database that needs to be highly secured).
Here is the download link for LAPS, as well as documentation on the solution.
To learn more about related important Hybrid IT & Cloud topics, please take a look at these recent posts. And if you have any additional questions around Active Directory—or any other aspects of Microsoft or Windows Server—please don’t hesitate to contact us. We’d love to help you out.
Consultant
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie | Duration | Description |
---|---|---|
cookielawinfo-checbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.