LinuxQuestions.org - LDAP login weirdness

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - LDAP login weirdness (https://www.linuxquestions.org/questions/linux-security-4/ldap-login-weirdness-766599/)

LDAP login weirdness

I've got LDAP authentication working fine under CentOS 5.4 - users can log in, a home directory is created. But when they log in, they get this:

Quote:

> ssh user.name@testserver
user.name's password:
Creating directory '/home/user.name'.
id: cannot find name for user ID 1009
id: cannot find name for user ID 1009
[I have no name!@testserver ~]$

Running "getent passwd" as the user turns up nothing. Also, the user's home directory has the wrong group ID:

Quote:

drwxr-xr-x 2 user.name splunk 4096 Nov 3 13:34 user.name/

The LDAP server is configured to allow anonymous reads. Here's my slapd.conf:

Quote:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/sudo.schema

allow bind_v2

pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args

TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /etc/openldap/cacerts/ca-cert.pem
TLSCertificateFile /etc/openldap/cacerts/server-cert.pem
TLSCertificateKeyFile /etc/openldap/cacerts/server-key.pem
TLSVerifyClient never

access to *
by dn="cn=Manager,dc=domain,dc=com" write
by self write
by * read

database bdb
suffix "dc=domain,dc=com"
rootdn "cn=Manager,dc=domain,dc=com"
rootpw {SSHA}xxxx
directory /var/lib/openldap-data
index objectClass eq

Users are restricted from logging in based on /etc/security/access.conf entries by group. The user is a member of the right group:

Quote:

# getent group | grep user
dev-web:*:1506:user.name

and the "splunk" group is 506 in the /etc/group file.

All I can find on the error implies it's either a permissions problem on the passwd or group files, which doesn't apply, or anonymous reads must be enabled, which are.

The strange thing is that my user account that can log in fine, which is a member of wheel and also has an ssh key. Not sure if that's relevant.

What does your /etc/nsswitch.conf contain?

So command "id" works for some LDAP users but not all?

Quote:

Originally Posted by twk (Post 3743700)

What does your /etc/nsswitch.conf contain?

Quote:

passwd: files ldap
shadow: files ldap
group: files ldap

hosts: files dns

bootparams: nisplus [NOTFOUND=return] files

ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files

netgroup: files ldap

publickey: nisplus

automount: files ldap
aliases: files nisplus

On a side note I figured out the group stuff, the gid in LDAP was wrong.

Still having issues though!

Quote:

Originally Posted by fantasygoat (Post 3743253)

I have no name!@testserver

If I remember correctly, that is caused by /etc/libnss-ldap.conf being readable by root only.
Changing the permissions should solve the problem.
Instead running nscd works too, I believe.

I'd rather not have to run nscd, and the file /etc/libnss-ldap.conf doesn't exist on the boxes.

This is on CentOS 5.4.

Maybe it's named or located differently? Or don't you have libnss-ldap on CentOS at all? (What is the replacement?)

If you want to look for the file, try greping e.g. for "nss_connect_policy".

nss_ldap is configured from /etc/ldap.conf I believe.

The funny thing is, on a fresh box, my config works perfectly and all uids and gids are visible. On the installed boxes, I get the uid issue.

Perhaps I should define a binddn? If so, where in LDAP should I put it?

Out of desperation I tried starting nscd, and doing so causes all logins to fail - it doesn't appear to try LDAP at all. Stopping it returns the behavior to "normal" whereby nss_ldap seems to be unable to make anonymous binds.

Another update. Removing TLS makes it work. So now I have to figure out what's wrong with my certificates.

I now have this working on one server, but not another. I have no idea what the difference is - ldap.conf, nsswitch.conf and pam.d/system-auth are identical. The security certificates are the same and pass openssl checks. But, when I log into one machine it can't get usernames:

Quote:

jwilson@test:[jwilson] 1$ ls -la
total 36
drwxr-xr-x 2 1001 wheel 4096 Nov 5 12:04 ./
drwxr-xr-x 6 root root 4096 Nov 4 18:40 ../
-rw-r--r-- 1 1001 wheel 33 Nov 4 12:45 .bash_logout
-rw-r--r-- 1 1001 wheel 176 Nov 4 12:45 .bash_profile
-rw-r--r-- 1 1001 wheel 124 Nov 4 12:45 .bashrc
-rw------- 1 root root 321 Nov 5 12:04 .history
-rw------- 1 1001 wheel 35 Nov 4 12:57 .lesshst
-rw-r--r-- 1 root root 808 Nov 5 12:03 .tcshrc

However, when I sudo to root, it works.

Quote:

jwilson@test:[jwilson] 2$ sudo tcsh
root@test:[jwilson] 13# ls -la
total 36
drwxr-xr-x 2 jwilson wheel 4096 Nov 5 12:04 ./
drwxr-xr-x 6 root root 4096 Nov 4 18:40 ../
-rw-r--r-- 1 jwilson wheel 33 Nov 4 12:45 .bash_logout
-rw-r--r-- 1 jwilson wheel 176 Nov 4 12:45 .bash_profile
-rw-r--r-- 1 jwilson wheel 124 Nov 4 12:45 .bashrc
-rw------- 1 root root 321 Nov 5 12:04 .history
-rw------- 1 jwilson wheel 35 Nov 4 12:57 .lesshst
-rw-r--r-- 1 root root 808 Nov 5 12:03 .tcshrc

So something in nss_ldap only works as root.

Aha! Eureka! The problem was a symlinked /etc/ldap.conf file. Removing the symlink and putting the file is place solves the problem.