[
https://issues.apache.org/jira/browse/IMPALA-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rodoni closed IMPALA-8111.
-------------------------------
Resolution: Fixed
Fix Version/s: Impala 3.2.0
> 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
> Fix For: Impala 3.2.0
>
>
> 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)
