Kerberos/AD/LDAP/Synchro On suppose que openldap heimdal et perl sont installés. Accès entre les services Un compte «syncad» est défini dans le KDC. Il est configuré pour écrire dans le LDAP, via une auth SASL/GSSAPI. Pour cela il faut également que le service ldap soit connu dans Kerberos. Ce compte syncad doit avoir des droits admin dans le KDC pour créer des comptes. Le service syncad/admin est à utiliser. Grâce à l'approbation des domaines AD/Kerberos, le compte syncad existe aussi dans AD. Il faut lui donner les droits «Opérateur de compte» afin qu'il puisse créer des objets LDAP. La connection vers AD se fait par GSSAPI. Le script tourne sur le machine tierce. Il lit le serveur LDAP via l'utilisateur syncad, et va écrire dans l'ad les objets nécessaires. Il va également écrire dans le KDC pour la création des comptes. Mise en exploiration Les userpassword sont de la forme {SASL}user@REALM pour déléguer l'auth à SASL, qui va faire du Kerberos derriere Données: Serveur ldap: iutsud-ldap.u-strasbg.fr Serveur KDC: iutsud-kdc.u-strasbg.fr Domaine Kerberos: UNIX.LOCAL Domaine Windows: DPTINFO.UDS.LOCAL Version de heimdal utilisée: 0.8 Précisions SASL est utilisé de deux manières ici. La premiere avec le stockage dans userpassword de {SASL}login@REALM. Cela dit que quand on fait un bind simple sur le ldap pour vérifier le mot de passe, on va faire du SASL pour vérifier el mot de passe après. A ne pas confondre avec un bind SASL au serveur ldap Bind simple: ldapsearch -x -H ldap://iutsud-ldap.u-strasbg.fr Bind SASL: ldapsearch -Z -H ldap://iutsud-ldap.u-strasbg.fr Cette précision pour la suite: si on a un ticket kerberos, mais que le SASL est mal configuré pour le serveur LDAP (par ex, on arrive pas à lire le keytab), le bind SASL échoue alors que le bind simple passera. La différénce est de taille puisque dans la conf, on regardera si on fait un bind SASL/GSSAPI pour autoriser ou pas l'écriture dans le LDAP. Ceci vous sauvera 4h de travail.
LDAP AD Lecture via uid=syncad Auth GSSAPI Ecriture via syncad memberof Operator Auth: Trust + GSSAPI Ecriture via syncad/admin Auth keytab KDC Sur le serveur KDC: Création des principals: $ kadmin -l kadmin> add -r syncad Password expiration time [never]: kadmin> add -r syncad/admin Password expiration time [never]: kadmin> add -r ldap/iutsud-ldap.u-strasbg.fr/unix.local
Password expiration time [never]: kadmin> Configuration du KDC pour autoriser la création des SPN: Dans kadmin.acl, rajouter syncad * Redémarrer le serveur KDC pour prendre en compte les changements Vérification: Depuis un poste distant, $ kinit -t syncadadmin.keytab syncad/admin $ kadmin kadmin> add toto devrait fonctionner. Configuration LDAP Sur le serveur iutsud-ldap, on va stocker le keytab du service /etc/krb5.keytab : iutsud-ldap $ kinit root/admin root/admin@unix.local's Password: ***** iutsud-ldap $ kadmin kadmin> ext_keytab ldap/iutsud-ldap.u-strasbg.fr/unix.local Ce keytab sert pour le bind SASL. La commande vient de créer le fichier /etc/ldap/krb5.keytab. Donner les droits en lecture au groupe openldap sur ce fichier (chmod g+r && chown.openldap ). TODO: Il faut que slapd sache où est le keytab: KRB5_KTNAME=/etc/ldap/krb5.keytable. Cependant, certains disent que ca marche que avec le Kerberos MIT, et donc que il faut utiliser une directive dans SASL (dans /usr/lib/sasl2/slapd.conf et y mettre keytab: /path/to/file) Mettre KRB5_KTNAME= la ou ca va bien et redemarrer slapd Pour tester si le contenu du keytab correspond à ce que l'on souhaite: $ kinit -t /etc/ldap/krb5.keytab ldap/iutsud-ldap.u-strasbg.fr@unix.local $ klist (TODO: Ecrire la commande pour lister le contenu klist -k -t -e (marche pas avec heimdal??). Créer un keytab de la même manière sur la machine qui va lancer le script, pour le SPN syncad/admin et pour syncad. Configuration du serveur openldap pour autoriser l'acces en lecture (bind simple) : rajouter à access to * by dn="uid=syncad,cn=gssapi,cn=auth" read
Pour autoriser l'acces en bind SASL: sasl-secprops none #sasl-host iutsud-ldap.u-strasbg.fr saslregexp uid=(.+),cn=(.+),cn=.+,cn=auth ldap:///dc=$2,dc=fr??sub?( (uid=$1)(cn=$1@$2)) saslregexp uid=(.+),cn=.+,cn=auth ldap:///dc=u-strasbg,dc=fr??sub?( (uid=$1)(krbname=$1@unix.local)) #TODO: On peut deleguer le SASL vers un serveur externe? Plusieurs? Il faut configurer SASL pour que ca puisse être utilisé par slapd: mettre: pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux dans /usr/lib/sasl2/slapd.conf. Vérification de l'accès LDAP en bind SASL: # kinit -k -t syncad.keytab syncad@unix.local # ldapsearch -H ldap://iutsud-ldap.u-strasbg.fr SASL/GSSAPI authentication started SASL username: syncad@unix.local. # klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: syncad@unix.local Issued Expires Principal Dec 2 15:24:30 Dec 3 01:24:30 krbtgt/unix.local@unix.local Dec 2 15:24:34 Dec 3 01:24:30 ldap/iutsud-ldap.u-strasbg.fr@unix.local Le ldapsearch a du sortir des informations et surtout il doit y avoir au debut SASL/GSSAPI le klist permet de vérifier qu'on a bien eu un TGS pour le service ldap. Et encore 2 heures que je vous sauve, pour rien de plus: Il faut que chaque client qui demande un bind SASL/GSSAPI ait un SPN host/f.q.d.n@unix.local. Sinon le bind SASL/GSSAPI a l'air de bien se faire, mais rien n'est retourné. Et comme bonus, je livre un autre problème qui peut arriver: $ ldapsearch -H ldap://iutsud-ldap.u-strasbg.fr -ZZ SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) Ceci arrive si vous avez plusieurs REALM de configuré, pour un meme domaine. Il faut que il y ait une entrée dans /etc/krb5.conf de la forme: [domain_realm]
.u-strasbg.fr = UNIX.LOCAL Dans la conf du serveur AD Ajouter un user "syncad" et mapper l'identité syncad@unix.local sur celui ci. Cela évite en particulier de se retrouver dans des cas inextricables: Pour lire le LDAP a part un bind SASL/GSSAPI, il faut passer en LDAPS et poru cela, il faut installer un gestionnaire de certificat, jongler avec les formats d'ad, et comme sans doute vous n'avez pas le même domaine AD et DNS (dptinfo.uds.local et u-strasbg.fr, iutsud-w2k3.u-strasbg.fr = w2k3.dptinfo.uds.local, vous allez vous retrouver à devoir resoudre des sacs de noeux. Si vous arrivez au message : additional info: SASL(- 1): generic failure: GSSAPI Error: Miscellaneous failure (Cannot resolve network address for KDC in requested realm) vous êtes arrivé presque a la fin du sac de noeux: il faut rajouter dans le krb5.conf l'entrée pour le REALM DPTINFO.UDS.LOCAL etc. mais à ce stade, je n'ai plus rien à vous apprendre. Donner des pouvoirs de superman à ce compte (lockez le compte et oubliez le mot de passe), en lui faisant une delegation de pouvoir sur le domaine complet, en modification sur tout: Gestion des utilisateurs et groupes, bouton de droite sur le domaine, "déleguer", choisir syncad@dptinfo.uds.local, puis "Créer une Tache", choisir le premier "de ce dossier et des objets qui s'y trouvent" puis "controle total". Serrer les fesses. Verifier qu'on lit bien l'ad complet # kinit -k -t syncad.keytab syncad@unix.local # ldapsearch -H ldap://iutsud-w2k3.u-strasbg.fr -b "dc=dptinfo,dc=uds,dc=local" Le bind doit se faire en SASL/GSSAPI. Toute autre URI vous fera revenir au sac de neoux au debut de ce paragraphe. On peut verifier les credentials acquis: on a fait jouer l'approbation de domaine, et on a eu un ticket pour acceder au service ldap du serveur AD, version REALM AD! iutsud-kdc:~# klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: syncad@unix.local Issued Expires Principal Dec 2 20:32:06 Dec 3 06:32:06 krbtgt/unix.local@unix.local Dec 2 20:32:08 Dec 3 06:32:06 krbtgt/dptinfo.uds.local@unix.local Dec 2 20:31:57 Dec 3 06:31:57 ldap/w2k3.dptinfo.uds.local@dptinfo.uds.local Maintenant on arrive à lire dans LDAP, écrire dans le KDC, et écrire dans l'ad. Reste à synchroniser