我们希望提高 Active Directory 中数据的标准化和质量。在此过程中，我们发现了格式不一致的问题distinguishedName；特别是格式CN本身。我们通常在一个法人实体（顶级 OU）内具有合理的（但从未达到 100%）一致性，但在这些实体之间，使用各种格式。最常见的格式是：
GivenName + ' ' + Surname例如“John Bevan”Surname + ', ' + GivenName例如“Bevan, John”string.ToUpper(SURNAME) + ' ' + GivenName例如“BEVAN John”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- 尽管讨论的重点是“如何避免碰撞”部分。
答案1
根据我的经验，没有。我见过大型组织（超过 100,000 个）随着时间的推移采用了不同的格式，而且很乱。我认为有些组织使用 givenName surName，因为这是默认设置。
对于大型全球组织需要记住的事情，我见过一些地方，女性可能不想使用自己的姓氏，或者一半的男性都叫穆罕默德，我见过像“s”这样的单字符名称，或者姓氏太长，他们将其缩写为“M”，因此 givenName/surName 组合可能不像在西方文化中那样有效。
还有收购的话题。根据收购的处理方式，最终可能会有多个目录和一个元目录，以及多种格式。标准化 cn 的使用可能不是首要任务。或者他们可能会对随后入职的员工使用“标准”cn 格式，所以这有点像 mosh pit。
如果 samAccountName 具有标准化格式，则 Cn=samAccountName 可能看起来合乎逻辑。一些组织允许人们选择自己的用户名，因此如果有人选择“jj89”作为用户名，则可能不会产生预期的结果。
有些组织根本不依赖 cn，而是使用具有标准格式且存储在不同属性中的员工 ID。
我不会担心需要转义的字符。专有名称几乎可以包含任何字符，使用 LDAP 目录的人的工作就是知道哪些字符需要转义。