LDAP OpenLDAP et mots de passe - Page 1

J'essaie tranquillement de me refaire un serveur perso (actuellement un OS X Server, mais j'essaie de voir si je peux le remplacer par un Linux).

J'aimerais notamment une authentification centralisée et compatible avec OS X Client, du coup j'ai choisi OpenLDAP + Kerberos.

Pour l'authentification Kerberos dans OpenLDAP, ça fonctionne plutôt bien. J'ai créé un utilisateur test2 (dans OpenLDAP et dans Kerberos), et je peux faire des requêtes sans problème ( ldapsearch -Y GSSAPI -b cn=users,dc=mondomaine,dc=net "(&(&(objectClass=inetOrgPerson)(objectClass=posixAccount)(objectClass=shadowAccount)(objectClass=apple-user)(objectClass=extensibleObject))(|(uid=test2)(cn=test2)(mail=test2)(altSecurityIdentities=test2)))" )

Si j'utilise l'authentification par mot de passe, ça fonctionne également (-D blabla -w toto). Le mot de passe a été créé via ldappasswd.
D'ailleurs, quand je fais une recherche, j'ai userPassword:: e1NTSEF9bUxXMnFMU1VDaTJ6Wmt3a0FoejRrQ04rdzFtWjJsckc=
Il me semblait que la fonction de hash était précisée dans l'attribut (du genre {SSHA}e1NTSEF9bUxXMnFMU1VDaTJ6Wmt3a0FoejRrQ04rdzFtWjJsckc= ). Est-ce normal ? Comment imposer du SSHA ?

Maintenant, OS X Client demande apparemment du MD5-DIGEST pour s'authentifier.
J'ai donc essayé ldapsearch -Y MD5-DIGEST blabla, mais je n'aime pas la réponse :

SASL/DIGEST-MD5 authentication started
Please enter your password: 
ldap_sasl_interactive_bind_s: Invalid credentials (49)
	additional info: SASL(-13): user not found: no secret in database

D'ailleurs, c'est exactement la même réponse que j'ai dans les logs quand j'essaie de me logguer depuis OS X.

Après un peu de lecture, j'ai cru comprendre qu'il fallait utiliser saslpasswd2 pour enregistrer les mots de passe. Pas de problème :

$ sudo saslpasswd2 -c test2
Password: 
Again (for verification): 
$ sudo sasldblistusers2
test2@prefix: userPassword

Aucune mention de MD5-DIGEST et je crois qu'il devrait y en avoir.


Si vous avez des idées…

bon, pour la première question,

base64.b64decode('e1NTSEF9bUxXMnFMU1VDaTJ6Wmt3a0FoejRrQ04rdzFtWjJsckc=') ='{SSHA}mLW2qLSUCi2zZkwkAhz4kCN+w1mZ2lrG'

Donc, c'est bon, je stocke bien en SSHA... Ne reste plus que le problème du DIGEST-MD5

Le LDAP support bien le DIGEST-MD5, il n'arriverait donc pas à trouver la base sasl...

$ sudo ldapsearch  -x -D "CN=admin,DC=mondomaine,DC=net" -w toto -b "" -s base "supportedsaslmechanisms"    
dn:
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: NTLM

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Bon, je ne peux pas trop répondre dans la mesure où j'utilise mes propres scripts pour la génération des mots de passe (SSHA2), mais je trouve ton mot de passe crypté à première vue très très court (c'est peut-être la police qui fait ça, mais là, on dirait qu'il n'y a pas de graine aléatoire dans ton SSHA2).

Le cas échéant, je peux t'envoyer (là je ne suis pas au boulot) mon script pour l'affectation des mots de passe (ou un mot de passe crypté qui soit "à ma sauce" pour que tu testes).

Sinon, je trouve quand même très étrange qu'un client impose une méthode d'authentification ; normalement, c'est au serveur de gérer la procédure d'authentification (au pire, le client peut refuser l'auth s'il n'est pas en ldaps, mais c'est tout... je me demande pourquoi OSX impose ça...)

je comprends quand même que le login ne fonctionne pas par Kerberos, vu que tu n'as pas de ticket quand tu te loggues...
Du coup, il faut au moins une autre méthode que GSSAPI pour se connecter (par exemple DIGEST-MD5), mais je ne suis pas sûr qu'OS X refuse toute autre méthode.

Et quoiqu'il en soit, je ne vois vraiment pas comment faire pour que SASL fonctionne correctement

Sinon, le SSHA me semble raisonnable (22 caractères + 8 de sel)

