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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
manu
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
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...)
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
Emmanuel Dreyfus wrote:
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
Emmanuel Dreyfus <manu@netbsd.org> wrote:
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@netbsd.org
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
Emmanuel Dreyfus wrote:
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
# 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
Et avec tout ca, ca marche. Mais pourquoi le monde est il devenu si compliqué? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Emmanuel Dreyfus <manu@netbsd.org> wrote:
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
# 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
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
# 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
