遇到这种突然出现的访问权限问题确实挺闹心的，结合你提供的日志信息（里面的401.3错误其实指向了资源ACL权限问题），我帮你梳理几个关键的排查方向，看看能不能解决这个403错误：

• 检查IIS身份验证配置：

  • 确认站点的匿名身份验证是否启用，并且匿名用户身份（默认是IUSR）对PDF文件及父文件夹有读取权限；如果站点用了Windows身份验证，要确保访问用户的身份能正常读取这些资源。
  • 日志里先出现401未授权再转403，很大概率是身份验证环节出了问题，导致请求没有拿到合法的访问权限。

• 核对NTFS权限的细节：

  • 虽然你已经确认IIS_IUSRS有读权限，但要检查权限是否继承到了子文件——有时候父文件夹的权限没勾选“替换子容器和对象的权限”，新生成的PDF可能没继承到权限。
  • 查看文件的实际所有者，若所有者不是有权限的账号（比如管理员），可能会导致权限设置不生效；另外要排查是否存在拒绝权限（拒绝权限优先级高于允许权限）。

• 检查IIS请求筛选规则：

  • 打开IIS管理器，找到对应站点的「请求筛选」，查看「文件扩展名」标签，确认.pdf是允许访问的状态，没有被误添加到拒绝列表。
  • 同时检查「隐藏段」「URL」筛选规则，有没有误拦截了/PDFs/这个路径。

• 确认处理程序映射设置：

  • 检查站点的「处理程序映射」，找到.pdf对应的映射项，确认是由「StaticFile」模块处理——如果被错误映射到PHP或其他需要额外权限的处理程序，也会导致访问报错。

• 临时权限测试：

  • 可以临时把PDF文件的只读权限开放给「Everyone」组，如果能正常访问，说明还是权限配置的问题，再逐步缩小范围排查具体是哪个账号的权限缺失。

附你提供的日志信息：

2023-11-10 15:03:30 [ip removed] GET /PDFs/PDF-2023110813295.pdf - 443 - [ip address removed] 4 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/119.0.0.0+Safari/537.36 [url removed] 401 3 5 1541 0

备注：内容来源于stack exchange，提问作者user1765369