@Malrashed Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. If you are still experiencing the issue, can you provide the information @jagarwal has requested? Thanks. ... View more

@phir1, Did @Sean464's responses assist in resolving your query? If it did, kindly mark the relevant reply as the solution, as it will aid others in locating the answer more easily in the future.  ... View more

Your suggestion is very helpful, I'm going to check it. Thank you. ... View more

Thanks for the confirmation @syedshakir. Much appreciated.  ... View more

@Amn_468  did you resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future.  ... View more

Hi @PrernaU, did @Sean464's solution help you?  If so, can you please mark the appropriate reply as the solution? It will make it easier for others to find the answer in the future.  ... View more

Hello @srinikar87    The error indicates that your KDC server requires clients to pre-authenticate themselves before it can issue a Ticket Granting Ticket (TGT).   If your KDC is a MIT kerberos, then probably a command line argument was passed by your administrator to require all clients to use pre-authentication. In this case, we can run the following command on your KDC server which will disable pre-authentication only for the impala principal, and the generate missing credentials should work.     kadmin.local: modprinc -requires_preauth impala/e2e-02-cdlkc1.nokia.com@NOKIA.COM   If your KDC is an AD server, then your AD administrator must enable the “Do not require Kerberos pre-authentication” checkbox in the user properties of the newly created impala principal. Refer the attachment.    Please let us know how this goes.      Reference: http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Adding-or-Modifying-Principals.html     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. ... View more

Hello @nj20200 It seems there is an older/previous version of openssl-devel package (openssl-libs-1.0.2k-19.el7.x86_64) is installed, which is causing the installation failure of new version openssl-devel package (openssl-devel-1.0.1e-60.el7.x86_64).    So instead of installing the package, update the openssl-devel package by running  "#yum update openssl-devel with -force option"  or just remove the previous package and install the new version of openssl-devel package.  ... View more

Hello @prabhat10 ,  Try this -    Backup your /etc/krb5.conf on all the hosts  Verify the encryption types supported from your Kerberos server (If MIT - Check "supported_enctypes" in /var/kerberos/krb5kdc/) Check the "Kerberos Encryption Types" under  CM > Administration > Security > Kerberos Credentials > Configuration. Include the encryption types supported by your KDC.  Enable "Manage krb5.conf through Cloudera Manager" from the same configuration page.  Select "Deploy Kerberos client configuration" from the drop-down near your cluster.  Once deployed, verify if the krb5.conf on the agent nodes have the encryption types included as mentioned in CM.  If CM server is running on stale kerberos configuration, copy the krb5.conf from one of the agent nodes to CM server. Regenerate the principals from CM. (If this is success, you should be able to restart CM and CDH services). ... View more