Windows服务器站点搭建：权限配置一步到位

　　跟老板拍桌子那天，我手边咖啡早凉了，PM在钉钉弹窗里第七次问“权限是不是没配好”，而我盯着IIS管理器里那个勾了又取消、取消又勾上的“继承权限”复选框，突然觉得这玩意儿跟去年十二月我们上线前夜一模一样——就差没在服务器上贴张便利贴写“求别崩”。

　　我原以为把ApplicationPoolIdentity加进IIS_IUSRS组再顺手给站点目录来个“修改+读取+遍历”就完事了。结果呢？PHP脚本死活读不到config.ini，后端工程师甩过来一个curl -v的返回头截图，Status: 500，底下连error_log都没生成。我查事件查看器翻到一半，发现是w3wp进程在跑，但实际用的是IUSR账户——谁改的？没人认。我敢打包票，上个月重装过那台服务器的磁盘，RAID卡驱动还是带签名的旧版，蓝屏过两次，但这个权限问题不是硬件导致的。

文章配图，仅供参考

　　首屏救火的时候，Lighthouse跑分截图发到群里没人回。桌面那个没关的录屏窗口还停在“Generating report…（14s）”帧上，光标在左下角闪，像在嘲笑我。下午三点零七分，前端冲进来问“能不能先放开everyone全权限顶一下”，我说不行，他说“那CI/CD流程卡在这儿，要不你先点个‘确定’？”我点了。然后他马上撤回了那条消息，说“刚发现是git hooks里漏了个chown”。哦，原来如此。

　　“Windows服务器站点搭建：权限配置一步到位”——这话听着像宣传册上抠下来的。可它真有点东西，就是那种不讲道理的优胜劣汰。你只要敢漏掉一项ACL条目，它不会报错，它会等你上线第三天凌晨两点，在订单支付回调接口里默默挂掉第一个POST请求，等你扒着Fiddler抓包才发现，是appsettings.json被IIS自动缓存成只读属性了。你得手动右键→属性→安全→高级→取消“从父项继承”，再点“复制”，再勾上“替换子容器和对象的所有者”，中间还不能让后端在旁边切数据库连接池——他会误触PowerShell里的Set-ItemProperty，把所有NTFS时间戳全刷成1601年1月1日，然后整个监控平台告警图标开始转圈，一圈，两圈，三圈，没人记得它最初为什么转。

　　我试过一次“一步到位”的批处理脚本，含二十一个Set-Acl命令、三个icacls调用、一个Get-ChildItem递归排除logs和temp文件夹——它运行成功了，Event Log里打了绿色勾。但第二天用户上传头像失败，查了半天，是upload目录下的web.config文件自带的触发了双重跳转，让AppPoolIdentity在第二次上下文切换时丢了token。这个我说不准，微软文档里压根没提这个组合的兼容性警告，只有社区某位2018年的回帖写着“建议直接禁用impersonation”，后面跟着一个已删除的GitHub issue链接。

　　对面工位的后端换了根充电线，Type-C接口，亮白光，不是蓝的。他说旧线充到73%就不进了，现在能到99%，但他昨晚还是因为笔记本休眠没保存代码，把一个修复JWT签名校验的补丁弄丢了。这种事儿跟我这儿权限配置有什么关系？没有。但我记得清清楚楚，因为他换线的时候正巧我在重置一个被加密的web.config中的connectionStrings节，密钥轮换后忘了重启App Pool，导致所有DB连接走的还是旧密钥，直到SQL Server报出Login failed for user 'NT AUTHORITY\\IUSR'。这时候你没法跟任何人讲清楚——这是密码学、权限系统、IIS管道模型和.NET运行时初始化顺序四个维度在打架。

　　我上周翻了下CDN账单，静态资源缓存命中率92.7%，但后台API网关那一栏显示“边缘规则冲突：重复定义Origin header rewrite”，运维说这个不归他们管。我想起上季度KPI折算里有一项叫“基础设施稳定性权重”，占17%，但它没说明白是看平均响应延迟，还是看单次500错误持续时长，或是看IIS Application Pool崩溃频率。反正我不太关心，我只关心下次再有人问我“为啥网站打不开”，能不能让我直接甩过去一条PowerShell命令——哪怕它只在83%的Windows Server 2022标准版实例上有效。

　　再说一遍，“一步到位”不是魔法，是压缩包解压时那个强制覆盖提示框：“您正在覆盖已存在的文件”。你点了“是”，但没注意下面小字写着“包括其所有继承权限设置”。这行字，没人读。包括我，包括去年十二月那个凌晨三点对着Event ID 1309反复刷新的我。我现在还在用那个老办法：先删inheritance，再手动加两条，再右键→属性→安全→编辑→添加→Advanced→Find Now→找到IIS_IUSRS→勾“修改”，中间要是鼠标抖了一下点到了“Special permissions”，就得重来。我不写文档，也不建Checklist，因为每次服务器版本不一样，AD域策略不一样，甚至管理员控制台的语言包版本都不一样——上周有台机器中文界面，ACL对话框里写的却是英文“Modify”，而另一台英文界面里弹出来的是“写入”两个中文字。

　　谁去倒水？是我自己。水壶在茶水间第三层，紫砂釉面，把手有点烫。我接水时看了眼手机，微信里有个未读，是测试同学发的：“你们那个健康检查端点，/healthz返回503，但我们测环境是200”，我没回。因为我知道，她测的是Dev，而Staging那台服务器的AppPool回收时间被设成了“120分钟”，但实际负载是每97分钟必掉一次，原因是某个DLL的内存泄漏阈值被Windows内存管理器动态调低了11MB。这跟权限没关系，但跟“一步到位”有关——所有看似独立的模块，最后都会在ACL树的同一个叶节点上撞上。

　　我现在打算把所有站点权限脚本都打上“v0.9-alpha-broken-on-WS2022-LTSC”的tag，放GitLab private repo。不跑CI，不上Ansible Tower，就本地PowerShell ISE里调试。什么时候哪台服务器真能一次配对、三天不崩、五个不同角色的人都没提过权限问题……我再把tag改成1.0。在此之前，先这么耗着吧。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!