grouper-users - RE: [grouper-users] PSPNG to AD question.... ( workaround )
Subject: Grouper Users - Open Discussion List
List archive
- From: "Black, Carey M." <>
- To: "Bee-Lindgren, Bert" <>, Grouper Users <>
- Subject: RE: [grouper-users] PSPNG to AD question.... ( workaround )
- Date: Thu, 25 Apr 2019 15:07:56 +0000
|
Bert,
I don’t see how “special handling of objectclass or objectclass=top could get in the way later”. FWIW: “top” is as far as I know a universal thing in LDAP. If an LDAP service does not use “top”, then it is not an LDAP service. However, it is your call. Any “special case” can be a problem, or “the best thing since sliced bread”.
As to the question of “how to avoid needing so much diagnosis next time?”: Better DEBUG logging. I am a big fan of verbose logs. Especially at TRACE, and somewhat so on DEBUG. I believe that “TRACE” should review all details that might even be remotely “hard to see” from the outside. ( Basically everything *except* password. And if you want to support logging password, do that with some additional/odd/weird config setting that requires TRACE and that extra setting. Let’s call that “bad_user_wants_to_log_passwords = true”. :) ) I believe that when code “makes a decision” it needs to “vocalize it before it does it” and “confirm that it did it”. ( in DEBUG ) In this case if I had seen a log like the following prior to the attempt to change the AD group then it would have been obvious what was going on: DEBUG: ‘obectclass’ attribute found to have an extra value ‘top’. That value will be removed from AD. Also, if I could have had it dump the “ldap read details” and the ldap modify details” I might have been able to “do the diff myself” from only the logs. However, that approach does not communicate the “decision” that the code was making. So I prefer the former approach.
Having “PSPNG could notice incomplete [configuration]” is not a horrible idea. But ( IMHO ) you will always be chasing that problem. It is more of a “guessing game” and might be complicated by the variety of environments and future configuration complications too. (Like trying to guess how a JXEL script would evaluate in the context of a group/user without having the group/user/connected system available. ) The logging approach is more of a communication of intent/action and is much more concreate and limited in scope to what the code does or does not do. ( There is not “try”. :) ) Leaving the deployer(configurator) to “do the right thing” for what they want the system to do. And giving them feedback about how the system is responding to what they “told it to do”.
-- Carey Matthew
From: Bee-Lindgren, Bert <>
Carey,
Thanks for all these details and the work behind them!
I did change PSPNG's full-sync processing to update (non-membership) attributes and that is what is attempting this objectclass change.
I've thought a bit about how to address this... I think that special handling of objectclass or objectclass=top could get in the way later. Therefore, I think putting the values into the configuration like you did is the best approach, and I've updated the example with this.
But how to avoid needing so much diagnosis next time?... Perhaps PSPNG could notice incomplete LdifCreationTemplates by reading just-created objects and failing (or at least logging) if the new objects don't match the template? What do you think?
Thanks again, Bert
From:
<> on behalf of Black, Carey M. <>
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.