Win7 客户端因 samba4 RODC 上的缓存凭据失败

Question

我正在为一位即将将 samba4 部署到 1400 个远程站点的客户设置测试环境，但我遇到了一个问题。毕竟，我的工作是遇到问题然后解决它们。

活动目录

• 林根和单域：main.adlab.netdirect.ca
• 在 Windows 2008 R2 上创建
• 2008 FFL
• 2008 东航

总公司

• AD1：Windows 2008 R2 DC
• AD2：Windows 2008 R2 DC
• Windows 7 专业版客户端

分支机构

• SLES11SP2（完全更新！）与 Samba 4（来自 sernet 的 4.1.1-7.suse111 包）
• Samba 4 配置为 RODC

我已经配置了密码复制策略以允许将某些帐户缓存在 RODC 上，然后将这些帐户填充到 RODC：

sles-shire:~ # samba-tool rodc preload 'win7-shire$' --server main.adlab.netdirect.ca
Replicating DN CN=WIN7-SHIRE,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca
Exop on[CN=WIN7-SHIRE,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca] objects[1] linked_values[2]

sles-shire:~ # samba-tool rodc preload 'win7-shire-2$' --server main.adlab.netdirect.ca
Replicating DN CN=WIN7-SHIRE-2,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca
Exop on[CN=WIN7-SHIRE-2,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca] objects[1] linked_values[1]

sles-shire:~ # samba-tool rodc preload 'bilbo' --server main.adlab.netdirect.ca
Replicating DN CN=Bilbo Baggins,OU=Shire,OU=Offices,DC=main,DC=adlab,DC=netdirect,DC=ca
Exop on[CN=Bilbo Baggins,OU=Shire,OU=Offices,DC=main,DC=adlab,DC=netdirect,DC=ca] objects[1] linked_values[2]

我知道这些凭据被缓存在 RODC 上，因为如果我删除站点链接，我可以使用缓存用户登录，但不能使用其他用户登录：

michael@sles-shire:~> smbclient //sles-shire.main.adlab.netdirect.ca/sysvol -U michael
Enter michael's password: 
session setup failed: NT_STATUS_IO_TIMEOUT

michael@sles-shire:~> smbclient //sles-shire.main.adlab.netdirect.ca/sysvol -U bilbo
Enter bilbo's password: 
Domain=[MAIN] OS=[Unix] Server=[Samba 4.1.1-SerNet-SuSE-7.suse111]
smb: \> ls
  .                                   D        0  Mon Nov 18 16:09:44 2013
  ..                                  D        0  Mon Nov 18 16:11:15 2013
  main.adlab.netdirect.ca             D        0  Wed Nov 20 17:54:13 2013

所以身份验证工作正常！但是当我尝试登录 Windows 7 PC (WIN7-SHIRE) 时，出现错误：

发生内部错误。

啧。谢谢。如果我使用了错误的密码，我会得到：

用户名或密码不正确。

所以身份验证正在发生，但 Windows 7 不喜欢某些东西。我在事件日志中看到这些错误，我认为它们与这个问题有关：

安全系统检测到服务器 ldap/sles-shire.main.adlab.netdirect.ca 的身份验证错误。来自身份验证协议 Kerberos 的失败代码是“发生内部错误。(0xc00000e5)”。

安全系统检测到服务器 DNS/sles-shire.main.adlab.netdirect.ca 的身份验证错误。来自身份验证协议 Kerberos 的失败代码是“发生内部错误。(0xc00000e5)”。

如果我已经登录并尝试使用网络服务，我会得到：

安全系统检测到服务器 cifs/sles-shire.main.adlab.netdirect.ca 的身份验证错误。来自身份验证协议 Kerberos 的失败代码是“发生内部错误。(0xc00000e5)”。

我在服务器上的 krb5.conf：

[libdefaults]
    default_realm = MAIN.ADLAB.NETDIRECT.CA
    dns_lookup_realm = true
    dns_lookup_kdc = true

[realms]

[logging]
    kdc = FILE:/var/log/krb5/krb5kdc.log
    admin_server = FILE:/var/log/krb5/kadmind.log
    default = SYSLOG:NOTICE:DAEMON

这是真正的踢球者：

当站点链接打开时，该行为仍会发生。我可以使用未缓存在 RODC 上的帐户登录域 PC ，但如果它们在 RODC 上，我会收到相同的错误。

我已确保 AD DNS 中所有适当的 SRV 记录都已到位。我通过将分支机构中的 Windows 2008 R2 DC 提升为 RODC 角色并确保 Windows 和 Samba RODC 都存在所有适当的 DNS 记录来确保这一点。

（有些是必须手动添加的，因为它们还没有被 samba 添加：

SRV _ldap._tcp.${SITE}._sites.DomainDnsZones.${DNSDOMAIN} ${HOSTNAME} 389
SRV _ldap._tcp.${SITE}._sites.ForestDnsZones.${DNSFOREST} ${HOSTNAME} 389

)（必须关闭括号）

那么......什么坏了，我该如何修复它？

---

SPN 信息

> dsquery * "CN=SLES-SHIRE,OU=Domain Controllers,DC=main,DC=adlab,DC=netdirect,DC=ca" -attr servicePrincipalName
  servicePrincipalName
  ldap/SLES-SHIRE;
  ldap/4116d553-d66b-4c8b-9a60-90380ac69c04._msdcs.main.adlab.netdirect.ca;
  ldap/SLES-SHIRE.main.adlab.netdirect.ca/main.adlab.netdirect.ca;
  HOST/SLES-SHIRE.main.adlab.netdirect.ca/main.adlab.netdirect.ca;
  ldap/SLES-SHIRE.main.adlab.netdirect.ca;
  ldap/SLES-SHIRE.main.adlab.netdirect.ca/MAIN;
  HOST/SLES-SHIRE.main.adlab.netdirect.ca/MAIN;
  RestrictedKrbHost/SLES-SHIRE.main.adlab.netdirect.ca;
  RestrictedKrbHost/SLES-SHIRE;
  GC/SLES-SHIRE.main.adlab.netdirect.ca/main.adlab.netdirect.ca;
  HOST/SLES-SHIRE.main.adlab.netdirect.ca;HOST/SLES-SHIRE;

> dsquery * "CN=WIN7-SHIRE,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca" -attr servicePrincipalName
  servicePrincipalName
  TERMSRV/WIN7-SHIRE.main.adlab.netdirect.ca;
  TERMSRV/WIN7-SHIRE;
  RestrictedKrbHost/WIN7-SHIRE;
  HOST/WIN7-SHIRE;
  RestrictedKrbHost/WIN7-SHIRE.main.adlab.netdirect.ca;
  HOST/WIN7-SHIRE.main.adlab.netdirect.ca;

Answer 1

看起来问题可能与探索/测试安装相关的所有死胡同和松散的电线有关。

在根据实际配置过程恢复环境并重新进行 AD 和 RODC 设置后，此场景完美运行，没有任何问题！