My customer installed Recommended Patch cluster with Xscreensaver patch
included (115158-06) on their Solaris 9 box. After the installation,
they found out when user locks their session, 2 invalid password
attemtpts are sent to their LDAP Server.
Please see below cu's detailed informations against the issue:
==============================
Background.
We use Sun's Solaris 9 bundled Sun One Directory server (iDS5.1) as our
naming service. After applying patch 115158-06 whenever a user locks
their session, our LDAP server records 2 failed password attempts. We
are using the Gnome 2.0 desktop downloaded from Sun downloads.
According to this latest patch rev
4818344 xscreensaver doesn't use PAM correctly
I'm guessing that PAM support has been added to xscreensaver but I'm
unable to find documenation as to what needs added to pam.conf. This
issue occurs on SunRay and non-SunRay sessions so pam.conf entries for
both would be helpful.
List steps to reproduce the problem(if applicable): Apply patch
115158-06 to Solaris 9, login in to Gnome and lock the screen. Check the
LDAP entry for the user, passwordretrycount will be at 2.
==============================
The Network Engr who worked with the customer on ldap side found out the
cause of this problem to the ldap side. Here's what the Network Engr
told me:
** After the Patch Cluster installation, when ldap users (uid in ldap
database) login to Gnome and lock the screen, 2 failed passwd attempts
are logged to the ldap server (since this user is ldap uid). The problem
doesn't exists when logging into CDE. Sending 2 failed passwd attempts
to the ldap server will cause a problem because after 3 failed attemtps
they lock a user's passwd. So if they make a mistake to unlock their
screen it locks their passwd and they only get 1 attempt
(xserverscreenlock has alrady caused 2 fail attempts). Customer
says this happens on all GNONE 2.0 windows, does not matter if is sunray
or stand alone server.
xxxxx@xxxxx.com 2005-03-09 00:34:49 GMT
Work Around
Here's the temporary workaround from the Xserver Engr Mahmood Ali.
============================
Since there is no xscreensaver service module listed in pam.conf the
code falls to the "other" stack and ldap module is being picked up from
there. This is from looking at your pam.conf file listed at the end of
this email.
I think pam authentication is failing because xscreensaver at the moment
assumes that you are going to only enter your unix password and does not
prompt you for your ldap password, currently xscreensaver GUI is
hardwired to only assume user is going to enter username and password,
no other ECHO_OFF messages coming from pam are displayed, this is
obvious from pam interaction below that your customer provided (ldap
module is prompting the user for ldap password also, and the user never
sees that), hence a failure in authentication.
I believe if they list pam_ldap.so.1 to be optional, authentication may
succeed. So, have the customer add the following in their pam.conf file:
xscreensaver auth requisite pam_authtok_get.so.1
xscreensaver auth required pam_dhkeys.so.1
xscreensaver auth required pam_unix_cred.so.1
xscreensaver auth required pam_unix_auth.so.1
This will help in not locking the system if user mistypes a password,and
ldap retrycount locks the user out for good, but this is bypassing the
ldap authentication, for which we will deliver the fix very soon.
So, try to explain to the customer that ldap is working fine for initial
user login and other programs that need authentication, but just
xscreensaver cannot handle it at the moment and a fix is in progress,
and better if they bypass ldap only for xscreensaver for fear of users
mistyping their passwords and ldap locking them out for good.
===================================
BUt customer doesn't want to try this due to security issues. He would like to wait for the fix (either binary or patch).
xxxxx@xxxxx.com 2005-03-09 00:34:49 GMT