ASP.NET Core 2 Windows身份验证仅管理员可用问题排查与解决
2026-5-22
问题原因及解决方法
这种情况我在部署域内IIS站点时碰到过好多次，核心问题基本都围绕权限配置和身份验证链路这两块，咱们逐个排查：
一、最常见原因：站点文件/文件夹的NTFS权限缺失
域用户反复跳登录页，很大概率是他们没有读取站点文件的权限——本地管理员默认拥有系统级权限，所以能正常访问，其他域用户则被NTFS权限直接拦住了。
解决步骤：
- 找到你的站点根文件夹，右键选择「属性」→「安全」标签页
- 点击「编辑」→「添加」，输入你的域用户组（比如
DOMAIN\Domain Users）或者特定需要访问的域用户 - 给添加的用户/组分配读取和执行、列出文件夹内容、读取这三个基础权限，点击确定保存
二、IIS授权规则限制了非本地管理员访问
如果你的站点默认设置了只允许本地管理员组访问，那域用户自然会被拒绝，强制跳回登录界面。
解决步骤：
- 打开IIS管理器，找到你的站点，双击「授权规则」
- 检查是否存在拒绝所有用户或者仅允许
BUILTIN\Administrators的规则 - 如果有，删除拒绝规则；然后点击「添加允许规则」，选择「指定角色或用户组」，输入域用户组（比如
DOMAIN\Domain Users），或者根据需求选择「所有用户」，点击确定
三、应用程序池身份权限不足
如果你的站点用的是默认的ApplicationPoolIdentity，它在域环境下可能没有足够权限去验证域用户身份，或者访问站点资源。
解决步骤：
- 在IIS管理器中，找到站点对应的应用程序池，右键选择「高级设置」
- 在「进程模型」→「标识」处，点击「...」按钮
- 选择「自定义账户」，点击「设置」，输入一个具备域权限的服务账户（比如
DOMAIN\IIS_Service_Account，这个账户需要拥有站点文件夹的读取权限，以及AD用户验证权限），输入密码后确定 - 重启应用程序池和站点
四、Windows身份验证的提供商配置问题
有时候Negotiate（Kerberos）提供商出现配置问题，导致域用户无法完成身份验证，而本地管理员依赖NTLM能正常通过。
解决步骤：
- 在IIS管理器中，找到站点，双击「身份验证」
- 找到「Windows身份验证」，右键选择「高级设置」
- 勾选「启用内核模式身份验证」（这个设置能让IIS更稳定地处理域用户验证）
- 回到身份验证界面，右键「Windows身份验证」→「提供程序」，确保
NTLM和Negotiate都在列表里，还可以尝试把NTLM移到最上方（优先使用NTLM验证，规避Kerberos的潜在配置问题）
五、浏览器的身份验证设置问题
部分浏览器默认会阻止自动发送域凭据，导致每次都要手动输入，甚至验证失败。
解决步骤：
- 对于Chrome/Edge：打开设置→隐私和安全→网站设置→权限→更多权限→自动登录，把你的内网站点添加到「允许自动登录」列表
- 对于IE：打开Internet选项→安全→本地Intranet→站点→高级，把你的内网站点添加到本地Intranet区域，然后在「自定义级别」里设置「自动登录到Intranet区域」
内容的提问来源于stack exchange，提问作者Jimmy Mathai
相关产品推荐
相关产品推荐
