Créer un réplicat ldap de la branche de mon labo

Services numériques de la PLM Compte PLM
#1

Bonjour ici !

L’IMT a pour le moment une base d’utilisateurs propre, et c’est un peu difficile de jongler entre l’identifiant IMT, l’identifiant établissement (univ toulouse 3), et l’identifiant PLM.

Je voudrais donc créer un réplica local de la branche de l’IMT de l’annuaire ldap contenant les comptes PLM, en lecture seule.

Le but : pouvoir faire une transition pour mes applications locales de la base de comptes IMT vers les comptes PLM, pour en suivant supprimer la base de comptes locale.

Comment procéder ? Dans mes souvenirs, pour un serveur secondaire openldap il faut au niveau du serveur principal :

  • un identifiant unique de réplication
  • un identité de connexion permettant de récupérer les infos souhaitées

Au niveau du serveur secondaire, il doit falloir :

  • la chaîne de certificat permettant de valider le certificat du serveur

Côté réseau : que le serveur secondaire puisse se connecter au serveur principal en ldaps (tcp port 636).

Cela vous paraît possible ?

Amicalement,

Pierre

#2

Salut,
Je pense qu’on peut y arriver.
La problématique du côté de la PLM:
ce qui identifie un compte PLM dans un labo, c’est un attribut “ou” qui a une valeur (historiquement le numéro CNRS de l’UMR). Par exemple, mon compte uid=depouill aura un attribut ou: 5251. C’est ainsi le cas de tous les comptes IMB.
Afin de pouvoir réaliser une réplication partielle, il faut un compte de réplication qui a un attribut qui peut être autre (prenons ici “o”) et à la même valeur : uid=replicator-imb a un attribut o: 5251.
Dans ce cas on pourrait mettre une ACL openldap du type:

to dn.regex="uid=[^,]+,o=people,dc=mathrice,dc=fr"
  by set="(user/o & this/ou) " read

qui fait le boulot:

  • user/o c’est le compte replicator-imb authentifié et son attribut “o”
  • this/ou c’est l’entrée matchant “uid=[^,]+,o=people,dc=mathrice,dc=fr”
  • (user/o & this/ou) pour que l’ACL fonctionne, ces deux valeurs doivent matcher.

Et hop…

1 « J'aime »
#3

Salut,
Je propose de créer une entrée pour le compte de réplication dans la branche du labo de l’IMT : uid=replicator,cn=umr5219,o=admin,dc=mathrice,dc=fr et d’ajouter l’ACL suivante :

to dn.regex="uid=[^,]+,o=people,dc=mathrice,dc=fr" attrs=userPassword
by set="[uid=replicator,]+([ldap:///o=admin,dc=mathrice,dc=fr??sub?(o=]+ this/ou +[)])/cn+[,o=admin,dc=mathrice,dc=fr]" read

qui forge la chaine correspondante au DN du compte replicator de l’IMT.

De cette manière, pas besoin d’ajouter un attribut “o” au compte replicator et l’ACL cible spécifiquement l’entrée replicator dans la branche correspondante au labo. Avec la solution de Philippe, j’ai l’impression qu’une personne pourrait modifier sa propre entrée LDAP pour s’ajouter l’attribut ‘o’ et aurait ainsi les droits sur les comptes du labo correspondant, non ?

1 « J'aime »
#4

Très belle réponse, faut s’y prendre à tête reposée pour la déchiffrer, mais pas mal du tout.
Pour ta remarque, en effet, si on autorise un user à ajouter ce type d’attribut. J’avais aussi l’ACL qui restreignait aux users dans le groupe c=labo,o=admin.
Mais ok pour ta proposition, ça me va.

#5

Cela a l’air bien. Enfin, après une aspirine et la lecture de la doc openldap sur les acl et l’utilisation de set. :thinking: → :+1:

J’ai testé, et un utilisateur (moi en l’occurence) ne peut pas s’ajouter l’attribut o, ce qui est plutôt rassurant. Du coup, la version de Philippe me paraît plus simple.

Dans la vue que j’ai avec phpldap je ne vois pas la branche o=admin, mais je vois une branche o=replica. Je pensais que les comptes de cette branche correspondaient aux identités pour la réplication, ce n’est pas le cas ? Pour ma culture, à quoi correspond cette branche ?

#6

Ah oui effectivement il n’y a pas d’ACL permettant de s’ajouter un attribut, donc pas de problème pour ça !

Je viens également de découvrir cette branche replica où il y a déjà quelques utilisateurs comme par exemple :

dn: cn=umr5251,o=replica,dc=mathrice,dc=fr
cn: umr5251
objectclass: simpleSecurityObject
objectclass: organizationalRole
ou: 5251

Je ne sais pas si c’est utilisé ou non mais on peut reprendre le principe. Du coup l’ACL de philippe deviendrait :

to dn.regex="uid=[^,]+,o=people,dc=mathrice,dc=fr" attrs=userPassword
  by set="(user/ou & this/ou) " read
#7

C’est pas mal d’avoir la liste des réplicats au même endroit, c’est plus clair. On pourrait même stocker l’id de réplication là-dedans.

#8

Prochaine étape : je vous envoie un mot de passe chiffré pour que vous puissiez créer l’identité de réplication. Vous utilisez quoi comme algo ?

#9

oui ok, on fait comme ça. Pour l’id de réplication, coté serveur il n’y a rien à faire et on n’a pas besoin de stocker cet ID. Tout se passe coté client.