Connexion a partir d'un annuaire

[9年前 に Emilien Bécu によって更新されました。]

Bonjour,

J'ai un problèmes avec l'authentification Liferay à partir d'un openLDAP, j'ai correctement configuré via l'interface graphique Liferay, et j'arrive à me logguer avec (user1) mais avec lui seulement, j'ai monté le niveau de log et je voit ceci quand je tente une connexion avec autre compte par ex : (user2)

14:08:58,948 DEBUG [ajp-bio-8009-exec-6][DefaultLDAPToPortalConverter:101] Screen name (user1) and email address (user1)@liferay.com
14:08:58,956 DEBUG [ajp-bio-8009-exec-6][PortalLDAPImporterImpl:1196] User (user1)@liferay.com is already synchronized, but updated password to avoid a blank value
14:08:58,958 WARN [ajp-bio-8009-exec-6][PortalLDAPImporterImpl:1098] Unable to populate expando attributes
14:08:58,959 DEBUG [ajp-bio-8009-exec-6][PortalLDAPImporterImpl:1102] com.liferay.portlet.expando.NoSuchTableException: No ExpandoTable exists with the key {companyId=10253, classNameId=10105, name=CUSTOM_FIELDS}
com.liferay.portlet.expando.NoSuchTableException: No ExpandoTable exists with the key {companyId=10253, classNameId=10105, name=CUSTOM_FIELDS}
at com.liferay.portlet.expando.service.persistence.ExpandoTablePersistenceImpl.findByC_C_N(ExpandoTablePersistenceImpl.java:986)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.liferay.portal.security.lang.DoPrivilegedHandler.doInvoke(DoPrivilegedHandler.java:88)
at com.liferay.portal.security.lang.DoPrivilegedHandler.invoke(DoPrivilegedHandler.java:56)
at com.sun.proxy.$Proxy539.findByC_C_N(Unknown Source)
at com.liferay.portlet.expando.service.impl.Exp

C'est comme si il tente d'utiliser le même compte pour se connecter tout le temps, j'ai même tester de mettre le même mot de passe sur le user2 que sur le user1 et ça fonctionne pas, je n'ai aucune idée de ou peut venir ce problème.

Merci pour (future) aide

[9年前 に Darryl Kpizingui によって更新されました。]

Bonjour,

Avez-vous vérifié que la requête vers le LDAP ne renvoie pas toujours un seul et même utilisateur (user1) au lieu de tous les utilisateurs disponibles dans celui-ci ?
L'utilisateur (user2) a t-il été importé dans Liferay?
Comment se fait le lien entre le login Liferay et l'identifiant de l'utilisateur dans le LDAP?

ldap.auth.search.filter.0=(uid=@screen_name@)

[9年前 に Emilien Bécu によって更新されました。]

Darryl Kpizingui:

Avez-vous vérifié que la requête vers le LDAP ne renvoie pas toujours un seul et même utilisateur (user1) au lieu de tous les utilisateurs disponibles dans celui-ci ?

Je n'ai pas de requête LDAP dans mes logs, j'ai pourtant monter le niveau en debug sur tout ce qui concerne le LDAP... j'ai tenté de supprimer le user1 sur lequel liferay reste bloqué et j'ai réussi à me connecter avec le user2, seulement maintenant le user1 ne peux plus se connecter et j'ai toujours le user2 qui apparait dans les logs quand je tente une connexion avec n'importe quel user du ldap...

Darryl Kpizingui:

L'utilisateur (user2) a t-il été importé dans Liferay?

Oui l'utilisateur s'importe bien à la première connexion, le mappage des attributs me semble correct, j'ai le minimum d'info (volontaire de ma part pour éviter des erreurs), les infos importé pour le user Liferay sont le login, mail, prénom, nom, mot de passe..

Darryl Kpizingui:

Comment se fait le lien entre le login Liferay et l'identifiant de l'utilisateur dans le LDAP?

