2

Implementing "Protected Users" and coming across this problem that I couldn't find a solution to anywhere. Cannot join computers to the domain with delegation permissions. Instead "Add workstation to the domain" right was assigned to a group.

Extensive background:

It is my understanding that members of protected users will be forced to use Kerberos authentication. In fact that's something I see when trying to join a workstation allowing a member of this group the following permissions on the Computers container:

Delegation at the "Computers" container:

  • Create computer objects - This object and all descendants

  • Read/write account restrictions - Descendant Computer objects

  • Validated write to service principal name - Descendant Computer objects

  • Validated write to DNS host name - Descendant Computer objects

  • Create all child objects - Descendant Computer objects

  • Reset password - Descendant Computer objects

Tested on two users: a user with "Protected Users" group membership and a user without "Protected Users" group membership. Both users are part of the delegation group.

Test itself:

When trying to add a computer to the domain a user without Protected Users group successfully adds the workstation to the domain. A user with Protected Users group will receive an error: "Account restrictions are preventing this user from signing in". I can see the NTLM authentication failure under the ProtectedUserFailures-DomainController

However changing the group policy to allow "Add workstations to the domain" by adding the group both users belong to will change the outcome to success on both. Now I can see info under ProtectedUserSuccesses-DomainController with Kerberos authentication.

So my question is: What mechanisms are in play and what permissions can I delegate to achieve the same result, or is this not possible? How come the user right allows this action to be completed for a member of "Protected Users" group, while simple delegation does not?

Before anyone asks, this was tested and works in prod as well as a simple test environment you can recreate with the info above.

Igor Akula
  • 23
  • 3

2 Answers2

0

For those that end up here in the future, I was able to join a computer to my domain while being in the Protected Users group by using powershell: Add-Computer -DomainName "example.org" -OUPath "OU=Delegated OU,DC=example,DC=org" -DomainCredential example\user

Note that using the -Credential switch makes it go NTLM, need to use the -DomainCredential.

BOFH2.0
  • 1
0

I suspect this is a problem because you are violating Microsoft's explicit recommendations by applying delegated permissions to the Computers container.

From Delegating Administration of Default Containers and OUs:

If you need to delegate control over users or computers, do not modify the default settings on the users and computers containers. Instead, create new OUs (as needed) and move the user and computer objects from their default containers and into the new OUs. Delegate control over the new OUs, as needed. We recommend that you not modify who controls the default containers.

So basically you can use the legacy Computers container and the corresponding "Add workstations to the domain" right or you can use proper OUs with delegated permissions, but if you choose to use the legacy Computers container you are not expected to be using delegated permissions. It should not therefore be surprising that Microsoft didn't test this particular scenario when they implemented Protected Users!

Note that if you are using separate OUs, joining a new computer to the domain becomes a two-step process: you must explicitly create the computer object in the desired OU before joining the computer to the domain.

More speculatively:

It seems likely that your current process is falling down when the new computer attempts to join the domain and finds that there is no existing computer object, in which case it automatically creates one in the Computers container. It would seem that this automated process, which is only required in the legacy scenario, only knows how to create a computer in either of two ways, one of which requires the "Add workstations to the domain" privilege and the other of which uses NTLM authentication.

The use of NTLM here might be an inherent limitation in the relevant protocol or it might just be an artifact of the legacy code used by the Windows client in this scenario. I suppose you could in principle reverse engineer this process by capturing the traffic between the server and client, but it probably isn't worth the effort that would be involved.

At any rate, you could test this theory by getting the protected user to explicitly create the new computer object in the Computers container (using Active Directory Users and Computers from a machine that is already in the domain) before attempting to join the new computer to the domain. I suspect you will find that this process works even without the "Add workstations to the domain" privilege.

Harry Johnston
  • 5,875
  • 4
  • 35
  • 52