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