Using Google Cloud’s “Set Windows password” function on a domain controller
By using the Set Windows password button in the Cloud Console or the Generate Windows logon credentials function in IAP Desktop, you can request the Windows guest OS agent to create a local user account for you, or to reset a password of an existing user account. In the last post, we looked at the risks associated with these local administrator accounts and why it might be a good idea to disable the feature for domain-joined VM instances.
But what about domain controllers? Local user accounts are managed in the SAM database, but the SAM database is disabled on domain controllers unless it’s running in restore mode. Does that mean the Set Windows password does not work for domain controllers?
The Guest OS agent is oblivious to whether it’s running on a domain controller or not, and does the same thing in both cases: To create users and reset their passwords, the agent calls the Win32 NetUserAdd and NetUserSetInfo functions. These functions have been around since NT 3.1 and as it turns out, they work just fine on a domain controller. As result:
- If you use the Set Windows password function on a domain controller and specify the SAM username of an existing domain user, the guest OS agent resets that domain user’s password.
- If you specify a username that isn’t used yet, the agent creates a new domain user , places it in the Users container in Active Directory, and adds it to the Administrators group. This group gives the user full access to the domain controller.
Before you conclude that this is a security hole, keep in mind that using the Set Windows password requires you to have the Compute Instance Admin and Service Account User role. These roles give you full access to a VM, and can be thought of as being equivalent to having physical access to an on-premises server. From a security perspective, these results are therefore not really worrying.
Still, having Set Windows password modify domain users is probably not what you’d expect and almost certainly not what you want. On domain controllers, it’s therefore even more important than on other domain-joined VM instances to disable the account manager.
P.S. I updated the Compute Engine documentation to include a note that describes the behavior on domain controllers.
Thanks to Marco Ferrari for reviewing this blog post.