pam_krb5 with PKINIT from Heimdal and MIT
Jeffrey Hutzelman
jhutz at cmu.edu
Fri Oct 13 15:07:09 EDT 2006
On Friday, October 13, 2006 01:38:13 PM -0500 "Douglas E. Engert"
<deengert at anl.gov> wrote:
> I understand that it can be done the other way. Its just that in most
> distributions its done with using the same authtok. Solaris 10 goes so far
> as to use pam_authtok.so to prompt for "Password:" before any of the
> individual modules do.
That's entirely configuration, and the default behavior is generally
appropriate for the default set of modules.
> It practice, even on non-Solaris systems, what the user sees is
> "Password:" and has no idea which password this is referring to
It's referring to whatever password the user types, which usually can be
for any of the password-centric PAM modules that are configured. If you
have a module that's not password-centric, then it need not prompt for a
password, and you probably should put such things before anything that
prompts for a password, if you expect to let users in without typing one.
> We have seen on some systems where Kerberos can be used, but the user uses
> the local password that the Kerberos is tried first, and the W2K3
> KDC logs a failure, and can turn off an account.
Put pam_unix first and you won't have that problem. Or, don't configure
your Kerberos PAM module with use_first_pass/try_first_pass -- at least
some modules already prompt with "Password for <principal>:", as do some
versions of kinit.
None of the PAM modules I know of that support smartcards conflate PIN's
with passwords. These modules never use the value of PAM_AUTHTOK as a PIN,
nor do they store a successful PIN in that item. To do otherwise would be
a bad move, as a smartcard PIN is unlikely to be the same as some other
password, and there are consequences to trying a wrong one.
Naturally, anyone who ships a default or pre-fabricated configuration
supporting these features will need to carefully consider how they interact
in order to get the right results with the best user experience. In many
cases, getting it right is going to require site-local knowledge.
-- Jeff
More information about the krbdev
mailing list