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

Question 1

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

使用 SAML 2.0 登录方法创建 Web 平台应用，设置如下：

单点登录网址：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（据我所知不是较新的）中执行此操作。如果您没有它：

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 来自同一位置。您确实需要指定注销 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 [email protected] -ImmutableId [email protected] -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。我已就此问题向 Microsoft 提交了一张票据，希望有某种未记录的秘密咒语可以让它将您发送到正确的地方。

Answer