下载Edge扩展前对用户/机器进行身份验证的技术问题

针对你在域内私有服务器托管Edge扩展、通过注册表强制部署时遇到的update_url需公开、无法添加验证头的问题，提供以下几个可行的解决方案：

1. 反向代理层实现身份验证 #

在Edge与私有扩展服务器之间部署反向代理（如Nginx、IIS应用请求路由ARR），由代理完成用户/机器的身份验证，Edge仍使用公开的代理地址发起请求：

• 配置反向代理监听公开端口，转发请求到内部私有扩展服务器
• 在代理上启用Windows身份验证（NTLM/Kerberos），利用域内设备的机器账户或用户账户自动完成验证，无需额外配置Edge
• 代理拒绝未通过验证的请求并返回403，域内设备的Edge会自动携带当前域身份凭证发起请求，无需用户干预

2. 直接配置私有服务器支持域身份验证 #

如果私有服务器是IIS等支持Windows身份验证的服务，可直接开启NTLM/Kerberos验证：

• 确保私有服务器已加入域，配置正确的SPN（服务主体名称）以支持Kerberos
• 将update_url指向私有服务器的域内地址，Edge在访问域内可信站点时，Windows会自动发送当前设备/用户的域凭证，无需手动添加请求头
• 检查Edge的安全设置，确认“自动登录到Intranet站点”已启用（默认域内站点会自动适配）

3. 打包扩展为MSI通过组策略部署替代自动更新 #

放弃update_url自动更新机制，将扩展打包为MSI安装包，通过组策略批量部署到OU内设备：

• 使用Edge官方扩展打包工具生成包含扩展的MSI文件
• 在组策略中配置“软件部署”，指定目标OU范围，设备开机或用户登录时自动安装/更新扩展
• 后续版本更新只需重新打包MSI并更新组策略部署即可，完全避免公开update_url的问题

4. 动态令牌式的变通方案（复杂度较高） #

若必须保留update_url自动更新，可通过组策略为每个设备推送带唯一令牌的update_url：

• 服务器端生成与域内设备绑定的唯一验证令牌
• 通过组策略修改设备注册表中的update_url，附加令牌参数（如https://your-server/update.xml?token=XXX）
• 服务器端验证请求中的令牌有效性，通过后返回扩展更新包
• 注意：此方案需维护设备与令牌的映射关系，令牌存在泄露风险，仅作为临时替代方案

优先推荐方案 #

优先选择反向代理身份验证或域内服务器直接身份验证，这两种方案完全适配现有域环境，无需修改Edge原生行为，实现成本低且安全性高。

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