如何在Active Directory中自动化RFC2307属性?

在SFU和IdMU被微软认为不被使用的情况下,如何在Active Directory中以可扩展和可靠的方式实现RFC2307属性的自动化和pipe理?而在Server 2016中将不可用?

我的目标是在Active Directory中创build用户或组时自动设置uidNumber,gidNumber,unixHomeDirectory和loginShell。 将用户添加到组时,还应将该用户添加到该组的memberUid属性中。

我已经考虑过使用自制的Powershell或者VB脚本,但是当多个pipe理员使用高可靠性要求的生产系统中的数以千计的用户使用它时,感觉并不是非常可扩展的。 我觉得这应该是一个普遍的问题,应该有好的解决办法,但是我找不到。

根据我的经验,我已经看到了两种方法。

  1. 购买一个解决scheme,可以开箱即用,成为您在AD之上的身份pipe理解决scheme。
  2. 写你自己的。

我不会发布选项1的产品build议,因为它违反了网站规则,我相信您可以对此进行自己的研究 。 但是让我来描述一下我们如何在自己的工作环境中用自己写的工具来完成这个工作

基本的前提是你应该停止创build账户,让你的工具为你做。 特别是使用您编写的工具,您可以硬编码并执行有关您的特定环境(用户位置,名称格式,自动组成员资格等)的其他工具无法知晓的业务规则。 这有使您的工具更容易使用的副作用。 从ADUC手动创build用户的人越less,您的环境就越具有一致性和可靠性。

在我们的环境中,与人有关的所有新身份都由上游的人力资源拥有系统自动configuration(并取消configuration)。 但是,这只需要处理基本的GAL相关元数据(名称,电子邮件,电话等)。 我们还在PDC模拟器DC上运行了一个PowerShell脚本,每5分钟运行一次,查找包含不完整RFC2307configuration文件的帐户,并根据需要更新它们。 它还更新组的某些子集的GID。 UID和GID是基于从帐户的SID计算它们的algorithm生成的。 人力资源系统也有可能configurationRFC2307configuration文件,但是在那时AD团队拥有这些数据/stream程的工作量不大。

此外,我们还有一个本地网页,用于configuration“非人”账户,如服务账户,共享账户,testing账户等。除了细粒度的密码策略之外,每种账户都会自动configuration适当的RFC2307属性,用户名格式约定等

在这一天结束的时候,AD只是一个巨大的LDAP服务器,有很多方法可以通过编程方式进行交互。