Grouper Users - Open Discussion List

["Bryan E. Wooten" <>]

 

 

From: Bryan E. Wooten
Sent: Thursday, March 14, 2013 8:09 AM
To: 'Gagné Sébastien'
Subject: RE: [grouper-users] AD / LDAP Provisioning with PSP - One last hurdle?

 

Yeah, I set the standard peopleBaseDn to the AD DN. I expected LDAP to fail and AD to work. What happened is the PSP made no attempt to provision LDAP but the attempt to provision AD continued to us the standard DN. The peopleBaseDn is on set in either ldap.properties or ad.properties and only referenced in psp.xml.

 

I am going to retry all my tests, I may have missed something.

 

Cheers,

 

Bryan

 

From: Gagné Sébastien []
Sent: Thursday, March 14, 2013 8:02 AM
To: Bryan E. Wooten
Subject: RE: [grouper-users] AD / LDAP Provisioning with PSP - One last hurdle?

 

So this configuration (psp.ad.peopleBaseDn) was working with only AD ?

 

What if you set the standard peopleBaseDn to the AD DN without changing anything else ? do you get the right DN then ?

 

I’m afraid that maybe somewhere there’s an hardcoded reference to the standard parameter (or one forgotten one in you configuration)

 

 

De : Bryan E. Wooten []
Envoyé : 14 mars 2013 09:51
À : Gagné Sébastien
Cc :
Objet : RE: [grouper-users] AD / LDAP Provisioning with PSP - One last hurdle?

 

Yes, I believe it is correct. I have this in both my ad.properties and ldap.properties:

 

Ad.properties:

 

# The base DN for people.

edu.internet2.middleware.psp.peopleBaseDn=ou=people,dc=testad,dc=utah,dc=edu

edu.internet2.middleware.psp.ad.peopleBaseDn=ou=people,dc=testad,dc=utah,dc=edu

 

ldap.properties:

 

# The base DN for people.

edu.internet2.middleware.psp.peopleBaseDn=ou=people,o=utah.edu

edu.internet2.middleware.psp.ad.peopleBaseDn=ou=people,dc=testad,dc=utah,dc=edu

 

I started by getting everything to work with just ldap. Then I add both ad and ldap to the subject source for the UI. I then reconfigured so that the PSP would work against just AD. After that I used the the psp-example-grouper-openldap-multiple as a template to combine both ldap and AD into the psp.

 

Everything seems to work except provisioning subjects to AD groups.

 

After watching yesterday’s IAM Online I beginning to think we may be starting off with a too complicated initial plan.

 

-Bryan

 

 

From: Gagné Sébastien []
Sent: Thursday, March 14, 2013 7:28 AM
To: Bryan E. Wooten
Subject: RE: [grouper-users] AD / LDAP Provisioning with PSP - One last hurdle?

 

I assume you checked that you used the right ad.peopleBaseDn in your psp configuration. Other than that it confusing. AbstractLdap seems to be a vt-ldap class, so maybe there’s a problem in which files vt-ldap uses for properties ?

 

I had a question about your setup : did you try to make it work using only one subject source for both LDAP and AD ? Assuming both directories have the same users, do you think it would be possible or will we have to always select the subject source ?

 

De : [] De la part de Bryan E. Wooten
Envoyé : 13 mars 2013 16:50
À :
Objet : [grouper-users] AD / LDAP Provisioning with PSP - One last hurdle?

 

All,

 

Below is link showing my Grouper configuration. The goal of the exercise was to create folders, groups and add members to a group using the UI.

Then use gsh to provision these items into both an LDAP and Active Directory using the PSP:

(gsh 2% loaderRunOneJob("CHANGE_LOG_changeLogTempToChangeLog")

loader ran successfully: Ran the changeLogTempToChangeLog daemon

gsh 3% loaderRunOneJob("CHANGE_LOG_consumer_psp")

 

https://www.lucidchart.com/publicSegments/view/5140e0fd-c828-43f4-a5d8-19b90a005178

 

Everything works except adding members. Adding members works partially.

 

Using the UI I can select a subject from LDAP data source and add to a group. When I run loaderRunOneJob this subject is correctly provisioned to LDAP. From the grouper_error.log it appears that no attempt is made to provision the subject to AD.

 

Using the UI if I select a subject from AD data source and add to a group running the PSP does not provision the user into either LDAP or AD.

 

I have found the error.

 

2013-03-13 11:35:24,687: [main] DEBUG Psp.execute(1069) -  - PSP 'psp' - Calc CalcRequest[id=u0000401,requestID=<null>,returnData=identifier,schemaEntityRef=SchemaEntityRef[targetID=ldap,entityName=member,isContainer=false]] Resolving attributes '[memberDn]'.

2013-03-13 11:35:24,687: [main] DEBUG SimpleAttributeAuthority.getAttributes(86) -  - get attributes 'u0000401' aa 'psp.AttributeAuthority'

2013-03-13 11:35:24,688: [main] DEBUG AbstractLdap.search(193) -  - Search with the following parameters:

2013-03-13 11:35:24,689: [main] DEBUG AbstractLdap.search(194) -  -   dn = ou=people,o=utah.edu

2013-03-13 11:35:24,689: [main] DEBUG AbstractLdap.search(195) -  -   filter = (& (unid=u0000401) (objectclass=inetOrgPerson))

2013-03-13 11:35:24,689: [main] DEBUG AbstractLdap.search(196) -  -   filterArgs = []

2013-03-13 11:35:24,690: [main] DEBUG AbstractLdap.search(197) -  -   searchControls =

2013-03-13 11:35:24,690: [main] DEBUG AbstractLdap.search(198) -  -   handler = [edu.internet2.middleware.psp.ldap.QuotedDnResultHandler@7c30cd64, ]

 

For some reason the dn is from the peopleBaseDn for LDAP and not the peopleBaseDn I configured for AD.

 

As an experiment I set peopleBaseDn for both ldap and ad to be the value used by AD. This did change the results.

 

Any thoughts?

 

Thanks,

 

Bryan