configuration authentification ldap

[seb_dut]

bonjour,

nous n'arrivons pas à configurer alfresco pour permettre l'authentification via un annuaire Ldap.

notre configuration est la suivante :
- Alfresco 2.1
- Tomcat 6.x
- jre 1.5.x
- os Red Hat 4.5
- Annuaire Ldap  : edirectory de novell netware 6.5

La vérification des mécanismes d'authentification autorisés par notre Ldap donne le résultat suivant :

ldapsearch -h [IP LDAP] -p 389 -x -b "" -s base -LLL supportedSASLMechanisms
dn:
supportedSASLMechanisms: EXTERNAL
‍‍‍‍

Nous avons donc tenté d'utiliser le mécanisme simple, en mode anonymous dans le fichier de conf ldap-authentication-context.xml qui a le contenu suivant :

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE beans PUBLIC '-//SPRING//DTD BEAN//EN' 'http://www.springframework.org/dtd/spring-beans.dtd'>
<beans>
    <bean id="authenticationComponent" class="org.alfresco.repo.security.authentication.ldap.LDAPAuthenticationComponentImpl">
        <property name="LDAPInitialDirContextFactory">
            <ref bean="ldapInitialDirContextFactory"/>
        </property>
        <property name="userNameFormat">
            <value>uid=%s,o=[organisation]</value>
        </property>
    </bean>
    <bean id="ldapInitialDirContextFactory" class="org.alfresco.repo.security.authentication.ldap.LDAPInitialDirContextFactoryImpl">
        <property name="initialDirContextEnvironment">
            <map>
                <entry key="java.naming.factory.initial">
                    <value>com.sun.jndi.ldap.LdapCtxFactory</value>
                </entry>
                <entry key="java.naming.provider.url">
                    <value>ldap://[IP LDAP]:389</value>
                </entry>
                <entry key="java.naming.security.authentication">
                    <value>simple</value>
                </entry>
            </map>
        </property>
    </bean>
   </beans>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Après vérif, nous arrivons bien via ldapsearch a trouver l'entrée recherchée dans le ldap en indiquant son uid, en mode anonyme, et via
