Unable to unlock screen when using ldap

[Bavo]

After locking the screen, you are unable to unlock it again when using ldap authentication.

No errors, it just keeps saying wrong password.
Local users can unlock the screen, but only if /etc/libnss-ldap.conf /etc/pam_ldap.conf are readable for everyone, which i don't want since this files contain passwords to connect to the ldapserver.

[Bavo (bavo-t)]

Making /etc/ldap/ldap.conf also world readable fixes this problem.

But this still means that anyone can see the password to connect to the ldap-server.

Can't this be fixed by making gnome-screensaver use nscd or something. How does sudo and others take care of this?

[Daniel Holbach (dholbach)]

Thanks for the bug report. Somebody should forward this bug upstream.

[Miguel Cabrera (mfcabrera)]

Hi. I've set up a network that use ldap auth and it is working perfectly in Ubuntu Dapper/Edgy.
for the connection to the LDAP Server (OpenLDAP) the permission I user are:

-rw-r--r-- 1 root root 636 2006-07-28 09:36 /etc/ldap/ldap.conf
-rw-r--r-- 1 root root 9107 2006-07-28 09:36 /etc/libnss-ldap.conf
-rw-r--r-- 1 root root 9056 2006-07-28 09:37 /etc/pam_ldap.conf

But none of these have a password for connecting. The password is stored in
-rw------- 1 root root 15 2006-05-18 06:49 /etc/ldap.secret

I think this is not a bug but a misconfiguration.

[Miguel Cabrera (mfcabrera)]

Thanks for the bug report, but it's looks like it's a misconfiguration of the files you mentioned.

[Bavo (bavo-t)]

-rw------- 1 root root 15 2006-05-18 06:49 /etc/ldap.secret
is only useful if you are using the rootdn to connect to the ldapserver. I'm using another dn to bind to the ldapserver. The password for this user has to be set in the ldap.conf file.

what i have in my ldap.conf is
binddn cn=*****,o=itf,c=be
bindpw **************
and no rootbinddn entry

