【问题标题】:Authenticating Sharepoint 2013 on-premise with Azure AD使用 Azure AD 在本地对 Sharepoint 2013 进行身份验证
【发布时间】:2018-01-11 11:18:23
【问题描述】:

我们的客户有一个 Azure AD,其中包含其公司位于全球多个位置的所有用户。他希望他的用户能够使用 Azure AD 上的 Microsoft 帐户登录我们的 SP 应用。

显然,由于 Azure AD 使用 SAML 2.0,而 SharePoint 使用 Ws-Fed(类似于 SAML 1.1),我们需要将这些声明从 2.0 转换为 Ws-Fed(或 SAML 1.1)。

这曾经是使用 Azure 的 Azure 控制服务完成的,该服务将在今年年底(2018 年)被弃用,因此开发使用它的解决方案毫无意义。

因此,我们找到了许多指南 herehere,其中详细说明了如何在 Azure AD 和 ADFS 之间创建声明提供者信任,以及如何在 AD FS 和 SharePoint 之间设置依赖方信任。

理论上,这通过以下方式起作用:

  1. 用户登录到他在 Azure AD 上的 Microsoft 帐户,带有声明的 SAML 2.0 令牌从 Azure AD 发送到 AD FS
  2. 所有声明都传递给 AD FS,因为我们以这种方式配置了我们的规则(按照指示 here
  3. AD FS 将这些从 SAML 2.0 转换为 Ws-Fed(或 SAML 1.1)
  4. AD FS 将必要的声明映射到 UPN(按照指示 here)并将结果发送到 SharePoint

我们似乎在转换步骤中遇到了问题。 我们已经使用 Fiddler 调试了该过程,以查看进出 AD FS 服务器的请求。 Azure AD 声明已成功发送到 AD FS,但在 AD FS 发出新声明时遇到错误(假设在 Ws-Fed 或 SAML 1.1 中)。

以下是 AD FS 的堆栈跟踪:

Microsoft.IdentityServer.Web.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. ---> System.ServiceModel.FaultException: MSIS3127: The specified request failed.
   at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
   at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
   --- End of inner exception stack trace ---
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, UInt32 lifetime, Uri& replyTo)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, MSISSession& session)
  at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSerializedToken(String signOnToken, WSFederationMessage incomingMessage)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseForProtocolResponse(FederationPassiveContext federationPassiveContext)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponse(FederationPassiveContext federationPassiveContext, SecurityToken securityToken)

System.ServiceModel.FaultException: MSIS3127: The specified request failed.
   at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
   at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)

我们还进行了内部测试,我们使用本地 AD 登录到 SharePoint 站点,以确保 AD FS 和 SharePoint 之间的设置正确。这按预期工作,SharePoint 收到了步骤 4 中配置的声明。

对于从 SAML 2.0 到 Ws-Fed(或 SAML 1.1)的“转换”过程的任何帮助,我们将不胜感激。

帮助我欧比旺克诺比,你是我唯一的希望!

【问题讨论】:

    标签: azure sharepoint-2013 azure-active-directory saml-2.0 adfs


    【解决方案1】:

    将 AD FS 的 PreventTokenReplays 参数设置为 false

    在我们的案例中,这就是我们困了好几天的原因。我们阅读的任何地方都没有提到这一点,我们只是在转到 AD FS 服务器的事件查看器并查看日志后才发现它。

    打开 PowerShell,并使用以下命令添加 AD FS 管理单元:

    Add-PSSnapin Microsoft.Adfs.PowerShell

    然后,使用以下命令获取您的 AD FS 属性:

    Get-adfsproperties

    检查 PreventTokenReplays 参数的值。如果它设置为false,你应该很好。如果设置为 true,则使用以下命令将其翻转为 false:

    Set-adfsproperties -PreventTokenReplays $false

    现在,您需要重新启动 AD FS 服务。只需转到 services.msc,找到 AD FS 2.0 Windows 服务,右键单击它,然后点击重新启动。

    【讨论】:

      【解决方案2】:

      配置概览 创建新的 Azure AD 租户和命名空间。 添加 WS-Federation 身份提供者。 将 SharePoint 添加为信赖方应用程序。 为基于声明的身份验证创建规则组。 配置 X.509 证书。 创建声明映射。 为新的身份提供者配置 SharePoint。 设置权限。 验证新的提供者

      你可以关注这个博客一步一步的过程 https://www.sharepointcollabs.com/2017/03/using-microsoft-azure-active-directory.html

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2017-08-06
        • 2019-05-29
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2020-01-14
        • 2015-07-22
        • 2017-04-08
        相关资源
        最近更新 更多