[
https://issues.apache.org/jira/browse/LIVY-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953229#comment-16953229
]
Wing Yew Poon commented on LIVY-692:
------------------------------------
This issue is not a bug. It arose from two causes: (1) I was not using a pure
upstream Livy 0.6 but an internal version based on Livy 0.6 with some internal
changes which happened to cause the livy principal to be obtained from ticket
cache instead of keytab (needed for the principal to be used for Kerberos
authentication in the Thrift server in binary mode), and (2) a misunderstanding
that livy.server.auth.kerberos.principal should be the principal to use in the
JDBC URL for connecting to the Thrift server. I was led to (2) because using
the livy principal in the JDBC URL failed for me due to (1).
> Thrift server Kerberos authentication does not use configured principal
> -----------------------------------------------------------------------
>
> Key: LIVY-692
> URL: https://issues.apache.org/jira/browse/LIVY-692
> Project: Livy
> Issue Type: Bug
> Components: Thriftserver
> Affects Versions: 0.6.0
> Reporter: Wing Yew Poon
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I tried to use the Thrift server in Livy 0.6. I have a secure cluster, and I
> set
> {noformat}
> livy.server.thrift.authentication=KERBEROS
> {noformat}
> on the server side. I also have livy.server.auth.kerberos.keytab and
> livy.server.auth.kerberos.principal configured. In particular, in my system,
> I have
> {noformat}
> livy.server.auth.kerberos.principal=HTTP/<livy_server>@<REALM>
> {noformat}
> When I try to connect to the Thrift server using the beeline shipped with
> Hive, with
> {noformat}
> beeline -u
> 'jdbc:hive2://<livy_server>:<thrift_port>/<db>;principal=HTTP/<livy_server>@<REALM>'
> {noformat}
> it fails with
> {noformat}
> Error: Could not open client transport with JDBC Uri: ... :: Peer indicated
> failure: GSS initiate failed (state=08S01,code=0)
> {noformat}
> On the server side, the log shows
> {noformat}
> 2019-10-03 15:21:09,536 ERROR org.apache.thrift.transport.TSaslTransport:
> SASL negotiation failure
> javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: Failure unspecified at GSS-API level (Mechanism level: Invalid
> argument (400) - Cannot find key of appropriate type to decrypt AP REP - DES3
> CBC mode with SHA1-KD)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(GssKrb5Server.java:199)
> at
> org.apache.thrift.transport.TSaslTransport$SaslParticipant.evaluateChallengeOrResponse(TSaslTransport.java:539)
> at
> org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:283)
> at
> org.apache.thrift.transport.TSaslServerTransport.open(TSaslServerTransport.java:41)
> at
> org.apache.thrift.transport.TSaslServerTransport$Factory.getTransport(TSaslServerTransport.java:216)
> at
> org.apache.livy.thriftserver.auth.TUGIAssumingTransportFactory$$anon$1.run(AuthBridgeServer.scala:143)
> at
> org.apache.livy.thriftserver.auth.TUGIAssumingTransportFactory$$anon$1.run(AuthBridgeServer.scala:142)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1710)
> at
> org.apache.livy.thriftserver.auth.TUGIAssumingTransportFactory.getTransport(AuthBridgeServer.scala:142)
> at
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:269)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: GSSException: Failure unspecified at GSS-API level (Mechanism
> level: Invalid argument (400) - Cannot find key of appropriate type to
> decrypt AP REP - DES3 CBC mode with SHA1-KD)
> at
> sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:856)
> at
> sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
> at
> sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
> at
> com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(GssKrb5Server.java:167)
> ... 14 more
> Caused by: KrbException: Invalid argument (400) - Cannot find key of
> appropriate type to decrypt AP REP - DES3 CBC mode with SHA1-KD
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:278)
> at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:149)
> at
> sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:108)
> at
> sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:829)
> ... 17 more
> {noformat}
> On debugging, I found that the UGI in the TUGIAssumingTransportFactory is not
> that of the configured HTTP principal but the UGI of the service principal
> (livy).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
