PAM, S/key, Solaris, and password expiration

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

 



Hello all,

I first sent this message while not a subscriber and I received an email stating
that it was subimtted to the moderator's approval and that I should subscribe
and resend it. So I've just subscribed and I hope the moderator won't waste his
precious time on my first message.

I hope this is the right place to ask my question, please tell me if it's not.
Now on to the actual payload of this email...

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 ?

Have you already faced such issues ? Can you please give me some piece of
advice on this problem ? That would be very helpful to me.

Many thanks in advance and sorry for my poor English.

--
David





[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux