Grouper Users - Open Discussion List

[Tom Zeller <>]

Great, looks like you were able to correct the example Active
Directory configuration to match the RDN and DN. In the next version,
2.1.0, I changed how ldap DNs are created from Grouper names, which
hopefully will be an improvement. The difference between 'name' and
'extension' can be confusing.

For issue #4, to not delete existing groups from AD, in ldappcng.xml, change

 <object id="group" authoritative="true">

to

 <object id="group" authoritative="false">

In general, ldappcng should be authoritative for the OU that Grouper
groups are provisioned to. Authoritative means 'delete anything that
is not sourced from Grouper". If authoritative="false", then ldappcng
will not delete groups which are deleted from Grouper. With real-time
provisioning in version 2.1.0, this will not be the case, and Grouper
groups will be deleted even if authoritative="false".

I hope this helps.

Just curious, what is your attribute definition (jn
ldappcng-resolver.xml) for sAMAccountName ?

TomZ

2012/1/19 Gagné Sébastien 
<>:
> Hello again,
>
> Completed #2 : I did in fact needed to add <attribute name="sAMAccountName"
> /> in the group definition of the ldappcng.xml file.
>
>
>
> I found solution for #1 and #3, it turns out that they were related. The
> error occured because the last part of the DN (cn=UdeM:TestGrouper) was
> different than the CN specified (TestGrouper)
>
>
>
> I fixed it in config file ldappc-resolver.xml. I changed the
> sourceAttributeID of the group-dn attribute definition from value “name” to
> “extension” (CN was already defined like that)
>
>
>
> <resolver:AttributeDefinition id="group-dn"
> xsi:type="ldappc:LdapDnPSOIdentifier"
>
>   structure="${DNstructure}" sourceAttributeID="extension"
> rdnAttributeName="cn" base="${groupsOU}">
>
>   <resolver:Dependency ref="GroupDataConnector" />
>
> </resolver:AttributeDefinition>
>
>
>
> <resolver:AttributeDefinition id="cn" xsi:type="ad:Simple"
> sourceAttributeID="extension">
>
>   <resolver:Dependency ref="GroupDataConnector" />
>
> </resolver:AttributeDefinition>
>
>
>
> I think (but haven’t tested yet) that I will also have to use the
> “extension” field for the “stem-dn” attribute if we are going to use more
> than one level of stems.
>
>
>
> I believe that if I had a flat dn structure I would need to change the CN’s
> source attribute to the value “name” to match the DN
>
>
>
> Maybe this could be added to the ldappc.properties file under the
> DNstructure property. Something like ${CNattribute} with value “name” or
> “extension” depending on the DNStructure (flat=name, bushy=extension). Maybe
> this could even be done in the source code.
>
>
>
>
>
> So the only problem I still have is the “one-way provisioning” in #4
>
>
>
> Thanks
>
>
>
> De : 
> 
> [mailto:]
>  De la part de Gagné Sébastien
> Envoyé : 18 janvier 2012 11:43
> À : 
> 
> Objet : [grouper-users] LDAPPCNG configuration with Active Directory
>
>
>
> Hello,
>
> I’m in the process of configuring the provisioning to an Active Directory
> but I ran in some problems. I’m using LDAPPCNG with Grouper 2.0.1. I’m not
> very familiar with the Shibboleth configuration files, so part of my
> problems may come from there. I would need your help on a few things.
>
>
>
> 1.
>
> Is there an example configuration for AD ? I used the configuration files
> found in “ldappcng-ActiveDirectory/” but it seems I still have problems with
> group provisioning.
>
>
>
> I provisioned a stem successfully and was able to do “bulkCalc” and
> “bulkDiff” operations successfully. However when I try to provision a single
> group using the following command, I get an error (Stem UofM was previously
> provisionned) :
>
>
>
> $GROUPER_HOME/bin/gsh.sh -ldappcng -sync UdeM:TestGrouper
>
> [LDAP: error code 34 - 00002081: NameErr: DSID-03050C42, problem 2003
> (BAD_ATT_SYNTAX) , data 0, best match of:
> 'cn=UdeM:TestGrouper,ou=UdeM,ou=people,dc=devsim,dc=umontreal,dc=ca'_]
>
>
>
> Maybe it has something to do with the colon (but CN can have them though),
> maybe it’s missing a required attribute in ldappcng.xml or maybe there’s a
> problem with the “member” value (but I tried it with no members in the group
> and still doesn’t work).
>
>
>
> I use the default group definition that came with the archive where group
> definition is :
>
>     <object id="group" authoritative="true">
>
>       <identifier ref="group-dn" baseId="${groupsOU}">
>
>         <identifyingAttribute name="objectClass" value="${groupObjectClass}"
> />
>
>       </identifier>
>
>       <attribute name="objectClass" ref="group-objectclass" />
>
>       <attribute name="cn" />
>
>       <attribute name="description" />
>
>       <references name="member">
>
>         <reference ref="members-jdbc" toObject="member" />
>
>         <reference ref="members-g:gsa" toObject="group" />
>
>       </references>
>
>     </object>
>
>
>
>
>
> 2.
>
> Provisionning the group’s sAMAccountName. AD seems to fill the
> sAMAccountName with a default value when it’s not specified in group
> creation.  How can I add this attribute to be provisioned ?
>
>
>
> My current understanding would be to add it as new attribute in the group in
> the “ldappcng.xml” file. Would that work ?
>
>
>
>
>
> 3.
>
> Apparently groups will be provisioned with “cn=UdeM:TestGrouper” even though
> I specified “DNstructure=bushy”. The bushy seems to be Ok since the group
> would be in OU=UdeM.
>
>
>
> We would like to use the group’s ID instead of the ID Path for the cn. I
> think this configuration would have to be done in ldappcng.xml and/or
> ldappc-resolver.xml (maybe add a “ref=” value to the “cn” attribute or
>
> maybe change “extension” to something else in the resolver
> “<resolver:AttributeDefinition id="cn" xsi:type="ad:Simple"
> sourceAttributeID="extension">” )
>
>
>
> Did anyone do this ?
>
>
>
>
>
> 4.
>
> Is it possible to do some kind of One way sync from Grouper to AD ? What
> would be interesting for us would be : have Grouper with its own set of
> groups (student classes) and have it provision them in AD without changing
> the other groups already in AD. From my first tests with “bulkDiff” I saw
> that Grouper sees the other groups in AD that it doesn’t have and produces a
> “deleteRequest” for each of them. What I’m trying to say here (I hope I’m
> making some sense here) : is it possible to set Grouper to only manage and
> provision groups that were created/delete by him and ignore groups that were
> created using other applications ?
>
>
>
>
>
> Thank you all for your time
>
>
>
>
>
>
>
> Sébastien Gagné,     | Analyste en informatique
>
> 514-343-6111 x33844  | Université de Montréal,
>
>                      | Pavillon Roger-Gaudry, local X-100-11
>
>