Si c'est a propos du bind ou password-compare, j'en n'ai aucune idée, j'ai configuré le login liferay avec LDAP depuis l'interface graphique, je peux le faire dans le fichier portal-ext.properties, mais ce sera plus tard quand tout fonctionnera bien, j'irai dans la BDD récupérer le code xml pour le remettre dans le fichier portal-ext.

Darryl Kpizingui:

ldap.auth.search.filter.0=(uid=@screen_name@)

Voici la config que j'ai dans l'interface graphique (les valeurs en # sont correctement renseigné chez moi, je ne peux juste pas les transmettre)

[9年前 に Darryl Kpizingui によって更新されました。]

Je n'ai pas vu dans les captures d'écran, le paramétrage du binding des utilisateurs. Vous deviez avoir un champ "Filtre De Recherche D'Authentification " qui est le filtre que Liferay utilise pour recuperer l'utilisateur du LDAP lors de l'authentification. Si vous ne saisissez rien, je pense que Liferay va prendre tous les utilisateur du LDAP se basant sur le filtre de recherche. Ensuite, le premier dans la liste est importé. Ce qui pourrait expliqué pourquoi vous avez le user1 à chaque fois, et puis le user2 quand vous avez supprimer le user1 du LDAP (?).

Vu que vous vous connectiez avec l'adresse email, le filtre pourrait être CHAMP_EMAIL_DANS_LDAP=@email_address@.

Sinon, vous pouvez mettre un point d'arrêt dans la méthode ci-dessous à la ligne 250 pour voir exactement ce qui se passe.

//package com.liferay.portal.security.ldap;
public User importLDAPUser(
long ldapServerId, long companyId, String emailAddress,
String screenName)

[9年前 に Emilien Bécu によって更新されました。]

Pardon, il manque en effet une capture ecran la voici :


Cette solution me semble bonne : CHAMP_EMAIL_DANS_LDAP=@email_address@.

Mais dans mon LDAP mes utilisateurs issu d'un export UNIX :


Je ne sais pas à quoi ressemble une requête LDAP que Liferay peut faire, il regarde le nom de l'objet? dans mon cas uid=user1, ou mieux il cherche dans les attribut de chaque objet?

Pour le point d'arrêt, je ne maitrise pas cette technique, est ce que vous auriez un tutoriel à me recommander? Le serveur que je possède n'est joingnable que par ssh, je n'ai pas d'interface graphique. Je le dit au cas oui cela poserai problème pour la méthode de debug

[9年前 に Darryl Kpizingui によって更新されました。]

Cette solution me semble bonne : CHAMP_EMAIL_DANS_LDAP=@email_address@.

Cela règle t-il votre problème?

Sinon le problème évident à votre démarche est le filtre d'authentification : (ObjectClass=person)(uid=@user_id@)
1) L'authentification se fait par adresse email, le user_id est donc inconnu et aura toujours la valeur 0. Votre utilisateur sera donc toujours(ObjectClass=person)(uid=0).
2) Le filtre devrait être (mail=@email_address@)

L'authentification se fait comme suit, avec une certaine reserve :
1) Liferay recupère le filtre d'authentification et remplace les variables @xxxx@ dans la chaine. Si le login se fait par email, @screen_name@ et @user_id@ sont respectivement une chaine vide et 0. Un parallèle peut être fait avec les autres méthodes.
2) L'utilisateur correspondant à la recherche d'import d'utilisateur + filtre est récupérer du LDAP. Le premier de la liste est utilisé.
3.a) Liferay tente une connection au LDAP avec le FULL-DN de l'utilisateur + son mot de passe.
3.b) SI la méthode d'authentification n'est pas BIND, Liferay compare directement les mots de passe
4) Si 3) réussi, l'utilisateur est authentifié.

J'espère que cela pourra vous être utile.

[9年前 に Emilien Bécu によって更新されました。]

Merci pour ces explications, cela m'aide à comprendre où Liferay va chercher les informations,

La solution mail=@user_id@ me renvoit :
10:32:54,674 ERROR [ajp-bio-8009-exec-2][LDAPAuth:330] Problem accessing LDAP server com.liferay.portal.kernel.ldap.LDAPFilterException: Invalid filter (ObjectClass=person)mail=0

