对于我们这个行业，经常会遇到AD管理的很多问题，其中部分是企业里IT管理常见的需求，部分是鲜见的奇怪需求。今天我来讲一个我们企业目前遇到的一个问题： 在AD里授权给Helpdesk人员将客户端计算机加入域的权限。因为我们通常不希望给这些人员的账户太多的权限，要遵循最小权限的原则。

首先微软推荐我们完成这个任务的两种途径：

一、通过组策略完成：

1. 打开【域默认组策略】，选择【计算机配置】-【策略】-【Windows设置】-【安全设置】-【本地策略】-【用户权限分配】，在右侧策略列表中选择【将工作站添加到域】，双击打开；

2. 将需要授权的用户添加到策略中来，如图，点确定即可完成。策略的生效可能需要时间，当然也可以强制刷新组策略。

二、通过委派任务来实现，具体如下：

1. 在域控上打开Active Directory 用户和计算机，右击域名(注意“将计算机加入域”只能在域上委派，不能在OU上)，选择【委派控制】;

2. 下一步，点击添加，选择被授权的用户或组，下一步；

3. 选择委派的任务，在这里你可以使用常见的委派任务，也可以自定义任务；而我们选择【将计算机加入域】，下一步，确定整个信息后点完成。这样就完成了委派的任务。此时你委派的用户就有将计算机加域的权限了。

以上两种方法是微软推荐的，可以在网上找到更加详细的教程。

但是本文的目的不仅仅是与大家分享如何授权加域，我要分析的是一个特殊场景：

正常来讲，Helpdesk人员经常会帮客户的计算机重装系统，而重装系统后需要将计算机名改为原来的计算机名再将其加入域中，这样不会在系统更改不必要的信息，方便计算机管理。因为我们之前已经对helpdesk人员进行加域的授权操作，按理说他们应该是可以对计算机进行加域操作。

但事与愿违，Helpdesk人员反映他们用自己的管理帐户加域时，出现错误，提示如下：

用其他有加域权限的helpdesk账号也尝试加域，依然出错。但如果用域管理员的账号则没有问题。

这个时候helpdesk人员向我们抱怨授权不成功。 我们也很郁闷，因为我们是按照微软的说明来操作的。

于是，排错的工作就此展开。

首先，我们确定其他场景下加域是否可以，经过与helpdesk人员的沟通，我们缩小 的问题的范围：如果他们用一个新的计算机名加域时，则可以顺利加域，而如果是一个旧的计算机名加域，则会出现这个问题。奇怪的是我们的其中一个同事A做了一个测试，将一台新的计算机名加域，然后再退域，用另一个helpdesk的账户加域失败，错误同上。而再用这个同事A的加域就可以。

其次，我们查找相关资料并仔细在AD控制台中查阅相关对象的权限设置，我发现一些规律：

前提操作：利用委派将kaka与Totti两个账户赋与加域的权限

1. 委派加域权限实质上就是赋与用户创建计算机对象的权限。它在Computers安全权限为【 创建计算机对象】。

2. 如果我将计算机Test19加域，用的是Totti的账户，我们会发现在computers中计算机对象test19的安全权限中有“读取、更改密码。。。”，而kaka在这个对象上的安全权限没有“读取、更改密码。。。”，只有特殊权限。

3. 然后我尝试将test19退域，再加域，此时加域时我选择用kaka的账号去加域，结果

至此，我想问题的原因已经找到：

默认委派加域权限给某个用户，此用户则拥有创建计算机对象的权限。而对已经存在的计算机对象它并没有读取与写入的权限，所以当我们尝试用这个用户将某个DC中已经存在的计算机对象的名称去加域时，会报错：access is denied。而默认当时将这个计算机对象初次加域的用户对这个计算机对象是有读取等权限的。因此，如果我们用当时将这台计算机加入域的用户再进行加域操作时，则不会报错。

最后，解决的办法：

一、将computers容器的安全权限中添加helpdesk，并给予读取的权限或更多。

二、将计算机对象删除，再让helpdesk去加域。(不推荐，因为多一步，太麻烦)

三、将helpdesk人员加入到系统内置组Account Operators(附：这个组拥有用户、组、计算机对象的完全控制权限)。