[
https://issues.apache.org/jira/browse/HADOOP-13565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiao Chen updated HADOOP-13565:
-------------------------------
Description:
In KerberosAuthenticationHandler#authenticate, we use canonicalized server name
derived from HTTP request to build server SPN and authenticate client. This can
be problematic if the HTTP client/server are running from a non-local Kerberos
realm that the local realm has trust with (e.g., NN UI).
For example,
The server is running its HTTP endpoint using SPN from the client realm:
<name>hadoop.http.authentication.kerberos.principal</name>
<value>HTTP/_HOST/TEST.COM</value>
When client sends request to namenode at http://NN1.example.com:50070 from
[email protected].
The client talks to KDC first and gets a service ticket
HTTP/NN1.example.com/TEST.COM to authenticate with the server via SPNEGO
negotiation.
The authentication will end up with either no valid credential error or
checksum failure depending on the HTTP client naming resolution or HTTP Host
field from the request header provided by the browser.
The root cause is KerberosUtil.getServicePrincipal("HTTP", serverName)}} will
always return a SPN with local realm (HTTP/[email protected]) no
matter the server login SPN is from that domain or not.
The proposed fix is to change to use default server login principal (by passing
null as the 1st parameter to gssManager.createCredential()) instead. This way
we avoid dependency on HTTP client behavior (Host header or name resolution
like CNAME) or assumption on the local realm.
was:
In KerberosAuthenticationHandler#authenticate, we use canonicalized server name
derived from HTTP request to build server SPN and authenticate client. This can
be problematic if the HTTP client/server are running from a non-local Kerberos
realm that the local realm has trust with (e.g., NN UI).
For example,
The server is running its HTTP endpoint using SPN from the client realm:
<name>hadoop.http.authentication.kerberos.principal</name>
<value>HTTP/_HOST/TEST.COM</value>
When client sends request to namenode at http://NN1.example.com:50070 from
[email protected].
The client talks to KDC first and gets a service ticket
HTTP/NN1.example.com/TEST.COM to authenticate with the server via SPNEGO
negotiation.
The authentication will end up with either no valid credential error or
checksum failure depending on the HTTP client naming resolution or HTTP Host
field from the request header provided by the browser.
The root cause is KerberosUtil.getServicePrincipal("HTTP", serverName)}} will
always return a SPN with local realm (HTTP/[email protected]) no
matter the server login SPN is from that domain or not.
The proposed fix is to change to use default server login principle (by passing
null as the 1st parameter to gssManager.createCredential()) instead. This way
we avoid dependency on HTTP client behavior (Host header or name resolution
like CNAME) or assumption on the local realm.
> KerberosAuthenticationHandler#authenticate should not rebuild SPN based on
> client request
> -----------------------------------------------------------------------------------------
>
> Key: HADOOP-13565
> URL: https://issues.apache.org/jira/browse/HADOOP-13565
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Xiaoyu Yao
> Assignee: Xiaoyu Yao
> Attachments: HADOOP-13565.00.patch
>
>
> In KerberosAuthenticationHandler#authenticate, we use canonicalized server
> name derived from HTTP request to build server SPN and authenticate client.
> This can be problematic if the HTTP client/server are running from a
> non-local Kerberos realm that the local realm has trust with (e.g., NN UI).
> For example,
> The server is running its HTTP endpoint using SPN from the client realm:
> <name>hadoop.http.authentication.kerberos.principal</name>
> <value>HTTP/_HOST/TEST.COM</value>
> When client sends request to namenode at http://NN1.example.com:50070 from
> [email protected].
> The client talks to KDC first and gets a service ticket
> HTTP/NN1.example.com/TEST.COM to authenticate with the server via SPNEGO
> negotiation.
> The authentication will end up with either no valid credential error or
> checksum failure depending on the HTTP client naming resolution or HTTP Host
> field from the request header provided by the browser.
> The root cause is KerberosUtil.getServicePrincipal("HTTP", serverName)}} will
> always return a SPN with local realm (HTTP/[email protected]) no
> matter the server login SPN is from that domain or not.
> The proposed fix is to change to use default server login principal (by
> passing null as the 1st parameter to gssManager.createCredential()) instead.
> This way we avoid dependency on HTTP client behavior (Host header or name
> resolution like CNAME) or assumption on the local realm.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
