[ https://issues.apache.org/jira/browse/IMPALA-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754518#comment-16754518 ]
Alex Rodoni commented on IMPALA-8111: ------------------------------------- https://gerrit.cloudera.org/#/c/12291/ > Document workaround for some authentication issues with KRPC > ------------------------------------------------------------ > > Key: IMPALA-8111 > URL: https://issues.apache.org/jira/browse/IMPALA-8111 > Project: IMPALA > Issue Type: Task > Components: Docs > Affects Versions: Impala 2.12.0, Impala 3.1.0 > Reporter: Michael Ho > Assignee: Alex Rodoni > Priority: Major > Labels: future_release_doc, in_32 > > There have been complaints from users about not being able to use Impala > after upgrading to Impala version with KRPC enabled due to authentication > issues. Please document them in the known issues or best practice guide. > 1. https://issues.apache.org/jira/browse/IMPALA-7585: > *Symptoms*: When using Impala with LDAP enabled, a user may hit the > following: > {noformat} > Not authorized: Client connection negotiation failed: client connection to > 127.0.0.1:27000: SASL(-1): generic failure: All-whitespace username. > {noformat} > *Root cause*: The following sequence can lead to the user "impala" not being > created in /etc/passwd. > {quote}time 1: no impala in LDAP; things get installed; impala created in > /etc/passwd > time 2: impala added to LDAP > time 3: new machine added > {quote} > *Workaround*: > - Manually edit /etc/passwd to add the impala user > - Upgrade to a version of Impala with the patch IMPALA-7585 > 2. https://issues.apache.org/jira/browse/IMPALA-7298 > *Symptoms*: When running with Kerberos enabled, a user may hit the following > error: > {noformat} > WARNINGS: TransmitData() to X.X.X.X:27000 failed: Not authorized: Client > connection negotiation failed: client connection to X.X.X.X:27000: Server > impala/x.x....@vpc.cloudera.com not found in Kerberos database > {noformat} > *Root cause*: > KrpcDataStreamSender passes a resolved IP address when creating a proxy. > Instead, we should pass both the resolved address and the hostname when > creating the proxy so that we won't end up using the IP address as the > hostname in the Kerberos principal. > *Workaround*: > - Set rdns=true in /etc/krb5.conf > - Upgrade to a version of Impala with the fix of IMPALA-7298 > 3. https://issues.apache.org/jira/browse/KUDU-2198 > *Symptoms*: When running with Kerberos enabled, a user may hit the following > error message where <random-string> is some random string which doesn't match > the primary in the Kerberos principal > {noformat} > WARNINGS: TransmitData() to X.X.X.X:27000 failed: Remote error: Not > authorized: {username='<random-string>', principal='impala/redacted'} is not > allowed to access DataStreamService > {noformat} > *Root cause*: > Due to system "auth_to_local" mapping, the principal may be mapped to some > local name. > *Workaround*: > - Start Impala with the flag {{--use_system_auth_to_local=false}} -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org