[LDAP-interop] native solaris 8 client and openldap 2.2: "requirebind" / acls

Fri Aug 19 13:23:05 EDT 2005

It seems like Andy has not applied the "result.c" patch required to properly read RootDSE.

===
I'm seeing a few issues here.
1) rule 3: <access to dn="ou=People,..."> in OpenLDAP 2.2 means access
to that entry only; if you meant subtree access, you should rather use
<access to dn.subtree="ou=People,...">.
2) rule 3: <by users auth> means that already authenticated clients can
only access this entry for... authentication; makes little sense to me.
3) rule 3: <by anonymous read> means that non-authenticated clients can
read what authenticated clients could not.
4) rule 4: maybe you were misguided by this catchall, which was caught
buy anything but "ou=People,dc=example,dc=com"?
===
I wrote the how-to, thank you Pierangelo for correcting my ACLs.

Do the following ACLs make sense? What I want is NOT FOR "anonymous" user to read anything under the ou=People, but FOR authenticated users and proxyAgent to do so.

access to attrs=userPassword
            by self write
            by * auth
access to dn=""
            by * read
access to dn.subtree="ou=People,dc=example,dc=com"
            by self write
            by dn="cn=proxyagent,ou=profile,dc=example,dc=com" read
            by users read
            by anonymous none
access to * by self write
            by * read

Rgds
Gary

	-----Original Message----- 
	From: ldap-interop-bounces at fini.net on behalf of Pierangelo Masarati 
	Sent: Fri 8/19/2005 11:29 PM 
	To: OpenLDAP interoperability list 
	Cc: 
	Subject: Re: [LDAP-interop] native solaris 8 client and openldap 2.2: "requirebind" / acls

	andy bezella wrote:

	>lo -
	>
	>i am working my way through an attempt to get the native solaris 8 ldap
	>client (with patch 108993-36) working with openldap 2.2.13 installed
	>from rpm on Red Hat Enterprise Linux AS release 4 (Nahant Update 1).  i
	>am pretty much restricted to these versions at this time.  everything
	>below boils down to: is the "require bind" option (useful and/or)
	>compatible with the solaris client, and if not what is the best set of
	>options or acls to use in its place.
	>
	>i've got the basics working.  i've taken the default slapd.conf and
	>modified the suffix and rootdn entries, and un-commented and edited
	>rootpw.  added the initial entries and used the migration scripts to
	>move over the data from a nis domain.
	>
	>at that point i can use the ldapclient program to initialize the client:
	># ldapclient -i -b "dc=blah,dc=navitaire,dc=com" -d domain \
	>       -s sub 192.168.9.22
	>System successfully configured
	>
	>`ldaplist passwd` returns the expected values, and i can su to a user
	>(fails with "No directory!" since i haven't gotten automounts setup
	>yet).  this all appears to be working properly.
	>
	>the problems arise as i try to incrementally increase security.  my
	>initial step was simply to try to exclude unauthenticated access.  in
	>slapd.conf, the desired option seemed to be "require bind" (which,
	>afaict, differs from "require authc" in that it would still allow
	>anonymous binds).  i created a
	>"cn=proxyagent,ou=profile,dc=blah,dc=navitaire,dc=com" ldap entry for
	>the clients to use (i don't think it matters, but i'll mention that the
	>full dn has four "dc=blah" components).  since eventually i hope to
	>implement tls, i am planning on using simple authentication.
	>
	>if that isn't the proper way to do it, and it is instead better
	>attempted through acls, then everything below here might be pointless.
	>i've taken these acl directives from
	>http://web.singnet.com.sg/~garyttt/Installing%20and%20configuring%
	>20OpenLDAP%20for%20RedHat%20Enterprise%20Linux3.htm and they appear to
	>work:
	>  # ACL directives
	>  access to attrs=userPassword
	>            by self write
	>            by * auth
	>  access to dn=""
	>            by * read
	>  access to dn="ou=People,dc=example,dc=com"
	>            by self write
	>            by dn="cn=proxyagent,ou=profile,dc=example,dc=com" read
	>            by users auth
	>            by anonymous read
	>  access to *
	>            by self write
	>            by * read
	> 
	>
	I'm seeing a few issues here.
	1) rule 3: <access to dn="ou=People,..."> in OpenLDAP 2.2 means access
	to that entry only; if you meant subtree access, you should rather use
	<access to dn.subtree="ou=People,...">.
	2) rule 3: <by users auth> means that already authenticated clients can
	only access this entry for... authentication; makes little sense to me.
	3) rule 3: <by anonymous read> means that non-authenticated clients can
	read what authenticated clients could not.
	4) rule 4: maybe you were misguided by this catchall, which was caught
	buy anything but "ou=People,dc=example,dc=com"?

	>i am browsing to see if they can be tightened down in this situation
	>while maintaining functionality.  any suggestions?
	>
	>the remainder deals with my struggle with "require bind:"
	># ldapsearch -h 149.122.9.22 -b "" -s base '(objectclass=*)' \
	>namingContexts
	>now fails but:
	># ldapsearch -h 149.122.9.22 -b "" -s base \
	>       -D "cn=proxyagent,ou=profile,dc=blah,dc=navitaire,dc=com" \
	>       -w passwd '(objectclass=*)' namingContexts
	>succeeds.  again, seems to be working as i expect.  however, no matter
	>what i try, i cannot seem to get the ldapclient routine to successfully
	>initialize the client.
	># ldapclient -i -b "dc=blah,dc=navitaire,dc=com" \
	>       -D "cn=proxyagent,ou=profile,dc=blah,dc=navitaire,dc=com" \
	>       -w passwd -d domain -s sub -c proxy -a simple 192.168.9.22
	>hangs and i have to ^C the script:
	>^Cstart: /usr/lib/ldap/ldap_cachemgr... failed
	>"/usr/lib/ldap/ldap_cachemgr" returned: 33280
	>
	>the slapd.log shows repeated:
	>Aug 16 16:39:00 nvtmmds001 slapd[24159]: >>> dnPrettyNormal: <>
	>Aug 16 16:39:00 nvtmmds001 slapd[24159]: <<< dnPrettyNormal: <>, <>
	>and
	>Aug 16 16:39:00 nvtmmds001 slapd[24159]: send_ldap_result: err=1
	>matched="" text="BIND required"
	> 
	>
	This log seems to indicate that whatever operation you try with the
	solaris client, it first attempts to search the rootDSE (dn="") prior to
	binding.  You should relax that "require bind" (e.g. by putting it into
	a database specification instead of global) if you can't get the client
	to bind before looking up the rootDSE.  Note that, for a client to bind
	(non anonymously), being able to anonymously read (portions of) the
	rootDSE may be appropriate; for instance, to discover the
	supportedSASLmechs; so your requirement should definitely be relaxed. 
	Can you post logs at "stats" (256) level of the entire session?

	p.

	    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497

	_______________________________________________
	LDAP-interop mailing list
	LDAP-interop at fini.net
	http://lists.fini.net/mailman/listinfo/ldap-interop

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 12182 bytes
Desc: not available
Url : http://lists.fini.net/pipermail/ldap-interop/attachments/20050820/7e958e6f/attachment.bin
-------------- next part --------------
_______________________________________________
LDAP-interop mailing list
LDAP-interop at fini.net
http://lists.fini.net/mailman/listinfo/ldap-interop