内容摘要：上周帮朋友处理一个ASP.NET站点，部署到IIS后一直报500.19。错误信息里写着“由于权限不足无法读取配置文件”。我让他把应用程序池账户改成Administrator，问题立刻消失。他挺高兴，我

上周帮朋友处理一个ASP.NET站点，部署到IIS后一直报500.19。错误信息里写着“由于权限不足无法读取配置文件”。我让他把应用程序池账户改成Administrator，问题立刻消失。他挺高兴，我说你别高兴，这事儿相当于你家门锁坏了，你直接把门拆了。

IIS的权限体系其实不复杂，但很多人绕不明白。核心就一句话：IIS自己不做权限判断，它借用Windows的账户体系来干活。每个应用程序池跑在一个身份下面，这个身份对网站目录、配置文件、临时目录有什么权限，IIS就有什么权限。它就是个中间人，真正的权限规则全是NTFS在管。

默认情况下，应用程序池用的是ApplicationPoolIdentity这个虚拟账户。名字听起来像个系统内置账号，实际上它连本地用户都算不上，是IIS动态创建的一个影子账户。你在“计算机管理”里翻不到它，但它确实存在，格式是IIS AppPool\你的池名称。给它授权的方式和给普通用户授权没区别——右键文件夹、属性、安全、编辑、添加，输入那个名字就行。

问题往往出在几个地方。一个是网站根目录的权限。很多人把站点放在C盘某个自建文件夹里，默认继承的是C盘根目录的权限，而C盘根目录对普通用户只给了读取和执行，没有写入。如果你的应用需要写日志、上传文件、生成缓存，那就得手动给IIS AppPool\池名加上修改权限。另一个是web.config的读取权限。这个文件在站点根目录下，如果根目录权限没问题，它一般也没问题。但有时候从别的机器拷贝过来，或者用压缩包解压，权限会乱掉。我见过最离谱的是有人用Git部署，web.config的属主变成了某个已经不存在的SID，IIS读的时候直接拒绝。

还有一个坑是临时目录。ASP.NET编译的时候要把动态程序集写到C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files下面。这个目录默认给IIS_IUSRS组授了写权限，而ApplicationPoolIdentity正好属于这个组。但如果你把应用程序池身份改成了自定义账户，比如NetworkService或者某个域用户，那就得单独给这个目录授权。否则页面会报“编译器错误”，提示无法写入临时文件。

说回我朋友那个事。他为什么改成Administrator就好了？因为Administrator对几乎所有目录都有完全控制权限，绕过了所有NTFS限制。但这样做等于把整个服务器的控制权交给了网站进程。万一网站有文件上传漏洞，攻击者上传一个.aspx木马，这个木马就能以Administrator身份读写系统盘、安装服务、创建用户。所以正确做法是给IIS AppPool\他的池名授予站点目录的修改权限，然后把应用程序池身份改回去。

实际操作中还有个细节：改完权限后IIS不会自动刷新。你得回收应用程序池，或者干脆iisreset。我有次给一个目录加了权限，刷新页面还是403，折腾了十分钟才想起来没回收池。这事儿没什么技术含量，但就是容易忘。

另外提一句，如果你用的是Web Deploy做发布，它默认会带着源机器的ACL一起同步过去。有时候本地开发机上的权限和服务器上不一样，发布完就出问题。可以在发布配置里关掉“保留权限”那个选项，让目标服务器自己决定权限。

IIS权限这东西，说穿了就是“谁在什么目录下能干什么”。把应用程序池身份当成一个普通用户来看待，该给什么权限就给什么权限，别偷懒用Administrator，也别指望IIS会自动帮你搞定。它没那么聪明。