使用AD作为通用目录

我曾在一个大的（100k +用户）环境中工作，在这个环境中，AD用来存储大量的一般员工信息 – 除了通常的电子邮件和用户\部门名称之外，我们还有多个电话号码，实际办公地点到办公室的位置），组织层次结构（为谁工作），员工号码，照片缩略图，正常时区，开始date以及其他一些我现在无法回忆的东西。

无可否认，我们在控制访问API的内部集合（以及一些授权过程，以批准访问它们的方式）中拥有相当的灵活性，允许我们控制权限的授权，以按用户/每个组的基础更新特定的AD属性，所以它是很容易将这些AD属性的更新安全地绑定到HR应用程序中，这是处理这类数据pipe理的地方。

作为一个大型组织的用户，我发现拥有这样的信息是非常有用的，并且能够通过我自己的应用程序中的简单LDAP查询来获取这类数据，而不必跳过这些环节来访问HR数据库也非常有用。

如果您使用Exchange，则允许用户在全球地址簿中查找其他人，特别是对于大型组织而言，可以提供帮助。 如果你不使用Exchange，没有一些自定义的编程可能没有太多的好处。

话虽如此，作为一个我们以前运行Exchange的小型机构，仍然运行着AD，并且除了全名和less数几个部门联系以外，从未将非login信息放入其中。

我应该补充一点，最大的障碍在于保持AD更新是IT的一个function，在许多组织中，没有一个好的过程来获取从HR到IT等通用目录的各种信息 – 通常安全性或所需的权限是新员工和更新的IT优先级。

我们使用电话信息，组织信息（由我们的人力资源系统提供）和几个extensionAttributes for misc。 东东。 从IT的angular度来看，组织信息是非常宝贵的，因为您可以快速查看您正在处理的是谁，或联系团队而不是个人。 电话信息可以使用简单的networking前端进行查询。 用户也习惯通过Outlook查看相当多的信息。 噢，组织信息也被用来根据你所在的部门dynamic地填充一些全局组。这些组被用来提供基于部门的访问。 总之，AD是一个容纳这样的东西的好地方。

我已经看到它在一个环境中用来监视什么时候使用特定的计算机作为一种员工监控系统，但是这并不像使用LDAP一样有意义。

我们把它作为一个通用的目标来处理交换，但是，出于安全的原因，我们仍然使用它与用户身份validation。 如果只是内部人员，这对我们来说就没有必要了。