Configuration et fonctionnement du LDAP dans JCMS

1. Configuration

La configuration LDAP se fait via l'éditeur de propriétés dans l'onglet LDAP.

Consultez les bulles d'aide lors de la configuration, elles vous donneront les informations nécessaires.

Pour les filtres de recherche la syntaxe à respecter est celle de la norme LDAP. Un aperçu basique des possibilités de filtrage est présenté dans l'article suivant sur le site de Microsoft :
http://technet.microsoft.com/en-us/library/aa996205(EXCHG.65).aspx

2. Fonctionnement

JCMS utilise le serveur LDAP pour permettre l'authentification des utilisateurs si celle-ci est effectué par login / mot de passe, ainsi que pour effectuer la synchronisation des membres et des groupes avec les données de l'annuaire

2.1 Authentification

Lorsqu'un utilisateur tente de s'authentifier à JCMS en utilisant un login et un mot de passe, si un utilisateur LDAP correspondant est trouvé dans l'annuaire, alors les identifiants sont validés auprès du serveur LDAP pour autoriser l'authentification.

2.2 Synchronisation des membres et des groupes

Il existe 5 cas différents pour la synchronisation des membres et des groupes dans JCMS : 

  1. L'utilisateur s'authentifie, le membre et ses groupes sont synchronisés
    lors de l'authentification réussie d'un utilisateur
  2. Un administrateur demande la synchronisation d'un groupe LDAP
    dans liste des groupes via l'icône d'éclair "Synchroniser avec LDAP..."
  3. Un administrateur demande la synchronisation des membres LDAP d'un groupe quelconque (LDAP ou non)
    dans la liste des membres via le bouton "Synchroniser les membres LDAP de ce groupe..."
  4. Un administrateur demande la synchronisation de tous les membres LDAP existant
    dans la listes des membres via le bouton "Synchroniser tous les membres LDAP..."
  5. Un administrateur demande la synchronisation d'un membre
    dans l'édition d'un membre via le bouton "Synchroniser avec LDAP...", ou dans le menu contextuel d'un membre via le choix "Synchroniser avec LDAP..."

Chacune de ces actions déclenche un comportement spécifique de synchronisation expliqué ci-dessous.

2.2.1 L'utilisateur s'authentifie, le membre et ses groupes sont synchronisés

  • Quand : à la connexion d'un utilisateur
  • Comment : quand l'utilisateur a entré des identifiants valides du LDAP
  • Le membre est synchronisé, ses groupes sont entièrement mis à jour, s'il n'appartient plus à un groupe il en est retiré, s'il appartient à un nouveau groupe il est ajouté

Dans le détail, lors de la connexion d'un utilisateur à JCMS, le processus de synchronisation LDAP est le suivant :

  1. Connexion au LDAP avec le dn/pass admin,
  2. Récupération de l'entrée LDAP correspondant à l'utilisateur en cours d'authentification,
  3. Authentification : Connexion/Déconnexion au LDAP avec le dn/pass de l'utilisateur pour validation du mot de passe,
  4. Synchronisation du Membre JCMS avec les données du LDAP ;
    1. Récupération des groupes de l'utilisateur,
    2. Récupération des parents des groupes de l'utilisateur,
  5. Déconnexion.

Note : l'authentification par login/mot de passe est le seul cas pendant lequel 2 connexions LDAP sont créées :

  • une connexion avec les identifiants de l'utilisateur destinée uniquement à valider informations de connexion (logins / mot de passe).
  • une connexion administrateur pour la récupération et la synchronisation du membre et de ses groupes

2.2.2 Un administrateur demande la synchronisation d'un groupe LDAP

  • Où : dans la liste des groupes (groupList.jsp)
  • Comment : Icone éclair Icône de synchronisation LDAP"Synchroniser avec LDAP...", disponible sur les groupes LDAP,
  • Cette action déclenche la synchronisation du groupe à partir des informations du LDAP
    Les sous groupes et membres renvoyés par le LDAP sont mis à jour

2.2.3 Un administrateur demande la synchronisation des membres LDAP d'un groupe quelconque (LDAP ou non)

  • Où : dans la liste des membres (memberList.jsp et autres listes identiques), quand un groupe est sélectionné
  • Comment : via le bouton "Synchroniser les membres LDAP de ce groupe..."
  • Les membres JStore du groupe sont itérés et s'il s'agit d'un membre LDAP, le membre est synchronisé, ses groupes sont entièrement mis à jour, s'il n'appartient plus à un groupe il en est retiré, s'il appartient à un nouveau groupe il est ajouté

