[ 
https://issues.apache.org/jira/browse/RANGER-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146775#comment-15146775
 ] 

rangerqa commented on RANGER-840:
---------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment
  
http://issues.apache.org/jira/secure/attachment/12787877/0001-Ranger-840-Honoring-custom-truststore-configuration-.patch
  against master revision a918de3.

    {color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

    {color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
                        Please justify why no new tests are needed for this 
patch.
                        Also please list what manual steps were performed to 
verify this patch.

    {color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

    {color:green}+1 javadoc{color}.  There were no new javadoc warning messages.

    +1 checkstyle.  The patch generated 0 code style errors.

    {color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 2.0.3) warnings.

        {color:red}-1 release audit{color}.  The applied patch generated 1 
release audit warnings.

    {color:red}-1 core tests{color}.  The test build failed in  

Test results: 
https://builds.apache.org/job/PreCommit-RANGER-Build/53//testReport/
Release audit warnings: 
https://builds.apache.org/job/PreCommit-RANGER-Build/53//artifact/patchprocess/patchReleaseAuditProblems.txt
Console output: https://builds.apache.org/job/PreCommit-RANGER-Build/53//console

This message is automatically generated.

> ranger-admin and ranger-usersync does not honour the SSL truststore property
> ----------------------------------------------------------------------------
>
>                 Key: RANGER-840
>                 URL: https://issues.apache.org/jira/browse/RANGER-840
>             Project: Ranger
>          Issue Type: Bug
>          Components: Ranger, usersync
>    Affects Versions: 0.5.0, 0.5.1
>         Environment: Ranger trying to use AD (running with SSL) for usersync 
> and admin UI access
>            Reporter: Sailaja Polavarapu
>            Assignee: Sailaja Polavarapu
>             Fix For: 0.6.0
>
>         Attachments: 
> 0001-Ranger-840-Honoring-custom-truststore-configuration-.patch
>
>
> While configuring the Ranger usersync with AD over SSL , there is an option 
> to specify the truststore i.e. "ranger.usersync.truststore.file". Even if 
> this property (and its related password field) is set, the ranger-usersync 
> daemon would not honor it and the usersync will not work.
> Similar problem can be seen with ranger-admin daemon.
> ERROR:
> ================================
> In case of the error, the stack trace would be something like this:
> 27 Jan 2016 23:51:16 ERROR UserGroupSync [UnixUserSyncThread] - Failed to 
> initialize UserGroup source/sink. Will retry after 3600000 milliseconds. 
> Error details:
> javax.naming.CommunicationException: simple bind failed: 
> ad01.lab.hortonworks.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)
>         at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2788)
>         at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
>         at 
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
>         at 
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
>         at 
> com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
>         at 
> com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
>         at 
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
>         at 
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
>         at javax.naming.InitialContext.init(InitialContext.java:244)
>         at 
> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
>         at 
> org.apache.ranger.ldapusersync.process.LdapUserGroupBuilder.createLdapContext(LdapUserGroupBuilder.java:190)
>         at 
> org.apache.ranger.ldapusersync.process.LdapUserGroupBuilder.updateSink(LdapUserGroupBuilder.java:304)
>         at 
> org.apache.ranger.usergroupsync.UserGroupSync.run(UserGroupSync.java:58)
>         at java.lang.Thread.run(Thread.java:745)
> Caused by: 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 sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>         at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
>         at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
>         at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
>         at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
>         at 
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
>         at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
>         at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
>         at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
>         at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>         at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)
>         at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
>         at 
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
>         at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:426)
>         at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:399)
>         at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
>         at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
>         ... 14 more
> Steps to RE-CREATE:
> ==========================================
> 1. Have an Active Directory working over SSL. Copy the SSL certificate (say, 
> ad.cert) of AD on ranger node.
> 2. Import the AD certificate into truststore (remember the password set here)
> $JAVA_HOME/bin/keytool -import -trustcacerts -alias root -file 
> /etc/pki/tls/certs/ad.cert -keystore 
> /usr/hdp/current/ranger-usersync/userSyncCACerts
> 3. Install & configure Ranger. In the usersync and admin authentication, 
> select 'Active Directory' and give all the required parameters.
> 4. Also, locate the "ranger.usersync.truststore.file" property in the config 
> and give the keystore path & password from step#2.
> 5. Restart Ranger daemons.
> 6. Check the usersync log for the above stack trace.
> WORKAROUND:
> ==================================
> To make ranger-usersync work with SSL truststore, one need to manually 
> specify the truststore path in the 
> /usr/hdp/current/ranger-usersync/ranger-usersync-services.sh script using the 
> "-Djavax.net.ssl.trustStore=" flag.
> Then restart the usersync daemon "manually".
> # diff ranger-usersync-services.sh.orig ranger-usersync-services.sh
> 67c67
> <     nohup java -Dproc_rangerusersync 
> -Dlog4j.configuration=file:/etc/ranger/usersync/conf/log4j.xml ${JAVA_OPTS} 
> -Dlogdir="${logdir}" -cp "${cp}" 
> org.apache.ranger.authentication.UnixAuthenticationService -enableUnixAuth > 
> ${logdir}/auth.log 2>&1 &
> ---
> >     nohup java -Dproc_rangerusersync* 
> > -Djavax.net.ssl.trustStore=/usr/hdp/current/ranger-usersync/userSyncCACerts 
> > *-Dlog4j.configuration=file:/etc/ranger/usersync/conf/log4j.xml 
> > ${JAVA_OPTS} -Dlogdir="${logdir}" -cp "${cp}" 
> > org.apache.ranger.authentication.UnixAuthenticationService -enableUnixAuth 
> > > ${logdir}/auth.log 2>&1 &
> On the other hand, the ranger-admin daemon will not give any error in the log 
> file but it won't allow AD user either. To get the same error stack, one need 
> to enable debug log level for ranger-admin.
> For ranger-admin, the file to edit would be : 
> /usr/hdp/current/ranger-admin/ews/ranger-admin-services.sh.
> # diff ranger-admin-services.sh.orig ranger-admin-services.sh
> 56c56
> <     java -Dproc_rangeradmin ${JAVA_OPTS} 
> -Dlogdir=${XAPOLICYMGR_EWS_DIR}/logs/ -Dcatalina.base=${XAPOLICYMGR_EWS_DIR} 
> -cp 
> "${XAPOLICYMGR_EWS_DIR}/webapp/WEB-INF/classes/conf:${XAPOLICYMGR_EWS_DIR}/lib/*:${RANGER_JAAS_LIB_DIR}/*:${RANGER_JAAS_CONF_DIR}:${JAVA_HOME}/lib/*:$CLASSPATH"
>  org.apache.ranger.server.tomcat.EmbeddedServer > logs/catalina.out 2>&1 &
> ---
> >     java -Dproc_rangeradmin ${JAVA_OPTS} 
> > -Djavax.net.ssl.trustStore=/usr/hdp/current/ranger-usersync/userSyncCACerts 
> > -Dlogdir=${XAPOLICYMGR_EWS_DIR}/logs/ 
> > -Dcatalina.base=${XAPOLICYMGR_EWS_DIR} -cp 
> > "${XAPOLICYMGR_EWS_DIR}/webapp/WEB-INF/classes/conf:${XAPOLICYMGR_EWS_DIR}/lib/*:${RANGER_JAAS_LIB_DIR}/*:${RANGER_JAAS_CONF_DIR}:${JAVA_HOME}/lib/*:$CLASSPATH"
> >  org.apache.ranger.server.tomcat.EmbeddedServer > logs/catalina.out 2>&1 &



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to