On 22/12/2011 18:02, Mariusz Kruk wrote:
W dniu 2011-12-22 17:01, Yann Autissier pisze:
I am using the libnss-ldap and libpam-ldap packages with default
configuration.
NSS is configured to allow passwd and group resolution over ldap.
user@host:~$ cat /etc/nsswitch.conf
passwd: compat ldap
group: compat ldap
shadow: compat ldap
If a user account exists in local /etc/passwd and in the ldap database,
the user can authenticate with both passwords, but is always logged in
as the local user.
It seems to me that nss should resolve the correct uid.
I'm not sure what you mean by 'the correct uid'. NSS is responsible only for
mapping from UID to name. And it does it in order specified in nsswitch.conf. So
if you want to see what name UID=12345 maps to, the system (in presented
configuration) first tries to look into /etc/passwd, then checks the ldap
database for entry with apropriate attribute with the value of 12345 (don't
remember ATM which attribute it is by default).
I think that NSS and PAM are working with username, and when authentication
succeeds in libpam-ldap, it returns success, then NSS resolves the username with
the first uid found in 'compat ldap'.
I can create a ldap account named 'root', with a weak password and uid
12345, then su - on the system and log in as root with the weak
password, and get uid 0.
It's not debian related, but I would like to know if this is a
misconfiguration.
Again, it has nothing to do with NSS. I suppose (sorry, don't have
a box with default config anywhere near) it can be caused by PAM stack
misconfiguration where pam tries to authenticate against local users database
and then, when it fails, tries again with the same password against LDAP. If you
did authentication the other way around - first checking in LDAP, and only then
in local file, you should be OK (remember about restricting UID range in
pam_ldap).
As I mentioned, I don't have a way to confirm this on a live box, so please
correct me if I'm wrong.
Swapping pam_unix and pam_ldap in /etc/pam.d/common-* does not seem to solve the
problem.
Swapping to 'passwd: ldap files' in /etc/nsswitch.conf reverse the problem, as I
cannot get uid=0 anymore.
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f022737.7020...@autissier.net
