Grouper Users - Open Discussion List

[Raymond D Walker <>]

See inline...

On Oct 19, 2009, at 12:18 PM, Tom Zeller wrote:

> Please see responses inline, and thanks for the feedback,
> TomZ
>
> On Mon, Oct 19, 2009 at 12:16 PM, Raymond D Walker  
> <>
>  wrote:
>> I have three queries concerning provisioning groups:
>>
>> -Provisioning groups and membership back to the source where members
>> were sourced from (SunOne LDAP in our case,) obviously works fine
>> since all members "exist". For our attempt at enterprise groups
>> rollout, we are also provisioning to Active Directory (via running a
>> second LDAPPC,) where some group members originally sourced from LDAP
>> do not necessarily exist in Active Directory. The behavior we see is
>> the provisioner failing when trying to add a non-existend AD user  
>> to a
>> group provisioned to AD. We've modified some of the code to
>> essentially "ignore" this, but thought it was an appropriate topic to
>> bring up. Is there a different way to be doing this which would avert
>> code modifications?
>
> It seems that some sites might want ldappc to terminate execution if a
> subject cannot be found, while others might want the condition logged,
> or even, as you say, ignored.
>
> Perhaps a property set on the source-subject-identifier xml
> configuration with values of exception, log, or ignore when a subject
> cannot be found ?
>
> e.g.
>
> <source-subject-identifier source="..." subject-attribute="..." >
>   <ldap-search base="..." scope="... filter="..."
> not-found="exception|log|ignore" />
> </source-subject-identifier>

Yes, this would be most optimal, as our current "solution" may or may  
not have possible side effects.

>> -Our Active Directory environment consists of two sub-OU's (faculty/
>> staff & student domains) where some persons play dual roles, and
>> therefore have two accounts with the same uid under both domains. We
>> experienced an issue with adding these people to provisioned
>> enterprise groups as they would be found as "duplicates" and thus  
>> halt
>> the provisioner with an error. The intended outcome would be to have
>> any and all accounts be added to these provisioned enterprise groups.
>> Our workaround has been to modify the lookup code and allow for
>> multiple users to be looked up and then provisioned into the group.
>
> So, there are 2 options : (1) keep the requirement that a subject
> lookup should return one and only one subject and perform multiple
> searches or (2) allow the subject lookup to return multiple results.
> The first option would involve more lookups, which might be annoying
> for large groups.
>
> Option 1 might look like :
>
> <source-subject-identifier source="..." subject-attribute="..." >
>   <ldap-search base="ou=faculty" scope="... filter="..." not- 
> found="ignore" />
>   <ldap-search base="ou=student" scope="... filter="..." not-found=| 
> ignore" />
> </source-subject-identifier>
>
> and option 2 :
>
> <source-subject-identifier source="..." subject-attribute="..." >
>   <ldap-search base="..." scope="... filter="..." not-found="ignore"
> multiple-results="true" />
> </source-subject-identifier>
>
> Implementing both options shouldn't be that difficult. Thoughts ?

I would say both! ...by allowing multiple "ldap-search" entries AND  
allowing the "multiple-results" attribute to be set would take care of  
everything in one fell swoop. Possibly making multiple-results be an  
optional attribute whose default would be false.

For our particular implementation, I'd rather have just one search at  
the base with the ability for multiple returns, as we're treating  
grouper as a strictly enterprise groups tool, thus we don't  
differentiate user types on systems we've provisioned to.

But I can see other implementations wanting to be more strict on their  
user lookups.

>> -Ability to attribute multiple object classes to provisioned groups.
>> Unless I missed how this could be done, I did not see any ability to
>> do this.
>
> Correct. Although just this past Friday I provided integration of the
> Shibboleth Attribute Resolver with ldappc (1.5.0), which means that we
> now have a lot of flexibility when provisioning attributes. Let me
> write a test case and I'll get back on this one.
>

Sounds great & thanks much for your reponses.

-Ray Walker