Hi @xu jerry Few observations: 1. The crontab is set to get a new ticket at midnight every day. But the klist output says that the ticket was acquired on "09/23/16 07:10:35". Meaning, someone (or some program) had refreshed the ticket after midnight at 7:10. 2. By default, the TGT would be valid for a day. But in your case, the validity looks to be '2days and 2 minutes' (from klist output). Is that expected? 3. The KDC logs clearly says that the ticket was expired by "Sep 23 10:57:31". Also you can see that there was a TGT request (AS_REQ) at midnight (that'd be your crontab). And there were two service ticket requests (TGS_REQUEST). So as per KDC log, no one refreshed the TGT after midnight. (so my #1 stand false as of this) To answer your question: My question is : Can other application(such as : hadoop client) edit /tmp/krb5cc_613 programmly? I think other application (hadoop client) just read information from /tmp/krb5cc_613 instead writing it. Usually the hadoop clients and applications would only consume (i.e. read) the TGT. The only condition in which a TGT would get updated is when an application try to do kinit programmatically. If you are consistently getting this error, then I'd advice to run kinit in the debug mode. That is once you get ticket expired error, then execute these and check (& post) the output here. export KRB5_TRACE=/dev/stdout klist -eaf kvno <name_of_any_service_principal> Also, it'd also make sense to attach your /etc/krb5.conf to know what are the current Kerberos configurations. Hope this help. ... View more

@mqureshi I'd like to see the values that you are using, like what <principal> , <keytab> and <proxyuser> are set to? Similarly what value are you seeing in <kerberos principal> in the log? ... View more

@Sarah Maadawy No. That means that the external users can be allowed to access Ranger UI and not every internal user is allowed the access by default. ... View more

Great article @Robert Levas ! For the completeness purpose, I'd like to see this information added to the above article: While mapping the Kerberos principals, if the Kerberos principal names are in the UPPER case or CaMeL case, they won't be recognized on the Linux machine (as Linux users are always in lower case). So you need to add the extra switch "/L" in the RULE definition to force the conversion to lower case. For example, here are some auth_to_local rule examples with lower case switch added: "RULE:[1:$1]/L" "RULE:[2:$1]/L" "RULE:[2:$1;$2](^.*;admin$)s/;admin$///L" "RULE:[2:$1;$2](^.*;guest$)s/;guest$//g/L" And based on these rules, here are the expected output for the following inputs: "JOE@FOO.COM" to "joe" "Joe/root@FOO.COM" to "joe" "Joe/admin@FOO.COM" to "joe" "Joe/guestguest@FOO.COM" to "joe" Hope this helps. ... View more

Thanks @Dale Bradman for updating here. Glad that it worked for you. ... View more

Hello @Dale Bradman The correct values in the advance-kms site should be: hadoop.kms.authentication.type=kerberos hadoop.kms.authentication.kerberos.keytab=/etc/security/keytabs/spnego.service.keytab hadoop.kms.authentication.kerberos.principal=* Also, the log messages in xa_portal.log doesn't look to be ERROR messages (they are INFO), so i believe that the root cause of error is somewhere above these lines. If they are not there, then I'd suggest you to enable debug logging for Ranger admin service and try the operation once again. How to enable debug logging for Ranger admin service STEP 1: On the Ranger admin host, edit the /usr/hdp/current/ranger-admin/ews/webapp/WEB-INF/log4j.xml file. STEP 2: Change "info" to "debug" as shown in the below configuration stanza: <category name="org.apache.ranger" additivity="false"> <priority value="debug" /> <appender-ref ref="xa_log_appender" /> </category> STEP 3: Save and Restart the Ranger admin service. ... View more