cancel
Showing results for 
Search instead for 
Did you mean: 

Alfresco 4, AD 2008 R2, user import fails

rocketrog
Champ in-the-making
Champ in-the-making
I have read a lot about this and found many similar posts but no answers. I have alfresco community v4. I am trying to synchronize users and groups with our 2008 R2 Active Directory domain. The import fails with LDAP error code 12. From what I have read, alfresco works well with AD 2003. The paged results problem only shows up with AD 2008 R2. Does anyone have a fix?

Here is LDAP error 12
2012-04-03 13:55:06,330  WARN  [security.sync.ChainingUserRegistrySynchronizer] [Thread-1] Failed initial synchronize with user registries
org.alfresco.error.AlfrescoRuntimeException: 03030000 User and group import failed
   at org.alfresco.repo.security.sync.ldap.LDAPUserRegistry.processQuery(LDAPUserRegistry.java:1141)
   at org.alfresco.repo.security.sync.ldap.LDAPUserRegistry.access$2500(LDAPUserRegistry.java:77)
[snip]
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
Caused by: javax.naming.OperationNotSupportedException: [LDAP: error code 12 - 00002040: SvcErr: DSID-031401E7, problem 5010 (UNAVAIL_EXTENSION), data 0
]; remaining name 'OU=NIDs,OU=WSU Accounts,DC=ad,DC=wsu,DC=edu'

I tried setting queryBatchSize=0. That was interesting; it changed the LDAP error code to 4. I also changed my userSearchBase and was able to import fewer than 1000 users. LDAP error 12 shows up whenever I try to import all users.

This is what I get if I set queryBatchSize=0
 2012-04-03 12:49:53,609  ERROR [security.sync.ChainingUserRegistrySynchronizer] [Thread-1] Synchronization aborted due to error
org.alfresco.error.AlfrescoRuntimeException: 03030000 User and group import failed
   at org.alfresco.repo.security.sync.ldap.LDAPUserRegistry.processQuery(LDAPUserRegistry.java:1141)
   at org.alfresco.repo.security.sync.ldap.LDAPUserRegistry.access$2500(LDAPUserRegistry.java:77)
[snip]
Caused by: javax.naming.SizeLimitExceededException: [LDAP: error code 4 - Sizelimit Exceeded]; remaining name 'OU=NIDs,OU=WSU Accounts,DC=ad,DC=wsu,DC=edu'
   at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3093)

There are web pages about this problem in AD 2008 R2 and the pagedResultsControl, specifically here http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/183a8f2c-0cf7-4081-9110-4cf41b91...

Can I work around LDAP error 12 by changing the properties file or is it a problem with AD 2008 R2?

Groups are imported BTW, but there are only a few dozen of them.
Authentication also works.
9 REPLIES 9

ashex
Champ in-the-making
Champ in-the-making
Go Cougs Smiley Happy

I'm working through a similar issue but it's not quite the same.

Can you post your config for the ldap subsystem?

rocketrog
Champ in-the-making
Champ in-the-making
Go Cougs!

here is my ldap-ad-authentication
# This flag enables use of this LDAP subsystem for authentication. It may be
# that this subsytem should only be used for synchronization, in which case
# this flag should be set to false.
ldap.authentication.active=true

#
# This properties file brings together the common options for LDAP authentication rather than editing the bean definitions
#
ldap.authentication.allowGuestLogin=true

# How to map the user id entered by the user to taht passed through to LDAP
# In Active Directory, this can either be the user principal name (UPN) or DN.
# UPNs are in the form <sAMAccountName>@domain and are held in the userPrincipalName attribute of a user
ldap.authentication.userNameFormat=%s@ad.wsu.edu

# The LDAP context factory to use
ldap.authentication.java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory

# The URL to connect to the LDAP server
ldap.authentication.java.naming.provider.url=ldap://directory.wsu.edu:389

# The authentication mechanism to use for password validation
ldap.authentication.java.naming.security.authentication=simple

# Escape commas entered by the user at bind time
# Useful when using simple authentication and the CN is part of the DN and contains commas
ldap.authentication.escapeCommasInBind=false