Même sans le (ObjectClass=person)
11:57:48,420 ERROR [ajp-bio-8009-exec-3][LDAPAuth:330] Problem accessing LDAP server com.liferay.portal.kernel.ldap.LDAPFilterException: Invalid filter mail=0

Je reprend votre explication :
1) Liferay recupère le filtre d'authentification et remplace les variables @xxxx@ dans la chaine. Si le login se fait par email, @screen_name@ et @user_id@ sont respectivement une chaine vide et 0. Un parallèle peut être fait avec les autres méthodes.

Donc au moment de la connexion avec user1, qui doit s'identifier par défaut avec son adresse mail [e-mail] ,
-> mail=@email_address@ -> mail=[e-mail]

2) L'utilisateur correspondant à la recherche d'import d'utilisateur + filtre est récupérer du LDAP. Le premier de la liste est utilisé.
Si un user dans le LDAP possède un attribut mail==[e-mail], Liferay effectue une requête dans LDAP pour récuperer tout ses attributs et les map avec les correspondance effectué, par exemple prénom->cn,nom->sn,MotDePasse->UserPassword etc...

3.a) Liferay tente une connexion au LDAP avec le FULL-DN de l'utilisateur + son mot de passe.
3.b) SI la méthode d'authentification n'est pas BIND, Liferay compare directement les mots de passe
Donc à ce moment Liferay utilise quoi pour la tentative de connexion? Que ce soit bind ou autre il doit bien faire référence à un objet.
Solution 1 : Le FULL-DN qui doit être comme ceci -> uid=user1,ou=users,o=MonOrganisation,dc=Liferay,dc=com
Solution 2 : Ou bien il utilise l'adresse mail -> mail=[e-mail],ou=users,o=MonOrganisation,dc=Liferay,dc=com

4) Si 3) réussi, l'utilisateur est authentifié.


Dans l'étape 3) si c'est la solution 2 qui est retenu pour moi la connexion ne peut pas marcher à moins d'avoir créer des alias mail de chaque personne dans le LDAP
Si c'est la solution 1 je ne comprend pas pourquoi il ne peux pas se connecter, il résout bien le mail, mais Liferay bloque avant même de faire la requête vers le LDAP, ce qui veut dire que la syntaxe dans le filter n'est pas bon....

J'ai l'impression de tourner en rond...

[9年前 に Darryl Kpizingui によって更新されました。]

Désolé, je m'étais trompé en écrivant. Si vous utilisez le mail pour la connexion dans Liferay le filtre doit être:

2) Le filtre devrait être  (mail=@email_address@)

et non mail=@user_id@ , ce qui est consistant avec le fait que le @user_id@ == 0 pour une authentification par mail
Avec ou sans (ObjectClass=person), vous verrez avec les tests.

[9年前 に Emilien Bécu によって更新されました。]

Oui je me suis douté mais j'ai testé quand même histoire d'etre sur, j'ai donc corrigé de mon coté et voici ce que ça donne


mail=@email_address@
log liferay :
07:55:30,580 DEBUG [ajp-bio-8009-exec-6][LDAPSettingsUtil:49] Search filter before transformation mail=@email_address@
07:55:30,580 ERROR [ajp-bio-8009-exec-6][LDAPAuth:330] Problem accessing LDAP server
com.liferay.portal.kernel.ldap.LDAPFilterException: Invalid filter mail=[e-mail]

log ldap
Jun 24 09:55:03 portal slapd[22224]: conn=1005 op=101 SRCH base="o=corp,dc=liferay,dc=com" scope=2 deref=3 filter="(objectClass=person)"
Jun 24 09:55:03 portal slapd[22224]: conn=1005 op=101 SRCH attr=userPassword sn mail givenName mail
Jun 24 09:55:03 portal slapd[22224]: conn=1005 op=101 SEARCH RESULT tag=101 err=0 nentries=3 text=

La connexion ne fonctionne pas


