Update user group not getting synchronized

[Antony Pulicken]

Hi,

We have AD has the source and we are facing an issue while trying to update the groups (memberOf) of a user in AD.  The changes in the user groups (memberOf) attribute of the user is not getting 'synchronized' to Syncope if we update only that attribute. It works perfectly fine when we change some other attribute like first name or last name along with user group (memberOf).

Do you have any suggestions? Please let me know.

Thanks and Regards,
Antony.

[Fabio Martelli]

Really strange.
Are you using the latest committed version of AD connector?

I provided a sync test really complete from my point of view. In particular, with reference to your issue, I verify creation, group IN and group OUT.

Please, let me have more information about.

Regards,
F.

[Antony Pulicken]

Thanks Fabio for the response.

We are using a two month old version of AD connector. But today I took the latest AD connector code from the trunk and configured it in Syncope and the result is the same !

Then I configured SyncTest.java to point to my local AD and even that is failing after the group membership update (SyncTest.java:234). Please let me know your thoughts.

java.lang.AssertionError: expected:<1> but was:<0>
    at org.junit.Assert.fail(Assert.java:91)
    at org.junit.Assert.failNotEquals(Assert.java:645)
    at org.junit.Assert.assertEquals(Assert.java:126)
    at org.junit.Assert.assertEquals(Assert.java:470)
    at org.junit.Assert.assertEquals(Assert.java:454)
    at org.connid.ad.sync.SyncTest.sync(SyncTest.java:234)
 
Regards,
Antony.

[Fabio Martelli]

Il giorno 07/dic/2011, alle ore 07.36, Antony Pulicken ha scritto:

Thanks Fabio for the response.

We are using a two month old version of AD connector. But today I took the latest AD connector code from the trunk and configured it in Syncope and the result is the same !

Then I configured SyncTest.java to point to my local AD and even that is failing after the group membership update (SyncTest.java:234). Please let me know your thoughts.

java.lang.AssertionError: expected:<1> but was:<0>
    at org.junit.Assert.fail(Assert.java:91)
    at org.junit.Assert.failNotEquals(Assert.java:645)
    at org.junit.Assert.assertEquals(Assert.java:126)
    at org.junit.Assert.assertEquals(Assert.java:470)
    at org.junit.Assert.assertEquals(Assert.java:454)
    at org.connid.ad.sync.SyncTest.sync(SyncTest.java:234)

Hi Antony,

I cannot imagine what are differences between our target AD resources.

I have to well understand your customizations about:

1. SyncTest.java (or other .java files)

2. ad.properties file

Please, let me have your changes.

Regards,

F.

[Antony Pulicken]

Hi Fabio,

I have not customized anything. I took the latest code from trunk and only modified the ad.properties. Please find my ad.properties below:

host = 172.16.147.129
port = 636
principal = cn=administrator,cn=Users,DC=poc,DC=demo,DC=com
credentials = password
usersBaseContext = cn=Users,DC=poc,DC=demo,DC=com
baseContextToSynchronize = DC=poc,DC=demo,DC=com
memberships = CN=Domain Guests,cn=Users,DC=poc,DC=demo,DC=com ; CN=Domain Computers,cn=Users,DC=poc,DC=demo,DC=com

Regards,
Antony

[Fabio Martelli]

Il giorno 07/dic/2011, alle ore 14.49, Antony Pulicken ha scritto:

Hi Fabio,

I have not customized anything. I took the latest code from trunk and only modified the ad.properties. Please find my ad.properties below:

host = 172.16.147.129
port = 636
principal = cn=administrator,cn=Users,DC=poc,DC=demo,DC=com
credentials = password
usersBaseContext = cn=Users,DC=poc,DC=demo,DC=com
baseContextToSynchronize = DC=poc,DC=demo,DC=com
memberships = CN=Domain Guests,cn=Users,DC=poc,DC=demo,DC=com ; CN=Domain Computers,cn=Users,DC=poc,DC=demo,DC=com

Hi Antony,