if someone can get the rootdn password for your ldap server you can get in serious trouble, so it is not a great idea to put it somewhere on the client computer (even when it's only readable for root)

Is it possible to reopen this bug?

[SoboL (sobol)]

I have encounter this problem as well.

I'm on Ubuntu Edgy 6.10, happens on my friend's desktop too.

Version:

ii gnome-screensaver 2.16.1-0ubuntu1
Pam:
/etc/pam.d/gnome-screensaver:
auth sufficient pam_unix.so

Even if i use local user still can't unlock screen, when permission to /etc/libnss-ldap.conf is +r for root only.

[SoboL (sobol)]

Forgot to mention that i can't use /etc/ldap.secret as I'm not authenticating in ldap as root ( security reasons ).

[Joe Baker (joebaker)]

I cannot unlock mine either.

Here's the configuration...

file /etc/pam.d/gnome-screensaver contains:
@include common-auth

These files have permissions of rw-r--r--
/etc/ldap/ldap.conf
/etc/libnss-ldap.conf
/etc/pam_ldap.conf

file /etc/ldap/ldap.conf contained:
BASE o=ultrapossum
HOST

I think this was setup by some ldap authentication utility.... I have modified the file to include settings for our server as such:
BASE dc=nelfc, dc=com
HOST ldap://192.168.0.201
#BASE o=ultrapossum
#HOST

... but alas, this didn't solve the problem either.

I'll look for sane values in the other pam/ldap files to see if I can find out what's going wrong here. I should also note that I am running an LTSP thin client session. Maybe I'll try this on the server itself. It's the ltsp-standalone-server as provided by Ubutnut 6.10.

Cheers till later!
-Joe Baker

[Joe Baker (joebaker)]

Same problem exists again in Feisty 7.04.

-Joe Baker

[Joe Baker (joebaker)]

/etc/pam.d/gnome-session
only contained:
@include common-auth

I've changed it to be as such:
#---------------------------
@include common-auth
@include common-account
@include common-session
@include common-password
#--------------------------

I used grep to identify other pam.d profiles in the directory to see which other profiles also included common-auth. These profiles also included common-auth and were the model for the change I'm trying out:

   ssh, kscreensaver, login, gdm, kcheckpasswd

I'll report back later on how this works.
Thanks.
-Joe Baker

[Joe Baker (joebaker)]

LDAP authenticated users still can't unlock the Gnome-Screensaver.
Adding the includes to /etc/pam.d/gnome-screensaver did not help.

This is an important issue for large scale deployments. Our deployment is small, but gnome-screensaver needs to work with out having access to any master password in the LDAP configuration file.

-Joe

[Emu (eziegler)]

The problem can also be due to encrypted connections to the LDAP server since the private key must be readable by root only. In older versions of ubuntu (at least Dapper Drake) the following commands fixed the problem:

    chmod +s /usr/lib/gnome-screensaver/gnome-screensaver-dialog
    chmod +s /usr/bin/kcheckpass

But due to the SUID/SGID bits possible security holes are opened.

Under Feisty Fawn even this does not work anymore! A connection of the screensavers to the LDAP server over nscd would (as suggested above) should be the best solution.

[Cesar Avalos (avaloscesar)]

Come on guys,
There is already a year this bug is open.
This problem is critical to corporation deployments.
I'm having the same problem with libnss-ldap + lipam-krb5 authentication under Feisty and Gutsy.
When gnome-screensaver lock up. It just show a black screen where you are unable to do nothing.

[Sebastien Bacher (seb128)]

Cesar, there is ten of thousands of bugs open and only a limited number of people working on those and only some with a ldap setup to confirm the issue. Maybe you could try to work on a patch or mail the ubuntu-devel list if you think that's an issue that should be considered this cycle

[Joe Baker (joebaker)]

Consider the issue confirmed.
This problem plagues other distributions as well.
Please just make some queries upstream with the Gnome developers on our
behalf.

Thanks
-Joe Baker

Sebastien Bacher wrote:
> Cesar, there is ten of thousands of bugs open and only a limited number
> of people working on those and only some with a ldap setup to confirm
> the issue. Maybe you could try to work on a patch or mail the ubuntu-
> devel list if you think that's an issue that should be considered this
> cycle
>
>

[lcars (andrea-inversepath)]

This also affects setups where with TLS certificate validation (client and server), nscd is used as a 'proxy' and no certificates are readable to the users (not even per-user .ldaprc). The only solution would be having a gnome-screensaver master process which validates passwords as root (could be ugly and undoable) or using a pam module that wraps using a suid app (like pam_unix does with check_unixpwd but only for ldap, since pam_ldap runs as the invoking user..and rightly so).

So this is a very specific scenario that needs some code love, and yes as pointed out every distribution is affected as well.

[saulors (saulor)]

the same here with ubuntu 7.10

Does someone has tryied any tried any trick??

can I change gnome-screensaver by xscreensaver?? does it fix the problem??

Thanks

[MattPie (piechota)]

Problem still exists in Hardy 8.04-Release. Sigh. Note that this is a basic LDAP server, with no SSL/TLS or password required to access the server. I really like Ubuntu, but this seems like Enterprise Computing 101...

RHEL5/CentOS5 has a patch in their SRPM named 'better-pam-integration' (attached) and LDAP+Gnome-screensaver works. I'll look into it, but the patch is for g-ss 2.16.1, so I'm not sure how compatible it'll be with 2.22.2 that Ubuntu is using.

[MattPie (piechota)]

The patch above didn't go smoothly, and I can't justify working more on it during work time. :)

But I've found a workaround:
If you add 'auth sufficient pam_ldap.so' to the BEGINNING on /etc/pam.d/gnome-screensaver, gnome-screensaver unlocks properly for LDAP users. BUT, there's an odd effect on local users. If you're logged in as a local user and screen locks, you have to enter your password twice*. The first time, it'll go to 'checking...' but it doesn't gray-out the text box. Type you password in again and hit enter and the screen will unlock. Note that I'm not expert in PAM, but I don't think this will leave gaping holes in your system.

* I forgot to test if you could just hit return or enter garbage for the first entry, I suspect you can.

[Emu (eziegler)]

The problem with the two password requests can be solved by adding 'use_first_pass' to the line with pam_unix.so, such that it looks like
    auth sufficient pam_ldap.so
    auth required pam_unix.so nullok_secure use_first_pass

However, this does not solve the problem when the LDAP connection is encrypted and the certificate can only be read by root. Also in Hardy gnome-screensaver does not seem to communicate with the NSCD, but tries to call the LDAP server directly.

