Dynamics NAV 2017 WebClient是否支持SAML认证及配置咨询

核心结论：NAV 2017原生不支持SAML认证 #

Microsoft Dynamics NAV 2017作为Business Central的前身版本，没有原生集成SAML单点登录功能——SAML支持是在Business Central 14及后续版本才正式引入的。因此无法直接在NAV服务器层面配置SAML实体ID（entity-ID）来对接Azure AD App Proxy的SAML需求。

基于Azure AD App Proxy的间接实现方案 #

虽然NAV本身不支持SAML，但可以通过Azure AD App Proxy结合IIS身份验证的方式间接实现SSO，具体步骤如下：

• 确保IIS层的Windows身份验证正常
  为NAV Web Client站点启用Windows身份验证，禁用匿名和表单身份验证；验证域用户可通过Windows身份验证直接登录NAV Web Client（依赖域登录会话，无需重复输入密码）。
• 配置Azure AD App Proxy发布本地NAV应用
  在Azure AD中创建应用代理，指向本地NAV Web Client的内部URL；选择SSO模式为Integrated Windows Authentication（IWA），此时App Proxy会处理前端的Azure AD认证，再将域用户身份传递给后端IIS；关于实体ID：由于NAV无原生SAML实体ID，可自定义一个（例如https://your-nav-proxy-domain.com），在App Proxy的SAML配置中填写该值即可。
• NAV用户映射配置
  在NAV管理控制台中，确保Azure AD用户对应的域账号已在NAV中创建并分配权限，或配置NAV用户与Azure AD用户的属性关联。

替代SSO方案 #

如果上述间接方案不符合需求，可考虑以下替代方案：

• AD FS + Windows身份验证
  基于企业内部AD FS服务器实现SSO，用户登录域后，访问NAV Web Client时自动通过AD FS完成身份验证，无需额外输入密码。需在IIS中配置AD FS信任，同时NAV服务器使用Windows身份验证。
• NAV原生Azure AD身份验证
  NAV 2017支持Azure AD用户验证（非SAML模式），可在NAV管理控制台中设置Authentication参数为AzureActiveDirectory，配置Azure AD租户ID、客户端ID等信息，用户可直接使用MS365账号登录NAV Web Client。此方案需确保NAV用户与Azure AD用户一一对应。
• 第三方身份代理模块
  在IIS层部署第三方SAML代理模块（如Okta IIS Agent、PingFederate），由模块处理SAML认证流程，将认证后的用户身份转换为NAV支持的Windows或NAV用户身份，再转发给NAV Web Client。

注意事项 #

所有操作均在测试环境验证后再推广到生产环境，已做备份的前提下可放心测试；后续切换到Business Central时，BC原生支持SAML，当前的过渡方案可平滑迁移。

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