Bon, on est à la limite de l'univers que je maîtrise (je ne pratique pas du tout OpenLdap avec Kerberos, quand j'ai dû authentifier des machines OSX sur un annuaire, je le faisais directement sur un serveur OpenLdap en https, et là le seul système de tickets que j'utilise est pour le web avec CAS).
J'ai quand même rapidement fait un tour sur Google, et j'ai trouvé quelqu'un qui semble avoir des problèmes assez similaires (http://www.openldap.org/lists/openldap-software/200410/msg00335.html et la réponse qu'il s'est faite). Le souci est que depuis 2004, OpenLdap a beaucoup changé. Je ne sais pas si tu travailles toujours avec un fichier de configuration "à l'ancienne" (ce qui est mon cas, je trouve ça moins dangereux en cas de modifications régulières, ça évite de corrompre l'arbre en pleine exécution) ou dans l'arbre config de l'annuaire, mais il y a peut-être quand même quelque chose à voir à ce niveau.

Bah en soi, la partie Kerberos fonctionne très bien avec mon LDAP, c'est la partie non kerberos justement

et je confirme, ça a pas mal changé, mais la configuration reste une vraie catastrophe Encore pire, peut-être... Et les tutus n'aident pas vraiment, ni la doc d'ailleurs


Ceci dit, si tu as une autre méthode pour qu'un client OS X puisse s'authentifier sur un OpenLDAP, je suis preneur...

Il faut que je regarde comment ça a évolué (je n'ai pas fait ça depuis OS 10.3, et je sais qu'Apple a fait des coupes franches dans certaines parties système), mais je n'ai pas d'OSX sous la main :/
(Il faudrait que je me fasse un Hackintosh sous Virtualbox, tiens )

A priori, c'est encore possible (vu que ça fonctionne comme ça chez moi ), j'aurais tendance à dire que le problème est plutôt sous Linux (vu que je n'arrive pas à faire d'authentification DIGEST-MD5).

Oui mais en fait, je ne comprends pas pourquoi tu utilises Kerberos, en fait (tu as des applications secondaires qui s'authentifient automatiquement après l'authentification du client OSX ?) ?
Et niveau Linux, comment est ta configuration ? (version et fichier slapd.conf...)

À terme, oui, j'aimerais que tous les autres services que j'ai actuellement (VPN, calendrier, carnet d'adresses, web, ...) s'authentifient via Kerberos. C'est plutôt fiable et ça évite d'avoir un mot de passe à taper trop souvent... Puis surtout, c'est un trip de geek

Le seul inconvénient, c'est que mon téléphone ne supporte pas Kerberos

Oh, ok, dans ce cas, je comprends mieux, du coup...

D'ailleurs, j'ai trouvé un moyen « simple » pour le SSO sur mon téléphone, via des certificats PKCS 12 ^^

Bon, j'ai peut-être trouvé (je fais des tests dans une seconde VM, pas encore vérifié dans la VM d'origine)
Apparemment, il manquait dans cn=config.ldif
olcPasswordHash: {CLEARTEXT}


Accessoirement, je n'ai pas besoin de saslpasswd2 pour utiliser SASL () : OpenLDAP utilise SASL, mais en interne, sans passer par le service externe SASLauthd.

