grouper-users - RE: [grouper-users] PSPNG to AD question.... ( workaround )
Subject: Grouper Users - Open Discussion List
List archive
- From: "Black, Carey M." <>
- To: Grouper Users <>
- Subject: RE: [grouper-users] PSPNG to AD question.... ( workaround )
- Date: Thu, 25 Apr 2019 05:27:38 +0000
|
I have been through a few rounds of “still getting the error… can I get more permission” but we still have not found the magic switch yet. :(
The issue appears to be limited to only the “Full Sync” processing.
INFO LdapSystem.performLdapModify(392) - - xxx: Performing Ldap modification: [org.ldaptive.ModifyRequest@601820118::modifyDn=cn=xxxx,ou=xxx,ou=xx,OU=xxx,OU=xxx,DC=xxx,DC=xxx,DC=xxx,DC=xxx,DC=xxx, attrMods=[[org.ldaptive.AttributeModification@219437121::attrMod=REPLACE, attribute=[objectclass[group]]]], controls=null, referralHandler=null, intermediateResponseHandlers=null]
Which looks like the only attribute that is attempted to be modified is “objectclass”. Which is a silly thing to try to replace with any other value. Nor is there any reason why PSPNG should think the AD group is no longer a “group”. It is like it just does not compare the values right.
I highly suspect an either a “real bug” in PSPNG, or a “bug” in my configuration of it. I just don’t see it yet.
I have also simplified my config quite a bit to try to rule out the odd stuff I was trying to do. I think the only relevant config values are:
changeLog.consumer.xxxTest.groupSearchAttributes = cn,objectClass changeLog.consumer.xxxTest.groupCreationLdifTemplate = dn: ${utils.bushyDn(group.name.replaceFirst("xxx:yyy:zzz:",""),"cn", "ou")}||cn: ${group.getExtension()}||objectclass: group changeLog.consumer.xxxTest.groupAttributeName = memberof changeLog.consumer.xxxTest.allGroupsSearchFilter = (objectclass=group) changeLog.consumer.xxxTest.singleGroupSearchFilter = (&(objectclass=group)(${utils.bushyDn(group.name.replaceFirst("xxx:yyy:zzz:",""),"cn", "ou").replaceFirst(",ou=.*","")}))
The “replaceFirst()” is to get the DN’s in AD to not know/use the folder structure above where the integration is anchored in grouper. In the singleGroupSearchFilter I am using the same function to build the “cn=<name_of_group>” just for consistency. However, I then need to “cut the dn” at the first “,ou=” too. I suspect I could use “cn=${group.getExtension()}” as well, but I am trying to be as consistent as possible.
OH… I think I found it. ( It still smells like a PSPNG bug to me, but I will accept that a config change can “work around it”....)
I was staring at the object in AD with an LDAP client and it “clicked”... The object has TWO values for objectclass. ( top and group ) And the “REPLACE op” is only trying to put “group” into AD.
So it must be trying to “remove” top. (<-- $@$@#$%@@!!!!!!! )
The default example(for AD) .groupCreationLdifTemplate is (on the wiki): changeLog.consumer.pspng_activedirectory.groupCreationLdifTemplate = dn: cn=${group.name}||cn: ${group.name}||objectclass: group
However then I noticed the example for “POSIX GROUPS”: (and the only one of all of them ) changeLog.consumer.psong_posixGroup.groupCreationLdifTemplate = dn: cn=posix-${group.name}||cn: posix-${group.name}||objectclass: posixGroup||objectclass: groupOfNames||gidNumber: ${group.idIndex}
THERE ARE TWO “objectclass” values being set… “posixGroup” and “groupOfNames”…..
OMG… ( My forehead really took a beating try to get to this “revelation”/”understanding” of PSPNG.)
Changed (added a second “||objectclass: top” value) : changeLog.consumer.xxx.groupCreationLdifTemplate = dn: ${utils.bushyDn(group.name.replaceFirst("xxx:yyy:zzz:",""),"cn", "ou")}||cn: ${group.getExtension()}||objectclass: group||objectclass: top
stop daemon start daemon
start gsh. Trigger a fully sync for the consumer…
provisioner_name="xxx"; // Whatever your provisioner is called in grouper_loader.properties gs=GrouperSession.startRootSession(); full_provisioner=edu.internet2.middleware.grouper.pspng.FullSyncProvisionerFactory.getFullSyncer(provisioner_name); full_provisioner.startFullSyncOfAllGroupsAndWaitForCompletion()
No error in the log.
I think that is a bug in the code. ( Or at least in the docs. ) I don’t understand how any of the example configs could work if “top” is not “implied/ignored automatically”. So I assume that it “use to work” and now it doesn’t. So I hold to thinking it is a bug in the code. Maybe due to the move to the ldaptive library? Maybe some other change? But this behavior does not work with the “example configs”.
GRRRRRR….. time to get some sleep.
Grouper 2.3 api patches installed: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110 pspng patches installed: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24
-- Carey Matthew
From: Jeffrey Williams <>
Confirm with your AD Team, but it sounds like they delegated the common task "Create, delete and manage groups" to your account. Manage here means write access to the members property but I don't think much else. Like many things Microsoft, there are several separate delegations they can use to let you read and write the other properties. It all depends on how permissions-retentive your AD Team wants to be about it. :).
Good luck!
On Wed, Apr 17, 2019 at 10:04 PM Black, Carey M. <> wrote:
-- |
- RE: [grouper-users] PSPNG to AD question.... ( workaround ), Black, Carey M., 04/25/2019
- Re: [grouper-users] PSPNG to AD question.... ( workaround ), Bee-Lindgren, Bert, 04/25/2019
- RE: [grouper-users] PSPNG to AD question.... ( workaround ), Black, Carey M., 04/25/2019
- Re: [grouper-users] PSPNG to AD question.... ( workaround ), Bee-Lindgren, Bert, 04/25/2019
Archive powered by MHonArc 2.6.19.