topic Re: Long Song Sync Ldap in Alfresco Archive

Long Song Sync Ldap

paulweb — Wed, 05 Aug 2009 06:02:35 GMT

os: win xp pro alfresco version 3.2for ldap Authentication I setalfresco-global.propertiesauthentication.chain=alfrescoNtlm1:alfrescoNtlm,ldap1:ldap‍‍‍alfresco-authentication.propertiesalfresco.authentication.allowGuestLogin=truealfresco.authentication.authenticateCIFS=true‍‍‍‍ldap-authentication.pr

Re: Long Song Sync Ldap

dward — Wed, 05 Aug 2009 08:45:10 GMT

Try using this URL

ldap.authentication.java.naming.provider.url=ldap://pridc.my-domain.ru:389

and if that doesn't work you need to double check your parameters using an LDAP browser (such as the one from http://www.ldapbrowser.com)

Make sure you can connect to ldap://pridc.my-domain.ru:389 with the username in

ldap.synchronization.java.naming.security.principal

and password in

ldap.synchronization.java.naming.security.credentials

Now browse to the ou for the group search base and make sure the DN matches the one you have configured in ldap.synchronization.groupSearchBase. Do the same for ldap.synchronization.userSearchBase.

Please note that any non-ASCII characters in alfresco-global.properties have to be unicode escaped. So if it's easier for you, you can save them in UTF-8 format in a text editor and then use the JDK native2ascii tool to properly encode it as a properties file

native2ascii -encoding UTF-8 < myfile.txt > alfresco-global.properties

Hope this helps.

Re: Long Song Sync Ldap

dward — Wed, 05 Aug 2009 09:11:39 GMT

I see the following additional problems with your configuration

Your group queries are treating organizationalUnits as groups. Therefore your ldap.synchronization.groupType would have to be organizationalUnit. However, that would not work either because a group object has to have a repeating 'member' attribute, unlike organizationalUnit. Please remove your changes to the queries and personType and groupType and use the defaults for ldap-ad.

You have multiple copies of ldap.synchronization.personQuery and ldap.synchronization.personDifferentialQuery. Only the last ones will be used.

Your person queries use organizationalPerson. Therefore you would have to set ldap.synchronization.personType to organizationalPerson

You have set ldap.synchronization.groupMemberAttributeName to title. This will never work as the group member attribute must be a multi-valued attribute that lists the DNs of the members of a group.

The ldap.synchronisation.import.group.clearAllChildren property is not relevant in v3.2

The supplied defaults in ldap-ad.properties should be fine for Active Directory. We did not expect you to have to make such fundamental changes to the queries and types used.

Re: Long Song Sync Ldap

paulweb — Wed, 05 Aug 2009 12:35:22 GMT

Hi, dward
thanks for the help

The supplied defaults in ldap-ad.properties should be fine for Active Directory. We did not expect you to have to make such fundamental changes to the queries and types used.

I did not expect, but such is a life. We in Russia have a saying: "every dog has his day".
I have seen the errors in a configuration and I will correct them. The administrator at us in holiday therefore with some parametres has not understood up to the end.
If all turns out, I will write about it, it can in the future to somebody will help.

But before it I will specify:
1. I checked inquiries in ldapbrowser and javaldap/editor
2. All files I keep in utf-8
3. A line of connection the same correct
4. The duplicate of lines my typing error
5. "ldap.synchronisation.import.group.clearAllChildren=true", you never can tell, and suddenly would leave

Re: Long Song Sync Ldap

benswitzer — Thu, 06 Aug 2009 14:27:23 GMT

I've had my users' access to Share sites disappear. Figuring its because the share groups have been clobbered by my ldap-ad sync.

Prior to 3.2 I had used the "ldap.synchronisation.import.group.clearAllChildren=true" setting to ensure they weren't removed.

I've had to restore from a backup to get things going again.

Hoping that by changing synchronization.synchronizeChangesOnly from false to true, this will fix my issue. I'll report back when my next sync fires.

Ben

Re: Long Song Sync Ldap

dward — Thu, 06 Aug 2009 15:29:56 GMT

See also http://forums.alfresco.com/en/viewtopic.php?f=9&t=20715#p67597

There is evidently a problem here.

See http://wiki.alfresco.com/wiki/The_Synchronization_Subsystem#Deletion_Behavior

