Grouper Users - Open Discussion List

[Tom Zeller <>]

>> Hi,
>>
>> My ldappcng.xml file contains
>>
>> <object id="stem">
>>       <identifier ref="stem-dn" baseId="${groupsOU}">
>>         <identifyingAttribute name="objectclass" 
>> value="organizationalUnit" />
>>       </identifier>
>>       <attribute name="objectClass" ref="stem-objectclass" />
>>       <attribute name="ou" ref="stem-ou" />
>>       <attribute name="description" ref="stem-description" />
>> </object>
>>
>> I want to provision the stem A:B:C:D into LDAP with DN
>>
>> ou=D,ou=C,ou=B,ou=A,ou=grouper,dc=ligo,dc=org
>>
>> Note that the DN
>>
>> ou=C,ou=B,ou=A,ou=grouper,dc=ligo,dc=org
>>
>> already exists in LDAP.
>>
>> When I run
>>
>> gsh.sh -ldappcng -calc A:B:C:D
>>
>> it shows me
>>
>> <ldappc:calcResponse
>> xmlns:ldappc='http://grouper.internet2.edu/ldappc'
>> status='success' requestID='2011/04/05-14:27:46.415_QWFMLUAJ'>
>>   <ldappc:id ID='A:B:C:D'/>
>>   <ldappc:pso entityName='stem'>
>>     <psoID
>> ID='ou=A:B:C:D,ou=C,ou=B,ou=A,ou=grouper,dc=ligo,dc=org'
>> targetID='ldap'/>
>>     <data>
>>       <dsml:attr xmlns:dsml='urn:oasis:names:tc:DSML:2:0:core'
>> name='objectClass'>
>>         <dsml:value>top</dsml:value>
>>         <dsml:value>organizationalUnit</dsml:value>
>>       </dsml:attr>
>>       <dsml:attr xmlns:dsml='urn:oasis:names:tc:DSML:2:0:core'
>> name='ou'>
>>         <dsml:value>A</dsml:value>
>>       </dsml:attr>
>>     </data>
>>   </ldappc:pso>
>> </ldappc:calcResponse>
>>
>> and if I use -sync instead of -calc the provisioned DN is
>>
>> ou=A:B:C:D,ou=C,ou=B,ou=A,ou=grouper,dc=ligo,dc=org
>>
>> instead of what I want.
>>
>> How can I adjust the stem provisioning configuration in
>> ldappcng.xml so that I get the DN
>>
>> ou=D,ou=C,ou=B,ou=A,ou=grouper,dc=ligo,dc=org
>>
>> Note that in ldappc.properties I do have
>>
>> ldappc.properties:DNstructure=bushy
>>
>
> Apologies for answering my own question minutes
> later...(though a confirmation from Tom Z would be
> appreciated!).
>
> In ldappc-resolver.xml I changed
>
> <resolver:AttributeDefinition id="stem-dn"
> xsi:type="ldappc:LdapDnPSOIdentifier"
>    structure="${DNstructure}" sourceAttributeID="name"
> rdnAttributeName="ou" base="${groupsOU}">
>    <resolver:Dependency ref="StemDataConnector" />
>  </resolver:AttributeDefinition>
>
> to instead read
>
> <resolver:AttributeDefinition id="stem-dn"
> xsi:type="ldappc:LdapDnPSOIdentifier"
>    structure="${DNstructure}" sourceAttributeID="extension"
> rdnAttributeName="ou" base="${groupsOU}">
>    <resolver:Dependency ref="StemDataConnector" />
>  </resolver:AttributeDefinition>
>
> That is, I changed sourceAttributeID from 'name' to
> 'extension'.
>
> This appears to give me the provisioning I needed.

The <resolver:AttributeDefinition
xsi:type="ldappc:LdapDnPSOIdentifier"> returns a DN whose RDN
AttributeType (e.g. cn in cn=foo) is specified by rdnAttributeName,
and whose AttributeValue (e.g. foo in cn=foo) is the value of the
sourceAttributeID attribute.

If sourceAttributeID=name, then the RDN will be of the form
cn=parentStem:childStem regardless of whether the structure is flat or
bushy.

If the structure is bushy, then the DN will comprise a hierarchy based
on the parent stem of the object (group or stem) - which results in
the somewhat odd behavior you describe when sourceAttributeID=name.

Hope this helps.

TomZ