This is a discussion on Re: How to prevent hosts (clients) with no keytab from obtainingtickets - Kerberos ; On Nov 28, 2007, at 13:33, Steven Miller wrote: > I've set verify_ap_req_nofail in krb5.conf and hosts > without a keytab can still connect and obtain tickets. > Am I misunderstanding what this option does? It has nothing to do ...
On Nov 28, 2007, at 13:33, Steven Miller wrote:
> I've set verify_ap_req_nofail in krb5.conf and hosts
> without a keytab can still connect and obtain tickets.
> Am I misunderstanding what this option does?
It has nothing to do with getting tickets, as such, but figuring out
whether to trust them.
An attacker on the net can send a fake KDC reply encrypted using a
password known to an attacker sitting at the keyboard -- and here I
don't mean "keyboard" literally; it could be a remote login attempt,
if a password prompt is given -- and decrypting it proves nothing
about the validity of the KDC, it only proves that the supposed KDC
and the user getting the password challenge both know the same
password. Successfully running "kinit" means about as much security-
wise as creating a file /tmp/krb5cc_12345 with some random junk in
it, unless you've got some exceptional circumstances, like maybe a
local KDC and no active network interface.
The verify_init_creds routine attempts to figure out if the tickets
are from a legitimate KDC, by using them to authenticate to the local
"host" service (with an "ap_req" message), and using a local keytab
to decrypt them; if it succeeds, the user has authenticated via the
real KDC, and if it fails, something went wrong. That could be an
attack, or a network problem in the second exchange, or a missing
keytab file on a misconfigured server, or perhaps other issues.
In some environments (like MIT's Athena, and perhaps your
environment), many random client workstations are set up without
keytab files (and without any interesting local secrets to protect,
like users' files or email, which are all accessed through an
authenticated network service) and without remote login access, so
the login password prompt is more about automatically setting up the
user's single-sign-on access, and maybe presenting a small barrier to
someone walking in off the street, than trying to protect an
unprivileged computer with no interesting secrets that the supposed
attacker already has physical access to. (The pros and cons of such
an environment, and the threat models that permit or prohibit such
things, can be debated elsewhere.) So the verify_ap_req_nofail
option (which can be overridden in the application, if desired) lets
you specify whether the keytab entry not existing (presumably because
the machine isn't configured for one, and not because the service is
registered but the keytab is missing or corrupted) should be
considered an error or not.
Note that programs like kinit, which don't give any privileges the
user doesn't already have, have no reason to use verify_init_creds
(and, without root access to read the keytab, can't use it properly
anyways). And of course random network services that get sent
credentials from the client always do their verification using
keytabs. It's only in programs that ask for passwords *and* give
some kind of access (like allowing logins on machines with state to
be protected) that need to make these sorts of checks.