grouper-users - Re: [grouper-users] PSPNG with bushy LDAP
Subject: Grouper Users - Open Discussion List
List archive
- From: Greg Haverkamp <>
- To: "Morgan, Andrew Jason" <>
- Cc: "" <>
- Subject: Re: [grouper-users] PSPNG with bushy LDAP
- Date: Thu, 30 Jan 2020 16:26:08 -0800
On Thu, Jan 30, 2020 at 3:37 PM Morgan, Andrew Jason <> wrote:
I'm trying to do the same thing for our Oracle DSEE LDAP server, but I don't see a clean way to do it. I need to create a working singleGroupSearchFilter, but gidNumber is not an allowed attribute on objectclass=groupOfUniqueNames (or groupOfNames). We want to keep our bushy layout. Here are a couple ideas:
- Stick the group.idIndex in the "description" attribute
- Create the groups with objectclass=groupOfUniqueNames,posixGroup (not allowed by the schema, but ODSEE doesn't enforce it) and use gidNumber
- Create a new Auxiliary objectclass "osuGrouperGroup" that allows gidNumber
- Use bushyDN but stick the whole group name in the "cn" attribute so that cn is unique
Are there other ideas? Is anyone else using bushy layout with ODSEE, OpenLDAP, etc?
changeLog.consumer.pspng_app.singleGroupSearchFilter = (&(objectClass=groupOfNames)(cn=${group.name}))
changeLog.consumer.pspng_app.groupSearchAttributes = cn,objectClass,description,ou
changeLog.consumer.pspng_app.groupCreationLdifTemplate = dn: ${utils.bushyDn(group.name, "cn", "cn")}||objectClass: groupOfNames||cn: ${group.extension}||cn: ${group.name}||description: ${group.description}
changeLog.consumer.pspng_app.ouCreationLdifTemplate = dn: ${dn}||objectclass: organizationalRole||cn: ${ou}
changeLog.consumer.pspng_app.groupSearchAttributes = cn,objectClass,description,ou
changeLog.consumer.pspng_app.groupCreationLdifTemplate = dn: ${utils.bushyDn(group.name, "cn", "cn")}||objectClass: groupOfNames||cn: ${group.extension}||cn: ${group.name}||description: ${group.description}
changeLog.consumer.pspng_app.ouCreationLdifTemplate = dn: ${dn}||objectclass: organizationalRole||cn: ${ou}
In this particular case, I'm using two CN's, one to represent the value of the leftmost RDN, and one to represent the complete group name for the singleGroupSearchFilter. This has a side effect. Since PSPNG patch 4+ (if my note in GRP-2347 is correct), this can cause considerable logging noise, because an optimization to speed up PSPNG dropped the ability of the logging to handle multi-valued CN's.
I've got at least one application that benefits from this structure in a way I didn't initially expect. With Hashicorp Vault, you can map LDAP group names to Vault policies, to apply policies to group members. With only the leftmost RDN, there'd be the risk of duplicate LDAP groups being issued in Vault's app space. With the complete group name also there, that's not a problem, and it handles the multiple CN values without a problem.
Greg
- [grouper-users] PSPNG with bushy LDAP, Morgan, Andrew Jason, 01/30/2020
- Re: [grouper-users] PSPNG with bushy LDAP, Greg Haverkamp, 01/31/2020
Archive powered by MHonArc 2.6.19.