通过Graph创建的Azure AD联合用户无法使用指定IssuerAssignedId邮箱登录

当前配置的核心问题 #

• 创建用户时完全没有显式给UserPrincipalName字段赋值，按照Azure AD的默认规则，创建请求中未传入该字段时，系统会自动生成objectId为前缀、租户onmicrosoft.com为后缀的随机UPN，这就是你现在只能用自动生成UPN登录的直接原因。
• 混用了两类完全互斥的身份配置：既给用户挂了SignInType = "federated"的联合身份标识，又设置了本地托管的PasswordProfile。Azure AD的规则里，federated类型的Identities是用来对接外部身份提供商的映射标识，本身不具备本地登录名属性；纯联合账号的密码校验完全由外部IdP完成，Azure AD不会对这类账号存储或校验本地密码。这种混配场景下，系统只会把自动生成的托管域UPN作为有效登录入口，你在Identities里填的abc@myOrganizatinName.com.au根本不会被纳入登录名的校验范围。
• 你将备用邮箱放在OtherMails字段中，这个字段仅用于存储联系用途的备用邮箱地址，和Azure AD的登录名体系没有任何映射关系，自然不会被识别为登录账号。

不同目标场景的正确配置方式 #

场景1：需要用自定义邮箱作为登录名、直接用配置的本地密码登录（不对接外部IdP） #

这是绝大多数场景的实际需求，需要按以下规则调整代码和租户配置：

• 先确认自定义域名myOrganizatinName.com.au已经在Azure AD租户的自定义域名列表中完成所有权验证，且域类型为托管
• 创建用户时必须显式将UserPrincipalName赋值为目标登录邮箱abc@myOrganizatinName.com.au，不能依赖系统自动生成UPN
• 将Identities里的SignInType从federated改为emailAddress，只有这个类型的标识才会被Azure AD纳入多登录名的校验范围
• 保留原本的PasswordProfile和PasswordPolicies配置，托管域的本地密码逻辑可正常生效
• 在租户级设置里打开「允许用户使用电子邮件地址登录」的开关，开启后不管是UPN本身还是对应的email类型Identities，都可以作为有效登录名

对应的正确代码片段：

var user = new Microsoft.Graph.User
{
    // 必须显式设置UPN，这是原代码的核心缺失项
    UserPrincipalName = "abc@myOrganizatinName.com.au",
    DisplayName = "John Doe",
    Identities = new List<ObjectIdentity>()
    {
        new ObjectIdentity()
        {
            SignInType = "emailAddress",
            Issuer = "myOrganizatinName.com.au",
            IssuerAssignedId = "abc@myOrganizatinName.com.au"
        }
    },
    PasswordProfile = new Microsoft.Graph.PasswordProfile
    {
        Password = "Officework1",
        ForceChangePasswordNextSignIn = false
    },
    PasswordPolicies = "DisablePasswordExpiration",
    OtherMails = new List<string>()
    {
        "JohnDoe@gmail.com"
    }
};

场景2：确实需要搭建联合身份账号（登录时跳转外部IdP认证，不使用Azure AD本地密码） #

如果目标是对接自有IdP完成联合登录，需要调整以下配置：

• 把myOrganizatinName.com.au在Azure AD的域类型从「托管」改为联合，完成域的联合信任配置（配置IdP的签名证书、登录端点、登出端点等）
• 从用户创建配置里删掉PasswordProfile和PasswordPolicies相关代码，纯联合账号不支持本地密码校验，这类配置不会生效
• 必须显式设置UserPrincipalName为abc@myOrganizatinName.com.au，系统不会为联合域的账号自动生成onmicrosoft后缀的UPN
• 保持Identities里的SignInType = "federated"配置不变，作为外部IdP和Azure AD用户主体的映射标识

常见踩坑提醒 #

• 不要指望只在Identities里塞自定义邮箱、不设置UserPrincipalName就能实现自定义邮箱登录，Azure AD的登录校验永远会优先校验已显式设置的UPN，未显式设置的情况下，系统自动生成的UPN是唯一的有效托管域登录名
• federated类型的Identities本质是跨身份系统的映射键，不是登录名，和emailAddress、userName类型的Identities的生效逻辑完全不同，不要混用
• 已经创建完成的存量用户不需要重新新建，只需要调用Graph API的用户更新接口，补上正确的UserPrincipalName、调整Identities的SignInType类型，就能让自定义邮箱成为有效登录名，不需要删除原用户。

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