(ObjectClass=person)mail=@email_address@
log liferay
07:59:05,649 DEBUG [ajp-bio-8009-exec-6][LDAPSettingsUtil:49] Search filter before transformation (ObjectClass=person)mail=@email_address@
07:59:05,649 ERROR [ajp-bio-8009-exec-6][LDAPAuth:330] Problem accessing LDAP server
com.liferay.portal.kernel.ldap.LDAPFilterException: Invalid filter (ObjectClass=person)mail=[e-mail]

log ldap
Pas de log

La connexion ne fonctionne pas


J'ai un doute sur cette partie


Pour moi le premier champ sert bien à filtrer la recherche dans le LDAP,
et le deuxième sert à valider l'import d'un user qui possède l'objectClass défini

Si je me trompe il faut me corriger, je n'ai pas trouver cette informations ou alors en anglais et je comprend pas la nuance...

[9年前 に Darryl Kpizingui によって更新されました。]

(ObjectClass=person)(mail=@email_address@)

Il manque les parenthèses. La syntaxe que vous utilisiez est correcte vu que vous arriviez à vous connecter.
Mon intervention, pour résumer, est juste pour dire qu'au lieu d'utiliser (uid=@user_id@), il faut utiliser (mail=@email_address@).

Pour tester rapidement les filtres, vous pouvez les mettre dans le champ "Filtre de recherche d'importation" et vérifier que Liferay importe bien un seul utilisateur. Par exemple la valeur (ObjectClass=person)(mail=[e-mail]) devrait retourner le user1 pour l'action "Tester les utilisateurs LDAP".

[9年前 に Emilien Bécu によって更新されました。]

Oui mais mon problème quand j'utilise la syntaxe avec (ObjectClass=person)(mail=@email_address@)

c'est que lors d'une tentative de connexion avec un compte user que liferay n'a jamais vu, j'obtient cela :

log LDAP

Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=107 SRCH base="o=corp,dc=liferay,dc=com" scope=2 deref=3 filter="(objectClass=person)"
Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=107 SRCH attr=mail [e-mail]
Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=107 SEARCH RESULT tag=101 err=4 nentries=1 text=
Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=108 SRCH base="uid=user2,ou=users,o=corp,dc=liferay,dc=com" scope=0 deref=3 filter="(objectClass=*)"
Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=108 SRCH attr=sn userPassword mail givenName uid mail creatorsName createTimestamp modifiersName modifyTimestamp
Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=108 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 24 11:50:48 portal slapd[22224]: conn=7653 fd=15 ACCEPT from IP=127.0.0.1:34403 (IP=0.0.0.0:389)
Jun 24 11:50:48 portal slapd[22224]: conn=7653 op=0 BIND dn="uid=user2,ou=users,o=corp,dc=liferay,dc=com" method=128
Jun 24 11:50:48 portal slapd[22224]: conn=7653 op=0 BIND dn="uid=user2,ou=users,o=corp,dc=liferay,dc=com" mech=SIMPLE ssf=0
Jun 24 11:50:48 portal slapd[22224]: conn=7653 op=0 RESULT tag=97 err=0 text=
Jun 24 11:50:48 portal slapd[22224]: conn=7653 op=1 UNBIND
Jun 24 11:50:48 portal slapd[22224]: conn=7653 fd=15 closed
Jun 24 11:50:48 portal slapd[22224]: conn=1018 op=29 SRCH base="o=corp,dc=liferay,dc=com" scope=2 deref=3 filter="(&(mail=[e-mail])(objectClass=person))"
Jun 24 11:50:48 portal slapd[22224]: conn=1018 op=29 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=109 SRCH base="o=corp,dc=liferay,dc=com" scope=2 deref=3 filter="(&(objectClass=groupOfNames)(member=uid=user2,ou=users,o=corp,dc=liferay,dc=com))"
Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=109 SRCH attr=cn
Jun 24 11:50:48 portal slapd[22224]: <= bdb_equality_candidates: (member) not indexed
Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=109 SEARCH RESULT tag=101 err=0 nentries=0 text=

