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
stuff,
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.
Thanks,
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@redhat.com
> https://listman.redhat.com/mailman/listinfo/pam-list
