查看进行集成并讨论使用用户名在AD中填充的sAMAccountName属性。
目前，如果使用该用户名检测到重复的帐户，系统将使用第一个姓氏和姓氏，例如Robert McKay将会：rmckay。创建的第一个帐户可以正常工作，但如果有第二个帐户，它将是romckay并继续沿着一个奇怪的额外字母和数字路径，强制用户的唯一性。客户端希望转移到完全数字的用户名。它现在不是rmckay而是0000001（用于登录AD连接或从AD拉出的所有内容）。
此外，还有一些系统从sAMAccountName派生他们的帐户登录和生成 - 所以即使在已经设置了AD登录的电子邮件和系统的情况下，依赖于sAMAccountName的下游系统仍然需要登录：员工ID +密码与友好用户名+密码。
此外，工作人员已经就用户友好性下降达成了共识 - 但是一个主要问题是电子邮件可能出现的问题，但是这将通过使用别名来解决。任何人都知道成功的任何地方都能够将员工ID实现为sAMAccountName，并发现最终结果是积极的（减少用户友好性？）或者可以指出可以审核分享的最佳实践？
答案 0 :(得分：1)
在我们的环境中，我们有10个域在当天分别创建，然后最终在一个林下聚集在一起。其中一个领域，他们做了类似的事情。 sAMAccountName是两个一致的字母（始终相同），后跟每个用户唯一的4位数字。
据我所知，该要求最初来自使用该用户名系统的某些大型机应用程序。我不知道细节。
近年来，我们一直在努力远离它。这毫无意义。
如果你必须这样做，请记住userPrincipalName属性，该属性也可以用于登录。所以即使sAMAccountName很糟糕，你仍然可以制作{{1}等于他们的电子邮件地址，然后用户可以使用userPrincipalName登录。他们甚至不需要知道他们userPrincipalName是什么。