从ADFS切换至PHS前的依赖项检查方法咨询

嗨，我完全理解你在公司合并过程中想要替换ADFS为PHS时的顾虑——提前排查潜在依赖问题确实能避免切换后出现业务中断的风险，下面是几个实用的检查方向和操作建议：

• 核查应用程序的身份验证协议兼容性
  先把所有依赖原ADFS的应用列出来逐一确认：

  • 查看这些应用是否支持SAML 2.0、OAuth 2.0或OpenID Connect协议，毕竟PHS配合Azure AD主要支持这些标准协议。如果有老旧应用仅依赖ADFS专属的WS-Federation，那可能需要评估应用改造方案，或者临时保留部分ADFS兼容配置过渡。
  • 不确定的话，可以直接联系应用厂商或查看官方配置文档，确认他们是否支持Azure AD作为身份提供商，而非仅适配ADFS。

• 梳理ADFS的自定义配置与依赖规则

  • 检查你的ADFS是否存在自定义声明转换规则、专属的多因素认证（MFA）策略或是条件访问逻辑。PHS依赖Azure AD的原生功能，这些ADFS上的自定义规则需要迁移到Azure AD中，比如用Azure AD的声明映射、内置条件访问策略来替代。
  • 确认是否有应用依赖ADFS生成的特定属性或自定义声明，这类需求需要提前在Azure AD中配置对应的同步规则或声明映射。

• 利用Azure AD Connect工具做预检查

  • 运行Azure AD Connect自带的健康检查功能，它会自动扫描当前ADFS环境与Azure AD的兼容性，提示诸如属性同步冲突、不支持的配置项等潜在问题。
  • 执行PowerShell命令Invoke-ADSyncDiagnostics，这个命令会生成一份详细的诊断报告，不仅能帮你找出同步过程中的障碍，也能间接反映切换到PHS后可能遇到的风险点。

• 搭建测试环境做验证

  • 最好搭建一个和生产环境一致的测试环境，先在测试环境切换到PHS，然后逐一验证所有核心应用的登录流程、权限分配、业务操作是否正常。这是最稳妥的方式，能提前发现很多隐藏的依赖问题。
  • 可以先同步一小部分测试用户到测试Azure AD，模拟真实使用场景，排查是否存在用户属性缺失、权限异常等情况。

• 检查本地服务与ADFS的集成情况

  • 如果有本地服务（比如文件服务器、Exchange服务器）依赖ADFS做身份验证，要确认这些服务是否支持Azure AD的身份验证方式，或者是否需要调整为直接使用本地AD的身份验证逻辑（如果仍依赖本地AD的话）。

总的来说，做好应用梳理、配置核查和测试环境验证这几步，基本能覆盖大部分潜在的依赖风险，让切换过程更顺畅。

备注：内容来源于stack exchange，提问作者Mathias Rønnow Nørtoft