Some LDAP Users cannot login

[t_schoeberl]

Hello,

I am currently working with Alfresco Community 5.2f and I have a problem with our LDAP authentication configuration. Mostly everyday there is an user who cannot login and nothing is in the logfile. The user is not locked in AD, because he can login in other applications and the other users can successfully login in Alfresco. After a restart from Alfresco it works for the user, but some other users cannot login.

We tried a synchronisation cronjob for each hour, but the user cannot login yet.

Here is my LDAP configuration:

synchronization.synchronizeChangesOnly=true
synchronization.import.cron=0 0 * * * ?

authentication.chain=alfrescoNtlm1:alfrescoNtlm,ldap1:ldap

ldap.authentication.active=true
ldap.authentication.allowGuestLogin=true
ldap.authentication.userNameFormat=
ldap.authentication.java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
ldap.authentication.java.naming.provider.url=[x]
ldap.authentication.java.naming.security.authentication=simple
ldap.authentication.escapeCommasInBind=false
ldap.authentication.escapeCommasInUid=false
ldap.authentication.defaultAdministratorUserNames=schota
ldap.synchronization.active=true
ldap.synchronization.java.naming.security.authentication=simple
ldap.synchronization.java.naming.security.principal=[x]
ldap.synchronization.java.naming.security.credentials=[x]
ldap.synchronization.queryBatchSize=500
ldap.synchronization.attributeBatchSize=500
ldap.synchronization.groupQuery=(objectclass\=group)
ldap.synchronization.groupDifferentialQuery=(&(objectclass\=group)(!(whenChanged<\={0})))
ldap.synchronization.personQuery=(&(objectclass\=organizationalPerson)(|(company\=OOEGKK)(memberOf\=CN=g-ueberlassene,OU=System,OU=_Groups,OU=OOEGKK,DC=ooegkk,DC=gkk,DC=sv-services,DC=at))(!(userPrincipalName\=*accounting.sv-services.at)))
ldap.synchronization.personDifferentialQuery=(&(&(objectClass\=organizationalPerson)(|(company\=OOEGKK)(memberOf\=CN=g-ueberlassene,OU=System,OU=_Groups,OU=OOEGKK,DC=ooegkk,DC=gkk,DC=sv-services,DC=at))(!(userPrincipalName\=*accounting.sv-services.at)))(!(whenChanged<\={0})))
ldap.synchronization.groupSearchBase=OU\=_Groups,OU\=OOEGKK,DC\=ooegkk,DC\=gkk,DC\=sv-services,DC\=at
ldap.synchronization.userSearchBase=DC\=sv-services,DC\=at
ldap.synchronization.modifyTimestampAttributeName=whenChanged
ldap.synchronization.timestampFormat=yyyyMMddHHmmss'.0Z'
ldap.synchronization.userIdAttributeName=cn
ldap.synchronization.userFirstNameAttributeName=givenName
ldap.synchronization.userLastNameAttributeName=sn
ldap.synchronization.userEmailAttributeName=mail
ldap.synchronization.userOrganizationalIdAttributeName=o
ldap.synchronization.defaultHomeFolderProvider=largeHomeFolderProvider
ldap.synchronization.groupIdAttributeName=cn
ldap.synchronization.groupDisplayNameAttributeName=cn
ldap.synchronization.groupType=group
ldap.synchronization.personType=organizationalPerson
ldap.synchronization.groupMemberAttributeName=member
ldap.synchronization.enableProgressEstimation=true
ldap.authentication.java.naming.read.timeout=180000

Any help regarding this issue would be greatly appreciated.

Thanks

[afaust]

If there is currently nothing in the log file then it is a bit difficult to guess what might be the cause, especially since other users can login. I recommend adjusting the log levels to get more information.Though Alfresco can be annoyingly reserved when it comes to logging, there might be some info to be gained. The following logger(s) should be set to DEBUG:

• org.alfresco.repo.security.sync.ldap.LDAPUserRegistry
• org.springframework.extensions.webscripts.DeclarativeWebScript