FYI in v3.2, users and groups imported from an external directory are tagged with a 'zone' ID corresponding to the instance name of the corresponding authentication subsystem. On synchronization with a directory, only those users and groups in its zone are candidates for deletion. In addition, 'collisions' between users with the same ID that exist in a different zone are resolved by letting the directory that exists earlier in the authentication chain take precedence. On collision with a directory of lower precedence, the duplicated user or group is deleted and then recreated in the other directory's zone, as they are assumed to now be a different user or group in a different directory. The problem is that the Alfresco built in users and groups (and those upgraded from previous versions) are all given the lowest precedence. So if your sync brings in users and groups that already exist in Alfresco and weren't created by LDAP sync in v3.2 they will all get deleted and recreated the first time.

Now this clearly isn't ideal in an upgrade scenario, because as you have found, the connections between recreated users and sites will get lost. The synchronizeChangesOnly flag won't affect this behaviour. This just decides whether it queries all users and groups from the directory or just those changed since the last sync. When this flag is true, it can't work out which users and groups have been deleted so won't delete any users and groups, except those that it thinks that have been 'occluded' by higher priority directories, which is still the problem.

I have logged

https://issues.alfresco.com/jira/browse/ETHREEOH-2626

In future, we will give special treatment to users that exist in the built-in Alfresco zone and automatically move them to the LDAP directory's zone. I will try to get this into HEAD ASAP.

Re: Long Song Sync Ldap

benswitzer — Thu, 06 Aug 2009 15:35:47 GMT

Thanks for the feedback.

Question then, will my change to the synchronizeChangesOnly setting have any affect, or will I experience the same issue on the next sync?

Re: Long Song Sync Ldap

dward — Thu, 06 Aug 2009 15:39:14 GMT

The synchronizeChangesOnly flag won't affect this behaviour.

Re: Long Song Sync Ldap

dward — Thu, 06 Aug 2009 18:47:57 GMT

FYI a fix for this has now been merged to HEAD (revision 15637). Here's the change comment:

LDAP sync will no longer delete and recreate colliding users and groups in zones that aren't even in the authentication chain.
- Instead such users and groups will be 're-zoned' to the first zone where they were found
- Avoids losing site memberships, etc. on upgrade or change of authentication chain
- Will continue to recreate users and groups from lower priority zones in the authentication chain
- Updated unit tests appropriately

Re: Long Song Sync Ldap

paulweb — Thu, 06 Aug 2009 22:40:28 GMT

I have found problem :!: . And… this themes I would rename:"Swan song for Russian language"
In LDAPUserRegistry.java i have added debug information and have started alfresco and at authentification has received the following


18:03:46,379 DEBUG [org.alfresco.repo.security.sync.ldap.LDAPUserRegistry] ok1
18:03:46,379 DEBUG [org.alfresco.repo.security.sync.ldap.LDAPUserRegistry] ok4
18:03:46,379 DEBUG [org.alfresco.repo.security.sync.ldap.LDAPUserRegistry] ou=? ?????» ?????µ?????? ???°????,DC=royal-bank,DC=ru
18:03:46,379 DEBUG [org.alfresco.repo.security.sync.ldap.LDAPUserRegistry] (&(objectclass=organizationalPerson)(userAccountControl:1.2.840.113556.1.4.803:=512))
‍‍‍‍‍‍

What is such "ou=? ?????» ?????µ?????? ???°????,DC=royal-bank,DC=ru", you ask? I answer in our AD all groups have russian names for example "отдел программированния" аnd because of it all problems in russian language.
I have corrected inquiry "ldap.synchronization.userSearchBase=ou\=отдел программированния,dc=my-domain,dc=ru" on "ldap.synchronization.userSearchBase=dc\=my-domain,dc=ru" and synchronisation has earned !!!

if you use in AD russian language, then translate your name groups to unicode for example
query
ldap.synchronization.userSearchBase=ou\=отдел программированния,dc=my-domain,dc=ru
query
ldap.synchronization.userSearchBase=ou\=\u043E\u0442\u0434\u0435\u043B \u043F\u0440\u043E\u0433\u0440\u0430\u043C\u043C\u0438\u0440\u043E\u0432\u0430\u043D\u043D\u0438\u044F,dc=my-domain,dc=ru

convertor http://rishida.net/scripts/uniview/conversion

All thanks

Re: Long Song Sync Ldap

dward — Fri, 07 Aug 2009 09:45:56 GMT

If you actually understood my earlier reply, you will see I told you that your properties would need to be unicode escaped. And I showed an example of using the native2ascii tool that comes with the JDK. There is no need to download a custom tool.