Ranger SSL connection to active directory - trying to fix PKIX path building failed error

[#1]

Hi all! I am HOPING this is a simple question. So, I initially got our ranger-to-active-directory user sync working. (Standard LDAP url, port 389). And now per our corporate IT guys, I need to move this to an SSL connection. OK, I'm game...! I initially tested the LDAPS connection using the 'ldaptool' that's included with ranger for testing things. Quickly uncovered that I needed a certificate from the AD guys. Got it, and I easily got it installed into the system standard location for such things, the java "cacerts" keystore. (/usr/java/latest/jre/lib/security/cacerts). And... voila, the ldaptool worked. Woo! almost there. So, in the ranger config, I changed the ldap url from LDAP://companyADSERVER.org:389 to LDAPS://companyADSERVER.org:636. This should work, because I already have the specific certificate already imported into the standard cacerts location on the server that hosts my ranger goodies. Nope. I'm getting the following:

Caused by: javax.naming.CommunicationException: simple bind failed: mcwdc1.mcwcorp.net: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] at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)

Whish is of course, java's way of telling me that it can't find the certificate in whatever keystore it's using.

So, I did some digging, and found this!

<property> <name>ranger.usersync.truststore.file</name> <value>/usr/hdp/current/ranger-usersync/conf/mytruststore.jks</value> </property>

...and so I then took the certificate, and added it into THAT keystore. But, I am still getting the exact same error. I am pretty sure I'm THIS -> <- close. Any help would be much appreciated!

[#2 · Accepted solution]

@Kent Brodi

Please double check that java which ranger admin and usersync is using the one you added the certificate into (/usr/java/latest/jre/lib/security/cacerts).

Also please refer this doc https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.6/bk_Security_Guide/content/configure_ambari_...

[#3]

This is the most correct answer..! I *thought* I was using one java, but discovered ranger was using another java that ambari itself installed in a totally different location. I added a ton of commentary below however for others to benefit from.

[#4]

can you please try generating certificate from ranger usersync keystore and importing it into the AD truststore.

[#5]

OK, I finally figured this out. The problem apparently is not so much ranger itself, it's how the horton ambari fires off processes on the nodes via ITS OWN JAVA in most or many cases..

When investigating, I had assumed all along that I had one java jdk on the servers. Apparently I did not notice that in choosing jdk 1.8 in the ambari setup, it downloads an installs ITS OWN jdk and stuffs it deep under /usr/lib64. I assumed incorrectly I was picking the option of "what java I am already using"...

Here's the java I installed, and is what is set up to be the default java via /etc/alternatives:

/usr/java/jdk1.8.0_65/jre/bin/java /usr/java/jdk1.8.0_65/bin/java

But here is the java that ambari installed, and uses:

/usr/jdk64/jdk1.8.0_60/jre/bin/java /usr/jdk64/jdk1.8.0_60/bin/java

which explains why (at the command level), my ldap ssl tests were working fine-- it found and used the proper cacerts I had stufed the certificate into, using the system-default jdk, and worked. But... ranger did not. Because ranger uses the java that ambari has, and NOT the system default. This is what took me a while to figure out.

(all of this confusion could have been avoided if, when installing ambarti, I picked a "custom" JDK.... In that case each system would have and use only ONE java, period).

Adding to my issue is that the ranger usersync and ranger admin both use different bits; and I *think* my usersync was probably working (because I had added the cert into the ranger-specific truststore....), but I could not log into the ranger admin console because well... that does NOT use the ranger-specific truststore, and defaults of course to the AMBARI-INSTALLED-JAVA version of cacerts, and not the cacerts I *thought* it was using. (the ranger admin truststore issue is resolved by editing /usr/hdp/current/ranger-admin/ews/ranger-admin-services.sh and adding:

-Djavax.net.ssl.trustStore=<path to preferred cacerts location> as a java option )

I think my only complaint I have in this whole deal, is that in the ranger config screens, while there's a truststore option listed for the usersync part, there's NOT a truststore config option listed for the ranger ADMIN part, as they are different things.