your configuration seems to be right. I executed integration tests using groups "CN=Domain Guests" and "CN=Domain Computers" and all seems to work fine.

Just a little bug to solve in CrudTest (equals assertion between expected groups and actuals). 

No problems about synchronization.

What about the number of members of the group indicated? I ask you this question because we could have a problem with the pagination.

Please let me know.

I am just a little bit scared of membership configuration from syncope console: that white space between "Domani" and "Guest"/"Computers" could be a problem.

Probably a bug to solve. I will check it within this week and I come back to you asap.

Regards,

F.

[Antony Pulicken]

Thanks Fabio for the quick response.

The number of members indicated in the group is correct. I also tried adding the user to a group that doesn't have any space in between. But that is also not getting picked up in the sync. 

Currently I'm Not  trying with Syncope as it's clear that issue is with the connector. I'm using 'SyncTest.java' for my testing.

Regards,
Antony.

[Fabio Martelli]

Il giorno 07/dic/2011, alle ore 17.15, Antony Pulicken ha scritto:

Thanks Fabio for the quick response.

The number of members indicated in the group is correct. I also tried adding the user to a group that doesn't have any space in between. But that is also not getting picked up in the sync. 

Could you search for exceptions into surefire logs: please, let me have your .../target/surefire-reports/org.connid.ad.sync.SyncTest-output.txt

Currently I'm Not  trying with Syncope as it's clear that issue is with the connector. I'm using 'SyncTest.java' for my testing.

Yes, I know. That was just a consideration from another point of view..

I think that we should move our discussion on connid mailing list.

Regards,

F.

[Antony Pulicken]

Hi Fabio,

Please find the log files attached (org.connid.ad.sync.SyncTest-output.txt and org.connid.ad.sync.SyncTest.txt). 

I will start posting in the conn id mailing list going forward.

Thanks and Regards,
Antony.

[Fabio Martelli]

Il giorno 08/dic/2011, alle ore 00.01, Antony Pulicken ha scritto:

Hi Fabio,

Please find the log files attached (org.connid.ad.sync.SyncTest-output.txt and org.connid.ad.sync.SyncTest.txt). 

I will start posting in the conn id mailing list going forward.

Hi Antony,

as you know Active Directory (JNDI implementation) connector works only with some version of windows servers (take a look at wiki page).

In case of Windows Server 2003 consider that you have to raise functional level and forest function level of your AD to "Windows Server 2003".

This limitation is due to the use of a particular flag of the DirSync control. 

This flag is used to perform incremental searches and it influences member group IN/OUT (this is exactly your issue).

Please, verify your windows version and configuration (functional level in case of 2003) and let me know.

