I have configured my RHEL linux machine to be authenticated against active directory without being joining it to domain, using nss-pam-ldapd pam_ldap samba-winbind openldap-devel krb5-devel.
I am able to login on linux machines using active directory accounts, but I am not sure if the kerberos is being used during authentication, because I dont see the TGT in linux machine's local cache, but when I use "kinit username" and then check with klist I do see the TGT.
I am little confused, on how to confirm if the kerberos is being used or not.

Thanks,
Subodh.

if kinit and klist are working and you see tgt, it means kerberod is working. creste a new test account and try to authenticate, if it is successful that will be another check kerberos been used.

1 members found this post helpful.

Hi, thanks, I checked with tcpdump command while logging into it with domain account from another console and I do see traffic on Kerberos port 88, so I think this confirms that its using Kerberos during authentication.

Did you remember to get a host ticket for local authentication use? Without it, Kerberos logins can't work, but kinit and such will work - after logging in. The reason it is needed is that it cannot authenticate the KDC without one.

1 members found this post helpful.

Hi thanks, yes ideally Linux box should have a ticket in its cache, after logging in with domain account, I don't see any ticket in local cache when I check with klist command.
But when I checked with "tcpdump -I eth1 port 88", I get below response.
16:16:11.668583 IP MyLinuxBox.46509 > MyWindowsDomainController.kerberos: v5
16:16:11.669810 IP MyWindowsDomainController.kerberos > MyLinuxBox.46509:
so I was thinking how is it happening.

It is possible if you have a keytab, AND the login process is not configured to save the TGT.

The way the login is supposed to work is that the users ticket is just a byproduct. It isn't the goal.

A kerberos login works by:

0. get the users login identity (and sometimes principle name - otherwise use the login identity)
1. Asking for a TGT from the KDC (which requires the users password to decrypt).
2. Getting a service ticket for the local machine
3. Decrypting the service ticket using the host keytab
4. if steps 1-3 succeed setup the users session
5. save credentials

The users TGT (and the cache) are the byproduct of step 1. It requires code to save the ticket (it is stored in a memory resident cache for use in all three steps). Only after step 3 is completed (and the user account is set up) can the users credentials be copied to a user accessible cache. Step 5 is optional.

At this point it depends on the utility you are using to login (it may not allow saving), and the /etc/krb5.conf file:

http://www.eyrie.org/~eagle/software.../pam-krb5.html

I'm assuming you are using PAM for the login. Some systems (such as RH and RH derived systems) put the users cache in odd places (/run/user/<uid>/...) so things have to be compiled appropriately, and the users KRB5CCNAME has to be set by PAM. (see the reference file for how to retain cache entries...)