2.2.4 Un administrateur demande la synchronisation de tous les membres LDAP existant

  • Où : dans la liste des membres (memberList.jsp et autres listes identiques), quand aucun groupe n'est sélectionné
  • Comment : via le bouton "Synchroniser tous les membres LDAP..."
  • Tous les membres JStore sont itérés et s'il s'agit d'un membre LDAP, le membre est synchronisé, ses groupes sont entièrement mis à jour, s'il n'appartient plus à un groupe il en est retiré, s'il appartient à un nouveau groupe il est ajouté

2.2.5 Un administrateur demande la synchronisation d'un membre

  • Où et comment :
    • lors de l'édition d'un membre (editMember.jsp), via le bouton "Synchroniser avec LDAP..."
    • dans le menu contextuel d'un membre, via le choix "Synchroniser avec LDAP..."
  • Le membre est synchronisé, ses groupes sont entièrement mis à jour, s'il n'appartient plus à un groupe il en est retiré, s'il appartient à un nouveau groupe il est ajouté.

2.3 Intégration avec un SSO

Les modules d'authentification par SSO (CAS, Windows Waffle, NTLM, ClearTrusts, ...) sont compatibles avec la synchronisation LDAP : ils récupèrent le login du membre et s'appuient sur JCMS pour la synchronisation LDAP du membre.

Avec ce fonctionnement, il est tout à fait possible d'utiliser un référentiel d'authentification "A" pour le SSO et un annuaire LDAP "B" pour JCMS, tant que le login de l'utilisateur est le même dans les deux.

3. Configuration de plusieurs annuaires LDAP (JCMS 8 et au delà)

JCMS 8 permet d’authentifier un membre et de récupérer ses informations à partir de plusieurs annuaires LDAP.

3.1 Multi-LDAP : Pré-requis

Deux pré-requis sont indispensables pour activer cette fonctionnalité :

  1. Schéma Identique sur tous les annuaires :
    les schéma doivent être identiques sur tous les annuaires
  2. Information discriminante pour la sélection de l'annuaire :
    Il est nécessaire de disposer d'une information discriminante pour permettre le choix du bon annuaire LDAP lors de synchronisation d'un membre ou d'un groupe. 
    • à l'authentification : le login
      • identifiant bas niveauDOMAIN\sAMAccountName, ex:contoso\smith (discriminant "contoso")
      • userPrincipalName, ex: smith@contoso.local (discriminant "contoso.local")
      • email, ex: john.smith@contoso.com (discriminant "contoso.com")
      • sAMAccountName, ex: smith OK pour configuration par défaut, insuffisant autrement car pas de discriminant
    • à la synchronisation d'un membre : Attention, son login doit contenir les informations identiques utilisé lors de l'authentification, il est donc capital de faire un mapping du login qui contienne cette information discriminante
    • à la synchronisation d'un groupe : Le DN du groupe LDAP

3.2 Multi-LDAP : Configuration et Fonctionnement

La configuration du Multi-LDAP s'effectue en éditant le fichier custom.prop

3.2.1 Configuration des annuaires

  • Chaque annuaire LDAP est configuré dans les propriétés JCMS :
    • l'annuaire par défaut est configuré via les propriétés LDAP déjà existantes dans JCMS : ldap.server.* 
      ces propriétés sont accessibles dans l'interface d'administrations de JCMS
    • les autres annuaires sont configurés via les propriétés ldap.server.{id}.* où {id} est un identifiant spécifique à chaque annuaire (en minuscule). c'est généralement ce qui sert de "discriminant" pour choisir le ldap concerné.
    • Pour les annuaires Windows, on utilisera de préférence comme identifiant le nom du domaine, en minuscule.
      Ces propriétés doivent être saisies manuellement dans les fichiers de propriétés
  • Seul les propriétés ldap.server.* peuvent être configurées de manière spécifique à chaque domaine :
    • L'activation du LDAP dans JCMS reste commun à tous les annuaires, via la propriété ldap.enabled
    • Le mapping avec le schéma est commun à tous les annuaires, il est déclaré via les propriétés ldap.mapping.* et ldap.grp-mapping.*
  • Des alias de configuration peuvent être ajoutés pour créer des références vers une autre configuration.
    Ils permettent la résolution de l'annuaire à utiliser lors de l'authentification et de la synchronisation (cf explication ci après)
    ldap.conf-aliases.{alias-name}: {conf-id}
    • {conf-id} est l'identifiant d'une configuration existante, ({id} dans le premier exemple)
    • {alias-name} est un nom alternatif donné à cette configuration utilisé dans le processus de recherche

