Windows SMB域认证权限由共享权限、NTFS权限和AD域身份解析协同决定，取三者交集；域用户SID及组成员关系经Kerberos传递，实现集中化权限管理与自动同步。
windows smb 共享在域身份认证下，权限不是简单“用户对上文件夹”的一对一映射，而是由共享权限、ntfs 权限和域身份解析机制三者协同决定的。关键在于：域用户登录后，系统会将其 sid（安全标识符）与 ad 中的组成员关系一并传递给 smb 服务端；服务端再结合共享路径上的两层权限策略，最终计算出实际可执行的操作。
域用户 SID 与组策略的自动继承
当 Windows 客户端以域用户（如 CONTOSO\alice）身份挂载 SMB 共享时，客户端会通过 Kerberos 协议向域控制器请求票据，并将该用户的完整 SID 及其所属的所有安全组（如 CONTOSO\HR-Users、CONTOSO\File-Readers）一并提交给文件服务器。这意味着：
- 无需在每台文件服务器上单独创建本地用户或重复添加权限
- 只要在 AD 中调整用户所属组，其在所有已配置域信任的 SMB 共享上的访问权限就会同步更新
- 组嵌套（例如 HR-Users 属于 All-Employees）也会被正确展开并参与权限计算
共享权限 + NTFS 权限 = 实际生效权限
两者不是叠加，而是取交集——最终权限是二者中最严格的那个。例如：
- 共享权限设为“读取”，NTFS 权限设为“修改” → 实际只能读取
- 共享权限设为“更改”，NTFS 权限拒绝“删除” → 删除操作被阻止
- 若某用户未被显式授予共享权限，但属于一个拥有“读取”权限的域组，则仍可访问（组权限有效）
注意：NTFS 权限优先级更高，且支持更细粒度控制（如“遍历文件夹”、“创建文件”、“取得所有权”等），而共享权限仅提供读取/更改/完全控制三级粗粒度控制。
AD 域环境下 SMB 权限映射的关键配置点
要确保域身份能正确映射并生效，必须完成以下几项基础配置：
- 文件服务器必须加入同一域，且 DNS 指向域控制器（否则无法解析 Kerberos 票据）
- SMB 共享所在卷需启用 NTFS 格式，并禁用“简单文件共享”（即关闭“网络发现”中的简易共享模式）
- 在共享属性中，应移除默认的
Everyone权限，改用明确的域用户或域安全组（如CONTOSO\IT-Admins）分配权限 - 若使用 Azure 文件存储等云 SMB 服务，还需提前在存储账户中启用 AD DS 或 Microsoft Entra ID 身份验证，并分配“存储文件数据 SMB 共享参与者”角色
常见权限失效原因与排查方向
域用户能挂载成功却提示“拒绝访问”，往往不是权限没配，而是身份链路中断：
- Kerberos 失败退为 NTLM：若时间偏差 >5 分钟、SPN 未注册或客户端未启用 Kerberos，可能降级使用 NTLM，导致组信息丢失
- DNS 解析异常：客户端无法正向/反向解析域控制器主机名，造成身份验证超时或失败
-
缓存凭据干扰：之前用存储密钥挂载过同一共享，系统可能残留旧凭据；需运行
cmdkey /delete:target清理 - ACL 继承被中断：手动取消了子文件夹的权限继承，又未重新赋予对应域组权限，导致深层目录不可访问
