authentification LDAP, filtres, et TLS

Le
manu
Bonjour

Deux problèmes autour de l'usage de l'annuaire LDAP pour
l'authentification et la base d'utilisateurs dans MacOS X pour lesquels
je ne vois pas de solution:

1) Comment appliquer un filtre sur les requetes LDAP, pour que ne soient
par exemple vus comme usagers que les objets de l'annuaire qui ont un
attribut authorizedService=mac

On peut indiquer une classe d'objet (ex: inetOrgPerson, posixAccount),
une base de recherche (ex: dc=example,dc=net), mais je n'ai pas vu de
possibilité de mettre un filtre.

2) Plus grave: si je met dans /etc/openldap/ldap.conf
TLS_REQCERT demand
Alors la commande ldapsearch va continuer de marcher très bien, mais par
contre, dès le reboot suivant, DirectoryService deviendra incapable de
contacter l'annuaire. La negociaition TLS échoue (erreur -14002 dans les
logs)

C'est ennuyeux parcequ'on ne peut pas configurer le comportement des
outils à la ligne de commande pour verifier les certificats, et pire
encore, ca jette le doute sur la capacité de DirectoryService à le
faire.

Or faire du TLS sans verifier les certificats, ca ne sert pas à grand
chose (attaques triviales à coup de Man in the Middle). Donc là si
quelqu'un a une solution, ca me soulagerai.

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@netbsd.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
manu
Le #456546
Deux problèmes autour de l'usage de l'annuaire LDAP pour
l'authentification et la base d'utilisateurs dans MacOS X pour lesquels
je ne vois pas de solution:


Et un troisième:
3) comment on explique à MacOS X que les changements de mot de passe
doivent se faire par operation LDAP étendue et pas juste en ecrivant
dans l'attribut userPassword? (sans même s'authentifier avant, en plus,
quel rustre...)

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz


manu
Le #456083
Emmanuel Dreyfus
Et un troisième:
3) comment on explique à MacOS X que les changements de mot de passe
doivent se faire par operation LDAP étendue et pas juste en ecrivant
dans l'attribut userPassword? (sans même s'authentifier avant, en plus,
quel rustre...)


Un élément de réponse: avec une version récente de DirectoryService
(faire DirectoryService -v, si ca dit 2.1, c'est ok), par défaut il
tente d'abord une opération étendur puis un changement simple.

Mais y'a un soucis: dans mon cas, j'ai un serveur LDAP maitre et des
repliques. Le client MacOS X ne connait que les repliques. Quand il
tente une opération étendue, il recoit un referral lui indiquant de
s'adresser au serveur LDAP maitre. Et il s'adresse, mais avec un BIND
anonyme. Evidemment, l'operation échoue.

Epreuve suivante: expliquer à MacOS X que lorsque l'on suit un referral,
il faut se réauthentifier sur le serveur suivant.

Y'a une alternative, qui consiste à configurer le serveur replique (qui
est sous OpenLDAP) pour utiliser slapo-chain et faire suivre lui même au
maitre LDAP. Un bref examen du truc semble montrer que c'est pas du tout
evident à faire marcher, ce bordel.

La suite prochainement...

Par ailleurs, je n'ai toujours pas trouvé comment convaincre le plugin
LDAPv3 de DirectoryServer de fonctionner lorsque /etc/openldap/ldap.conf
contient TLS_REQCERT demand, si quelqu'un a une idée...
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz


manu
Le #456080
Emmanuel Dreyfus
Y'a une alternative, qui consiste à configurer le serveur replique (qui
est sous OpenLDAP) pour utiliser slapo-chain et faire suivre lui même au
maitre LDAP. Un bref examen du truc semble montrer que c'est pas du tout
evident à faire marcher, ce bordel.


