IdP for Username/Password Authentication LDAPS (with AD) issues

Youssef GHORBAL youssef.ghorbal at pasteur.fr
Wed Mar 23 05:28:59 EDT 2016


> On 22 Mar 2016, at 23:22, Kevin Foote <kpfoote at uoregon.edu> wrote:
> 
> 
>> On Mar 22, 2016, at 12:39 PM, Youssef GHORBAL <youssef.ghorbal at pasteur.fr> wrote:
>> 
>> 	I want to do Username/Password Authentication using LDAPS (against an AD) with an IdP 2.4
> 
> First, you should be using IdP 3 for installs these days… 2.4 is EOL pretty soon.

Who talked about a *new* installation here.
It’s a 3 yrear running instance, that we are moving from an OpenLDAP to AD backend. The OpenLDAP had a certificate signed by a public CA. The AD not.

>> #> c_rehash /opt/active_directory_ca/
>> #> openssl s_client -CApath /opt/active_directory_ca/ -connect tom.corp.pasteur.fr:636
>> 
>> 	What am I missing ? In the idp-process.log, I can’t seem to find any clue whether the CA file (sslSocketFactory) is taken into account or ignored for some other obscure reason.
>> 	How can I push investigations deeper (I currently @ DEBUG level)
>> 
>> 	Any help would be appreciated.
> 
> Now since you are for some reason installing IdP 2.4...
> Java does not use openssl .. you need to add the AD CA into your java key-store using keytool.

Of course it does’nt. I posted the openssl example to illustrate that I’m actually using the good CA file.

> ${JAVA_HOME/jre/lib/security/cacerts I believe. 

The documentation says that you can do either way :

1 - add the CA to the keystore with the keytool
2 - use the sslSocketFactory to point to the exact PEM file you need to validate the certificate chain. That’s what I’m trying to do.

=> I may be misunderstanding the documentation here, maybe you have to do both, but it’s unlikely.

By the way the same mecanisme is used in attribute resolution :
https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverLDAPDataConnector

"To enable LDAP with StartTLS add the attribute useStartTLS="true" to the data connector definition. If your LDAP server's digital certificate is not trusted by the JVM and you do not wish, or are unable, to add the CA that signed your LDAP server's digital certificate to your keystore, you may provide the LDAP server's certificate itself within this connector's configuration or provide the certificate of the CA that generated and signed the server certificate.  This is an X.509 credential defined in the same manner as all other X.509 security credentials.  To trust the server or CA X.509 certificate, use the <StartTLSTrustCredential> to point to the trusted certificate in line in the data connector or in a file you point to containing the certificate.  The login module in login.config can point to the same file (assuming you use the same LDAP directory for user authentication and to retrieve attributes) eliminating the need to import and maintain multiple copies of the certificate.”

Youssef


More information about the users mailing list