On Thu, 2012-03-01 at 14:38 +0000, John Hodrien wrote:
On Thu, 1 Mar 2012, Ondrej Valousek wrote:
> Got it finally working by re-creating /etc/krb5.keytab file from the scratch.
> It turned out, that I did not use Samba to join the machine to AD, but I used
> There is nothing wrong with that, the only thing is, that unlike Samba &
> SSSD, Centrify does refresh principals in /etc/krb5.keytab creating multiple
> principals in keytab that differ only by the KVNO number.
> This is nice, but both sshd & pam_krb5.so seem to totally ignore KVNOs,
> picking the first principal they find in keytab.
Why would you want to collect the old credentials? Aren't the credentials
with the lower KVNOs obsolete?
No, they are not until all clients have obtained new tickets.
If you immediately remove a key upon refresh, all clients that have
acquire a ticket against the old key and have it still valid (validity
depends on local KDC configuration but may be 24h or even days) they
will just fail to connect to a service if said service does not have
access to the previous key.
The problem is compounded by the fact you have no way to tell the
clients that you got new keys, so client simply error out. The user is
required to do destroy his credentials and obtain new ones and then go
fetch new tickets for the service.
Old kvnos can be rotated away once the Realm specific limits on
credential expiration are reached so that it is technically impossible
to have around valid tickets obtained against the old key.
> So I am going to file RH bugzilla report
Mmm, sounds like it might be worthwhile.
Yes those tools should support cases where a keytab has keys with
different kvnos and use the highest one they can find. So a bugzilla is
Simo Sorce * Red Hat, Inc * New York