Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

migrated from superuser.com Jul 31 '10 at 14:04

This question came from our site for computer enthusiasts and power users.

    
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
add comment

3 Answers

up vote 1 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 7 '10 at 22:14
add comment

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.

share|improve this answer
    
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 1 '10 at 21:07
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.