Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Re: provisioning groups to AD, but no members?

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Re: provisioning groups to AD, but no members?


Chronological Thread 
  • From: David Langenberg <>
  • To: Rob Gorrell <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] Re: provisioning groups to AD, but no members?
  • Date: Fri, 13 Dec 2013 13:33:11 -0700




On Fri, Dec 13, 2013 at 1:02 PM, Rob Gorrell <> wrote:
looking at this a little more, I'm feeling like what is happening is when the psp goes to add my user as a member of the provisioned group in AD, its looking up my DN using another source, and because of that, failing to locate a DN relevant to the target AD which I'm provisioning against. So in another words, if I add 'rwgorrel' to be a member of uncg:test using the UI, my default subject picker is used (a source called uncg-person). However, I'm provisioning to a target called 'authad'. so when the PSP goes to write out the membership of uncg:test, my user, rwgorrel is being looked up in the original uncg-person source, instead of the authad source as it would need to be. rwgorrel is contained in both locations, but directory structure, objectclasses, etc differ, so ultimately, psp doesn't find a poper DN to build the membership in my target (authad). I sorta see why this would be the case, but certainly you're not limited to only provisioning to the source where members were originally found. how to tell the psp not to lookup me against the source which first added me, but do a fresh lookup against the target source i'm trying to provision against?

Right, and here is where psp-resolver and creating multiple attribute lookup definitions come into play.   Take a peek at how psp-example-grouper-to-openldap-multiple example config handles the lookup and resolution of the user DNs across the differing LDAP servers.

Dave


 

does that train of though make any sense?


below's my uidNumber=33521 that identifys me (rwgorrel), but the DN and filter are all wrong for the target I'm provisioning too (authad). these settings instead match the subject source where I was intially looked up against when added to the grouper group (uncg-person)...

2013-12-13 13:06:43,143: [main] DEBUG AbstractLdap.search(193) -  - Search with the following parameters:
2013-12-13 13:06:43,143: [main] DEBUG AbstractLdap.search(194) -  -   dn = ou=accounts,o=uncg
2013-12-13 13:06:43,143: [main] DEBUG AbstractLdap.search(195) -  -   filter = (& (uidNumber=33521) (objectclass=userProxy))
2013-12-13 13:06:43,143: [main] DEBUG AbstractLdap.search(196) -  -   filterArgs = []
2013-12-13 13:06:43,144: [main] DEBUG AbstractLdap.search(197) -  -   searchControls = javax.naming.directory.SearchControls@33e2e8cc
2013-12-13 13:06:43,144: [main] DEBUG AbstractLdap.search(198) -  -   handler = [edu.vt.middleware.ldap.handler.FqdnSearchResultHandler@618787c9]
2013-12-13 13:06:43,144: [main] WARN  AbstractLdap.operationRetry(1105) -  - Error performing LDAP operation, retrying (attempt 0)
javax.naming.CommunicationException: Connection reset [Root exception is java.net.SocketException: Connection reset]; remaining name 'ou=accounts,o=uncg'




On Fri, Dec 13, 2013 at 1:29 PM, Rob Gorrell <> wrote:
So I've been working on understanding the PSP for some time now. I've finally resolved my problems in getting grouper groups to provision to my active directory using PSP, but now even though the group objects are being created, the memberships aren't being written. I'm using the flat structure with cnSourceAttributeID=name. the only real change I've made to psp.xml from the example is to comment out the sAMAccountName stuff and let AD choose that (was having length and semicolon problems with this attribute)

trying to provision a simple group of uncg:test with rwgorrel (cn=rwgorrel,ou=accounts,o=uncg) produces an AD group of cn=uncg:test,ou=devgroups,o=uncg but its membership is empty.

After running a 'bin/gsh.sh -psp -sync uncg:test' grouper doesn't seem to contact a source to look up the DN for my member object (rwgorrel). This section of log has caught my attention, though I'm not 100% sure what to make of it. Does something need to be changed in my psp.xml to match up with AD's name for member and memberOf attributes?

2013-12-13 13:21:07,300: [main] DEBUG PsoReferences.getReferences(148) -  - Pso references 'member' - Get references for 'uncg:test'
2013-12-13 13:21:07,300: [main] DEBUG PsoReference.getReferences(90) -  - Pso reference 'membersLdap' - Get references for 'uncg:test'
2013-12-13 13:21:07,300: [main] DEBUG PsoReference.getReferences(97) -  - Pso reference 'membersLdap' - Source attribute does not exist
2013-12-13 13:21:07,300: [main] DEBUG PsoReference.getReferences(90) -  - Pso reference 'membersGsa' - Get references for 'uncg:test'
2013-12-13 13:21:07,300: [main] DEBUG PsoReference.getReferences(97) -  - Pso reference 'membersGsa' - Source attribute does not exist
2013-12-13 13:21:07,300: [main] DEBUG PsoReferences.getReferences(160) -  - Pso references 'member' - Returned 0 references.
2013-12-13 13:21:07,301: [main] DEBUG PsoIdentifier.getPSOIdentifier(86) -  - PSO Identifier Definition 'groupDn' - Source attribute 'groupDnAlternate' does not exist
2013-12-13 13:21:07,301: [main] DEBUG PsoIdentifier.getPSOIdentifier(86) -  - PSO Identifier Definition 'groupDn' - Source attribute 'groupDnAlternateChangeLog' does not exist
2013-12-13 13:21:07,302: [main] DEBUG Pso.getPSO(282) -  - Pso 'group' - Get pso for 'uncg:test' returned 1 objects.
2013-12-13 13:21:07,302: [main] DEBUG Pso.getPSO(222) -  - Pso 'member' - Get pso for 'uncg:test'
2013-12-13 13:21:07,302: [main] DEBUG PsoIdentifier.getPSOIdentifier(86) -  - PSO Identifier Definition 'memberDn' - Source attribute 'memberDn' does not exist
2013-12-13 13:21:07,302: [main] DEBUG Pso.getPSO(229) -  - Pso 'member' - Unable to calculate pso identifier for 'uncg:test'
2013-12-13 13:21:07,302: [main] DEBUG Pso.getPSO(222) -  - Pso 'groupMembership' - Get pso for 'uncg:test'

Thanks
-Rob

--
Robert W. Gorrell
Systems Architect, Identity and Access Management
University of NC at Greensboro
336-334-5954
PGP Key ID B36DB0CA



--
Robert W. Gorrell
Systems Architect, Identity and Access Management
University of NC at Greensboro
336-334-5954
PGP Key ID B36DB0CA



--
David Langenberg
Identity & Access Management
The University of Chicago



Archive powered by MHonArc 2.6.16.

Top of Page