Bug #13075
fermé
Synchronisation LDAP: problème si traitement par paquet de 1000, certains utilisateurs ne sont pas repris.
100%
Description
Contexte : Synchronisation d'utilisateurs depuis un annuaire LDAP Active Directory
Sur une synchronisation complète, (méthode internalLdapSearch), tout les éléments ne sont pas ramenés d'un bloc, mais par paquet, donc les 999 premiers éléments sont ramenés.
(par ordre de sAMAccountName)
Ensuite, la requête est censée reprendre au 1000ème élément en repartant du dernier sAMAccountName synchronisé.
Exemple :
[DEBUG] élément #999 : CN=OUNI Meryem,OU=01-CAMPUS,DC=CG11,DC=local | From: LDAPUtility.search1000Plus() [DEBUG] Size Limit Reached... | From: LDAPUtility.search1000Plus() [DEBUG] Requête sur le domaine LDAP distant (protocole v3), BaseDN=OU=01-CAMPUS,DC=CG11,DC=LOCAL scope=2 Filter=(&(&(objectClass=user)(&(sn=*)(givenName=*)(employeeId=*)(mail=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2))))(sAMAccountName>=meryem.ouni)) | From: LDAPUtility.search1000Plus()
[DEBUG] élément #1000 : CN=TAURINES Marie-Hélène,OU=01-CAMPUS,DC=CG11,DC=local | From: LDAPUtility.search1000Plus()
Donc ici, dernier élément synchronisé: meryem.ouni
Problème: ils ne ramènent pas les éléments dont le sAMAccountName est inférieur à "ma" c'est à dire par exemple tout ceux qui ont un point ou un tiret après le m.
Mis à jour par
Mis à jour par Yohann Chastagnier il y a presque 2 ans
- Statut changé de In progress... à Resolved
- % réalisé changé de 0 à 100
Lorsqu'il existe un grand nombre d'entrée qui répond à une requête LDAP, certains serveur limite le résultat de la requête à N entrées.
Dans MSAD, cette limite est de 1000 entrées par défaut.
Lorsque le résultat de la requête est limité à ces N entrées, le client LDAP doit alors traiter la situation pour obtenir les autres entrées.
Plusieurs méthodes peuvent être employées pour cela.
Jusqu'à maintenant, celle utilisée par Silverpeas était de travailler sur des résultats de recherche triés par rapport à un attribut de l'utilisateur (par défaut sAMAccountName).
La valeur de l'attribut de tri de la dernière entrée d'un bloc de N utilisateurs était utilisée pour compléter le filtre de recherche et exécuter de nouveau la requête LDAP.
Sur un résultat LDAP dépassant la limite N, par exemple, si l'attribut de tri est sAMAccountName et que la valeur de ce dernier pour la dernière entrée d'un bloc de résultat est "yohann.chastagnier", alors une nouvelle requête LDAP est réalisée avec le filtre LDAP initial complété de la manière suivante : (&(filtre initial)(sAMAccountName >= yohann.chastagnier))
Or, avec les serveurs MSAD par exemple, il semble exister une différence entre l'algorithme de tri sur un attribut et l'algorithme de traitement d'un filtre sur ce même attribut.
Pour continuer avec l'exemple précédent, s'il existe une entrée dans un résultat LDAP à la place N+1 avec le sAMAccountName "yohann-chastagnier", lorsque le filtre sAMAccountName >= yohann.chastagnier est appliqué, le serveur considère "yohann-chastagnier" comme plus petit que "yohann.chastagnier".
De fait, par cette différente de traitement, certaines entrées peuvent alors être ignorées selon les mouvements opérés sur le serveur LDAP et selon la taille des blocs de résultat de recherche.
Pour éviter cette problématique, une nouvelle méthode à été implémentée dans Silverpeas pour récupérer les blocs de résultat de recherche : le résultat paginé (LDAP Control Extension for Simple Paged Results Manipulation).
Si elle n'est pas supportée par le serveur LDAP, le système bascule sur l'ancienne.
A noter qu'elle est bien prise en charge par MSAD :-)
PR : https://github.com/Silverpeas/Silverpeas-Core/pull/1224
Mis à jour par Miguel Moquillon il y a presque 2 ans
- Statut changé de Resolved à Integration in progress...
Mis à jour par Miguel Moquillon il y a presque 2 ans
- Statut changé de Integration in progress... à Closed
Intégré dans la 6.2.x et dans master