Hello all,
I reply to my own email, since I've done something new to solve my problem.
> I've written two PAM authentication modules for Solaris 7 that implements
> S/key. The first one checks /etc/skey.access in order to know if S/key
> is mandatory for the current connexion and the second performs the S/key
> authentication. I use the PAM stacking feature the following way (taken
> from /etc/pam.conf) :
>
> login auth sufficient /usr/lib/security/pam_my_skey.so
> login auth requisite /usr/lib/security/pam_my_skey_access.so
> login auth required /usr/lib/security/pam_unix.so.1 debug try_first_pass
>
> This parts seems to work as expected. For example, if you come from a
> trusted network, as stated in skey.access, you can choose between normal
> and S/Key auth, an S/key challenge being sent in all cases.
>
> Now let's see what wrong. After a succesful 'auth' phase, PAM enters the
> 'account' phase, which is normally done with pam_unix.so under Solaris. In case
> a user succesfully authenticates through S/key and his/her standard password
> has expired, he/she will be asked for a new one before accessing the shell.
> Obviously this is bad since we don't want a reusable password to be sent on the
> wire. Even worse, the same thing happens if the account is locked ('*LK*' in
> the password field of /etc/shadow) and the password considered expired. In this
> particular case, the user won't log in.
>
> I considered recoding an 'account' module to replace Sun's pam_unix but I see
> some problems with this approach :
>
> - I don't have the source of Sun's pam_unix so I'm afraid to forget something
> that should be there.
> - How to deal with connections that allow both normal auth and S/key ? I think
> I cannot just say : "let's ignore those expiration fields". The fact is that
> I dont know which authentication scheme has been used in the 'auth' phase when
> I'm in the 'account' phase.
> - more to come ?
RTFM'ing one more time, I noticed the pam_set_data() and pam_get_data() functions
and I decided to use them the following way : if we're authenticating with S/Key,
then use pam_set_data to record that fact, else don't. I then wrote an 'account'
module that checks if this data is present and if so bypasses traditionnal password
expiration checking, if not the module returns PAM_IGNORE. I use the module as
follows :
other account sufficient /usr/lib/security/pam_my_skey_acct.so
other account required /usr/lib/security/pam_unix.so.1 debug
Can you please be kind enough to tell me if this approach looks valuable to you
PAM specialists and security experts ? May I request a peer review of my code
that I would either send to the list or put somewhere online ?
Many thanks in advance, hoping I'm not wasting your time.
Have a pleasant day.
--
David
