kinit&pam_sss:获取初始凭证时找不到所要求的领域的KDC

我有一个非常类似的问题,就像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.

您可能有兴趣查看https://bugzilla.redhat.com/show_bug.cgi?id=972357和https://bugzilla.redhat.com/show_bug.cgi?id=924404

如果您没有在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/