Grouper Users - Open Discussion List

[Tom Zeller <>]

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>

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

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

> Raymond Walker
> Software Systems Engineer Sr.
> ITS Northern Arizona University