Même si c'est hors-charte sur ce groupe, la solution au problème pourra
interesser des gens qui faisant une recherche sur le sujet. Et comme
c'est loin d'être correctement documenté, voila ce que j'ai eu à faire,
en attendant que j'ecrive une entrée de FAQ:

Rappel du problème:

On a un maitre LDAP, des repliques LDAP, et MacOS X s'authentifie contre
les repliques. L'opération de changement de mot de passe implique de
parler au maitre plutot qu'aux repliques. Il n'a pas l'air possible de
dire à MacOS X d'utiliser un serveur différent pour le changement de mot
de passe.

On peut configurer les repliques pour envoyer un referral quand le
client tente de faire une modification à l'annuaire (par exemple changer
de mot de passe). Si le serveur est OpenLDAP, ca se fait en ajoutant une
directive updatedn:
updateref ldaps://ldapmaster.example.net

Alors MacOS X va alors s'authentifier contre la réplique, puis suivre le
referral et aller demander au maitre de modifier le mot de passe. Petit
soucis: il ne juge pas nescessaire de s'authentifier à nouveau sur le
maitre. Le maitre refusera logiquement une opération de changement de
mot de passe non authentifiée, et ca foire.

Impossible de trouver comment convaincre MacOS X de s'authentifier à
nouveau. La solution consiste donc à configurer les repliques pour
transmettre la requete de changement de mot de passe au maitre.

Voici comment faire sur OpenLDAP avec une authentification par
certificat SSL entre replique et maitre. Ca se fait avec slapo-chain
coté replique, qui va transmettre la requete du client vers le maitre.

Il faut aussi configurer le maitre pour accepter que les repliques se
comportent en proxy pour un usager: une replique est authentifiée par un
certificat et doit agir sur l'annuaire avec les droits d'un usager. Ca
se fait par le biais de l'attribut authzTo, qui indique pour qui un
usager peut agir. On commence donc par faire correspondre au certificat
de la réplique un usager qui existe et qui a un authzTo, ensuite le
authzTo permet à la replique de changer le mot de passe pour l'usgager.
Le maitre fait confiance à la replique pour ce qui est d'avoir
authentifier l'usager qui demande le changement de mot de passe.

1) slapd.conf sur la replique:

# Dans la section globale
TLSCertificateFile /etc/openssl/certs/ldapreplica1.crt
TLSCertificateKeyFile /etc/openssl/private/ldapreplica1.key
TLSCACertificateFile /etc/openssl/certs/ca.crt

overlay chain
chain-uri ldaps://ldapmaster.example.net
chain-idassert-bind bindmethod=sasl
saslmech=EXTERNAL
binddn="cn=bugworkaround"
mode=self
chain-idassert-authzFrom "*"
chain-return-error TRUE

# Dans la section sur la base de suffix "dc=example,dc=net"
updateref ldaps://ldapmaster.example.net


2) slapd.conf sur le maitre:
# Dans la section globale
TLSCertificateFile /etc/openssl/certs/ldapmaster.crt
TLSCertificateKeyFile /etc/openssl/private/ldapmaster.key
TLSCACertificateFile /etc/openssl/certs/ca.crt

# traduction du CN de ldapreplica1.crt en un DN existant
authz-policy to
authz-regexp cn=ldapeplica1.example.net
cn=ldapreplica1,ou=pseudo-users,dc=example,dc=net

# Dans la section sur la base de suffix "dc=example,dc=net"
# Ne surtout pas laisser les usager modifier leurs authzTo
access to attrs=authzTo
by * read stop

access to attrs=userPassword
by anonymous auth stop
by self =dw stop
by * none stop


3) Dans l'arbre LDAP:
dn: cn=ldapreplica1,ou=pseudo-users,dc=example,dc=net
objectClass: organizationalRole
cn: ldapreplica1
ou: pseudo-users
authzTo: *


Et avec tout ca, ca marche. Mais pourquoi le monde est il devenu si
compliqué?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz


Publicité
Poster une réponse
Anonyme