Et le log liferay devient dingue

09:50:48,299 DEBUG [ajp-bio-8009-exec-11][LDAPSettingsUtil:49] Search filter before transformation (ObjectClass=person)(mail=@email_address@)
09:50:48,299 DEBUG [ajp-bio-8009-exec-11][LDAPSettingsUtil:64] Search filter after transformation (ObjectClass=person)(mail=[e-mail])
09:50:48,300 DEBUG [ajp-bio-8009-exec-11][LDAPSettingsUtil:44] -- listing properties --
password=userPassword
lastName=sn
screenName=mail
uuid=uid
firstName=givenName
emailAddress=mail

09:50:48,301 DEBUG [ajp-bio-8009-exec-11][LDAPAuth:261] Search filter returned at least one result
09:50:48,301 DEBUG [ajp-bio-8009-exec-11][LDAPSettingsUtil:44] -- listing properties --
password=userPassword
lastName=sn
screenName=mail
uuid=uid
firstName=givenName
emailAddress=mail

09:50:48,302 DEBUG [ajp-bio-8009-exec-11][LDAPSettingsUtil:44] -- listing properties --

09:50:48,302 DEBUG [ajp-bio-8009-exec-11][LDAPSettingsUtil:44] -- listing properties --

09:50:48,302 DEBUG [ajp-bio-8009-exec-11][LDAPSettingsUtil:44] -- listing properties --

09:50:48,306 DEBUG [ajp-bio-8009-exec-11][LDAPSettingsUtil:44] -- listing properties --
password=userPassword
lastName=sn
screenName=mail
uuid=uid
firstName=givenName
emailAddress=mail

09:50:48,306 DEBUG [ajp-bio-8009-exec-11][LDAPSettingsUtil:44] -- listing properties --

09:50:48,307 DEBUG [ajp-bio-8009-exec-11][LDAPSettingsUtil:44] -- listing properties --

09:50:48,308 DEBUG [ajp-bio-8009-exec-11][LDAPSettingsUtil:44] -- listing properties --

09:50:48,309 DEBUG [ajp-bio-8009-exec-11][DefaultLDAPToPortalConverter:101] Screen name [e-mail] and email address [e-mail]
09:50:48,318 DEBUG [ajp-bio-8009-exec-11][PortalLDAPImporterImpl:1196] User [e-mail] is already synchronized, but updated password to avoid a blank value
09:50:48,320 WARN  [ajp-bio-8009-exec-11][PortalLDAPImporterImpl:1098] Unable to populate expando attributes
09:50:48,321 DEBUG [ajp-bio-8009-exec-11][PortalLDAPImporterImpl:1102] com.liferay.portlet.expando.NoSuchTableException: No ExpandoTable exists with the key {companyId=10253, classNameId=10105, name=CUSTOM_FIELDS}
com.liferay.portlet.expando.NoSuchTableException: No ExpandoTable exists with the key {companyId=10253, classNameId=10105, name=CUSTOM_FIELDS}
	at com.liferay.portlet.expando.service.persistence.ExpandoTablePersistenceImpl.findByC_C_N(ExpandoTablePersistenceImpl.java:986)
	at sun.reflect.GeneratedMethodAccessor1074.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at com.liferay.portal.security.lang.DoPrivilegedHandler.doInvoke(DoPrivilegedHandler.java:88)
	...
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
	at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)
09:50:48,325 WARN  [ajp-bio-8009-exec-11][PortalLDAPImporterImpl:1098] Unable to populate expando attributes
09:50:48,325 DEBUG [ajp-bio-8009-exec-11][PortalLDAPImporterImpl:1102] com.liferay.portlet.expando.NoSuchTableException: No ExpandoTable exists with the key {companyId=10253, classNameId=10122, name=CUSTOM_FIELDS}
com.liferay.portlet.expando.NoSuchTableException: No ExpandoTable exists with the key {companyId=10253, classNameId=10122, name=CUSTOM_FIELDS}
	at com.liferay.portlet.expando.service.persistence.ExpandoTablePersistenceImpl.findByC_C_N(ExpandoTablePersistenceImpl.java:986)
	at sun.reflect.GeneratedMethodAccessor1074.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at com.liferay.portal.security.lang.DoPrivilegedHandler.doInvoke(DoPrivilegedHandler.java:88)
	...
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
	at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)
