У меня очень похожая проблема, как описано в этой теме на CentOS 6.3 с аутентификацией на DC 2008R2 AD.
Вот мой 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 username@XXXXXXX.LOCAL
Все работает, как задумано, klist -e возвращает детали, которые должны, однако, когда я пытаюсь:
su имя пользователя
В sssd krb5_child.log отображается следующее:
[unpack_buffer] (0x0100): cmd [241] uid [10002] gid [10002] validate [false] offline [false] UPN [username@XXXXXXX.COM]
[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 - это псевдоним для XXXXXXX.LOCAL в дереве AD и который работает:
kinit username@XXXXXXX.COM
выдает точно такую же ошибку, что и в журнале krb5_child.log
kinit: не удается найти KDC для запрошенной области при получении начальных учетных данных
Я несколько дней бился головой об стену по этой проблеме и был бы признателен за любые подсказки. :)
То, с чем вы имеете дело, называется принципалами предприятия. У вас есть один домен AD, но с пользователями могут быть связаны дополнительные основные имена пользователей (UPN), поэтому в дополнение к XXXX.LOCAL они могут иметь XXXX.COM и использовать user@XXXX.COM вместо user@XXXX.LOCAL.
SSSD поддерживает принципалов предприятия, начиная с версии 1.10. В реализации было несколько ошибок, которые повлияли на бета-версии 1.10, но они исправлены до финальной версии, доступной в 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 и вы отключите поиск DNS, ваш хост не имеет возможности узнать, что 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-successeded-but-ads_sasl_spnego_krb5_bind-failed в моих журналах.
Это было решение для меня, и я подумал, что это может быть полезно и для вас.
Когда я смотрел в / var / log / samba, я заметил два log.wb-* файлы. В моем окружении у нас есть два разных царства. Я проверил оба файла журнала. В log.wb-Correctrealm был пуст. В log.wb-Incorrectrealm был ли файл журнала с указанным выше сообщением об ошибке.
Я проверил свою конфигурацию самбы (/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 теперь заселялся.
Это решило указанную выше ошибку.
Этого решения я нигде не нашел и просто хотел передать.
Вы должны правильно настроить не только 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.