nss_ldap as unprivileged user without giving away the ldap.secret

chakkerz · 04-08-2010, 11:06 PM

Hello there

I'm new to (open)LDAP, i'm attempting to rebuild our current LDAP setup, but i would like to tighten and so that end want to restrict anonymous to auth, rather than read, thus my slapd.conf is:

Code:

access to *
	by self write
	by users read
#	by anonymous read 
	by anonymous auth

The client hosts are connecting via nss ldap and have a corresponding ldap.secret file which authenticates them and all of this works fine for root but not for unprivileged users. I've come to the conclusions based on what the internets tell me that this is because my ldap.secret is chmod'ed to 600 . What i would LIKE is not to chmod the ldap.secret file to 666 because that would mean the rootbinddn is not protected, and that's ... crap.

Firstly, is there something i can do to achieve a setup where the ldap.secret file is world readable?

Secondly, can I create a user that can read all the entries just like to rootbinddn but restrict that user's access to read only so even if i have to make the ldap.secret world readable, it being compromised doesn't give too much away.

Third, I have actually tried to make the ldap.secret world readable and despite the log indicating that it knows the answer to my question, it then decides not to pass this information on.

slapd.conf

Code:

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

## custom includes
include         /etc/openldap/custom/solaris.schema
include         /etc/openldap/custom/openssh-lpk_openldap.schema

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

## new for ssl only
## by's need to be indented
access to *
	by self write
	by users read
	by anonymous read 
#	by anonymous auth

TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /etc/openldap/certificates/cacert.pem 
TLSCertificateFile /etc/openldap/certificates/servercrt.pem 
TLSCertificateKeyFile /etc/openldap/certificates/serverkey.pem
TLSVerifyClient never

database	bdb
suffix		"dc=example,dc=org"
rootdn		"cn=admin,dc=example,dc=org"
rootpw		{SSHA}WSEae1GsFDN0aOnxHdslw1RaUuWb65gw

directory	/var/lib/ldap
loglevel	127

index objectClass                       eq,pres
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell    eq,pres
index uid,memberUid                     eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub

## sync / replication for master configuration:
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

ldap.conf

Code:

uri ldaps://cakewalk.example.org/
base dc=example,dc=org
rootbinddn cn=admin,dc=example,dc=org

timelimit 30
bind_timelimit 30
idle_timelimit 3600
bind_policy soft

nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm

ssl yes
tls_checkpeer yes
tls_cacertfile /etc/ssl/certs/cacert.pem
tls_ciphers AES256-SHA

pam_password md5

[root@cakewalk ~]# rpm -q openldap
openldap-2.3.43-3.el5
(all related packages like openldap-server etc are also this version)

[root@cakeclient ~]# rpm -q nss_ldap
nss_ldap-253-21.el5

Diff between successful bind (as root user) vs unsuccessful bind as mere mortal but with secret chmod'ed to 666:

Code:

: >>> dnPrettyNormal: <cn=admin,dc=example,dc=org>            | : >>> dnPrettyNormal: <> 
: <<< dnPrettyNormal: <cn=admin,dc=example,dc=org>,         < | : <<< dnPrettyNormal: <>, <> 
: do_bind: version=3 dn="cn=admin,dc=example,dc=org"          | : do_bind: version=3 dn="" method=128 
: ==> bdb_bind: dn: cn=admin,dc=example,dc=org                | : send_ldap_result: conn=0 op=0 p=3 
: do_bind: v3 bind: "cn=cn=admin,dc=example,dc=org" to "      <
: send_ldap_result: conn=9 op=0 p=3                           <
: send_ldap_result: err=0 matched="" text=""                    : send_ldap_result: err=0 matched="" text="" 
: send_ldap_response: msgid=1 tag=97 err=0                      : send_ldap_response: msgid=1 tag=97 err=0 
                                                              > : do_bind: v3 anonymous bind

kbp · 04-11-2010, 09:20 AM

The rootbinddn directive is specifically only for root, to allow normal users to access the directory, create a read-only account and add it's dn into /etc/ldap.conf (conf file for nss-ldap) as:

binddn <cn=... etc>
bindpw <insert_password_here>

Note: 'bindpw' is not a valid directive for openldap (/etc/openldap/ldap.conf)

chakkerz · 04-11-2010, 10:34 PM

That worked, though there is one other piece to this puzzle namely adding an unprivileged user:

Code:

[root@cakewalk ~]# ldapmodify -x -D "cn=admin,dc=example,dc=org" -W
Enter LDAP Password: <password>
dn: cn=unprivuser,dc=example,dc=org
changetype: add
cn: unprivuser
sn: unprivuser
objectclass: top
objectclass: person
userPassword: unprivuser

adding new entry "cn=unprivuser,dc=example,dc=org"
^d

For some reason ldapadd just would not give me any love ... and none of the guides were fixing the problem ... The above worked for me.

Cheers
chakkerz

samsabed · 08-16-2010, 08:35 PM

Quote:

Originally Posted by kbp

The rootbinddn directive is specifically only for root, to allow normal users to access the directory, create a read-only account and add it's dn into /etc/ldap.conf (conf file for nss-ldap) as:

binddn <cn=... etc>
bindpw <insert_password_here>

Note: 'bindpw' is not a valid directive for openldap (/etc/openldap/ldap.conf)

Then the encrypted password is available for all, like pre shadow times. Can this be done the way shadow passwords are done. ie only visible to the root user

chakkerz · 08-16-2010, 10:14 PM

Yes, use ldap.secret with 600 permission (or 400).

What i've ended up doing is actually the following:
Have the rootbinddn defined, with the password in /etc/ldap.secret and binddn and password defined together in /etc/ldap.conf:

Code:

rootbinddn cn=authenticated_LDAP,dc=example,dc=org

binddn cn=unprivuser,dc=example,dc=org
bindpw BlahBlah

frndrfoe · 08-16-2010, 10:28 PM

Put this above your current acl and you do not need a ldap.secret file. Have them authenticate to see the password as themselves.

access to attrs=userpassword
by self write
by anonymous auth
by * none