Muahahah, putain de nouvelle façon de configurer à la con (voilà pourquoi je reconfigure tout pour utiliser les fichiers "à l'ancienne", au moins on sait ce qu'il y a dedans de façon claire).

Je confirme, ça fonctionne nickel, et je peux également me logguer sur mon OS X

putain de configuration à la con...

Cela dit, elle est préférable pour les systèmes stabilisés... en fait, je conseille de faire la préprod "à l'ancienne", et la prod avec tout dans la base. C'est préférable niveau sécurité, on bénéficie de la souplesse de l'annuaire, on peut répliquer la conf, on peut faire des modifs à la volée sans couper le service...

Oh, certainement... mais c'est la structure-même de la configuration qui n'est pas évidente, je trouve.

Avec les différents fichiers de configuration par sous-base, etc..

Hum, normalement tu ne devrais pas avoir du tout de fichier de configuration, si c'est un cn=config qui est paramétré

Aaaaaah, cn=config.ldif, ok, c'est la méthode "intermédiaire", tu as quand même un fichier de configuration (dans le dernier que j'ai eu à installer, il n'y en avait même pas - enfin, on pouvait en créer un pour envoyer les paramètres, hein - charge au "spécialiste" de tout créer dans l'arbre config à la main.

Si, si, il y a cn=config.ldif, mais aussi un dossier cn=config :

prefix# ls /etc/ldap/slapd.d/cn=config
cn=module{0}.ldif  cn=schema  cn=schema.ldif  olcBackend={0}hdb.ldif  olcDatabase={0}config.ldif  olcDatabase={-1}frontend.ldif  olcDatabase={1}hdb.ldif

Maintenant, prochaine étape : authentification sur Linux via Kerberos ^^

Pour moi, c'était un fichier de config qui était chargé en base... Mais du coup, je ne sais pas ce qu'il se passe quand tu modifies la configuration en base :/

Alors j'ai pas pratiqué longtemps ce type de config, mais je ne sais plus s'il reproduit exactement l'arborescence de configuration en fichiers à chaque évolution ou s'il y a une commande pour exporter la config en cours (je sais qu'il y a une commande pour générer un fichier de config "à l'ancienne" depuis une configuration en arbre, je l'ai utilisée, mais c'était il y a trop longtemps.

Tiens, je n'ai jamais fait de réplication LDAP, est-ce compliqué à mettre en place ?

(bon, par contre, ça m'obligerait à avoir une seconde VM pour tester, mais ce n'est pas très grave ^^)

Ah alors sur le papier, non, c'est pas compliqué. En pratique, ça a chié quand j'ai dû le mettre en prod à mon ancien boulot parce qu'il y a des versions d'OpenLDAP qui avaient des problèmes au niveau de slurpd (le démon de synchro).
En plus, c'est un système de réplication incrémentiel, avec tout ce que ça incombe comme problèmes (il faut que les deux serveurs soient exactement au même niveau au moment de la mise en place de la réplication).

Bon, va falloir que j'essaie alors ^^
Je pense faire de toute façon plusieurs VM sur mon prochain serveur, autant en profiter ^^

Apr 22 10:07:03 prefix krb5kdc[1096]: AS_REQ (4 etypes {18 17 16 23}) 10.19.1.50: NEEDED_PREAUTH: test2@19POUCES.NET for krbtgt/19POUCES.NET@19POUCES.NET, Additional pre-authentication required
Apr 22 10:07:04 prefix krb5kdc[1096]: AS_REQ (4 etypes {18 17 16 23}) 10.19.1.50: ISSUE: authtime 1335082024, etypes {rep=18 tkt=18 ses=18}, test2@19POUCES.NET for krbtgt/19POUCES.NET@19POUCES.NET
Apr 22 10:07:04 prefix krb5kdc[1096]: TGS_REQ (4 etypes {18 17 16 23}) 10.19.1.50: ISSUE: authtime 1335082024, etypes {rep=18 tkt=18 ses=18}, test2@19POUCES.NET for host/prefix.int.19pouces.net@19POUCES.NET
Apr 22 10:07:04 prefix login[6458]: pam_krb5(login:auth): user test2 authenticated as test2@19POUCES.NET
Apr 22 10:07:04 prefix login[6458]: pam_unix(login:account): could not identify user (from getpwnam(test2))
Apr 22 10:07:04 prefix login[6458]: pam_ldap: error trying to bind (Invalid credentials)
Apr 22 10:07:04 prefix login[6458]: Authentication failure

Ça avance, mais ce n'est toujours pas ça....

Apr 22 18:12:10 prefix krb5kdc[1096]: AS_REQ (4 etypes {18 17 16 23}) 10.19.1.50: NEEDED_PREAUTH: test2@19POUCES.NET for krbtgt/19POUCES.NET@19POUCES.NET, Additional pre-authentication required
Apr 22 18:12:10 prefix krb5kdc[1096]: AS_REQ (4 etypes {18 17 16 23}) 10.19.1.50: ISSUE: authtime 1335111130, etypes {rep=18 tkt=18 ses=18}, test2@19POUCES.NET for krbtgt/19POUCES.NET@19POUCES.NET
Apr 22 18:12:10 prefix krb5kdc[1096]: TGS_REQ (4 etypes {18 17 16 23}) 10.19.1.50: ISSUE: authtime 1335111130, etypes {rep=18 tkt=18 ses=18}, test2@19POUCES.NET for host/prefix.int.19pouces.net@19POUCES.NET
Apr 22 18:12:10 prefix login[7093]: pam_krb5(login:auth): user test2 authenticated as test2@19POUCES.NET
Apr 22 18:12:10 prefix login[7093]: pam_unix(login:account): could not identify user (from getpwnam(test2))
Apr 22 18:12:11 prefix login[7093]: pam_env(login:session): No such user!?
Apr 22 18:12:11 prefix login[7093]: pam_env(login:session): No such user!?
Apr 22 18:12:11 prefix login[7093]: pam_krb5(login:session): (user test2) getpwnam failed for test2
Apr 22 18:12:11 prefix login[7093]: pam_unix(login:session): session opened for user test2 by LOGIN(uid=0)
Apr 22 18:12:11 prefix login[7093]: User not known to the underlying authentication module

Bon, bah fallait simplement relancer nscd...

Pourquoi tous ces smileys ? Ya bien une manière de faire marcher ça, le tout c'est de la connaitre, non ? ^^

Ça serait encore mieux si c'était correctement documenté

Après être reparti de ma sauvegarde de la VM pour refaire les réglages (histoire de vérifier que j'avais bien compris le truc), ça fonctionne quand je me connecte en direct, ça fonctionne quand je passe par un sudo (sauf le ticket Kerberos), mais :

su test2
Password: 
su : Échec d'authentification
zsh: segmentation fault  su test2

nscd... le système de cache le plus pourri du monde... (on redémarrait le service toutes les 2h, à Lyon, quand on avait le samba sur l'annuaire LDAP... ça merdait grave avec les changements de mots de passe)