Azure App Service AD认证访问拒绝：迁移后AD用户修改操作失败求助

刚碰到过类似的Azure迁移场景，结合你描述的情况（创建AD用户成功，但修改密码、添加组等操作报访问拒绝），给你梳理几个核心排查方向和解决方案：

1. 先确认AD服务账户的权限细节 #

创建用户成功说明基础的LDAP连接和创建权限没问题，但修改操作需要更细分的权限：

• 重置密码：需要服务账户拥有目标用户对象（或所在OU）的「重置密码」权限，这个和普通的「修改属性」权限是分开的，别搞混了。
• 添加到组：需要服务账户拥有目标组的「添加成员」权限，或者在用户对象上拥有「添加到组」的权限。
• 操作步骤：打开AD用户和计算机，找到目标OU/用户/组，右键→属性→安全→高级，检查服务账户的权限条目，确保对应修改操作的权限已勾选允许。

2. 验证VNET集成的网络端口完整性 #

虽然创建用户能用LDAP端口，但修改操作可能涉及AD的其他核心端口，被NSG或防火墙阻断就会报错：

• 必须打通的端口：除了LDAP（389/636），还要确保Kerberos（88）、RPC（135）、AD动态端口范围（默认49152-65535）能正常访问。
• 测试方法：在App Service的Kudu控制台里用tcpping命令测试连通性，比如：

  tcpping your-dc-domain.com 88
  tcpping your-dc-domain.com 135
  

  如果某个端口不通，去VNET的NSG或防火墙规则里放行对应端口。

3. 排查Kerberos身份验证的坑 #

很多AD修改操作依赖Kerberos而非简单的LDAP绑定，容易出问题的点：

• 确认服务账户的SPN（服务主体名称）是否正确配置，如果代码用了Kerberos认证，SPN不匹配会导致权限验证失败。
• 检查App Service的运行身份：如果用的是App Service默认的系统身份，可能无法获取有效的Kerberos票据，建议改用托管身份（需要把托管身份加入AD并分配权限），或者在代码里明确指定拥有足够权限的域账户来执行AD操作。

4. 检查AD对象的权限继承设置 #

有些AD对象可能禁用了权限继承，导致父OU的权限无法传递到子对象：

• 操作步骤：打开AD用户和计算机→查看→高级功能，然后找到目标用户/组，右键→属性→安全→高级，确认「允许继承来自父系的权限」是否勾选。如果没勾选，需要手动给服务账户添加修改权限，或者开启继承。

5. 抓详细日志定位根因 #

光看「访问拒绝」太笼统，得拿更细的日志：

• 在代码里捕获完整的AD异常信息，比如LDAP错误代码（比如50是访问拒绝，子代码能告诉你具体是权限不足还是其他原因）。
• 去域控制器的安全日志里找「失败审核」事件，里面会记录哪个账户执行了什么操作，以及被拒绝的具体原因，这是定位问题最直接的方法。

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