09:50:48,327 DEBUG [ajp-bio-8009-exec-11][LDAPSettingsUtil:44] -- listing properties --
user=member
groupName=cn

09:50:48,337 DEBUG [ajp-bio-8009-exec-11][PortalLDAPUtil:44] -- listing properties --
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
java.naming.provider.url=ldap://localhost:389
com.sun.jndi.ldap.connect.timeout=500
java.naming.security.principal=cn=admin-ldap,dc=liferay,dc=com
com.sun.jndi.ldap.connect.pool=true
java.naming.security.credentials=*******
java.naming.referral=follow
com.sun.jndi.ldap.read.timeout=15000

09:50:48,337 DEBUG [ajp-bio-8009-exec-11][LDAPSettingsUtil:44] -- listing properties --
password=userPassword
lastName=sn
screenName=mail
uuid=uid
firstName=givenName
emailAddress=mail

Je ne comprend pas ce qu'il fait, il test une premiere fois avec le user1, on le voit bien dans le log LDAP
Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=107 SRCH base="o=corp,dc=liferay,dc=com" scope=2 deref=3 filter="(objectClass=person)"
Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=107 SRCH attr=mail [e-mail]
Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=107 SEARCH RESULT tag=101 err=4 nentries=1 text=

Mais 4 erreurs apparaissent et juste après il fait ça :

Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=108 SRCH base="uid=user2,ou=users,o=corp,dc=liferay,dc=com" scope=0 deref=3 filter="(objectClass=*)"
Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=108 SRCH attr=sn userPassword mail givenName uid mail creatorsName createTimestamp modifiersName modifyTimestamp
Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=108 SEARCH RESULT tag=101 err=0 nentries=1 text=

Pourquoi et ou est ce qu'il va cherche ce user2 ?

Si je test la connexion directment avec le user2 j'obtient ceci :
Log LDAP

Jun 24 12:49:02 portal slapd[22224]: conn=1005 op=110 SRCH base="o=corp,dc=liferay,dc=com" scope=2 deref=3 filter="(objectClass=person)"
Jun 24 12:49:02 portal slapd[22224]: conn=1005 op=110 SRCH attr=mail [e-mail]
Jun 24 12:49:02 portal slapd[22224]: conn=1005 op=110 SEARCH RESULT tag=101 err=4 nentries=1 text=
Jun 24 12:49:02 portal slapd[22224]: conn=1005 op=111 SRCH base="uid=user2,ou=users,o=corp,dc=liferay,dc=com" scope=0 deref=3 filter="(objectClass=*)"
Jun 24 12:49:02 portal slapd[22224]: conn=1005 op=111 SRCH attr=sn userPassword mail givenName uid mail creatorsName createTimestamp modifiersName modifyTimestamp
Jun 24 12:49:02 portal slapd[22224]: conn=1005 op=111 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 24 12:49:02 portal slapd[22224]: conn=7760 fd=15 ACCEPT from IP=127.0.0.1:34510 (IP=0.0.0.0:389)
Jun 24 12:49:02 portal slapd[22224]: conn=7760 op=0 BIND dn="uid=user2,ou=users,o=corp,dc=liferay,dc=com" method=128
Jun 24 12:49:02 portal slapd[22224]: conn=7760 op=0 BIND dn="uid=user2,ou=users,o=corp,dc=liferay,dc=com" mech=SIMPLE ssf=0
Jun 24 12:49:02 portal slapd[22224]: conn=7760 op=0 RESULT tag=97 err=0 text=
Jun 24 12:49:02 portal slapd[22224]: conn=7760 op=1 UNBIND
Jun 24 12:49:02 portal slapd[22224]: conn=7760 fd=15 closed
Jun 24 12:49:02 portal slapd[22224]: conn=1018 op=30 SRCH base="o=corp,dc=liferay,dc=com" scope=2 deref=3 filter="(&(mail=[e-mail])(objectClass=person))"
Jun 24 12:49:02 portal slapd[22224]: conn=1018 op=30 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 24 12:49:02 portal slapd[22224]: conn=1005 op=112 SRCH base="o=corp,dc=liferay,dc=com" scope=2 deref=3 filter="(&(objectClass=groupOfNames)(member=uid=user2,ou=users,o=corp,dc=liferay,dc=com))"
Jun 24 12:49:02 portal slapd[22224]: conn=1005 op=112 SRCH attr=cn
Jun 24 12:49:02 portal slapd[22224]: <= bdb_equality_candidates: (member) not indexed
Jun 24 12:49:02 portal slapd[22224]: conn=1005 op=112 SEARCH RESULT tag=101 err=0 nentries=0 text=user2

