Azure实例SAML Subject/NameID无法自定义，默认返回Microsoft GUID求助

检查SAML应用的NameID声明配置 #

• 登录Azure AD门户，找到目标企业应用，进入单一登录 > 用户属性与声明
• 确认NameID声明的状态：
  • 若没有该声明，手动添加：点击添加新声明，名称设为NameID，选择目标用户属性（如user.mail或user.userprincipalname），格式匹配需求（比如邮箱对应urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress）
  • 若已有NameID声明，检查源属性是否被误设为user.objectid（该属性会返回用户GUID），同时确认格式是否符合预期（你的断言中格式为persistent，这会触发Azure生成持久化GUID）

验证用户属性有效性 #

• 检查目标用户的Azure AD配置文件，确认你要用作NameID的属性（如邮箱、用户主体名）已填充有效值
• 若用户同步自本地AD，排查AD同步规则，确保目标属性未被过滤，同步过程无报错

确认服务提供方（SP）的SAML请求要求 #

• 部分SP会在SAML请求中指定NameID格式，若请求格式为urn:oasis:names:tc:SAML:2.0:nameid-format:persistent，Azure AD会优先遵循该要求返回GUID
• 可通过浏览器开发者工具抓包查看SP发起的SAML请求，检查<NameIDPolicy>节点的Format值；若需强制指定格式，可在企业应用的单一登录 > 高级设置中开启强制NameID格式，并选择所需格式

排查策略干扰 #

• 检查针对该应用的条件访问策略，确认无会话控制或其他规则修改断言内容
• 若使用自定义SAML策略（Identity Experience Framework），核对<OutputClaim>节点中NameID的配置，确保源属性未被覆盖为objectid

重置应用SAML配置 #

• 若以上步骤无效，可在企业应用的单一登录页面点击重置单一登录，重新配置用户属性与声明后再次测试

附：你提供的SAML断言片段 #

<Subject>
    <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">qAQx8T4vIpuL866RU691ifJ0gObt564JKYWuEC80_U0</NameID>
    <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData InResponseTo="id-4fef566567e33c8abc6f23f08bd4dc4f6d8cc0b"
         NotOnOrAfter="2023-06-08T21:10:15.856Z"
         Recipient="https://idp.ngrok.com/saml/edghtsrt_2Qw4TKzV0wq7bwDqMntP6WLxaFB/acs"
    </SubjectConfirmation>
</Subject>

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