# $OpenLDAP$
-# Copyright 2007-2008 The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 2007-2011 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: Overlays
> # numResponses: 3
> # numEntries: 2
-For more information, please see {{slapo-accesslog(5)}} and the {{SECT:delta-syncrepl replication}} section.
+
+H3: Further Information
+
+{{slapo-accesslog(5)}} and the {{SECT:delta-syncrepl replication}} section.
H2: Audit Logging
In this example for testing, we are logging changes to {{F:/tmp/auditlog.ldif}}
-A typical {{TERM:LDIF}} file created by {{B:slapo-auditlog (5)}} would look like:
+A typical {{TERM:LDIF}} file created by {{B:slapo-auditlog(5)}} would look like:
> # add 1196797576 dc=suretecsystems,dc=com cn=admin,dc=suretecsystems,dc=com
> dn: dc=suretecsystems,dc=com
> # end add 1196797577
+H3: Further Information
+
+{{:slapo-auditlog(5)}}
+
+
H2: Chaining
> chain-return-error TRUE
+H3: Read-Back of Chained Modifications
+
+Occasionally, applications want to read back the data that they just wrote.
+If a modification requested to a shadow server was silently chained to its
+provider, an immediate read could result in receiving data not yet synchronized.
+In those cases, clients should use the {{B:dontusecopy}} control to ensure
+they are directed to the authoritative source for that piece of data.
+
+This control usually causes a referral to the actual source of the data
+to be returned. However, when the {{slapo-chain(5)}} overlay is used,
+it intercepts the referral being returned in response to the
+{{B:dontusecopy}} control, and tries to fetch the requested data.
+
+
+H3: Further Information
+
+{{:slapo-chain(5)}}
+
+
H2: Constraints
Configuration via {{slapd.conf}}(5) would look like:
> overlay constraint
-> constraint_attribute mail regex ^[:alnum:]+@mydomain.com$
+> constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$
> constraint_attribute title uri
> ldap:///dc=catalog,dc=example,dc=com?title?sub?(objectClass=titleCatalog)
> objectClass: olcOverlayConfig
> objectClass: olcConstraintConfig
> olcOverlay: constraint
-> olcConstraintAttribute: mail regex ^[:alnum:]+@mydomain.com$
+> 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
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
expands to all user's emails according to our LDAP filter:
In {{slapd.conf}}(5):
+
> overlay dynlist
> dynlist-attrset nisMailAlias labeledURI
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
directory.
In {{F:slapd.conf}}(5):
+
+> include /path/to/dyngroup.schema
+> ...
> overlay dynlist
-> dynlist-attrset groupOfNames labeledURI member
+> dynlist-attrset groupOfURLs labeledURI member
++
++Note: We must include the {{F:dyngroup.schema}} file that defines the
++{{F:groupOfURLs}} objectClass used in this example.
Let's apply it to the following entry:
+
> cn=allusers,ou=group,dc=example,dc=com
> cn: all
-> objectClass: groupOfNames
+> objectClass: groupOfURLs
> labeledURI: ldap:///ou=people,dc=example,dc=com??one?(objectClass=inetOrgPerson)
The behavior is similar to the dynamic list configuration we had before:
-whenever an entry with the {{F:groupOfNames}} object class is retrieved, the
+whenever an entry with the {{F:groupOfURLs}} object class is retrieved, the
search specified in the {{F:labeledURI}} attribute is performed. But this time,
only the distinguished names of the results are added, and as values of the
{{F:member}} attribute.
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
> include /usr/share/openldap/schema/core.schema
> include /usr/share/openldap/schema/cosine.schema
-> modulepath /usr/lib/openldap
-> moduleload memberof.la
+>
> authz-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth"
> "cn=Manager,dc=example,dc=com"
> database bdb
requested explicitly.
+H3: Further Information
+
+{{:slapo-memberof(5)}}
+
+
H2: The Proxy Cache Engine
{{TERM:LDAP}} servers typically hold one or more subtrees of a
H3: Proxy Cache Configuration
The cache configuration specific directives described below must
-appear after a {{EX:overlay proxycache}} directive within a
-{{EX:"database meta"}} or {{EX:database ldap}} section of
+appear after a {{EX:overlay pcache}} directive within a
+{{EX:"database meta"}} or {{EX:"database ldap"}} section of
the server's {{slapd.conf}}(5) file.
H4: Setting cache parameters
-> p
roxyCache <DB> <maxentries> <nattrsets> <entrylimit> <period>
+> p
cache <DB> <maxentries> <nattrsets> <entrylimit> <period>
This directive enables proxy caching and sets general cache
parameters. The <DB> parameter specifies which underlying database
{{EX:bdb}} or {{EX:hdb}}. The <maxentries> parameter specifies the
total number of entries which may be held in the cache. The
<nattrsets> parameter specifies the total number of attribute sets
-(as specified by the {{EX:proxyAttrSet}} directive) that may be
+(as specified by the {{EX:pcacheAttrset}} directive) that may be
defined. The <entrylimit> parameter specifies the maximum number of
entries in a cacheable query. The <period> specifies the consistency
check period (in seconds). In each period, queries with expired
H4: Defining attribute sets
-> p
roxyAttrset <index> <attrs...>
+> p
cacheAttrset <index> <attrs...>
Used to associate a set of attributes to an index. Each attribute
set is associated with an index number from 0 to <numattrsets>-1.
-These indices are used by the proxyTemplate directive to define
+These indices are used by the pcacheTemplate directive to define
cacheable templates.
H4: Specifying cacheable templates
-> p
roxyTemplate <prototype_string> <attrset_index> <TTL>
+> p
cacheTemplate <prototype_string> <attrset_index> <TTL>
Specifies a cacheable template and the "time to live" (in sec) <TTL>
for queries belonging to the template. A template is described by
by <attrset_index>.
-H4: Example
+H4: Example for slapd.conf
An example {{slapd.conf}}(5) database section for a caching server
which proxies for the {{EX:"dc=example,dc=com"}} subtree held
> suffix "dc=example,dc=com"
> rootdn "dc=example,dc=com"
> uri ldap://ldap.example.com/
-> overlay proxycache
-> proxycache bdb 100000 1 1000 100
-> proxyAttrset 0 mail postaladdress telephonenumber
-> proxyTemplate (sn=) 0 3600
-> proxyTemplate (&(sn=)(givenName=)) 0 3600
-> proxyTemplate (&(departmentNumber=)(secretary=*)) 0 3600
+> overlay pcache
+> pcache bdb 100000 1 1000 100
+> pcacheAttrset 0 mail postaladdress telephonenumber
+> pcacheTemplate (sn=) 0 3600
+> pcacheTemplate (&(sn=)(givenName=)) 0 3600
+> pcacheTemplate (&(departmentNumber=)(secretary=*)) 0 3600
>
> cachesize 20
> directory ./testrun/db.2.a
> index objectClass eq
> index cn,sn,uid,mail pres,eq,sub
+H4: Example for slapd-config
+
+The same example as a LDIF file for back-config for a caching server
+which proxies for the {{EX:"dc=example,dc=com"}} subtree held
+at server {{EX:ldap.example.com}}.
+
+> dn: olcDatabase={2}ldap
+> objectClass: olcDatabaseConfig
+> objectClass: olcLDAPConfig
+> olcDatabase: {2}ldap
+> olcSuffix: dc=example,dc=com
+> olcRootDN: dc=example,dc=com
+> olcDbURI: "ldap://ldap.example.com"
+>
+> dn: olcOverlay={0}pcache
+> objectClass: olcOverlayConfig
+> objectClass: olcPcacheConfig
+> olcOverlay: {0}pcache
+> olcPcache: bdb 100000 1 1000 100
+> olcPcacheAttrset: 0 mail postalAddress telephoneNumber
+> olcPcacheTemplate: "(sn=)" 0 3600 0 0 0
+> olcPcacheTemplate: "(&(sn=)(givenName=))" 0 3600 0 0 0
+> olcPcacheTemplate: "(&(departmentNumber=)(secretary=))" 0 3600
+>
+> dn: olcDatabase={0}hdb
+> objectClass: olcHdbConfig
+> objectClass: olcPcacheDatabase
+> olcDatabase: {0}hdb
+> olcDbDirectory: ./testrun/db.2.a
+> olcDbCacheSize: 20
+> olcDbIndex: objectClass eq
+> olcDbIndex: cn,sn,uid,mail pres,eq,sub
+
H5: Cacheable Queries
A LDAP search query is cacheable when its filter matches one of the
-templates as defined in the "proxyTemplate" statements and when it references
+templates as defined in the "pcacheTemplate" statements and when it references
only the attributes specified in the corresponding attribute set.
In the example above the attribute set number 0 defines that only the
attributes: {{EX:mail postaladdress telephonenumber}} are cached for the following
-proxyTemplates.
+pcacheTemplates.
H5: Examples:
> Attrs: mail telephoneNumber
is cacheable, because it matches the template {{EX:(&(sn=)(givenName=))}} and its
- attributes are contained in proxyAttrset 0.
+ attributes are contained in pcacheAttrset 0.
> Filter: (&(sn=Richard*)(telephoneNumber))
> Attrs: givenName
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
There are two ways password policy can be applied to individual objects:
-1. Default password policy - If, as in the example above, the password policy
-module was configured with the DN of a default policy object and if that object
-exists, then the policy defined in that object is applied.
+1. The pwdPolicySubentry in a user's object - If a user's object has a
+pwdPolicySubEntry attribute specifying the DN of a policy object, then
+the policy defined by that object is applied.
-2. The pwdPolicySubentry in a user's object - If a user's object contains a
-value for the pwdPolicySubEntry attribute, and if that object exists, then
-the policy defined by that object is applied. Remember that we need to add
-object class pwdPolicy to the user's object as well.
+2. Default password policy - If there is no specific pwdPolicySubentry set
+for an object, and the password policy module was configured with the DN of a
+default policy object and if that object exists, then the policy defined in
+that object is applied.
Please see {{slapo-ppolicy(5)}} for complete explanations of features and discussion of
- "Password Management Issues" at {{URL:http://www.connexitor.com/forums/viewtopic.php?f=6&t=25}}
+ "Password Management Issues" at {{URL:http://www.symas.com/blog/?page_id=66}}
+
+H3: Further Information
+
+{{:slapo-ppolicy(5)}}
H2: Referential Integrity
H3: Referential Integrity Configuration
The configuration for this overlay is as follows:
+
> overlay refint
> refint_attributes <attribute [attribute ...]>
> refint_nothing <string>
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"
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.
+The {{rootdn}} must be set for the database as refint runs as the {{rootdn}} to gain access to
+make its updates. The {{rootpw}} does not need to be set.
+
+H3: Further Information
+
+{{:slapo-refint(5)}}
+
+
H2: Return Code
H3: Overview
This overlay is useful to test the behavior of clients when
-server-generated erroneous and/or unusual responses occur.
+server-generated erroneous and/or unusual responses occur,
+for example; error codes, referrals, excessive response times and so on.
+
+This would be classed as a debugging tool whilst developing client software
+or additional Overlays.
+
+For detailed information, please see the {{slapo-retcode(5)}} man page.
H3: Return Code Configuration
+The retcode overlay utilizes the "return code" schema described in the man page.
+This schema is specifically designed for use with this overlay and is not intended
+to be used otherwise.
+
+Note: The necessary schema is loaded automatically by the overlay.
+
+An example configuration might be:
+
+> overlay retcode
+> retcode-parent "ou=RetCodes,dc=example,dc=com"
+> include ./retcode.conf
+>
+> retcode-item "cn=Unsolicited" 0x00 unsolicited="0"
+> retcode-item "cn=Notice of Disconnect" 0x00 unsolicited="1.3.6.1.4.1.1466.20036"
+> retcode-item "cn=Pre-disconnect" 0x34 flags="pre-disconnect"
+> retcode-item "cn=Post-disconnect" 0x34 flags="post-disconnect"
+
+Note: {{retcode.conf}} can be found in the openldap source at: {{F:tests/data/retcode.conf}}
+
+An excerpt of a {{F:retcode.conf}} would be something like:
+
+> retcode-item "cn=success" 0x00
+>
+> retcode-item "cn=success w/ delay" 0x00 sleeptime=2
+>
+> retcode-item "cn=operationsError" 0x01
+> retcode-item "cn=protocolError" 0x02
+> retcode-item "cn=timeLimitExceeded" 0x03 op=search
+> retcode-item "cn=sizeLimitExceeded" 0x04 op=search
+> retcode-item "cn=compareFalse" 0x05 op=compare
+> retcode-item "cn=compareTrue" 0x06 op=compare
+> retcode-item "cn=authMethodNotSupported" 0x07
+> retcode-item "cn=strongAuthNotSupported" 0x07 text="same as authMethodNotSupported"
+> retcode-item "cn=strongAuthRequired" 0x08
+> retcode-item "cn=strongerAuthRequired" 0x08 text="same as strongAuthRequired"
+
+Please see {{F:tests/data/retcode.conf}} for a complete {{F:retcode.conf}}
+
+
+H3: Further Information
+
+{{:slapo-retcode(5)}}
+
H2: Rewrite/Remap
H3: Overview
-It performs basic DN/data rewrite and
-objectClass/attributeType mapping.
+It performs basic DN/data rewrite and objectClass/attributeType mapping. Its
+usage is mostly intended to provide virtual views of existing data either
+remotely, in conjunction with the proxy backend described in {{slapd-ldap(5)}},
+or locally, in conjunction with the relay backend described in {{slapd-relay(5)}}.
+
+This overlay is extremely configurable and advanced, therefore recommended
+reading is the {{slapo-rwm(5)}} man page.
H3: Rewrite/Remap Configuration
+H3: Further Information
+
+{{:slapo-rwm(5)}}
+
+
H2: Sync Provider
H3: Overview
-This overlay implements the provider-side support for syncrepl
-replication, including persistent search functionality
-
+This overlay implements the provider-side support for the LDAP Content Synchronization
+({{REF:RFC4533}}) as well as syncrepl replication support, including persistent search functionality.
H3: Sync Provider Configuration
+There is very little configuration needed for this overlay, in fact for many situations merely loading
+the overlay will suffice.
+
+However, because the overlay creates a contextCSN attribute in the root entry of the database which is
+updated for every write operation performed against the database and only updated in memory, it is
+recommended to configure a checkpoint so that the contextCSN is written into the underlying database to
+minimize recovery time after an unclean shutdown:
+
+> overlay syncprov
+> syncprov-checkpoint 100 10
+
+For every 100 operations or 10 minutes, which ever is sooner, the contextCSN will be checkpointed.
+
+The four configuration directives available are {{B:syncprov-checkpoint}}, {{B:syncprov-sessionlog}},
+{{B:syncprov-nopresent}} and {{B:syncprov-reloadhint}} which are covered in the man page discussing
+various other scenarios where this overlay can be used.
+
+H3: Further Information
+
+The {{:slapo-syncprov(5)}} man page and the {{SECT:Configuring the different replication types}} section
+
H2: Translucent Proxy
H3: Overview
-This overlay can be used with a backend database such as slapd-bdb (5)
+This overlay can be used with a backend database such as {{:slapd-bdb}}(5)
to create a "translucent proxy".
-Content of entries retrieved from a remote LDAP server can be partially
-overridden by the database.
+Entries retrieved from a remote LDAP server may have some or all attributes
+overridden, or new attributes added, by entries in the local database before
+being presented to the client.
+
+A search operation is first populated with entries from the remote LDAP server,
+the attributes of which are then overridden with any attributes defined in the
+local database. Local overrides may be populated with the add, modify, and
+modrdn operations, the use of which is restricted to the root user of the
+translucent local database.
+
+A compare operation will perform a comparison with attributes defined in the
+local database record (if any) before any comparison is made with data in the
+remote database.
H3: Translucent Proxy Configuration
+There are various options available with this overlay, but for this example we
+will demonstrate adding new attributes to a remote entry and also searching
+against these newly added local attributes. For more information about overriding remote
+entries and search configuration, please see {{:slapo-translucent(5)}}
+
+Note: The Translucent Proxy overlay will disable schema checking in the local
+database, so that an entry consisting of overlay attributes need not adhere
+ to the complete schema.
+
+First we configure the overlay in the normal manner:
+
+> include /usr/local/etc/openldap/schema/core.schema
+> include /usr/local/etc/openldap/schema/cosine.schema
+> include /usr/local/etc/openldap/schema/nis.schema
+> include /usr/local/etc/openldap/schema/inetorgperson.schema
+>
+> pidfile ./slapd.pid
+> argsfile ./slapd.args
+>
+> database bdb
+> suffix "dc=suretecsystems,dc=com"
+> rootdn "cn=trans,dc=suretecsystems,dc=com"
+> rootpw secret
+> directory ./openldap-data
+>
+> index objectClass eq
+>
+> overlay translucent
+> translucent_local carLicense
+>
+> uri ldap://192.168.X.X:389
+> lastmod off
+> acl-bind binddn="cn=admin,dc=suretecsystems,dc=com" credentials="blahblah"
+
+You will notice the overlay directive and a directive to say what attribute we
+want to be able to search against in the local database. We must also load the
+ldap backend which will connect to the remote directory server.
+
+Now we take an example LDAP group:
+
+> # itsupport, Groups, suretecsystems.com
+> dn: cn=itsupport,ou=Groups,dc=suretecsystems,dc=com
+> objectClass: posixGroup
+> objectClass: sambaGroupMapping
+> cn: itsupport
+> gidNumber: 1000
+> sambaSID: S-1-5-21-XXX
+> sambaGroupType: 2
+> displayName: itsupport
+> memberUid: ghenry
+> memberUid: joebloggs
+
+and create an LDIF file we can use to add our data to the local database, using
+ some pretty strange choices of new attributes for demonstration purposes:
+
+> [ghenry@suretec test_configs]$ cat test-translucent-add.ldif
+> dn: cn=itsupport,ou=Groups,dc=suretecsystems,dc=com
+> businessCategory: frontend-override
+> carLicense: LIVID
+> employeeType: special
+> departmentNumber: 9999999
+> roomNumber: 41L-535
+
+Searching against the proxy gives:
+
+> [ghenry@suretec test_configs]$ ldapsearch -x -H ldap://127.0.0.1:9001 "(cn=itsupport)"
+> # itsupport, Groups, OxObjects, suretecsystems.com
+> dn: cn=itsupport,ou=Groups,ou=OxObjects,dc=suretecsystems,dc=com
+> objectClass: posixGroup
+> objectClass: sambaGroupMapping
+> cn: itsupport
+> gidNumber: 1003
+> SAMBASID: S-1-5-21-XXX
+> SAMBAGROUPTYPE: 2
+> displayName: itsupport
+> memberUid: ghenry
+> memberUid: joebloggs
+> roomNumber: 41L-535
+> departmentNumber: 9999999
+> employeeType: special
+> carLicense: LIVID
+> businessCategory: frontend-override
+
+Here we can see that the 5 new attributes are added to the remote entry before
+being returned to the our client.
+
+Because we have configured a local attribute to search against:
+
+> overlay translucent
+> translucent_local carLicense
+
+we can also search for that to return the completely fabricated entry:
+
+> ldapsearch -x -H ldap://127.0.0.1:9001 (carLicense=LIVID)
+
+This is an extremely feature because you can then extend a remote directory server
+locally and also search against the local entries.
+
+Note: Because the translucent overlay does not perform any DN rewrites, the local
+ and remote database instances must have the same suffix. Other configurations
+will probably fail with No Such Object and other errors
+
+H3: Further Information
+
+{{:slapo-translucent(5)}}
+
H2: Attribute Uniqueness
H3: Overview
-This overlay can be used with a backend database such as slapd-bdb (5)
+This overlay can be used with a backend database such as {{slapd-bdb(5)}}
to enforce the uniqueness of some or all attributes within a subtree.
H3: Attribute Uniqueness Configuration
+This overlay is only effective on new data from the point the overlay is enabled. To
+check uniqueness for existing data, you can export and import your data again via the
+LDAP Add operation, which will not be suitable for large amounts of data, unlike {{B:slapcat}}.
+
+For the following example, if uniqueness were enforced for the {{B:mail}} attribute,
+the subtree would be searched for any other records which also have a {{B:mail}} attribute
+containing the same value presented with an {{B:add}}, {{B:modify}} or {{B:modrdn}} operation
+which are unique within the configured scope. If any are found, the request is rejected.
+
+Note: If no attributes are specified, for example {{B:ldap:///??sub?}}, then the URI applies to all non-operational attributes. However,
+the keyword {{B:ignore}} can be specified to exclude certain non-operational attributes.
+
+To search at the base dn of the current backend database ensuring uniqueness of the {{B:mail}}
+attribute, we simply add the following configuration:
+
+> overlay unique
+> unique_uri ldap:///?mail?sub?
+
+For an existing entry of:
+
+> dn: cn=gavin,dc=suretecsystems,dc=com
+> objectClass: top
+> objectClass: inetorgperson
+> cn: gavin
+> sn: henry
+> mail: ghenry@suretecsystems.com
+
+and we then try to add a new entry of:
+
+> dn: cn=robert,dc=suretecsystems,dc=com
+> objectClass: top
+> objectClass: inetorgperson
+> cn: robert
+> sn: jones
+> mail: ghenry@suretecsystems.com
+
+would result in an error like so:
+
+> adding new entry "cn=robert,dc=example,dc=com"
+> ldap_add: Constraint violation (19)
+> additional info: some attributes not unique
+
+The overlay can have multiple URIs specified within a domain, allowing complex
+selections of objects and also have multiple {{B:unique_uri}} statements or
+{{B:olcUniqueURI}} attributes which will create independent domains.
+
+For more information and details about the {{B:strict}} and {{B:ignore}} keywords,
+please see the {{:slapo-unique(5)}} man page.
+
+H3: Further Information
+
+{{:slapo-unique(5)}}
+
H2: Value Sorting
H3: Overview
-This overlay can be used to enforce a specific order for the values
-of an attribute when it is returned in a search.
-
+The Value Sorting overlay can be used with a backend database to sort the
+values of specific multi-valued attributes within a subtree. The sorting occurs
+whenever the attributes are returned in a search response.
H3: Value Sorting Configuration
+Sorting can be specified in ascending or descending order, using either numeric
+or alphanumeric sort methods. Additionally, a "weighted" sort can be specified,
+ which uses a numeric weight prepended to the attribute values.
+
+The weighted sort is always performed in ascending order, but may be combined
+with the other methods for values that all have equal weights. The weight is
+specified by prepending an integer weight {<weight>} in front of each value
+of the attribute for which weighted sorting is desired. This weighting factor
+is stripped off and never returned in search results.
+
+Here are a few examples:
+
+> loglevel sync stats
+>
+> database hdb
+> suffix "dc=suretecsystems,dc=com"
+> directory /usr/local/var/openldap-data
+>
+> ......
+>
+> overlay valsort
+> valsort-attr memberUid ou=Groups,dc=suretecsystems,dc=com alpha-ascend
+
+For example, ascend:
+
+> # sharedemail, Groups, suretecsystems.com
+> dn: cn=sharedemail,ou=Groups,dc=suretecsystems,dc=com
+> objectClass: posixGroup
+> objectClass: top
+> cn: sharedemail
+> gidNumber: 517
+> memberUid: admin
+> memberUid: dovecot
+> memberUid: laura
+> memberUid: suretec
+
+For weighted, we change our data to:
+
+> # sharedemail, Groups, suretecsystems.com
+> dn: cn=sharedemail,ou=Groups,dc=suretecsystems,dc=com
+> objectClass: posixGroup
+> objectClass: top
+> cn: sharedemail
+> gidNumber: 517
+> memberUid: {4}admin
+> memberUid: {2}dovecot
+> memberUid: {1}laura
+> memberUid: {3}suretec
+
+and change the config to:
+
+> overlay valsort
+> valsort-attr memberUid ou=Groups,dc=suretecsystems,dc=com weighted
+
+Searching now results in:
+
+> # sharedemail, Groups, OxObjects, suretecsystems.com
+> dn: cn=sharedemail,ou=Groups,ou=OxObjects,dc=suretecsystems,dc=com
+> objectClass: posixGroup
+> objectClass: top
+> cn: sharedemail
+> gidNumber: 517
+> memberUid: laura
+> memberUid: dovecot
+> memberUid: suretec
+> memberUid: admin
+
+
+H3: Further Information
+
+{{:slapo-valsort(5)}}
+
H2: Overlay Stacking
projects / openldap / blobdiff