Active Directory用户对象包含许多可被视为标识符的字段。 以下列出了其中一些在ADUC中的标签及其属性名称：
我试图让我们的开发人员在编写用AD进行身份validation的自定义代码时仅使用其中的一个来标准化 – 麻烦是我不确定哪一个是“正确的”，或者如果不同的是正确的情况。 我甚至不确定任何上述领域应该使用！
有没有其他人select使用consistanly，什么影响你在这个决定？ 任何澄清问题的文件？
CN（通用名称）不适合login，因为CN本身不能唯一标识用户。 我可以有一个
CN=Ryan Ries,OU=Dallas,DC=Domain,DC=com
我也可以有一个
CN=Ryan Ries,OU=New York,DC=Domain,DC=com
用户的CN也是RDN（相对可分辨名称）。它们具有相同的CN，但具有不同的DN。 您可能会注意到，如果您的组织中有两个名为Ryan Ries的组织，那么您将遇到问题，并且必须为第二个组织创build类似rries2的SamAccountName。
DN（专有名称）不好login，因为谁想用CN=ryan,OU=Texas,DC=brazzers,DC=com等用户名login系统。 虽然使用DN能够唯一确定用户身份，但是必须input才是烦人的。 这是文件系统上相对path和绝对path之间的相同概念。 这也意味着你确切地知道对象在目录结构中的什么位置，而不必search它。 你通常不会。
这称为不明确的名称parsing（ANR） – 当您没有他或她的可分辨名称时，在用户的目录中search。
UPN（用户主体名称）非常好，因为它们看起来像电子邮件地址，它们可以与用户的公司电子邮件地址相同，它们很容易记住，并且首选login，因为名称将被search先在本地域中，然后在森林中search。
微软表示：UPN的重点是整合电子邮件和login名称空间，以便用户只需要记住一个名字。 UPN是Windows用户的首选login名称。 用户应该使用他们的UPNlogin到域。 在login时，首先通过search本地域，然后search全局编录来validationUPN。 未能在本地域或GC中findUPN会导致拒绝UPN。 在创build用户帐户时可以分配UPN， 但不是必需的 。
请记住，在devise应用程序时，最后“不需要”一点。
SamAccountName也很好，因为SamAccountName对于域中的每个人（而不是森林）都是唯一的。另外，SamAccountNames也很简短。 大多数人都使用SamAccountNameslogin，即使他们没有在AD森林中唯一标识您，这就是为什么您必须指定一个域名以与您的SamAccountName一起使用，以便系统知道您尝试login的域。
以下是关于这个问题的一些很好的文档供进一步阅读：
http://msdn.microsoft.com/en-us/library/windows/desktop/ms677605(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx
如果您将用户名称称为某人input以进行login的内容，那么我会build议将sAMAccountName （与域名结合使用）或userPrincipalName （在林中将是唯一的）。
至于用户名作为唯一标识符，Windows使用所有访问控制条目的SID，并提供从用户名转换为SID的一整套方法。 SID匹配用户隐喻的一个帐户的生命周期，因为重命名和移动域内没有任何效果，但删除并重新创build一个新的SID结果。
为此，我将调用LookupAccountName ，它接受一个表示用户名的string，并返回用户所在域的sAMAccountName ， SID和域名。
用户可以使用Windows支持的任何语法来login，不需要额外的培训。
我build议允许用户select他想使用的名称的格式，并在应用程序端确定用户的input。 例如：如果用户键入：[email protected] – 将其视为UPN并在AD中searchUPN。 如果用户键入：username – 将其视为预定义默认域的samAccountName，当然如果用户inputdomain \ username – 将其视为来自指定域的samAccountName。 总是检索用户的SID并将所有权限分配给SID，因为人们结婚并且用户名可以更改。