解决在 Azure 活动目录(AD) 和 Office 365 的 AD FS 问题

重要说明:本文是由 Microsoft 机器翻译软件进行的翻译并可能由 Microsoft 社区通过社区翻译机构(CTF)技术进行后期编辑,或可能是由人工进行的翻译。Microsoft 同时向您提供机器翻译、人工翻译及社区后期编辑的文章,以便对我们知识库中的所有文章以多种语言提供访问。翻译的文章可能存在词汇、句法和/或语法方面的错误。Microsoft 对由于内容的误译或客户对内容的使用所导致的任何不准确、错误或损失不承担责任。

点击这里察看该文章的英文版: 3079872
本文讨论了工作流对 Azure 活动目录(AD) 或 Office 365 中的联合用户的身份验证问题进行故障诊断。
症状
  • 联盟的用户不能登录到 Office 365 或 Microsoft Azure 即使拥有 domainxx.onmicrosoft.com UPN 后缀的托管仅云的用户可以登录不会有问题。
  • 重定向到 活动目录的联合身份验证服务 (AD FS) 或 STS 的联盟用户不会发生。或者,会触发"该页无法显示"错误。
  • 当您尝试使用 AD FS 进行身份验证时,您会收到与证书相关的警告,在浏览器上。这说明证书验证失败或证书不受信任。
  • "未知的身份验证方法"错误或错误消息指出,不支持 AuthnContext。此外,AD FS 或 STS 级错误时您将被重定向从 Office 365。
  • AD FS 引发"拒绝访问"错误。
  • AD FS 将引发错误,指出没有访问站点; 出现问题这包括引用 ID 号。
  • 反复提示用户提供凭据在 AD FS 级别。
  • 联盟的用户不能从外部网络身份验证或使用应用程序时采用的外部网络路由 (如 Outlook)。
  • 令牌签名证书更改 AD FS 上之后,联盟的用户无法登录。
  • 当联盟的用户签入在 Microsoft Azure 中的 Office 365 可以触发"对不起,但是我们在遇到您登录的问题"的错误。此错误包括错误代码 8004786 C、 80041034、 80041317、 80043431、 80048163、 80045C 06,如 8004789A 或坏请求。

