web-dev-qa-db-fra.com

kinit & pam_sss: impossible de trouver KDC pour le domaine demandé lors de l'obtention des informations d'identification initiales

J'ai un problème très similaire à celui décrit dans ce fil sur CentOS 6.3 s'authentifiant contre un AD 2008R2 DC.

Voici mon krb5.conf, je sais pertinemment que XXXXXXX.LOCAL est le vrai nom de domaine:

[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

Quand je fais un:

kinit [email protected]

Tout fonctionne comme prévu, klist -e retourne cependant les détails qu'il devrait quand j'essaye de:

nom d'utilisateur

Le sssd krb5_child.log montre ce qui suit:

[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

Je sais également que XXXXXXX.COM est un alias de XXXXXXX.LOCAL dans l'arborescence AD ​​et que l'exécution:

kinit [email protected]

produit exactement la même erreur que dans le krb5_child.log

kinit: impossible de trouver KDC pour le domaine demandé lors de l'obtention des informations d'identification initiales

Je me suis cogné la tête contre le mur pendant plusieurs jours sur ce problème et j'apprécierais tous les conseils. :)

active-directorywindows-server-2008-r2kerberospamsssd
6
Sauraus

Ce que vous traitez s'appelle les directeurs d'entreprise. Vous avez un seul domaine AD, mais les utilisateurs peuvent avoir des noms d'utilisateur principal (UPN) associés, donc en plus de XXXX.LOCAL, ils peuvent avoir XXXX.COM et utiliser [email protected] à la place de [email protected].

SSSD prend en charge les principes d'entreprise à partir de 1.10. Il y avait peu de bogues dans l'implémentation qui affectaient les versions bêta 1.10, mais ils sont résolus avant la version finale qui est disponible dans Fedora 19+.

Cependant, cette modification n'est pas disponible dans RHEL 6.x (ou CentOS 6.x d'ailleurs) car la prise en charge des principaux d'entreprise est relativement invasive et n'a pas été rétroportée vers 1.9.x.

Vous pouvez être intéressé par des détails sur https://bugzilla.redhat.com/show_bug.cgi?id=972357 et https://bugzilla.redhat.com/show_bug. cgi? id = 924404

6
abbra

Si vous ne spécifiez pas le domaine dans le krb5.conf et que vous désactivez les recherches DNS, votre hôte n'a aucun moyen de savoir que XXXXXX.COM est un alias pour XXXXXX.LOCAL.

Ajoutez une section de domaine dans votre krb5.conf comme ceci et voyez ce qui se passe.

XXXXXXX.COM = {
 kdc = ad1.XXXXXXX.local
 kdc = ad2.XXXXXXX.local
 admin_server = ad1.XXXXXXX.local

}

Activer les recherches DNS pour le domaine et le kdc accomplirait également la même chose.

Dig -t srv _kerberos._udp.XXXXXX.com

devrait être les vrais serveurs utilisés ci-dessus.

Cependant, je ne suis pas sûr que ce soit vraiment la bonne chose. Le krb5.conf ci-dessus devrait vous placer dans le domaine XXXXXX.LOCAL, en essayant de comprendre pourquoi sssd ignore ce qui pourrait vous conduire davantage dans la bonne direction.

4
Fred the Magic Wonder Dog

J'ai eu un problème très similaire sur RHEL 6. J'étais déjà connecté au domaine, mais j'ai continué à voir l'erreur kinit-reused-but-ads_sasl_spnego_krb5_bind-failed dans mes journaux.

C'était la résolution pour moi, et je pensais que cela pourrait aussi vous être bénéfique.

Quand je cherchais dans/var/log/samba, j'ai remarqué deux log.wb-* des dossiers. Dans mon environnement, nous avons deux domaines différents. J'ai vérifié les deux fichiers journaux. Le log.wb-Correctrealm était vide. Le log.wb-Incorrectrealm était le fichier journal produisant le message d'erreur répertorié ci-dessus.

J'ai vérifié ma configuration samba (/etc/samba/smb.conf) et j'ai trouvé le problème.

Ces lignes avaient le domaine incorrect répertorié.

idmap config Incorrectrealm:backend = rid
idmap config Incorrectrealm:range = 10000000-19999999

J'ai changé les lignes pour refléter le domaine correct

idmap config Correctrealm:backend = rid
idmap config Correctrealm:range = 10000000-19999999

et redémarré le service smb. Je suis ensuite retourné à mes fichiers journaux et au domaine avec log.wb-Correctrealm était en cours de remplissage.

Cela a résolu l'erreur ci-dessus.

Je n'avais trouvé cette résolution nulle part ailleurs et je voulais simplement la transmettre.

2
sjustice

Vous devez configurer correctement non seulement krb5.conf mais aussi sssd.conf - soit codez en dur les noms d'hôte de votre serveur avec krb5_server/ldap_server/whatnot ou pointez resolv.conf sur un serveur qui peut résoudre les enregistrements SRV appropriés pour vous.

Voir aussi http://jhrozek.wordpress.com/2014/11/04/how-does-sssd-interact-with-tools-like-kinit/ pour un aperçu de la façon dont sssd interagit avec kinit/libkrb5.

1
jhrozek