I still don't get why the workaround setting gnome-screensaver-dialog SUID doesn't work anymore. In that case pam_ldap should run with root rights. Has anyone more insight on the authentication mechanism? Maybe gnome-screensaver-dialog calls another program to do the actual verification in newer versions...

[Stefan Kohlsmann (mail-dcop)]

Got same problem here and I solved it, by copy / linking:

ln -s /etc/ldap.conf /etc/libnss-ldap.conf
and
ln -s /etc/ldap.conf /etc/pam_ldap.conf

For me, I copy the /etc/libnss-ldap.conf + /etc/pam_ldap.conf from an old System, so I cant compare if these links are right, but the content of the three files ldap.conf, libnss-ldap.conf and pam_ldap.conf here the same.

[pacesie (ne-pacesie)]

I also has this problem on kubuntu from edgy to hardy with dell 630 laptop. I do not use LDAP at all, this problem is just there after I install kubuntu. I cannot login back after locking a session.

[zjohnson (zjohnson)]

I am having a problem like this with gnome-screensaver and libnss-mysql-bg under Hardy Heron, but I am not sure if it is the same problem.

Users with an entry in /etc/shadow can unlock just fine, but any user who is authenticated via libnssmysql fails. However they can log in and still have thier session back if they pick switch user and login with the same username and password.

My /var/log/auth.log reports this when I try to unlock gnome-screensaver with libnss-mysql-bg:

Nov 13 17:09:38 p70 unix_chkpwd[6072]: check pass; user unknown
Nov 13 17:09:38 p70 unix_chkpwd[6072]: password check failed for user (sa)
Nov 13 17:09:38 p70 gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): authentication failure; logname= uid=3282 euid=3282 tty=:0.0 ruser= rhost= user=sa

some file contents and permissions:

root@digit:/etc/pam.d# cat gnome-screensaver
@include common-auth
auth optional pam_gnome_keyring.so

root@digit:/etc/pam.d# ls -Fal /usr/lib/gnome-screensaver/gnome-screensaver-dialog
-rwsr-sr-x 1 root root 56464 2008-11-13 15:33 /usr/lib/gnome-screensaver/gnome-screensaver-dialog*

root@digit:/etc/pam.d# ls -Fald /sbin/unix_chkpwd
-rwxr-sr-x 1 root shadow 19584 2008-05-16 08:21 /sbin/unix_chkpwd*

root@digit:/etc/pam.d# ls -Fald /etc/shadow
-rw-r----- 1 root shadow 993 2008-09-19 13:49 /etc/shadow

root@digit:/etc/pam.d# ls -Fald /etc/libnss-mysql.cfg
-rw-r--r-- 1 root root 2386 2006-09-20 10:47 /etc/libnss-mysql.cfg

root@digit:/etc/pam.d# ls -Fald /etc/libnss-mysql-root.cfg
-rw-r----- 1 root shadow 77 2006-09-13 14:22 /etc/libnss-mysql-root.cfg

[zjohnson (zjohnson)]

Actually doing this works, but I would prefer to not have to do it:

root@digit:/etc/pam.d# chmod u+s /sbin/unix_chkpwd
root@digit:/etc/pam.d# ls -Fald /sbin/unix_chkpwd
-rwsr-sr-x 1 root shadow 19584 2008-05-16 08:21 /sbin/unix_chkpwd*

Not really sure why this is required. No files set up by the libnss-mysql-bg package are root only except /etc/libnss-mysql-root.cfg which I set to be group shadow to match /sbin/unix_chkpwd.

[Ro (robert-markula)]

The same bug can be observed with karmic. Any solution yet?

[Thilo Mende (ubuntu-thilomende)]

We have this bug with Lucid as well. The proposed solutions (linking /etc/ldap.conf or modifying /etc/pam.d/gnome-screensaver) do not help.

[Emu (email-eziegler)]

SOLVED in Ubuntu Lucid: use 'libnss-ldapd' and 'libpam-ldapd' (note the 'd' at the end of the packages) together with with the 'nslcd' package (note the 'l' in the middle)

This allows to set the user and group with which the 'nslcd' daemon runs in '/etc/nslcd.conf'. I set the group from 'nslcd' to 'ssl-cert' and made sure that the key file can be read for that group.

my '/etc/nslcd.conf' reads as follows:

