[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PAM, S/key, Solaris, and password expiration

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []