Support Questions

Find answers, ask questions, and share your expertise

Impala LDAP authentication issues

avatar
Explorer

Hi,

         I've pretty much read through all the articles and questions about this, but i'm still having issues. the ldap user is definitely there and i can query through ldap port:389. 

I've set up the HUE ldap to authenticate against my openldap server, it works great. But i couldn't get the impala ldap setup to work. I'm using CDH 6.3. 

 

I configured impala ldap settings through CM gui, services restarted okay after the config

 

Advanced Configuratoin snippet(safety valve) :--ldap_passwords_in_clear_ok=true

Enable LDAP Authentication: checked

LDAP URL: ldap://myldapFQDN:389
LDAP BaseDN: ou=users,dc=ldap,dc=xxx,dc=com
 
 
Error when using cloudera impala jdbc driver to connect, it worked with AuthMech=0 before I enabled LDAP
drv <- RJDBC::JDBC("com.cloudera.impala.jdbc4.Driver", "/opt/jars/ImpalaJDBC4.jar")
con <- dbConnect(drv, "jdbc:impala://impalaDaemonIP:21050;AuthMech=3;UID=myuser;PWD=mypassword")
Error in .jcall(drv@jdrv, "Ljava/sql/Connection;", "connect", as.character(url)[1], : java.sql.SQLException: [Cloudera][ImpalaJDBCDriver](500176) Error connecting to HiveServer2, please verify connection settings.
 
Error when using the impala-shell
impala-shell -i impalaDaemonIP -d default -l -u myuser --auth_creds_ok_in_clear
prompted password and entered

Socket error None: timed out
***********************************************************************************
Welcome to the Impala shell.
(Impala Shell v3.2.0-cdh6.3.2 (1bb9836) built on Fri Nov 8 07:22:06 PST 2019)

Press TAB twice to see a list of available commands.
***********************************************************************************

LDAP authentication is enabled, but the connection to Impala is not secured by TLS.
ALL PASSWORDS WILL BE SENT IN THE CLEAR TO IMPALA.
[Not connected] >

 

/var/log/impalad/impalad.INFO   log info

 

I0211 21:51:14.585675 63449 thrift-util.cc:123] TAcceptQueueServer: Caught TException: invalid sasl status
I0211 22:00:26.182997 63450 authentication.cc:254] Trying simple LDAP bind for: uid=myuser,ou=users,dc=ldap,dc=xxx,dc=com
W0211 22:02:33.461439 63450 authentication.cc:261] LDAP authentication failure for uid=myuser,ou=users,dc=ldap,dc=xxx,dc=com : Can't contact LDAP server
E0211 22:02:33.461570 63450 authentication.cc:164] SASL message (LDAP): Password verification failed

 

 

1 ACCEPTED SOLUTION

avatar
Explorer

Hi tmater, sorry for the delay, yea the user does exist in the directory in that OU.

 

       I actually do have an update on this, so originally the cloudera cluster(on AWS network) authenticates against my ldap server(on premise office network) via the WAN traffic. I did open port 389 and 636 both UDP and TCP on my ldap server and firewall. That didn't work. I just finished setting up a VPN tunnel between AWS and on premise network, I use the LAN ip for ldap settings on impala, and now it works. So i'm not sure if there's any additional ports needed to be open for the impala LDAP authentication or I did something wrong. But everything works now through the ldap and VPN tunnel.

View solution in original post

2 REPLIES 2

avatar
Expert Contributor

Hi @jayGenesis ,

Impala supports simple bind authentication in CDH 6.3. The documentation for reference:

 

LDAP BaseDN (--ldap_baseDN)
Replaces the username with a distinguished name (DN) of the form: uid=userid,ldap_baseDN. (This is equivalent to a Hive option).

LDAP Pattern (--ldap_bind_pattern)
This is the most general option, and replaces the username with the string ldap_bind_pattern where all instances of the string #UID are replaced with userid. For example, an ldap_bind_pattern of "user=#UID,OU=foo,CN=bar" with a username of henry will construct a bind name of "user=henry,OU=foo,CN=bar".

 

This means that with the mentioned base dn configured there will be a bind request from Impala towards the LDAP server with uid=<username>,ou=users,dc=ldap,dc=xxx,dc=com user dn and its password, if this user does not exist the authentication will fail. Does the mentioned user exist in the LDAP directory?

avatar
Explorer

Hi tmater, sorry for the delay, yea the user does exist in the directory in that OU.

 

       I actually do have an update on this, so originally the cloudera cluster(on AWS network) authenticates against my ldap server(on premise office network) via the WAN traffic. I did open port 389 and 636 both UDP and TCP on my ldap server and firewall. That didn't work. I just finished setting up a VPN tunnel between AWS and on premise network, I use the LAN ip for ldap settings on impala, and now it works. So i'm not sure if there's any additional ports needed to be open for the impala LDAP authentication or I did something wrong. But everything works now through the ldap and VPN tunnel.