[
https://issues.apache.org/jira/browse/HADOOP-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045271#comment-15045271
]
Matt Foley edited comment on HADOOP-12617 at 12/7/15 8:32 PM:
--------------------------------------------------------------
[~ste...@apache.org], not in a properly configured system. There is some
evidence that if run on a system with Kerberos configured on but default realm
not defined (either via System Property "java.security.krb5.realm" or krb5.conf
parameter "default_realm"), that getDefaultRealm() or getDomainRealm() may
throw an exception. But that's a fairly gross misconfiguration.
Also, I put a call to both getDefaultRealm() and getDomainRealm() in the
revised unit test, and they did not throw an exception on the Jenkins test
host, which may or may not be well configured.
Do you think the error should be suppressed without logging? I had wondered
why there was no logging in the KerberosUtils class.
Also, does anyone listening have access to the documentation for IBM Java
package "com.ibm.security.krb5"? getDomainRealm() follows the model of
getDefaultRealm(), but I was unable to confirm that
com.ibm.security.krb5.internal.PrincipalName exists and respects the semantics
of principal string type "KRB_NT_SRV_HST". Thanks.
was (Author: mattf):
[~ste...@apache.org], not in a properly configured system. There is some
evidence that if run on a system with Kerberos configured on but default realm
not defined (either via System Property "java.security.krb5.realm" or krb5.conf
parameter "default_realm"), that getDefaultRealm() or getDomainRealm() may
throw an exception. But that's a fairly gross misconfiguration.
Do you think the error should be suppressed without logging? I had wondered
why there was no logging in the KerberosUtils class.
Also, does anyone listening have access to the documentation for IBM Java
package "com.ibm.security.krb5"? getDomainRealm() follows the model of
getDefaultRealm(), but I was unable to confirm that
com.ibm.security.krb5.internal.PrincipalName exists and respects the semantics
of principal string type "KRB_NT_SRV_HST". Thanks.
> 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
> Attachments: HADOOP-12617-branch-2.7.001.patch,
> HADOOP-12617.001.patch, HADOOP-12617.002.patch, HADOOP-12617.003.patch
>
>
> 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)
