When you mention you have the same problem, what is the exact error you are getting?   As for the original issue in this post, we see two items that can cause issues for kerberos in Hadoop:   (1) hosts with no domains (even .local would do) (2) Capital letters on hostnames.   You have this configured the hostname with all capitals:  impala/CLOUDERAVALM1@REALM.COM   In order to have the best chance of getting kerberos to work, I would recommend verifying the following:   (1)  All hosts have Fully-qualified domain names.  For instance, "hostname" should return the hostname and "hostname -f" should return the FQDN. (2)  If relying on the hosts file for resolution, make sure that you are using the following format: IP FQDN HOSTNAME For example:   10.0.0.2   myhost.example.com myhost   (3)  Make sure you use only uppercase host names.  Hadoop is sensitive to this at the moment.  Though technically valid, it will cause problems for sure.   (4)  Ensure all hosts can resolve eachother with forward and reverse DNS (with FQDN).   I think the main problem you are facing is dealing with the uppercase hostnames without a domain.  It'll work fine without Kerberos involved, but when intoducing Kerberos, the rules change a bit to support that method of authentication.   After you make the network changes, make sure to regenerate credentials for all roles so that the correct principals are created.   I hope this is a good start.   Regards,   Ben ... View more

In older versions of Cloudera Manager (4.x I believe), the keytab file used to be stored in /etc/cloudera-scm-server as "cmf.keytab". Now, it is stored in Cloudera Manager's database.   To create or update the KDC account manager in Cloudera Manager, you can reference this documentation:   http://www.cloudera.com/documentation/enterprise/latest/topics/cm_sg_deploy_keytab_s5.html   ... View more

Actually, this message may be showing us the cause.  Due to the fact that the interesting bit was off the page when I was looking at your Zookeeper snippet, I couldn't see it at first:   2016-12-26 20:13:48,322 INFO org.apache.zookeeper.server.PrepRequestProcessor: Got user-level KeeperException when processing sessionid:0x1593c8f09d800f6 type:create cxid:0x2 zxid:0x1b2ea txntype:-1 reqpath:n/a Error Path:/solr Error:KeeperErrorCode = NoNode for /solr   Zookeeper appears to have no znode for /solr To create one, in Cloudera Manager, Go to Solr. Next, click on the Actions button (drop-down) on the far right and choose "Initialize Solr" This will create the /solr znode.   After that, try starting Solr again.   Regards,   Ben ... View more

A0: While using LDAP as a "unified account system", Cloudera recommends against leveraging LDAP Group Mapping.  I'll repost the Note on the page you mentioned: Important: Cloudera strongly recommends against using Hadoop's LdapGroupsMapping provider. LdapGroupsMapping should only be used in cases where OS-level integration is not possible. Production clusters require an identity provider that works well with all applications, not just Hadoop. Hence, often the preferred mechanism is to use tools such as SSSD, VAS or Centrify to replicate LDAP groups.   The idea is to allow tools that were designed for unix account integration with LDAP/Active Directory, etc. You could enable LDAP Groups Mapping for HDFS, but only HDFS would know about users/groups.  The OS would not know about them.   A1: Yes, each host should have the same set of users.  Two common methods of managing this (without having to manually update every host's passwd and group files:   - Tools such as SSSD, VAS, and Centrify allow hosts to retrieve user information from one location.  As long as each host in the cluster is configured to use the tool, each host can find a singular entry in LDAP (hdfs user for instance) - Puppet, Chef, or other automation tools can be used to push out passwd/group changes to all hosts.   A2: No. There is no "syncing" for LDAP Groups Mapping; rather, there is one LDAP entry that services will reference.   A3: By default, Cloudera Manager has "Create Users and Groups, and Apply File Permissions for Parcels" enabled.  When the parcel is activated, the agents on each host managed by that Cloudera Manager will create local users and groups if that setting is enabled.  It won't create them in LDAP, though.   A4: I'm affraid I don't understand the question completely, so I'll answer generally.  As long as your client has the proper configuration and credentials to authenticate, it should be able to work.   I hope that all helps.   Regards,   Ben ... View more