Hi,
I'd like to use nscd for passwd+group caching. pam_ldap is configured and works (e.g. 'id foo' returns the correct user id if foo is present in ldap).
If I start nscd manually (not started by default), 'id foo' returns 'No such user'. As soon as I stop nscd, 'id foo' starts working again. I suspect nscd is only looking at /etc/passwd because 'id root' always works (root is present in /etc/passwd).
This is on a CentOS 5 system. Disabling SELinux did not help.
I did not attach any config files purposefully because I don't know where to look for the problem and attaching nsswitch.conf, ldap.conf etc. would result in a huge post. Nevertheless, I will consider any information needed to diagnose the problem although I suspect that this a very simple configuration problem.
Thank you very much :-) fs
Eventually I found the problem: nscd did bind anonymously and slapd was configured to prevent access to ldap information by anonymous users. I thought that specifying "rootbinddn" and the correct password in ldap.secret would prevent that but obviously nscd needs "binddn" and "bindpw" in ldap.conf.
fs
On Sun, 2007-09-30 at 19:15 +0200, Felix Schwarz wrote:
Eventually I found the problem: nscd did bind anonymously and slapd was configured to prevent access to ldap information by anonymous users. I thought that specifying "rootbinddn" and the correct password in ldap.secret would prevent that but obviously nscd needs "binddn" and "bindpw" in ldap.conf.
---- these are things that you have to work out for yourself.
I tend to allow anonymous bind for most things such as users and groups and deny access to specific attributes such as userPasswd/sambaLMPasswd/sambaNTPasswd and any other sensitive passwords to those who are specifically permitted.
You can also set up rootbinddn and rootpasswd in /root/.ldaprc # I'm assuming that nscd runs as root...I tend not to use nscd because it makes debugging difficult. Any 'user' (like root) can have a file called .ldaprc in their home directory.
I would find it awkward to set /etc/ldap.conf not to be world readable and that would make it awkward to put such an important password into that file.
Of course, you could put in a binddn and bindpw that is significantly less privileged than rootbinddn.
Craig
On Sun, 2007-09-30 at 19:15 +0200, Felix Schwarz wrote:
Eventually I found the problem: nscd did bind anonymously and slapd was configured to prevent access to ldap information by anonymous users. I thought that specifying "rootbinddn" and the correct password in ldap.secret would prevent that but obviously nscd needs "binddn" and "bindpw" in ldap.conf.
fs
nscd runs as user "nscd" so it's not going to use rootbinddn.
-Steve
On Mon, 2007-10-01 at 07:40 -0500, Steve Rigler wrote:
On Sun, 2007-09-30 at 19:15 +0200, Felix Schwarz wrote:
Eventually I found the problem: nscd did bind anonymously and slapd was configured to prevent access to ldap information by anonymous users. I thought that specifying "rootbinddn" and the correct password in ldap.secret would prevent that but obviously nscd needs "binddn" and "bindpw" in ldap.conf.
fs
nscd runs as user "nscd" so it's not going to use rootbinddn.
---- rootbinddn does not have anything to do with 'user root'
'User root' can bind as whatever is in /root/.ldaprc which by default is nothing which will default to whatever values are set as binddn/bindpw in /etc/ldap.conf
rootbinddn is the all-powerful bind of LDAP
Craig
On Mon, 2007-10-01 at 07:27 -0700, Craig White wrote:
On Mon, 2007-10-01 at 07:40 -0500, Steve Rigler wrote:
On Sun, 2007-09-30 at 19:15 +0200, Felix Schwarz wrote:
Eventually I found the problem: nscd did bind anonymously and slapd was configured to prevent access to ldap information by anonymous users. I thought that specifying "rootbinddn" and the correct password in ldap.secret would prevent that but obviously nscd needs "binddn" and "bindpw" in ldap.conf.
fs
nscd runs as user "nscd" so it's not going to use rootbinddn.
rootbinddn does not have anything to do with 'user root'
'User root' can bind as whatever is in /root/.ldaprc which by default is nothing which will default to whatever values are set as binddn/bindpw in /etc/ldap.conf
rootbinddn is the all-powerful bind of LDAP
Craig
It has a lot to do with user root if you use rootbinddn in "/etc/ldap.conf" and put the password into "/etc/ldap.secret" which should only be readable by root.
-Steve
Steve Rigler schrieb:
It has a lot to do with user root if you use rootbinddn in "/etc/ldap.conf" and put the password into "/etc/ldap.secret" which should only be readable by root.
You are right but I even set the permissions on ldap.secret to 0644 to be sure that there are no acl problems. I expected that nscd would use rootbinddn if ldap.secret was readable for the user "nscd".
fs
PS: This was on a test machine, I won't ever make ldap.secret world readable in a production environment.
On Sun, 2007-10-07 at 12:23 +0200, Felix Schwarz wrote:
Steve Rigler schrieb:
It has a lot to do with user root if you use rootbinddn in "/etc/ldap.conf" and put the password into "/etc/ldap.secret" which should only be readable by root.
You are right but I even set the permissions on ldap.secret to 0644 to be sure that there are no acl problems. I expected that nscd would use rootbinddn if ldap.secret was readable for the user "nscd".
fs
PS: This was on a test machine, I won't ever make ldap.secret world readable in a production environment.
---- Why would nscd need to bind on it's own to ldap? Perhaps it's because I don't normally use nscd but I can't see any reason for it to do so. Either a user or service binds to LDAP with it's own credentials or it fails and nscd shouldn't need it's own set of credentials. Perhaps someone can tech me something here.
Craig
On Sun, 2007-10-07 at 12:23 +0200, Felix Schwarz wrote:
Steve Rigler schrieb:
It has a lot to do with user root if you use rootbinddn in "/etc/ldap.conf" and put the password into "/etc/ldap.secret" which should only be readable by root.
You are right but I even set the permissions on ldap.secret to 0644 to be sure that there are no acl problems. I expected that nscd would use rootbinddn if ldap.secret was readable for the user "nscd".
fs
PS: This was on a test machine, I won't ever make ldap.secret world readable in a production environment.
There should be no reason for "nscd" to bind as rootbinddn. If it needs to bind at all it should use a proxy account defined with "binddn". "rootbinddn" should be used for "root" operations such as changing a user's password. See item 3 on this page:
http://kbase.redhat.com/faq/FAQ_79_7246.shtm
-Steve
-
Craig White -
Felix Schwarz -
Steve Rigler