Grouper Users - Open Discussion List

[Tom Zeller <>]

Apologies for the delay in my response.

In general, I think you will be ok, meaning : you should be able to do
what you want.

It will take me a minute to parse your configuration, in the meantime,
could you help me understand  :

> Our static groups may not have a canonical groupDn, and often not any static
> group at all.

I think you are saying that the ldap dn of a static group is user
specified, and stored as a group attribute in grouper. This seems
fine.

And, regarding :

> allows the user to also specify the DOMAIN where groups are stored (we do
> not always have them in the same domain as users).

What is the impact of the user specified domain ? Does each domain
require an ldap connection ?

Thanks for trying out the psp.

TomZ

On Wed, Apr 4, 2012 at 12:05 PM, Colin Hudler 
<>
 wrote:
> We have custom provisioner to LDAP. Users are allowed to add a Group Type
> and attribute value that the provisioner looks for to enable the
> synchronization to LDAP. One of the attributes allows the user to write the
> group into one or many pre-defined LDAP containers (e.g,
> ou=groups,ou=groups,ou=application,...). The attribute value is a string
> containing DNs separated by semicolon.
>
> My approach so far is the goal of psp writing exactly the same
> static/dynamic groups as our custom sync. Success is measured by bulkCalc
> returning whatever is the equivalent of no-op. Alternatively, I can
> restructure how we use Types and Attributes. The immovable is our ability to
> direct static groups using Type/Attribute for one or more LDAP containers.
>
> I have been successful in plucking the groups in GroupDataConnector,
> AllGroupNamesConnector, et al, by using GroupExactAttribute filters.
> However, I wonder about the feasibility of the dynamic user-specified static
> group DNs. Besides that I cannot currently conceive of the correct
> psp-resolver configuration, I think this might be opposed to the design
> (please let me know). Will it cause problems with the groupDn attribute? Our
> static groups may not have a canonical groupDn, and often not any static
> group at all. Attached is my attempt at a psp-resolver and psp.xml
> configuration just for POC. I think the log message during bulkCalc "PSO
> Identifier Definition 'groupDn' - Source attribute 'groupDn' does not exist"
> points at least at part of my problem.
>
> As if that isn't enough, our custom AD synchronizer works similarly, except
> allows the user to also specify the DOMAIN where groups are stored (we do
> not always have them in the same domain as users). Perhaps I'll tackle this
> another time, but we also have user objects from a forest trust which are
> resolved by the provisioner (the group-member in AD must be a specially
> formatted foreign SID obtained from the other forest, not a vanilla local
> user object). WHAT A MESS!