Hey guys,
I am working with the LSEE 11 and trying to run a LDAP server. From scratch on everything went fine. With the standard configuration I can login, but if I use the LDAP Browser and hit anonymous access, I can see my whole LDAP tree. User name, mailaddresses and so on. And I am not happy with it.
So I tried to change the access control from access to * by * read to access to * by * auth or access to * by * search
The user password is already in auth mode.
But with every other configuration instead of read, I cannot login anymore. Insufficient access. After the first try with auth I read the log files and saw that there is a search operation. So i switched to search. Now the server denies some read operations.
So, my questions are: Is it just normal that anyone can see the LDAP tree? Is there any other option to hide my tree? And what attributes have to be readable to login?
Thanks a lot. Holger
Hi Holger,
I'd try with the following ACLs:
access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=example,dc=com" write by anonymous auth by self write by * none
access to * by dn="cn=admin,dc=example,dc=com" write by users read by * none
This way you'll be allowing unauthenticated users to log in using their password fields and you'll restrict read access on the rest of the base to authenticated users. The first ACL also allows users to change their own passwords (write in the userPassword and shadowLastChange attributes).
2010/9/29 Holger Schier hschier@mathematik.uni-mainz.de:
Hey guys,
I am working with the LSEE 11 and trying to run a LDAP server. From scratch on everything went fine. With the standard configuration I can login, but if I use the LDAP Browser and hit anonymous access, I can see my whole LDAP tree. User name, mailaddresses and so on. And I am not happy with it.
So I tried to change the access control from access to * by * read to access to * by * auth or access to * by * search
The user password is already in auth mode.
But with every other configuration instead of read, I cannot login anymore. Insufficient access. After the first try with auth I read the log files and saw that there is a search operation. So i switched to search. Now the server denies some read operations.
So, my questions are: Is it just normal that anyone can see the LDAP tree? Is there any other option to hide my tree? And what attributes have to be readable to login?
Thanks a lot. Holger
Hi Diego,
I tried your ACLs. Here are my entries:
olcAccess: {0}to attrs=shadowLastChange,userPassword by dn.base="cn=admin,dc=MY,dc=DC" write by anonymous auth by self write by * none olcAccess: {1}to * by dn.base="cn=admin,dc=MY,dc=DC" write by users read by * none
Then I tried to login and failed. "Login incorrect". In my messages:
slapd[5527]: slapd starting login[4786]: pam_ldap: ldap_search_s No such object login[4786]: FAILED LOGIN 1 FROM /dev/tty1 FOR UNKNOWN, User not known to the underlying authentication module
If I change the last line of the ACLs to: by * read everything works fine.
So, I did some more logging:
-----
slapd[8440]: conn=1 fd=13 ACCEPT from IP=127.0.0.1:41031 (IP=0.0.0.0:389) slapd[8440]: connection_get(13) slapd[8440]: conn=1 op=0 EXT oid=1.3.6.1.4.1.1466.20037 slapd[8440]: do_extended: oid=1.3.6.1.4.1.1466.20037 slapd[8440]: conn=1 op=0 STARTTLS slapd[8440]: conn=1 op=0 RESULT oid= err=0 text= slapd[8440]: connection_get(13) slapd[8440]: connection_get(13) slapd[8440]: conn=1 fd=13 TLS established tls_ssf=256 ssf=256 slapd[8440]: connection_get(13) slapd[8440]: conn=1 op=1 BIND dn="" method=128 slapd[8440]: send_ldap_result: err=0 matched="" text="" slapd[8440]: conn=1 op=1 RESULT tag=97 err=0 text= slapd[8440]: connection_get(13) slapd[8440]: SRCH "dc=MY,dc=DC" 2 0 slapd[8440]: 1 0 0 slapd[8440]: filter: (&(objectClass=shadowAccount)(uid=schier)) slapd[8440]: attrs: slapd[8440]: uid slapd[8440]: userPassword slapd[8440]: shadowLastChange slapd[8440]: shadowMax slapd[8440]: shadowMin slapd[8440]: shadowWarning slapd[8440]: shadowInactive slapd[8440]: shadowExpire slapd[8440]: shadowFlag slapd[8440]: slapd[8440]: conn=1 op=2 SRCH base="dc=MY,dc=DC" scope=2 deref=0 filter="(&(objectClass=shadowAccount)(uid=schier))"
slapd[8440]: conn=1 op=2 SRCH attr=uid userPassword shadowLastChange shadowMax shadowMin shadowWarning shadowInactive shadowExpire shadowFlag
slapd[8440]: => access_allowed: search access to "dc=MY,dc=DC" "entry" requested
slapd[8440]: => acl_get: [2] attr entry slapd[8440]: => acl_mask: access to entry "dc=MY,dc=DC", attr "entry" requested slapd[8440]: => acl_mask: to all values by "", (=0) slapd[8440]: <= check a_dn_pat: cn=admin,dc=MY,dc=DC slapd[8440]: <= check a_dn_pat: users slapd[8440]: <= check a_dn_pat: * slapd[8440]: <= acl_mask: [3] applying none(=0) (stop) slapd[8440]: <= acl_mask: [3] mask: none(=0) slapd[8440]: => slap_access_allowed: search access denied by none(=0) slapd[8440]: => access_allowed: no more rules slapd[8440]: send_ldap_result: err=32 matched="" text="" slapd[8440]: conn=1 op=2 SEARCH RESULT tag=101 err=32 nentries=0 text= slapd[8440]: conn=2 fd=14 ACCEPT from IP=127.0.0.1:41032 (IP=0.0.0.0:389) slapd[8440]: connection_get(14) slapd[8440]: conn=2 op=0 EXT oid=1.3.6.1.4.1.1466.20037 slapd[8440]: do_extended: oid=1.3.6.1.4.1.1466.20037 slapd[8440]: conn=2 op=0 STARTTLS slapd[8440]: conn=2 op=0 RESULT oid= err=0 text= slapd[8440]: connection_get(14) slapd[8440]: connection_get(14) slapd[8440]: conn=2 fd=14 TLS established tls_ssf=256 ssf=256 slapd[8440]: connection_get(14) slapd[8440]: conn=2 op=1 BIND dn="" method=128 slapd[8440]: send_ldap_result: err=0 matched="" text="" slapd[8440]: conn=2 op=1 RESULT tag=97 err=0 text= slapd[8440]: connection_get(14) slapd[8440]: SRCH "dc=MY,dc=DC" 2 0 slapd[8440]: 1 0 0 slapd[8440]: filter: (&(objectClass=posixAccount)(objectClass=posixAccount)(uid=schier)) slapd[8440]: attrs: slapd[8440]: slapd[8440]: conn=2 op=2 SRCH base="dc=MY,dc=DC" scope=2 deref=0 filter="(&(objectClass=posixAccount)(objectClass=posixAccount)(uid=schier))" slapd[8440]: => access_allowed: search access to "dc=MY,dc=DC" "entry" requested slapd[8440]: => acl_get: [2] attr entry slapd[8440]: => acl_mask: access to entry "dc=MY,dc=DC", attr "entry" requested slapd[8440]: => acl_mask: to all values by "", (=0) slapd[8440]: <= check a_dn_pat: cn=admin,dc=MY,dc=DC slapd[8440]: <= check a_dn_pat: users slapd[8440]: <= check a_dn_pat: * slapd[8440]: <= acl_mask: [3] applying none(=0) (stop) slapd[8440]: <= acl_mask: [3] mask: none(=0) slapd[8440]: => slap_access_allowed: search access denied by none(=0) slapd[8440]: => access_allowed: no more rules slapd[8440]: send_ldap_result: err=32 matched="" text="" slapd[8440]: conn=2 op=2 SEARCH RESULT tag=101 err=32 nentries=0 text= login[8129]: pam_ldap: ldap_search_s No such object login[8129]: FAILED LOGIN 1 FROM /dev/tty1 FOR schier, User not known to the underlying authentication module
Am 04.10.2010 20:30, schrieb Diego Lima:
Hi Holger,
I'd try with the following ACLs:
access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=example,dc=com" write by anonymous auth by self write by * none
access to * by dn="cn=admin,dc=example,dc=com" write by users read by * none
This way you'll be allowing unauthenticated users to log in using their password fields and you'll restrict read access on the rest of the base to authenticated users. The first ACL also allows users to change their own passwords (write in the userPassword and shadowLastChange attributes).
Holger
Hi Holger,
Then I tried to login and failed. "Login incorrect". In my messages:
slapd[5527]: slapd starting login[4786]: pam_ldap: ldap_search_s No such object login[4786]: FAILED LOGIN 1 FROM /dev/tty1 FOR UNKNOWN, User not known to the underlying authentication module
It seems that you are using ldap to log in to your system, correct? In this case you'll also have to set it up to authenticate to your directory with a valid user. I'm not sure how Suse does this, but in Debian you'd set a binddn and bindpw containing a DN to bind to the directory with and its password, respectively, in order to allow libnss-ldap to lookup user names in the database correctly. I'd advise you to look at Suse's documentation for more information on setting this up.
If I change the last line of the ACLs to: by * read everything works fine.
Thats understandable as the system will be able to do ldap lookups anonymously. Just look at Suse's docs on how to set its pam-ldap and nss-ldap to authenticate to your ldap server.
Hi Diego,
ahh, that makes sense. One last question to that: Is there any option to encrypt the bindpw instead of using a clear one?
YaST doesn't use any of these options, so I have to edit the ldap.conf for pam manually.
Thanks a lot so far.
Am 05.10.2010 14:02, schrieb Diego Lima:
It seems that you are using ldap to log in to your system, correct? In this case you'll also have to set it up to authenticate to your directory with a valid user. I'm not sure how Suse does this, but in Debian you'd set a binddn and bindpw containing a DN to bind to the directory with and its password, respectively, in order to allow libnss-ldap to lookup user names in the database correctly. I'd advise you to look at Suse's documentation for more information on setting this up.
Holger
Hi Holger,
Is there any option to encrypt the bindpw instead of using a clear one?
Not as far as I know. I've tried to use passwords encrypted by slappasswd but it'll fail to bind. I've settled for creating an user that has read-only access to my directory and binding with this user.
openldap-technical@openldap.org
-
Diego Lima -
Holger Schier