On 07/20/2010 02:11 PM, Nicolai Stange wrote:
>
> The only entries in my /etc/ldap.conf are those:
> tls_cacertfile /etc/nss/ca.example.org-cert.pem
> tls_cert /etc/nss/nss-cert.pem
> tls_key /etc/nss/nss-key.pem
I don't think that can possibly be true. If you don't have a uri
specified, you won't get any results. I just tested that on a system
which is running a directory server.
Try this:
$ grep '^[^#]' /etc/ldap.conf
I get:
base dc=private,dc=dragonsdawn,dc=net
timelimit 120
bind_timelimit 120
idle_timelimit 3600
nss_initgroups_ignoreusers
root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm,polkituser,rtkit,pulse
uri ldap://directory.private.dragonsdawn.net/
ssl no
tls_cacertdir /etc/openldap/cacerts
pam_password md5
> The nss-{key,cert}.pem may be used to bind at the following DN:
> dn: cn=nss,ou=Special Users,dc=example,dc=org
I don't think that makes any difference unless you specify binddn in
/etc/ldap.conf
> Setting ownerships to world readable, e.g.
...
> doesn't change anything.
What about the permission on the directory /etc/nss?
All of those items must be readable by all users. The only file which
can be restricted is an optional file referenced by rootbinddn in
/etc/ldap.conf which is typically used if you require specific
credentials to change passwords. If you use this file, non-root users
still need valid credentials to bind and search the directory read-only.
You might be able to avoid giving users any access if you use sssd and
nss_sss, but that's an unusual configuration.
The key to solving this problem is that all users of your system must
have read access to all of the information that they require to bind and
search in your directory server.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
