AADSTS50107：将 Okta 集成为 AAD 的 IdP 时，请求的联合领域对象不存在

Question

我尝试使用 Okta 设置 AAD，发现当用户访问 App Embed 链接并将其 SAML 响应发布到https://login.microsoftonline.com/login.srf时，他们会收到无用的错误：

AADSTS50107: Requested federation realm object 'http://okta.com/..............' does not exist

我已经设置了一个外部身份提供商。如何让它识别我的域名？

Answer 1

首先，确保集成设置正确。要将 Okta 用作来宾用户 AAD 入站联合的 IdP，您需要在 Okta 中创建一个新的自定义应用程序：

使用 SAML 2.0 登录方法和以下设置创建 Web 平台应用程序：

• 单点登录 URL：https://login.microsoftonline.com/login.srf
• 将其用于收件人 URL 和目标 URL：是
• 受众 URI（SP 实体 ID）：https://login.microsoftonline.com/{your AAD tenant id}/
• 默认 RelayState：将此留空，但可以在此处放置一些内容来创建智能链接
• 姓名 ID 格式：未指定
• 应用程序用户名：电子邮件（如果您的 okta 用户名是电子邮件，则为 okta 用户名）

如果您停在这里，您的用户将无法登录（根据您的应用程序的部署方式，他们将获得一些通用访问被拒绝），并且隐藏在登录尝试的 HTTP 记录中的内容如下：

AADSTS5000819: SAML Assertion is invalid. Email address claim is missing or does not match domain from an external realm.

要解决此问题，您必须添加属性声明：

• 姓名：http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
• 名称格式：Unspecified
• 价值：user.email

该文档暗示您还必须添加此其他属性来告诉它用于电子邮件地址的内容，但实际上似乎并不需要：

• 姓名：emailaddress
• 名称格式：Unspecified
• 价值：http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

单击“显示高级设置”并使其看起来像这样（请注意，将来，请检查 RSA 和 SHA256 是否仍然安全，如果可用，请更新为更好的设置）：

电子邮件地址在这里有些特殊，不一定是实际的电子邮件。为了获得最佳结果，我建议使用别名域，特别是如果您已经使用 AAD，原因如下。

保存您的应用程序并获取元数据文件：

