When I log in as user1 and then tries to ksu to user2, the cache is owned by
user1! user2 has no access at all, even no read access! The cache file is not
on the normal form /tmp/krb5cc_uid, instead it is /tmp/krb5cc_uid.1 (an integer
is appended)
I'm using NFS4 Kerberos and both are working
One more thing, I had to go back to su and it works correctly. I can
successfully su to a different user and access the new home directory
without any problems but I'm keen to use ksu as all services on my
cluster have been moved to Kerberos. To clarify, to be able to access the home
directory,
Richard E. Silverman wrote:
A couple of questions:
1) What are the tkt and skey types on the tickets the client gets? The
etype of the service credentials?
klist -e reports:
Etype (skey, tkt): DES cbc mode with RSA-MD5, ArcFour with HMAC/md5
for the TGT. The keytab lists the key
Douglas E. Engert wrote:
Richard Silverman asked how did you add the principals to AD?
If you used the same AD account for both principals, they will use the
same password to generate the key, and will use the same kvno.
Thus your first problem might be the kvno is not found, in the keytab.
Coy Hile [EMAIL PROTECTED] wrote:
If we need to test, for example, that a user is actually getting a
TGT, we need to inform the user that we're changing their password
temporarily, change it, authenticate as them directly, and then have
them change it back. We've all been wondering aloud
