@@ -224,6 +227,11 @@ A typical {{TERM:LDIF}} file created by {{B:slapo-auditlog (5)}} would look like
> # end add 1196797577
H3: Further Information
{{:slapo-auditlog(5)}}
H2: Chaining
...
...
@@ -314,6 +322,11 @@ side, the actual error is returned to the client.
> chain-return-error TRUE
H3: Further Information
{{:slapo-chain(5)}}
H2: Constraints
...
...
@@ -350,6 +363,11 @@ An example for use with {{cn=config}}:
> olcConstraintAttribute: mail regex ^[:alnum:]+@mydomain.com$
> olcConstraintAttribute: title uri ldap:///dc=catalog,dc=example,dc=com?title?sub?(objectClass=titleCatalog)
H3: Further Information
{{:slapo-constraint(5)}}
H2: Dynamic Directory Services
...
...
@@ -436,6 +454,12 @@ refresh the meeting using (basically complete control):
Any user can join the meeting, but not add another attendee, but they can refresh the meeting. The ACLs above are quite straight forward to understand.
H3: Further Information
{{:slapo-dds(5)}}
H2: Dynamic Groups
...
...
@@ -482,6 +506,7 @@ Here is an example which will allow us to have an email alias which automaticall
expands to all user's emails according to our LDAP filter:
In {{slapd.conf}}(5):
> overlay dynlist
> dynlist-attrset nisMailAlias labeledURI
...
...
@@ -489,6 +514,7 @@ This means that whenever an entry which has the {{F:nisMailAlias}} object class
retrieved, the search specified in the {{F:labeledURI}} attribute is performed.
Let's say we have this entry in our directory:
> cn=all,ou=aliases,dc=example,dc=com
> cn: all
> objectClass: nisMailAlias
...
...
@@ -510,10 +536,12 @@ automatically populate an {{F:allusers}} group with all the user accounts in the
directory.
In {{F:slapd.conf}}(5):
> overlay dynlist
> dynlist-attrset groupOfNames labeledURI member
Let's apply it to the following entry:
> cn=allusers,ou=group,dc=example,dc=com
> cn: all
> objectClass: groupOfNames
...
...
@@ -536,6 +564,12 @@ distinguished names. The {{F:memberUid}} attribute used in the {{F:posixGroup}}
object class can hold only names, not DNs, and is therefore not suitable for
dynamic groups.
H3: Further Information
{{:slapo-dynlist(5)}}
H2: Reverse Group Membership Maintenance
H3: Overview
...
...
@@ -614,6 +648,11 @@ Note that the {{B:memberOf}} attribute is an operational attribute, so it must b
requested explicitly.
H3: Further Information
{{:slapo-memberof(5)}}
H2: The Proxy Cache Engine
{{TERM:LDAP}} servers typically hold one or more subtrees of a
...
...
@@ -757,6 +796,11 @@ H5: Examples:
is not cacheable, because the filter does not match the template ( logical
OR "|" condition instead of logical AND "&" )
H3: Further Information
{{:slapo-pcache(5)}}
H2: Password Policies
...
...
@@ -870,6 +914,10 @@ Please see {{slapo-ppolicy(5)}} for complete explanations of features and discus
"Password Management Issues" at {{URL:http://www.connexitor.com/forums/viewtopic.php?f=6&t=25}}
H3: Further Information
{{:slapo-ppolicy(5)}}
H2: Referential Integrity
...
...
@@ -897,6 +945,7 @@ all the groups he/she was a member of. No more scripting for this.
H3: Referential Integrity Configuration
The configuration for this overlay is as follows:
> overlay refint
> refint_attributes <attribute [attribute ...]>
> refint_nothing <string>
...
...
@@ -917,6 +966,7 @@ to the entry.
To illustrate this overlay, we will use the group membership scenario.
In {{F:slapd.conf}}:
> overlay refint
> refint_attributes member
> refint_nothing "cn=admin,dc=example,dc=com"
...
...
@@ -941,30 +991,95 @@ If we removed all users from the directory who are a member of this group, then
would be a single member in the group: {{F:cn=admin,dc=example,dc=com}}. This is the
{{F:refint_nothing}} parameter kicking into action so that the schema is not violated.
H3: Further Information
{{:slapo-refint(5)}}
H2: Return Code
H3: Overview
This overlay is useful to test the behavior of clients when