Log liferay

10:49:02,821 DEBUG [ajp-bio-8009-exec-4][LDAPAuth:361] Authenticator is enabled
10:49:02,831 DEBUG [ajp-bio-8009-exec-4][PortalLDAPUtil:44] -- listing properties --
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
java.naming.provider.url=ldap://localhost:389
com.sun.jndi.ldap.connect.timeout=500
java.naming.security.principal=cn=adminldap,dc=liferay,dc=com
com.sun.jndi.ldap.connect.pool=true
java.naming.security.credentials=******
java.naming.referral=follow
com.sun.jndi.ldap.read.timeout=15000

10:49:02,832 DEBUG [ajp-bio-8009-exec-4][LDAPSettingsUtil:49] Search filter before transformation (ObjectClass=person)(mail=@email_address@)
10:49:02,833 DEBUG [ajp-bio-8009-exec-4][LDAPSettingsUtil:64] Search filter after transformation (ObjectClass=person)(mail=[e-mail])
10:49:02,833 DEBUG [ajp-bio-8009-exec-4][LDAPSettingsUtil:44] -- listing properties --
password=userPassword
lastName=sn
screenName=mail
uuid=uid
firstName=givenName
emailAddress=mail

10:49:02,835 DEBUG [ajp-bio-8009-exec-4][LDAPAuth:261] Search filter returned at least one result
10:49:02,836 DEBUG [ajp-bio-8009-exec-4][LDAPSettingsUtil:44] -- listing properties --
password=userPassword
lastName=sn
screenName=mail
uuid=uid
firstName=givenName
emailAddress=mail

10:49:02,836 DEBUG [ajp-bio-8009-exec-4][LDAPSettingsUtil:44] -- listing properties --

10:49:02,837 DEBUG [ajp-bio-8009-exec-4][LDAPSettingsUtil:44] -- listing properties --

10:49:02,837 DEBUG [ajp-bio-8009-exec-4][LDAPSettingsUtil:44] -- listing properties --

10:49:02,840 DEBUG [ajp-bio-8009-exec-4][LDAPSettingsUtil:44] -- listing properties --
password=userPassword
lastName=sn
screenName=mail
uuid=uid
firstName=givenName
emailAddress=mail

10:49:02,841 DEBUG [ajp-bio-8009-exec-4][LDAPSettingsUtil:44] -- listing properties --

10:49:02,842 DEBUG [ajp-bio-8009-exec-4][LDAPSettingsUtil:44] -- listing properties --

10:49:02,842 DEBUG [ajp-bio-8009-exec-4][LDAPSettingsUtil:44] -- listing properties --

