Greg Hudson wrote: > > Martin Rex wrote: > > > > I've tried everything I can reasonably think of, but kinit -k > > always fails with the non-sensical error message > > "kinit: Key table entry not found while getting initial credentials" > > You can probably get a better picture of the problem by setting the > environment variable KRB5_TRACE to a filename (or just /dev/stdout) for > the kinit command.
Thanks -- KRB5_TRACE ... and there was light! (I really had expected "-V" to do what KRB5_TRACE does, or a strong hint to KRB5_TRACE on "kinit -h" output.) > > This error message ought to name the principal it didn't find, but for > complicated reasons the more specific message gets lost in > some (common) configurations. (Beware: I know very little about KDC interals and lower level Kerberos protocol, so some of my conclusions may be wrong). Douglas is correct that W2K8R2-AD uses aes256-cts (while W2K3-AD uses rc4-hmac), I would have expected that by using Microsoft KTPASS.EXE with an explict "-crypt RC5-HMAC-NT" parameter that I would force one specific key+etype into the KDB (and nothing else), but KRB5_TRACE for kinit says that W2K8-AD sticks to aes256-cts no matter what. (btw. I'm using KTPASS.EXE from&on W2K8R2 PDC). Using KTPASS.EXE "/SETPASS /PASS *" produces keytabs that will not work (dunno why) for both enctypes HMAC-RC4 and AES256. Using only "+rndpass" with AES256 works, HMAC-RC4 don't work either. Can I somehow force the Account to use an rc4-hmac key exclusively, or will I have to fill the keytab with entries for every possible enctype for interop with XP/2003 _and_ Vista/Win7 clients -- or is the enctype of the server principal irrelevant to the clients that want to authenticate to that service? Also there seems to be a problem with the SALT, which seem to make KTPASS.EXE fail for principal names that are not SPNs (do not contain a forward slash). The salt value appears to be something stores seperately on the KDC/AD, because it is created by KTPASS.EXE on the windows machine and appears in plaintext of the kinit KRB5_TRACE on the linux machine. KTPASS.EXE seems to set the salt (and only then use it correctly) when it succeeds setting the SPN in its operation, and fails otherwise (and always fails with slash-less principals). The (k)vno==0 shown by kinit -k KRB5_TRACE confuses me, it always traces "keytab (vno 0, enctype aes256-cts)", even when it succeeds and finds the key, though the keytab only contains a key with kvno 17 (at the moment). I think I can wiggle through the MIT Kerberos part of the puzzle with KRB5_TRACE infos, but I'm heavily confused on Microsoft side of the game (KTPASS.EXE/W2K8-AD). If someone happens to have URLs into enlightening Microsoft Online Docs or KBs, that would be great. -Martin ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
