公网环境下获取客户端域/用户名及LDAP查询可行性相关问题

需求可行性与UPN获取相关问题 #

你提到的需求默认不可行，公网非域内场景下，浏览器不会主动暴露UserPrincipalName(UPN)这类域身份标识。
你用到的System.DirectoryServices.AccountManagement.UserPrincipal.Current.UserPrincipalName接口，仅在服务端部署在域环境、客户端是域内设备且走Windows集成认证（IWA/NTLM/Kerberos）的内网场景下才能拿到客户端用户的UPN。公网非域场景下调用该接口，要么返回空值，要么返回服务端自身运行账号的信息，无法获取客户端用户的对应值。
不存在通用的浏览器配置项可以主动把UPN暴露给公网站点：只有当站点被手动加入客户端的本地Intranet/受信任站点列表、站点配置了Windows集成认证，且客户端是已加入域的设备、当前用域账号登录时，才会在认证握手阶段传递身份信息，该行为属于认证流程的一部分，并不是浏览器把UPN暴露给前端或者应用层直接获取。

公网场景可提取的客户端标识符 #

由于浏览器安全沙箱限制，你无法从公网客户端浏览器直接获取可信的、和LDAP条目绑定的原生身份标识，仅能通过以下方式获取可用于查询的标识符：

• 用户主动提交的绑定标识：最稳妥的域无关方案是先做用户登录流程，让用户主动输入和LDAP条目预先绑定的邮箱、手机号、自定义账号等标识，用该标识执行LDAP查询，适配多机构服务的场景。
• 客户端证书标识：如果可以给合法用户下发客户端证书，配置站点走TLS双向认证，可以从客户端证书的主体字段、SAN字段提取和LDAP绑定的标识，可信度和安全性远高于普通浏览器字段。
• 其余浏览器原生可获取字段仅可作为辅助校验，不能作为唯一查询标识：包括User-Agent、客户端公网IP、Cookie/LocalStorage存储的自定义会话标识等，这类字段均可被篡改，无法唯一对应LDAP中的用户条目。

对应方案的安全影响 #

• 如果你用不可信的客户端提交字段做LDAP查询，存在LDAP注入风险：如果没有对查询参数做严格的校验过滤，攻击者可以构造恶意参数窃取全量LDAP目录数据，甚至篡改目录内容。
• 如果你强行在公网部署Windows集成认证传递身份信息，存在凭证泄露、中继攻击风险，跨多机构的场景下跨域信任配置复杂度极高，很容易出现权限溢出问题。
• 即使LDAP服务器部署在客户端内网仅对己方设备开放，也要严格限制应用绑定的LDAP账号权限：仅开放最低必要的查询权限，禁止赋予写入、修改权限，避免应用被作为跳板窃取LDAP数据。
• 多机构域无关场景下，用单一标识查询多个机构的LDAP目录可能出现标识冲突问题，比如两个不同机构的用户使用相同的账号前缀，需要额外增加机构维度的标识做联合查询，避免返回错误的用户数据。

内容的提问来源于stack exchange，提问作者user7858150