@irfangk1  You can find more details about headless / service principals/keytabs in the following doc:  https://docs.hortonworks.com/HDPDocuments/HDP3/HDP-3.1.0/authentication-with-kerberos/content/kerberos_principals.html ... View more

@irfangk1  From Standard Kerberos perspective there is no command to differentiate between headless/service keytab.  However, we can differentiate between headless / service keytabs  you can find the detailed discussion about it in the following thread:  https://community.cloudera.com/t5/Support-Questions/Headless-Keytab-Vs-User-Keytab-Vs-Service-Keytab/m-p/175276 Try running the following command on your keytab: Headless keytab Headless principals are not bound to a specific host or node, they have the syntax: - @EXAMPLE.COM   # klist -kte /etc/security/keytabs/hdfs.headless.keytab Keytab name: FILE:/etc/security/keytabs/hdfs.headless.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 2 08/11/2019 01:58:27 hdfs-ker1latest@EXAMPLE.COM (des-cbc-md5) 2 08/11/2019 01:58:27 hdfs-ker1latest@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 2 08/11/2019 01:58:27 hdfs-ker1latest@EXAMPLE.COM (des3-cbc-sha1) 2 08/11/2019 01:58:27 hdfs-ker1latest@EXAMPLE.COM (arcfour-hmac) 2 08/11/2019 01:58:27 hdfs-ker1latest@EXAMPLE.COM (aes128-cts-hmac-sha1-96)   If it is truly a headless keytab then it will not have a principal specific to a Host.   Service keytab Service principal is something that does not need to be a POSIX user,they are mostly applications that have own arrangement on how they run on the OS level and need to interact with the Kerberized cluster. Notice it's principal name has hostname included. Example: # klist -kte /etc/security/keytabs/nn.service.keytab Keytab name: FILE:/etc/security/keytabs/nn.service.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 2 08/11/2019 01:58:40 nn/ker1latest1.example.com@EXAMPLE.COM (des-cbc-md5) 2 08/11/2019 01:58:40 nn/ker1latest1.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 2 08/11/2019 01:58:40 nn/ker1latest1.example.com@EXAMPLE.COM (des3-cbc-sha1) 2 08/11/2019 01:58:40 nn/ker1latest1.example.com@EXAMPLE.COM (arcfour-hmac) 2 08/11/2019 01:58:40 nn/ker1latest1.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)   . ... View more

@lvic4594_  Great to know that the issue is resolved after making the recommended changes to use the producer.config argument explicitly  --producer.config /etc/kafka/conf/producer.properties  As the issue is resolved, hence it will be great to mark this thread as Solved. So that other users can quickly find the resolved threads/answers,. ... View more

@Reed Villanueva The users created inside the Ambari UI can be of two types "LOCAL" users and "LDAP" users. You can find this detail isnide the "users" table of ambari DB. Ambari in any case is not responsible for creating user/groups for those ambari UI users in any node. For example you will see "admin" user in ambari but you wont see any such user on ambari server host or on any other node. If you have integrated ambari with some user base like LDAP /AD then you can run the ldap-sync command to sync those users and groups present in the LDAP to sync them to ambari database "users'" table. So that those users can login to ambari UI with the LDAP credentials. But if you want these same Users to be created on every Physical host so that you can login to those hosts using the mentioned user accounts then you will need to setup SSSD service to sync those LDAP users to the OS users. https://github.com/HortonworksUniversity/Security_Labs/blob/master/HDP-2.6-AD.md#setup-ados-integration-via-sssd ... View more

@Reed Villanueva Few things: 1. Ambari never adds any host entry inside the "/etc/hosts" file. It is the responsibility of the cluster admin to make sure all the hostname entries are added to either in a DNS server or inside the "/etc/hosts" file of each node of the cluster (irrespective it is a new node or old node) 2. Every cluster node should return a Fully Qualified Hostname (FQDN) when you run the following command on any cluster node. # hostname -f 3. Each and every node present in your cluster should be able to resolve each other using their FQDN (not using the alias hostname) So ping hw04 and ping hw04.ucera.local are not same . So to fix the issue please perform the above checks. And make sure that the "/etc/hosts" file entry on ambari server host and all cluster nodes are identical. Then verify if the ping and telnet works file from all cluster nodes and they are able to reach "hw04.ucera.local" correctly. # cat /etc/hosts # ping hw04.ucera.local  # telnet hw04.ucera.local  50075 . ... View more

@Reed Villanueva Please check if you can acccess the hostname "hw04.ucera.local" from all your cluster nodes? Without any hostname/firewall issue? Please run the same command from all cluster nodes: # ping hw04.ucera.local # telnet hw04.ucera.local  50075 # hostname -f . ... View more