# /etc/nslcd.conf
# nslcd configuration file. See nslcd.conf(5)
# for details.

# The user and group nslcd should run as.
uid nslcd
gid ssl-cert

# The location at which the LDAP server(s) should be reachable.
uri ldap://<put server address here>

# The search base that will be used for all queries.
base <put LDAP base here>

# The LDAP protocol version to use.
ldap_version 3

# SSL options
ssl start_tls
tls_reqcert demand
tls_cacertfile /etc/ssl/certs/ca-local.cert.pem
tls_cert /etc/ssl/certs/client.cert.pem
tls_key /etc/ssl/private/client.key.pem

[Thilo Mende (ubuntu-thilomende)]

Problem solved for me as well. It was in fact a permission problem: all the ldap-files were world-readable, except the certificate. After changing that to o+r, everything works fine.

[Emu (email-eziegler)]

The point is that the certificate key should *never* be world readable for security reasons. Otherwise you might as well not use encryption at all as any user on your system can access it. That's the whole reason for the nscl/nslcd concept. Better use the solution I posted above.

Some explanations for those who are interested (they might not be accurate as I'm not aware of how things are implemented, but they make sense to me):

The PAM modules are configured as dynamically linkable libraries. Since your gnome-screensaver runs with your own user rights, all libraries linked into it run with user rights as well. So when gnome-screensaver tries to connect to the LDAP server via PAM it cannot read the certificate key and fails to connect resulting in a rejected password.

One solution would be to allow all users to read the key, but that's a giant security hole as mentioned above. Another solution would be to set the SUID bit of the gneome-screensaver dialog so it runs with root rights no matter which user started it (doesn't work anymore for some time, my guess is that the program checks if it runs with root rights and fails to prevent users gaining root rights using buffer overflows or other bugs in the program). This worked for the KDE screensaver though.

That's the reason why the nscd was so important with the old systems. Instead of invoking the PAM modules directly most programs would do authentication via nscd which runs as root and thus can connect to the LDAP server. However, gnome-screensaver never did :(

The new packages introduce nslcd which does not need to be addressed by gnome-screensaver as the PAM modules communicate with it automatically. It also doesn't run with root rights unless explicitly set (which is not necessary), but sufficient rights to read the key file. Therfore it allows to keep the certificate key closed without the risk of someone abusing it to gain root rights.

[Thilo Mende (ubuntu-thilomende)]

Could you point out why a world-readable certificate is a problem? From my understanding,
it is used to verify the identity of the server, and is thus public (as any certificate e.g. used for
https)

[Emu (email-eziegler)]

Sorry for the confusion. We need to distinguish three files:
    - the CA certificate (world-readable) is used to verify the identity of the server to the client
    - the client certificate (world-readable) is used to verify the identity of the client to the server
    - the private key (readable to root and nslcd only) is also needed to verify the identity of the client to the server as well as encrypting the communication

As long as it is just the CA and client certificates that are world-readable there is no problem at all. I'm just talking about the private key file. I assumed that you were referring to the private key as well as I don't see how it could work otherwise without using the nslcd daemon. If the key is not world-readable, there is no problem at all.

[Sebastien Bacher (seb128)]

not sure the issue is really a gnome-screensaver one, in any case the patch there needs work so unsubcribing the review team and tagging the patch as needswork

[Brian (genkuro)]

@Emu Thanks for an excellent description and fix.

[Larry Mancinelli (larry-mancinelli)]

Sorry to awaken such an old thread, but in case anyone is still having problems with this, I was able to get it working perfectly in my environment. I was experiencing the original issue and I tried the MattPie/Emu solution from posts #20/21, but I was still receiving two password prompts for local users. I ended up taking their suggestions and coming up with this:

I did not have to change anything in /etc/pam.d/gnome-screensaver. Instead, I made the first two lines in /etc/pam.d/common-auth file read as follows:

auth [success=2 default=ignore] pam_ldap.so
auth [success=1 default=ignore] pam_unix.so nullok_secure use_first_pass

Using this configuration, both local users and ldap users can log into the desktop AND unlock the screensaver by entering their password only once. I cannot speak to how well this works with an encrypted ldap setup.

[Larry Mancinelli (larry-mancinelli)]

Nevermind. I realized that ldap.conf was world readable, which I don't want. Back to the drawing board.