Support Questions

Find answers, ask questions, and share your expertise Client not found in Kerberos database (6) - CLIENT_NOT_Fou



I am trying to implement Kerberos security on cloudera CDH-5.3.  In kerberos implementation wizard it generates principals for all the services.

The prinicpal generated are as follows - 


kadmin.local: listprincs


But when i try to start all the services in the cluster it gives following error -


Failed to start namenode. Login failure for hdfs/ from keytab hdfs.keytab
at org.apache.hadoop.hdfs.server.namenode.NameNode.loginAsNameNodeUser(
at org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(
at org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(
at org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(
at org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(
at org.apache.hadoop.hdfs.server.namenode.NameNode.main(
Caused by: Client not found in Kerberos database (6) - CLIENT_NOT_FOUND
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(
at Method)
... 7 more
Caused by: KrbException: Client not found in Kerberos database (6) - CLIENT_NOT_FOUND
... 20 more
Caused by: KrbException: Identifier doesn't match expected value (906)
... 23 more


The problem seems to be that principal name that cloudera uses to authenticate is in SMALL LETTERS of FQDN while the generated princpals are



How to ensure that cloudera generates the principals(domain name) from - /etc/host file without converting it into small case


Super Guru

Hadoop in general expects that your hostnames and domain names are all lowercase.  When Kerberos is introduced, this becomes important.  While it is possible to override this behavior (of expecting lowercase) by doing manual configuration, I recommend ensuring via /etc/hosts or DNS that your host and domain are lower case.  After that is corrected, regenerate credentials and that should correct the problem.





New Contributor

We are seeing similar issue. Everything was working fine for our test setup but now we started seeing this issue.

You notice the "Client not found" it is relevent to jaas.conf, It has Server by default and it used to work but now we are seeing th default option Server but when we restart zookeepr, hdfs, hbase service it looks for Client. Since this dynamic config we can not do manual fix, we try running command manually after fix, it works for zookeeper, while there is no jaas.conf in hdfs folder.


What could have change that all applications starts looking for "Client" from "Server" option in jaas.conf.



ERROR org.apache.zookeeper.server.ZooKeeperServerMain: Unexpected exception, exiting abnormally Could not configure server because SASL configuration did not allow the  ZooKeeper server to authenticate itself properly: Client not found in Kerberos database (6) - CLIENT_NOT_FOUND
	at org.apache.zookeeper.server.ServerCnxnFactory.configureSaslLogin(
	at org.apache.zookeeper.server.NIOServerCnxnFactory.configure(
	at org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(
	at org.apache.zookeeper.server.ZooKeeperServerMain.initializeAndRun(
	at org.apache.zookeeper.server.ZooKeeperServerMain.main(
	at org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(
	at org.apache.zookeeper.server.quorum.QuorumPeerMain.main(



New Contributor
I found the issue with our KDC server setup, We use master and slave KDC server. Hadoop was using slave KDC for authentication and Updates were made on Master but not replicated properly. While using kinit, key was working. Once we reviewed KDC krb5.log we found same message in krb log that user was not present. Once the replication issue is fixed. Hadoop also started working.

Community Manager

There is some great discussion here.  @singhuda have you resolved the original issue?

Cy Jervis, Manager, Community Program
Was your question answered? Make sure to mark the answer as the accepted solution.
If you find a reply useful, say thanks by clicking on the thumbs up button.

New Contributor

I am also facing similar issue. Without kerberos all the services are running properly but when I try to kerberized the cluster with AD external authentication, the CM's wizard took me properly until stopping the cluster but when the cluster is restarting I am facing the issues in first step of hdfs dependency .. zookeeper

Unexpected exception, exiting abnormally Could not configure server because SASL configuration did not allow the  ZooKeeper server to authenticate itself properly: Client not found in Kerberos database (6)
	at org.apache.zookeeper.server.ServerCnxnFactory.configureSaslLogin(
	at org.apache.zookeeper.server.NIOServerCnxnFactory.configure(
	at org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(
	at org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(
	at org.apache.zookeeper.server.quorum.QuorumPeerMain.main(

 we have generated credentials for common/single user for entire cluster services.. 

Any idea whats the issue..

Super Guru



Make sure you have your /etc/krb5.conf configured correctly so that the zookeeper is sending its AS_REQ to the right KDC.  If you have just changed from one KDC to another, the /etc/krb5.conf also needs to be updated.  If you are not managing it with Cloudera Manager, it needs to be changed manually.


Either way, you could do a tcpdump on port 88 and check if output requests are going to the right KDC if /etc/krb5.conf is configured properly for your new KDC.



New Contributor



I just groomed all krb5.* files on all hosts and re-enable the kerberos through CM where it can regenerate all missing credentials including managing krb. This time I gave freehand to CM to create individual service princiaples to various services(hdfs, hive, hue, etc.) instead of existing service principle (a system user). 

This time Zookeeper started successfully but not HDFS. The HttpFS is also started in HDFS. I can't see any errors but can see WARNINGS in log file



CredentialManager kt_renewer WARNING Couldn't kinit as 'HTTP/' using
/run/cloudera-scm-agent/process/1330-hdfs-HTTPFS/httpfs.keytab --- kinit:
Client 'HTTP/' not found in Kerberos database while getting
initial credentials



Super Guru



What you provided appears to be an agent log message that indicates an attempt to kinit with the HTTP principal on the host where HTTPFS role runs was not successful.  Check on the host where the httpfs role runs and make sure the krb5.conf file is correct.  This shoud not impact HDFS as a whole since HTTPFS is a client of HDFS really.


Cloudera Manager should merge the HTTP principal automatically, so please run the following to make sure the keytab has the right keys:


# klist -kte /run/cloudera-scm-agent/process/1330-hdfs-HTTPFS/httpfs.keytab



New Contributor

I have the same issue , 


My hosts in cluster have hostname something like this


192.168.X.X  Master

192.168.X.X Slave1

192.168.X.X Slave2

192.168.X.X Slave3 


And generated principal names were like





And when a data node is started it was looking for hdfs/master@Former Member instead of hdfs/Master@Former Member


Resoultion steps:


1)Change HOSTNAME in /etc/sysconfig/network 


HOSTNAME=master on Master node , HOSTNAME=slave1 on Slave1 node

2)Have all the hosts in cluster maintain same hostname 


192.168.X.X master

192.168.X.X slave


3) Reboot all hosts


4) Check for the hostname 


5) On Cloudera manager -> For each hosts - > regenrate keytab


6) Go to Administration->Security->KerberosCredentials ->Check the prinicipal names are with correct hosts like 






New Contributor

Thanks Nitesh, this should be a mandatory steps in the doc to install multi datanode cluster with Kerberos enabled



I modified the HOSTNAME to lowercase and modified /etc/hosts and rebooted the servers.

Cloudera Manager is generating only 3 principals (hue, solr and HTTP). If I click "generate missing credentials", it says

"No roles required Kerberos credentials to be generated."


Please help what needs to be done to generate all the credentials.