故障排除的工作流
  1. 访问 https://login.microsoftonline.com然后输入该联盟的用户的登录名称 (某人@示例.com).按 tab 键以从登录框中删除焦点之后,检查是否状态的页面将变为"重定向",然后在被重定向到活动目录联合身份验证服务 (AD FS) 用于登录。

    重定向时,您将看到以下页面:

    步骤 1 的屏幕快照
    1. 如果没有重定向发生并提示您在同一页上输入的密码,这意味着,Azure 活动目录 (AD) 或 Office 365 不能识别用户或域的用户进行联合。若要检查是否存在联合身份验证信任之间 Azure 的广告或 Office 365 和 AD FS 服务器,运行 获得 msoldomain 从 Azure AD PowerShell 的 cmdlet。如果域联合,其身份验证属性会作为"联盟",如下面的屏幕快照中所示:

      对联盟域的步骤
    2. 如果重定向发生的但您无法重定向到您用于登录的 AD FS 服务器,请检查是否 IP 和它可以连接到 TCP 端口 443 上的 IP,AD FS 服务名称将解析为正确。

      如果域显示为"联盟",通过运行以下命令来获取有关联合身份验证信任的信息:
      Get-MsolFederationProperty -DomainName <domain>
      Get-MsolDomainFederationSettings -DomainName <domain>
      检查 URI、 URL 和 Office 365 或 Azure AD 配置联合身份验证伙伴的证书。
  2. 您将被重定向到 AD FS 后,浏览器可能会引发与证书信任相关的错误,并为某些客户端和设备它可能不允许您建立 SSL 会话与 AD FS。若要解决此问题,请执行以下步骤:
    1. 确保提供给客户端的 AD FS 服务通信证书是同一张在 AD FS 配置。

      有关步骤 A 的屏幕快照

      理想情况下,AD FS 服务通信证书应尝试建立 SSL 隧道的 AD FS 服务时提供给客户端的 SSL 证书相同。

      在 AD FS 2.0:

      • -> 默认第一个站点将证书绑定到 IIS。
      • 使用 AD FS 管理单元中添加相同的证书与服务通信的证书。

      在 AD FS 2012 R2:

      • 使用 AD FS 管理单元或 添加 adfscertificate 添加服务通信证书的命令。
      • 使用 一组 adfssslcertificate 若要设置相同的证书用于 SSL 绑定的命令。

    2. 请确保该 AD FS 服务通信证书受信任的客户端。
    3. 如果不 SNI 功能的客户端试图建立 2-12 R2 的 AD FS 或 WAP 与 SSL 会话,则尝试可能会失败。在这种情况下,可以考虑在 AD FS 或 WAP 服务器以支持非 SNI 客户端添加备用项。有关详细信息,请参见以下博客文章:
  3. 您可能会遇到"未知的身份验证方法"错误或错误说明时您将被重定向从 Office 365 的 AuthnContext 在 AD FS 或 STS 级别不受支持。当 Office 365 和 Azure AD 使用重定向到 AD FS 或 STS 强制执行身份验证方法的参数,这是最常见的。若要强制身份验证方法,请使用下列方法之一:
    • WS 联合身份验证使用 WAUTH 查询字符串强制首选的身份验证方法。
    • 对于 SAML2.0使用以下内容:
      <saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml:AuthnContext>
    当强制身份验证方法发送值不正确,或 AD FS 或 STS 上不支持该身份验证方法,您收到一条错误消息之前进行身份验证。

    下表显示并能识别出有关 AD FS 的 Uri 的身份验证类型 WS 联合身份验证 被动的身份验证。
    需要的身份验证方法wauth 的 URI
    用户名称和密码的身份验证urn: oasis: 姓名: tc: SAML:1.0:am:password
    SSL 客户端身份验证urn: ietf:rfc:2246
    Windows 集成身份验证urn: 联盟: 身份验证: windows

    支持 SAML 身份验证上下文类

    身份验证方法 身份验证上下文类 URI
    用户名称和密码urn: oasis: 姓名: tc: SAML:2.0:ac:classes:Password
    密码保护传输urn: oasis: 姓名: tc: SAML:2.0:ac:classes:PasswordProtectedTransport
    传输层安全性 (TLS) 客户端urn: oasis: 姓名: tc: SAML:2.0:ac:classes:TLSClient
    X.509 证书urn: oasis: 姓名: tc: SAML:2.0:ac:classes:X 509
    集成的 Windows 身份验证urn: 联盟: 身份验证: windows
    Kerberosurn: oasis: 姓名: tc: SAML:2.0:ac:classes:Kerberos

    若要确保在 AD FS 级别受支持的身份验证方法,请检查以下。

    AD FS 2.0

    在下 /adfs/ls/web.config请确保该身份验证类型的项已存在。

    <microsoft.identityServer.web></microsoft.identityServer.web>
    <localAuthenticationTypes></localAuthenticationTypes>
    添加名称 ="窗体"page="FormsSignIn.aspx"/ >
    <add name="Integrated" page="auth/integrated/"></add>
    <add name="TlsClient" page="auth/sslclient/"></add>
    <add name="Basic" page="auth/basic/"></add>


    AD FS 2.0: 如何更改本地身份验证类型

    AD FS 2012 R2

    在下 AD FS 管理请单击 身份验证策略 在 AD FS 单元中。

    在中 主的身份验证 部分中单击 编辑 下一步 全局设置.您还可以右击 身份验证策略 然后选择 编辑全局主身份验证.或者,在 操作 窗格中选择 编辑全局主身份验证.

    在中 编辑全局身份验证策略 窗口,请在 主要 选项卡上,可以配置设置为全局身份验证策略的一部分。例如,对于主身份验证,可以选择可用的身份验证方法在下 外部网内联网.

    * * 请确保选中必需的身份验证方法复选框。
  4. 如果您转到 AD FS 并输入您的凭据,但您无法进行身份验证,检查下列问题。
    1. 活动目录复制问题

      AD 复制被破坏,如果给用户或组所做的更改可能不跨域控制器同步。域控制器之间可能有密码保护,UPN, GroupMembershipProxyaddress 会影响 AD FS 响应 (身份验证和声明) 不匹配。首先应看一看与 AD FS 位于同一站点的域控制器。运行 repadmin /showrepsDCdiag /v 命令应显示 AD FS 很有可能要联系的域控制器上是否存在的问题。

      您还可以收集 AD 复制摘要,以确保广告的更改都被复制,正确地在所有域控制器。" repadmin /showrepl * /csv > showrepl.csv 输出可用于检查复制状态。有关详细信息,请参阅 活动目录(AD) 复制问题的疑难解答.
    2. 帐户锁定或禁用在 活动目录(AD) 中

      当最终用户进行身份验证通过 AD FS 时,他或她将不会收到一条错误消息,指出该帐户已锁定或禁用。从 AD FS 和登录审核,您应该能够确定是否因为身份验证失败错误的密码,帐号是否被禁用或锁定,等等。

      若要启用 AD FS 和登录审核对 AD FS 服务器,请执行以下步骤:
      1. 使用本地或域策略启用成功或失败的以下策略:
        • 审核登录事件,位于计算机配置 \windows 设置 \ 安全设置 setting\Local Policy\Audit 策略"
        • 审核对象访问,位于计算机配置 \windows 设置 \ 安全设置 setting\Local Policy\Audit 策略"
        有关策略的屏幕快照
      2. 禁用以下策略:

        审核: 强制审核策略子类别设置 (Windows Vista 或更高版本) 替代审核策略类别设置

        此策略位于计算机配置 \windows 设置 \ 安全设置 setting\Local 策略 \ 安全选项。

        有关策略的截屏

        如果您想要配置了此设置通过使用高级审核,请单击 此处.
      3. 将 AD FS 配置审核:
        1. 打开 AD FS 2.0 管理管理单元中。
        2. 操作窗格中,单击编辑联合身份验证服务属性
        3. 联合身份验证服务属性 对话框中,单击事件 选项卡。
        4. 选择成功审核 失败审核 的复选框。

          关于 sceenshot 启用 AD FS 的审核
        5. 运行 GPupdate /force 在服务器上。
    3. 未正确注册服务主体名称 (SPN)

      可能重复的 Spn 或非 AD FS 服务帐户下注册 SPN。AD FS 服务器场安装,请确保 SPN 主机/AD FSservicename 将在运行 AD FS 服务的服务帐户下。AD FS 独立设置,在运行服务 网络服务该 SPN 必须在承载 AD FS 服务器计算机帐户下。

      AD FS 服务名称的屏幕快照

      确保没有重复的 Spn,AD FS 服务,因为这可能会导致 AD FS 间歇性身份验证失败。若要列出了 Spn,请运行 SETSPN – L<ServiceAccount></ServiceAccount>.

      关于列表 SPN 的屏幕快照

      运行 SETSPN – 主机/AD FSservicename ServiceAccount 若要添加 SPN。

      运行 SETSPN – X-F 检查重复的 Spn。
    4. 在 活动目录(AD) 中的重复 Upn

      用户可以在使用它们时,AD FS 通过身份验证 SAMAccountName 但不能进行身份验证时使用 UPN。在这种情况下,Active Directory 可能包含两个用户具有相同的 UPN。结尾时添加和修改用户具有相同的 UPN 的两个用户,可以通过脚本 (adsi 编辑)。

      使用 UPN 时进行身份验证,在此情况下,为防止重复的用户验证该用户。因此,不会验证所提供的凭据。

      可以使用类似以下的查询来检查是否有在广告中多个具有相同属性值的对象:
      Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN

      确保,在重复的用户的 UPN 被重命名,以便与 UPN 的身份验证请求验证正确的对象。
    5. 在方案中,其中使用您的电子邮件地址作为 Office 365 中的登录 ID,您重定向到 AD FS 进行身份验证时输入的相同的电子邮件地址验证可能会失败的审核日志中的"NO_SUCH_USER"错误。若要启用 AD FS,若要使用 UPN 或 SAMaccountname 以外的其他属性来查找用户进行身份验证,您必须配置 AD FS 支持替代登录 id。有关详细信息,请参阅 配置备用的登录 ID.

      在 AD FS 2012 R2

      1. 设置 更新 2919355.
      2. 通过运行以下 PowerShell 命令 联合服务器场中的任何更新 AD FS 配置 (如果有 WID 场,您必须运行此命令在主 AD FS 服务器场中):

        组-AdfsClaimsProviderTrust-TargetIdentifier"广告机构"-AlternateLoginID <attribute>-LookupForests <forest domain=""></forest> </attribute>

        注意:AlternateLoginID 是您想要将用于登录属性的 LDAP 名称。和 LookupForests 是林用户属于的 DNS 条目的列表。

        若要启用替代登录 ID 功能,必须配置两个 AlternateLoginIDLookupForests 具有一个非空的、 有效的值的参数。

    6. AD FS 服务帐户没有签署证书的专用密钥的 AD FS 标记的读取访问权限。若要添加此权限,请执行以下步骤:
      1. 当添加新的令牌签名证书时,您会收到下面的警告:"确保选定证书的专用密钥被访问到此联合身份验证服务的服务器场中每台服务器上的服务帐户。
      2. 单击开始,单击运行,类型 mmc.exe然后按 enter 键。
      3. 单击文件,然后单击添加/删除管理单元中
      4. 双击证书
      5. 选择问题中,计算机帐户,然后单击下一步
      6. 选择本地计算机,然后单击完成
      7. 展开证书 (本地计算机) 角色l,然后选择证书
      8. 用鼠标右键单击您的新令牌签名证书,选择所有任务,然后选择管理私钥

        有关步骤 8 sceenshot
      9. 添加您的 AD FS 2.0 服务帐户的读访问权限,然后单击确定
      10. 关闭证书 MMC。
    7. AD FS 或 LS 虚拟目录启用 Windows 身份验证的扩展保护选项。特定的浏览器,这可能会导致问题。有时,您可能会看到重复提示输入凭据,AD FS,这可能与 扩展的保护 AD FS 或 LS 应用程序在 IIS 中启用 Windows 身份验证的设置。

      有关步骤 8 sceenshot
      扩展的保护 对于启用了身份验证,身份验证请求绑定到这两个服务主体名称 (Spn 的服务器到该客户端尝试连接到外部传输层安全 (TLS) 通道集成 Windows 身份验证对其发生)。扩展的保护,增强了现有的 Windows 身份验证功能,以减少身份验证中继或"中间人"攻击。但是,某些浏览器不能使用 扩展的保护 设置;相反他们反复提示输入凭据,然后又拒绝访问。禁用 扩展的保护 帮助是这种情况。

      有关详细信息,请参阅 AD FS 2.0: 不断提示您输入凭据时使用 Fiddler web 调试程序.

      AD FS 2012 r2

      运行以下 命令 以禁用 Extendedprotection:

      一组 ADFSProperties — ExtendedProtectionTokenCheck 无

    8. 在信赖方 (RP) 信任颁发授权规则可能会拒绝用户访问。在 AD FS 配置成信赖方信任,您可以配置控件是否已经过身份验证的用户应发出一个标记为信赖方颁发授权规则。管理员可以使用颁发决定是否拒绝访问权限的用户是已上移至超类索赔作为组的成员的声明。

      如果某些联盟的用户无法验证通过 AD FS 中,可能需要检查 Office 365 RP 颁发授权规则并查看是否 允许所有用户访问 配置规则。

      有关规则的截屏
      如果不配置此规则,细读来检查是否在该规则中的条件计算为"true"为受影响的用户自定义的授权规则。有关详细信息,请参阅以下资源:
      如果您的 AD FS 服务器直接访问,但当您访问 AD FS 通过 AD FS 代理无法验证时,可以验证从 intranet,检查以下问题:
      • 在 AD FS 服务器和 AD FS 代理服务器上的时间同步问题

        请确保 AD FS 服务器上的时间,并在代理服务器上的时间同步。通过在域控制器上的时间超过五分钟,AD FS 服务器上的时间处于关闭状态,会发生身份验证失败。当 AD FS 代理服务器上的时间不同步与 AD FS 中时,代理信任是影响和破坏。因此,从 AD FS 代理的请求就会失败。
      • 检查 AD FS 代理信任与 AD FS 服务是否工作正常。如果您怀疑代理信任被破坏,请重新运行代理服务器配置。
  5. AD FS 颁发令牌,Azure 广告或 Office 365 引发一个错误之后。在此情况下,请检查下列问题:
    • 颁发的令牌中的 AD FS 声明应在 Azure 的广告匹配的用户各自的属性。在 Azure AD 的标记或 Office 365 提供以下理赔所需。

      WSFED:
      UPN: 此声明的值应符合 Azure AD 中用户的 UPN。
      ImmutableID: 此声明的值应与匹配 sourceAnchor 或 ImmutableID 的用户,在 Azure 的广告。

      Azure AD 中获取用户的属性值,请运行下面的命令行: 获得 MsolUser – 范围内<UPN></UPN>

      SAML 2.0:
      IDPEmail: 此声明的值应符合 Azure AD 中的用户的用户主体名称。
      NAMEID: 此声明的值应与匹配 sourceAnchor 或 ImmutableID 的用户,在 Azure 的广告。

      有关详细信息,请参阅 使用 SAML 2.0 身份标识提供程序来实现单一登录。

      示例:
      同步用户的 UPN 做广告,但不会更新在线目录发生更改时,会出现此问题。在这种情况下,您可以要么更正用户的 UPN AD (以匹配相关的用户的登录名) 中或运行以下 命令 以更改联机目录中相关的用户的登录名:

      设置 MsolUserPrincipalName 的范围内 [ExistingUPN] NewUserPrincipalName [DomainUPN-AD]

      它也可能是您正在使用 AADsync 进行同步 作为 UPN 邮件作为 SourceAnchor EMPID但声称没有更新 AD FS 级别的规则发送信赖方 作为 UPN 邮件作为 ImmutableID EMPID.
    • 还有的令牌签名证书不匹配 AD FS 和 Office 365。

      这是最常见的问题之一。AD FS 使用令牌签名证书进行签名发送给用户或应用程序的标记。AD FS 和 Office 365 之间的信任是基于此令牌签名证书联合的信任 (例如,Office 365 验证收到的令牌已被使用令牌签名证书的信任声明提供程序 [AD FS 服务])。

      如果 AD FS 的令牌签名证书自动证书翻转或由管理员的干预 (后或更改证书到期之前),新证书的详细信息必须更新 Office 365 的联盟域的组织。

      Office 365 或 Azure 广告将尝试到达的 AD FS 服务,提供来自公共网络的访问。我们尝试 ADFS 的联合身份验证元数据定期轮询,拉 ADFS,主要令牌签名证书的任何配置更改。如果不使用此过程,全局管理员应该看到通知在 Office 365 门户,警告有关的令牌签名证书到期时间和动作来服用,以对其进行更新。

      您可以使用 获得 MsolFederationProperty 域名<domain></domain> 转储 AD FS 和 Office 365 的联合身份验证属性。在此处您可以比较 TokenSigningCertificate 指纹,以检查您的联盟域的 Office 365 租户配置是否与 AD FS 同步。如果找到匹配的令牌签名证书配置中,运行下面的命令来更新它:
      Update-MsolFederatedDomain -DomainName <domain> -SupportMultipleDomain
      您还可以运行以下工具计划上的 AD FS 服务器的令牌签名证书并更新 Office 365 租户自动自动证书翻转将监视任务。

      Microsoft Office 365 联合元数据更新自动化安装工具

      验证和单一登录使用 AD FS 管理
    • Office 365 RP 颁发转换声明规则配置不正确。

      在您拥有多个 Tld (顶级域) 的情况下,您可能必须登录问题如果 Supportmultipledomain RP 信任已创建和更新时没有使用开关。有关详细信息,请单击 此处.
    • 请确保该令牌加密 正在使用 AD FS 或 STS 到 Azure 广告或 Office 365 颁发令牌时。
  6. 有陈旧的缓存的凭据 Windows 凭据管理器中。

    有时在登录期间中从工作站到门户网站 (或使用 Outlook 时),则会提示用户提供凭据,凭据可能保存为 Windows 凭据管理器 (控制 Panel\User Accounts\Credential 管理器) 中的目标 (Office 365 或 AD FS 服务)。这有助避免一些时间,提示输入凭据,但之后更改了用户密码,并且不会更新凭据管理器可能会导致问题。在该方案中,陈旧的凭据发送到 AD FS 服务,因此身份验证失败。删除或更新缓存的凭据,Windows 凭据管理器中有所帮助。
  7. 请确保配置信赖方信任为 Office 365 的安全哈希算法,被设置为 SHA1。

    在 STS/AD FS 和 Azure AD/Office 365 之间的信任使用 SAML 2.0 协议,配置为数字签名安全哈希算法应当是 SHA1。
  8. 如果上述原因的任何适用于您的具体情况,使用 Microsoft 创建一个支持案例,要求他们检查是否用户帐户以一致的方式显示在 Office 365 租户。有关详细信息,请参阅以下资源:

    从 AD FS 2.0 时联合的用户登录到 Office 365 的错误消息:"没有访问该站点时出现问题"

    联合是反复提示用户提供凭据时他或她在 Office 365 登录期间连接的 AD FS 2.0 服务终结点
  9. 这取决于 (与 Azure AD 集成) 的云服务访问,身份验证请求发送到 AD FS 可能会有所不同。例如: 某些请求可能包括其他参数,如 WauthWfresh这些参数可能会导致 AD FS 级别不同的行为。

    我们建议的 AD FS 二进制文件始终保存已更新以包括有关已知问题的修复程序。有关最新的更新程序的详细信息,请参阅下表。

属性

文章 ID:3079872 - 上次审阅时间:08/12/2015 04:20:00 - 修订版本: 2.0

Windows Server 2008 Datacenter, Windows Server 2008 Enterprise, Windows Server 2008 Foundation, Windows Server 2008 Standard, Windows Server 2008 R2 Datacenter, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Foundation, Windows Server 2008 R2 Standard, Windows Server 2012 Foundation, Windows Server 2012 Essentials, Windows Server 2012 Datacenter, Windows Server 2012 Standard, Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Essentials, Windows Server 2012 R2 Foundation, Windows Server 2012 R2 Standard

  • kbmt KB3079872 KbMtzh
反馈