RE: Problems with login users using ldap

Daniel Orozco, modified 5 Years ago. New Member Posts: 13 Join Date: 10/16/15 Recent Posts
Good morning for everyone!I will describe my environment. 
Liferay 7.2 Comunity edition over Linux CentOS. 
LDAP connection with Active Directory (Windows).
 All the configurations seems to be ok and the portal works well almost all the time.In some cases, any user tries to login in to the portal and the page doesn't be anything. No errors in log file, no messages in Liferay.

 But if, the user puts an invalid password, Liferay says that the password is wrong. With this behavior, I think that Liferay is validating the password against ldap correctly, but it isn´t able to login the users.When i look the user in active directory, the parameter "whenChanged" in active directory is with nearly date. 
After a few hours, the user can login again correctly.I would to know if there is a sync process that update the users when active directory change.
Thanks a lot!
thumbnail
Christoph Rabel, modified 5 Years ago. Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
No idea.
I would first try to set the debug level for
com.liferay.portal.security.ldap.internal.DefaultPortalLDAP     
com.liferay.portal.security.ldap.internal.authenticator.LDAPAuth
com.liferay.portal.security.ldap.internal
Maybe it gives you a hint what happens.
When you enable LDAP, you can configure in the settings how it should behave.
In Instance Settings -> LDAP
Import: Create users when they authenticate
Import at startup: Import users in a loop, the import interval specifies how many minutes it will wait when an import run has been completed.
Weird idea: Maybe you have import disabled but Import at startup enabled. I am not sure what happens then, but maybe it authenticates the user and says: Oh, I should not create it and nothing happens. Later it is created by the job and everything is fine afterwards.
But something like that should only affect new users. And I am just wild guessing here ...
Daniel Orozco, modified 5 Years ago. New Member Posts: 13 Join Date: 10/16/15 Recent Posts
Hi Cristoph. 

Thanks for your answer.

I have "enable import" checked and "Enable Import on Startup" disabled. (Image attach)
How I could enable debug level? You're right. At least, we need to know what is the problem.
Daniel Orozco, modified 5 Years ago. New Member Posts: 13 Join Date: 10/16/15 Recent Posts
Cristoph! I enabled debug label that you sold me.
I was comparing logs between an user that works fine and user doesn't work.
The debug trace is identical!I don´t know what is the problem.2020-07-03 18:58:58.480 DEBUG [https-jsse-nio-443-exec-1][LDAPAuth:459] Authenticator is enabled
2020-07-03 18:58:58.481 DEBUG [https-jsse-nio-443-exec-1][LDAPAuth:672] Using LDAP server 34328 to authenticate user 0
2020-07-03 18:58:58.481 DEBUG [https-jsse-nio-443-exec-1][DefaultPortalLDAP:172] {java.naming.referral=follow, com.sun.jndi.ldap.connect.timeout=500, java.naming.security.principal=BuscadorLDAP@domain.org, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, com.sun.jndi.ldap.connect.pool=true, java.naming.provider.url=ldap://****.org:389, com.sun.jndi.ldap.read.timeout=15000, java.naming.security.credentials=********}
2020-07-03 18:58:58.501 DEBUG [https-jsse-nio-443-exec-1][LDAPAuth:339] Found results with search filter: (mail=daniel.orozco@cafedecolombia.com)
2020-07-03 18:58:58.502 DEBUG [https-jsse-nio-443-exec-1][DefaultPortalLDAP:729] LDAP user attribute sn: lastname
2020-07-03 18:58:58.502 DEBUG [https-jsse-nio-443-exec-1][DefaultPortalLDAP:729] LDAP user attribute description: Position
2020-07-03 18:58:58.502 DEBUG [https-jsse-nio-443-exec-1][DefaultPortalLDAP:729] LDAP user attribute cn: Full name
2020-07-03 18:58:58.503 DEBUG [https-jsse-nio-443-exec-1][DefaultPortalLDAP:729] LDAP user attribute memberOf: OU=Group1,CN=Group2
2020-07-03 18:58:58.503 DEBUG [https-jsse-nio-443-exec-1][DefaultPortalLDAP:729] LDAP user attribute st: region
2020-07-03 18:58:58.509 DEBUG [https-jsse-nio-443-exec-1][DefaultPortalLDAP:172] {java.naming.referral=follow, com.sun.jndi.ldap.connect.timeout=500, java.naming.security.principal=BuscadorLDAP@***.org, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, com.sun.jndi.ldap.connect.pool=true, java.naming.provider.url=ldap://****.org:389, com.sun.jndi.ldap.read.timeout=15000, java.naming.security.credentials=********}
2020-07-03 18:58:58.514 DEBUG [https-jsse-nio-443-exec-1][DefaultPortalLDAP:307] LDAP group attribute cn: ACL101005
2020-07-03 18:58:58.522 DEBUG [https-jsse-nio-443-exec-1][LDAPAuth:474] Found preferred LDAP server
2020-07-03 18:58:58.522 DEBUG [https-jsse-nio-443-exec-1][LDAPAuth:479] Import user password enabled

I replied the incident, changing my password on active directory.
Any idea could help me. 
Thanks
thumbnail
Christoph Rabel, modified 5 Years ago. Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
Note: Maybe you should edit your post and remove names/domains/emailaddresses. It's your call, but there are harvesters that parse websites for emailaddresses to spam them and it's best to avoid that.
That the log is identical tells us, that the problem is not related to the ldap server itself. According to the debug log, Login was a success. You could next try to disable the "Import user password" checkbox in the settings, maybe it fails somewhere in that codepath. I doubt it, but it should be easy to test.
I believe, your issue is elsewhere. Can you describe in more detail what happens? You wrote: "and the page doesn't be anything. ". Maybe the error is not in the backend but in the frontend.
What do you mean with that. A blank page? The login page again? Could you check in the frontend using the browser developer console for Javascript errors? Could you test with two browsers? I mean, login fails for a user. Switch with that user to Firefox/Chrome/... and try again. Does the browser make a difference.
It would also be interesting to know what the request returns. I mean, with the browser developer console you can use the network tab to check the request and the response for the login request. Clear it, click the login button and check the result.
Daniel Orozco, modified 5 Years ago. New Member Posts: 13 Join Date: 10/16/15 Recent Posts
Hi Cristoph!

Thanks for your advice. 
I edited my last post.

I have been looking error whole day and night, and I found the reason of problem, but not the solution yet.Database production for liferay metadata is postgresql.   
I checked each field of "user_" table.  So i saw passwordmodifieddate field is loaded with a future date. (5 hours). For this reason, the portal begins to work fine after a few hours.

So... the problem is a GMT or UTC configuration, but the GMT in liferay (tomcat) and SO is ok. Database server GMT configurations, is configured correctly.   The user.timezone parameter is GMT-5.   
Also i changed Configuration ->  instance settings ->  Localization ->  Timezone from UTC to UTC-5 (I am from Colombia)

I reboot the service but the behavior is the same.
 Thanks again!
Daniel Orozco, modified 5 Years ago. New Member Posts: 13 Join Date: 10/16/15 Recent Posts
Resolved!!!

The user.timezone parameter in GMT-5 failed with ldap syncronization, if the parameter is configured in the java_opts (setenv.sh).

In this article, i found the solution. https://help.liferay.com/hc/es/articles/360034940932-Si-el-usuario-cambia-la-contrase%C3%B1a-en-LDAP-no-se-puede-loguear-por-una-cantidad-de-horas-DXP-7-0-FP-81-o-superior

Thanks a lot for everything Cristoph