Grouper Users - Open Discussion List

[Tom Barton <>]

Legacy attributes, as we use, spring into existence with the creation of a (legacy) group type. Group types are available to anyone with ADMIN on a group to assign to that group. Once a type is assigned, its attributes are available to be filled in by an ADMIN. I would say this isn't a great model for delegation since there's no constraint on it. We have probably gotten away with it for provisioning purposes because only a few IT people know what to put in there or would have the gumption to do so.

New attributes have a much better security model, in particular, supporting constrained delegation. In a more perfect world I'd convert our existing practice to those (right after we upgrade our grouper to the current rev!).

I don't know whether PSP currently could meet our LDAP and AD provisioning needs, but I'm hopeful that further development of that part of grouper will resume before long, and we'll be able to put our feature requests on the table with everyone else.

Tom

On 3/4/2013 1:05 PM, Earl Lewis wrote:

Tom,

Thanks so much for the response, glad to hear someone else is doing this and have developed what sounds like a pretty clear methodology for doing so. 

If I extend your comments re: attributes, it sounds like this would involve IT staff intervention, in order to know when/where to apply these custom attributes to newly created groups, so provisioning gets pushed to the right targets. Is that correct?

We're trying to anticipate a high degree of self-service (on the part of departmental users) for group creation/management. Is this something that you do? And is this concept "compatible" with your provisioning strategy?

Earl

801-581-3635 (office)

801-554-3596 (mobile)

On 3/2/13 5:10 PM, "Tom Barton" <> wrote:

Earl,

At UChicago we selectively provision some groups to LDAP and some to AD. There is only a little overlap between them. Furthermore, many groups are not pushed out to either, or to anywhere else, for a variety of reasons. The general principle we try to follow in this is to put the info where it is needed, but only there.

As to how, we have used locally developed provisioning tools for quite some time. These look for custom attribute values on a group to know whether to provision it to a given target. Distinct OUs in an LDAP or AD service are different targets, as is an isMemberOf-only, no actual group object style. We also provision some groups into our person registry system to support associated applications, and to several other application-specific databases.

We look forward to replacing some of these with PSP in the not distant future.

Tom

On 3/1/2013 11:45 AM, Earl Lewis wrote:

[Edit]

I assume others out there are in similar circumstances so I'm wondering what you're doing and how you're doing it? 

Earl

801-581-3635 (office)

801-554-3596 (mobile)

On 3/1/13 9:53 AM, "Earl Lewis" <> wrote:

We had an interesting discussion yesterday concerning Grouper and it's provisioning to multiple LDAPs. We're in the middle of a limited pilot for our IT department. Our thinking is that we are going to have Grouper provisioning groups on an OpenDJ and ActiveDirectory. Obviously these are two different beasts and need to have their own connector/configurations so updates in Grouper can be reflected in the directories. 

The question came when we started talking about provisioning to one directory OR the other, I.e. push some groups to one directory flavor and some to the other. In other words not just arbitrarily pushing all updates to both. Is targeting specific directories for specific groups the norm, or the exception? 

I assume others out there are in similar circumstances so I'm wondering what you're doing and you're doing it? 

Earl

801-581-3635 (office)

801-554-3596 (mobile)