cancel
Showing results for 
Search instead for 
Did you mean: 

Some LDAP Users cannot login

t_schoeberl
Champ on-the-rise
Champ on-the-rise

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

1 ACCEPTED ANSWER

cesarista
World-Class Innovator
World-Class Innovator

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.

View answer in original post

13 REPLIES 13

t_schoeberl
Champ on-the-rise
Champ on-the-rise

Solution:

In alfresco-global.properties


authentication.protection.enabled=false

So now the user can log in after unlocking in ad.

But so we think that the mitigating brute force attack on user passwords in Alfresco does not work correctly.

Mitigating brute force attack on user passwords | Alfresco Documentation 

Thanks and regards!

The protection mechanism should be better described. For that I understand only the user should be blocked after 10 unsuccessful login attempts (authentication.protection.limit = 10), but there are no reports of non-authenticating users attempting to log in with the wrong password several times.

Hi:

I think this is not for using audit tools like hydra in an evil way. But I think it may be problematic for the final user, when Alfresco is configured with a complex authentication chain with several user directory origins, and the user is failing several times the real password because he/she needs more coffee...

Regards.

--C.

ainsof
Confirmed Champ
Confirmed Champ

I have a similar problem and I think it has something to do with ldap-ad. When a user enters an incorrect password, their account gets locked on AD. When they are unlocked on AD, they are still locked on alfresco. The

authentication.protection.periodSeconds=6

settings seems to have no effect, as the account is locked until the alfresco service is restarted.

The solution of :

authentication.protection.enabled=false

works for me too