authentification simple ("-x)  :

ldapsearch -x -h [IP LDAP] -b "o=[organisation]" "(uid=SDUPONT)"
# extended LDIF
#
# LDAPv3
# base <o=[organisation]> with scope sub
# filter: (uid=SDUPONT)
# requesting: ALL
#

# DUPONT, CLT_SERV, INFORMATIQUE, SIEGE, [organisation]
dn: cn=DUPONT,ou=CLT_SERV,ou=INFORMATIQUE,ou=SIEGE,o=[organisation]
uid: SDUPONT
initials: SD
givenName: Sebastien
sn: DUPONT
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
objectClass: ndsLoginProperties
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Après démarrage du service, le log indique

16:43:56,647 WARN  [org.alfresco.repo.security.authentication.ldap.LDAPInitialDirContextFactoryImpl] LDAP server supports anonymous bind ldap://[IP LDAP]:389
16:43:56,648 INFO  [org.alfresco.repo.security.authentication.ldap.LDAPInitialDirContextFactoryImpl] LDAP server does not support simple string user ids and invalid credentials at ldap://[IP LDAP]:389
16:43:56,650 INFO  [org.alfresco.repo.security.authentication.ldap.LDAPInitialDirContextFactoryImpl] LDAP server does not fall back to anonymous bind for a simple dn and password at ldap://[IP LDAP]:389
‍‍‍‍‍

et impossible de se connecter, ni de mieux cerner le problème. Quelqu'un  a-t-il une idée ?

merci !
Sébastien

[rguinot]

Les messages que vous mentionnez sont des WARN et des INFO, donc par définition pas des ERROR, et ne sont pas la cause de vos problèmes de connexion

En revanche, êtes vous sur d'avoir correctement wiré les jobs d'import LDAP  dans le scheduler ?
Avez vous renommé ldap-synchronisation-context.xml.sample en ldap-synchronisation-context.xml dans votre repertoire d'extension ?

Il peut être utile d'activer le DEBUG sur

org.alfresco.repo.importer.ExportSourceImporter‍

pour voir un peu plus en détail ce qu'il se passe

[seb_dut]

bonjour,

je n'ai pas de fichier ldap-synchronisation-context.xml.sample, mais les bean correspondant aux jobs d'import étaient initialement dans le fichier ldap-authentication-context.xml .
Je les avais retiré, ne comprenant pas trop bien le mécanisme de synchro proposé:
Les bean en questions sont les suivants :

<bean id="ldapPeopleExportSource" class="org.alfresco.repo.security.authentication.ldap.LDAPPersonExportSource">
<bean id="ldapGroupExportSource" class="org.alfresco.repo.security.authentication.ldap.LDAPGroupExportSource">
<bean id="ldapPeopleTrigger" class="org.alfresco.util.TriggerBean">
<bean id="ldapGroupTrigger" class="org.alfresco.util.TriggerBean">
<bean id="ldapPeopleImport" class="org.alfresco.repo.importer.ExportSourceImporter">
<bean id="ldapGroupImport" class="org.alfresco.repo.importer.ExportSourceImporter">

Après redémarrage et tentative de connexion, message "Impossible de se connecter - nom d'utilisateur/mot de passe inconnu." sur l'interface client, et aucune info dans le log malgré l'ajout du débug sur ExportSourceImporter …

Si je comprends bien le mécanisme, ExportSourceImporter devrait être appelé sur tentative de login, et donc je devrais avoir au moins une trace dans le log de la tentative : j'ai surement un autre problème, que je vais essayer de résoudre lundi.

[michaelh]

je n'ai pas de fichier ldap-synchronisation-context.xml.sample

En fait en version 2.1 c'est normal. Ce fichier apparait à partir de la 2.1.1. Ca ne change pas grand chose aux principes généraux.

Je ne suis plus très frais pour donner un avis sur les logs ce soir, mais une astuce en attendant : pour activer le debug LDAP complet, ajouter les lignes suivantes au fichier "log4j.properties"

log4j.logger.org.alfresco.repo.importer.ImporterJob=debug
log4j.logger.org.alfresco.repo.importer.ExportSourceImporter=debug
log4j.logger.org.alfresco.repo.security.authentication.ldap=debug‍‍‍‍

A lundi donc !

EDIT : je me rends compte que Romain a déjà parlé de debug … bon … c'est un signe de plus => dodo

[seb_dut]

bonjour,

bon, je progresse très doucement :
j'ai décommenté les schedulers des beans "ldapPeopleTrigger" et "ldapGroupTrigger", ce qui a permis au redémarrage du service tomcat de faire l'import des users présents dans notre ldap, modulo les erreurs dues à des informations obligatoires non présentes sur certaines entrées :

10:35:52,557 WARN  [org.alfresco.repo.security.authentication.ldap.LDAPGroupExportSource] Missing GID on {objectclass=        objectClass: groupOfNames, top}
…
10:35:52,592 DEBUG [org.alfresco.repo.security.authentication.ldap.LDAPPersonExportSource] Adding user for SDUPONT
…

Je reste cependant toujours bloqué sur l'écran de connexion, avec un message "impossible de se connecter, user/pwd inconnu", et je n'ai aucun log qui trace la tentative de connexion, alors que j'ai bien mis les logs en debug

log4j.logger.org.alfresco.repo.security.authentication=debug

En redémarrant alfresco sans l'extension ldap, j'arrive bien à me connecter avec les comptes hors ldap qui existaient auparavant (compte admin), et je vérifie bien l'existence des comptes crées par l'import ldap.

Par contre, impossible de me connecter aux comptes crées via l'import Ldap…quel pwd utiliser ?

Je sèche un peu, si personne n'a d'idée magique, je retenterai sur une version plus récente d'Alfresco.

[michaelh]

Les utilisateurs sont stockés sous quelle forme ? Parfois il faut passer par user@domain pour se connecter (je ne sais pas ce qu'attend edirectory, je n'en ai jamais croisé)

J'avoue que je sèche un peu là

En tout cas si vous êtes en version 2.1.0, un passage en version supérieure ne changera rien, ça fonctionne bien normalement …

[rguinot]

Je n'ai pas les fichiers de conf sous la main, mais il faut voir a quelle propriété du LDAP tu as mappé la propriété qui te sert à te logger dans Alfresco (peut être l'uid, le cn , ou autres).

