我们有一位客户采用以下设置。
onPrem Active Directory 与 Azure AD Connect 和密码哈希同步 (PHS) 结合使用,包括 SSO 激活
所有 M365 应用的 SSO
集成大约 15 种不同的外部云应用程序,这些应用程序与 Azure 建立信任关系以便在浏览器中使用 SSO
现在,客户希望迁移到 ADFS 身份验证,以便将来为所有应用程序使用 onPrem MFA 解决方案。那么,如果我们将 Azure AD Connect 中的“用户登录”方法从 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 解决方案之一。