非域客户端使用域账号访问域内SMB服务器的认证机制

核心结论：你描述的场景下不会触发Kerberos认证，没有标准实现支持SMB文件服务器代客户端向KDC申请票据或中继Kerberos认证请求，默认会自动协商降级为NTLM认证完成域账号校验。

Kerberos协议在该场景下不可用的原因 #

Kerberos的设计逻辑强制要求客户端必须直连KDC（域控制器）才能完成认证，全程不需要服务端代转发认证请求：

• 客户端需首先直连KDC，凭自身域账号凭据换取TGT（票据授予票据）
• 访问SMB服务前，客户端需持TGT再次直连KDC，申请对应SMB服务的服务票据（ST）
• 客户端拿到服务票据后，才会将票据发送给SMB服务器做合法性校验
  整个流程中，已加域的SMB服务器仅承担Kerberos应用服务端的角色，只负责验证客户端提交的服务票据是否有效，既没有代客户端向KDC申请票据的功能，也没有中继Kerberos初始认证请求的设计，该模式本身也违背Kerberos不向业务服务暴露用户长期密钥的安全原则。

该场景实际运行的NTLM认证流程 #

Windows SMB服务默认支持认证协议自动协商，当客户端无法连通KDC、无法获取Kerberos票据时，会自动切换到NTLM认证，流程完全适配你给出的网络限制（仅客户端到SMB服务器连通、SMB服务器可正常连通域控）：

• 客户端发起SMB连接后，与服务器协商认证协议，最终选定NTLM作为认证方案
• SMB服务器生成16位随机挑战值发送给客户端
• 客户端用输入的域账号密码对应的NTLM哈希，对挑战值做加密计算，生成一次性认证响应报文发回SMB服务器
• SMB服务器通过自身作为域成员与域控预先建立的安全通道（该通道走服务器自身的网络链路，不受客户端侧防火墙策略限制），将挑战值、客户端响应、目标域账号信息转发给域控做校验
• 域控用AD中存储的对应域账号密码哈希做相同计算，结果匹配则返回认证成功响应，SMB服务器再根据该账号的权限配置开放对应访问范围

凭据存储相关说明 #

由于不存在SMB服务器代客户端申请Kerberos票据的流程，服务器侧不需要存储客户端的域账号凭据：

• NTLM流程中，客户端不会向SMB服务器发送明文密码，也不会发送密码哈希本身，仅传输基于单次挑战计算出的临时响应值
• 标准Windows SMB服务实现不会持久化存储认证过程中的用户凭据、响应值，仅在内存中临时处理验证报文，验证完成后立即清除
• 只有当SMB服务器被恶意植入凭据抓取、记录类后门时，才会出现用户凭据被窃取、存储的情况，属于非标准的恶意行为。

特殊情况说明 #

如果环境配置了域级或服务器本地的NTLM阻断策略，该场景下客户端会直接认证失败：既无法连通KDC走Kerberos流程，NTLM协商又被策略拦截，无可用认证协议。如果SMB服务器自身也无法连通域控，则只能依靠服务器本地缓存的历史域凭据完成验证，缓存过期后认证会直接失败。

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