# Escape commas entered by the user when setting the authenticated user
# Useful when using simple authentication and the CN is part of the DN and contains commas, and the escaped \, is
# pulled in as part of an LDAP sync
# If this option is set to true it will break the default home folder provider as space names can not contain \
ldap.authentication.escapeCommasInUid=false

# Comma separated list of user names who should be considered administrators by default
ldap.authentication.defaultAdministratorUserNames=admin1,admin2

# This flag enables use of this LDAP subsystem for user and group
# synchronization. It may be that this subsytem should only be used for
# authentication, in which case this flag should be set to false.
ldap.synchronization.active=true

# The authentication mechanism to use for synchronization
ldap.synchronization.java.naming.security.authentication=simple

# The default principal to bind with (only used for LDAP sync). This should be a UPN or DN
ldap.synchronization.java.naming.security.principal=user@ad.wsu.edu

# The password for the default principal (only used for LDAP sync)
ldap.synchronization.java.naming.security.credentials=password

# If positive, this property indicates that RFC 2696 paged results should be
# used to split query results into batches of the specified size. This
# overcomes any size limits imposed by the LDAP server.
ldap.synchronization.queryBatchSize=1000

# If positive, this property indicates that range retrieval should be used to fetch
# multi-valued attributes (such as member) in batches of the specified size.
# Overcomes any size limits imposed by Active Directory.       
ldap.synchronization.attributeBatchSize=1000

# The query to select all objects that represent the groups to import.
ldap.synchronization.groupQuery=(objectclass\=group)

# The query to select objects that represent the groups to import that have changed since a certain time.
ldap.synchronization.groupDifferentialQuery=(&(objectclass\=group)(!(modifyTimestamp<\={0})))

# The query to select all objects that represent the users to import.
ldap.synchronization.personQuery=(&(objectclass\=user)(userAccountControl\:1.2.840.113556.1.4.803\:\=512))

# The query to select objects that represent the users to import that have changed since a certain time.
ldap.synchronization.personDifferentialQuery=(&(objectclass\=user)(userAccountControl\:1.2.840.113556.1.4.803\:\=512)(!(modifyTimestamp<\={0})))

# The group search base restricts the LDAP group query to a sub section of tree on the LDAP server.
ldap.synchronization.groupSearchBase=OU=WSU,DC=ad,DC=wsu,DC=edu

# The user search base restricts the LDAP user query to a sub section of tree on the LDAP server.
ldap.synchronization.userSearchBase=OU=NIDs,OU=WSU Accounts,DC=ad,DC=wsu,DC=edu

# The name of the operational attribute recording the last update time for a group or user.
ldap.synchronization.modifyTimestampAttributeName=modifyTimestamp

# The timestamp format. Unfortunately, this varies between directory servers.
ldap.synchronization.timestampFormat=yyyyMMddHHmmss'.0Z'

# The attribute name on people objects found in LDAP to use as the uid in Alfresco
ldap.synchronization.userIdAttributeName=sAMAccountName

# The attribute on person objects in LDAP to map to the first name property in Alfresco
ldap.synchronization.userFirstNameAttributeName=givenName

# The attribute on person objects in LDAP to map to the last name property in Alfresco
ldap.synchronization.userLastNameAttributeName=sn

# The attribute on person objects in LDAP to map to the email property in Alfresco
ldap.synchronization.userEmailAttributeName=mail

# The attribute on person objects in LDAP to map to the organizational id  property in Alfresco
ldap.synchronization.userOrganizationalIdAttributeName=company

# The default home folder provider to use for people created via LDAP import
ldap.synchronization.defaultHomeFolderProvider=largeHomeFolderProvider

# The attribute on LDAP group objects to map to the authority name property in Alfresco
ldap.synchronization.groupIdAttributeName=cn

# The attribute on LDAP group objects to map to the authority display name property in Alfresco
ldap.synchronization.groupDisplayNameAttributeName=displayName

# The group type in LDAP
ldap.synchronization.groupType=group

