嘿PJ，完全理解你们安全部门的顾虑——直接把LDAPS、Kerberos这类AD核心协议的端口开放给第三方托管服务器，确实会把内部域控暴露在不必要的风险下。结合微软AD的生态，这里有几个更安全的替代方案供你参考：

• 方案一：使用AD FS（Active Directory Federation Services）搭建联邦身份层
  AD FS是微软原生的联邦身份服务，相当于在你们内部AD和第三方软件之间加了一个安全中间层：

  • 第三方软件只需要通过标准的SAML 2.0或OAuth 2.0协议与AD FS通信，所有流量都是加密的HTTPS（仅需开放443端口），不需要直接接触LDAPS或Kerberos。
  • AD FS负责与内部AD交互完成身份验证和权限查询，你可以通过AD FS的声明规则细粒度控制第三方能获取的用户信息和权限范围。
  • 额外安全增强：可以给AD FS配置MFA（多因素认证）、IP白名单限制，只允许第三方托管服务器的IP段访问，进一步降低风险。

• 方案二：借助Azure AD同步+应用代理/ B2B合作
  如果你们已经在使用Azure AD，可以把内部AD的用户和权限同步到云端，让第三方软件通过Azure AD完成认证：

  • 用Azure AD Connect把内部AD用户同步到Azure AD，然后配置Azure AD应用代理，让第三方软件的认证请求导向Azure AD，而非直接访问内部AD。
  • 或者用Azure AD B2B合作功能，将第三方服务器的访问权限纳入Azure AD的条件访问策略（比如强制MFA、设备合规检查）。
  • 优势：不需要在本地防火墙开放任何AD相关端口，所有认证流量都经过Azure AD的安全体系，微软会负责云端服务的安全维护。

• 方案三：部署LDAP反向代理做流量管控
  如果第三方软件仅支持LDAP协议，不愿意修改认证逻辑，可以在内部网络边缘部署LDAP代理服务器：

  • 第三方服务器只和这个代理通信（代理对外暴露LDAPS端口），代理再转发合法请求到内部AD，同时拦截非法访问。
  • 你可以在代理层做细粒度控制：比如限制第三方只能访问特定OU的用户、只能读取必要的用户属性，还可以开启详细的访问日志审计所有请求。
  • 推荐工具：开源的OpenLDAP slapd（配置为代理模式）或者商业级的LDAP网关产品，确保代理本身的安全配置（比如强密码、IP白名单）。

• 方案四：自定义API身份中间层
  如果需要完全控制认证流程，可以开发一个轻量的身份认证中间层服务：

  • 这个服务部署在内部网络，通过LDAP或Kerberos与AD交互；对外提供REST API或OAuth2接口给第三方软件调用。
  • 第三方软件通过调用这些API来验证用户身份、获取权限信息，所有对外流量都是HTTPS加密，你可以在中间层加限流、MFA、令牌过期等安全措施。
  • 优势：完全自定义权限逻辑，第三方无法直接接触内部AD，适合有特殊业务需求的场景。

总结一下，如果是微软生态环境，优先推荐AD FS或Azure AD的方案，原生兼容性和安全性更有保障；LDAP代理适合第三方软件仅支持LDAP的场景；自定义API则适合需要高度定制的情况。

备注：内容来源于stack exchange，提问作者PJ87