[
https://issues.apache.org/jira/browse/PHOENIX-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16920876#comment-16920876
]
Josh Elser commented on PHOENIX-5393:
-------------------------------------
[~swaroopa], did someone fix this? Commenting on a resolved issue isn't a good
way to get attention. Is there some Jira issue open tracking this work item?
> Perform _HOST principal expansion for SPENGO QueryServer principal
> ------------------------------------------------------------------
>
> Key: PHOENIX-5393
> URL: https://issues.apache.org/jira/browse/PHOENIX-5393
> Project: Phoenix
> Issue Type: Improvement
> Reporter: István Tóth
> Assignee: Josh Elser
> Priority: Blocker
> Fix For: queryserver-1.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> [~stoty] found that we aren't doing {{_HOST}} expansion for PQS. We naturally
> get this for the principal we use to talk to HBase (by virtue of using
> SecurityUtil/UGI to log in). However, for SPNEGO, we're using the Avatica API
> to do this, so it doesn't do this "Hadoop-ism" for us.
> We can use SecurityUtil to do it ourselves and then pass the correct hostname
> into the Avatica {{HttpServer.Builder}} API.
> The error you get when {{_HOST}} is set is pretty obtuse on the server-side,
> including to help the poor soul who ventures here with a similar error.
> {noformat}
> 2019-07-17 08:48:03,383 WARN
> org.apache.phoenix.shaded.org.eclipse.jetty.security.SpnegoLoginService:
> 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){noformat}
> We identified the problem by seeing, in {{-Dsun.security.spnego.debug=true
> -Dsun.security.krb5.debug=true}} output, the following:
> {noformat}
> Looking for keys for: HTTP/[email protected]{noformat}
> At this point in the call, we should have had an expanded "instance" in the
> principal.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
