AADSTS50107：將 Okta 集成為 AAD 的 IdP 時，請求的聯合領域對像不存在

我正在嘗試使用 Okta 設置 AAD，並發現當使用者訪問 App Embed 連結並將其 SAML 響應發佈到https://login.microsoftonline.com/login.srf時，他們會收到一個無用的錯誤：

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

我已經設置了一個外部身份提供者。如何讓它辨識我的域？

首先，確保集成實際上設置正確。要將 Okta 作為 IdP 用於來賓使用者與 AAD 的入站聯合，您需要在 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 方面，您應該在 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）中執行此操作。如果你沒有它：

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；我建議將 /login/signout URL 放入 Okta 或您真正想要的任何東西。

如果你得到一些錯誤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，這會很方便。

如果您可以驗證您的域，這可能是更好的選擇，因為如果需要（對於 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。如果有一個未記錄的秘密咒語讓它把你送到正確的地方，我有一張向微軟開放的票。

引用自：https://serverfault.com/questions/1062333