
我們有一位客戶具有以下設定。
具有 Azure AD Connect 和密碼雜湊同步 (PHS)(包括 SSO 啟動)的 onPrem Active Directory
適用於所有 M365 應用程式的 SSO
整合約 15 個不同的外部雲端應用程序,這些應用程式信任與 Azure 的關係,以便在瀏覽器中使用 SSO
現在,客戶希望遷移到 ADFS 身份驗證,以便將來對其所有應用程式使用 onPrem MFA 解決方案。那麼,如果我們將 Azure AD Connect 中的「使用者登入」方法變更為 PHS(包括 PHS),會發生什麼情況? SSO 到「ADFS 聯合」?我找到了以下帖子:混合 ADFS 和 Azure AD 進行驗證 - Microsoft 問答其中使用者「amanpreetsingh-msft」描述了通訊流程。但由於我們的設定略有不同,我不確定這種通訊流程是否也適用於我們。 SSO 仍然會自動運作嗎?對於兩種不同的 SSO 方法:“PRT SSO”和“無縫 SSO”,我們需要考慮什麼。我們目前不知道客戶使用什麼類型的 SSO。
我還發現了以下通信流程:單一登入2 但它並沒有完全涵蓋我們的設置。因為我們不會將任何 kerberos 票證轉送到 Azure AD。我們的星座涉及 SAML、傳入和傳出聲明、Azure 和服務提供者(而不是直接 ADFS)之間的信任以及「PRT SSO」或「無縫 SSO」技術中的某種 SSO 令牌。在我們的例子中,通訊流程會是什麼樣子?
或者,將應用程式和 Azure 之間的信任從 Azure 逐一「遷移」到 ADFS 可能是更好的方法嗎?
感謝您的幫忙!
答案1
這取決於應用程序,但最可能的情況是您必須將所有應用程式設定為使用 ADFS 信任而不是 Azure AD 信任。
它是可能的某些應用程式可以簡單地繼續使用 Azure AD 信任,然後 Azure AD 將使用 ADFS 處理聯合驗證,但這會使登入程序變得更加複雜,並使其更難管理和故障排除。此外,新增 ADFS 意味著新增潛在的故障點,例如「如果 ADFS 不起作用,您將無法登入任何內容」(這就是為什麼 ADFS 通常至少使用兩台伺服器集區來實作) 。
附註:您不會「將網域移轉到 Microsoft AD Connect 中的「ADFS 驗證」」;您需要設定一個實際的 ADFS 場(包括用於在外部發布它的反向代理),然後在 Azure AD 中設定聯合驗證的網域。
我不知道你的場景的具體情況,但這似乎有點複雜,特別是如果你沒有很好的 ADFS 經驗(無意冒犯,你似乎沒有);如果客戶執行所有這些操作的原因只是為了使用自己的 MFA 解決方案,我強烈建議他們啟用 Microsoft 的 MFA,或者切換到可以與 Azure AD 整合的各種雲端 MFA 解決方案之一。