Enable computer and user accounts to be trusted for delegation

The process of promoting a server to a domain controller usually goes without any issue if DNS and network are done properly, but every now and then, an error pops-up and if we don’t deal with it, we cannot continue. This is what happened to me when not to long ago I needed to promote a new domain controller in an existing domain in an environment that I do not manage and an error message shows-up right before the promoting process begins. In this article I was able to reproduce the error from my client’s environment and I’m going to show some troubleshooting steps here, as future reference.

Like I have said, I was trying to promote a new domain controller in an existing domain and right before I hit the Install button on the Active Directory Domain Services Configuration Wizard, an error shows-up making the promotion process to stop.

Verification of Administrators rights failed. The Administrator account does not have the “Enable computer and user accounts to be trusted for delegation” right enabled.

The massage is clear that it is a permissions issue, but I was using an Administrator account! Most of the times an Administrator account can do all the good’s and bad’s in a forest/domain if it is not limited by a GPO. The next step was to check if the account I was using to promote this server to a domain controller was indeed part of the domain Administrators group. And it was.

Since I was sure this is a permission issue I googled around where I can find the policy (Enable computer and user accounts to be trusted for delegation) in the error message. And sure enough I got my answer. The policy resides in the Default Domain Controllers Policy GPO in Computer Configuration > Policies > Windows Settings > Security Settings > Local Policy > User Rights Assignment and the user account used to promote the new domain controller needs to be part of this policy.

By default only the domain Administrators group is part of this policy, so in case of delegation all we need to do is make the account part of the local Administrators group. Like I said above, the account I was using was already part of this security group.

Something had to block or overwrite this policy and one way to test this is to put the server (future domain controller) in the Domain Controllers container then open a command prompt on the server as Administrator and issue the bellow command line. In the results, we should be able to see the Enable computer and user accounts to be trusted for delegation policy. If it is not there, then the policy is not applying.

Even if you have UAC disabled, the terminal still needs to be opened as Administrator or it is not going to work.

whoami /priv

Now I know that the policy is there, it is correctly configured, it is not filtered by security or a WMI filtering, but it is not applying. This means that it is overwritten by another GPO with a lower precedence. The lower the GPO precedence number the more it wins.

The next step was to find out what policy overwrites the Default Domain Controllers Policy. A simple way to do this was to open the Resultant Set of Policy console (rsop.msc) on the server and check the policy settings path (Computer Configuration > Policies > Windows Settings > Security Settings > Local Policy > User Rights Assignment). And sure enough, there was another GPO with the same policy configured but with different values, and in this case it was a different security group configured. I had two options, either add my account to this security group, or disable the policy. Since I don’t like changing default settings in a domain, I asked around, a funny thing is that the security group was not even used anymore, so I disabled the policy in this winning GPO.

After issuing a gpupdate /force command on the server and a reboot I then checked the privileges on the server. This time the policy showed up and the last thing was to try and promote the server as a domain controller.

whoami /priv

And it worked!

 

Summary

Most of the times it not easy to identify the problem especially in large environments with thousands of GPOs ( yes, you read that right, thousands of GPOs) and if you are not managing the environment full time. With a little bit of patience and having some troubleshooting steps solving the problem becomes way easier and goes way faster.

Let me know in the comments area how you dealt with this error when it showed up in your Active Directory Domain Services Configuration Wizard.