In recognition of OpenLDAP 2.2 going stable, the FreeBSD project has now made it the standard version for the -CURRENT ports tree going forward. This will relieve many of us of the extra work needed to hack dependant ports so they would accept 2.2 in place of the previous standard, 2.1 (which is still what you'll get -- for now -- in the FreeBSD -STABLE branch or in the packages that shipped with -RELEASE). Eldapo thanks the talented engineers over at the FreeBSD project for this most intelligent decision.
OpenLDAP 2.2 STABLE
OpenLDAP version 2.2 has gone STABLE! While I've been running it for a few months, its finally good to be able to recommend it for production use. Among the features it now offers to OpenLDAP users for the first time are LDAP Sync and Simple Paged Results Control. Still missing are Server Side Sort and Multi-Master replication, but the project leads continue to insist that this is A Good Thing (TM). Being in the midst of moving my own app dev people away from SSS, I wholeheartedly agree on the former. Why should I give up precious RAM and CPU cycles so the app server will look faster than it really is? MMR is another thing, but so far I am inclined to the view that it is not a critical feature, and that finite developer time would be more effectively used in other areas for now. Microsoft and Novell marketing have been beating Sun up for years on this, but like so many other "value-adds" from closed-source vendors, it really is something we can mostly do without.
LDAP Sync is another matter. While implemented in 2.2 as a way for consumer directories to "pull" updates from suppliers, it has the potential for allowing syncrhonization between directories of different vendors -- something that has up to now been impossible. It also invites the possibility of client-side synchronization by mail clients and PDAs. ELDAPO is pleased.
OpenLDAP Access Controls
At work we don't use OpenLDAP -- yet. But that doesn't keep me from continuing to experiment with what I consider the best LDAP directory software available today.
Perhaps one of the most daunting tasks of a neophyte OpenLDAP administrator is properly setting up access controls. Although acknowledged by all to be "powerful", the regex style ACL syntax used by OpenLDAP are a real stumbling block to many. The primary rule to be observed is that once an attribute or dn has had rights to it defined, any subsequent attempt to define access will be ineffective. Failure to define the access of a particular category of user (users, self, anonymous) will result in a denial of access. I found that ordering my rules from specific to general according to logical groupings of dns or attributes to be the most effective strategy. These groupings usually relate to who should be able to see and write to particular attributes or dns. For example, the following control
access to attr=uid,c,title
by group/groupofuniquenames/uniquemember=
"cn=Administrators,dc=example,dc=com" write
by users read
by anonymous read
will result in title only being writable by admins, and only being readable by authenticated users (write implies read, which also implies search). Users cannot write to the attribute. Everyone else (anonymous) will be unable to see it at all. Note the unintuitive syntax for defining a group's rights -- I have the author of this WLUG Wiki to thank for leading me to the correct string to use. Also note that in an actual access
control the "by" line would not contain a line break.
Following is a default set of ACLs I recently implemented in production. Keep in mind that for formatting purposes I've put line breaks here. Lines beginning with "access to" or "by" should continue without breaking in an actual slapd.conf file.
# Custom access controls - created 12/31/03 by P Lembo
# Read access to root dse by all
access to dn=""
by * read
# Access by all to schema
access to dn.base="cn=subschema"
by * read
# Access to monitor by all
access to dn.base="cn=monitor"
by * read
# Limited access to password
access to attr=userpassword
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by self write
by users auth
by anonymous auth
# Limited access to Posix account attributes
access to attr=uidnumber,gidnumber,homedirectory,loginshell,gecos
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by self read
# Limited access to Samba account attributes
access to attr=lmpassword,ntpassword,pwdlastset,acctflags,logontime,logofftime,
kickofftime,pwdcanchange,pwdmustchange,smbhome,homedrive,profilepath,
userworkstations,primarygroupid,rid
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by self read
# User access to organizational attributes
access to attr=o,ou,c,description,uniquemember
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by users read
# Access to public attributes by all
access to attr=uid,c,title
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by users read
by anonymous read
# Self write access to public attributes
access to attr=cn,displayname,sn,givenname,mail,telephonenumber,facsimiletelephonenumber
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by self write
by users read
by anonymous read
# Self write and limited access to private attributes
access to attr=homephone
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by self write
by users read
# Self write and read access to all other attributes
access to *
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by self write
by users read
by anonymous read
Subscribe to:
Posts (Atom)
