Hi, another juicy customer question with a cool solution. The problem is this: on all workstations, the built-in Administrator account is disabled. Restriction groups are used to populate the group “Built-in\Administrators” with domain groups. No “back-door” local administrator accounts exist. So, when the desktop support team is trying to troubleshoot connectivity problems with machines, they may remove the computer from the domain. Once they do this, there is no way to log back on. Things were complicated even further as the workstations involved had their install partition encrypted with BitLocker, meaning any data on the workstation is also lost.

So, without exposing a back-door account, we needed a way to prevent the workstation administrator from removing a workstation from the domain, but not in a “permanent” way – slow them down in such a way that undoing the prevention should remind them to add a temporary backdoor account before removing from the domain. And here’s what we came up with:

We ran Sysinternals Process Monitor while removing the computer from the domain to see what changes are made to the system. If we can set a “deny” to the first action, then all the other actions will also be prevented from happening.

The first change that happens to the system during a removal from the domain is to set the “Netlogon”service to start-up as “manual” instead of “automatic”. So by setting a deny in the registry for the user “SYSTEM”, we prevent the first action. But the remove from the domain process is clever, and detects if it cannot change the value it will attempt to take ownership of the registry key. So we also need to prevent modifying the owner. All of that looks like this:

RegDeny-DomainDisjoin

So when the workstation administrator attempts to remove the computer from the domain, they hit an immediate “access denied” and all further processing stops. Now the administrator must remove the explicit denies and that will hopefully be enough of a reminder to add a local administrator before rebooting the machine after removing it from the domain.

Please note that this is not a supported or recommended method to perform this job, but it did fit well for the customer who was in that tricky situation.