Will Fiveash wrote:
> That is the plan. This is also why pam_krb5 when doing PKINIT should be > stacked above pam_authtok_get to avoid pam_authtok_get's prompting for a > password inappropriately. Login is easy. Screen unlock is much harder. Make sure you plan will work with the actions the user must preform and in what order they are preformed and what is happening internally. User walks up to a screen saver on screen and moves the mouse or hit a key to see if its locked or not. screen saver calls PAM with logined in username. In current configurations, the first thing the user see is enter password. The user may or may have not inserted a smartcard yet. If you skip pam_authtok_get and use pam_krb5 first you may have started the process to see if a card is present. > >>>> Note that if pam_krb is stacked below pam_authtok_get it would function >>>> as it currently does which is to get the user's Kerberos credential >>>> using their long term Kerberos password. >>> That seems reasonable. >> No! With Russ's pam_krb5 if a null password is passed to pam_krb5, and >> try_pkinit if a card is present then it will try pkinit. In that case the >> prompt for a password is pased back via the pam_conv routines and callbacks. >> With OpenSC for example the prompt will have something like Enter PIN for >> (card label). >> (I don't have a pin-pad reader, to test with, but this method should work >> with it too.) The user just has to have the card in th reader before >> hitting enter for the user prompt. Russ's pam_krb5 also works with >> the xscreensaver and dtlogin. >> >> So an pam_authtok prompt could be something like: >> "Insert smartcard then enter user and enter null password" > > Be aware that the current OpenSolaris PAM framework typically relies on > the pam_authtok_get module to prompt for the password. Yea, and pam_authtok_get can accept a blank. (Solaris 10 can at least.) This blank is then passed along to other pam modules, The pam_krb5 can use it to indicate if it should try a password or attempt PKINIT. For testing on Solaris 10, I have used pam.conf sections like (The pam_smartcard.so.1 never worked so I commented it out): #dtlogin auth requisite pam_smartcard.so.1 dtlogin auth requisite pam_authtok_get.so.1 debug dtlogin auth required pam_dhkeys.so.1 dtlogin auth required pam_unix_cred.so.1 debug #dtlogin auth optional pam_krb5.so.1 dtlogin auth optional /krb5m/lib/security/pam_krb5.so debug try_pkinit try_first_pass minimum_uid=100 dtlogin auth required /krb5m/lib/security/pam_afs_session.so debug # allows password login dtlogin auth optional pam_unix_auth.so.1 debug # # xscreensaver used by gnome or CDE # xscreensaver auth requisite pam_authtok_get.so.1 #xscreensaver auth required pam_dhkeys.so.1 #xscreensaver auth optional pam_krb5.so.1 # use next with /krb5m. Above 1 with native xscreensaver auth optional /krb5m/lib/security/pam_krb5.so try_pkinit try_first_pass minimum_uid=100 #xscreensaver auth optional /krb5m/lib/security/pam_krb5.so try_pkinit minimum_uid=100 # xscreensaver auth required /krb5m/lib/security/pam_afs_session.so nopag # allows unlock with local password xscreensaver auth optional pam_unix_auth.so.1 # Thus is a password is null, pam_krb5 tries pkinit. If its not it tries norlam Kerberos password, and if root was trying to login, Russ's minimum_uid=100 does nothing with root, and pam_unix_auth will. The really problem is with the PAM framework. It does not give the user any choice as to how the user would like to try authenticaiton. It should be asking as the first prompt (a list or menu) like to use a smartcard for local or PKINIT login, local password Kerberos password, OTP password, (or whatever else is available maybe fingerprint of face recognition?) Pam would then route to the appropriate modules, rather then starting a sequence of optional/required modules that may treat this as a failed login attempt,which can lead to locked accounts. At least pam_authtok_get should have a prompt option to tell the user what to do next. > OpenSolaris > pam_krb5 must follow this module currently as it relies on it for the > password. This is the reason I'm suggesting that if pam_krb5 is stacked > above pam_authtok_get it would assume it should try PKINT only. Given > this I don't seen the need for another config parameter like try_pkinit. You might be able able to drop the try_pkinit but only if the some other method is available to tell the differenrce between a smartcard and some other crypto device supported below pkcs#11. > >>> I want to see an updated pam_krb5(5) man page explaining how to use PKINIT >>> and including the example PAM stacks for use of PKINIT. >> See Russ's pam_krb5.5 man page. > -- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
