accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-4416) MAC failures when running on host configured with mixed-case hostname
Date Mon, 22 Aug 2016 20:10:20 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431516#comment-15431516
] 

Josh Elser commented on ACCUMULO-4416:
--------------------------------------

Here's an example which might help. Consider some hypothetical organization "FOO" (their KDC
realm). Inside of the FOO organization, there exists a number of machines, "bar1", "bar2",
and "bar3". These machines have the FQDN's of "bar1.foo.com", "bar2.foo.com", and "bar3.foo.com".
Assume there is some service ("my_service") which users can speak to over SASL, configured
for authentication via the Kerberos v5 implementation with GSSAPI. Finally, assume there are
two users in the FOO organization "josh" and "christopher".

DNS makes no distinction between "Bar3.foo.com" and "bar3.foo.com", they both resolve to the
same physical host on the network. Josh and Christopher can use either hostname to SSH into
this host (in addition to any other permutation of capitalization). What happens when they
try to communicate with the aforementioned hypothetical service?

Let's consider that Josh continues to use "Bar3.foo.com" to communicate with the service (because
he's a silly goose) while Christopher uses "bar3.foo.com" to communicate with the service.
Their hypothetical client code, to perform the authentication specified by GSSAPI/SASL, must
provide the server's principal. Specifically, Josh and Christopher would use "my_service/Bar3.foo.com@FOO"
and "my_service/bar3.foo.com@FOO", respectively.

Josh's request would fail with an error "Server not found in database" from the KDC. Because
the KDC is sensitive to capitalization and the service was configured with the actual FQDN
for "bar3", the KDC is not aware of any such principal "my_service/Bar3.foo.com". The handshake
will fail and Josh's request will be denied. Christopher's request would pass because the
KDC does know about "my_service/bar3.foo.com" and can perform the necessary authentication
handshake.

Does that help?

> MAC failures when running on host configured with mixed-case hostname
> ---------------------------------------------------------------------
>
>                 Key: ACCUMULO-4416
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4416
>             Project: Accumulo
>          Issue Type: Bug
>          Components: test
>    Affects Versions: 1.7.1
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Minor
>
> HADOOP-7988
> Kerberos is case-sensitive. DNS is not. I saw a case where a host with mixed-case hostname
had a MAC instance that fell over because of a spam of failed RPCs that never succeeded.
> MiniKDC and our code seems to be doing the right thing, but somehow a lower-case on the
hostname we were using on the client to communicate with the tserver happened. I'm not sure
what component did this. Should look into this with some VM configured with a mixed-case hostname.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message