我有一个非常类似的问题，就像CentOS 6.3上的这个线程中描述的那样，对2008R2 AD DC进行身份validation。
这里是我的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 当我做一个：
kinit [email protected]
一切按预期工作，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的别名，运行如下：
kinit [email protected]
产生与krb5_child.log完全相同的错误
kinit：在获取初始凭证时找不到所请求领域的KDC
我已经在这个问题上撞了我的头几天，感激任何指针。 🙂
你所处理的是所谓的企业主体。 您有一个AD域，但用户可以有其他用户主体名称（UPN）关联，因此除了XXXX.LOCAL，他们可以有XXXX.COM并使用[email protected]代替[email protected]。
SSSD支持从1.10开始的企业主体。 在实施中，只有很less的bug影响了1.10 beta版本，但是在Fedora 19+的最终版本发布之前就已经解决了。
然而，RHEL 6.x（或者CentOS 6.x）并没有提供这种改变，因为对企业主体的支持是相对侵入性的，并没有反向移植到1.9.x.
如果您没有在krb5.conf指定领域并closuresDNS查找，则主机无法知道XXXXXX.COM是XXXXXX.LOCAL的别名。
像这样在你的krb5.conf中添加一个领域部分，看看会发生什么。
XXXXXXX.COM = { kdc = ad1.XXXXXXX.local kdc = ad2.XXXXXXX.local admin_server = ad1.XXXXXXX.local }
打开dns查找领域和kdc也会完成同样的事情。
dig -t srv _kerberos._udp.XXXXXX.com
应该是以上使用的真正的服务器。
不过，我不确定这是否正确。 上面的krb5.conf应该把你放在XXXXXX.LOCAL领域，试图找出为什么sssd忽略这可能会导致你更多的正确的方向。
我在RHEL 6上遇到了一个非常类似的问题。我已经连接到域，但是我一直看到错误kinit-succeeded-but-ads_sasl_spnego_krb5_bind-在我的日志中失败。
这是我的决议，我认为这对你也有好处。
当我在/ var / log / samba中查看时，我注意到两个log.wb-*文件。 在我的环境中，我们有两个不同的领域。 我检查了两个日志文件。 log.wb-Correctrealm是空的。 log.wb-Incorrectrealm是生成上面列出的错误消息的日志文件。
我检查了我的桑巴configuration（ /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的领域。
这解决了上面的错误。
我没有在其他地方find这个解决scheme，只是想通过它。
您应该正确地configuration不仅krb5.conf，而且sssd.conf – 要么您的服务器主机名用krb5_server / ldap_server / whatnot硬编码，要么指向resolv.conf在服务器，可以为您解决正确的SRVlogging。
有关sssd如何与kinit / libkrb5交互的概述，另请参阅http://jhrozek.wordpress.com/2014/11/04/how-does-sssd-interact-with-tools-like-kinit/ 。