[
https://issues.apache.org/jira/browse/HADOOP-9296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582674#comment-13582674
]
Allen Wittenauer commented on HADOOP-9296:
------------------------------------------
After more thought, as far as I can tell, doesn't actually do anything to
protect the web interfaces for the TaskTracker or the DataNode. I'm guessing
this is built around the idea that something else is protecting those or the
user will always connect to the JT or NN first in order to get a delegation
token? Also, how does SPNEGO for the NN/2NN work under this scenario? Will
the hdfs user need to come from the "user" realm as well?
I recognize this is a kludge for broken company policies and politics who for
whatever reasons aren't willing to do Kerberos properly with a one-way trust.
But I'm worried this is going to give a false sense of security without making
sure that other things are in place. At the minimum, the documentation
accompanying this change should be explicit about its use cases and promote the
usage of real trusts.
> Authenticating users from different realm without a trust relationship
> ----------------------------------------------------------------------
>
> Key: HADOOP-9296
> URL: https://issues.apache.org/jira/browse/HADOOP-9296
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Reporter: Benoy Antony
> Assignee: Benoy Antony
> Attachments: HADOOP-9296-1.1.patch, multirealm.pdf
>
>
> Hadoop Masters (JobTracker and NameNode) and slaves (Data Node and
> TaskTracker) are part of the Hadoop domain, controlled by Hadoop Active
> Directory.
> The users belong to the CORP domain, controlled by the CORP Active Directory.
> In the absence of a one way trust from HADOOP DOMAIN to CORP DOMAIN, how will
> Hadoop Servers (JobTracker, NameNode) authenticate CORP users ?
> The solution and implementation details are in the attachement
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira