Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] LDAPPCNG configuration with Active Directory

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] LDAPPCNG configuration with Active Directory

Chronological Thread 
  • From: Gagné Sébastien <>
  • To: <>
  • Subject: RE: [grouper-users] LDAPPCNG configuration with Active Directory
  • Date: Thu, 19 Jan 2012 10:02:41 -0500

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 id="cn" xsi:type="ad:Simple" sourceAttributeID="extension">

  <resolver:Dependency ref="GroupDataConnector" />



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 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




De : [mailto:] De la part de Gagné Sébastien
Envoyé : 18 janvier 2012 11:43
À :
Objet : [grouper-users] LDAPPCNG configuration with Active Directory



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.



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/ -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}" />


      <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" />






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 ?




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 ?




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


Archive powered by MHonArc 2.6.16.

Top of Page