Grouper Developers Forum

[Tom Zeller <>]

Hmm, yes, open a bug please.

Identifier comparison is case sensitive. I took care to canonicalize ldap dns, maybe not enough, and missed something when refactoring.

Thanks for testing AD.

TomZ

On Wednesday, February 22, 2012, Gagné Sébastien wrote:

Hello,

I think I found the problem! Apparently PSP is case sensitive when checking group members. In my configuration I had lower case “dc” and “ou”, but when they were provisioned in the AD Group’s member, those parts were upper-cased. Further Diffs saw the upper case AD member while it saw lower case Grouper Member and found them to be different (so add the lower case and delete the upper case).

 

I fixed it by putting upper-case “DC” and “OU” in my sources.xml and in ldap.properties, but I think that the PSP shouldn’t be case sensitive when checking DNs (what if a LDAP directory puts a lowercase CN ? there’s no way to change it).

 

Should I open a JIRA about it ?

 

From the Diff below, here are the differences :

Add      vv

<spmlref:toPsoID ID='CN=test 1234,ou=People,dc=devsim,dc=umontreal,dc=ca' targetID='ldap'/>

<spmlref:toPsoID ID='CN=test 1234,OU=People,DC=devsim,DC=umontreal,DC=ca' targetID='ldap'/>

Delete ^^

 

 

De : [mailto:] De la part de Gagné Sébastien
Envoyé : 21 février 2012 15:32
À :
Cc :
Objet : [grouper-dev] PSP - existing memberships not matched

 

Another problem with PSP provisioning using Grouper 2.1 (API, UI and PSP)

 

When using bulkDiff and bulkSync, it seems the psp does not match the AD membership with the Grouper membership. If you look at the bulkDiff below, you will see that there is an add request and a delete request for the same subject ID (test 1234). If I try to sync (see below) the request will fail because it tries to add the same member a second time. Even if I add a new subject I get the same result, the only thing different is there will be a second ID in the ‘add’. Sync will still fail and the new member will NOT be provisioned (which is a big deal).

 

If I start with an empty group and add multiple members they will be provisioned to AD, but after that it will begin to fail in the same way. If I delete all the members in AD before a sync it will sync properly.

 

It might be worth mentioning that I encountered the same problem with the previous LDAPPCNG and was never able to fix it (I decided to wait for the PSP)

 

My hypothesis is that somewhere AD’s sAMAccountName or the group’s member isn’t mapped to the Subject ID  (which is mapped to sAMAccountName).

Or group’s member dn do not match the subject ID (which is sAMAccountName)

 

Anyone had this problem ?

 

Thanks

 

 

$ ../bin/gsh.sh -psp -bulkDiff

 

  <psp:diffResponse status='success' requestID='2012/02/21-15:06:23.415'>

    <modifyRequest xmlns='urn:oasis:names:tc:SPML:2:0' entityName='group' requestID='2012/02/21-15:06:23.536' returnData='everything'>

      <psoID ID='cn=Test3,ou=Stem2,ou=UdeM,ou=People,dc=devsim,dc=umontreal,dc=ca' targetID='ldap'/>

      <modification modificationMode='add'>

        <capabilityData mustUnderstand='true' capabilityURI='urn:oasis:names:tc:SPML:2:0:reference'>

          <spmlref:reference xmlns='urn:oasis:names:tc:SPML:2:0' xmlns:spmlref='urn:oasis:names:tc:SPML:2:0:reference' typeOfReference='member'>

            <spmlref:toPsoID ID='CN=test 1234,ou=People,dc=devsim,dc=umontreal,dc=ca' targetID='ldap'/>

          </spmlref:reference>

        </capabilityData>

      </modification>

      <modification modificationMode='delete'>

        <capabilityData mustUnderstand='true' capabilityURI='urn:oasis:names:tc:SPML:2:0:reference'>