question about krb5_verify_init_creds() and verify_ap_req_nofail
will.fiveash at oracle.com
Tue Jan 11 19:15:41 EST 2011
On Tue, Jan 11, 2011 at 06:51:18PM -0500, Sam Hartman wrote:
> >>>>> "Will" == Will Fiveash <will.fiveash at oracle.com> writes:
> Will> On Tue, Jan 11, 2011 at 04:20:45PM -0500, Sam Hartman wrote:
> >> Really? I't expect krb5_kt_default() to succeed if the keytab
> >> does not exist.
> Will> My bad, you are correct that krb5_kt_default() will succeed
> Will> without a keytab existing.
> Will> Still, why try checking the keytab if verify_ap_req_nofail is
> Will> set to false?
> [I'm not sure why setting nofail to true causes the code to fail; I'd
> expect nofail = true would decrease failures.]
> This is the designed behavior of the code. The reason that verify_creds
> does not always fail is that some machines are not keyed. To provide a
> secure environment, you want the ability to assert that all your
> machines will be keyed in a configuration file.
I have no problem with a default of verifying a TGT/init_cred.
> However, if a key is present, it provides better security (and defense
> against an important attack) to use it. If the key is bogus, the
> administrator should delete it.
OK, that is what I wanted to confirm (always checking for a service key
in the keytab and using it if found regardless of verify_ap_req_nofail's
setting). I understand your point (and hope that the error message set
when krb5_verify_init_creds() fails because of a bogus service key
provides a good hint to the admin as to the problem).
> We could create a option to ignore the keytab in this case, although I'd
> call that option
verify_ap_req_nofail runs a close second in the awkward option name
contest (which a google search will confirm). 8^)
> Given those semantics I don't support actually creating that option.
Sent using mutt, a sweet, text based e-mail app <http://www.mutt.org/>
More information about the krbdev