How to secure LDAP

Question

Not sure if this belongs more on serverfault or not...

BACKGROUND:

I am using openldap, and pam/nss/ldap for authentiction on my server (webmail, etc).

My files, which work fine:

/etc/openldap/slapd.conf:

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
allow bind_v2
pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd.args
loglevel 0

access to attrs=userPassword,shadowLastChange
    by dn="cn=Admin,dc=MYDOMAIN,dc=com" write
    by anonymous auth
    by self write
    by * none

access to *
    by dn="cn=Admin,dc=MYDOMAIN,dc=com" write
    by * read

database        bdb
suffix dc=MYDOMAIN,dc=com
rootdn cn=Manager,dc=MYDOMAIN,dc=com

directory       /var/lib/ldap
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

But when I change the access to:

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

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

I can no longer login anymore. How can I write this so that I can still login, but that everyone in the world doesn't have read writes?

I'm going to try these out and then update it in just a bit with my findings... — NinjaCat, Jul 31 '10 at 17:56

score 1 · Accepted Answer · answered Jul 31 '10 at 14:28

I think if you do:

access to attrs=userPassword,shadowLastChange
    by dn="cn=Admin,dc=MYDOMAIN,dc=com" write
    by anonymous auth
    by self write
    by * none

access to *
    by dn="cn=Admin,dc=MYDOMAIN,dc=com" write
    by self write
    by anonymous auth
    by users read
    by * none

You'll have what you want.

score 1 · Answer 2 · answered Jul 31 '10 at 16:26

1

I have found out that at least for samba on debian you've have to give * read access to a few attributes on the login accounts :

access to attrs=userPassword
    by anonymous auth
    by * none

access to dn.subtree="ou=People,dc=MYDOMAIN,dc=com"
    attrs=dc,cn,uid,gecos,entry
    by * read

access to *
    by dn="cn=admin,dc=MYDOMAIN,dc=com" write
    by peername.ip=127.0.0.1 read
    by * none

dn.subtree="ou=..." adds extra security so you only expose to anonymous what's really inevitable. This means that anonymous can't search/browse this subtree BTW, he/she can only 'guess' the right dc,cn,whatever your app/service needs.

The by peername.ip=127... should be avoidable if you make all the apps/services that use login with the admin account or if you want read-only access for your apps you could make a special dn for that, you could then skip the peername.ip stanza.

answered Jul 31 '10 at 16:26

Jasper

1,087
10
10

With this solution, (1) gives ability to authenticate. (2) gives everyone the ability to read, right? (3) gives only admins write, and only localhost to read. Why would we want (2) to give everyone read? I admit to being a newbie to this. And if I read it correctly, it won't allow users to change their password, right? – NinjaCat Jul 31 '10 at 18:07
Most apps need to be able to read (at least samba and horde, PAM bases stuff) first want to establish that the user exists and then try to authenticate. As I said being able to read the subtree doesn't meand they can list them. Indeed, you have to add by self write to atrrs=userPassword. – Jasper Jul 31 '10 at 20:23
How so "being able to read the subtree doesn't mean they can list them"...? I am just trying to learn this, so I apologize if this is a dumb question. – NinjaCat Jul 31 '10 at 23:38
I up-rated this one and will post a new question specific to this solution... – NinjaCat Aug 07 '10 at 22:14

score 0 · Answer 3 · answered Jul 31 '10 at 16:49

0

Your issue might be order. It looks as though you put the catchall entry at the top, instead of at the bottom where it belongs.

Besides, if you're interested in security, you'll want to use TLS or SSL to secure the communications channel.

answered Jul 31 '10 at 16:49

Slartibartfast

3,265
17
16

The TLS/SSL is for another question I will post... I didn't want to bunch up two questions in one ;) – NinjaCat Jul 31 '10 at 17:54
TLS/SSL is only important if you want to authenticate over insecure networks, i.e. internet. If you authenticate on the same server it's complete unimportant, over LAN somewhat important (if you have untrusted authenticated users). – Jasper Jul 31 '10 at 20:24
Right now, I have it only listening on localhost. But I want to set it up so that I can hook it up via Thunderbird, among other things. I'll post a topic on that in the AM, b/c I have lots of problems once I enable TLS/SSL. – NinjaCat Jul 31 '10 at 23:35
Jasper: 1) If you want to authenticate on the same server, don't bother with LDAP; you're wasting your time. 2) If you trust your LAN that much, why bother having authentication? Just have them enter their names at the login prompt. Either you have a lot more control over your particular LAN than most do, or you're making a serious error. – Slartibartfast Aug 01 '10 at 21:07

How to secure LDAP

3 Answers3