hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Foley (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-12617) SPNEGO authentication request to non-default realm gets default realm name inserted in target server principal
Date Sun, 06 Dec 2015 22:16:10 GMT

    [ 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
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);
Subject is set with the correct user principal and target server name and realm.  After executing
the line:
String servicePrincipal = KerberosUtil.getServicePrincipal("HTTP", KerberosAuthenticator.this.url.getHost());
The ServicePrincipal is returned as: "HTTP/hostname" (with an actual value for "hostname"),
but no realm.
Then, when it gets the serviceName
GSSName serviceName = gssManager.createName(servicePrincipal, oid);
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
> 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

View raw message