[LDAP-interop] native solaris 8 client and openldap2.2: "requirebind" / acls

[Tay, Gary]

Thank you Pierangleo for your crystal-clear explanations.
 
Gary

	-----Original Message----- 
	From: ldap-interop-bounces at fini.net on behalf of Pierangelo Masarati 
	Sent: Sat 8/20/2005 4:04 PM 
	To: OpenLDAP interoperability list 
	Cc: 
	Subject: Re: [LDAP-interop] native solaris 8 client and openldap2.2: "requirebind" / acls
	
	

	Tay, Gary wrote:
	
	>It seems like Andy has not applied the "result.c" patch required to properly read RootDSE.
	> 
	>
	^^^ this is a horrible hack!  A "cleaner" solution would be to design a
	dynamic module that intercepts searches and, if the base is "" and the
	scope is base and the attribute list is empty or contains "*", it
	injects a '+'.  This would avoid to patch slapd and make it not
	compliant to a number of specs.  This can work with OpenLDAP >= 2.3. 
	Stay tuned.
	
	>
	>===
	>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
	> 
	>
	Of course it depends on what you intend to do.  The above look like a
	minimal generally useful set of ACLs that allow everyone to perform
	simple bind (auth access to all userPasswords in the DSA), read access
	to the rootDSE (I'd add read access to "cn=Subschema" just in case;
	actually, I note it's already there in the HOWTO).
	The culprit is in rules #3 & #4. where entries under "ou=People" can:
	  - be written by themselves (isn't this too liberal?)
	  - be read by some applicative identity
	  - be read by all authenticated clients
	  - the last who "by anonymouys none" is redundant, you can safely
	remove it (I see in the HOWTO that you allow to choose between "by
	anonymous {none|auth|read}").
	and all other entries can:
	  - be written by themselves (see above)
	  - be read by everybody (this catches the "cn=Subschema" anyway; it's
	fine unless you prefer to specifically address it with a rule, so that
	in case this catchall is modified to have "by * <(less than read)>",
	"cn=Subschema" is still readable.
	
	If you realize the above, and it complies with your intentions, then
	they look definitely fine.  I'd post a comment like the above along with
	the rules, so that people that use them can judhe if they fit their
	needs and have a hint as where and how modify them if they don't.
	
	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: 7930 bytes
Desc: not available
Url : http://lists.fini.net/pipermail/ldap-interop/attachments/20050820/beb95dc7/attachment.bin
-------------- next part --------------
_______________________________________________
LDAP-interop mailing list
LDAP-interop at fini.net
http://lists.fini.net/mailman/listinfo/ldap-interop