Grouper Users - Open Discussion List

[Gagné Sébastien <>]

Sorry about the rejection, apparently they are blocked at the barracudas level, so I can’t do anything (short of zipping it, crypted and password protecting it before sending…)

 

In your group membership PSO I don’t think you have to change the references since this must be the LDAP attribute name of where it’s going

 

<!-- The ldap group "member" attribute. -->

    <references name="member">

 

What if you modify your “member” pso to include both LDAP and AD members, something like :

 

  <pso id="member">

 

    <!-- The ldap member DN. -->

    <identifier

      ref="memberDn"

      targetId="ldap"

      containerId="${edu.internet2.middleware.psp.peopleBaseDn}" />

 

    <!-- The AD member DN. -->

    <identifier

      ref="memberDnFromAD"

      targetId="ad"

      containerId="${edu.internet2.middleware.psp.ad.peopleBaseDn}" />

 

    <!-- Identifies member objects which exist on the target by objectclass attribute value. -->

    <identifyingAttribute

      name="objectclass"

      value="person" />

 

  </pso>

 

Then create memberDnFromAD in psp-resolver.xml ? Objectclass might be a problem though. I’m not totally sure how this pso is used, but it seems it serves as a lookup, maybe a hardcoded one like you said ?

 

De : [mailto:] De la part de Bryan E. Wooten
Envoyé : 14 mars 2013 12:40
À :
Objet : FW: [grouper-users] AD / LDAP Provisioning with PSP - One last hurdle?

 

Meant to send this directly to Sebatien, but his mail server keeps rejecting any email with xml in it.

 

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

 

I think you may be onto something.

 

I did this:

 

<!-- Do not provision grouper members, but enable lookup. -->

  <pso id="LDAPmember">

 

And this:

 

<!-- Provision a group membership triggered by the grouper change log. -->

  <pso id="groupMembership">

 

    <!-- The ldap group DN calculated from membership change log events. -->

    <identifier

      ref="changeLogMembershipGroupDn"

      targetId="ldap"

      containerId="${edu.internet2.middleware.psp.groupsBaseDn}" />

 

    <!-- The ldap group "member" attribute. -->

    <references name="LDAPmember">

 

I could not find any other references to “member” in any of the xml files.

 

The result was this:

 

2013-03-14 10:01:23,377: [main] ERROR BaseService.loadContext(188) -  - Configuration was not loaded for psp service, error creating components.  The root cause of this error was: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'member' is defined

2013-03-14 10:01:23,383: [main] ERROR GrouperLoaderType$4.runJob(596) -  - Problem with change log consumer: psp

java.lang.RuntimeException: Problem with class: class edu.internet2.middleware.psp.grouper.PspChangeLogConsumer

 

Not to jump to conclusions, but it appears the PSP is hardcoded to perform member lookups using only the pso  id=”member” since the alternate id name caused this failure.

 

Also the psp-services.xml doesn’t seem to support multiple psp.AttributeResolver  which reads an ldap.properties file.

 

-Bryan

 

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

 

The psp can be a pain to configure. Another option is that your “  <pso id="member">” is used “by default” by some part of the psp. What happens if you change it from member to LDAPmember. I expect something will fail badly, but you might see where it’s used

 

 

 

 

De : Bryan E. Wooten []
Envoyé : 14 mars 2013 10:09
À : Gagné Sébastien
Objet : 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