我已经将us.mycompany.local中的所有用户UPN后缀的公司名称更改为mycompany.com，以便使用声明感知的应用程序。 在更改之前的testing中，我发现即使更改了UPN后缀，用户也可以使用旧的后缀成功进行身份validation。 我不明白的是为什么这仍然有效。
Ryan和Joe上面的评论是有针对性的。 这听起来像你的用户使用他们的隐式UPNlogin。 您网域的FQDN是否为us.mycompany.local？
在Active Directory中，每个用户有两个UPN：
显式UPN（eUPN）：这是用户对象的userPrincipalName属性的值。 无论您在林中configuration了什么备用UPN后缀，都可以将其更改为任何值。
隐式UPN（iUPN）：这是通过连接用户对象的samAccountName属性的值和域的FQDN的值构造的。 FQDN以LDAP：// CN = DOMAIN_NETBIOS_NAME，CN = Partitions，CN = Configuration，DC = DOMAIN）存储的域crossRef对象的dnsRoot属性的值存储。
DS MVP的Jorge de Almeida Pinto有一系列更详细的post： https : //jorgequestforknowledge.wordpress.com/2010/10/12/user-principal-names-in-ad-part-1 https://jorgequestforknowledge.wordpress.com/2010/10/12/user-principal-names-in-ad-part-2 https://jorgequestforknowledge.wordpress.com/2010/10/12/user-principal-names -in-AD-部分3
同样值得注意的是，如果出现冲突，eUPN会“胜出”。 例如，考虑以下（虽然荒谬）的情况：
example.com user1 [email protected] 如果您尝试使用用户名[email protected]login，您将以User2身份login。 但是，如果您将User2的userPrincipalName更改为其他任何内容，您将以User1login。
更多信息每个MS： http : //support.microsoft.com/kb/929272
这可能是两件事情之一：1.新的UPN作为替代UPN被添加，而原始的UPN仍然存在。 2.旧的UPN被添加为“域名（pre-windows 2000）”，并将起作用
转到活动目录域和信任，并检查upn（s）和pre-windows设置。