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.
Share on 
