Skip to Content.
Sympa Menu

grouper-dev - [grouper-dev] Re: PSP - existing memberships not matched

Subject: Grouper Developers Forum

List archive

[grouper-dev] Re: PSP - existing memberships not matched


Chronological Thread 
  • From: Tom Zeller <>
  • To: Gagné Sébastien <>
  • Cc: "" <>
  • Subject: [grouper-dev] Re: PSP - existing memberships not matched
  • Date: Wed, 22 Feb 2012 17:33:52 -0600
  • Authentication-results: mr.google.com; spf=pass (google.com: domain of designates 10.180.101.200 as permitted sender) ; dkim=pass

My first thought is that the LdapSourceAdapter does not canonicalize
ldap DNs (which is probably the correct behavior) while the psp does,
so that case sensitive matching does not match as we want it to.

I probably should support case insensitive matching of identifiers,
and maybe of attribute values.

However, what we may want to allow pluggable identifier comparison,
including ldap DN canonicalization as well as case [in]sensitivity.

Hmm...

TomZ

2012/2/22 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'>



Archive powered by MHonArc 2.6.16.

Top of Page