5:28 a.m.
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
11:30 a.m.
New subject: What attributes to authenticate (or) How to block the ldap tree for anonymous users
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(a)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
--
Diego Lima
http://www.diegolima.org
3:23 a.m.
New subject: What attributes to authenticate (or) How to block the ldap tree for anonymous users
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
5:02 a.m.
New subject: What attributes to authenticate (or) How to block the ldap tree for anonymous users
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.
--
Diego Lima
http://www.diegolima.org
5:39 a.m.
New subject: What attributes to authenticate (or) How to block the ldap tree for anonymous users
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
7:05 a.m.
New subject: What attributes to authenticate (or) How to block the ldap tree for anonymous users
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.
--
Diego Lima
http://www.diegolima.org
4554
days inactive
4560
days old
openldap-technical@openldap.org
5 comments
2 participants
participants (2)
-
Diego Lima -
Holger Schier