这种AD/DC做了冗余更新后出现的间歇性Samba共享故障真的挺闹心的，结合你提到的systemctl status smb显示预认证失败的报错，大概率是Kerberos层面和新DC的交互出了问题，给你几个实用的排查和修复方向：

• 检查Kerberos客户端配置是否同步到新DC
  先看看/etc/krb5.conf里的KDC配置是不是已经更新成两台新的冗余DC了？很多时候旧配置还指向原来的单DC，AD切换后就会出现间歇性找不到可用KDC的情况。可以把KDC列表改成两台新DC的主机名，示例配置如下：

  [realms]
  YOUR.DOMAIN = {
      kdc = dc1.your.domain
      kdc = dc2.your.domain
      admin_server = dc1.your.domain
      default_domain = your.domain
  }
  

  另外验证Kerberos票据获取是否正常：执行kinit <你的域用户账户>，如果能顺利拿到票据，说明基础Kerberos交互没问题；如果有报错，重点排查KDC的网络可达性和DNS解析。

• 刷新Samba的Kerberos密钥缓存
  AD更新后，Samba依赖的机器账户密钥可能没同步到位。可以先停掉smb服务：systemctl stop smb，然后清空Kerberos缓存：kdestroy -A，接着重新生成域机器账户的keytab文件：net ads keytab create -U <域管理员账户>，最后重启smb和nmb服务：systemctl restart smb nmb。要是重启后还是有问题，可以尝试重新加入域：net ads join -U <域管理员账户>。

• 确认Samba与SSSD的Kerberos协同配置
  虽然SSSD允许域用户登录且无报错，但可能Samba没正确使用SSSD提供的Kerberos上下文。检查/etc/samba/smb.conf里的关键参数，确保配置类似这样：

  security = ADS
  realm = YOUR.DOMAIN
  password server = dc1.your.domain dc2.your.domain
  idmap config * : backend = sss
  

  另外留意winbind服务状态，如果你的环境依赖winbind，确保它正常运行：systemctl status winbind，必要时调整配置禁用winbind（如果用SSSD的话，很多场景不需要winbind）。

• 排查DNS解析的稳定性
  间歇性故障很多时候和DNS脱不了干系，AD更新后新DC的DNS记录有没有在HPC上稳定解析？在HPC上执行nslookup _kerberos._tcp.your.domain，看看返回的是不是两台新DC的地址。如果解析不稳定（比如偶尔返回旧DC或只返回一台），得调整HPC的DNS服务器配置，确保能稳定解析到两台新DC。

• 开启详细日志精准定位问题
  如果上面的步骤还没解决，建议开启Samba的详细日志。在smb.conf里添加或修改：

  log level = 3 passdb:5 auth:5
  

  重启smb服务后，等故障出现时查看/var/log/samba/log.smbd日志，里面会有预认证失败的具体细节，比如是哪个DC拒绝了请求、密钥不匹配的原因等，这能帮你快速锁定问题根源。

你可以先从这些步骤入手排查，要是某个环节出现具体报错或者配置疑问，随时把相关日志片段或配置内容贴出来，我再帮你细化分析。

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