Active Directory ldaps authentication

Tue Sep 1 21:45:23 EDT 2015

Hi Scott & Micheal,

First thank you for your help and input it pointed me in the right direction.  The problem I was having was cert based.  My AD cert didn’t have the proper info in the Subject or Subject Alternative Name fields.  Which brings me to my current problem

I have created a new cert on my AD server with the DNS name as the subject (shows up as CN=ADServer1.addomain.fdu.edu<http://ADServer1.addomain.fdu.edu>) and the Subject Alternative Name is the DNS and SPN names.  I have multiple DCs configured in a round robin DNS.  What seems to be happening is when the cert is being verified JAAS tries to validate the hostname against all of the servers in the SAN (including each member of the round robin up to the first 3 responses) and then fails even though it finds a match.

2015-09-01 20:51:45.613 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:127] - Verify with the following parameters:
2015-09-01 20:51:45.613 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:128] -   hostname = ADServer1.addomain.fdu.edu<http://ADServer1.addomain.fdu.edu>
2015-09-01 20:51:45.614 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:129] -   cert = CN=ADServer1.addomain.fdu.edu<http://ADServer1.addomain.fdu.edu>
2015-09-01 20:51:45.614 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:202] - verifyDNS using subjectAltNames = [ADDOMAIN, addomain.fdu.edu<http://addomain.fdu.edu>, ADServer1.addomain.fdu.edu<http://ADServer1.addomain.fdu.edu>]
2015-09-01 20:51:45.615 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:210] - verifyDNS found hostname match: ADServer1.addomain.fdu.edu<http://ADServer1.addomain.fdu.edu>
2015-09-01 20:51:45.854 - DEBUG [edu.vt.middleware.ldap.ssl.AggregateTrustManager:75] - invoking checkServerTrusted for sun.security.ssl.X509TrustManagerImpl at 14ef752
2015-09-01 20:51:45.855 - DEBUG [edu.vt.middleware.ldap.ssl.AggregateTrustManager:75] - invoking checkServerTrusted for edu.vt.middleware.ldap.ssl.HostnameVerifyingTrustManager at f8f387

2015-09-01 20:51:46.457 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:127] - Verify with the following parameters:
2015-09-01 20:51:46.457 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:128] -   hostname = ADServer1.addomain.fdu.edu<http://ADServer1.addomain.fdu.edu>
2015-09-01 20:51:46.457 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:129] -   cert = CN=ADServer2.addomain.fdu.edu<http://ADServer2.addomain.fdu.edu>
2015-09-01 20:51:46.458 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:202] - verifyDNS using subjectAltNames = [ADDOMAIN, addomain.fdu.edu<http://addomain.fdu.edu>, ADServer6.addomain.fdu.edu<http://ADServer6.addomain.fdu.edu>]
2015-09-01 20:51:46.681 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:164] - Error occured attempting authentication
javax.naming.PartialResultException: null

Caused by: javax.naming.CommunicationException: simple bind failed: DomainDnsZones.addomain.fdu.edu<http://DomainDnsZones.addomain.fdu.edu>:636

Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Hostname '[ADServer1.addomain.fdu.edu<http://ADServer1.addomain.fdu.edu>]' does not match the hostname in the server's certificate

Caused by: java.security.cert.CertificateException: Hostname '[ADServer1.addomain.fdu.edu<http://ADServer1.addomain.fdu.edu>]' does not match the hostname in the server's certificate

Not sure what my cert should look like for my environment.

Please advise,

-Chris

PS not sure where DomainDnsZones.addomain.fdu.edu<http://DomainDnsZones.addomain.fdu.edu>:636 is coming from.

On Aug 3, 2015, at 1:40 PM, Cantor, Scott <cantor.2 at osu.edu<mailto:cantor.2 at osu.edu>> wrote:

On 8/3/15, 1:37 PM, "users on behalf of Michael O Holstein" <users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net> on behalf of michael.holstein at csuohio.edu<mailto:michael.holstein at csuohio.edu>> wrote:

As I understood his question, he's not talking about the business of authenticating *peers* inside the IDP, he's getting the error from the ldaptive library because the self-signed cert that AD servers generate for their LDAPS isn't understood by the java crypto API.

Yes, that was my understanding.

I suppose you could invoke Tomcat (or Jetty) with an explicit keystore that wasn't the generic system root (meaning it'd only use it for that process) and that keystore could be the same as the IDP .. but I've never seen such a think suggested outside manually declaring a keystore just to sort our this kind of problem (eg: is it the Oracle one I'm using? or the OpenJDK one?, or the Debian one? ...)

The IdP has no requirement for relying on the Java root store in any capacity.

IMHO there is a good way around this problem .. if you have multiple AD servers you can use something like ha-proxy with a 20year self-signed cert out the front and the -ignore option out the back .. so you don't have to fuss with it every year. Of course there are other ways, but that is the cheap one.

Indeed, any server (other than web) should use a long-lived, self-signed certificate.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150902/ece71385/attachment.html>