Since these loggers can create quite a lot of output it is recommended to only have them active when reproducing this issue with an end user. Normally, Alfresco Community Edition does not support dynamic changes to Log4J configuration, but you could use the OOTBee Support Tools addon which adds this capability to the Repository Administration Console / Share Admin Tools.

The DeclarativeWebScript is the generic class for all web scripts - setting its logger is meant to have Alfresco log out the error message for the authentication via the Share login form. The LDAPUserRegistry is used in parts of the authentication exchange when the user DN needs to be resolved from a simplified user name (in your case, matching the user name input against the CN of users).

[cesarista]

Yes, as Axel mentioned, log4j is your friend. Maybe this logger also helps:

log4j.logger.org.alfresco.repo.security.authentication.ldap=DEBUG

But, is this for an OpenLDAP or for an Active Directory ? 

Regards.

--C.

P.S: By the way, you can set ldap.authentication.allowGuestLogin=false

[t_schoeberl]

Yes like you mentioned, I didn't want to set the loglevel to debug, because the output is quite a lot. Thanks, i will try the OOTBee Support Tools addon.

‌

Its for an Active Directory.

Regards.

[t_schoeberl]

So i installed the OOTBee Support Tools and set the LogLevel to DEBUG. If a user log in to Alfresco I see a DEBUG output in the Logfile. But unfortunately if a user who is locked try to log in, I see nothing in the logfile and he cannot log in. We think that the user is locked in AD and after 30 minutes he is unlocked but Alfresco don't recognize this and don't authenticate aigainst AD. Is the user locked somewhere in Alfresco intern? Do you have any idea?

Thanks and regards.

[cesarista]

Hi Tanja:

I'm asking because there exists two different OOTB subsystems for Alfresco: ldap (for OpenLDAP) and ldap-ad (for Active Directory using LDAP protocol).

community-edition-old/ldap-ad-authentication.properties at master · Alfresco/community-edition-old ·... 

But is usual to see "sAMAccountName" as userIdAttributteName or ldap-ad in authentication chain, or 

Regards.

--C.

[cesarista]

Hi,

Alfresco ldap (or ldap-ad) subsystem delegates authentication in AD, and so, no passwords are saved in Alfresco database. If you are right, Alfresco seems to do what it was made for. But if you are right, other aplications will be suitable of login issues during AD locks. And this would be generated by some application on your organization (Alfresco or another application) doing continuous wrong auth requests in AD, resulting in the corresponding temp locks.

Regards.

--C.

[t_schoeberl]

To be more precise i will try to give you a detailed information of what we do:

situation 1:
- user account in ad is not locked -> user is able to login to alfresco (which is ok)

situation 2:
- user tries to access a rest url, e.g. /alfresco/service/, user is prompted for username/password. if the user enters the wrong username/password for five times then the account is locked in ad
- user tries to login to alfresco -> user is not able to login, as the account ist locked in ad (as expected, the user is also unable to login through other applications that are chained to ad)
- account is unlocked in ad
- user tries to login to alfresco -> user ist not able to login (at the same time the user is able to login again through other applications that are chained to ad)

So we believe, that the status of a user account is somewhere cached in alfresco, which prevents alfresco to do a authentication query towards ad where the user would already be unlocked.

[cesarista · Accepted solution]

Hi:

Maybe it is related with this feature in Alfresco 5.2: 

https://community.alfresco.com/docs/DOC-6301-alfresco-community-edition-52#jive_content_id_Slowdown_... 

Diving into repository.properties I see (you may check and confirm them also in System Information page in OOTB addon).

https://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/projects/repository/config/al... 

# Brute force protection
authentication.protection.enabled=true
authentication.protection.limit=10
authentication.protection.periodSeconds=6

Regards.

--C.

[robsoncardoso_t]

I have the same problem. And it started to happen only after using version 5.2.
The problem is that some users have problems authenticating to AD, I realized that this usually happens after the user changes the AD password and especially when the user generates a password with special characters.
I tried to identify if it could be the brute force attack feature but I did not find a relationship.