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

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

Hello david:

You are not wasting anybody's time.

The fact that I sit in front of a computer takes all the blame
for that.

But on serious side, since you seem to heavilly involved in this PAM
maybe you would know the answer to a simple question.

How would you write /etc/pam.conf so that it forces a password at login
and that password is NOT MD5 encoded in /etc/shadow but stored as plain
text in /etc/passwd.

I have created a ramdisk version of linux and wanted to put a very
minimal PAM operation
in place instead of pam_permit.so for all my authentication.


Mark Diener

dplist@free.fr wrote:
> 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
> _______________________________________________
> Pam-list mailing list
> Pam-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/pam-list

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