3.2.2 Processus de recherche de la configuration LDAP

La configuration LDAP à utiliser est détectée dans plusieurs circonstances :

  • à l'authentification d'un membre : le login saisi par l'utilisateur doit contenir une information discriminante :
    • si c'est un login au format userPrincipalName ou email (ex: smith@CONTOSO.local ou john.smith@contoso.com) : le texte après le caractère "@" est extrait puis utilisé dans le processus de recherche expliqué ci-dessous (ex: contoso.local ou contoso.com)
    • si c'est un login au format down-level logon name (ex: CONTOSO\smith) : le texte précédent le caractère "\" est extrait puis utilisé dans le processus de recherche expliqué ci dessous (ex: contoso)
  • à la synchronisation d'un membre (depuis le back office) : le même processus de recherche de configuration s'applique, en utilisant dans ce cas le champ login du membre
  • à la synchronisation d'un groupe :
    • Pendant l'authentification d'un membre : la configuration sélectionnée pour le membre s'applique,
    • Depuis le back office : Le DN du groupe à synchroniser est extrait et la première configuration ayant un DN de recherche correspondant est retournée.

Dans les cas de synchronisation de membres évoqués ci-dessus, une chaîne de caractère discriminante a été extraite du contexte d'authentification ou de synchronisation. C'est cette chaîne de caractère (en minuscule) qui utilisée pour recherchet la configuration appropriée, la plupart du temps, cette chaine correspondra au domaine Windows :

  1. D'abord en utilisant ce texte pour rechercher les propriétés via le {id} 
    Par exemple, si le texte extrait est CONTOSO, une configuration ldap.server.contoso.* sera utilisée si elle existe.
  2. Puis via les conf-aliases 
    Par exemple, si le texte extrait est contoso.local ou contoso.com , les alias suivants pourront être utilisés si ils ont été déclarés et qu'ils référencent une configuration valide :
    • ldap.conf-aliases.contoso.local: contoso
    • ldap.conf-aliases.contoso.com: contoso

Si aucune chaîne discriminante n'a pu être extraite du contexte, c'est la configuration par défaut qui s'applique.

3.2.3 Exemple Contoso / Trey

Exemple :

  • La société Contoso a 2 domaines Active Directory CONTOSO et TREY (une récente acquisition)
  • 2 configurations LDAP sont créées dans les propriétés :
    • ldap.server.* pour la configuration par défaut du domaine CONTOSO
    • ldap.server.trey.* pour la configuration du domaine TREY
  • certains paramètres ne sont précisés que pour la configuration par défaut car TREY utilise les mêmes réglages (identifiants de connexion, et filtres de recherche)
  • le mapping est obligatoirement commun à tous les annuaires

 

ldap.enabled: true
ldap.synchronize.enable: true
ldap.synchronize-groups.enable: false
ldap.server.ssl: false    
ldap.server.port: 389 
ldap.server.sizelimit: 100
ldap.server.timelimit: 0
ldap.server.version: 3

# Default configuration
ldap.server.hostname: 192.168.0.123
ldap.server.suffix: cn=Users,dc=Contoso,dc=com
ldap.server.groupsuffix: ou=Users,dc=Contoso,dc=com

# Trey 
ldap.server.trey.hostname: 192.168.0.124
ldap.server.trey.suffix: cn=Users,dc=Trey,dc=local
ldap.server.trey.groupsuffix: ou=Users,dc=Trey,dc=local
ldap.conf-aliases.trey.local: trey
ldap.conf-aliases.trey.com: trey

# Credentials -> in our case, use same for all directories
ldap.server.login: Directory Manager
ldap.server.password: REVTMzo=abzcxdef123246==  

# Search filter -> again, in our example they are common to all directories 
ldap.server.userfilter: (&(objectClass=person)(objectClass=user)(userPrincipalName={0}))
ldap.server.userobjectclass: user
ldap.server.groupfilter: (&(objectClass=group)(member={0}))
ldap.server.groupobjectclass: group

# LDAP Mapping (obligatory common to all directories) 
ldap.mapping.login: userPrincipalName
ldap.mapping.name: sn
ldap.mapping.f-name: givenName
ldap.mapping.salut: 
ldap.mapping.organization: organizationName
ldap.mapping.department: department
ldap.mapping.job: title
ldap.mapping.mail: mail
ldap.mapping.phone: telephoneNumber
ldap.mapping.mobile: mobile
ldap.mapping.address: streetAddress
ldap.mapping.info: description
ldap.grp-mapping.name: cn
ldap.grp-mapping.member: member

3.3 Multi-LDAP : Configuration Open API (REST)

Lorsque l'Open API (REST) est utilisée en environnement multi-LDAP avec des identifiant bas niveau comme login (e.g. DOMAIN\sAMAccountName), par exemple depuis l'addin Microsoft, il est nécessaire de configurer les frontaux (Apache) et les serveurs d'applications (Tomcat) pour autoriser l'utilisation des backslash ( \) dans les URLs.

Sur Apache HTTPD :

Ajouter la directive suivante dans la configuration de Apache :

AllowEncodedSlashes On

Consultez la documentation officielle de Apache HTTPD pour plus d'informations :
http://httpd.apache.org/docs/2.2/mod/core.html#allowencodedslashes

Sur Apache HTTPD concernant mod_jk :

L'option +ForwardURIProxy doit être utilisée (c'est la valeur par défaut en l'absence de précision) : 

JkOptions +ForwardURIProxy

Les autres options de gestion d'URI sont incompatibles avec le Multi-LDAP pour l'API REST.
Consultez la documentation officielle du connecteur jk pour plus d'informations :

http://tomcat.apache.org/connectors-doc/reference/apache.html

Sur Tomcat :

Exécuter Tomcat avec les propriétés suivantes : 

-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true 
-Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true

Consultez la documentation officielle de Tomcat pour plus d'information : http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html 

4. Limites

4.1 LDAP Referrals

JCMS ne supporte pas LDAP Referrals. Cela veut dire qu'il n'est pas possible de synchroniser les données d'un LDAP qui sont en fait réparties sur plusieurs autres annuaires LDAP.

2 solutions pour contourner cette limitation :

  1. Utiliser un meta-annuaire LDAP qui se chargera de faire l'agrégation complète des informations réparties sur les différents serveurs LDAP.
    Avec ActiveDirectory il est possible de résoudre ce problème en désignant le serveur LDAP comme catalogue global, puis en configurant JCMS pour contacter le catalogue global sur le port 3226.
    http://technet.microsoft.com/en-us/library/cc728188(WS.10).aspx
    http://www.crhea.cnrs.fr/Cours%20info/fr/Catalogue global.pdf
  2. A partir de JCMS 8, configurez plusieurs annuaires LDAP pour permettre la synchronisation des utilisateurs des groupes à partir de plusieurs annuaires.
    Attention : le support de plusieurs annuaires LDAP dans JCMS 8 n'ajoute pas le support des LDAP Referrals et toutes les données à synchroniser pour un membre ou un groupe doivent se trouver sur le même annuaire.

4.2 Groupes Cycliques

Il n'est pas possible de synchroniser dans JCMS une arborescence de groupe cyclique (p.ex. Group 1 est parent de Groupe 2, lui même parent de Groupe 3, lui même parent du Groupe 1).

La synchronisation est effectuée par JCMS mais sans le cycle, l'arborescence reproduite dans JCMS sera dépendante du premier groupe synchronisé (eg si le Groupe 2 est le premier groupe synchronisé, alors l'arborescence commencera au Groupe 3).

4.3 Multi LDAP : Récupération des groupes des utilisateurs

Les groupes d'un utilisateurs sont récupérés uniquement sur l'annuaire LDAP à partir duquel l'utilisateur a été synchronisé.

Ce mode fonctionnement garanti un cloisonnement des annuaires : les informations d'un membre et ses groupes sont toutes récupérés dans un seul et unique endroit. De plus ce choix est plus performant car une seule connexion LDAP est effectuée pour la synchronisation du membre.

Ce comportement peut être adapté selon vos besoins via un développement spécifique dans la classe custom.LdapAuthenticationHandler

5. Développements spécifiques

5.1 Sur la synchronisation

Le fichier source de la classe custom.LdapAuthenticationHandler est volontairement inclus dans JCMS pour permettre des développements avancés.

Exemples :

  • Synchronisation de droits en fonction de groupes spécifiques du LDAP
  • Ajout d'ExtraData pour la synchronisation de champs supplémentaires
  • ...

5.2 Sur un module SSO

Principe général : Le SSO s'occupe de la partie authentification, puis un module JCMS récupère le login et délègue la synchronisation du Membre aux couches standards de JCMS.

Dans votre module, après avoir récupéré le login via le SSO, déclenchez la synchronisation comme suit :

/**
   * Try to connect to the ldap and update/create the member with the given login.
   *
   * @param login the ldap username of the user to create
   * @return the newly created or updated JCMS Member
   */
  private Member synchronizeAccount(String login) {
    if (!channel.isLdapEnabled()) {
      return null;
    }
    
    // Retrieve the last available configuration (updated by channel)
    // and open a connection using the mapper
    LDAPConfiguration ldapConf = channel.getLDAPConfiguration();
    LDAPMapper mapper = new LDAPMapper(ldapConf);
    if (!mapper.isConnected()) {
      logger.warn("Could not connect to LDAP", mapper.getLastException());
      return null;
    }

    // Search user and synchronize
    Member member = LdapAuthenticationHandler.synchronizeAccount(mapper,
                               login,  /* login: retrieved from NTLM */
                               null,   /* password: we don't have it*/
                               channel.getDefaultAdmin(), /* opAuthor */
                               false,  /* checkConnect: no need to check connection as it was done by SSO, and we don't have the password, so it wouldn't work */
                               true    /* synchronize, that's the purpose! */);
    if (member == null) {
      logger.warn("Could not synchronize SSO member \""+login+"\" with LDAP", mapper.getLastException());
    }

    mapper.disconnect();
    return member;
  }

5.3 Ecriture dans le LDAP

Bien que cela ne soit jamais utilisé en standard, l'API LDAP utilisée dans JCMS permet l'écriture dans le LDAP.
Consultez la documentation sur l'API ci dessous pour plus d'informations à ce sujet.

Un exemple de code pour modifier le mot de passe d'un utilisateur ActiveDirectory est disponible dans la section questions/réponses.

5.4 Documentation sur l'API LDAP (liens)

L'API LDAP dans JCMS se divise en 2 parties :

6. Processus de résolution d'incident

A vérifier au préalable :

  • BASIQUE : Un essai de connexion dans l'édition de propriété est validé.
  • Le DN qui est spécifié dans les propriétés de JCMS pour la connexion au LDAP DOIT impérativement disposer des droits de recherche/lecture sur le LDAP pour récupérer les informations de synchronisation.
  • Absence de développements spécifiques sur custom.LdapAuthenticationHandler
  • Sensibilité à la casse dans la configuration : "groupofuniquenames" n'est pas égal à "groupOfUniqueNames"

Si le problème persiste :

  1. Activation des logs dans log4j.xml :
    1. mode DEBUG sur custom.LdapAuthenticationHandler
    2. mode TRACE sur com.jalios.ldap
    3. mode TRACE sur com.jalios.jcms.ldap
    Objectif : cerner où se trouve le blocage.
    Important : Récupérez les logs dans le fichier jcms.log (pas ceux affichés sur la console) car ces logs contiennent plus d'informations qui matérialisent beaucoup mieux les appels récursifs pour la synchronisation des groupes.
  2. Récupération d'un export LDIF du serveur LDAP avec au minimum 1 Groupe et 1 Membre.
    Objectif : valider le schéma et la configuration de la webapp.

7. Questions/Réponses

Ces questions/réponses sont issues du support Jalios ou de réponses à appel d'offre.

7.1 [ActiveDirectory] Est-il possible de modifier le mot de passe du LDAP depuis JCMS

