From: Gavin Henry <ghenry@openldap.org>
Date: Fri, 14 Mar 2008 22:53:34 +0000 (+0000)
Subject: New Access Control Section, including a new Sets section incorporating ITS#5278,... 
X-Git-Tag: OPENLDAP_REL_ENG_2_4_9~20^2~88
X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=43a8dc824fbdf63285b90251de16d4857a61d54d;p=openldap

New Access Control Section, including a new Sets section incorporating ITS#5278, ITS#5279 and ITS#5281.
---

diff --git a/doc/guide/admin/Makefile b/doc/guide/admin/Makefile
index f71513c919..dfd373d0a9 100644
--- a/doc/guide/admin/Makefile
+++ b/doc/guide/admin/Makefile
@@ -21,6 +21,7 @@ sdf-src: \
 	../plain.sdf \
 	../preamble.sdf \
 	abstract.sdf \
+	access-control.sdf \
 	appendix-changes.sdf \
 	appendix-common-errors.sdf \
 	appendix-configs.sdf \
@@ -65,7 +66,10 @@ sdf-img: \
 	dual_dc.png \
 	intro_dctree.png \
 	intro_tree.png \
-	refint.png 
+	refint.png \
+	set-following-references.png \
+	set-memberUid.png \
+	set-recursivegroup.png 
 
 guide.html: guide.sdf sdf-src sdf-img
 	sdf -2html guide.sdf