Comme Michaël, je n'ai jamais croisé d'edirectory.

[seb_dut]

bonjour,

j'ai trouvé d'où venait le problème, j'avais effectivement fait une boulette sur le mapping qui était en cause, désolé de vous avoir ennuyé.

Pour la petite histoire,

j'avais essayé les trois mappings suivants, sans résultat :
<property name="userNameFormat"><value>%s</value></property>
<property name="userNameFormat"><value>uid=%s</value></property>
<property name="userNameFormat"><value>uid=%s,o=[organisation]</value></property>

Le ldap a en effet une organisation que je ne maitrise pas, en visualisant avec ldap brower, ça ressemble à ça :

o=[organisation]
cn=[hors sujet]
…(plein d'autres entrées ne correspondant pas à des users mais à d'autres problématiques)
cn=[hors sujet]
ou=SIEGE
     ou=INFORMATIQUE
               ou=CLT_SERV
                     cn=DUPONT
     ou=EXTERNE
          cn=MARTIN  
ou=REGION1
     cn=DURAND
…
ou=REGION2
ou=REGION3‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

et l'entrée DUPONT dispose des infos suivantes :

givenName   Sebastien
initials   SD
sn   DUPONT
mail   s.dupont@[organisation].fr
objectClass   inetOrgPerson
objectClass   organizationalPerson
objectClass   person
objectClass   top
objectClass   ndsLoginProperties
uid   SDUPONT
‍‍‍‍‍‍‍‍‍‍‍

L'utilisation du cn m'embêtait, car l'unicité n'est pas assurée. Et donc je préférais prendre l'uid, plus sûr, qui a la forme suivante : [1ère lettre du prénom][nom].

J'ai testé le mapping suivant, et ça marche finalement :
<value>cn=%s,ou=SIEGE,ou=INFORMATIQUE,ou=CLT_SERV,o=[organisation]</value>

Par contre en ne filant que cn=%s, cela ne passe pas, il faut fournir un chemin complet ce qui m'arrange pas.

Ce qui m'a induit en erreur, c'est que la recherche via uid avec ldapsarch marchait :
ldapsearch -x -h [ip LDAP] -b "o=[organisation]" uid=SDUPONT -LLL

Ldapsearch semble parcourir tout l'arbre…

Finalement, vu que le chemin complet est nécessaire, je sens que je vais être obligé de modifier le formulaire de connexion pour adjoindre au login le chemin complet, de façon à récupérer dans %s un identifiant complet.

Par contre le jour où j'ai deux utilisateurs dans le même chemin, je serai coincé :-)
Si quelqu'un a une solution plus élégante, je suis preneur !

merci à tous pour votre aide !

[lme]

Pour authentifier avec un annuaire, on peut dire qu'il existe 2 méthodes :

- search + bind : On fait d'abord une recherche dans l'annuaire avec le login (du genre uid=toto), on obtient alors le DN complet (cn=toto,dc=truc,o=orga…) et on peut tenter un bind de l'utilisateur avec son DN complet et son mot de passe. Problème : que faire si la recherche retourne plusieurs résultats ?

- bind : On construit le DN complet de l'utilisateur à partir de son login et on tente un bind sur l'annuaire avec le DN et le mot de passe.

Alfresco utilise la 2nd solution, c'est pourquoi tu dois renseigner ceci :

<value>cn=%s,ou=SIEGE,ou=INFORMATIQUE,ou=CLT_SERV,o=[organisation]</value>‍

De mémoire, un utilisateur du forum avait modifié le code d'Alfresco pour utiliser la 1ère méthode. Je te laisse le soin de retrouver son post