The formatting of the principal name is just a property and while it could
be changed I believe the cluster name is usually added as Principal Suffix
because what if there are multiple clusters in the same Kerberos realm.
If the principal was only hdfs@domain then multiple clusters would share
the same KDC entry. Re-generating the keytab in one cluster might cause
issues in the others. Also potential security risk as it would allow cross
cluster access.
This kinit is correct
kinit -kt /etc/security/keytabs/hdfs.headless.keytab hdfs-spark_cluster
Using principal: hdfs-spark_cluster@test_kdc.com
When you present that principal you will be treated like hdfs because of
the rule RULE:[1:$1@$0](hdfs-spark_cluster@test_kdc.com)s/.*/hdfs/
On Mon, May 7, 2018 at 6:14 PM, Lian Jiang <jiangok2...@gmail.com> wrote:
> Hi,
>
> I am using HDP2.6 and have enabled kerberos. The rules generated by ambari
> has:
>
> RULE:[1:$1@$0](hdfs-spark_cluster@test_kdc.com)s/.*/hdfs/
>
> Also, klist shows hdfs user is mapped correctly to the rule:
>
> [hdfs@test-namenode ~]$ klist
> Ticket cache: KEYRING:persistent:1012:1012
> Default principal: hdfs-spark_cluster@test_kdc.com
>
> User hdfs-spark_cluster is associated with hdfs keytab:
>
> [hdfs@test-namenode ~]$ kinit -V -kt
> /etc/security/keytabs/hdfs.headless.keytab
> hdfs-spark_cluster
> Using existing cache: persistent:1012:1012
> Using principal: hdfs-spark_cluster@test_kdc.com
> Using keytab: /etc/security/keytabs/hdfs.headless.keytab
> Authenticated to Kerberos v5
>
> However, hdfs is NOT associated with this hdfs keytab:
>
> [hdfs@test-namenode ~]$ kinit -V -kt
> /etc/security/keytabs/hdfs.headless.keytab
> hdfs
> Using new cache: persistent:1012:krb_ccache_V36KQXp
> Using principal: hdfs@test_kdc.com
> Using keytab: /etc/security/keytabs/hdfs.headless.keytab
> kinit: Keytab contains no suitable keys for hdfs@test_kdc.com while
> getting initial credentials
>
> As you can see, kinit maps hdfs to hdfs@test_kdc.com instead of
> hdfs-spark_cluster@test_kdc.com.
>
> I guess this is the reason I got "Failed to find any Kerberos tgt" when
> doing "hdfs dfs -ls".
>
> I don't know why ambari create kerberos users in the format of
> "hdfs-{CLUSTERNAME}@{REALNAME}" instead of "hdfs@{REALNAME}".
>
> Should I follow https://community.hortonworks.com/articles/79574/build-a-
> cluster-with-custom-principal-names-using.html to force ambari to create
> hdfs@test_kdc.com instead of hdfs-spark_cluster@test_kdc.com? Or I am
> missing anything else?
>
> Thanks for any help.
>
>
