Windows Server上IIS与Node并行时，能否经Windows Authentication校验后代理请求至Node并携带用户安全组头

你描述的这套架构完全可以落地实现，也是Windows Server环境下搭建内网AD集成业务系统非常成熟的生产级方案，不存在架构层面的障碍。

核心实现逻辑 #

整套流程的交互链路完全匹配Windows生态的组件设计定位：

• 对外的IIS站点作为统一入口，承接所有客户端的HTTPS请求，原生完成Negotiate/NTLM的Windows身份校验，和域环境的认证流程完全打通
• 身份校验通过后，IIS通过反向代理能力把请求转为内网HTTP格式转发给本地运行的Node服务，整个转发过程中Node完全不感知Windows认证的握手流程
• 转发时通过规则把已校验的用户身份、用户安全组信息注入自定义请求头，供Node处理后续业务逻辑

具体落地步骤 #

• IIS基础配置
  搭建对外的HTTPS站点，绑定有效TLS证书，关闭站点匿名认证，启用Windows Authentication模块，确保域内用户访问时能正常触发Negotiate/NTLM认证流程；安装IIS反向代理必备的应用程序请求路由（ARR）模块、URL重写模块，开启ARR的基础代理功能。
• 反向代理与请求头规则配置
  在URL重写面板新增入站规则，把所有匹配的请求路由到本地Node服务的HTTP监听地址（如http://127.0.0.1:3000）；先配置出站规则，清空客户端可能伪造的同名自定义头（如客户端自行发送的X-Windows-Username），避免身份伪造漏洞；再配置头注入规则，把IIS服务器变量中已校验的LOGON_USER（带域前缀的用户名，如DOMAIN\zhangsan）的值映射到X-Windows-Username请求头，把认证流程解析出的USER_ROLES（用户所属安全组列表）的值映射到X-Windows-User-Groups请求头。
• Node服务适配
  Node服务无需额外处理HTTPS、Windows认证逻辑，仅绑定本地回环地址127.0.0.1的监听端口，禁止对外暴露端口；业务代码中直接从请求头读取注入的用户身份、安全组信息即可，以Express框架为例的示例代码：

  // 校验请求是否经过IIS认证
  const currentUser = req.headers['x-windows-username'];
  if (!currentUser) {
    return res.status(401).send('Invalid access');
  }
  // 解析用户安全组
  const userSecurityGroups = (req.headers['x-windows-user-groups'] || '').split(';').filter(Boolean);
  

常见踩坑提示 #

• Node服务必须绑定127.0.0.1回环地址，绝对不能监听0.0.0.0对外暴露端口，否则攻击者可以绕过IIS直接访问Node端口，跳过整个认证流程
• 配置头注入规则时一定要先清除客户端传入的同名请求头，否则攻击者可以自行伪造身份头获取管理员权限
• 如果拿不到完整的安全组列表，需要检查IIS应用池的运行身份：默认的本地系统身份可能没有域用户信息查询权限，给应用池配置一个具备域查询权限的低权限域账号运行即可
• 配置ARR代理时记得调整默认超时参数，避免长耗时的Node接口被代理提前中断返回502

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