Grouper Users - Open Discussion List

[Jeffrey Williams <>]

As a follow-up, we've configured vt-ldap for the LDAP Loader job as follows:

#JFW: vtLDAP configuration for LDAP loader jobs

ldap.campusLdap.url = "ldaps://someDC.campus.uncg.edu:636/dc=campus,dc=uncg,dc=edu

ldap.campusLdap.user = cn=grouperadm,ou=accounts,dc=campus,dc=uncg,dc=edu

ldap.campusLdap.pass = /opt/etc/grouperadm.pass.cipher

ldap.campusLdap.tls = false

The DC uses a local-CA-issued certificate for LDAPS .  When an LDAP loader job fires off, a long error starting with this is returned:

 Error connecting to LDAP URL: ldaps://someDC.campus.uncg.edu:636/dc=campus,dc=uncg,dc=edu

javax.naming.CommunicationException: simple bind failed: someDC.campus.uncg.edu:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

We're using the TIER grouper container, so I've tried:

• Adding the CA root certificate directly to the existing etc/pki/java/cacerts via keytool
• copying the previous "known-good" cacerts from our 2.2.0 server over to our 2.3.0 containers and copied it into /etc/pki/java/

In both cases, I restart the container with no change to the error.  

Is there a particular log that we can turn up to verify which jks is being used that is throwing the error?  Anyone else run into this?

-Jeff

On Wed, Jan 24, 2018 at 3:27 PM, Shilen Patel <> wrote:

The loader is actually still using vt-ldap.  We’re working on changing that soon.  But until then, if you’re using PSPNG, then you’ll be using/configuring both vt-ldap and ldaptive.

 

- Shilen

 

From: <> on behalf of Rob Gorrell <>
Date: Wednesday, January 24, 2018 at 1:54 PM
To: "" <>
Subject: [grouper-users] LDAP loader jobs can't find connection post 2.2 (vtldap) -> 2.3 (ldaptive) upgrade

 

We recently completed an upgrade to Grouper 2.3 and everything has gone quite well... we're back online with subject resolution to our ldap source, sql loading jobs, pspng conversion, etc... but one area we're currently struggling with is our all our LDAP loader jobs... which functioned normally prior to the upgrade, but now all complain:

"Cant find the ldap connection named: 'campusLdap' in the grouper-loader.properties.  Should have entry: ldap.campusLdap.url or ldap.campusLdap.configFileFromClasspath, Problem with ldap connection: campusLdap"

Prior to the upgrade, in Grouper 2.2, our grouper-loader.properties looked like this:
ldap.campusLdap.url = "ldaps://prddc02.campus.uncg.edu:636/dc=campus,dc=uncg,dc=edu
ldap.campusLdap.user = someuser
ldap.campusLdap.pass = somepass

That syntax appeared to no longer work for us in Grouper 2.3. Working with converting from the PSP to PSPNG taught us that this needed to be reconfigured to account for the switch from vtldap to ldaptive. So in Grouper 2.3, our current grouper-loader.properties now looks like this:

ldap.campusLdap.ldapUrl = ldaps://prddc02.campus.uncg.edu:636/dc=campus,dc=uncg,dc=edu
ldap.campusLdap.bindDn = somepass
ldap.campusLdap.bindCredential = someuser

 

But when we execute the job, the error message indicates it expects the old (vtldap) config of .url (not the new ldaptive syntax of .ldapUrl)... which is a bit confusing. So what is an LDAP loading source supposed to look like in grouper-loader.properties under 2.3? All the wiki documention for loader and the error message being return would seem to indicate this hasn't changed from the past... but our own experience with PSPNG and knowledge of the switch to ldaptive would seem to hint otherwise.

 

Can anyone educate me on how ldap loading sources might need to be reconfigured post upgrade from 2.2 to 2.3?

 

Thanks,

-Rob

 

--

Robert W. Gorrell
IT Manager, Identity and Access Management

University of NC at Greensboro
336-334-5954
PGP Key ID B36DB0CA

--

Jeffrey Williams, Identity Management Specialist
Identity Architecture, ITS
University of North Carolina at Greensboro
256-TECH (256-8324)