How to "kdestroy" user's ticket in FreeIPA

[#1]

We are trying out FreeIPA and integrated the same to our Ambari Hadoop cluster (HDP v3.0.1).

We are able to add users and provide them access to Hadoop with help of Kinit command.

However, when deleting the users in FreeIPA GUI, the principal gets deleted. The deleted user's principal will not be there in the "kadmin" prompt when I do listprincs.

But the user will still be having a valid ticket when he does "klist" and can access Hadoop even though the principal is removed. We cannot do "kdestory" manually. Typically, when users are removed in FreeIPA, the same users should not be able to access Hadoop as well.

Can't FreeIPA handle kdestroy?

Please provide your suggestions.

Thanks,

Shesh

[#2]

@Shesh Kumar

The MIT-specific 'kadmin' utility will not work with the IPA KDC. To manage users in an IPA KDC, you will need to use the IPA-specific client - 'ipa'. For example:

ipa user-add rlevas -principal rlevas@LOCAL.REALM --first Robert --last Levas --cn rlevas

And removing a user would be

ipa user-del rlevas

The kinit and kdestroy commands are like login and logout commands. They do not create or remove users in the KDC - MIT or IPA.

On top of this, once you use kinit to authenticate a user, a ticket cache is established for the user. This ticket cache will live even after you delete the account in the IPA KDC and klist will still show the cached data. However access to services using that ticket cache should fail as the KDC will not grant service tickets for that user. To remove the ticket cache, kdestroy must executed.

I hope this helps.

[#3]

Thanks for your suggestion. I really appreciate it. I have one more doubt.

So If I have to remove/delete multiple users in IPA...say like 50 users, I will also need to login the server as root, switch to their user and fire "kdestroy" to remove the ticket cache? Won't this be too much of manual effort? What is the best practice that you recommend?

[#4]

I don't think that you need to remove any of the ticket caches. They will become orphaned and also eventually time out. Even if the cache is valid, I do not think that any requests will be allowed at the service level since all ticket requests and validation checks go though the KDC. So if the KDC no longer knows about a principal, tickets will not be granted or validated.

I may need to test this to be certain that what I say is totally correct, but I believe that once the account in the KDC is removed the relevant principal will no longer be valid for authentication.

[#5]

Thank you so much Robert! Highly appreciate your views.

I've one more doubt which I came across. It is about auto-renew of Kerberos ticket.

As you know we have successfully integrated FreeIPA with Ambari cluster which also has IPA replication as well.

I noticed that user's kerberos ticket is not auto-renewing even though they have a valid ticket.

shesh.kumar@stg-ambarixenial001:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1193
Default principal: shesh.kumar@EXAMPLE.COM
Valid starting     Expires            Service principal
11/18/18 18:15:37  11/19/18 18:15:34  krbtgt/EXAMPLE.COM@EXAMPLE.COM
     renew until 11/25/18 18:15:34

As you can see above, the ticket is not auto-renewing. How can I make sure that kerberos ticket is auto-renewed once the user executes the "kinit" command.

Let me show you what I have done from my side. I've added these 3 lines in /etc/sssd/sssd.conf file which is present in FreeIPA server (which don't have Hadoop client).

krb5_lifetime = 120s 
krb5_renewable_lifetime = 150m 
krb5_renew_interval = 10s

Will this work?

Thanks,

Shesh Kumar