diff --git a/doc/guide/admin/access-control.sdf b/doc/guide/admin/access-control.sdf
new file mode 100644
index 0000000000..5132ba0dbe
--- /dev/null
+++ b/doc/guide/admin/access-control.sdf
@@ -0,0 +1,1136 @@
+# $OpenLDAP$
+# Copyright 1999-2008 The OpenLDAP Foundation, All Rights Reserved.
+# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
+
+H1: Access Control
+
+Access to your directory can be configured via two methods, the first using
+{{SECT:The slapd Configuration File}} and the second using the {{slapd-config}}(5) 
+format ({{SECT:Configuring slapd}}).
+
+H2: Static Access Control Configuration
+
+Access to entries and attributes is controlled by the
+access configuration file directive. The general form of an
+access line is:
+
+>	<access directive> ::= access to <what>
+>		[by <who> [<access>] [<control>] ]+
+>	<what> ::= * |
+>		[dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
+>		[filter=<ldapfilter>] [attrs=<attrlist>]
+>	<basic-style> ::= regex | exact
+>	<scope-style> ::= base | one | subtree | children
+>	<attrlist> ::= <attr> [val[.<basic-style>]=<regex>] | <attr> , <attrlist>
+>	<attr> ::= <attrname> | entry | children
+>	<who> ::= * | [anonymous | users | self
+>			| dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>] 
+>		[dnattr=<attrname>]
+>		[group[/<objectclass>[/<attrname>][.<basic-style>]]=<regex>]
+>		[peername[.<basic-style>]=<regex>]
+>		[sockname[.<basic-style>]=<regex>]
+>		[domain[.<basic-style>]=<regex>]
+>		[sockurl[.<basic-style>]=<regex>]
+>		[set=<setspec>]
+>		[aci=<attrname>]
+>	<access> ::= [self]{<level>|<priv>}
+>	<level> ::= none | disclose | auth | compare | search | read | write | manage
+>	<priv> ::= {=|+|-}{m|w|r|s|c|x|d|0}+
+>	<control> ::= [stop | continue | break]
+
+where the <what> part selects the entries and/or attributes to which
+the access applies, the {{EX:<who>}} part specifies which entities
+are granted access, and the {{EX:<access>}} part specifies the
+access granted. Multiple {{EX:<who> <access> <control>}} triplets
+are supported, allowing many entities to be granted different access
+to the same set of entries and attributes. Not all of these access
+control options are described here; for more details see the
+{{slapd.access}}(5) man page.
+
+
+H3: What to control access to
+
+The <what> part of an access specification determines the entries
+and attributes to which the access control applies.  Entries are
+commonly selected in two ways: by DN and by filter.  The following
+qualifiers select entries by DN:
+
+>	to *
+>	to dn[.<basic-style>]=<regex>
+>	to dn.<scope-style>=<DN>
+
+The first form is used to select all entries.  The second form may
+be used to select entries by matching a regular expression against
+the target entry's {{normalized DN}}.   (The second form is not
+discussed further in this document.)  The third form is used to
+select entries which are within the requested scope of DN.  The
+<DN> is a string representation of the Distinguished Name, as
+described in {{REF:RFC4514}}.
+
+The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}},
+or {{EX:children}}.  Where {{EX:base}} matches only the entry with
+provided DN, {{EX:one}} matches the entries whose parent is the
+provided DN, {{EX:subtree}} matches all entries in the subtree whose
+root is the provided DN, and {{EX:children}} matches all entries
+under the DN (but not the entry named by the DN).
+
+For example, if the directory contained entries named:
+
+>	0: o=suffix
+>	1: cn=Manager,o=suffix
+>	2: ou=people,o=suffix
+>	3: uid=kdz,ou=people,o=suffix
+>	4: cn=addresses,uid=kdz,ou=people,o=suffix
+>	5: uid=hyc,ou=people,o=suffix
+
+\Then:
+. {{EX:dn.base="ou=people,o=suffix"}} match 2;
+. {{EX:dn.one="ou=people,o=suffix"}} match 3, and 5;
+. {{EX:dn.subtree="ou=people,o=suffix"}} match 2, 3, 4, and 5; and
+. {{EX:dn.children="ou=people,o=suffix"}} match 3, 4, and 5.
+
+
+Entries may also be selected using a filter:
+
+>	to filter=<ldap filter>
+
+where <ldap filter> is a string representation of an LDAP
+search filter, as described in {{REF:RFC4515}}.  For example:
+
+>	to filter=(objectClass=person)
+
+Note that entries may be selected by both DN and filter by
+including both qualifiers in the <what> clause.
+
+>	to dn.one="ou=people,o=suffix" filter=(objectClass=person)
+
+Attributes within an entry are selected by including a comma-separated
+list of attribute names in the <what> selector:
+
+>	attrs=<attribute list>
+
+A specific value of an attribute is selected by using a single
+attribute name and also using a value selector:
+
+>	attrs=<attribute> val[.<style>]=<regex>
+
+There are two special {{pseudo}} attributes {{EX:entry}} and
+{{EX:children}}.  To read (and hence return) a target entry, the
+subject must have {{EX:read}} access to the target's {{entry}}
+attribute.  To add or delete an entry, the subject must have
+{{EX:write}} access to the entry's {{EX:entry}} attribute AND must
+have {{EX:write}} access to the entry's parent's {{EX:children}}
+attribute.  To rename an entry, the subject must have {{EX:write}}
+access to entry's {{EX:entry}} attribute AND have {{EX:write}}
+access to both the old parent's and new parent's {{EX:children}}
+attributes.  The complete examples at the end of this section should
+help clear things up.
+
+Lastly, there is a special entry selector {{EX:"*"}} that is used to
+select any entry.  It is used when no other {{EX:<what>}}
+selector has been provided.  It's equivalent to "{{EX:dn=.*}}"
+
+
+H3: Who to grant access to
+
+The <who> part identifies the entity or entities being granted
+access. Note that access is granted to "entities" not "entries."
+The following table summarizes entity specifiers:
+
+!block table; align=Center; coltags="EX,N"; \
+	title="Table 6.3: Access Entity Specifiers"
+Specifier|Entities
+*|All, including anonymous and authenticated users
+anonymous|Anonymous (non-authenticated) users
+users|Authenticated users
+self|User associated with target entry
+dn[.<basic-style>]=<regex>|Users matching a regular expression
+dn.<scope-style>=<DN>|Users within scope of a DN
+!endblock
+
+The DN specifier behaves much like <what> clause DN specifiers.
+
+Other control factors are also supported.  For example, a {{EX:<who>}}
+can be restricted by an entry listed in a DN-valued attribute in
+the entry to which the access applies:
+
+>	dnattr=<dn-valued attribute name>
+
+The dnattr specification is used to give access to an entry
+whose DN is listed in an attribute of the entry (e.g., give
+access to a group entry to whoever is listed as the owner of
+the group entry).
+
+Some factors may not be appropriate in all environments (or any).
+For example, the domain factor relies on IP to domain name lookups.
+As these can easily be spoofed, the domain factor should be avoided.
+
+
+H3: The access to grant
+
+The kind of <access> granted can be one of the following:
+
+!block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
+	title="Table 6.4: Access Levels"
+Level		Privileges	Description
+none		=0			no access
+disclose	=d			needed for information disclosure on error
+auth		=dx			needed to authenticate (bind)
+compare		=cdx		needed to compare
+search		=scdx		needed to apply search filters
+read		=rscdx		needed to read search results
+write		=wrscdx		needed to modify/rename
+manage		=mwrscdx	needed to manage
+!endblock
+
+Each level implies all lower levels of access. So, for example,
+granting someone {{EX:write}} access to an entry also grants them
+{{EX:read}}, {{EX:search}}, {{EX:compare}}, {{EX:auth}} and
+{{EX:disclose}} access.  However, one may use the privileges specifier
+to grant specific permissions.
+
+
+H3: Access Control Evaluation
+
+When evaluating whether some requester should be given access to
+an entry and/or attribute, slapd compares the entry and/or attribute
+to the {{EX:<what>}} selectors given in the configuration file.
+For each entry, access controls provided in the database which holds
+the entry (or the first database if not held in any database) apply
+first, followed by the global access directives.  Within this
+priority, access directives are examined in the order in which they
+appear in the config file.  Slapd stops with the first {{EX:<what>}}
+selector that matches the entry and/or attribute. The corresponding
+access directive is the one slapd will use to evaluate access.
+
+Next, slapd compares the entity requesting access to the {{EX:<who>}}
+selectors within the access directive selected above in the order
+in which they appear. It stops with the first {{EX:<who>}} selector
+that matches the requester. This determines the access the entity
+requesting access has to the entry and/or attribute.
+
+Finally, slapd compares the access granted in the selected
+{{EX:<access>}} clause to the access requested by the client. If
+it allows greater or equal access, access is granted. Otherwise,
+access is denied.
+
+The order of evaluation of access directives makes their placement
+in the configuration file important. If one access directive is
+more specific than another in terms of the entries it selects, it
+should appear first in the config file. Similarly, if one {{EX:<who>}}
+selector is more specific than another it should come first in the
+access directive. The access control examples given below should
+help make this clear.
+
+
+
+H3: Access Control Examples
+
+The access control facility described above is quite powerful.  This
+section shows some examples of its use for descriptive purposes.
+
+A simple example:
+
+>	access to * by * read
+
+This access directive grants read access to everyone.
+
+>	access to *
+>		by self write
+>		by anonymous auth
+>		by * read
+
+This directive allows the user to modify their entry, allows anonymous
+to authentication against these entries, and allows all others to
+read these entries.  Note that only the first {{EX:by <who>}} clause
+which matches applies.  Hence, the anonymous users are granted
+{{EX:auth}}, not {{EX:read}}.  The last clause could just as well
+have been "{{EX:by users read}}".
+
+It is often desirable to restrict operations based upon the level
+of protection in place.  The following shows how security strength
+factors (SSF) can be used.
+
+>	access to *
+>		by ssf=128 self write
+>		by ssf=64 anonymous auth
+>		by ssf=64 users read
+
+This directive allows users to modify their own entries if security
+protections have of strength 128 or better have been established,
+allows authentication access to anonymous users, and read access
+when 64 or better security protections have been established.  If
+client has not establish sufficient security protections, the
+implicit {{EX:by * none}} clause would be applied.
+
+The following example shows the use of a style specifiers to select
+the entries by DN in two access directives where ordering is
+significant.
+
+>	access to dn.children="dc=example,dc=com"
+> 		by * search
+>	access to dn.children="dc=com"
+> 		by * read
+
+Read access is granted to entries under the {{EX:dc=com}} subtree,
+except for those entries under the {{EX:dc=example,dc=com}} subtree,
+to which search access is granted.  No access is granted to
+{{EX:dc=com}} as neither access directive matches this DN.  If the
+order of these access directives was reversed, the trailing directive
+would never be reached, since all entries under {{EX:dc=example,dc=com}}
+are also under {{EX:dc=com}} entries.
+
+Also note that if no {{EX:access to}} directive matches or no {{EX:by
+<who>}} clause, {{B:access is denied}}.  That is, every {{EX:access
+to}} directive ends with an implicit {{EX:by * none}} clause and
+every access list ends with an implicit {{EX:access to * by * none}}
+directive.
+
+The next example again shows the importance of ordering, both of
+the access directives and the {{EX:by <who>}} clauses.  It also
+shows the use of an attribute selector to grant access to a specific
+attribute and various {{EX:<who>}} selectors.
+
+>	access to dn.subtree="dc=example,dc=com" attrs=homePhone
+>		by self write
+>		by dn.children="dc=example,dc=com" search
+>		by peername.regex=IP:10\..+ read
+>	access to dn.subtree="dc=example,dc=com"
+>		by self write
+>		by dn.children="dc=example,dc=com" search
+>		by anonymous auth
+
+This example applies to entries in the "{{EX:dc=example,dc=com}}"
+subtree. To all attributes except {{EX:homePhone}}, an entry can
+write to itself, entries under {{EX:example.com}} entries can search
+by them, anybody else has no access (implicit {{EX:by * none}})
+excepting for authentication/authorization (which is always done
+anonymously).  The {{EX:homePhone}} attribute is writable by the
+entry, searchable by entries under {{EX:example.com}}, readable by
+clients connecting from network 10, and otherwise not readable
+(implicit {{EX:by * none}}).  All other access is denied by the
+implicit {{EX:access to * by * none}}.
+
+Sometimes it is useful to permit a particular DN to add or
+remove itself from an attribute. For example, if you would like to
+create a group and allow people to add and remove only
+their own DN from the member attribute, you could accomplish
+it with an access directive like this:
+
+>	access to attrs=member,entry
+> 		by dnattr=member selfwrite
+
+The dnattr {{EX:<who>}} selector says that the access applies to
+entries listed in the {{EX:member}} attribute. The {{EX:selfwrite}} access
+selector says that such members can only add or delete their
+own DN from the attribute, not other values. The addition of
+the entry attribute is required because access to the entry is
+required to access any of the entry's attributes.
+
+!if 0
+For more details on how to use the {{EX:access}} directive,
+consult the {{Advanced Access Control}} chapter.
+!endif
+
+
+H3: Configuration File Example
+
+The following is an example configuration file, interspersed
+with explanatory text. It defines two databases to handle
+different parts of the {{TERM:X.500}} tree; both are {{TERM:BDB}}
+database instances. The line numbers shown are provided for
+reference only and are not included in the actual file. First, the
+global configuration section:
+
+E:  1.	# example config file - global configuration section
+E:  2.	include /usr/local/etc/schema/core.schema
+E:  3.	referral ldap://root.openldap.org
+E:  4.	access to * by * read
+ 
+Line 1 is a comment. Line 2 includes another config file
+which contains {{core}} schema definitions.
+The {{EX:referral}} directive on line 3
+means that queries not local to one of the databases defined
+below will be referred to the LDAP server running on the
+standard port (389) at the host {{EX:root.openldap.org}}.
+
+Line 4 is a global access control.  It applies to all
+entries (after any applicable database-specific access
+controls).
+
+The next section of the configuration file defines a BDB
+backend that will handle queries for things in the
+"dc=example,dc=com" portion of the tree. The
+database is to be replicated to two slave slapds, one on
+truelies, the other on judgmentday. Indices are to be
+maintained for several attributes, and the {{EX:userPassword}}
+attribute is to be protected from unauthorized access.
+
+E:  5.	# BDB definition for the example.com
+E:  6.	database bdb
+E:  7.	suffix "dc=example,dc=com"
+E:  8.	directory /usr/local/var/openldap-data
+E:  9.	rootdn "cn=Manager,dc=example,dc=com"
+E: 10.	rootpw secret
+E: 11.	# indexed attribute definitions
+E: 12.	index uid pres,eq
+E: 13.	index cn,sn,uid pres,eq,approx,sub
+E: 14.	index objectClass eq
+E: 15.	# database access control definitions
+E: 16.	access to attrs=userPassword
+E: 17.		by self write
+E: 18.		by anonymous auth
+E: 19.		by dn.base="cn=Admin,dc=example,dc=com" write
+E: 20.		by * none
+E: 21.	access to *
+E: 22.		by self write
+E: 23.		by dn.base="cn=Admin,dc=example,dc=com" write
+E: 24.		by * read
+
+Line 5 is a comment. The start of the database definition is marked
+by the database keyword on line 6. Line 7 specifies the DN suffix
+for queries to pass to this database. Line 8 specifies the directory
+in which the database files will live.
+
+Lines 9 and 10 identify the database {{super-user}} entry and associated
+password. This entry is not subject to access control or size or
+time limit restrictions.
+
+Lines 12 through 14 indicate the indices to maintain for various
+attributes.
+
+Lines 16 through 24 specify access control for entries in this
+database.  As this is the first database, the controls also apply
+to entries not held in any database (such as the Root DSE).  For
+all applicable entries, the {{EX:userPassword}} attribute is writable
+by the entry itself and by the "admin" entry.  It may be used for
+authentication/authorization purposes, but is otherwise not readable.
+All other attributes are writable by the entry and the "admin"
+entry, but may be read by all users (authenticated or not).
+
+The next section of the example configuration file defines another
+BDB database. This one handles queries involving the
+{{EX:dc=example,dc=net}} subtree but is managed by the same entity
+as the first database.  Note that without line 39, the read access
+would be allowed due to the global access rule at line 4.
+
+E: 33.	# BDB definition for example.net
+E: 34.	database bdb
+E: 35.	suffix "dc=example,dc=net"
+E: 36.	directory /usr/local/var/openldap-data-net
+E: 37.	rootdn "cn=Manager,dc=example,dc=com"
+E: 38.	index objectClass eq
+E: 39.	access to * by users read
+
+H2: Dynamic Access Control Configuration
+
+Access to slapd entries and attributes is controlled by the
+olcAccess attribute, whose values are a sequence of access directives.
+The general form of the olcAccess configuration is:
+
+>	olcAccess: <access directive>
+>	<access directive> ::= to <what>
+>		[by <who> [<access>] [<control>] ]+
+>	<what> ::= * |
+>		[dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
+>		[filter=<ldapfilter>] [attrs=<attrlist>]
+>	<basic-style> ::= regex | exact
+>	<scope-style> ::= base | one | subtree | children
+>	<attrlist> ::= <attr> [val[.<basic-style>]=<regex>] | <attr> , <attrlist>
+>	<attr> ::= <attrname> | entry | children
+>	<who> ::= * | [anonymous | users | self
+>			| dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>] 
+>		[dnattr=<attrname>]
+>		[group[/<objectclass>[/<attrname>][.<basic-style>]]=<regex>]
+>		[peername[.<basic-style>]=<regex>]
+>		[sockname[.<basic-style>]=<regex>]
+>		[domain[.<basic-style>]=<regex>]
+>		[sockurl[.<basic-style>]=<regex>]
+>		[set=<setspec>]
+>		[aci=<attrname>]
+>	<access> ::= [self]{<level>|<priv>}
+>	<level> ::= none | disclose | auth | compare | search | read | write | manage
+>	<priv> ::= {=|+|-}{m|w|r|s|c|x|d|0}+
+>	<control> ::= [stop | continue | break]
+
+where the <what> part selects the entries and/or attributes to which
+the access applies, the {{EX:<who>}} part specifies which entities
+are granted access, and the {{EX:<access>}} part specifies the
+access granted. Multiple {{EX:<who> <access> <control>}} triplets
+are supported, allowing many entities to be granted different access
+to the same set of entries and attributes. Not all of these access
+control options are described here; for more details see the
+{{slapd.access}}(5) man page.
+
+
+H3: What to control access to
+
+The <what> part of an access specification determines the entries
+and attributes to which the access control applies.  Entries are
+commonly selected in two ways: by DN and by filter.  The following
+qualifiers select entries by DN:
+
+>	to *
+>	to dn[.<basic-style>]=<regex>
+>	to dn.<scope-style>=<DN>
+
+The first form is used to select all entries.  The second form may
+be used to select entries by matching a regular expression against
+the target entry's {{normalized DN}}.   (The second form is not
+discussed further in this document.)  The third form is used to
+select entries which are within the requested scope of DN.  The
+<DN> is a string representation of the Distinguished Name, as
+described in {{REF:RFC4514}}.
+
+The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}},
+or {{EX:children}}.  Where {{EX:base}} matches only the entry with
+provided DN, {{EX:one}} matches the entries whose parent is the
+provided DN, {{EX:subtree}} matches all entries in the subtree whose
+root is the provided DN, and {{EX:children}} matches all entries
+under the DN (but not the entry named by the DN).
+
+For example, if the directory contained entries named:
+
+>	0: o=suffix
+>	1: cn=Manager,o=suffix
+>	2: ou=people,o=suffix
+>	3: uid=kdz,ou=people,o=suffix
+>	4: cn=addresses,uid=kdz,ou=people,o=suffix
+>	5: uid=hyc,ou=people,o=suffix
+
+\Then:
+. {{EX:dn.base="ou=people,o=suffix"}} match 2;
+. {{EX:dn.one="ou=people,o=suffix"}} match 3, and 5;
+. {{EX:dn.subtree="ou=people,o=suffix"}} match 2, 3, 4, and 5; and
+. {{EX:dn.children="ou=people,o=suffix"}} match 3, 4, and 5.
+
+
+Entries may also be selected using a filter:
+
+>	to filter=<ldap filter>
+
+where <ldap filter> is a string representation of an LDAP
+search filter, as described in {{REF:RFC4515}}.  For example:
+
+>	to filter=(objectClass=person)
+
+Note that entries may be selected by both DN and filter by
+including both qualifiers in the <what> clause.
+
+>	to dn.one="ou=people,o=suffix" filter=(objectClass=person)
+
+Attributes within an entry are selected by including a comma-separated
+list of attribute names in the <what> selector:
+
+>	attrs=<attribute list>
+
+A specific value of an attribute is selected by using a single
+attribute name and also using a value selector:
+
+>	attrs=<attribute> val[.<style>]=<regex>
+
+There are two special {{pseudo}} attributes {{EX:entry}} and
+{{EX:children}}.  To read (and hence return) a target entry, the
+subject must have {{EX:read}} access to the target's {{entry}}
+attribute.  To add or delete an entry, the subject must have
+{{EX:write}} access to the entry's {{EX:entry}} attribute AND must
+have {{EX:write}} access to the entry's parent's {{EX:children}}
+attribute.  To rename an entry, the subject must have {{EX:write}}
+access to entry's {{EX:entry}} attribute AND have {{EX:write}}
+access to both the old parent's and new parent's {{EX:children}}
+attributes.  The complete examples at the end of this section should
+help clear things up.
+
+Lastly, there is a special entry selector {{EX:"*"}} that is used to
+select any entry.  It is used when no other {{EX:<what>}}
+selector has been provided.  It's equivalent to "{{EX:dn=.*}}"
+
+
+H3: Who to grant access to
+
+The <who> part identifies the entity or entities being granted
+access. Note that access is granted to "entities" not "entries."
+The following table summarizes entity specifiers:
+
+!block table; align=Center; coltags="EX,N"; \
+	title="Table 5.3: Access Entity Specifiers"
+Specifier|Entities
+*|All, including anonymous and authenticated users
+anonymous|Anonymous (non-authenticated) users
+users|Authenticated users
+self|User associated with target entry
+dn[.<basic-style>]=<regex>|Users matching a regular expression
+dn.<scope-style>=<DN>|Users within scope of a DN
+!endblock
+
+The DN specifier behaves much like <what> clause DN specifiers.
+
+Other control factors are also supported.  For example, a {{EX:<who>}}
+can be restricted by an entry listed in a DN-valued attribute in
+the entry to which the access applies:
+
+>	dnattr=<dn-valued attribute name>
+
+The dnattr specification is used to give access to an entry
+whose DN is listed in an attribute of the entry (e.g., give
+access to a group entry to whoever is listed as the owner of
+the group entry).
+
+Some factors may not be appropriate in all environments (or any).
+For example, the domain factor relies on IP to domain name lookups.
+As these can easily be spoofed, the domain factor should be avoided.
+
+
+H3: The access to grant
+
+The kind of <access> granted can be one of the following:
+
+!block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
+	title="Table 5.4: Access Levels"
+Level		Privileges	Description
+none		=0			no access
+disclose	=d			needed for information disclosure on error
+auth		=dx			needed to authenticate (bind)
+compare		=cdx		needed to compare
+search		=scdx		needed to apply search filters
+read		=rscdx		needed to read search results
+write		=wrscdx		needed to modify/rename
+manage		=mwrscdx	needed to manage
+!endblock
+
+Each level implies all lower levels of access. So, for example,
+granting someone {{EX:write}} access to an entry also grants them
+{{EX:read}}, {{EX:search}}, {{EX:compare}}, {{EX:auth}} and
+{{EX:disclose}} access.  However, one may use the privileges specifier
+to grant specific permissions.
+
+
+H3: Access Control Evaluation
+
+When evaluating whether some requester should be given access to
+an entry and/or attribute, slapd compares the entry and/or attribute
+to the {{EX:<what>}} selectors given in the configuration.  For
+each entry, access controls provided in the database which holds
+the entry (or the first database if not held in any database) apply
+first, followed by the global access directives (which are held in
+the {{EX:frontend}} database definition).  Within this priority,
+access directives are examined in the order in which they appear
+in the configuration attribute.  Slapd stops with the first
+{{EX:<what>}} selector that matches the entry and/or attribute. The
+corresponding access directive is the one slapd will use to evaluate
+access.
+
+Next, slapd compares the entity requesting access to the {{EX:<who>}}
+selectors within the access directive selected above in the order
+in which they appear. It stops with the first {{EX:<who>}} selector
+that matches the requester. This determines the access the entity
+requesting access has to the entry and/or attribute.
+
+Finally, slapd compares the access granted in the selected
+{{EX:<access>}} clause to the access requested by the client. If
+it allows greater or equal access, access is granted. Otherwise,
+access is denied.
+
+The order of evaluation of access directives makes their placement
+in the configuration file important. If one access directive is
+more specific than another in terms of the entries it selects, it
+should appear first in the configuration. Similarly, if one {{EX:<who>}}
+selector is more specific than another it should come first in the
+access directive. The access control examples given below should
+help make this clear.
+
+
+
+H3: Access Control Examples
+
+The access control facility described above is quite powerful.  This
+section shows some examples of its use for descriptive purposes.
+
+A simple example:
+
+>	olcAccess: to * by * read
+
+This access directive grants read access to everyone.
+
+>	olcAccess: to *
+>		by self write
+>		by anonymous auth
+>		by * read
+
+This directive allows the user to modify their entry, allows anonymous
+to authenticate against these entries, and allows all others to
+read these entries.  Note that only the first {{EX:by <who>}} clause
+which matches applies.  Hence, the anonymous users are granted
+{{EX:auth}}, not {{EX:read}}.  The last clause could just as well
+have been "{{EX:by users read}}".
+
+It is often desirable to restrict operations based upon the level
+of protection in place.  The following shows how security strength
+factors (SSF) can be used.
+
+>	olcAccess: to *
+>		by ssf=128 self write
+>		by ssf=64 anonymous auth
+>		by ssf=64 users read
+
+This directive allows users to modify their own entries if security
+protections of strength 128 or better have been established,
+allows authentication access to anonymous users, and read access
+when strength 64 or better security protections have been established.  If
+the client has not establish sufficient security protections, the
+implicit {{EX:by * none}} clause would be applied.
+
+The following example shows the use of style specifiers to select
+the entries by DN in two access directives where ordering is
+significant.
+
+>	olcAccess: to dn.children="dc=example,dc=com"
+> 		by * search
+>	olcAccess: to dn.children="dc=com"
+> 		by * read
+
+Read access is granted to entries under the {{EX:dc=com}} subtree,
+except for those entries under the {{EX:dc=example,dc=com}} subtree,
+to which search access is granted.  No access is granted to
+{{EX:dc=com}} as neither access directive matches this DN.  If the
+order of these access directives was reversed, the trailing directive
+would never be reached, since all entries under {{EX:dc=example,dc=com}}
+are also under {{EX:dc=com}} entries.
+
+Also note that if no {{EX:olcAccess: to}} directive matches or no {{EX:by
+<who>}} clause, {{B:access is denied}}.  That is, every {{EX:olcAccess:
+to}} directive ends with an implicit {{EX:by * none}} clause and
+every access list ends with an implicit {{EX:olcAccess: to * by * none}}
+directive.
+
+The next example again shows the importance of ordering, both of
+the access directives and the {{EX:by <who>}} clauses.  It also
+shows the use of an attribute selector to grant access to a specific
+attribute and various {{EX:<who>}} selectors.
+
+>	olcAccess: to dn.subtree="dc=example,dc=com" attrs=homePhone
+>		by self write
+>		by dn.children=dc=example,dc=com" search
+>		by peername.regex=IP:10\..+ read
+>	olcAccess: to dn.subtree="dc=example,dc=com"
+>		by self write
+>		by dn.children="dc=example,dc=com" search
+>		by anonymous auth
+
+This example applies to entries in the "{{EX:dc=example,dc=com}}"
+subtree. To all attributes except {{EX:homePhone}}, an entry can
+write to itself, entries under {{EX:example.com}} entries can search
+by them, anybody else has no access (implicit {{EX:by * none}})
+excepting for authentication/authorization (which is always done
+anonymously).  The {{EX:homePhone}} attribute is writable by the
+entry, searchable by entries under {{EX:example.com}}, readable by
+clients connecting from network 10, and otherwise not readable
+(implicit {{EX:by * none}}).  All other access is denied by the
+implicit {{EX:access to * by * none}}.
+
+Sometimes it is useful to permit a particular DN to add or
+remove itself from an attribute. For example, if you would like to
+create a group and allow people to add and remove only
+their own DN from the member attribute, you could accomplish
+it with an access directive like this:
+
+>	olcAccess: to attrs=member,entry
+> 		by dnattr=member selfwrite
+
+The dnattr {{EX:<who>}} selector says that the access applies to
+entries listed in the {{EX:member}} attribute. The {{EX:selfwrite}} access
+selector says that such members can only add or delete their
+own DN from the attribute, not other values. The addition of
+the entry attribute is required because access to the entry is
+required to access any of the entry's attributes.
+
+
+
+H3: Access Control Ordering
+
+Since the ordering of {{EX:olcAccess}} directives is essential to their
+proper evaluation, but LDAP attributes normally do not preserve the
+ordering of their values, OpenLDAP uses a custom schema extension to
+maintain a fixed ordering of these values. This ordering is maintained
+by prepending a {{EX:"{X}"}} numeric index to each value, similarly to
+the approach used for ordering the configuration entries. These index
+tags are maintained automatically by slapd and do not need to be specified
+when originally defining the values. For example, when you create the
+settings
+
+>	olcAccess: to attrs=member,entry
+> 		by dnattr=member selfwrite
+>	olcAccess: to dn.children="dc=example,dc=com"
+> 		by * search
+>	olcAccess: to dn.children="dc=com"
+> 		by * read
+
+when you read them back using slapcat or ldapsearch they will contain
+
+>	olcAccess: {0}to attrs=member,entry
+> 		by dnattr=member selfwrite
+>	olcAccess: {1}to dn.children="dc=example,dc=com"
+> 		by * search
+>	olcAccess: {2}to dn.children="dc=com"
+> 		by * read
+
+The numeric index may be used to specify a particular value to change
+when using ldapmodify to edit the access rules. This index can be used
+instead of (or in addition to) the actual access value. Using this 
+numeric index is very helpful when multiple access rules are being managed.
+
+For example, if we needed to change the second rule above to grant
+write access instead of search, we could try this LDIF:
+
+>	changetype: modify
+>	delete: olcAccess
+>	olcAccess: to dn.children="dc=example,dc=com" by * search
+>	-
+>	add: olcAccess
+>	olcAccess: to dn.children="dc=example,dc=com" by * write
+>	-
+
+But this example {{B:will not}} guarantee that the existing values remain in
+their original order, so it will most likely yield a broken security
+configuration. Instead, the numeric index should be used:
+
+>	changetype: modify
+>	delete: olcAccess
+>	olcAccess: {1}
+>	-
+>	add: olcAccess
+>	olcAccess: {1}to dn.children="dc=example,dc=com" by * write
+>	-
+
+This example deletes whatever rule is in value #1 of the {{EX:olcAccess}}
+attribute (regardless of its value) and adds a new value that is
+explicitly inserted as value #1. The result will be
+
+>	olcAccess: {0}to attrs=member,entry
+> 		by dnattr=member selfwrite
+>	olcAccess: {1}to dn.children="dc=example,dc=com"
+> 		by * write
+>	olcAccess: {2}to dn.children="dc=com"
+> 		by * read
+
+which is exactly what was intended.
+
+!if 0
+For more details on how to use the {{EX:access}} directive,
+consult the {{Advanced Access Control}} chapter.
+!endif
+
+
+H3: Configuration Example
+
+The following is an example configuration, interspersed
+with explanatory text. It defines two databases to handle
+different parts of the {{TERM:X.500}} tree; both are {{TERM:BDB}}
+database instances. The line numbers shown are provided for
+reference only and are not included in the actual file. First, the
+global configuration section:
+
+E:  1.	# example config file - global configuration entry
+E:  2.	dn: cn=config
+E:  3.	objectClass: olcGlobal
+E:  4.	cn: config
+E:  5.	olcReferral: ldap://root.openldap.org
+E:  6.	
+
+Line 1 is a comment. Lines 2-4 identify this as the global
+configuration entry.
+The {{EX:olcReferral:}} directive on line 5
+means that queries not local to one of the databases defined
+below will be referred to the LDAP server running on the
+standard port (389) at the host {{EX:root.openldap.org}}.
+Line 6 is a blank line, indicating the end of this entry.
+
+E:  7.	# internal schema
+E:  8.	dn: cn=schema,cn=config
+E:  9.	objectClass: olcSchemaConfig
+E: 10.	cn: schema
+E: 11.	
+
+Line 7 is a comment. Lines 8-10 identify this as the root of
+the schema subtree. The actual schema definitions in this entry
+are hardcoded into slapd so no additional attributes are specified here.
+Line 11 is a blank line, indicating the end of this entry.
+
+E: 12.	# include the core schema
+E: 13.	include: file:///usr/local/etc/openldap/schema/core.ldif
+E: 14.	
+
+Line 12 is a comment. Line 13 is an LDIF include directive which
+accesses the {{core}} schema definitions in LDIF format. Line 14
+is a blank line.
+
+Next comes the database definitions. The first database is the
+special {{EX:frontend}} database whose settings are applied globally
+to all the other databases.
+
+E: 15.	# global database parameters
+E: 16.	dn: olcDatabase=frontend,cn=config
+E: 17.	objectClass: olcDatabaseConfig
+E: 18.	olcDatabase: frontend
+E: 19.	olcAccess: to * by * read
+E: 20.	
+
+Line 15 is a comment. Lines 16-18 identify this entry as the global
+database entry. Line 19 is a global access control. It applies to all
+entries (after any applicable database-specific access controls).
+
+The next entry defines a BDB backend that will handle queries for things
+in the "dc=example,dc=com" portion of the tree. Indices are to be maintained
+for several attributes, and the {{EX:userPassword}} attribute is to be
+protected from unauthorized access.
+
+E: 21.	# BDB definition for example.com
+E: 22.	dn: olcDatabase=bdb,cn=config
+E: 23.	objectClass: olcDatabaseConfig
+E: 24.	objectClass: olcBdbConfig
+E: 25.	olcDatabase: bdb
+E: 26.	olcSuffix: "dc=example,dc=com"
+E: 27.	olcDbDirectory: /usr/local/var/openldap-data
+E: 28.	olcRootDN: "cn=Manager,dc=example,dc=com"
+E: 29.	olcRootPW: secret
+E: 30.	olcDbIndex: uid pres,eq
+E: 31.	olcDbIndex: cn,sn,uid pres,eq,approx,sub
+E: 32.	olcDbIndex: objectClass eq
+E: 33.	olcAccess: to attrs=userPassword
+E: 34.	  by self write
+E: 35.	  by anonymous auth
+E: 36.	  by dn.base="cn=Admin,dc=example,dc=com" write
+E: 37.	  by * none
+E: 38.	olcAccess: to *
+E: 39.	  by self write
+E: 40.	  by dn.base="cn=Admin,dc=example,dc=com" write
+E: 41.	  by * read
+E: 42.	
+
+Line 21 is a comment. Lines 22-25 identify this entry as a BDB database
+configuration entry.  Line 26 specifies the DN suffix
+for queries to pass to this database. Line 27 specifies the directory
+in which the database files will live.
+
+Lines 28 and 29 identify the database {{super-user}} entry and associated
+password. This entry is not subject to access control or size or
+time limit restrictions.
+
+Lines 30 through 32 indicate the indices to maintain for various
+attributes.
+
+Lines 33 through 41 specify access control for entries in this
+database.  As this is the first database, the controls also apply
+to entries not held in any database (such as the Root DSE).  For
+all applicable entries, the {{EX:userPassword}} attribute is writable
+by the entry itself and by the "admin" entry.  It may be used for
+authentication/authorization purposes, but is otherwise not readable.
+All other attributes are writable by the entry and the "admin"
+entry, but may be read by all users (authenticated or not).
+
+Line 42 is a blank line, indicating the end of this entry.
+
+The next section of the example configuration file defines another
+BDB database. This one handles queries involving the
+{{EX:dc=example,dc=net}} subtree but is managed by the same entity
+as the first database.  Note that without line 52, the read access
+would be allowed due to the global access rule at line 19.
+
+E: 43.	# BDB definition for example.net
+E: 44.	dn: olcDatabase=bdb,cn=config
+E: 45.	objectClass: olcDatabaseConfig
+E: 46.	objectClass: olcBdbConfig
+E: 47.	olcDatabase: bdb
+E: 48.	olcSuffix: "dc=example,dc=net"
+E: 49.	olcDbDirectory: /usr/local/var/openldap-data-net
+E: 50.	olcRootDN: "cn=Manager,dc=example,dc=com"
+E: 51.	olcDbIndex: objectClass eq
+E: 52.	olcAccess: to * by users read
+
+
+H3: Converting from slapd.conf(8) to a {{B:cn=config}} directory format
+
+Discuss slap* -f slapd.conf -F slapd.d/  (man slapd-config)
+
+
+H2: Sets - Granting rights based on relationships
+
+Sets are best illustrated via examples. The following sections will present 
+a few set ACL examples in order to facilitate their understanding.
+
+(Sets in Access Controls FAQ Entry: {{URL:http://www.openldap.org/faq/data/cache/1133.html}})
+
+Note: Sets are considered experimental. 
+
+
+H3: Groups of Groups
+
+The OpenLDAP ACL for groups doesn't expand groups within groups, which are
+groups that have another group as a member. For example:
+
+> dn: cn=sudoadm,ou=group,dc=example,dc=com
+> cn: sudoadm
+> objectClass: groupOfNames
+> member: uid=john,ou=people,dc=example,dc=com
+> member: cn=accountadm,ou=group,dc=example,dc=com
+>
+> dn: cn=accountadm,ou=group,dc=example,dc=com
+> cn: accountadm
+> objectClass: groupOfNames
+> member: uid=mary,ou=people,dc=example,dc=com
+
+If we use standard group ACLs with the above entries and allow members of the
+{{F:sudoadm}} group to write somewhere, {{F:mary}} won't be included:
+
+> access to dn.subtree="ou=sudoers,dc=example,dc=com"
+>         by group.exact="cn=sudoadm,ou=group,dc=example,dc=com" write
+>         by * read
+
+With sets we can make the ACL be recursive and consider group within groups. So
+for each member that is a group, it is further expanded:
+
+> access to dn.subtree="ou=sudoers,dc=example,dc=com"
+>       by set="[cn=sudoadm,ou=group,dc=example,dc=com]/member* & user" write
+>       by * read
+
+This set ACL means: take the {{F:cn=sudoadm}} DN, check its {{F:member}}
+attribute(s) (where the "{{F:*}}" means recursively) and intersect the result
+with the authenticated user's DN. If the result is non-empty, the ACL is
+considered a match and write access is granted.
+
+The following drawing explains how this set is built:
+!import "set-recursivegroup.png"; align="center"; title="Building a recursive group"
+FT[align="Center"] Figure X.Y: Populating a recursive group set
+
+First we get the {{F:uid=john}} DN. This entry doesn't have a {{F:member}}
+attribute, so the expansion stops here.  Now we get to {{F:cn=accountadm}}.
+This one does have a {{F:member}} attribute, which is {{F:uid=mary}}. The
+{{F:uid=mary}} entry, however, doesn't have member, so we stop here again. The
+end comparison is:
+
+> {"uid=john,ou=people,dc=example,dc=com","uid=mary,ou=people,dc=example,dc=com"} & user
+
+If the authenticated user's DN is any one of those two, write access is
+granted. So this set will include {{F:mary}} in the {{F:sudoadm}} group and she
+will be allowed the write access.
+
+H3: Group ACLs without DN syntax
+
+The traditional group ACLs, and even the previous example about recursive groups, require
+that the members are specified as DNs instead of just usernames.
+
+With sets, however, it's also possible to use simple names in group ACLs, as this example will
+show.
+
+Let's say we want to allow members of the {{F:sudoadm}} group to write to the
+{{F:ou=suders}} branch of our tree. But our group definition now is using {{F:memberUid}} for
+the group members:
+
+> dn: cn=sudoadm,ou=group,dc=example,dc=com
+> cn: sudoadm
+> objectClass: posixGroup
+> gidNumber: 1000
+> memberUid: john
+
+With this type of group, we can't use group ACLs. But with a set ACL we can
+grant the desired access:
+
+> access to dn.subtree="ou=sudoers,dc=example,dc=com"
+>       by set="[cn=sudoadm,ou=group,dc=example,dc=com]/memberUid & user/uid" write
+>       by * read
+
+We use a simple intersection where we compare the {{F:uid}} attribute
+of the connecting (and authenticated) user with the {{F:memberUid}} attributes
+of the group. If they match, the intersection is non-empty and the ACL will
+grant write access.
+
+This drawing illustrates this set when the connecting user is authenticated as
+{{F:uid=john,ou=people,dc=example,dc=com}}:
+!import "set-memberUid.png"; align="center"; title="Sets with memberUid"
+FT[align="Center"] Figure X.Y: Sets with {{F:memberUid}}
+
+In this case, it's a match. If it were {{F:mary}} authenticating, however, she
+would be denied write access to {{F:ou=sudoers}} because her {{F:uid}}
+attribute is not listed in the group's {{F:memberUid}}.
+
+H3: Following references
+
+We will now show a quite powerful example of what can be done with sets. This
+example tends to make OpenLDAP administrators smile after they have understood
+it and its implications.
+
+Let's start with an user entry:
+
+> dn: uid=john,ou=people,dc=example,dc=com
+> uid: john
+> objectClass: inetOrgPerson
+> givenName: John
+> sn: Smith
+> cn: john
+> manager: uid=mary,ou=people,dc=example,dc=com
+
+Writing an ACL to allow the manager to update some attributes is quite simple
+using sets:
+
+> access to dn.exact="uid=john,ou=people,dc=example,dc=com"
+>    attrs=carLicense,homePhone,mobile,pager,telephoneNumber
+>    by self write
+>    by set="this/manager & user" write
+>    by * read
+
+In that set, {{F:this}} expands to the entry being accessed, so that
+{{F:this/manager}} expands to {{F:uid=mary,ou=people,dc=example,dc=com}} when
+john's entry is accessed.  If the manager herself is accessing John's entry,
+the ACL will match and write access to those attributes will be granted.
+
+So far, this same behavior can be obtained with the {{F:dnattr}} keyword. With
+sets, however, we can further enhance this ACL. Let's say we want to allow the
+secretary of the manager to also update these attributes. This is how we do it:
+
+> access to dn.exact="uid=john,ou=people,dc=example,dc=com"
+>    attrs=carLicense,homePhone,mobile,pager,telephoneNumber
+>    by self write
+>    by set="this/manager & user" write
+>    by set="this/manager/secretary & user" write
+>    by * read
+
+Now we need a picture to help explain what is happening here (entries shortened
+for clarity):
+
+!import "set-following-references.png"; align="center"; title="Sets jumping through entries"
+FT[align="Center"] Figure X.Y: Sets jumping through entries
+
+In this example, Jane is the secretary of Mary, which is the manager of John.
+This whole relationship is defined with the {{F:manager}} and {{F:secretary}}
+attributes, which are both of the distinguishedName syntax (i.e., full DNs).
+So, when the {{F:uid=john}} entry is being accessed, the
+{{F:this/manager/secretary}} set becomes
+{{F:{"uid=jane,ou=people,dc=example,dc=com"}}} (follow the references in the
+picture):
+
+> this = [uid=john,ou=people,dc=example,dc=com]
+> this/manager = \
+>   [uid=john,ou=people,dc=example,dc=com]/manager = uid=mary,ou=people,dc=example,dc=com
+> this/manager/secretary = \
+>   [uid=mary,ou=people,dc=example,dc=com]/secretary = uid=jane,ou=people,dc=example,dc=com
+
+The end result is that when Jane accesses John's entry, she will be granted
+write access to the specified attributes. Better yet, this will happen to any
+entry she accesses which has Mary as the manager.
+
+This is all cool and nice, but perhaps gives to much power to secretaries. Maybe we need to further
+restrict it. For example, let's only allow executive secretaries to have this power:
+
+> access to dn.exact="uid=john,ou=people,dc=example,dc=com"
+>   attrs=carLicense,homePhone,mobile,pager,telephoneNumber
+>   by self write
+>   by set="this/manager & user" write
+>   by set="this/manager/secretary & 
+>           [cn=executive,ou=group,dc=example,dc=com]/member* & 
+>           user" write
+>   by * read
+
+It's almost the same ACL as before, but we now also require that the connecting user be a member
+of the (possibly nested) {{F:cn=executive}} group.
+
+
diff --git a/doc/guide/admin/aspell.en.pws b/doc/guide/admin/aspell.en.pws
index 086f7d98ea..fe6a20d2f6 100644
--- a/doc/guide/admin/aspell.en.pws
+++ b/doc/guide/admin/aspell.en.pws
@@ -1,4 +1,4 @@
-personal_ws-1.1 en 1559 
+personal_ws-1.1 en 1567 
 commonName
 Masarati
 subjectAltName
@@ -36,8 +36,8 @@ DIB
 dev
 reqNewSuperior
 librewrite
-memberof
 memberOf
+memberof
 BSI
 updateref
 buf
@@ -85,8 +85,8 @@ dlopen
 eng
 AttributeValue
 attributevalue
-DUA
 EOF
+DUA
 inputfile
 DSP
 refreshDone
@@ -112,6 +112,7 @@ GHz
 Bint
 memalloc
 FSF
+usernames
 strtol
 idl
 IDN
@@ -120,10 +121,10 @@ iff
 contextCSN
 auditModify
 auditSearch
-OpenLDAP
 openldap
-resultcode
+OpenLDAP
 resultCode
+resultcode
 sysconfig
 indices
 blen
@@ -156,13 +157,13 @@ argv
 kdz
 notAllowedOnRDN
 hostport
-StartTLS
 starttls
+StartTLS
 ldb
 servercredp
 ldd
-IPv
 ipv
+IPv
 hyc
 joe
 bindmethods
@@ -170,6 +171,7 @@ armijo
 ldp
 ISP
 len
+carLicense
 Choi
 Clatworthy
 scherr
@@ -185,16 +187,16 @@ attrstyle
 directoryOperation
 creatorsName
 mem
-oldPasswdFile
 oldpasswdfile
+oldPasswdFile
 uniqueMember
 krb
 libpath
 acknowledgements
 jts
 createTimestamp
-MIB
 LLL
+MIB
 OpenSSL
 openssl
 LOF
@@ -231,10 +233,10 @@ Subbarao
 aeeiib
 oidlen
 submatches
-PEM
 olc
-OLF
+PEM
 PDU
+OLF
 LDAPSchemaExtensionItem
 auth
 Pierangelo
@@ -271,12 +273,13 @@ rdn
 wZFQrDD
 OTP
 olcSizeLimit
-PRD
-sbi
 pos
+sbi
+PRD
 pre
 stringal
 retoidp
+sudoadm
 sdf
 efgh
 accesslog
@@ -290,8 +293,8 @@ sel
 bvec
 TBC
 stringbv
-SHA
 Sep
+SHA
 ptr
 conn
 pwd
@@ -308,8 +311,8 @@ myOID
 supportedSASLMechanism
 supportedSASLmechanism
 realnamingcontext
-UCD
 SMD
+UCD
 keytab
 portnumber
 uncached
@@ -322,8 +325,8 @@ sasldb
 UCS
 searchDN
 keytbl
-UDP
 tgz
+UDP
 freemods
 prepend
 errText
@@ -340,22 +343,22 @@ crit
 objectClassViolation
 ssf
 ldapfilter
-vec
-TOC
 rwm
+TOC
+vec
 pwdChangedTime
 tls
 peernamestyle
 xpasswd
-SRP
 tmp
+SRP
 SSL
 dupbv
 CPUs
 SRV
 entrymods
-sss
 rwx
+sss
 reqNewRDN
 rebindproc
 olcOverlayConfig
@@ -380,8 +383,8 @@ wildcards
 uri
 tty
 url
-sortKey
 XED
+sortKey
 UTF
 vlv
 TXN
@@ -406,12 +409,13 @@ MANCOMPRESSSUFFIX
 memberAttr
 multiclassing
 memberURL
+sudoers
 pwdMaxFailure
 pseudorootdn
 GDBM
 LIBRELEASE
-DSA's
 DSAs
+DSA's
 realloc
 booleanMatch
 compareTrue
@@ -467,8 +471,8 @@ pwdMinLength
 iZ
 ldapdelete
 xyz
-rdbms
 RDBMs
+rdbms
 extparam
 mk
 ng
@@ -527,8 +531,8 @@ ZZ
 LDVERSION
 testAttr
 backend
-backends
 backend's
+backends
 BerValues
 Solaris
 structs
@@ -540,9 +544,9 @@ ostring
 policyDN
 testObject
 pwdMaxAge
-binddn
-bindDN
 bindDn
+bindDN
+binddn
 distributedOperation
 schemachecking
 strvals
@@ -570,6 +574,7 @@ protocolError
 errno
 errOp
 serverctrls
+recursivegroup
 integerMatch
 moduledir
 dynstyle
@@ -582,14 +587,14 @@ IEEE
 regex
 SIGINT
 slappasswd
-errABsObject
 errAbsObject
+errABsObject
 ldapexop
-objectIdentifier
 objectidentifier
+objectIdentifier
 deallocators
-mirrormode
 MirrorMode
+mirrormode
 loopDetect
 SIGHUP
 authMethodNotSupported
@@ -606,8 +611,8 @@ filtercomp
 expr
 syntaxes
 memrealloc
-returncode
 returnCode
+returncode
 OpenLDAP's
 exts
 bitstringa
@@ -630,8 +635,8 @@ lastName
 lldap
 cachesize
 slapauth
-attributeType
 attributetype
+attributeType
 GSER
 olcDbNosync
 typedef
@@ -665,9 +670,9 @@ proxying
 organisations
 rewriteMap
 monitoredInfo
-modrDN
-ModRDN
 modrdn
+ModRDN
+modrDN
 HREF
 inline
 multiproxy
@@ -679,8 +684,8 @@ reqReferral
 rlookups
 siiiib
 LTSTATIC
-timelimitExceeded
 timeLimitExceeded
+timelimitExceeded
 XKYnrjvGT
 subtrees
 unixODBC
@@ -730,8 +735,8 @@ POSIX
 pathname
 noSuchObject
 proxyOld
-BerElement
 berelement
+BerElement
 sbiod
 plugin
 http
@@ -741,8 +746,8 @@ ldbm
 numericStringSubstringsMatch
 internet
 storages
-WhoAmI
 whoami
+WhoAmI
 criticality
 addBlanks
 logins
@@ -804,6 +809,7 @@ logold
 proxyattrset
 proxyAttrSet
 proxyAttrset
+mary
 crlcheck
 olcBdbConfig
 kadmin
@@ -989,6 +995,7 @@ subord
 namingViolation
 inappropriateAuthentication
 mixin
+suders
 syntaxOID
 olcTLSCACertificateFile
 IGJlZ
@@ -1099,6 +1106,7 @@ dynamicObject
 objectclass
 objectClass
 sizeLimitExceeded
+accountadm
 reqControls
 modme
 shtool
@@ -1408,8 +1416,8 @@ reqOld
 kbyte
 monitorCounter
 quickstart
-olcConstraintConfig
 UUID
+olcConstraintConfig
 rootpw
 veryclean
 syslogged
@@ -1555,6 +1563,6 @@ slimit
 ali
 attributeoptions
 uidNumber
-CA's
 CAs
+CA's
 namingContext
diff --git a/doc/guide/admin/master.sdf b/doc/guide/admin/master.sdf
index 9ec081a91c..d42e9e1daa 100644
--- a/doc/guide/admin/master.sdf
+++ b/doc/guide/admin/master.sdf
@@ -42,6 +42,9 @@ PB:
 !include "slapdconfig.sdf"; chapter
 PB:
 
+!include "access-control.sdf"; chapter
+PB:
+
 !include "runningslapd.sdf"; chapter
 PB:
 
diff --git a/doc/guide/admin/set-following-references.png b/doc/guide/admin/set-following-references.png
new file mode 100644
index 0000000000..2e6ef93f4a
Binary files /dev/null and b/doc/guide/admin/set-following-references.png differ
diff --git a/doc/guide/admin/set-memberUid.png b/doc/guide/admin/set-memberUid.png
new file mode 100644
index 0000000000..0b8e03742c
Binary files /dev/null and b/doc/guide/admin/set-memberUid.png differ
diff --git a/doc/guide/admin/set-recursivegroup.png b/doc/guide/admin/set-recursivegroup.png
new file mode 100644
index 0000000000..3a733b74f7
Binary files /dev/null and b/doc/guide/admin/set-recursivegroup.png differ
diff --git a/doc/guide/admin/slapdconf2.sdf b/doc/guide/admin/slapdconf2.sdf
index c8026294fa..d4c595c4f9 100644
--- a/doc/guide/admin/slapdconf2.sdf
+++ b/doc/guide/admin/slapdconf2.sdf
@@ -399,8 +399,7 @@ H4: olcAccess: to <what> [ by <who> [<accesslevel>] [<control>] ]+
 This directive grants access (specified by <accesslevel>) to a
 set of entries and/or attributes (specified by <what>) by one or
 more requestors (specified by <who>).
-See the {{SECT:Access Control}} section of this chapter for a
-summary of basic usage.
+See the {{SECT:Access Control}} section of this guide for basic usage.
 
 !if 0
 More detailed discussion of this directive can be found in the
@@ -946,534 +945,3 @@ H4: Sample Entry
 >olcDbConfig: set_flags DB_LOG_AUTOREMOVE
 >olcDbIDLcacheSize: 3000
 >olcDbIndex: objectClass eq
-
-
-H2: Access Control
-
-Access to slapd entries and attributes is controlled by the
-olcAccess attribute, whose values are a sequence of access directives.
-The general form of the olcAccess configuration is:
-
->	olcAccess: <access directive>
->	<access directive> ::= to <what>
->		[by <who> [<access>] [<control>] ]+
->	<what> ::= * |
->		[dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
->		[filter=<ldapfilter>] [attrs=<attrlist>]
->	<basic-style> ::= regex | exact
->	<scope-style> ::= base | one | subtree | children
->	<attrlist> ::= <attr> [val[.<basic-style>]=<regex>] | <attr> , <attrlist>
->	<attr> ::= <attrname> | entry | children
->	<who> ::= * | [anonymous | users | self
->			| dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>] 
->		[dnattr=<attrname>]
->		[group[/<objectclass>[/<attrname>][.<basic-style>]]=<regex>]
->		[peername[.<basic-style>]=<regex>]
->		[sockname[.<basic-style>]=<regex>]
->		[domain[.<basic-style>]=<regex>]
->		[sockurl[.<basic-style>]=<regex>]
->		[set=<setspec>]
->		[aci=<attrname>]
->	<access> ::= [self]{<level>|<priv>}
->	<level> ::= none | disclose | auth | compare | search | read | write | manage
->	<priv> ::= {=|+|-}{m|w|r|s|c|x|d|0}+
->	<control> ::= [stop | continue | break]
-
-where the <what> part selects the entries and/or attributes to which
-the access applies, the {{EX:<who>}} part specifies which entities
-are granted access, and the {{EX:<access>}} part specifies the
-access granted. Multiple {{EX:<who> <access> <control>}} triplets
-are supported, allowing many entities to be granted different access
-to the same set of entries and attributes. Not all of these access
-control options are described here; for more details see the
-{{slapd.access}}(5) man page.
-
-
-H3: What to control access to
-
-The <what> part of an access specification determines the entries
-and attributes to which the access control applies.  Entries are
-commonly selected in two ways: by DN and by filter.  The following
-qualifiers select entries by DN:
-
->	to *
->	to dn[.<basic-style>]=<regex>
->	to dn.<scope-style>=<DN>
-
-The first form is used to select all entries.  The second form may
-be used to select entries by matching a regular expression against
-the target entry's {{normalized DN}}.   (The second form is not
-discussed further in this document.)  The third form is used to
-select entries which are within the requested scope of DN.  The
-<DN> is a string representation of the Distinguished Name, as
-described in {{REF:RFC4514}}.
-
-The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}},
-or {{EX:children}}.  Where {{EX:base}} matches only the entry with
-provided DN, {{EX:one}} matches the entries whose parent is the
-provided DN, {{EX:subtree}} matches all entries in the subtree whose
-root is the provided DN, and {{EX:children}} matches all entries
-under the DN (but not the entry named by the DN).
-
-For example, if the directory contained entries named:
-
->	0: o=suffix
->	1: cn=Manager,o=suffix
->	2: ou=people,o=suffix
->	3: uid=kdz,ou=people,o=suffix
->	4: cn=addresses,uid=kdz,ou=people,o=suffix
->	5: uid=hyc,ou=people,o=suffix
-
-\Then:
-. {{EX:dn.base="ou=people,o=suffix"}} match 2;
-. {{EX:dn.one="ou=people,o=suffix"}} match 3, and 5;
-. {{EX:dn.subtree="ou=people,o=suffix"}} match 2, 3, 4, and 5; and
-. {{EX:dn.children="ou=people,o=suffix"}} match 3, 4, and 5.
-
-
-Entries may also be selected using a filter:
-
->	to filter=<ldap filter>
-
-where <ldap filter> is a string representation of an LDAP
-search filter, as described in {{REF:RFC4515}}.  For example:
-
->	to filter=(objectClass=person)
-
-Note that entries may be selected by both DN and filter by
-including both qualifiers in the <what> clause.
-
->	to dn.one="ou=people,o=suffix" filter=(objectClass=person)
-
-Attributes within an entry are selected by including a comma-separated
-list of attribute names in the <what> selector:
-
->	attrs=<attribute list>
-
-A specific value of an attribute is selected by using a single
-attribute name and also using a value selector:
-
->	attrs=<attribute> val[.<style>]=<regex>
-
-There are two special {{pseudo}} attributes {{EX:entry}} and
-{{EX:children}}.  To read (and hence return) a target entry, the
-subject must have {{EX:read}} access to the target's {{entry}}
-attribute.  To add or delete an entry, the subject must have
-{{EX:write}} access to the entry's {{EX:entry}} attribute AND must
-have {{EX:write}} access to the entry's parent's {{EX:children}}
-attribute.  To rename an entry, the subject must have {{EX:write}}
-access to entry's {{EX:entry}} attribute AND have {{EX:write}}
-access to both the old parent's and new parent's {{EX:children}}
-attributes.  The complete examples at the end of this section should
-help clear things up.
-
-Lastly, there is a special entry selector {{EX:"*"}} that is used to
-select any entry.  It is used when no other {{EX:<what>}}
-selector has been provided.  It's equivalent to "{{EX:dn=.*}}"
-
-
-H3: Who to grant access to
-
-The <who> part identifies the entity or entities being granted
-access. Note that access is granted to "entities" not "entries."
-The following table summarizes entity specifiers:
-
-!block table; align=Center; coltags="EX,N"; \
-	title="Table 5.3: Access Entity Specifiers"
-Specifier|Entities
-*|All, including anonymous and authenticated users
-anonymous|Anonymous (non-authenticated) users
-users|Authenticated users
-self|User associated with target entry
-dn[.<basic-style>]=<regex>|Users matching a regular expression
-dn.<scope-style>=<DN>|Users within scope of a DN
-!endblock
-
-The DN specifier behaves much like <what> clause DN specifiers.
-
-Other control factors are also supported.  For example, a {{EX:<who>}}
-can be restricted by an entry listed in a DN-valued attribute in
-the entry to which the access applies:
-
->	dnattr=<dn-valued attribute name>
-
-The dnattr specification is used to give access to an entry
-whose DN is listed in an attribute of the entry (e.g., give
-access to a group entry to whoever is listed as the owner of
-the group entry).
-
-Some factors may not be appropriate in all environments (or any).
-For example, the domain factor relies on IP to domain name lookups.
-As these can easily be spoofed, the domain factor should be avoided.
-
-
-H3: The access to grant
-
-The kind of <access> granted can be one of the following:
-
-!block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
-	title="Table 5.4: Access Levels"
-Level		Privileges	Description
-none		=0			no access
-disclose	=d			needed for information disclosure on error
-auth		=dx			needed to authenticate (bind)
-compare		=cdx		needed to compare
-search		=scdx		needed to apply search filters
-read		=rscdx		needed to read search results
-write		=wrscdx		needed to modify/rename
-manage		=mwrscdx	needed to manage
-!endblock
-
-Each level implies all lower levels of access. So, for example,
-granting someone {{EX:write}} access to an entry also grants them
-{{EX:read}}, {{EX:search}}, {{EX:compare}}, {{EX:auth}} and
-{{EX:disclose}} access.  However, one may use the privileges specifier
-to grant specific permissions.
-
-
-H3: Access Control Evaluation
-
-When evaluating whether some requester should be given access to
-an entry and/or attribute, slapd compares the entry and/or attribute
-to the {{EX:<what>}} selectors given in the configuration.  For
-each entry, access controls provided in the database which holds
-the entry (or the first database if not held in any database) apply
-first, followed by the global access directives (which are held in
-the {{EX:frontend}} database definition).  Within this priority,
-access directives are examined in the order in which they appear
-in the configuration attribute.  Slapd stops with the first
-{{EX:<what>}} selector that matches the entry and/or attribute. The
-corresponding access directive is the one slapd will use to evaluate
-access.
-
-Next, slapd compares the entity requesting access to the {{EX:<who>}}
-selectors within the access directive selected above in the order
-in which they appear. It stops with the first {{EX:<who>}} selector
-that matches the requester. This determines the access the entity
-requesting access has to the entry and/or attribute.
-
-Finally, slapd compares the access granted in the selected
-{{EX:<access>}} clause to the access requested by the client. If
-it allows greater or equal access, access is granted. Otherwise,
-access is denied.
-
-The order of evaluation of access directives makes their placement
-in the configuration file important. If one access directive is
-more specific than another in terms of the entries it selects, it
-should appear first in the configuration. Similarly, if one {{EX:<who>}}
-selector is more specific than another it should come first in the
-access directive. The access control examples given below should
-help make this clear.
-
-
-
-H3: Access Control Examples
-
-The access control facility described above is quite powerful.  This
-section shows some examples of its use for descriptive purposes.
-
-A simple example:
-
->	olcAccess: to * by * read
-
-This access directive grants read access to everyone.
-
->	olcAccess: to *
->		by self write
->		by anonymous auth
->		by * read
-
-This directive allows the user to modify their entry, allows anonymous
-to authenticate against these entries, and allows all others to
-read these entries.  Note that only the first {{EX:by <who>}} clause
-which matches applies.  Hence, the anonymous users are granted
-{{EX:auth}}, not {{EX:read}}.  The last clause could just as well
-have been "{{EX:by users read}}".
-
-It is often desirable to restrict operations based upon the level
-of protection in place.  The following shows how security strength
-factors (SSF) can be used.
-
->	olcAccess: to *
->		by ssf=128 self write
->		by ssf=64 anonymous auth
->		by ssf=64 users read
-
-This directive allows users to modify their own entries if security
-protections of strength 128 or better have been established,
-allows authentication access to anonymous users, and read access
-when strength 64 or better security protections have been established.  If
-the client has not establish sufficient security protections, the
-implicit {{EX:by * none}} clause would be applied.
-
-The following example shows the use of style specifiers to select
-the entries by DN in two access directives where ordering is
-significant.
-
->	olcAccess: to dn.children="dc=example,dc=com"
-> 		by * search
->	olcAccess: to dn.children="dc=com"
-> 		by * read
-
-Read access is granted to entries under the {{EX:dc=com}} subtree,
-except for those entries under the {{EX:dc=example,dc=com}} subtree,
-to which search access is granted.  No access is granted to
-{{EX:dc=com}} as neither access directive matches this DN.  If the
-order of these access directives was reversed, the trailing directive
-would never be reached, since all entries under {{EX:dc=example,dc=com}}
-are also under {{EX:dc=com}} entries.
-
-Also note that if no {{EX:olcAccess: to}} directive matches or no {{EX:by
-<who>}} clause, {{B:access is denied}}.  That is, every {{EX:olcAccess:
-to}} directive ends with an implicit {{EX:by * none}} clause and
-every access list ends with an implicit {{EX:olcAccess: to * by * none}}
-directive.
-
-The next example again shows the importance of ordering, both of
-the access directives and the {{EX:by <who>}} clauses.  It also
-shows the use of an attribute selector to grant access to a specific
-attribute and various {{EX:<who>}} selectors.
-
->	olcAccess: to dn.subtree="dc=example,dc=com" attrs=homePhone
->		by self write
->		by dn.children=dc=example,dc=com" search
->		by peername.regex=IP:10\..+ read
->	olcAccess: to dn.subtree="dc=example,dc=com"
->		by self write
->		by dn.children="dc=example,dc=com" search
->		by anonymous auth
-
-This example applies to entries in the "{{EX:dc=example,dc=com}}"
-subtree. To all attributes except {{EX:homePhone}}, an entry can
-write to itself, entries under {{EX:example.com}} entries can search
-by them, anybody else has no access (implicit {{EX:by * none}})
-excepting for authentication/authorization (which is always done
-anonymously).  The {{EX:homePhone}} attribute is writable by the
-entry, searchable by entries under {{EX:example.com}}, readable by
-clients connecting from network 10, and otherwise not readable
-(implicit {{EX:by * none}}).  All other access is denied by the
-implicit {{EX:access to * by * none}}.
-
-Sometimes it is useful to permit a particular DN to add or
-remove itself from an attribute. For example, if you would like to
-create a group and allow people to add and remove only
-their own DN from the member attribute, you could accomplish
-it with an access directive like this:
-
->	olcAccess: to attrs=member,entry
-> 		by dnattr=member selfwrite
-
-The dnattr {{EX:<who>}} selector says that the access applies to
-entries listed in the {{EX:member}} attribute. The {{EX:selfwrite}} access
-selector says that such members can only add or delete their
-own DN from the attribute, not other values. The addition of
-the entry attribute is required because access to the entry is
-required to access any of the entry's attributes.
-
-
-
-H3: Access Control Ordering
-
-Since the ordering of {{EX:olcAccess}} directives is essential to their
-proper evaluation, but LDAP attributes normally do not preserve the
-ordering of their values, OpenLDAP uses a custom schema extension to
-maintain a fixed ordering of these values. This ordering is maintained
-by prepending a {{EX:"{X}"}} numeric index to each value, similarly to
-the approach used for ordering the configuration entries. These index
-tags are maintained automatically by slapd and do not need to be specified
-when originally defining the values. For example, when you create the
-settings
-
->	olcAccess: to attrs=member,entry
-> 		by dnattr=member selfwrite
->	olcAccess: to dn.children="dc=example,dc=com"
-> 		by * search
->	olcAccess: to dn.children="dc=com"
-> 		by * read
-
-when you read them back using slapcat or ldapsearch they will contain
-
->	olcAccess: {0}to attrs=member,entry
-> 		by dnattr=member selfwrite
->	olcAccess: {1}to dn.children="dc=example,dc=com"
-> 		by * search
->	olcAccess: {2}to dn.children="dc=com"
-> 		by * read
-
-The numeric index may be used to specify a particular value to change
-when using ldapmodify to edit the access rules. This index can be used
-instead of (or in addition to) the actual access value. Using this 
-numeric index is very helpful when multiple access rules are being managed.
-
-For example, if we needed to change the second rule above to grant
-write access instead of search, we could try this LDIF:
-
->	changetype: modify
->	delete: olcAccess
->	olcAccess: to dn.children="dc=example,dc=com" by * search
->	-
->	add: olcAccess
->	olcAccess: to dn.children="dc=example,dc=com" by * write
->	-
-
-But this example {{B:will not}} guarantee that the existing values remain in
-their original order, so it will most likely yield a broken security
-configuration. Instead, the numeric index should be used:
-
->	changetype: modify
->	delete: olcAccess
->	olcAccess: {1}
->	-
->	add: olcAccess
->	olcAccess: {1}to dn.children="dc=example,dc=com" by * write
->	-
-
-This example deletes whatever rule is in value #1 of the {{EX:olcAccess}}
-attribute (regardless of its value) and adds a new value that is
-explicitly inserted as value #1. The result will be
-
->	olcAccess: {0}to attrs=member,entry
-> 		by dnattr=member selfwrite
->	olcAccess: {1}to dn.children="dc=example,dc=com"
-> 		by * write
->	olcAccess: {2}to dn.children="dc=com"
-> 		by * read
-
-which is exactly what was intended.
-
-!if 0
-For more details on how to use the {{EX:access}} directive,
-consult the {{Advanced Access Control}} chapter.
-!endif
-
-
-H2: Configuration Example
-
-The following is an example configuration, interspersed
-with explanatory text. It defines two databases to handle
-different parts of the {{TERM:X.500}} tree; both are {{TERM:BDB}}
-database instances. The line numbers shown are provided for
-reference only and are not included in the actual file. First, the
-global configuration section:
-
-E:  1.	# example config file - global configuration entry
-E:  2.	dn: cn=config
-E:  3.	objectClass: olcGlobal
-E:  4.	cn: config
-E:  5.	olcReferral: ldap://root.openldap.org
-E:  6.	
-
-Line 1 is a comment. Lines 2-4 identify this as the global
-configuration entry.
-The {{EX:olcReferral:}} directive on line 5
-means that queries not local to one of the databases defined
-below will be referred to the LDAP server running on the
-standard port (389) at the host {{EX:root.openldap.org}}.
-Line 6 is a blank line, indicating the end of this entry.
-
-E:  7.	# internal schema
-E:  8.	dn: cn=schema,cn=config
-E:  9.	objectClass: olcSchemaConfig
-E: 10.	cn: schema
-E: 11.	
-
-Line 7 is a comment. Lines 8-10 identify this as the root of
-the schema subtree. The actual schema definitions in this entry
-are hardcoded into slapd so no additional attributes are specified here.
-Line 11 is a blank line, indicating the end of this entry.
-
-E: 12.	# include the core schema
-E: 13.	include: file:///usr/local/etc/openldap/schema/core.ldif
-E: 14.	
-
-Line 12 is a comment. Line 13 is an LDIF include directive which
-accesses the {{core}} schema definitions in LDIF format. Line 14
-is a blank line.
-
-Next comes the database definitions. The first database is the
-special {{EX:frontend}} database whose settings are applied globally
-to all the other databases.
-
-E: 15.	# global database parameters
-E: 16.	dn: olcDatabase=frontend,cn=config
-E: 17.	objectClass: olcDatabaseConfig
-E: 18.	olcDatabase: frontend
-E: 19.	olcAccess: to * by * read
-E: 20.	
-
-Line 15 is a comment. Lines 16-18 identify this entry as the global
-database entry. Line 19 is a global access control. It applies to all
-entries (after any applicable database-specific access controls).
-
-The next entry defines a BDB backend that will handle queries for things
-in the "dc=example,dc=com" portion of the tree. Indices are to be maintained
-for several attributes, and the {{EX:userPassword}} attribute is to be
-protected from unauthorized access.
-
-E: 21.	# BDB definition for example.com
-E: 22.	dn: olcDatabase=bdb,cn=config
-E: 23.	objectClass: olcDatabaseConfig
-E: 24.	objectClass: olcBdbConfig
-E: 25.	olcDatabase: bdb
-E: 26.	olcSuffix: "dc=example,dc=com"
-E: 27.	olcDbDirectory: /usr/local/var/openldap-data
-E: 28.	olcRootDN: "cn=Manager,dc=example,dc=com"
-E: 29.	olcRootPW: secret
-E: 30.	olcDbIndex: uid pres,eq
-E: 31.	olcDbIndex: cn,sn,uid pres,eq,approx,sub
-E: 32.	olcDbIndex: objectClass eq
-E: 33.	olcAccess: to attrs=userPassword
-E: 34.	  by self write
-E: 35.	  by anonymous auth
-E: 36.	  by dn.base="cn=Admin,dc=example,dc=com" write
-E: 37.	  by * none
-E: 38.	olcAccess: to *
-E: 39.	  by self write
-E: 40.	  by dn.base="cn=Admin,dc=example,dc=com" write
-E: 41.	  by * read
-E: 42.	
-
-Line 21 is a comment. Lines 22-25 identify this entry as a BDB database
-configuration entry.  Line 26 specifies the DN suffix
-for queries to pass to this database. Line 27 specifies the directory
-in which the database files will live.
-
-Lines 28 and 29 identify the database {{super-user}} entry and associated
-password. This entry is not subject to access control or size or
-time limit restrictions.
-
-Lines 30 through 32 indicate the indices to maintain for various
-attributes.
-
-Lines 33 through 41 specify access control for entries in this
-database.  As this is the first database, the controls also apply
-to entries not held in any database (such as the Root DSE).  For
-all applicable entries, the {{EX:userPassword}} attribute is writable
-by the entry itself and by the "admin" entry.  It may be used for
-authentication/authorization purposes, but is otherwise not readable.
-All other attributes are writable by the entry and the "admin"
-entry, but may be read by all users (authenticated or not).
-
-Line 42 is a blank line, indicating the end of this entry.
-
-The next section of the example configuration file defines another
-BDB database. This one handles queries involving the
-{{EX:dc=example,dc=net}} subtree but is managed by the same entity
-as the first database.  Note that without line 52, the read access
-would be allowed due to the global access rule at line 19.
-
-E: 43.	# BDB definition for example.net
-E: 44.	dn: olcDatabase=bdb,cn=config
-E: 45.	objectClass: olcDatabaseConfig
-E: 46.	objectClass: olcBdbConfig
-E: 47.	olcDatabase: bdb
-E: 48.	olcSuffix: "dc=example,dc=net"
-E: 49.	olcDbDirectory: /usr/local/var/openldap-data-net
-E: 50.	olcRootDN: "cn=Manager,dc=example,dc=com"
-E: 51.	olcDbIndex: objectClass eq
-E: 52.	olcAccess: to * by users read
-
-
-H2: Converting from slapd.conf(8) to a {{B:cn=config}} directory format
-
-Discuss slap* -f slapd.conf -F slapd.d/  (man slapd-config)
diff --git a/doc/guide/admin/slapdconfig.sdf b/doc/guide/admin/slapdconfig.sdf
index 248c18041a..def9645415 100644
--- a/doc/guide/admin/slapdconfig.sdf
+++ b/doc/guide/admin/slapdconfig.sdf
@@ -91,9 +91,8 @@ H4: access to <what> [ by <who> [<accesslevel>] [<control>] ]+
 
 This directive grants access (specified by <accesslevel>) to a set
 of entries and/or attributes (specified by <what>) by one or more
-requestors (specified by <who>).  See the {{SECT:The access
-Configuration Directive}} section of this chapter for a summary of
-basic usage.
+requestors (specified by <who>).  See the {{SECT:Access Control}} section of 
+this guide for basic usage.
 
 !if 0
 More details discussion of this directive can be found in the
@@ -503,418 +502,3 @@ containing the database and associated indices live.
 \Default:
 
 >	directory /usr/local/var/openldap-data
-
-
-H2: The access Configuration Directive
-
-Access to entries and attributes is controlled by the
-access configuration file directive. The general form of an
-access line is:
-
->	<access directive> ::= access to <what>
->		[by <who> [<access>] [<control>] ]+
->	<what> ::= * |
->		[dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
->		[filter=<ldapfilter>] [attrs=<attrlist>]
->	<basic-style> ::= regex | exact
->	<scope-style> ::= base | one | subtree | children
->	<attrlist> ::= <attr> [val[.<basic-style>]=<regex>] | <attr> , <attrlist>
->	<attr> ::= <attrname> | entry | children
->	<who> ::= * | [anonymous | users | self
->			| dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>] 
->		[dnattr=<attrname>]
->		[group[/<objectclass>[/<attrname>][.<basic-style>]]=<regex>]
->		[peername[.<basic-style>]=<regex>]
->		[sockname[.<basic-style>]=<regex>]
->		[domain[.<basic-style>]=<regex>]
->		[sockurl[.<basic-style>]=<regex>]
->		[set=<setspec>]
->		[aci=<attrname>]
->	<access> ::= [self]{<level>|<priv>}
->	<level> ::= none | disclose | auth | compare | search | read | write | manage
->	<priv> ::= {=|+|-}{m|w|r|s|c|x|d|0}+
->	<control> ::= [stop | continue | break]
-
-where the <what> part selects the entries and/or attributes to which
-the access applies, the {{EX:<who>}} part specifies which entities
-are granted access, and the {{EX:<access>}} part specifies the
-access granted. Multiple {{EX:<who> <access> <control>}} triplets
-are supported, allowing many entities to be granted different access
-to the same set of entries and attributes. Not all of these access
-control options are described here; for more details see the
-{{slapd.access}}(5) man page.
-
-
-H3: What to control access to
-
-The <what> part of an access specification determines the entries
-and attributes to which the access control applies.  Entries are
-commonly selected in two ways: by DN and by filter.  The following
-qualifiers select entries by DN:
-
->	to *
->	to dn[.<basic-style>]=<regex>
->	to dn.<scope-style>=<DN>
-
-The first form is used to select all entries.  The second form may
-be used to select entries by matching a regular expression against
-the target entry's {{normalized DN}}.   (The second form is not
-discussed further in this document.)  The third form is used to
-select entries which are within the requested scope of DN.  The
-<DN> is a string representation of the Distinguished Name, as
-described in {{REF:RFC4514}}.
-
-The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}},
-or {{EX:children}}.  Where {{EX:base}} matches only the entry with
-provided DN, {{EX:one}} matches the entries whose parent is the
-provided DN, {{EX:subtree}} matches all entries in the subtree whose
-root is the provided DN, and {{EX:children}} matches all entries
-under the DN (but not the entry named by the DN).
-
-For example, if the directory contained entries named:
-
->	0: o=suffix
->	1: cn=Manager,o=suffix
->	2: ou=people,o=suffix
->	3: uid=kdz,ou=people,o=suffix
->	4: cn=addresses,uid=kdz,ou=people,o=suffix
->	5: uid=hyc,ou=people,o=suffix
-
-\Then:
-. {{EX:dn.base="ou=people,o=suffix"}} match 2;
-. {{EX:dn.one="ou=people,o=suffix"}} match 3, and 5;
-. {{EX:dn.subtree="ou=people,o=suffix"}} match 2, 3, 4, and 5; and
-. {{EX:dn.children="ou=people,o=suffix"}} match 3, 4, and 5.
-
-
-Entries may also be selected using a filter:
-
->	to filter=<ldap filter>
-
-where <ldap filter> is a string representation of an LDAP
-search filter, as described in {{REF:RFC4515}}.  For example:
-
->	to filter=(objectClass=person)
-
-Note that entries may be selected by both DN and filter by
-including both qualifiers in the <what> clause.
-
->	to dn.one="ou=people,o=suffix" filter=(objectClass=person)
-
-Attributes within an entry are selected by including a comma-separated
-list of attribute names in the <what> selector:
-
->	attrs=<attribute list>
-
-A specific value of an attribute is selected by using a single
-attribute name and also using a value selector:
-
->	attrs=<attribute> val[.<style>]=<regex>
-
-There are two special {{pseudo}} attributes {{EX:entry}} and
-{{EX:children}}.  To read (and hence return) a target entry, the
-subject must have {{EX:read}} access to the target's {{entry}}
-attribute.  To add or delete an entry, the subject must have
-{{EX:write}} access to the entry's {{EX:entry}} attribute AND must
-have {{EX:write}} access to the entry's parent's {{EX:children}}
-attribute.  To rename an entry, the subject must have {{EX:write}}
-access to entry's {{EX:entry}} attribute AND have {{EX:write}}
-access to both the old parent's and new parent's {{EX:children}}
-attributes.  The complete examples at the end of this section should
-help clear things up.
-
-Lastly, there is a special entry selector {{EX:"*"}} that is used to
-select any entry.  It is used when no other {{EX:<what>}}
-selector has been provided.  It's equivalent to "{{EX:dn=.*}}"
-
-
-H3: Who to grant access to
-
-The <who> part identifies the entity or entities being granted
-access. Note that access is granted to "entities" not "entries."
-The following table summarizes entity specifiers:
-
-!block table; align=Center; coltags="EX,N"; \
-	title="Table 6.3: Access Entity Specifiers"
-Specifier|Entities
-*|All, including anonymous and authenticated users
-anonymous|Anonymous (non-authenticated) users
-users|Authenticated users
-self|User associated with target entry
-dn[.<basic-style>]=<regex>|Users matching a regular expression
-dn.<scope-style>=<DN>|Users within scope of a DN
-!endblock
-
-The DN specifier behaves much like <what> clause DN specifiers.
-
-Other control factors are also supported.  For example, a {{EX:<who>}}
-can be restricted by an entry listed in a DN-valued attribute in
-the entry to which the access applies:
-
->	dnattr=<dn-valued attribute name>
-
-The dnattr specification is used to give access to an entry
-whose DN is listed in an attribute of the entry (e.g., give
-access to a group entry to whoever is listed as the owner of
-the group entry).
-
-Some factors may not be appropriate in all environments (or any).
-For example, the domain factor relies on IP to domain name lookups.
-As these can easily be spoofed, the domain factor should be avoided.
-
-
-H3: The access to grant
-
-The kind of <access> granted can be one of the following:
-
-!block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
-	title="Table 6.4: Access Levels"
-Level		Privileges	Description
-none		=0			no access
-disclose	=d			needed for information disclosure on error
-auth		=dx			needed to authenticate (bind)
-compare		=cdx		needed to compare
-search		=scdx		needed to apply search filters
-read		=rscdx		needed to read search results
-write		=wrscdx		needed to modify/rename
-manage		=mwrscdx	needed to manage
-!endblock
-
-Each level implies all lower levels of access. So, for example,
-granting someone {{EX:write}} access to an entry also grants them
-{{EX:read}}, {{EX:search}}, {{EX:compare}}, {{EX:auth}} and
-{{EX:disclose}} access.  However, one may use the privileges specifier
-to grant specific permissions.
-
-
-H3: Access Control Evaluation
-
-When evaluating whether some requester should be given access to
-an entry and/or attribute, slapd compares the entry and/or attribute
-to the {{EX:<what>}} selectors given in the configuration file.
-For each entry, access controls provided in the database which holds
-the entry (or the first database if not held in any database) apply
-first, followed by the global access directives.  Within this
-priority, access directives are examined in the order in which they
-appear in the config file.  Slapd stops with the first {{EX:<what>}}
-selector that matches the entry and/or attribute. The corresponding
-access directive is the one slapd will use to evaluate access.
-
-Next, slapd compares the entity requesting access to the {{EX:<who>}}
-selectors within the access directive selected above in the order
-in which they appear. It stops with the first {{EX:<who>}} selector
-that matches the requester. This determines the access the entity
-requesting access has to the entry and/or attribute.
-
-Finally, slapd compares the access granted in the selected
-{{EX:<access>}} clause to the access requested by the client. If
-it allows greater or equal access, access is granted. Otherwise,
-access is denied.
-
-The order of evaluation of access directives makes their placement
-in the configuration file important. If one access directive is
-more specific than another in terms of the entries it selects, it
-should appear first in the config file. Similarly, if one {{EX:<who>}}
-selector is more specific than another it should come first in the
-access directive. The access control examples given below should
-help make this clear.
-
-
-
-H3: Access Control Examples
-
-The access control facility described above is quite powerful.  This
-section shows some examples of its use for descriptive purposes.
-
-A simple example:
-
->	access to * by * read
-
-This access directive grants read access to everyone.
-
->	access to *
->		by self write
->		by anonymous auth
->		by * read
-
-This directive allows the user to modify their entry, allows anonymous
-to authentication against these entries, and allows all others to
-read these entries.  Note that only the first {{EX:by <who>}} clause
-which matches applies.  Hence, the anonymous users are granted
-{{EX:auth}}, not {{EX:read}}.  The last clause could just as well
-have been "{{EX:by users read}}".
-
-It is often desirable to restrict operations based upon the level
-of protection in place.  The following shows how security strength
-factors (SSF) can be used.
-
->	access to *
->		by ssf=128 self write
->		by ssf=64 anonymous auth
->		by ssf=64 users read
-
-This directive allows users to modify their own entries if security
-protections have of strength 128 or better have been established,
-allows authentication access to anonymous users, and read access
-when 64 or better security protections have been established.  If
-client has not establish sufficient security protections, the
-implicit {{EX:by * none}} clause would be applied.
-
-The following example shows the use of a style specifiers to select
-the entries by DN in two access directives where ordering is
-significant.
-
->	access to dn.children="dc=example,dc=com"
-> 		by * search
->	access to dn.children="dc=com"
-> 		by * read
-
-Read access is granted to entries under the {{EX:dc=com}} subtree,
-except for those entries under the {{EX:dc=example,dc=com}} subtree,
-to which search access is granted.  No access is granted to
-{{EX:dc=com}} as neither access directive matches this DN.  If the
-order of these access directives was reversed, the trailing directive
-would never be reached, since all entries under {{EX:dc=example,dc=com}}
-are also under {{EX:dc=com}} entries.
-
-Also note that if no {{EX:access to}} directive matches or no {{EX:by
-<who>}} clause, {{B:access is denied}}.  That is, every {{EX:access
-to}} directive ends with an implicit {{EX:by * none}} clause and
-every access list ends with an implicit {{EX:access to * by * none}}
-directive.
-
-The next example again shows the importance of ordering, both of
-the access directives and the {{EX:by <who>}} clauses.  It also
-shows the use of an attribute selector to grant access to a specific
-attribute and various {{EX:<who>}} selectors.
-
->	access to dn.subtree="dc=example,dc=com" attrs=homePhone
->		by self write
->		by dn.children="dc=example,dc=com" search
->		by peername.regex=IP:10\..+ read
->	access to dn.subtree="dc=example,dc=com"
->		by self write
->		by dn.children="dc=example,dc=com" search
->		by anonymous auth
-
-This example applies to entries in the "{{EX:dc=example,dc=com}}"
-subtree. To all attributes except {{EX:homePhone}}, an entry can
-write to itself, entries under {{EX:example.com}} entries can search
-by them, anybody else has no access (implicit {{EX:by * none}})
-excepting for authentication/authorization (which is always done
-anonymously).  The {{EX:homePhone}} attribute is writable by the
-entry, searchable by entries under {{EX:example.com}}, readable by
-clients connecting from network 10, and otherwise not readable
-(implicit {{EX:by * none}}).  All other access is denied by the
-implicit {{EX:access to * by * none}}.
-
-Sometimes it is useful to permit a particular DN to add or
-remove itself from an attribute. For example, if you would like to
-create a group and allow people to add and remove only
-their own DN from the member attribute, you could accomplish
-it with an access directive like this:
-
->	access to attrs=member,entry
-> 		by dnattr=member selfwrite
-
-The dnattr {{EX:<who>}} selector says that the access applies to
-entries listed in the {{EX:member}} attribute. The {{EX:selfwrite}} access
-selector says that such members can only add or delete their
-own DN from the attribute, not other values. The addition of
-the entry attribute is required because access to the entry is
-required to access any of the entry's attributes.
-
-!if 0
-For more details on how to use the {{EX:access}} directive,
-consult the {{Advanced Access Control}} chapter.
-!endif
-
-
-H2: Configuration File Example
-
-The following is an example configuration file, interspersed
-with explanatory text. It defines two databases to handle
-different parts of the {{TERM:X.500}} tree; both are {{TERM:BDB}}
-database instances. The line numbers shown are provided for
-reference only and are not included in the actual file. First, the
-global configuration section:
-
-E:  1.	# example config file - global configuration section
-E:  2.	include /usr/local/etc/schema/core.schema
-E:  3.	referral ldap://root.openldap.org
-E:  4.	access to * by * read
- 
-Line 1 is a comment. Line 2 includes another config file
-which contains {{core}} schema definitions.
-The {{EX:referral}} directive on line 3
-means that queries not local to one of the databases defined
-below will be referred to the LDAP server running on the
-standard port (389) at the host {{EX:root.openldap.org}}.
-
-Line 4 is a global access control.  It applies to all
-entries (after any applicable database-specific access
-controls).
-
-The next section of the configuration file defines a BDB
-backend that will handle queries for things in the
-"dc=example,dc=com" portion of the tree. The
-database is to be replicated to two slave slapds, one on
-truelies, the other on judgmentday. Indices are to be
-maintained for several attributes, and the {{EX:userPassword}}
-attribute is to be protected from unauthorized access.
-
-E:  5.	# BDB definition for the example.com
-E:  6.	database bdb
-E:  7.	suffix "dc=example,dc=com"
-E:  8.	directory /usr/local/var/openldap-data
-E:  9.	rootdn "cn=Manager,dc=example,dc=com"
-E: 10.	rootpw secret
-E: 11.	# indexed attribute definitions
-E: 12.	index uid pres,eq
-E: 13.	index cn,sn,uid pres,eq,approx,sub
-E: 14.	index objectClass eq
-E: 15.	# database access control definitions
-E: 16.	access to attrs=userPassword
-E: 17.		by self write
-E: 18.		by anonymous auth
-E: 19.		by dn.base="cn=Admin,dc=example,dc=com" write
-E: 20.		by * none
-E: 21.	access to *
-E: 22.		by self write
-E: 23.		by dn.base="cn=Admin,dc=example,dc=com" write
-E: 24.		by * read
-
-Line 5 is a comment. The start of the database definition is marked
-by the database keyword on line 6. Line 7 specifies the DN suffix
-for queries to pass to this database. Line 8 specifies the directory
-in which the database files will live.
-
-Lines 9 and 10 identify the database {{super-user}} entry and associated
-password. This entry is not subject to access control or size or
-time limit restrictions.
-
-Lines 12 through 14 indicate the indices to maintain for various
-attributes.
-
-Lines 16 through 24 specify access control for entries in this
-database.  As this is the first database, the controls also apply
-to entries not held in any database (such as the Root DSE).  For
-all applicable entries, the {{EX:userPassword}} attribute is writable
-by the entry itself and by the "admin" entry.  It may be used for
-authentication/authorization purposes, but is otherwise not readable.
-All other attributes are writable by the entry and the "admin"
-entry, but may be read by all users (authenticated or not).
-
-The next section of the example configuration file defines another
-BDB database. This one handles queries involving the
-{{EX:dc=example,dc=net}} subtree but is managed by the same entity
-as the first database.  Note that without line 39, the read access
-would be allowed due to the global access rule at line 4.
-
-E: 33.	# BDB definition for example.net
-E: 34.	database bdb
-E: 35.	suffix "dc=example,dc=net"
-E: 36.	directory /usr/local/var/openldap-data-net
-E: 37.	rootdn "cn=Manager,dc=example,dc=com"
-E: 38.	index objectClass eq
-E: 39.	access to * by users read
diff --git a/doc/guide/images/src/set-following-references.svg b/doc/guide/images/src/set-following-references.svg
new file mode 100644
index 0000000000..6b15705c3a
--- /dev/null
+++ b/doc/guide/images/src/set-following-references.svg
@@ -0,0 +1,272 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://web.resource.org/cc/"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="383.93671"
+   height="174.87033"
+   id="svg2"
+   sodipodi:version="0.32"
+   inkscape:version="0.45.1"
+   version="1.0"
+   sodipodi:docbase="/home/andreas/cvs/openldap-guide/images/src"
+   sodipodi:docname="set-managersecretary.svg"
+   inkscape:output_extension="org.inkscape.output.svg.inkscape"
+   inkscape:export-filename="/home/andreas/palestra/managersecretary.png"
+   inkscape:export-xdpi="187.53"
+   inkscape:export-ydpi="187.53">
+  <defs
+     id="defs4">
+    <marker
+       inkscape:stockid="Arrow1Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Lend"
+       style="overflow:visible">
+      <path
+         id="path3186"
+         d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
+         style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
+         transform="matrix(-0.8,0,0,-0.8,-10,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Lstart"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Lstart"
+       style="overflow:visible">
+      <path
+         id="path3183"
+         d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
+         style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
+         transform="matrix(0.8,0,0,0.8,10,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Send"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Send"
+       style="overflow:visible">
+      <path
+         id="path3198"
+         d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
+         style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
+         transform="matrix(-0.2,0,0,-0.2,-1.2,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lstart"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Lstart"
+       style="overflow:visible">
+      <path
+         id="path3201"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
+         transform="matrix(1.1,0,0,1.1,1.1,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Lend"
+       style="overflow:visible">
+      <path
+         id="path8347"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)" />
+    </marker>
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="3.1307244"
+     inkscape:cx="191.96835"
+     inkscape:cy="87.435165"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="true"
+     showguides="false"
+     inkscape:window-width="1280"
+     inkscape:window-height="953"
+     inkscape:window-x="0"
+     inkscape:window-y="24"
+     width="1052.3622px"
+     height="744.09449px" />
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Camada 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-241.56641,-98.789978)">
+    <g
+       id="g3270"
+       transform="translate(0,-9.9371414e-6)">
+      <text
+         inkscape:export-ydpi="136.2"
+         inkscape:export-xdpi="136.2"
+         inkscape:export-filename="/home/andreas/palestra/allmail.png"
+         id="text2170"
+         y="112.12766"
+         x="267.92389"
+         style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="112.12766"
+           x="267.92389"
+           id="tspan2172"
+           sodipodi:role="line">DN: uid=john,ou=people,dc=example,dc=com</tspan><tspan
+           id="tspan2174"
+           y="127.12766"
+           x="267.92389"
+           sodipodi:role="line">uid: john</tspan><tspan
+           id="tspan5373"
+           y="142.12766"
+           x="267.92389"
+           sodipodi:role="line">manager: uid=mary,ou=people,dc=example,dc=com</tspan><tspan
+           id="tspan3411"
+           y="157.12766"
+           x="267.92389"
+           sodipodi:role="line" /></text>
+      <rect
+         inkscape:export-ydpi="136.2"
+         inkscape:export-xdpi="136.2"
+         inkscape:export-filename="/home/andreas/palestra/allmail.png"
+         y="99.161621"
+         x="263.56467"
+         height="53.761242"
+         width="331.86697"
+         id="rect7321"
+         style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.74326539px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+      <rect
+         inkscape:export-ydpi="136.2"
+         inkscape:export-xdpi="136.2"
+         inkscape:export-filename="/home/andreas/palestra/allmail.png"
+         y="130.60817"
+         x="265.52121"
+         height="17.286547"
+         width="327.07599"
+         id="rect7323"
+         style="opacity:0.28915663;fill:#aa9ab2;fill-opacity:1;stroke:none;stroke-width:0.69669151;stroke-opacity:1" />
+    </g>
+    <text
+       xml:space="preserve"
+       style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="299.92389"
+       y="250.12769"
+       id="text2235"
+       inkscape:export-filename="/home/andreas/palestra/allmail.png"
+       inkscape:export-xdpi="136.2"
+       inkscape:export-ydpi="136.2"><tspan
+         sodipodi:role="line"
+         id="tspan2237"
+         x="299.92389"
+         y="250.12769">DN: uid=jane,ou=people,dc=example,dc=com</tspan><tspan
+         sodipodi:role="line"
+         x="299.92389"
+         y="265.12769"
+         id="tspan2239">uid: jane</tspan><tspan
+         sodipodi:role="line"
+         x="299.92389"
+         y="280.12769"
+         id="tspan2241" /><tspan
+         sodipodi:role="line"
+         x="299.92389"
+         y="295.12769"
+         id="tspan2243" /></text>
+    <rect
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.60843331px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       id="rect2245"
+       width="329.70166"
+       height="36.261875"
+       x="295.49725"
+       y="237.09422"
+       inkscape:export-filename="/home/andreas/palestra/allmail.png"
+       inkscape:export-xdpi="136.2"
+       inkscape:export-ydpi="136.2" />
+    <g
+       id="g3279"
+       transform="translate(0,-1.3751839e-5)">
+      <text
+         xml:space="preserve"
+         style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="283.92386"
+         y="181.12766"
+         id="text2223"
+         inkscape:export-filename="/home/andreas/palestra/allmail.png"
+         inkscape:export-xdpi="136.2"
+         inkscape:export-ydpi="136.2"><tspan
+           sodipodi:role="line"
+           id="tspan2225"
+           x="283.92386"
+           y="181.12766">DN: uid=mary,ou=people,dc=example,dc=com</tspan><tspan
+           sodipodi:role="line"
+           x="283.92386"
+           y="196.12766"
+           id="tspan2227">uid: mary</tspan><tspan
+           sodipodi:role="line"
+           x="283.92386"
+           y="211.12766"
+           id="tspan2229">secretary: uid=jane,ou=people,dc=example,dc=com</tspan><tspan
+           sodipodi:role="line"
+           x="283.92386"
+           y="226.12766"
+           id="tspan2231" /></text>
+      <rect
+         style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.74326539px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+         id="rect2233"
+         width="331.86697"
+         height="53.761246"
+         x="279.56464"
+         y="168.16162"
+         inkscape:export-filename="/home/andreas/palestra/allmail.png"
+         inkscape:export-xdpi="136.2"
+         inkscape:export-ydpi="136.2" />
+      <rect
+         style="opacity:0.28915663;fill:#aa9ab2;fill-opacity:1;stroke:none;stroke-width:0.69669151;stroke-opacity:1"
+         id="rect2247"
+         width="327.07599"
+         height="17.286547"
+         x="281.52118"
+         y="197.60815"
+         inkscape:export-filename="/home/andreas/palestra/allmail.png"
+         inkscape:export-xdpi="136.2"
+         inkscape:export-ydpi="136.2" />
+    </g>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Lend);stroke-opacity:1"
+       d="M 147.97396,105.42967 C 100.43828,122.29717 161.77464,141.46478 161.77464,141.46478"
+       id="path2275"
+       transform="translate(112.15223,34.695502)"
+       sodipodi:nodetypes="cc" />
+    <path
+       sodipodi:nodetypes="cc"
+       id="path3248"
+       d="M 276.12619,208.12517 C 228.59051,224.99267 289.92687,244.16028 289.92687,244.16028"
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Lend);stroke-opacity:1" />
+  </g>
+</svg>
diff --git a/doc/guide/images/src/set-memberUid.svg b/doc/guide/images/src/set-memberUid.svg
new file mode 100644
index 0000000000..52e958b341
--- /dev/null
+++ b/doc/guide/images/src/set-memberUid.svg
@@ -0,0 +1,272 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://web.resource.org/cc/"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="746.3288"
+   height="127.80122"
+   id="svg2"
+   sodipodi:version="0.32"
+   inkscape:version="0.45.1"
+   version="1.0"
+   sodipodi:docbase="/home/andreas/cvs/openldap-guide/images/src"
+   sodipodi:docname="set-memberUid.svg"
+   inkscape:output_extension="org.inkscape.output.svg.inkscape"
+   inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+   inkscape:export-xdpi="70.18"
+   inkscape:export-ydpi="70.18">
+  <defs
+     id="defs4">
+    <marker
+       inkscape:stockid="Arrow1Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Lend"
+       style="overflow:visible">
+      <path
+         id="path3186"
+         d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
+         style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
+         transform="matrix(-0.8,0,0,-0.8,-10,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Lstart"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Lstart"
+       style="overflow:visible">
+      <path
+         id="path3183"
+         d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
+         style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
+         transform="matrix(0.8,0,0,0.8,10,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Send"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Send"
+       style="overflow:visible">
+      <path
+         id="path3198"
+         d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
+         style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
+         transform="matrix(-0.2,0,0,-0.2,-1.2,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lstart"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Lstart"
+       style="overflow:visible">
+      <path
+         id="path3201"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
+         transform="matrix(1.1,0,0,1.1,1.1,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Lend"
+       style="overflow:visible">
+      <path
+         id="path8347"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)" />
+    </marker>
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="1.6105502"
+     inkscape:cx="373.1644"
+     inkscape:cy="63.900612"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="true"
+     showguides="false"
+     inkscape:window-width="1280"
+     inkscape:window-height="953"
+     inkscape:window-x="0"
+     inkscape:window-y="24"
+     width="1052.3622px"
+     height="744.09449px" />
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Camada 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-164.76663,-192.97633)">
+    <text
+       xml:space="preserve"
+       style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="177.73021"
+       y="206.31401"
+       id="text2170"
+       inkscape:export-filename="/home/andreas/palestra/allmail.png"
+       inkscape:export-xdpi="136.2"
+       inkscape:export-ydpi="136.2"><tspan
+         sodipodi:role="line"
+         id="tspan2172"
+         x="177.73021"
+         y="206.31401">DN: cn=sudoadm,ou=group,dc=example,dc=com</tspan><tspan
+         sodipodi:role="line"
+         x="177.73021"
+         y="221.31401"
+         id="tspan2174">cn: sudoadm</tspan><tspan
+         sodipodi:role="line"
+         x="177.73021"
+         y="236.31401"
+         id="tspan5373">objectClass: posixGroup</tspan><tspan
+         sodipodi:role="line"
+         x="177.73021"
+         y="251.31401"
+         id="tspan2336">gidNumber: 1000</tspan><tspan
+         sodipodi:role="line"
+         x="177.73021"
+         y="266.31401"
+         id="tspan3411">memberUid: john</tspan></text>
+    <rect
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.98517001px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       id="rect7321"
+       width="316.56842"
+       height="99.014832"
+       x="173.49196"
+       y="193.46892"
+       inkscape:export-filename="/home/andreas/palestra/allmail.png"
+       inkscape:export-xdpi="136.2"
+       inkscape:export-ydpi="136.2" />
+    <rect
+       inkscape:export-ydpi="136.2"
+       inkscape:export-xdpi="136.2"
+       inkscape:export-filename="/home/andreas/palestra/allmail.png"
+       y="255.51881"
+       x="175.66292"
+       height="16.666452"
+       width="107.33646"
+       id="rect5582"
+       style="opacity:0.28915663;fill:#aa9ab2;fill-opacity:1;stroke:none;stroke-width:0.69669151;stroke-opacity:1" />
+    <path
+       style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker-start:url(#Arrow2Lstart);marker-end:url(#Arrow2Lend);stroke-opacity:1"
+       d="M 288.18971,264.67045 C 388.9562,262.34006 478.83987,220.53502 612.19092,219.08835"
+       id="path7687"
+       sodipodi:nodetypes="cc"
+       inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+       inkscape:export-xdpi="80.970001"
+       inkscape:export-ydpi="80.970001" />
+    <g
+       id="g3381"
+       transform="translate(86,0)">
+      <text
+         xml:space="preserve"
+         style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="534.08191"
+         y="208.5367"
+         id="text3318"
+         inkscape:export-filename="/home/andreas/palestra/allmail.png"
+         inkscape:export-xdpi="136.2"
+         inkscape:export-ydpi="136.2"><tspan
+           sodipodi:role="line"
+           id="tspan3320"
+           x="534.08191"
+           y="208.5367">DN: uid=john,ou=people,dc=example,dc=com</tspan><tspan
+           sodipodi:role="line"
+           x="534.08191"
+           y="223.5367"
+           id="tspan3322">uid: john</tspan><tspan
+           sodipodi:role="line"
+           x="534.08191"
+           y="238.5367"
+           id="tspan3324">objectClass: person</tspan><tspan
+           sodipodi:role="line"
+           x="534.08191"
+           y="253.5367"
+           id="tspan3326">cn: john</tspan><tspan
+           id="tspan3334"
+           sodipodi:role="line"
+           x="534.08191"
+           y="268.5367">givenName: John</tspan><tspan
+           sodipodi:role="line"
+           x="534.08191"
+           y="283.5367"
+           id="tspan3330">sn: Smith</tspan></text>
+      <rect
+         style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.94494522px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+         id="rect3336"
+         width="294.23233"
+         height="98.00956"
+         x="530.39062"
+         y="194.49431"
+         inkscape:export-filename="/home/andreas/palestra/allmail.png"
+         inkscape:export-xdpi="136.2"
+         inkscape:export-ydpi="136.2" />
+      <rect
+         inkscape:export-ydpi="136.2"
+         inkscape:export-xdpi="136.2"
+         inkscape:export-filename="/home/andreas/palestra/allmail.png"
+         y="211.30989"
+         x="533.61841"
+         height="16.666452"
+         width="57.336445"
+         id="rect2372"
+         style="opacity:0.28915663;fill:#aa9ab2;fill-opacity:1;stroke:none;stroke-width:0.69669151;stroke-opacity:1" />
+    </g>
+    <text
+       xml:space="preserve"
+       style="font-size:12px;font-style:italic;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="164.28616"
+       y="318.28146"
+       id="text3369"><tspan
+         sodipodi:role="line"
+         id="tspan3371"
+         x="164.28616"
+         y="318.28146">[cn=sudoadm,ou=group,dc=example,dc=com]/memberUid</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:12px;font-style:italic;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="646.18683"
+       y="318.97287"
+       id="text3373"><tspan
+         sodipodi:role="line"
+         id="tspan3375"
+         x="646.18683"
+         y="318.97287">user/uid</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:12px;font-style:italic;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="581.57733"
+       y="319.33908"
+       id="text3377"><tspan
+         sodipodi:role="line"
+         id="tspan3379"
+         x="581.57733"
+         y="319.33908">&amp;</tspan></text>
+  </g>
+</svg>
diff --git a/doc/guide/images/src/set-recursivegroup.svg b/doc/guide/images/src/set-recursivegroup.svg
new file mode 100644
index 0000000000..07785816d1
--- /dev/null
+++ b/doc/guide/images/src/set-recursivegroup.svg
@@ -0,0 +1,497 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://web.resource.org/cc/"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="833.63007"
+   height="212.5425"
+   id="svg2"
+   sodipodi:version="0.32"
+   inkscape:version="0.45.1"
+   version="1.0"
+   sodipodi:docbase="/home/andreas/cvs/openldap-guide/images/src"
+   sodipodi:docname="set-recursivegroup.svg"
+   inkscape:output_extension="org.inkscape.output.svg.inkscape"
+   inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+   inkscape:export-xdpi="70.18"
+   inkscape:export-ydpi="70.18">
+  <defs
+     id="defs4">
+    <marker
+       inkscape:stockid="Arrow1Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Lend"
+       style="overflow:visible">
+      <path
+         id="path3186"
+         d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
+         style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
+         transform="matrix(-0.8,0,0,-0.8,-10,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Lstart"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Lstart"
+       style="overflow:visible">
+      <path
+         id="path3183"
+         d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
+         style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
+         transform="matrix(0.8,0,0,0.8,10,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Send"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Send"
+       style="overflow:visible">
+      <path
+         id="path3198"
+         d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
+         style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
+         transform="matrix(-0.2,0,0,-0.2,-1.2,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lstart"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Lstart"
+       style="overflow:visible">
+      <path
+         id="path3201"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
+         transform="matrix(1.1,0,0,1.1,1.1,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Lend"
+       style="overflow:visible">
+      <path
+         id="path8347"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)" />
+    </marker>
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="1.1313286"
+     inkscape:cx="471.10533"
+     inkscape:cy="166.19896"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="true"
+     showguides="false"
+     inkscape:window-width="1280"
+     inkscape:window-height="953"
+     inkscape:window-x="0"
+     inkscape:window-y="24"
+     width="1052.3622px"
+     height="744.09449px" />
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Camada 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-39.91817,-73.881854)">
+    <g
+       id="g3462"
+       transform="translate(30.553822,-0.6080081)"
+       inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+       inkscape:export-xdpi="80.970001"
+       inkscape:export-ydpi="80.970001">
+      <text
+         xml:space="preserve"
+         style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="523.97247"
+         y="89.280624"
+         id="text3318"
+         inkscape:export-filename="/home/andreas/palestra/allmail.png"
+         inkscape:export-xdpi="136.2"
+         inkscape:export-ydpi="136.2"><tspan
+           sodipodi:role="line"
+           id="tspan3320"
+           x="523.97247"
+           y="89.280624">DN: <tspan
+   style="font-weight:bold"
+   id="tspan7581">uid=john,ou=people,dc=example,dc=com</tspan></tspan><tspan
+           sodipodi:role="line"
+           x="523.97247"
+           y="104.28062"
+           id="tspan3322">uid: john</tspan><tspan
+           sodipodi:role="line"
+           x="523.97247"
+           y="119.28062"
+           id="tspan3324">objectClass: person</tspan><tspan
+           sodipodi:role="line"
+           x="523.97247"
+           y="134.28062"
+           id="tspan3326">cn: john</tspan><tspan
+           id="tspan3334"
+           sodipodi:role="line"
+           x="523.97247"
+           y="149.28062">givenName: John</tspan><tspan
+           sodipodi:role="line"
+           x="523.97247"
+           y="164.28062"
+           id="tspan3330">sn: Smith</tspan></text>
+      <rect
+         style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.97567958px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+         id="rect3336"
+         width="318.06735"
+         height="96.658691"
+         x="520.29657"
+         y="75.253609"
+         inkscape:export-filename="/home/andreas/palestra/allmail.png"
+         inkscape:export-xdpi="136.2"
+         inkscape:export-ydpi="136.2" />
+    </g>
+    <g
+       id="g3474"
+       transform="translate(30.276908,4.0242246)"
+       inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+       inkscape:export-xdpi="80.970001"
+       inkscape:export-ydpi="80.970001">
+      <g
+         id="g7676">
+        <text
+           xml:space="preserve"
+           style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+           x="523.97247"
+           y="199.28062"
+           id="text3416"
+           inkscape:export-filename="/home/andreas/palestra/allmail.png"
+           inkscape:export-xdpi="136.2"
+           inkscape:export-ydpi="136.2"><tspan
+             sodipodi:role="line"
+             id="tspan3418"
+             x="523.97247"
+             y="199.28062">DN: <tspan
+   id="tspan7674"
+   style="font-weight:bold">uid=mary,ou=people,dc=example,dc=com</tspan></tspan><tspan
+             sodipodi:role="line"
+             x="523.97247"
+             y="214.28062"
+             id="tspan3420">uid: mary</tspan><tspan
+             sodipodi:role="line"
+             x="523.97247"
+             y="229.28062"
+             id="tspan3422">objectClass: person</tspan><tspan
+             sodipodi:role="line"
+             x="523.97247"
+             y="244.28062"
+             id="tspan3424">cn: mary</tspan><tspan
+             id="tspan3426"
+             sodipodi:role="line"
+             x="523.97247"
+             y="259.28062">givenName: Mary</tspan><tspan
+             sodipodi:role="line"
+             x="523.97247"
+             y="274.28062"
+             id="tspan3432">sn: Smith</tspan></text>
+        <rect
+           style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.98239046px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+           id="rect3460"
+           width="322.48019"
+           height="96.651978"
+           x="520.29993"
+           y="185.25696"
+           inkscape:export-filename="/home/andreas/palestra/allmail.png"
+           inkscape:export-xdpi="136.2"
+           inkscape:export-ydpi="136.2" />
+      </g>
+    </g>
+    <g
+       id="g7550"
+       transform="translate(-109.4887,-12.321663)"
+       inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+       inkscape:export-xdpi="80.970001"
+       inkscape:export-ydpi="80.970001">
+      <g
+         id="g7614"
+         transform="translate(-103.41823,-0.8839165)">
+        <text
+           inkscape:export-ydpi="136.2"
+           inkscape:export-xdpi="136.2"
+           inkscape:export-filename="/home/andreas/palestra/allmail.png"
+           id="text3350"
+           y="216.91795"
+           x="258.37482"
+           style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+           xml:space="preserve"><tspan
+             y="216.91795"
+             x="258.37482"
+             id="tspan3352"
+             sodipodi:role="line">DN: cn=accountadm,ou=group,dc=example,dc=com</tspan><tspan
+             id="tspan3354"
+             y="231.91795"
+             x="258.37482"
+             sodipodi:role="line">cn: accountadm</tspan><tspan
+             id="tspan3356"
+             y="246.91795"
+             x="258.37482"
+             sodipodi:role="line">objectClass: groupOfNames</tspan><tspan
+             id="tspan3360"
+             y="261.91795"
+             x="258.37482"
+             sodipodi:role="line">member: <tspan
+   id="tspan7612"
+   style="font-weight:bold">uid=mary,ou=people,dc=example,dc=com</tspan></tspan><tspan
+             id="tspan3362"
+             y="276.91795"
+             x="258.37482"
+             sodipodi:role="line" /></text>
+        <rect
+           inkscape:export-ydpi="136.2"
+           inkscape:export-xdpi="136.2"
+           inkscape:export-filename="/home/andreas/palestra/allmail.png"
+           y="203.48654"
+           x="254.13257"
+           height="83.046989"
+           width="371.37915"
+           id="rect3402"
+           style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.97723264px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+        <rect
+           inkscape:export-ydpi="136.2"
+           inkscape:export-xdpi="136.2"
+           inkscape:export-filename="/home/andreas/palestra/allmail.png"
+           y="249.90959"
+           x="256.3075"
+           height="16.297295"
+           width="351.43427"
+           id="rect5542"
+           style="opacity:0.28915663;fill:#aa9ab2;fill-opacity:1;stroke:none;stroke-width:0.69669151;stroke-opacity:1" />
+      </g>
+    </g>
+    <g
+       id="g7662"
+       transform="translate(-217.44346,0.8839165)"
+       inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+       inkscape:export-xdpi="80.970001"
+       inkscape:export-ydpi="80.970001">
+      <text
+         inkscape:export-ydpi="136.2"
+         inkscape:export-xdpi="136.2"
+         inkscape:export-filename="/home/andreas/palestra/allmail.png"
+         id="text2170"
+         y="86.335617"
+         x="262.09247"
+         style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="86.335617"
+           x="262.09247"
+           id="tspan2172"
+           sodipodi:role="line">DN: <tspan
+   style="font-weight:bold"
+   id="tspan7595">cn=sudoadm,ou=group,dc=example,dc=com</tspan></tspan><tspan
+           id="tspan2174"
+           y="101.33562"
+           x="262.09247"
+           sodipodi:role="line">cn: sudoadm</tspan><tspan
+           id="tspan5373"
+           y="116.33562"
+           x="262.09247"
+           sodipodi:role="line">objectClass: groupOfNames</tspan><tspan
+           id="tspan3295"
+           y="131.33562"
+           x="262.09247"
+           sodipodi:role="line">member: uid=john,ou=people,dc=example,dc=com</tspan><tspan
+           id="tspan3297"
+           y="146.33562"
+           x="262.09247"
+           sodipodi:role="line">member: cn=accountadm,ou=people,dc=example,dc=com</tspan><tspan
+           id="tspan3411"
+           y="161.33562"
+           x="262.09247"
+           sodipodi:role="line" /></text>
+      <rect
+         inkscape:export-ydpi="136.2"
+         inkscape:export-xdpi="136.2"
+         inkscape:export-filename="/home/andreas/palestra/allmail.png"
+         y="73.485397"
+         x="257.84909"
+         height="83.049301"
+         width="369.61365"
+         id="rect7321"
+         style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.97492063px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+      <rect
+         style="opacity:0.28915663;fill:#aa9ab2;fill-opacity:1;stroke:none;stroke-width:0.69669151;stroke-opacity:1"
+         id="rect5582"
+         width="365.16586"
+         height="31.950695"
+         x="260.02518"
+         y="120.25619"
+         inkscape:export-filename="/home/andreas/palestra/allmail.png"
+         inkscape:export-xdpi="136.2"
+         inkscape:export-ydpi="136.2" />
+    </g>
+    <text
+       xml:space="preserve"
+       style="font-size:12px;font-style:italic;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="364.2525"
+       y="224.56728"
+       id="text7528"
+       inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+       inkscape:export-xdpi="80.970001"
+       inkscape:export-ydpi="80.970001"><tspan
+         sodipodi:role="line"
+         id="tspan7530"
+         x="364.2525"
+         y="224.56728">yes!</tspan></text>
+    <path
+       style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Lend);stroke-opacity:1"
+       d="M 365.29385,128.78999 C 466.06034,130.87918 457.22118,89.335108 547.38066,84.915525"
+       id="path7687"
+       sodipodi:nodetypes="cc"
+       inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+       inkscape:export-xdpi="80.970001"
+       inkscape:export-ydpi="80.970001" />
+    <path
+       style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Lend);stroke-opacity:1"
+       d="M 407.72184,145.90577 C 440.42676,177.72675 428.93584,200.70858 374.13302,201.5925"
+       id="path7689"
+       sodipodi:nodetypes="cc"
+       inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+       inkscape:export-xdpi="80.970001"
+       inkscape:export-ydpi="80.970001" />
+    <path
+       sodipodi:nodetypes="cc"
+       id="path7691"
+       d="M 396.23093,243.6739 C 484.62258,241.34352 479.3191,199.79944 547.38066,198.91553"
+       style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Lend);stroke-opacity:1"
+       inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+       inkscape:export-xdpi="80.970001"
+       inkscape:export-ydpi="80.970001" />
+    <text
+       id="text9637"
+       y="232.54912"
+       x="473.47699"
+       style="font-size:12px;font-style:italic;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       xml:space="preserve"
+       inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+       inkscape:export-xdpi="80.970001"
+       inkscape:export-ydpi="80.970001"><tspan
+         y="232.54912"
+         x="473.47699"
+         id="tspan9639"
+         sodipodi:role="line">more<tspan
+   id="tspan9641"
+   style="font-weight:bold"></tspan></tspan><tspan
+         y="247.54912"
+         x="473.47699"
+         sodipodi:role="line"
+         id="tspan9643"><tspan
+   style="font-weight:bold"
+   id="tspan9645">member</tspan>?</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:12px;font-style:italic;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="473.47699"
+       y="112.54912"
+       id="text9647"
+       inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+       inkscape:export-xdpi="80.970001"
+       inkscape:export-ydpi="80.970001"><tspan
+         sodipodi:role="line"
+         id="tspan9649"
+         x="473.47699"
+         y="112.54912">more<tspan
+   style="font-weight:bold"
+   id="tspan9651"></tspan></tspan><tspan
+         id="tspan9653"
+         sodipodi:role="line"
+         x="473.47699"
+         y="127.54912"><tspan
+   id="tspan9655"
+   style="font-weight:bold">member</tspan>?</tspan></text>
+    <text
+       id="text10626"
+       y="173.85262"
+       x="431.01266"
+       style="font-size:12px;font-style:italic;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       xml:space="preserve"
+       inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+       inkscape:export-xdpi="80.970001"
+       inkscape:export-ydpi="80.970001"><tspan
+         y="173.85262"
+         x="431.01266"
+         id="tspan10628"
+         sodipodi:role="line">more<tspan
+   id="tspan10630"
+   style="font-weight:bold"></tspan></tspan><tspan
+         y="188.85262"
+         x="431.01266"
+         sodipodi:role="line"
+         id="tspan10632"><tspan
+   style="font-weight:bold"
+   id="tspan10634">member</tspan>?</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:12px;font-style:italic;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="742.7262"
+       y="130.87918"
+       id="text10640"
+       inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+       inkscape:export-xdpi="80.970001"
+       inkscape:export-ydpi="80.970001"><tspan
+         sodipodi:role="line"
+         id="tspan10642"
+         x="742.7262"
+         y="130.87918">no <tspan
+   style="font-weight:bold"
+   id="tspan10648">member</tspan></tspan><tspan
+         sodipodi:role="line"
+         x="742.7262"
+         y="145.87918"
+         id="tspan10644">here!</tspan></text>
+    <text
+       id="text10650"
+       y="244.87918"
+       x="742.7262"
+       style="font-size:12px;font-style:italic;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       xml:space="preserve"
+       inkscape:export-filename="/home/andreas/set-recursivegroup.png"
+       inkscape:export-xdpi="80.970001"
+       inkscape:export-ydpi="80.970001"><tspan
+         y="244.87918"
+         x="742.7262"
+         id="tspan10652"
+         sodipodi:role="line">no <tspan
+   id="tspan10654"
+   style="font-weight:bold">member</tspan></tspan><tspan
+         id="tspan10656"
+         y="259.87918"
+         x="742.7262"
+         sodipodi:role="line">here!</tspan></text>
+  </g>
+</svg>