Hi!

I'm working on a Debian Squeeze system that connects to a LDAP server
using libpam-ldapd and libnss-ldapd.

If I use GDM with an account like 1234h (in the LDAP server exist an
account called 1234H) we can't connect.

Login with the real username 1234H works without any problem.

Removing the following line in /etc/pam.d/gdm3 file:

auth required pam_succeed_if.so user != root quiet_success

And then I can connect with both usernames.

So, the only way that I found to allow case-insensitive usernames and deny
root login was use pam_listfile module instead of pam_succeed_if:

auth required pam_listfile.so item=user sense=deny file=/etc/users.deny
onerr=succeed quiet

Where /etc/users.deny has root username as content.

reassign 685783 libpam-modules 1.1.1-6.1+squeeze1
thanks

Le vendredi 24 août 2012 à 15:33 +0200, cosme@tegnix.com a écrit :

Well that would be a bug in pam_succeed_if.

Cheers,

Sorry for not responding to this bug sooner.

I've looked at this report, and I'm not sure I understand what you're
saying.  It appears that:

 - you have an account in LDAP with a username of 1234H
 - you are trying to log in with a username of 1234h
 - you are expecting this to succeed.

But why are you expecting this to succeed?  Unix usernames are
case-sensitive.  LDAP usernames are *not* case-sensitive, and as a result if
you are using an LDAP backend, queries for the Unix username *may* work in a
case-insensitive manner.  But pam_succeed_if doesn't care about this, it's
up to libnss-ldap to provide the desired results.  pam_succeed_if does
expect the username to be resolvable... if it's not resolvable, this is not
a bug in pam_succeed_if.

So, what is the full /etc/pam.d/gdm3 config that reproduces this bug, and
what errors are logged to syslog when it fails?

Well, pam_listfile happens to not call pam_modutil_getpwnam(), so doesn't
trip over the problem of the username not being resolvable.  But the root
issue would still be that the username is not resolvable.