我们希望提高活动目录中数据的标准化和质量。在这样做时，我们发现 ; 的格式不一致distinguishedName。CN特别是本身的格式。我们通常在一个法律实体（顶级 OU）内具有合理的（尽管从未 100%）一致性，但在这些实体中，使用了各种格式。最常见的是：
GivenName + ' ' + Surname例如“约翰·贝文”Surname + ', ' + GivenName例如“贝文，约翰”string.ToUpper(SURNAME) + ' ' + GivenName例如“贝文约翰”sAmAccountName例如“ukjlb023”
关于什么是好的格式，或者在做出这个决定时需要考虑的因素，是否有任何指导方针？
- 值应该是唯一的，因此您想要一些不太可能与现有值发生冲突的东西（例如，仅使用
givenName您必须将附加值附加到许多条目以避免除了最稀有名称之外的所有条目的冲突）。 - 不可变的值更好（例如，由于某些系统使用 DN 作为标识符，因此更改构成 DN 的一部分的 CN 可能会对访问此类系统产生连锁反应）。
- 据推测，使用有意义的名称有一个好处，因为这允许人们在不必查找其他属性的情况下确定 CN/DN 所指的帐户……但这并不重要，因为可以轻松查询此类信息。
- 该格式
Surname + ', ' + GivenName包含一个逗号，它是 中的一个特殊字符DN，因此必须进行转义。通过避免 CN 中的特殊字符，我们从而限制了软件/查询/脚本中的错误的影响（这样做还有一个缺点，因为这些错误更容易被忽视）。 - 大概有一个索引应用于该字段，因此左侧的任何内容都会对搜索性能产生更大的影响。鉴于人们比姓氏或 sAmAccountName 更有可能知道同事的名字，也许将其
givenName放在第一位会有一些小的性能优势。 - 有些人以其他名字为人所知（例如 Robert->Bob、Madeeha->Dee、Ashish->Ash / 有些人只是更喜欢用他们的中间名或完全不同的名字来称呼）。如果昵称不是真实姓名的子字符串，则通过在 CN 中包含该姓名可能会在搜索能力方面有所帮助；例如
John \"JB\" Bevan（在 DN 中需要转义字符，但在 CN 中不需要）。
我的假设是正确的，还是其中任何一个只是过度思考问题/解决方法？
还有其他需要考虑的因素吗？
注意：有一个相关的问题：https ://stackoverflow.com/questions/7814569/what-do-people-use-for-cn-with-inetorgperson-in-ldap-directories - 虽然这集中在“如何避免碰撞”讨论的一部分。
根据我的经验，没有。我见过大型组织（超过 100,000 个）随着时间的推移采用了不同的格式并且一团糟。我认为有些组织使用 givenName surName 因为这是默认设置。
大型全球组织需要记住的事情，我见过女性可能不想使用姓氏的地方，或者一半男性的名字叫穆罕默德，我见过像“s”这样的单一字符名称，或者姓氏如此很长，他们将其缩写为“M”，因此 givenName/surName 组合在西方文化中可能效果不佳。
还有收购的话题。根据获取的处理方式，最终可能会有多个目录和一个元目录，以及多种格式。用于 cn 的内容的标准化可能不是一个高优先级。或者他们可能会为随后入职的员工使用“标准”cn 格式，所以这有点混乱。
如果 samAccountName 具有标准化格式，Cn=samAccountName 可能看起来合乎逻辑。一些组织允许人们选择他们的用户名，因此如果有人选择“jj89”作为他们的用户名，它可能不会产生预期的预期结果。
一些组织根本不依赖 cn，而是使用具有存储在不同属性中的标准格式的员工 ID。
我不会担心需要转义的字符。专有名称几乎可以包含任何字符，使用 LDAP 目录的人的工作就是知道哪些字符需要转义。