# The person type in LDAP
ldap.synchronization.personType=user

# The attribute in LDAP on group objects that defines the DN for its members
ldap.synchronization.groupMemberAttributeName=member

# If true progress estimation is enabled. When enabled, the user query has to be run twice in order to count entries.
ldap.synchronization.enableProgressEstimation=true

ashex
Champ in-the-making
Champ in-the-making
Debugging LDAP imports is a bit of a pain, try using Softerra LDAP Browser and run the same query Alfresco uses (without the timestamp portion) and see if it returns the full results. From there try different paging limits and see what will work.

dward
Champ on-the-rise
Champ on-the-rise
Thanks for bringing this to our attention

This appears to be a bug in AD 2008

A possible solution is described in this thread

http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/183a8f2c-0cf7-4081-9110-4cf41b91...

Can you please try modifying your queries to use whenChanged instead of modifyTimestamp. I.e. try the following in alfresco-global.properties:

ldap.synchronization.groupDifferentialQuery=(&(objectclass\=group)(!(whenChanged<\={0})))
ldap.synchronization.personDifferentialQuery=(&(objectclass\=user)(userAccountControl\:1.2.840.113556.1.4.803\:\=512)(!(whenChanged<\={0})))

If this works for you, please let us know and we'll make this the new product default.

rocketrog
Champ in-the-making
Champ in-the-making
Success! (with a caveat…)

Thanks Dave. Made the changes, restarted the app and the logs show
2012-04-16 11:41:39,996  INFO  [security.sync.ChainingUserRegistrySynchronizer] [ldap-ad1 User Creation and Association1] ldap-ad1 User Creation and Association: Processed 45700 entries out of 45944. 99% complete. Rate: 9 per second. 0 failures detected.
2012-04-16 11:41:59,055  INFO  [security.sync.ChainingUserRegistrySynchronizer] [ldap-ad1 User Creation and Association2] ldap-ad1 User Creation and Association: Processed 45800 entries out of 45944. 100% complete. Rate: 9 per second. 0 failures detected.
2012-04-16 11:42:16,708  INFO  [security.sync.ChainingUserRegistrySynchronizer] [ldap-ad1 User Creation and Association1] ldap-ad1 User Creation and Association: Processed 45900 entries out of 45944. 100% complete. Rate: 9 per second. 0 failures detected.
2012-04-16 11:42:23,395  INFO  [security.sync.ChainingUserRegistrySynchronizer] [Thread-1] ldap-ad1 User Creation and Association: Processed 45954 entries. Rate: 9 per second. 0 failures detected.
2012-04-16 11:42:23,395  INFO  [security.sync.ChainingUserRegistrySynchronizer] [Thread-1] ldap-ad1 User Creation and Association: Completed batch of 45944 entries
2012-04-16 11:42:25,082  INFO  [security.sync.ChainingUserRegistrySynchronizer] [Thread-1] Finished synchronizing users and groups with user registry 'ldap-ad1'
2012-04-16 11:42:25,082  INFO  [security.sync.ChainingUserRegistrySynchronizer] [Thread-1] 45
The caveats are that our AD has about 250,000 users so I will look into that, but more distressingly, tomcat6 is spiking to 99% CPU a day later. I read some forum posts about CPU spikes and I will let the computer run for four days and hope something changes.

dward
Champ on-the-rise
Champ on-the-rise
OK I've logged and fixed

https://issues.alfresco.com/jira/browse/ALF-13735

This will find its way into HEAD and future releases, just as soon as I get around to the merge in the next few days…

Thanks for helping us improve the interoperability of Alfresco with AD.

rocketrog
Champ in-the-making
Champ in-the-making
Yea! my first open-source contribution, kind of Smiley Very Happy

dward
Champ on-the-rise
Champ on-the-rise
It's now in HEAD and will be in nightly builds from tomorrow (although it's probably easier just to make the config change yourself!)

ashex
Champ in-the-making
Champ in-the-making
Well then, I should have reported this weeks ago!  :lol: I assumed there was a config issue on my end, this will probably fix the problems we're having!