在 AAD 方面，您应该在外部身份中设置外部 IdP ( https://portal.azure.com/#blade/Microsoft_AAD_IAM/CompanyRelationshipsMenuBlade/IdentityProviders )。在此部分中，您将向 Microsoft 登录门户注册一个电子邮件地址域，并进行设置，以便尝试使用该域中的电子邮件地址登录的用户将通过 Okta 发送。

有很多陷阱。它必须是当前没有人用于 AAD 的域，并且必须匹配多个规则 ( https://docs.microsoft.com/en-us/azure/active-directory/external-identities/direct-federation ) - 相关，要么需要域名与被动身份验证端点的域名部分相匹配，要么需要在域中设置 TXT 记录DirectFedAuthUrl=https://fabrikamconglomerate.com/adfs（其中 URL 与您在“被动身份验证端点”中配置的 URL 相同） ”）。

如果您确实有经过验证的域，您仍然可以将其用于联合而不删除它，但不能同时管理同一个域（AAD 是记录系统）和联合域（Okta 是记录系统），因为用户之间会发生冲突。您必须使用 powershell 来设置它。见下文。

创建一个 SAML 身份提供商，并将“联合 IdP 的域名”设置为您希望用户用于登录的域名。

从您的文件加载元数据。颁发者 URI 应类似于“http://www.okta.com/exkoMK3x9R3njKrTag24”。

设置元数据端点 URL，否则当证书过期时，您的集成将在大约 10 年后神秘地停止工作。该 URL 与您之前单击链接以获取元数据文件的 URL 相同。

您的用户访问您的应用程序（直接通过应用服务的 URL 或其他方式，而不是通过 Okta 的被动身份验证端点），并将他们重定向到 Microsoft 帐户登录页面。他们输入电子邮件，域名是您在“联合 IdP 的域名”中设置的域名。他们通过 Okta 发送，在那里登录，然后被重定向回来。

他们可能会收到“AADSTS50020：来自身份提供商的用户帐户...在租户中不存在...并且无法访问该租户中的应用程序...。需要将该帐户添加为外部用户首先是租户。注销并使用不同的 Azure Active Directory 用户帐户再次登录”。发生这种情况是因为您需要以某种方式配置它们，因为 AAD 不会从证明其身份的初始入站 SAML 推断它们的存在。

令人恼火的是，您无法启用用户流以通过 SAML IdP 进行自助注册（目前仅允许 Microsoft 帐户和其他 AAD 实例使用）。因此，目前，对于每个用户，您必须邀请他们作为 AAD 实例中的来宾用户（https://portal.azure.com/#blade/Microsoft_AAD_IAM/UsersManagementMenuBlade/MsGraphUsers并选择“新来宾用户”）。当您邀请他们时，您可以为他们提供使用您环境中的内容所需的任何应用程序访问权限和 AAD 组。使用他们在 Microsoft 登录提示时输入的电子邮件地址。

他们第一次登录时，将通过同意流程发送。谨防; 如果您在 AAD 中启用了“安全默认设置”，即使他们已经在 Okta 中通过 MFA 进行了身份验证，也会要求他们设置 Microsoft Authenticator。

就是这样！现在，您的用户可以通过 Okta 发送，而无需为 AAD 环境提供额外的密码。

如果您有经过验证的域，并且没有任何用户需要使用它来使用 AAD 作为 IdP 进行登录，则可以将其用于联合，而且更简单 - 您不必邀请来宾用户并让他们接受邀请。但你必须使用powershell。我认为您可能仍然需要已弃用的 MSOnline 模块来执行此操作，因此您必须在 Powershell 5（不是较新的 afaik）中执行此操作。如果您没有：

install-module -name MSOnline -Scope CurrentUser

登录：

Connect-MsolService

设置$cert为 Base64 格式的证书，不带空格或换行符：

$cert = "MIIDq..........."

然后建立联邦：

Set-MsolDomainAuthentication
    -DomainName example.net \
    -FederationBrandName "Example.net Okta Users"
    -Authentication Federated
    -PreferredAuthenticationProtocol Samlp
    -SigningCertificate $cert
    -MetadataExchangeUri "https://okta.example.net/app/xxxxxxxxxxxxxxxxxxxx/sso/saml/metadata"
    -PassiveLogOnUri "https://okta.example.net/app/dev-99999999_applicationname/xxxxxxxxxxxxxxxxxxxx/sso/saml"
    -IssuerUri "http://www.okta.com/xxxxxxxxxxxxxxxxxxxx"
    -LogOffUri "https://okta.example.net/login/signout"

命令中的 URI 来自您为上述外部身份方法获取它们的同一位置。您确实需要指定注销 URI；我建议输入 Okta 的 /login/signout URL 或您真正想要的任何内容。

如果您收到一些错误Set-MsolDomainAuthentication : Unable to complete this action. Try again later.，实际发生的情况是它拒绝了您的参数。通常是因为证书无效（您可能在删除所有换行符时删除了一些字符，或者没有删除空格，或者包含 ----- 标头）。或者，这是因为未指定 LogOffUri 等必要参数，或者您的 MetadataExchangeUri 不起作用。

cmdletGet-MsolDomain和Get-MsolDomainFederationSettings对于检查您的工作很有用。在前者中，您应该看到域名的身份验证从“托管”更改为“联合”。尝试在 login.microsoftonline.com 屏幕登录的用户现在将被发送到带有 SAMLRequest 的 PassiveLogOnUri 以获取 SAML 断言。

您仍然必须添加用户。它不会根据有效的 SAML 断言推断它们的存在。

New-MsolUser -UserPrincipalName someone@example.net -ImmutableId someone@example.net -DisplayName "Test User" -UsageLocation US

ImmutableId 参数是来自 SAML 的不可变 ID 中的内容，不一定是 UPN。如果您想使用有效电子邮件地址以外的其他内容作为 Okta 端的不可变 ID，并将其映射到 AAD 中的有效 UPN，这会很方便。

如果您可以验证您的域，这可能是更好的选择，因为这样您的 SP 发起的登录就可以在不需要使用租户登录 URL 的情况下工作（对于 B2B）。但使用此选项时，用户在 AAD 中将作为普通用户，而不是 B2B 来宾用户。如果您使用它，则AADSTS50107: Requested federation realm object does not exist, when integrating Okta as an IdP for AAD不应出现该错误。为什么？如果您正在进行 B2B，它只会在它认为用户正在登录的租户中查找颁发者（“联合领域对象”）。如果您使用经过验证的域，则您是 AAD 中该域的唯一用户，因此不会有任何歧义，它只能查找要使用的适当的 AAD 租户。

不幸的是，此方法也不允许您执行 IdP 发起的登录。它具有不同的故障模式：它会丢弃您的 RelayState 参数并仅将用户发送到位于 的 Office 365 门户https://www.office.com/?auth=2&home=1。我已经向微软开出了一张关于此事的票，万一有一个未记录的秘密咒语可以让它把你带到正确的地方。