我正在尝试使用 Okta 设置 AAD，并发现当用户访问 App Embed 链接并将其 SAML 响应发布到https://login.microsoftonline.com/login.srf时，他们会收到一个无用的错误：
AADSTS50107: Requested federation realm object 'http://okta.com/..............' does not exist
我已经设置了一个外部身份提供者。如何让它识别我的域？
AskOverflow.Dev
首先，确保集成实际上设置正确。要将 Okta 作为 IdP 用于来宾用户与 AAD 的入站联合，您需要在 Okta 中创建一个新的自定义应用程序：
使用具有以下设置的 SAML 2.0 登录方法创建 Web 平台应用程序：
https://login.microsoftonline.com/login.srfhttps://login.microsoftonline.com/{your AAD tenant id}/如果您停在这里，您的用户将无法登录（他们将获得一些通用访问被拒绝，具体取决于您的应用程序的部署方式），并且隐藏在登录尝试的 HTTP 记录中的是：
要解决此问题，您必须添加属性语句：
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddressUnspecifieduser.email该文档暗示您还必须添加此其他属性来告诉它用于电子邮件地址的内容，但它似乎实际上并不需要：
emailaddressUnspecifiedhttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress单击“显示高级设置”并使其看起来像这样（注意未来，检查 RSA 和 SHA256 是否仍然安全，如果可用，请更新为更好的东西）：
电子邮件地址在这里有些特殊，不一定是实际的电子邮件。为获得最佳效果，我建议使用别名域，尤其是在您已经使用 AAD 的情况下，因为以下内容。
保存您的应用程序并获取元数据文件：
在 AAD 方面，您应该在 External Identities ( https://portal.azure.com/#blade/Microsoft_AAD_IAM/CompanyRelationshipsMenuBlade/IdentityProviders )中设置您的外部 IdP 。在这一部分中，您将使用 Microsoft 登录门户注册一个电子邮件地址域，并使其尝试使用该域中的电子邮件地址登录时通过 Okta 发送用户。
有很多陷阱。它必须是当前没有人用于 AAD 的域，并且必须匹配多个规则 ( https://docs.microsoft.com/en-us/azure/active-directory/external-identities/direct-federation ) - 相关，要么你需要域名匹配被动认证端点的域名部分，要么你需要在域中设置一个TXT记录，例如
DirectFedAuthUrl=https://fabrikamconglomerate.com/adfs（其中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）中执行此操作。如果你没有它：
登录：
设置
$cert为 Base64 中的证书，不带空格或换行符：然后建立联邦：
命令中的 URI 来自与上述外部身份方法相同的位置。您确实需要指定注销 URI；我建议将 /login/signout URL 放入 Okta 或您真正想要的任何东西。
如果你得到一些错误
Set-MsolDomainAuthentication : Unable to complete this action. Try again later.，实际发生的是它拒绝了你的参数。通常是因为证书无效（您在删除所有换行符时删除了一些字符，或者没有删除空格，或者包含 ----- 标题）。或者，这是因为未指定像 LogOffUri 这样的必要参数，或者您的 MetadataExchangeUri 不起作用。cmdlet
Get-MsolDomain和Get-MsolDomainFederationSettings对检查您的工作很有用。在前者中，您应该看到您的域名身份验证从“托管”更改为“联合”。尝试在 login.microsoftonline.com 屏幕上登录的用户现在将通过 SAMLRequest 发送到 PassiveLogOnUri，以获取 SAML 断言。您仍然必须添加用户。它不会根据有效的 SAML 断言推断它们的存在。
ImmutableId 参数是来自 SAML 的不可变 ID 中的内容，不必是 UPN。如果您想使用有效电子邮件地址以外的其他内容作为 Okta 端的不可变 ID，并将其映射到 AAD 中的有效 UPN，这会很方便。
如果您可以验证您的域，这可能是更好的选择，因为如果需要（对于 B2B），您的 SP 启动的登录将在不使用租户登录 URL 的情况下工作。但是使用此选项，用户在 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。如果有一个未记录的秘密咒语让它把你送到正确的地方，我有一张向微软开放的票。您的回答@Falcon Momot 在很大程度上仍然是正确的。最后一部分，经过验证的域，对于Microsoft 文档不再有效。
我也不清楚的是，我必须在 Microsoft 登录页面上选择“登录选项”，然后选择“登录到组织”，然后提供组织-azure-domain。就在那时，我能够使用我的联合帐户登录。