Grouper Users - Open Discussion List

[Gagné Sébastien <>]

The authoritative attribute seems to be working, no more delete Request in 
bulkDiff.

As for the sAMAccoutName :
I copied the CN attribute description and changed it so sAMAccountName and 
extension and commented out the previous definition (the one with the 
script). It seems to work properly and it looks like this :

  <resolver:AttributeDefinition id="sAMAccountName" xsi:type="ad:Simple" 
sourceAttributeID="extension">
    <resolver:Dependency ref="GroupDataConnector" />
  </resolver:AttributeDefinition>

Without the script I fear that we might run into problems if users/groups 
have some unallowed characters in their name, but for our purpose user 
interaction will be low (mostly automated group creation)

I tried changing definition to use sourceAttributeID="extension", but there 
was some exception while provisioning stems (javascript variable "name" 
wasn't defined, tried putting extension in the script with no luck)

There's an other thing I did which I think could help others. I modified the 
SpmlDataConnector to use sAMAccountName instead of CN (see below). This was 
creating some problems because the OIM Password Sync that would create a 
dummy user object with the same CN as the user that changed its password, so 
when a member was provisioned there could be duplicates and cause Grouper to 
raise an exception. In our case sAMAccountName is globaly unique and is our 
Subject ID.

  <resolver:DataConnector id="SpmlDataConnector" provider="ldap-provider" 
xsi:type="ldappc:SPMLDataConnector"
    scope="subTree" base="${peopleOU}" returnData="identifier">
    <resolver:Dependency ref="MemberDataConnector" />
    
<ldappc:FilterTemplate>(sAMAccountName=${id.get(0)})</ldappc:FilterTemplate>
  </resolver:DataConnector>


I look forward to the real-time provisioning, it looks like a huge step 
forward.


-----Message d'origine-----
De : 

 
[mailto:]
 De la part de Tom Zeller
Envoyé : 19 janvier 2012 11:04
À : Gagné Sébastien
Cc : 

Objet : Re: [grouper-users] LDAPPCNG configuration with Active Directory

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