Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Expected behaviors for provisioning

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Expected behaviors for provisioning

Chronological Thread 
  • From: Tom Zeller <>
  • To: Raymond D Walker <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] Expected behaviors for provisioning
  • Date: Wed, 21 Oct 2009 06:14:20 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=cxf22UHxfhnaGhro2VKcH/mI/5QyxnUj7uA/AQGKX2typbn4XP6AbGPwH6WB75w1za 7QgYmI2PlnyMRz+BlQAXU0YGP9J7TgqWj5U5I4u+x++H28o5CqEqJ5EWDTO3xnww0Pql UX6LyRKLIdeRR/GOppSc0xPhGqG6onLIw9Q6g=

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
> 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="..." >
on-not-found="fail|warn|ignore" />

>>> -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! 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="..." >
multiple-results="false|true" />


Archive powered by MHonArc 2.6.16.

Top of Page