En principe oui, le code suivant peut servir de base de départ pour modifier le mot de passe d'un utilisateur ActiveDirectory.
ATTENTION CODE NON TESTE, A ADAPTE A VOTRE USAGE ! 

  /**
   * Update the password of the specified Member in the ActiveDirectory.
   * @param member the member for which password will be updated
   * @param newClearTextPassword the new password, in clear text form
   * @return true if updated was successful, false otherwise
   */
  public static boolean updateActiveDirectoryUserPassword(Member member, String newClearTextPassword) {
    // 1. Connect to LDAP
    LDAPConfiguration ldapConf = channel.getLDAPConfiguration();
    LDAPMapper mapper = new LDAPMapper(ldapConf);
    
    // 2. Update & disconnect
    boolean passwordUpdated = false;
    if (!mapper.isConnected()) {
      logger.warn("Could not connect to LDAP", mapper.getLastException());
    } else {
      updateActiveDirectoryUserPassword(mapper, member.getLogin(), newClearTextPassword);
      mapper.disconnect();
    }
    
    return passwordUpdated;
  }
 
  /**
   * Update the password of the specified Member in the ActiveDirectory.
   * @param mapper the LDAPMapper instance
   * @param login the login of the member for which modification is performed
   * @param newClearTextPassword the new password, in clear text form
   * @return true if updated was successful, false otherwise
   */
  public static boolean updateActiveDirectoryUserPassword(LDAPMapper mapper, String login, String newClearTextPassword) {
    LDAPEntry entry = mapper.getUserLDAPEntry(login, USER_ATTRIBUTES);
    if (entry == null) {
      return false;
    }
    
    // The password modify operation MUST occurs over SSL
    if (!channel.getLDAPConfiguration().isSSL()) {
      logger.warn("Updating user password with ActiveDirectory MUST be performed over SSL. Configure LDAP using SSL.");
      return false;
    }
    
    // http://support.microsoft.com/?kbid=269190
    // http://forums.sun.com/thread.jspa?threadID=592611
    // http://docs.sun.com/source/816-6402-10/addmod.htm#2842939
    
    LDAPAttribute newPasswordAttribute = new LDAPAttribute("unicodePwd", newClearTextPassword);
    LDAPModification ldapPasswordMod = new LDAPModification(LDAPModification.REPLACE, newPasswordAttribute);
    try {
      mapper.getLDAPConnection().modify(entry.getDN(), ldapPasswordMod);
    } catch (LDAPException ex) {
      logger.warn("Could not update ActiveDirectory password for user '" + entry.getDN() + "'", ex);
      return false;
    }
    
    return true;
  }

Il faut invoquer ce code dans un DataController lors de l'édition d'un membre, ou dans un JSP d'édition dédié au changement de mot de passe.

7.2 [ActiveDirectory] Est-il possible de synchroniser une Unité Organisationnelle (OU) et ses sous groupes.

Non.
JCMS permet en standard la synchronisation des arborescences de groupes et de leur sous-groupes. Mais pour ce qui est des Unités Organisationnelles ActiveDirectory, vous devez recourir soit à une modification de l'annuaire LDAP, soit à un développement spécifique dans JCMS.

Explication :

La synchronisation d'un groupe dans JCMS fonctionne en 3 étapes :

  1. On vérifie que l'entrée LDAP demandée est bien un groupe.
    Pour cela, on vérifie qu'il correspond à l'objectClass défini dans les propriétés de JCMS (dans le cas d'un annuaire ActiveDirectory, il s'agit de l'objectClass "group").
  2. On récupère le nom du groupe :
    Pour le nom du groupe, JCMS consulte l'attribut "Nom" tel que renseigné dans les propriétés de JCMS (dans le cas d'un annuaire ActiveDirectory, il s'agit de la propriété "cn").
  3. On récupère l'ensemble des "fils" du groupe (que cela soit des utilisateurs ou des groupes)
    Pour récupérer ces fils, JCMS consulte l'attribut "Membres" du groupe parent tel que renseigné dans les propriétés de JCMS (dans le cas d'un annuaire ActiveDirectory, il s'agit de la propriété "member").
    -> Dans le cas des OU d'ActiveDirectory, il n'existe pas de possibilité de récupérer les "fils" via un attribut spécifique de l'OU.

-> Les Unités Organisationnelles ActiveDirectory ne présentent aucun point commun avec un Groupe :

  • objectClass différentes
  • noms différents
  • pas de possibilité de récupérer la liste des sous-éléments

A ce titre, elles ne sont donc pas prises en compte par la mécanique générique de synchronisation des groupes de JCMS.

Solutions :
Les 2 possibilités sont donc :

  1. Modifier l'annuaire pour faire en sorte que les Unités Organisationnelles répondent aux contraintes suivantes :
    1. contiennent l'objectClass group (ou tout autre objectClass également commune avec les groupes à synchroniser)
    2. disposent d'un nom via l'attribut "cn" (ou tout autre attribut commun avec les groupes à synchroniser...)
    3. sous-groupes accessibles via l'attribut "member"... (ou tout autre attribut commun avec les groupes à synchroniser...)
  2. Réaliser un développement spécifique pour permettre cette synchronisation sans modification du schéma LDAP :
    Le code de synchronisation des utilisateurs et des groupes LDAP est volontairement ouvert dans JCMS pour permettre sa personnalisation selon les cas d'usages clients. Tout est disponible dans la classe WEB-INF/classes/custom/LdapAuthenticationHandler.java
    Jalios peut vous proposer une prestation pour réaliser ou vous assister dans cette tâche, et vous invite donc à consulter ses commerciaux si vous souhaitez partir sur cette piste.