Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Re: dealing with grouper, certificates, and connecting to sldap

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Re: dealing with grouper, certificates, and connecting to sldap


Chronological Thread 
  • From: Rob Gorrell <>
  • To: Gagné Sébastien <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] Re: dealing with grouper, certificates, and connecting to sldap
  • Date: Thu, 19 Sep 2013 09:56:10 -0400

Thanks, after several successful connections using the openldap-clients tools, I was going back to cut and paste my ldap.properties for you and happened to notice a simple typo in the binddn i had in the file. so easy to overlook this stuff when you spend all day burried in these configs, I guess sometime a little motivation is needed to go back over everything. Thanks again,

-Rob


On Wed, Sep 18, 2013 at 3:47 PM, Gagné Sébastien <> wrote:

It might be easier to spot the problem if you can provide a sanitized ldap.properties, especially the “edu.vt.middleware.ldap.” parameters

 

Have you tried connecting in non-ssl ?  Do you have a firewall blocking the connection ?

 

As you saw, the error simply says that it couldn’t connect to LDAP, it might be a bad URL or a SSL problem, do you have anything else in grouper’s logs ?

 

 

De : [mailto:] De la part de Rob Gorrell
Envoyé : 18 septembre 2013 15:15
À :
Objet : Re: [grouper-users] Re: dealing with grouper, certificates, and connecting to sldap

 

So not to rehash an old issue, but I'm once more stuck in ssl ldap connection problems... though not exactly the same as before. I've added a new source to my sources.xml that I need for the PSP to provision against. Its an Active Directory domain and a different source than I've used for anything in the past. What I'm getting when I just attempt to start up gsh and load the new sources.xml with the additional source in it is:

sources.xml jdbc source id:   jdbc: GrouperJdbcConnectionProvider
Subject API error: error with subject source id: authad, name: UNCG Auth Domain, problem with getSubject by id, in sources.xml: search searchSubject: , edu.internet2.middleware.subject.SourceUnavailableException: Ldap Exception: Pool is empty and object creation failed

this is different from before, but I think i read that "Ldap Exception: Pool is empty and object creation failed" has some dealings with ssl issues. has anyone encountered this sort of ldap error before? I have no problem connecting to the same source through an independent ldap client. the certificate used by this ldap server is in java's cacert bundle.

Thanks,

-Rob

 

On Mon, Jul 22, 2013 at 11:56 AM, Rob Gorrell <> wrote:

Bingo... that looks to be it. My loader job still didn't run, but looks like I'm pasted connectivity issues.
I changed ldap.tls = false and left the URL ldaps://

Thanks!
-Rob



On Mon, Jul 22, 2013 at 11:43 AM, David Langenberg <> wrote:

If it is doing tls=true, then you need to be using port 389.  Try setting ldap.tls=false and ldap.ssl=true.

 

Dave

 

On Mon, Jul 22, 2013 at 9:40 AM, Rob Gorrell <> wrote:

So, yes, my URL does include ldaps:// as directed by the comments in grouper-loader.properties:

#note the URL should start with ldap: or ldaps: if it is SSL.
#It should contain the server and port (optional if not default), and baseDn,
#e.g. ldaps://ldapserver.school.edu:636/dc=school,dc=edu
ldap.campusLdap.url = "ldaps://prddc02.campus.uncg.edu:636/dc=campus,dc=uncg,dc=edu

how do i know if grouper is using edu.vt.middleware.ldap.tls=true somewhere else? should I change the url back to ldap:// but leave port 636 assuming grouper is doing edu.vt.middleware.ldap.tls=true somewhere else despite what the comment says?

-Rob



On Mon, Jul 22, 2013 at 11:19 AM, David Langenberg <> wrote:

From the looks of that error, it seems your problem isn't with the TLS part, but rather something like you're telling it to use STARTTLS while speaking to AD over SSL.  In other words, ensure if your ldapUrl is ldaps://  that later on you're not setting 

 

edu.vt.middleware.ldap.tls=true.

 

Dave

 

On Mon, Jul 22, 2013 at 9:02 AM, Rob Gorrell <> wrote:

i'm still not able to get the SSL ldap connection working through grouper loader. I've got both the domain's CA and the ldap server's authentication certificate (consequently signed by the domain CA) in Java's keystore (/etc/pki/java/cacerts).

since this is new ground for me, i wanted to make sure the certs and the keystore was working properly, so I borrowed a sample java program from oracle that connects to ldap over ssl thus requiring use of the same keystore. Running the program on the grouper server, it works. To prove my point, I backed the two certificates out of the keystore I had added and ran again, this time I received the expected "unable to find valid certification path to requested target" error (same java error grouper gives me on the original java keystore). so my confidence i have the keystore setup correctly with the appropriate certs is there.

but when I put back in place the keystore with my added certs, the one that works on the same java ssl program, grouper is still returning:
[main] ERROR DefaultLdapFactory.create(109) -  - unabled to connect to the ldap
javax.naming.NamingException: [LDAP: error code 1 - 00000000: LdapErr: DSID-0C090DE6, comment: TLS or SSL already in effect, data 0, v1772]; remaining name ''

any suggestions? is there anyone out there using grouper to connect over SSL to an Active Directory LDAP source thats had to deal with this before? what does "TLS or SSL already in effect" possibly mean?

-Rob

--

Robert W. Gorrell
Middleware Engineer, Identity and Access Management

University of NC at Greensboro
336-334-5954



 

--
David Langenberg

Identity & Access Management

The University of Chicago




--

Robert W. Gorrell
Middleware Engineer, Identity and Access Management

University of NC at Greensboro
336-334-5954



 

--
David Langenberg

Identity & Access Management

The University of Chicago




--

Robert W. Gorrell
Middleware Engineer, Identity and Access Management

University of NC at Greensboro
336-334-5954




--

Robert W. Gorrell
Middleware Engineer, Identity and Access Management

University of NC at Greensboro
336-334-5954




--
Robert W. Gorrell
Middleware Engineer, Identity and Access Management
University of NC at Greensboro
336-334-5954



Archive powered by MHonArc 2.6.16.

Top of Page