../plain.sdf \
../preamble.sdf \
abstract.sdf \
+ access-control.sdf \
appendix-changes.sdf \
appendix-common-errors.sdf \
appendix-configs.sdf \
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
--- /dev/null
+# $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.
+
+
-personal_ws-1.1 en 1559
+personal_ws-1.1 en 1567
commonName
Masarati
subjectAltName
dev
reqNewSuperior
librewrite
-memberof
memberOf
+memberof
BSI
updateref
buf
eng
AttributeValue
attributevalue
-DUA
EOF
+DUA
inputfile
DSP
refreshDone
Bint
memalloc
FSF
+usernames
strtol
idl
IDN
contextCSN
auditModify
auditSearch
-OpenLDAP
openldap
-resultcode
+OpenLDAP
resultCode
+resultcode
sysconfig
indices
blen
kdz
notAllowedOnRDN
hostport
-StartTLS
starttls
+StartTLS
ldb
servercredp
ldd
-IPv
ipv
+IPv
hyc
joe
bindmethods
ldp
ISP
len
+carLicense
Choi
Clatworthy
scherr
directoryOperation
creatorsName
mem
-oldPasswdFile
oldpasswdfile
+oldPasswdFile
uniqueMember
krb
libpath
acknowledgements
jts
createTimestamp
-MIB
LLL
+MIB
OpenSSL
openssl
LOF
aeeiib
oidlen
submatches
-PEM
olc
-OLF
+PEM
PDU
+OLF
LDAPSchemaExtensionItem
auth
Pierangelo
wZFQrDD
OTP
olcSizeLimit
-PRD
-sbi
pos
+sbi
+PRD
pre
stringal
retoidp
+sudoadm
sdf
efgh
accesslog
bvec
TBC
stringbv
-SHA
Sep
+SHA
ptr
conn
pwd
supportedSASLMechanism
supportedSASLmechanism
realnamingcontext
-UCD
SMD
+UCD
keytab
portnumber
uncached
UCS
searchDN
keytbl
-UDP
tgz
+UDP
freemods
prepend
errText
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
uri
tty
url
-sortKey
XED
+sortKey
UTF
vlv
TXN
memberAttr
multiclassing
memberURL
+sudoers
pwdMaxFailure
pseudorootdn
GDBM
LIBRELEASE
-DSA's
DSAs
+DSA's
realloc
booleanMatch
compareTrue
iZ
ldapdelete
xyz
-rdbms
RDBMs
+rdbms
extparam
mk
ng
LDVERSION
testAttr
backend
-backends
backend's
+backends
BerValues
Solaris
structs
policyDN
testObject
pwdMaxAge
-binddn
-bindDN
bindDn
+bindDN
+binddn
distributedOperation
schemachecking
strvals
errno
errOp
serverctrls
+recursivegroup
integerMatch
moduledir
dynstyle
regex
SIGINT
slappasswd
-errABsObject
errAbsObject
+errABsObject
ldapexop
-objectIdentifier
objectidentifier
+objectIdentifier
deallocators
-mirrormode
MirrorMode
+mirrormode
loopDetect
SIGHUP
authMethodNotSupported
expr
syntaxes
memrealloc
-returncode
returnCode
+returncode
OpenLDAP's
exts
bitstringa
lldap
cachesize
slapauth
-attributeType
attributetype
+attributeType
GSER
olcDbNosync
typedef
organisations
rewriteMap
monitoredInfo
-modrDN
-ModRDN
modrdn
+ModRDN
+modrDN
HREF
inline
multiproxy
rlookups
siiiib
LTSTATIC
-timelimitExceeded
timeLimitExceeded
+timelimitExceeded
XKYnrjvGT
subtrees
unixODBC
pathname
noSuchObject
proxyOld
-BerElement
berelement
+BerElement
sbiod
plugin
http
numericStringSubstringsMatch
internet
storages
-WhoAmI
whoami
+WhoAmI
criticality
addBlanks
logins
proxyattrset
proxyAttrSet
proxyAttrset
+mary
crlcheck
olcBdbConfig
kadmin
namingViolation
inappropriateAuthentication
mixin
+suders
syntaxOID
olcTLSCACertificateFile
IGJlZ
objectclass
objectClass
sizeLimitExceeded
+accountadm
reqControls
modme
shtool
kbyte
monitorCounter
quickstart
-olcConstraintConfig
UUID
+olcConstraintConfig
rootpw
veryclean
syslogged
ali
attributeoptions
uidNumber
-CA's
CAs
+CA's
namingContext
!include "slapdconfig.sdf"; chapter
PB:
+!include "access-control.sdf"; chapter
+PB:
+
!include "runningslapd.sdf"; chapter
PB:
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
>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)
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
\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
--- /dev/null
+<?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>
--- /dev/null
+<?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">&</tspan></text>
+ </g>
+</svg>
--- /dev/null
+<?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>
projects / openldap / commitdiff