Furthermore, I opened a new issue on Syncope (#245) in order to manage array attribute better than now.

Thank you again for your collaboration.

Best regards,

F.

<org.connid.ad.SyncTest-output.txt><org.connid.ad.SyncTest.txt>

[Fabio Martelli]

Hi Antony,

sorry but we have to move our further discussion in mailing list.

Please, find my comments in line.

Il giorno 09/dic/2011, alle ore 16.55, Fabio Martelli ha scritto:

Il giorno 08/dic/2011, alle ore 00.01, Antony Pulicken ha scritto:

Hi Fabio,

Please find the log files attached (org.connid.ad.sync.SyncTest-output.txt and org.connid.ad.sync.SyncTest.txt).  

I will start posting in the conn id mailing list going forward.

Hi Antony,

as you know Active Directory (JNDI implementation) connector works only with some version of windows servers (take a look at wiki page).

In case of Windows Server 2003 consider that you have to raise functional level and forest function level of your AD to "Windows Server 2003".

This limitation is due to the use of a particular flag of the DirSync control. 

This flag is used to perform incremental searches and it influences member group IN/OUT (this is exactly your issue).

Please, verify your windows version and configuration (functional level in case of 2003) and let me know.

Furthermore, I opened a new issue on Syncope (#245) in order to manage array attribute better than now.

Thank you again for your collaboration.

Best regards,

F.

Il giorno 12/dic/2011, alle ore 09.03, Antony Pulicken ha scritto:

I did a workaround for it..Actually, I'm not sure whether it's a workaround or a fix...  please see the highlighted part in the code snippet from ADSyncStrategy.handleSyncDelta() and let me know your thoughts..Actually, member00 and member11 are handled in the same way...and it is working fine for the initial test cases that I executed in Syncope. Please let me know your thoughts...

Unfortunately member00 and member11 cannot be handled in the same way.

Member00 indicates users OUT from a certain group. This means that those users must be removed so the SyncDeltaType must be "DELETE".

This scenario is tested into SyncTest.java (from row #248 to row #273).

The fact that user is recreated in syncope is really strange. Possible cause are:

1. Syncope sync bug

2. Bad configuration

3. Something else inside ADSyncStrategy about coming from intersection between "CREATE_OR_UPDATE" set and "DELETE" set.

Furthermore, as written in syncope mailing list, about "Memberships" configuration, I'm going to work for a bug-fix.

From my side the next steps will be:

1. Work on issue #245

2. some tests in order to verify your issue

3. test execution report in mailing list (may be issue opened)

I'll come back to you asap.

Regards,

F.

        if (member00 != null) {
                // users to be removed
                if (LOG.isOk()) {
                    LOG.ok("Found users 'OUT' ...");
                }

                final NamingEnumeration<String> userDNs =
                        (NamingEnumeration<String>) member00.getAll();

                while (userDNs.hasMoreElements()) {
                    userDN = userDNs.next();
                    if (LOG.isOk()) {
                        LOG.ok("OUT user {0}", userDN);
                    }

                    profile = ctx.getAttributes(userDN);

                    guid = DirSyncUtils.getGuidAsString(
                            (byte[]) profile.get("objectGUID").get());

                    if (!handled.contains(guid)) {
                        handled.add(guid);

                        handler.handle(getSyncDelta(
                                oclass,
                                userDN,
                                SyncDeltaType.CREATE_OR_UPDATE, //SyncDeltaType.DELETE,
                                profile));
                    }
                }
            }

On Mon, Dec 12, 2011 at 9:24 AM, Antony Pulicken <antony....@gmail.com> wrote:

Further to the mail below, since I was not sure how to set 'Memberships' property from Syncope, I modified ADConfiguration.java constructor to pick up the valid groups from a configuration file. 

The sync started working fine partially as the addition of user groups were immediately getting synced to syncope. How ever, when we remove a user from an user group, the user is getting deleted and re-created in syncope. Have you tested this scenario before ? Please let me know.

Thanks and Regards,
Antony.

On Sun, Dec 11, 2011 at 9:49 PM, Antony Pulicken <antony....@gmail.com> wrote:

Thanks a lot Fabio. The test case is working fine after I raised the function level. But syncope still doesn't seem to work and I think it is because I have not set the 'Memberships'property of the ADConnector. Can you tell me where/how I can set this

Regards,

F.

[Antony Pulicken]

Hi Fabio,

I tested update and delete with just one user and couple of groups, and it's getting synchronized to syncope as expected ! I also added the user to a registered group (with out changing any other attributes of the user) and even that got synched with out any issues. Thanks for all the help !!

But when I deleted the user from a registered group, that is not getting synchronized to syncope. If we change any other attributes of the user along with the deletion from the group, then it's getting reflected in syncope. Please note that in the earlier version the user was getting re-created in syncope in this scenario and that has been resolved now. It's evident from the log files that user is getting picked up in the sync, but not getting propagated to syncope in this particular scenario.  Here are the log entries :  I have also attached the log file and connector configuration for your reference.

07:56:53.303 DEBUG org.connid.ad.sync.ADSyncStrategy.handleSyncDelta Modified group CN=Domain Controllers,CN=Users,DC=poc,DC=demo,DC=com
07:56:53.303 DEBUG org.connid.ad.sync.ADSyncStrategy.handleSyncDelta Found users OUT ...
07:56:53.304 DEBUG org.identityconnectors.framework.api.operations.SyncApiOp.sync Return: null
07:56:53.320 DEBUG org.identityconnectors.framework.api.operations.SyncApiOp.getLatestSyncToken Enter: getLatestSyncToken(ObjectClass: __ACCOUNT__)
07:56:53.320 DEBUG org.identityconnectors.framework.api.operations.SyncApiOp.getLatestSyncToken Return: SyncToken: [B@23a1effa
07:56:53.352 DEBUG org.identityconnectors.framework.api.operations.ValidateApiOp.validate Enter: validate()
07:56:53.354 DEBUG org.identityconnectors.framework.api.operations.ValidateApiOp.validate Return: null




Regards,
Antony.

On Mon, Dec 19, 2011 at 7:13 PM, Fabio Martelli <fabio.m...@gmail.com> wrote:

Il giorno 19/dic/2011, alle ore 13.53, Antony Pulicken ha scritto:

Sure Fabio. I will send the mail to the mailing list. The only reason it came to you directly is because you had sent a mail directly to me and I just responded to that. Anyway, sorry for that.

Antony, you found a bug in ad connector test. I've just fixed it as follows:

1. must be provided exactly 2 groups in ad.properties (added a comment)

2. evaluations must be done evaluating memberships in OR (modified SyncTest.java)

3. modified some assertion into SyncTest.java

Thank you for your feedbacks.

Let me know in mailing list about your integration between syncope and ad.

Regards,

F.

1. email should be an e-mail  --> is sAMAccountName an email?
Not sure how that happened. I have reverted it back again now.

2. by default userId schema is mandatory (and is an email) be sure to remove it or map it on an external attribute
Didn't quite get it.

I will send a mail with the details that you requested to the mailing list after testing this change.

Regards,
Antony.

On Mon, Dec 19, 2011 at 5:34 PM, Fabio Martelli <fabio.m...@gmail.com> wrote:

Hi Antony,

I have to ask you to write in mailing list (please, attach screenshots and syncope log files). 

... Questions and answers can help someone else ....

In the meanwhile, be sure to have configured the correct user schema mapping:

1. email should be an e-mail  --> is sAMAccountName an email?

2. by default userId schema is mandatory (and is an email) be sure to remove it or map it on an external attribute

....

I will wait for your email in mailing list.

Regards,

F.

Il giorno 19/dic/2011, alle ore 12.00, Antony Pulicken ha scritto:

Sorry Fabio. Please ignore my previous mail. I set  AdConfiguration.membershipsInOr to true and SyncTest went through. The earlier issue I mentioned was a data issue. How ever, I'm still struggling with syncope and not sure why I got  javax.naming.OperationNotSupportedException in Syncope. Please find attached the screenshots of the connector/resource configuration of the AD connector and let me know in case you find anything wrong with the configuration.

If you don't have time to look at it, please send me a screenshot of your AD connector and resource configuration so that I can compare.

Thanks and Regards,
Antony.

On Mon, Dec 19, 2011 at 4:09 PM, Antony Pulicken <antony....@gmail.com> wrote:

I took the latest from trunk (AD Connector) and I'm getting javax.naming.OperationNotSupportedException in both SyncTest.java and in Syncope. Can you please run SyncTest.java and see what happens at your end ? Please find the log details below: 

javax.naming.OperationNotSupportedException: [LDAP: error code 53 - 00002103: LdapErr: DSID-0C090769, comment: Error processing control, data 0, vece]; remaining name 'DC=poc,DC=demo,DC=com'
    at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3140)
    at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3013)
    at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2820)
    at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1829)
    at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1752)
    at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:368)
    at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:338)
    at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:321)
    at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:248)
    at org.connid.ad.sync.ADSyncStrategy.search(ADSyncStrategy.java:97)
    at org.connid.ad.sync.ADSyncStrategy.sync(ADSyncStrategy.java:201)
    at org.connid.ad.ADConnector.sync(ADConnector.java:131)
    at org.identityconnectors.framework.impl.api.local.operations.SyncImpl.sync(SyncImpl.java:63)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.identityconnectors.framework.impl.api.local.operations.ConnectorAPIOperationRunnerProxy.invoke(ConnectorAPIOperationRunnerProxy.java:93)
    at $Proxy11.sync(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.identityconnectors.framework.impl.api.local.operations.ThreadClassLoaderManagerProxy.invoke(ThreadClassLoaderManagerProxy.java:107)
    at $Proxy11.sync(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.identityconnectors.framework.impl.api.BufferedResultsProxy$BufferedResultsHandler.run(BufferedResultsProxy.java:162)

Regards,
Antony.

On Mon, Dec 19, 2011 at 2:15 PM, Fabio Martelli <fabio.m...@gmail.com> wrote:

Il giorno 19/dic/2011, alle ore 09.17, Antony Pulicken ha scritto:

Thanks Fabio as usual for the quick response.

I have not configured the new properties. I didn't see anything new in the ad.properties that is there on the trunk. Can you please tell me where/how to configure these new properties for the following scenarios ?

• In AD connector for running SyncTest.java

No new properties in ad.properties. For SyncTest.java you have nothing to do.

• In syncope for testing sync

It depends on what you are implementing.

1. if you want to perform an initial loading please check "Initial loading". Uncheck it after the first synchronization in order to sync members IN/OUT.

2. check "Verify memberships in OR" if you want synchronize users with at least one group specified. Uncheck it if you want synchronize only members of each specified group.

Please, consider that property at point 1 has been introduced only to increase initial loading performance avoiding useless actions.

Please, let me know something about your further tests.

Best regards,

F.

Regards,
Antony.

On Mon, Dec 19, 2011 at 1:28 PM, Fabio Martelli <fabio.m...@gmail.com> wrote:

Il giorno 19/dic/2011, alle ore 07.50, Antony Pulicken ha scritto:

Hi Fabio,

I took the latest AD connector code from the trunk and this issue has re-appeared. i.e, the updates of user group are not getting synchronized !! Can you please try running SyncTest.java on your environment after taking the latest code from the trunk ?

Hi Antony,

are you sure to have well configured new properties?

* Initial loading (check it just to perform an initial loading: this check ignore groups modifications)

* Verify memberships in OR (check it if you want to verify membership using  logical operator 'OR')

Actually, I'm using windows server 2003 since the time we started to work on this issue.

So I'm quite sure that the issue is not re-appeared.

Please, let me know.

Regards,

F.

<Screen Shot 2011-12-19 at 4.27.59 PM.png><Screen Shot 2011-12-19 at 4.28.21 PM.png>

[Fabio Martelli]

Il giorno 20/dic/2011, alle ore 08.46, Antony Pulicken ha scritto:

Hi Fabio,

I tested update and delete with just one user and couple of groups, and it's getting synchronized to syncope as expected ! I also added the user to a registered group (with out changing any other attributes of the user) and even that got synched with out any issues. Thanks for all the help !!

But when I deleted the user from a registered group, that is not getting synchronized to syncope. If we change any other attributes of the user along with the deletion from the group, then it's getting reflected in syncope. Please note that in the earlier version the user was getting re-created in syncope in this scenario and that has been resolved now. It's evident from the log files that user is getting picked up in the sync, but not getting propagated to syncope in this particular scenario.  Here are the log entries :  I have also attached the log file and connector configuration for your reference.

Hi Antony,

how many groups the user is member of?

You are working verifying memberships in OR. This means that if user is member of both specified groups, going out from one of these cannot imply a deletion.

Please, consider that working with "Verify memberships in OR" users will be considered "valid" till they are members of one specified group at least.

Furthermore, remember that if you want to retrieve "deleted users" and "users OUT" you have to check "Retrieve deleted users" (as you did, of course).

Please, check your memberships and let me know.

Best regards,

F.

to have to sync a deletion user must be OUT from both 

[Antony Pulicken]

Hi Fabio,

I think I didn't explain the issue correctly.  I'm not talking about the user getting deleted when we remove the user from 1 of the group.

I have mapped 'memberOf' (string, multi-value) attribute in the resource mapping and I can see that attribute getting updated in syncope when the user is added to a registered group in AD. But the vice versa is not happening.  That is, when the user is removed from a group, that user group is not getting deleted from the memberOf attribute of the user in syncope. It gets updated only if we change any other attribute like first name or last name. I hope we are on the same page now.

Regards,
Antony.

[Fabio Martelli]

Il giorno 20/dic/2011, alle ore 10.35, Antony Pulicken ha scritto:

Hi Fabio,

I think I didn't explain the issue correctly.  I'm not talking about the user getting deleted when we remove the user from 1 of the group.

I have mapped 'memberOf' (string, multi-value) attribute in the resource mapping and I can see that attribute getting updated in syncope when the user is added to a registered group in AD. But the vice versa is not happening.  That is, when the user is removed from a group, that user group is not getting deleted from the memberOf attribute of the user in syncope. It gets updated only if we change any other attribute like first name or last name. I hope we are on the same page now.

Sure, NOW we are on the same page :) The "problem" is clear. 

As you know memberOf is not a real attribute but a backlink attribute. This means that user is not modified adding or removing memberships.

This is the reason why DirSync protocol cannot catch memberships modification just looking users: in order to catch "usersIN" and "usersOUT" we look for specified groups modification also.

At the moment, for each modified membership I'm going to verify the filter (mermerships and custom filter).

If filter/condition is verified changes are applied: userIN --> create/update; userOUT --> delete.

If filter/condition is not verified changes are ignored.

With a little modification we can catch memberOf attribute change but just for memberships interested by specified groups.

This means that if a user will come into a not synchronized group, changes to user's memberOf attribute won't be synchronized; otherwise, if group is under synchronization, user's memberOf attribute will be synchronized.

Alternatively, we can look for each modified group. In this way we can catch all mermberOf attribute updates. This behavior is simple to implement but I am a little bit scared of about the performances.

In conclusion, we can make this little code change accepting limitation above but which alternative would you suggest?

Thank you for you contribution.

Regards,

F.

[Antony Pulicken]

Thanks Fabio for the detailed response.

Before discussing about the approach that we should take, can you tell me how it is working when a user is added to a registered group ? It gets synched 'independently'  and you can see the new group in the memberOf attribute in syncope.  The 'delete' of a user from the group should work the same way right ? Here are my thoughts on the approaches:

1. I feel registering the group memberships itself is NOT a good idea. Or in other words, we should also have a mechanism where we should be able synch all the users just based on the base context irrespective of the groups they belong to? Is it possible in the current scenario.
2. Regarding the approaches you suggested, I feel the first option is better even though it has a limitation( if a user will come into a not synchronized group, changes to user's memberOf attribute won't be synchronized).
3. Looking for each modified group is probably be a deviation from the current approach, as current scope of synchronization is limited to the registered groups currently and it's a performance overhead like you mentioned. Or you can give this option also by having another flag? :-)

[Fabio Martelli]

Il giorno 20/dic/2011, alle ore 12.49, Antony Pulicken ha scritto:

Thanks Fabio for the detailed response.

Before discussing about the approach that we should take, can you tell me how it is working when a user is added to a registered group ? It gets synched 'independently'  and you can see the new group in the memberOf attribute in syncope.  The 'delete' of a user from the group should work the same way right ? Here are my thoughts on the approaches:

If user goes out from a group we can have one of the following actions:

1. user doesn't verify conditions anymore --> syncope user will be deleted

2. user verifies conditions --> no action performed

In case of "user IN" we can have the following two actions:

1. user doesn't verify conditions --> no action performed

2. user verifies conditions --> syncope user will be created/updated

With "conditions" I mean ldap filters generated from connector configuration parameters (memberships, custom filter, ....). 

We can change the behavior by updating syncope user  every time the conditions are verified. This means to change the code relative to "users OUT" management.

1. I feel registering the group memberships itself is NOT a good idea. Or in other words, we should also have a mechanism where we should be able synch all the users just based on the base context irrespective of the groups they belong to? Is it possible in the current scenario.

It should be possible without specify memberships but by adding a custom search filter.

Btw, in this case, keeping the code as is, we cannot catch memberOf updates.

2. Regarding the approaches you suggested, I feel the first option is better even though it has a limitation( if a user will come into a not synchronized group, changes to user's memberOf attribute won't be synchronized)

3. Looking for each modified group is probably be a deviation from the current approach, as current scope of synchronization is limited to the registered groups currently and it's a performance overhead like you mentioned. Or you can give this option also by having another flag? :-)

I was thinking about performance .... probably what I wrote before is not so true: since, as far as I know, in general groups are much lower than users, including all groups in the DirSync search filter shouldn't be so negative in terms of performance.

I will open an issue to schedule this implementation.

Any comments about will be appreciated.

[Antony Pulicken]

Thanks Fabio for the detailed response.

Before discussing about the approach that we should take, can you tell me how it is working when a user is added to a registered group ? It gets synched 'independently'  and you can see the new group in the memberOf attribute in syncope.  The 'delete' of a user from the group should work the same way right ? Here are my thoughts on the approaches:

If user goes out from a group we can have one of the following actions:

1. user doesn't verify conditions anymore --> syncope user will be deleted

2. user verifies conditions --> no action performed (memberOf attribute of the user in syncope will be updated if it's mapped in syncope)

In case of "user IN" we can have the following two actions:

1. user doesn't verify conditions --> no action performed

2. user verifies conditions --> syncope user will be created/updated

With "conditions" I mean ldap filters generated from connector configuration parameters (memberships, custom filter, ....). 

We can change the behavior by updating syncope user  every time the conditions are verified. This means to change the code relative to "users OUT" management.

1. I feel registering the group memberships itself is NOT a good idea. Or in other words, we should also have a mechanism where we should be able synch all the users just based on the base context irrespective of the groups they belong to? Is it possible in the current scenario.

It should be possible without specify memberships but by adding a custom search filter.

Btw, in this case, keeping the code as is, we cannot catch memberOf updates.

Better approach would have  been to have the default behavior not to search/filter based on the membership and use the filter if any one wants to synch only certain groups. By the way, can you give me an example of the custom search filter (with out specifying memberships)? 

2. Regarding the approaches you suggested, I feel the first option is better even though it has a limitation( if a user will come into a not synchronized group, changes to user's memberOf attribute won't be synchronized)

3. Looking for each modified group is probably be a deviation from the current approach, as current scope of synchronization is limited to the registered groups currently and it's a performance overhead like you mentioned. Or you can give this option also by having another flag? :-)

I was thinking about performance .... probably what I wrote before is not so true: since, as far as I know, in general groups are much lower than users, including all groups in the DirSync search filter shouldn't be so negative in terms of performance.

I will open an issue to schedule this implementation.

Any comments about will be appreciated.

Ok. Then we can go with the approach 3 itself. With this fix, the memberOf attribute of the user in syncope should get updated when a user is added/removed from a group, even if the group is not registered. Hope my understanding is correct. This is a very critical issue for us and it's reported at the customer environment. Hope we will get a fix soon :-) Please let me know how I can help.
 

[Fabio Martelli]

Il giorno 21/dic/2011, alle ore 07.03, Antony Pulicken ha scritto:

Thanks Fabio for the detailed response.

Before discussing about the approach that we should take, can you tell me how it is working when a user is added to a registered group ? It gets synched 'independently'  and you can see the new group in the memberOf attribute in syncope.  The 'delete' of a user from the group should work the same way right ? Here are my thoughts on the approaches:

If user goes out from a group we can have one of the following actions:

1. user doesn't verify conditions anymore --> syncope user will be deleted

2. user verifies conditions --> no action performed (memberOf attribute of the user in syncope will be updated if it's mapped in syncope)

In case of "user IN" we can have the following two actions:

1. user doesn't verify conditions --> no action performed

2. user verifies conditions --> syncope user will be created/updated

With "conditions" I mean ldap filters generated from connector configuration parameters (memberships, custom filter, ....). 

We can change the behavior by updating syncope user  every time the conditions are verified. This means to change the code relative to "users OUT" management.

1. I feel registering the group memberships itself is NOT a good idea. Or in other words, we should also have a mechanism where we should be able synch all the users just based on the base context irrespective of the groups they belong to? Is it possible in the current scenario.

It should be possible without specify memberships but by adding a custom search filter.

Btw, in this case, keeping the code as is, we cannot catch memberOf updates.

Better approach would have  been to have the default behavior not to search/filter based on the membership and use the filter if any one wants to synch only certain groups. By the way, can you give me an example of the custom search filter (with out specifying memberships)? 

First of all consider that filter is not mandatory.

You can use ldap filters like the followings:

* uid=test*

* (|(division=hr)(memberOf=CN=Domain Guests,CN=Users,DC=pluto,DC=org))

* (&(distinguishedName=*,cn=hr,DC=pluto,DC=org)(objectclass=user))

* ....

2. Regarding the approaches you suggested, I feel the first option is better even though it has a limitation( if a user will come into a not synchronized group, changes to user's memberOf attribute won't be synchronized)

3. Looking for each modified group is probably be a deviation from the current approach, as current scope of synchronization is limited to the registered groups currently and it's a performance overhead like you mentioned. Or you can give this option also by having another flag? :-)

I was thinking about performance .... probably what I wrote before is not so true: since, as far as I know, in general groups are much lower than users, including all groups in the DirSync search filter shouldn't be so negative in terms of performance.

I will open an issue to schedule this implementation.

Any comments about will be appreciated.

Ok. Then we can go with the approach 3 itself. With this fix, the memberOf attribute of the user in syncope should get updated when a user is added/removed from a group, even if the group is not registered. Hope my understanding is correct. This is a very critical issue for us and it's reported at the customer environment. Hope we will get a fix soon :-) Please let me know how I can help.

Actually I already finished but I still have a strange behavior about user creation: sometimes memberOf attribute is not included into the set of returned attributes.

Now I'm investigating this bug. I'll come back to you asap.

[Antony Pulicken]

Thanks Fabio. Will wait for the updates from you. Hope you will be applying the fix to the tag as well.
http://syncope.googlecode.com/svn/tags/syncope-0.7RC1/

Regards,
Antony.

[Fabio Martelli]

Il giorno 21/dic/2011, alle ore 09.18, Antony Pulicken ha scritto:

Thanks Fabio. Will wait for the updates from you. Hope you will be applying the fix to the tag as well.
http://syncope.googlecode.com/svn/tags/syncope-0.7RC1/

Fix is only on the AD connector.

[Francesco Chicchiriccò]

On 21/12/2011 09:18, Antony Pulicken wrote:

Thanks Fabio. Will wait for the updates from you. Hope you will be applying the fix to the tag as well.
http://syncope.googlecode.com/svn/tags/syncope-0.7RC1/

An svn tag is a read-only thing: every further release will have its own tag (syncope-0.7RC2 / syncope-0.7-RC3, syncope-0.7, syncope-0.7.1 and so on); there is a dedicated branch for commits of release 0.7.X (http://syncope.googlecode.com/svn/branches/0_7_X/).

Regards.

-- 
Francesco Chicchiriccò

"Computer Science is no more about computers than astronomy
is about telescopes." (E. W. Dijkstra)

[Fabio Martelli]

Hi Antony and all,

issue #25 has been fixed. Please check it out and let me have your feedbacks.

Best regards,

F.

[Antony Pulicken]

Hi Fabio,

I tested and it's working perfectly !! Thanks a lot for the fix and the quick response.

Regards,
Antony.