UserPrincipal.FindByIdentity缺省重载查询AD抛多匹配异常原因

未指定IdentityType参数的UserPrincipal.FindByIdentity重载，与显式指定IdentityType的重载底层AD查询逻辑完全不同，你遇到的MultipleMatchesException是该重载的固有设计缺陷导致，与AD中账号的唯一标识属性重复无关。

• 显式指定IdentityType的重载，底层仅构造单属性精确匹配的LDAP查询语句：
  传入IdentityType.SamAccountName时，仅生成针对sAMAccountName属性的等值匹配过滤条件；传入IdentityType.UserPrincipalName时，仅针对userPrincipalName属性做等值匹配。整个查询过程不会扫描其他属性，自然不会出现跨属性命中多个对象的情况，与你测试的结果完全吻合。Sid、Guid类型查询报错是因为传入值不符合这两类属性的格式要求，属于正常参数校验失败。
• 无IdentityType参数的重载，底层执行预置多属性OR逻辑遍历匹配，不会默认按某一个唯一标识属性做精确查询：
  该重载内置了一长串匹配属性列表，除了广为人知的sAMAccountName、userPrincipalName、Sid、Guid、distinguishedName外，还包含cn（AD对象通用名）、name（对象名）、ntAccountName（旧版域\用户名格式标识）等非强唯一属性。查询时会将传入的username值依次与列表中所有属性做等值校验，任意属性命中即判定为匹配成功。
  该逻辑的缺陷在于：遍历匹配过程中，如果在两个不同属性上分别命中两个不同的AD对象，哪怕两个对象的UPN、sAMAccountName等所有强唯一标识属性完全不重复，也会直接抛出多匹配异常。你遇到的场景本质是：两个关联账号中，一个账号的某强唯一属性（比如sAMAccountName）匹配传入值，另一个账号的某非强唯一属性（比如cn、name）刚好也和传入值一致，跨属性命中了两个对象。

• 生产环境禁止使用不带IdentityType参数的FindByIdentity重载。该重载从.NET Framework 3.5版本引入时就存在该逻辑问题，为了兼容存量程序的行为，微软从未修改过默认匹配逻辑。
• 所有AD用户查询场景都显式指定需要匹配的IdentityType，不要依赖框架的默认匹配规则。
• 如果需要实现多属性组合匹配的查询需求，直接使用DirectorySearcher自行构造LDAP过滤语句，自主控制匹配规则和结果校验逻辑，避免框架默认逻辑带来的不可预期问题。

内容的提问来源于stack exchange，提问作者planedonut