asetkey should get this functionality inboard. you want to do it or should
i?
On Sat, 13 Jan 2007, Marcus Watts wrote:
After seeing the recent spate of people having trouble
with keytabs (I think mostly from AD) and openafs, I decided
to write a "verify keytab" utility. My intent is to do "more or less"
what I had suggested doing by hand (kinit + kvno + perl hack) but
all in one C program that (eventually) we can just tell people to
go run. So here's what I have (so far):
adogslife$ ./verifykt -k /tmp/afs.kt
Success; princ=<[EMAIL PROTECTED]> vno=3 req.etype=1 ans.etype=1
ticket.length = 160
adogslife$ ./verifykt -k /tmp/bad.kt
Failed in krb5_get_init_creds_keytab - error -1765328353 (Decrypt
integrity check failed)
adogslife$ ./verifykt -k /tmp/ltl-3.keytab
Success; princ=<afs-k5/[EMAIL PROTECTED]> vno=3 req.etype=18
ans.etype=18 ticket.length = 213
Success; princ=<afs-k5/[EMAIL PROTECTED]> vno=3 req.etype=17
ans.etype=18 ticket.length = 197
Success; princ=<afs-k5/[EMAIL PROTECTED]> vno=3 req.etype=16
ans.etype=18 ticket.length = 205
Success; princ=<afs-k5/[EMAIL PROTECTED]> vno=3 req.etype=1
ans.etype=18 ticket.length = 189
adogslife$
It's not obvious from this, but the above utility is going just
a bit farther than "kvno" - it's actually decoding/decrypting
the ticket. Turns out the ticket is always encrypted under
the "strongest" (probably the first) key type found and there's
no way to make MIT (at least) do different. Also, if there are
old kvno's in the keytab, there's no way to check those.
On the bright side, it would be silly to accept tickets that
aren't the strongest possible, if the kdc can't generate them.
That means changing rxk5 & verifykt a bit to enforce/check that.
I think the quality of what I can do here is going to depend
a bit on the kerberos library. The MIT folks seem bound & determined
not to provide interfaces like the above uses that would allow
"non-standard" access to things. The best thing I can do with MIT
is mk_req/rd_req, which seems a bit silly. I really like the idea
of having the decrypted but not yet decoded ticket available in this
program.
Anyways, I'm certainly interested in what people think.
-Marcus
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