10:49:02,843 DEBUG [ajp-bio-8009-exec-4][DefaultLDAPToPortalConverter:101] Screen name [e-mail] and email address [e-mail]
10:49:02,853 DEBUG [ajp-bio-8009-exec-4][PortalLDAPImporterImpl:1196] User [e-mail] is already synchronized, but updated password to avoid a blank value
10:49:02,854 WARN  [ajp-bio-8009-exec-4][PortalLDAPImporterImpl:1098] Unable to populate expando attributes
10:49:02,855 DEBUG [ajp-bio-8009-exec-4][PortalLDAPImporterImpl:1102] com.liferay.portlet.expando.NoSuchTableException: No ExpandoTable exists with the key {companyId=10253, classNameId=10105, name=CUSTOM_FIELDS}
com.liferay.portlet.expando.NoSuchTableException: No ExpandoTable exists with the key {companyId=10253, classNameId=10105, name=CUSTOM_FIELDS}
	at com.liferay.portlet.expando.service.persistence.ExpandoTablePersistenceImpl.findByC_C_N(ExpandoTablePersistenceImpl.java:986)
	at sun.reflect.GeneratedMethodAccessor1074.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at com.liferay.portal.security.lang.DoPrivilegedHandler.doInvoke(DoPrivilegedHandler.java:88)
	at com.liferay.portal.security.lang.DoPrivilegedHandler.invoke(DoPrivilegedHandler.java:56)
	...
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
	at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)
10:49:02,859 WARN  [ajp-bio-8009-exec-4][PortalLDAPImporterImpl:1098] Unable to populate expando attributes
10:49:02,860 DEBUG [ajp-bio-8009-exec-4][PortalLDAPImporterImpl:1102] com.liferay.portlet.expando.NoSuchTableException: No ExpandoTable exists with the key {companyId=10253, classNameId=10122, name=CUSTOM_FIELDS}
com.liferay.portlet.expando.NoSuchTableException: No ExpandoTable exists with the key {companyId=10253, classNameId=10122, name=CUSTOM_FIELDS}
	at com.liferay.portlet.expando.service.persistence.ExpandoTablePersistenceImpl.findByC_C_N(ExpandoTablePersistenceImpl.java:986)
	at sun.reflect.GeneratedMethodAccessor1074.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	...
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)
10:49:02,862 DEBUG [ajp-bio-8009-exec-4][LDAPSettingsUtil:44] -- listing properties --
user=member
groupName=cn

10:49:02,869 DEBUG [ajp-bio-8009-exec-4][PortalLDAPUtil:44] -- listing properties --
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
java.naming.provider.url=ldap://localhost:389
com.sun.jndi.ldap.connect.timeout=500
java.naming.security.principal=cn=adminldap,dc=liferay,dc=com
com.sun.jndi.ldap.connect.pool=true
java.naming.security.credentials=******
java.naming.referral=follow
com.sun.jndi.ldap.read.timeout=15000

10:49:02,870 DEBUG [ajp-bio-8009-exec-4][LDAPSettingsUtil:44] -- listing properties --
password=userPassword
lastName=sn
screenName=mail
uuid=uid
firstName=givenName
emailAddress=mail
liferay

[9年前 に Darryl Kpizingui によって更新されました。]

Je ne vois pas d'erreur dans les logs. Il y a du contenu car vous avez augmenté le niveau de journalisation.

Tout ce passe comme si le filtre de recherche d'authentification que reçoit le LDAP est (objectClass=person) et non (ObjectClass=person)(mail=@email_address@). C'est ce qui explique le fait que user2 est utilisé parce que premier dans la liste.

1Jun 24 11:50:48 portal slapd[22224]: conn=1005 op=107 SRCH base="o=corp,dc=liferay,dc=com" scope=2 deref=3 filter="(objectClass=person)"

Je ne suis pas un pro des requêtes LDAP, mais vous devriez peut être essayé (&(mail=@email_address@)(objectClass=person))
Le problème, selon moi, vient de la formulation de la requête et non de Liferay.

[9年前 に Emilien Bécu によって更新されました。]

C'est super ça fonctionne !!!!

Merci beaucoup Darryl Kpizingui,

N'empêche je suis quand même bien dégoûté d'avoir autant perdu de temps pour un ajout de (&...........), bon maintenant que j'ai réussi via l'interface graphique, je m'y met pour le faire via le fichier portal-ext.properties

Je posterai la configuration ici au cas ou cela intéresse des personnes qui sont dans mon cas