Grouper Users - Open Discussion List

[Tom Zeller <>]

Please see responses inline. Basically, I've committed what we've
agreed to and it's slated for 1.5.0.

On Tue, Oct 20, 2009 at 5:03 PM, Raymond D Walker 
<>
 wrote:
> 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.

Implemented as on-not-found="fail|warn|ignore", which if unspecified
defaults to warn.

<source-subject-identifier source="..." subject-attribute="..." >
  <ldap-search
     base="..."
     scope="...
     filter="..."
     on-not-found="fail|warn|ignore" />
</source-subject-identifier>

>
>>> -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.

Implemented as multiple-results="false|true", which if unspecified
defaults to false (the current behavior). If multiple-results="true",
then multiple objects may be provisioned for a single subject.

<source-subject-identifier source="..." subject-attribute="..." >
  <ldap-search
     base="..."
     scope="...
     filter="..."
     multiple-results="false|true" />
</source-subject-identifier>

TomZ