我遇到了与描述非常相似的问题在此主题中在 CentOS 6.3 上针对 2008R2 AD DC 进行身份验证。
这是我的 krb5.conf，我知道 XXXXXXX.LOCAL 是真正的域名：
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = XXXXXXX.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
verify_ap_req_nofail = false
[realms]
XXXXXXX.LOCAL = {
kdc = ad1.XXXXXXX.local
kdc = ad2.XXXXXXX.local
admin_server = ad1.XXXXXXX.local
default_domain = XXXXXXX.LOCAL
}
[domain_realm]
.XXXXXXX.local = XXXXXXX.LOCAL
XXXXXXX.local = XXXXXXX.LOCAL
.XXXXXXX.com = XXXXXXX.LOCAL
XXXXXXX.com = XXXXXXX.LOCAL
当我这样做时：
基尼特[电子邮件保护]
一切都按预期进行，但是当我尝试时，klist -e 返回了应有的详细信息：
su 用户名
sssd krb5_child.log 显示以下内容：
[unpack_buffer] (0x0100): cmd [241] uid [10002] gid [10002] validate [false] offline [false] UPN [[email protected]]
[unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_10002_XXXXXX] keytab: [/etc/krb5.keytab]
[krb5_child_setup] (0x0400): Will perform online auth
[krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment.
[krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment.
[krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [false]
[krb5_child_setup] (0x0100): Not using FAST.
[get_and_save_tgt] (0x0400): Attempting kinit for realm [XXXXXXX.COM]
[get_and_save_tgt] (0x0020): 977: [-1765328230][Cannot find KDC for requested realm]
[kerr_handle_error] (0x0020): 1030: [-1765328230][Cannot find KDC for requested realm]
[prepare_response_message] (0x0400): Building response for result [-1765328230]
[main] (0x0400): krb5_child completed successfully
我还知道 XXXXXXX.COM 是 AD 树中 XXXXXXX.LOCAL 的别名，并且运行：
基尼特[电子邮件保护]
产生与 krb5_child.log 中完全相同的错误
kinit：获取初始凭证时找不到请求领域的 KDC
我已经为这个问题苦思冥想好几天了，非常感激大家的指点。:)
答案1
您处理的是企业主体。您有一个 AD 域，但用户可以关联其他用户主体名称 (UPN)，因此除了 XXXX.LOCAL 之外，他们还可以拥有 XXXX.COM 并使用[电子邮件保护]代替[电子邮件保护]。
从 1.10 开始，SSSD 确实支持企业主体。实施过程中存在一些影响 1.10 测试版的错误，但它们已在 Fedora 19+ 中提供的最终版本发布之前得到解决。
但是，由于对企业主体的支持相对具有侵入性并且未移植到 1.9.x，因此此更改在 RHEL 6.x（或 CentOS 6.x）中不可用。
您可能有兴趣查看详细信息https://bugzilla.redhat.com/show_bug.cgi?id=972357和https://bugzilla.redhat.com/show_bug.cgi?id=924404
答案2
如果您未在其中指定领域krb5.conf并且关闭了 DNS 查找，则您的主机将无法知道 XXXXXX.COM 是 XXXXXX.LOCAL 的别名。
像这样在您的 krb5.conf 中添加一个领域部分，看看会发生什么。
XXXXXXX.COM = {
kdc = ad1.XXXXXXX.local
kdc = ad2.XXXXXXX.local
admin_server = ad1.XXXXXXX.local
}
打开领域和 kdc 的 DNS 查找也可以完成同样的操作。
dig -t srv _kerberos._udp.XXXXXX.com
应该是上面使用的真实服务器。
但是，我不确定这是否真的正确。上面的 krb5.conf 应该会将您置于 XXXXXX.LOCAL 领域，尝试弄清楚 sssd 为何忽略了这一点，可能会让您更接近正确的方向。
答案3
我在 RHEL 6 上遇到了非常类似的问题。我已经连接到域，但我不断在日志中看到错误 kinit-succeeded-but-ads_sasl_spnego_krb5_bind-failed。
这是我的解决办法，而且我认为它对你也可能有益。
当我查看 /var/log/samba 时，我注意到两个log.wb-*文件。在我的环境中，我们有两个不同的领域。我检查了两个日志文件。 是log.wb-Correctrealm空的。 是log.wb-Incorrectrealm产生上面列出的错误消息的日志文件。
我检查了我的 samba 配置（/etc/samba/smb.conf）并发现了问题。
这些行列出了错误的领域。
idmap config Incorrectrealm:backend = rid
idmap config Incorrectrealm:range = 10000000-19999999
我改变了这些线条以反映正确的范围
idmap config Correctrealm:backend = rid
idmap config Correctrealm:range = 10000000-19999999
并重新启动了 smb 服务。然后我回到我的日志文件，发现域log.wb-Correctrealm现在正在被填充。
这解决了上述错误。
我没有在其他地方找到这个解决方案，只是想把它传递下去。
答案4
您不仅应该正确配置 krb5.conf，还应该正确配置 sssd.conf - 使用 krb5_server/ldap_server/whatnot 硬编码您的服务器主机名，或者将 resolv.conf 指向可以为您解析正确 SRV 记录的服务器。
也可以看看http://jhrozek.wordpress.com/2014/11/04/how-does-sssd-interact-with-tools-like-kinit/了解 sssd 如何与 kinit/libkrb5 交互。