grouper-dev - [grouper-dev] RE: LDAP Loader with Composite Group
Subject: Grouper Developers Forum
List archive
- From: Chris Hyzer <>
- To: Gagné Sébastien <>, "" <>
- Subject: [grouper-dev] RE: LDAP Loader with Composite Group
- Date: Tue, 26 Jun 2012 17:00:27 +0000
- Accept-language: en-US
Cant you configure the ldap loader grouperLoaderLdapGroupNameExpression to be the name of the system of record group? If you have a composite, how will it know which one of the composite to load into? Also,
if you don’t use a composite, and the system of record is just a member of the overall group, then cant the PSP ignore the system of record groups by naming convention? Thanks, Chris From: Gagné Sébastien [mailto:]
Yes that’s the problem, we have multiple locations where we cana dd/remove members for different reasons for different « types » of groups (automated courses groups, manual delegated application
groups, application security groups, distribution list group). We plan on having incremental deployement, so we will only manage course groups in the beginning, but we still have to be in sync with the master directory (Active Directory) Yes the custom sync might me slower than the simpler SQL Loader, but at once a day I don’t think it’s going to be too bad. The PSP shouldn’t use that attribute, so I believe that it’s sync won’t
be affected right ? Back to my original question/problem/bug, when using the composite-include group, it is provisioned to AD, but when the LDAP loader tries to sync it, it tries to add members to a composite, which
is illegal. I believe the LDAP should detect the composite and use the API methods for composite (I believe I saw something like that in the code, but I’m not sure how they should be used) Thanks for your help De : Chris Hyzer []
It would be nice if you didnt have multiple places to add/remove members. You have 3 place right? System of record,
Grouper, and LDAP? From: Gagné Sébastien
[] Here is a quick data sources diagram, I hope it help clear some questions.
The biggest problem now lies with ad-hoc members.
-
If I use the SQL Loader with a single group, all ad hoc modifications are lost with the next sync. Regular syncs are required because group inscriptions will change. -
If I use a composite-include setup (MAT101 = MAT101_systemOfRecord UNION MAT101_includes) o
There will be problems with the LDAP Loader o
User might be confused with the use of the 3 groups (this task is delegated to the departments) -
If I use a 2 groups approach where (MAT101 = ad hoc members and MAT101_systemOfRecord is a member of MAT101), it might work but o
We’ll have to create 2 groups in AD (40 000 groups vs 20 000) o
We could hide the systemOfRecord group from view in Grouper but some might see it in AD (not a big deal) Another solution I thought of is to create a module that will use the Grouper Java API to create the Groups in the registry based on an SQL resultset. The benefits of this is that I will be able
to transform the data before the group creation and I might be able to use only one group. My idea was that, instead of creating a separate systemOfRecord group, I would add an attribute systemOfRecord on every membership I create based on the academic’s database. Would that approach work? Is it possible to get and set a membership attributes using the Java API? Thanks De : Chris Hyzer
Any chance you can draw and send a picture/diagram of what you would like the setup to look like?
J Thanks, Chris From: Gagné Sébastien
It depends on which one you’re talking about ;-) We would have 2 Loaders : one SQL Loader to get the system of record group and one LDAP Loader to bring back the changes made to the groups in AD (these include the overall groups and other “standard”
groups without system of records) Maybe the LDAP Loader should be configured to ignore these overall composite groups, but I thought it was worth mentioning this error. De : Chris Hyzer []
The loader needs to be configured to load the system of record group, not the overall, right? Thanks, Chris From: Gagné Sébastien
This happened with the Overall group. I have : Composite = Part1 UNION Part2 The PSP sent the Composite to AD with members = member of part 1 UNION member of part2 The problem is when the LDAP Loader runs for AD, it tries to add the members of Part1 and Part2 back into the Composite. We might not use this method, but I was testing some alternative and checking what is possible or not. De : Chris Hyzer []
Was the loader group on the overall group or the system of record group? Btw, we are talking about UNION composite since the PSP will provision better than the overall group having as members the system of record (loader) group and the includes group. If that wasn’t the case this
has more overhead than just having members. Anyways, if the loader is loading the system of record group then it should be fine since it is just a normal group. Thanks, Chris From:
On Behalf Of Gagné Sébastien I’m testing the LDAP with Composite Groups and found something that might be a problem I made a Union Composite Group called udem:CompositeInclude2; It has 4 indirect/effective members as a result of the Union of two groups. The PSP was able to provision the group with the effective memberships, meaning that the AD group has the 4 subject as member, not the 2 composite group. This is what I expected and wanted.
The problem come when I turn the LDAP Loader On, I get 4 hibernate exceptions (1 for each member) :
http://tinypaste.com/a6c4a9fb It seems the Loader doesn’t properly manage composite groups, maybe it tries to Add a member when it’s not allowed to on this type of object. Is that kind of use case supported with grouper ? What
should happen if a member is removed from AD ? Should the component of the composite be modified the reflect the change (i.e. remove the member from the group) ? Delete might be doable, but how would you manage a “add member” for a Union composite ? Deleting the Composite in Grouper resulted in the loader creating a normal group based on the members in the Active Directory. Sébastien Gagné, |
Analyste en informatique 514-343-6111 x33844
|
Université de Montréal,
|
Pavillon Roger-Gaudry, local X-100-11 |
- [grouper-dev] LDAP Loader with Composite Group, Gagné Sébastien, 06/21/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Chris Hyzer, 06/21/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Gagné Sébastien, 06/21/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Chris Hyzer, 06/21/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Gagné Sébastien, 06/21/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Chris Hyzer, 06/21/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Gagné Sébastien, 06/26/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Chris Hyzer, 06/26/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Gagné Sébastien, 06/26/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Chris Hyzer, 06/26/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Gagné Sébastien, 06/26/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Gagné Sébastien, 06/26/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Chris Hyzer, 06/21/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Gagné Sébastien, 06/21/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Chris Hyzer, 06/21/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Gagné Sébastien, 06/21/2012
- [grouper-dev] RE: LDAP Loader with Composite Group, Chris Hyzer, 06/21/2012
Archive powered by MHonArc 2.6.16.