[
https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044177#comment-15044177
]
Matt Foley commented on HADOOP-12617:
-------------------------------------
Teradata engineering team provided debugger information leading to the
following analysis:
A Java client desiring to initiate communication via HTTP/SPNEGO does the
following: In the context of a UGI.doAs(), it calls
org.apache.hadoop.security.authentication.client.KerberosAuthenticator.authenticate(),
which in turn calls doSpnegoSequence().
Inside doSpnegoSequence(), is this code at
https://github.com/apache/hadoop/blob/branch-2.7.2/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/client/KerberosAuthenticator.java#L287-L298
:
{code}
Subject.doAs(subject, new PrivilegedExceptionAction() {
public Void run() throws Exception {
GSSContext gssContext = null;
try {
GSSManager gssManager = GSSManager.getInstance();
String servicePrincipal = KerberosUtil.getServicePrincipal("HTTP",
KerberosAuthenticator.this.url.getHost());
Oid oid = KerberosUtil.getOidInstance("NT_GSS_KRB5_PRINCIPAL");
GSSName serviceName = gssManager.createName(servicePrincipal, oid);
{code}
Subject is set with the correct user principal and target server name and
realm. After executing the line:
{code}
String servicePrincipal = KerberosUtil.getServicePrincipal("HTTP",
KerberosAuthenticator.this.url.getHost());
{code}
The ServicePrincipal is returned as: "HTTP/hostname" (with an actual value for
"hostname"), but no realm.
Then, when it gets the serviceName
{code}
GSSName serviceName = gssManager.createName(servicePrincipal, oid);
{code}
The resulting data structure includes a subfield Krb5PrincipalName with value
"HTTP/hostname@DEFAULTREALM", where "hostname" and "DEFAULTREALM" are of course
substituted with real values. The default realm should not be here. It is
required that the correct non-default realm should be derived from the domain
of "hostname".
However, the second component of a principal is, strictly speaking, the
"instance", not the "server". Thus, the Kerb libraries are not inferring the
realm from the domain portion of the server name, because the formal semantics
don't actually match; and of course there is nowhere else the realm could be
correctly inferred from. KerberosUtil.getServicePrincipal() has to return a
full principal with correct realm, rather than the short principal with
inferred default realm.
> SPNEGO authentication request to non-default realm gets default realm name
> inserted in target server principal
> --------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-12617
> URL: https://issues.apache.org/jira/browse/HADOOP-12617
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Affects Versions: 2.7.1
> Environment: Java client talking to two secure clusters in different
> Kerberos realms,
> or talking to any secure cluster in non-default realm
> Reporter: Matt Foley
> Assignee: Matt Foley
>
> Note: This is NOT a vulnerability.
> In order for a single Java client to communicate with two different secure
> clusters in different realms (only one of which can be the "default_realm"),
> the client's krb5.conf file must specify both realms, and provide a
> \[domain_realm\] section that maps cluster servers' domains to the correct
> realms. With other appropriate behaviors (such as using the config from each
> cluster to talk to the respective clusters, and a user principal from each
> realm to talk to the respective realms), this is sufficient for most Hadoop
> ecosystem clients.
> But our SPNEGO using clients, such as Oozie, have a bug when it comes to
> talking to a non-default realm. The default realm name gets incorrectly
> inserted into the construction of the target server principal for the
> non-default-realm cluster. Details and proposed solution are given in the
> first comments below.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
