实施“受保护的用户”并遇到此问题，我无法在任何地方找到解决方案。无法使用委派权限将计算机加入域。相反，“将工作站添加到域”权限被分配给一个组。
广泛的背景：
据我了解，受保护用户的成员将被强制使用 Kerberos 身份验证。事实上，当我尝试加入工作站时，我看到了这种情况，该工作站允许该组的成员在计算机容器上拥有以下权限：
“计算机”容器中的委托：
创建计算机对象 - 此对象及其所有后代
读/写帐户限制 - 后代计算机对象
已验证写入服务主体名称 - 后代计算机对象
已验证写入 DNS 主机名 - 后代计算机对象
创建所有子对象 - 后代计算机对象
重置密码 - 后代计算机对象
针对两个用户进行了测试：一个是具有“受保护用户”组成员资格的用户，另一个不是“受保护用户”组成员资格的用户。这两个用户都是委派组的一部分。
测试本身：
当尝试将计算机添加到域时，没有受保护用户组的用户成功将工作站添加到域。具有受保护用户组的用户将收到错误：“帐户限制阻止此用户登录”。我可以在 ProtectedUserFailures-DomainController 下看到 NTLM 身份验证失败
但是，通过添加两个用户所属的组，将组策略更改为允许“将工作站添加到域”，这将使结果在两个方面都成功。现在我可以在 ProtectedUserSuccesses-DomainController 下看到带有 Kerberos 身份验证的信息。
所以我的问题是：有哪些机制在起作用，我可以委派哪些权限来实现相同的结果，或者这是不可能的？为什么用户权限允许“受保护的用户”组的成员完成此操作，而简单委派却不允许？
在有人询问之前，这已经过测试并且可以在生产中运行，并且您可以使用上述信息重新创建一个简单的测试环境。
答案1
我怀疑这是一个问题，因为您通过将委派权限应用于计算机容器违反了 Microsoft 的明确建议。
如果您需要委派对用户或计算机的控制权，请不要修改用户和计算机容器上的默认设置。相反，创建新的 OU（根据需要），并将用户和计算机对象从其默认容器移到新 OU。根据需要委派对新 OU 的控制权。我们建议您不要修改谁控制默认容器。
因此，基本上，您可以使用旧式计算机容器和相应的“将工作站添加到域”或者您可以使用具有委派权限的适当 OU，但如果您选择使用旧版计算机容器，则不应使用委派权限。因此，微软在实施受保护用户时没有测试这种特定场景也就不足为奇了！
请注意，如果您使用单独的 OU，则将新计算机加入域将变成一个两步过程：您必须在将计算机加入域之前在所需的 OU 中明确创建计算机对象。
更推测的是：
当新计算机尝试加入域并发现没有现有计算机对象时，您当前的进程似乎会失败，在这种情况下，它会自动在计算机容器中创建一个。似乎这个自动化过程只在旧方案中才需要，它只知道如何以两种方式之一创建计算机，其中一种需要“将工作站添加到域”权限，另一种使用 NTLM 身份验证。
这里使用 NTLM 可能是相关协议的固有限制，也可能只是 Windows 客户端在此场景中使用的旧代码的产物。我猜你原则上可以通过捕获服务器和客户端之间的流量来逆向此过程，但这可能不值得付出那么多努力。
无论如何，您可以通过让受保护的用户在尝试将新计算机加入域之前，在计算机容器中明确创建新的计算机对象（使用域中已有机器上的 Active Directory 用户和计算机）来测试此理论。我猜您会发现即使没有“将工作站添加到域”权限，此过程也能正常工作。
答案2
对于将来会来到这里的人，我能够使用 powershell 将位于受保护用户组中的计算机加入到我的域中：Add-Computer -DomainName "example.org" -OUPath "OU=Delegated OU,DC=example,DC=org" -DomainCredential example\user
请注意，使用 -Credential 开关会使其转到 NTLM，需要使用 -DomainCredential。