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: Tom Zeller <>
  • To: Gagné Sébastien <>
  • Cc:
  • Subject: Re: [grouper-users] LDAPPCNG configuration with Active Directory
  • Date: Fri, 20 Jan 2012 18:29:24 -0600

The bug, calling a method of an undefined or null variable, is in my
attribute resolver script definition. Could you create an issue in
jira, please ?

If you ran ldappcng as

$GROUPER_HOME/bin/ -ldappcng -sync UdeM:SubStem -entityName stem

instead of

$GROUPER_HOME/bin/ -ldappcng -sync UdeM:SubStem

then the bug should not appear because the sAMAccountName attribute
would not be resolved by the shibboleth attribute resolver, since only
stem attributes will be resolved.

When provisioning an unknown object (an unknown spmlv2 schema entity;
"-entityName stem" is not present in the gsh parameters) ldappcng
resolves all attributes, because in my experience, performance
bottlenecks are typically in the I/O to data sources (grouper) or
provisioning targets (active directory).

Some relevant code from (2.1.0) is in the
execute(CalcRequest, CalcResponse) method :

// attribute request context
BaseSAMLProfileRequestContext attributeRequestContext = new

// get targets specified in request before building the context
Map<String, List<Pso>> map = getTargetAndObjectDefinitions(calcRequest);

// determine attribute resolver requested attributes
LinkedHashSet<String> attributeIds = new LinkedHashSet<String>();
for (String targetId : map.keySet()) {
for (Pso psoDefinition : map.get(targetId)) {


// resolve attributes
LOG.debug("PSP '{}' - Calc {} Resolving attributes '{}'.",
new Object[] {getId(), calcRequest, attributeIds});
Map<String, BaseAttribute<?>> attributes =

For anyone interested.


Archive powered by MHonArc 2.6.16.

Top of Page