On Oct 12, 2010, at 12:06, Phillip Moore wrote: > Then I extract the keytab file for use in the test suite using: > > ktadd -k /path/to/$principal.keytab $principal > > I've discovered that as soon as I run ktadd, then I can no longer manually > authenticate as that principal anymore.
Yes, that's correct; ktadd changes the key and gives you the new one. That's intentional, the idea being that no one should be able to extract a key from the database while it's already in use by a service, because that would allow the extractor to either impersonate the service, or impersonate anyone *to* the service. By forcing the key change, the latter is prevented; the real service will be visibly broken, hopefully catching an administrator's attention. If you really want to get the current key out, in the general case, you need to run kadmin.local on the KDC itself and use "ktadd -norandkey" (with a sufficiently recent release -- I'm not sure when the option went in). Since you're using known passwords, though, you could just update the keytab file directly with ktutil instead. Ken ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
