2 # Copyright 2007-2017 The OpenLDAP Foundation, All Rights Reserved.
3 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
7 Overlays are software components that provide hooks to functions analogous to
8 those provided by backends, which can be stacked on top of the backend calls
9 and as callbacks on top of backend responses to alter their behavior.
11 Overlays may be compiled statically into {{slapd}}, or when module support
12 is enabled, they may be dynamically loaded. Most of the overlays
13 are only allowed to be configured on individual databases.
15 Some can be stacked on the {{EX:frontend}} as well, for global use. This means that
16 they can be executed after a request is parsed and validated, but right before the
17 appropriate database is selected. The main purpose is to affect operations
18 regardless of the database they will be handled by, and, in some cases,
19 to influence the selection of the database by massaging the request DN.
21 Essentially, overlays represent a means to:
23 * customize the behavior of existing backends without changing the backend
24 code and without requiring one to write a new custom backend with
25 complete functionality
26 * write functionality of general usefulness that can be applied to
27 different backend types
29 When using {{slapd.conf}}(5), overlays that are configured before any other
30 databases are considered global, as mentioned above. In fact they are implicitly
31 stacked on top of the {{EX:frontend}} database. They can also be explicitly
35 > overlay <overlay name>
37 Overlays are usually documented by separate specific man pages in section 5;
38 the naming convention is
40 > slapo-<overlay name>
42 All distributed core overlays have a man page. Feel free to contribute to any,
43 if you think there is anything missing in describing the behavior of the component
44 and the implications of all the related configuration directives.
46 Official overlays are located in
48 > servers/slapd/overlays/
50 That directory also contains the file slapover.txt, which describes the
51 rationale of the overlay implementation, and may serve as a guideline for the
52 development of custom overlays.
54 Contribware overlays are located in
56 > contrib/slapd-modules/<overlay name>/
58 along with other types of run-time loadable components; they are officially
59 distributed, but not maintained by the project.
61 All the current overlays in OpenLDAP are listed and described in detail in the
70 This overlay can record accesses to a given backend database on another
73 This allows all of the activity on a given database to be reviewed using arbitrary
74 LDAP queries, instead of just logging to local flat text files. Configuration
75 options are available for selecting a subset of operation types to log, and to
76 automatically prune older log records from the logging database. Log records
77 are stored with audit schema to assure their readability whether viewed as LDIF
80 It is also used for {{SECT:delta-syncrepl replication}}
82 Note: An accesslog database is unique to a given master. It should
85 H3: Access Logging Configuration
87 The following is a basic example that implements Access Logging:
90 > suffix dc=example,dc=com
95 > logold (objectclass=person)
102 > by dn.base="cn=admin,dc=example,dc=com" read
104 The following is an example used for {{SECT:delta-syncrepl replication}}:
107 > suffix cn=accesslog
108 > directory /usr/local/var/openldap-accesslog
109 > rootdn cn=accesslog
111 > index entryCSN,objectClass,reqEnd,reqResult,reqStart
113 Accesslog overlay definitions for the primary db
116 > suffix dc=example,dc=com
122 > # scan the accesslog DB every day, and purge entries older than 7 days
123 > logpurge 07+00:00 01+00:00
125 An example search result against {{B:cn=accesslog}} might look like:
127 > [ghenry@suretec ghenry]# ldapsearch -x -b cn=accesslog
131 > # base <cn=accesslog> with scope subtree
132 > # filter: (objectclass=*)
138 > objectClass: auditContainer
141 > # 20080110163829.000004Z, accesslog
142 > dn: reqStart=20080110163829.000004Z,cn=accesslog
143 > objectClass: auditModify
144 > reqStart: 20080110163829.000004Z
145 > reqEnd: 20080110163829.000005Z
148 > reqAuthzID: cn=admin,dc=suretecsystems,dc=com
149 > reqDN: uid=suretec-46022f8$,ou=Users,dc=suretecsystems,dc=com
151 > reqMod: sambaPwdCanChange:- ###CENSORED###
152 > reqMod: sambaPwdCanChange:+ ###CENSORED###
153 > reqMod: sambaNTPassword:- ###CENSORED###
154 > reqMod: sambaNTPassword:+ ###CENSORED###
155 > reqMod: sambaPwdLastSet:- ###CENSORED###
156 > reqMod: sambaPwdLastSet:+ ###CENSORED###
157 > reqMod: entryCSN:= 20080110163829.095157Z#000000#000#000000
158 > reqMod: modifiersName:= cn=admin,dc=suretecsystems,dc=com
159 > reqMod: modifyTimestamp:= 20080110163829Z
169 H3: Further Information
171 {{slapo-accesslog(5)}} and the {{SECT:delta-syncrepl replication}} section.
176 The Audit Logging overlay can be used to record all changes on a given backend database to a specified log file.
180 If the need arises whereby changes need to be logged as standard LDIF, then the auditlog overlay {{B:slapo-auditlog (5)}}
181 can be used. Full examples are available in the man page {{B:slapo-auditlog (5)}}
183 H3: Audit Logging Configuration
185 If the directory is running vi {{F:slapd.d}}, then the following LDIF could be used to add the overlay to the overlay list
186 in {{B:cn=config}} and set what file the {{TERM:LDIF}} gets logged to (adjust to suit)
188 > dn: olcOverlay=auditlog,olcDatabase={1}mdb,cn=config
190 > objectClass: olcOverlayConfig
191 > objectClass: olcAuditLogConfig
192 > olcOverlay: auditlog
193 > olcAuditlogFile: /tmp/auditlog.ldif
196 In this example for testing, we are logging changes to {{F:/tmp/auditlog.ldif}}
198 A typical {{TERM:LDIF}} file created by {{B:slapo-auditlog(5)}} would look like:
200 > # add 1196797576 dc=suretecsystems,dc=com cn=admin,dc=suretecsystems,dc=com
201 > dn: dc=suretecsystems,dc=com
203 > objectClass: dcObject
204 > objectClass: organization
206 > o: Suretec Systems Ltd.
207 > structuralObjectClass: organization
208 > entryUUID: 1606f8f8-f06e-1029-8289-f0cc9d81e81a
209 > creatorsName: cn=admin,dc=suretecsystems,dc=com
210 > modifiersName: cn=admin,dc=suretecsystems,dc=com
211 > createTimestamp: 20051123130912Z
212 > modifyTimestamp: 20051123130912Z
213 > entryCSN: 20051123130912.000000Z#000001#000#000000
214 > auditContext: cn=accesslog
215 > # end add 1196797576
217 > # add 1196797577 dc=suretecsystems,dc=com cn=admin,dc=suretecsystems,dc=com
218 > dn: ou=Groups,dc=suretecsystems,dc=com
221 > objectClass: organizationalUnit
223 > structuralObjectClass: organizationalUnit
224 > entryUUID: 160aaa2a-f06e-1029-828a-f0cc9d81e81a
225 > creatorsName: cn=admin,dc=suretecsystems,dc=com
226 > modifiersName: cn=admin,dc=suretecsystems,dc=com
227 > createTimestamp: 20051123130912Z
228 > modifyTimestamp: 20051123130912Z
229 > entryCSN: 20051123130912.000000Z#000002#000#000000
230 > # end add 1196797577
233 H3: Further Information
235 {{:slapo-auditlog(5)}}
243 The chain overlay provides basic chaining capability to the underlying
246 What is chaining? It indicates the capability of a DSA to follow referrals on
247 behalf of the client, so that distributed systems are viewed as a single
248 virtual DSA by clients that are otherwise unable to "chase" (i.e. follow)
249 referrals by themselves.
251 The chain overlay is built on top of the ldap backend; it is compiled by
252 default when {{B:--enable-ldap}}.
255 H3: Chaining Configuration
257 In order to demonstrate how this overlay works, we shall discuss a typical
258 scenario which might be one master server and three Syncrepl slaves.
260 On each replica, add this near the top of the {{slapd.conf}}(5) file
261 (global), before any database definitions:
264 > chain-uri "ldap://ldapmaster.example.com"
265 > chain-idassert-bind bindmethod="simple"
266 > binddn="cn=Manager,dc=example,dc=com"
267 > credentials="<secret>"
270 > chain-return-error TRUE
272 Add this below your {{syncrepl}} statement:
274 > updateref "ldap://ldapmaster.example.com/"
276 The {{B:chain-tls}} statement enables TLS from the slave to the ldap master.
277 The DITs are exactly the same between these machines, therefore whatever user
278 bound to the slave will also exist on the master. If that DN does not have
279 update privileges on the master, nothing will happen.
281 You will need to restart the slave after these {{slapd.conf}} changes.
282 Then, if you are using {{loglevel stats}} (256), you can monitor an
283 {{ldapmodify}} on the slave and the master. (If you're using {{cn=config}}
284 no restart is required.)
286 Now start an {{ldapmodify}} on the slave and watch the logs. You should expect
289 > Sep 6 09:27:25 slave1 slapd[29274]: conn=11 fd=31 ACCEPT from IP=143.199.102.216:45181 (IP=143.199.102.216:389)
290 > Sep 6 09:27:25 slave1 slapd[29274]: conn=11 op=0 STARTTLS
291 > Sep 6 09:27:25 slave1 slapd[29274]: conn=11 op=0 RESULT oid= err=0 text=
292 > Sep 6 09:27:25 slave1 slapd[29274]: conn=11 fd=31 TLS established tls_ssf=256 ssf=256
293 > Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=1 BIND dn="uid=user1,ou=people,dc=example,dc=com" method=128
294 > Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=1 BIND dn="uid=user1,ou=People,dc=example,dc=com" mech=SIMPLE ssf=0
295 > Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=1 RESULT tag=97 err=0 text=
296 > Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=2 MOD dn="uid=user1,ou=People,dc=example,dc=com"
297 > Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=2 MOD attr=mail
298 > Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=2 RESULT tag=103 err=0 text=
299 > Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=3 UNBIND
300 > Sep 6 09:27:28 slave1 slapd[29274]: conn=11 fd=31 closed
301 > Sep 6 09:27:28 slave1 slapd[29274]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
302 > Sep 6 09:27:28 slave1 slapd[29274]: syncrepl_entry: be_search (0)
303 > Sep 6 09:27:28 slave1 slapd[29274]: syncrepl_entry: uid=user1,ou=People,dc=example,dc=com
304 > Sep 6 09:27:28 slave1 slapd[29274]: syncrepl_entry: be_modify (0)
306 And on the master you will see this:
308 > Sep 6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 PROXYAUTHZ dn="uid=user1,ou=people,dc=example,dc=com"
309 > Sep 6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 MOD dn="uid=user1,ou=People,dc=example,dc=com"
310 > Sep 6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 MOD attr=mail
311 > Sep 6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 RESULT tag=103 err=0 text=
313 Note: You can clearly see the PROXYAUTHZ line on the master, indicating the
314 proper identity assertion for the update on the master. Also note the slave
315 immediately receiving the Syncrepl update from the master.
317 H3: Handling Chaining Errors
319 By default, if chaining fails, the original referral is returned to the client
320 under the assumption that the client might want to try and follow the referral.
322 With the following directive however, if the chaining fails at the provider
323 side, the actual error is returned to the client.
325 > chain-return-error TRUE
328 H3: Read-Back of Chained Modifications
330 Occasionally, applications want to read back the data that they just wrote.
331 If a modification requested to a shadow server was silently chained to its
332 provider, an immediate read could result in receiving data not yet synchronized.
333 In those cases, clients should use the {{B:dontusecopy}} control to ensure
334 they are directed to the authoritative source for that piece of data.
336 This control usually causes a referral to the actual source of the data
337 to be returned. However, when the {{slapo-chain(5)}} overlay is used,
338 it intercepts the referral being returned in response to the
339 {{B:dontusecopy}} control, and tries to fetch the requested data.
342 H3: Further Information
352 This overlay enforces a regular expression constraint on all values
353 of specified attributes during an LDAP modify request that contains add or modify
354 commands. It is used to enforce a more rigorous syntax when the underlying attribute
355 syntax is too general.
358 H3: Constraint Configuration
360 Configuration via {{slapd.conf}}(5) would look like:
363 > constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$
364 > constraint_attribute title uri
365 > ldap:///dc=catalog,dc=example,dc=com?title?sub?(objectClass=titleCatalog)
367 A specification like the above would reject any {{mail}} attribute which did not
368 look like {{<alpha-numeric string>@mydomain.com}}.
370 It would also reject any title attribute whose values were not listed in the
371 title attribute of any {{titleCatalog}} entries in the given scope.
373 An example for use with {{cn=config}}:
375 > dn: olcOverlay=constraint,olcDatabase={1}mdb,cn=config
377 > objectClass: olcOverlayConfig
378 > objectClass: olcConstraintConfig
379 > olcOverlay: constraint
380 > olcConstraintAttribute: mail regex ^[[:alnum:]]+@mydomain.com$
381 > olcConstraintAttribute: title uri ldap:///dc=catalog,dc=example,dc=com?title?sub?(objectClass=titleCatalog)
384 H3: Further Information
386 {{:slapo-constraint(5)}}
389 H2: Dynamic Directory Services
394 The {{dds}} overlay to {{slapd}}(8) implements dynamic objects as per {{REF:RFC2589}}.
395 The name {{dds}} stands for Dynamic Directory Services. It allows to define
396 dynamic objects, characterized by the {{dynamicObject}} objectClass.
398 Dynamic objects have a limited lifetime, determined by a time-to-live (TTL)
399 that can be refreshed by means of a specific refresh extended operation. This
400 operation allows to set the Client Refresh Period (CRP), namely the period
401 between refreshes that is required to preserve the dynamic object from expiration.
402 The expiration time is computed by adding the requested TTL to the current time.
403 When dynamic objects reach the end of their lifetime without being further
404 refreshed, they are automatically {{deleted}}. There is no guarantee of immediate
405 deletion, so clients should not count on it.
407 H3: Dynamic Directory Service Configuration
409 A usage of dynamic objects might be to implement dynamic meetings; in this case,
410 all the participants to the meeting are allowed to refresh the meeting object,
411 but only the creator can delete it (otherwise it will be deleted when the TTL expires).
413 If we add the overlay to an example database, specifying a Max TTL of 1 day, a
414 min of 10 seconds, with a default TTL of 1 hour. We'll also specify an interval
415 of 120 (less than 60s might be too small) seconds between expiration checks and a
416 tolerance of 5 second (lifetime of a dynamic object will be {{entryTtl + tolerance}}).
427 > entryExpireTimestamp
429 Creating a meeting is as simple as adding the following:
431 > dn: cn=OpenLDAP Documentation Meeting,ou=Meetings,dc=example,dc=com
432 > objectClass: groupOfNames
433 > objectClass: dynamicObject
434 > cn: OpenLDAP Documentation Meeting
435 > member: uid=ghenry,ou=People,dc=example,dc=com
436 > member: uid=hyc,ou=People,dc=example,dc=com
438 H4: Dynamic Directory Service ACLs
440 Allow users to start a meeting and to join it; restrict refresh to the {{member}};
441 restrict delete to the creator:
443 > access to attrs=userPassword
447 > access to dn.base="ou=Meetings,dc=example,dc=com"
451 > access to dn.onelevel="ou=Meetings,dc=example,dc=com"
453 > by dnattr=creatorsName write
456 > access to dn.onelevel="ou=Meetings,dc=example,dc=com"
458 > by dnattr=creatorsName write
462 > access to dn.onelevel="ou=Meetings,dc=example,dc=com"
464 > by dnattr=member manage
467 In simple terms, the user who created the {{OpenLDAP Documentation Meeting}} can add new attendees,
468 refresh the meeting using (basically complete control):
470 > ldapexop -x -H ldap://ldaphost "refresh" "cn=OpenLDAP Documentation Meeting,ou=Meetings,dc=example,dc=com" "120" -D "uid=ghenry,ou=People,dc=example,dc=com" -W
472 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.
475 H3: Further Information
485 This overlay extends the Compare operation to detect
486 members of a dynamic group. This overlay is now deprecated
487 as all of its functions are available using the
488 {{SECT:Dynamic Lists}} overlay.
491 H3: Dynamic Group Configuration
499 This overlay allows expansion of dynamic groups and lists. Instead of having the
500 group members or list attributes hard coded, this overlay allows us to define
501 an LDAP search whose results will make up the group or list.
503 H3: Dynamic List Configuration
505 This module can behave both as a dynamic list and dynamic group, depending on
506 the configuration. The syntax is as follows:
509 > dynlist-attrset <group-oc> <URL-ad> [member-ad]
511 The parameters to the {{F:dynlist-attrset}} directive have the following meaning:
512 * {{F:<group-oc>}}: specifies which object class triggers the subsequent LDAP search.
513 Whenever an entry with this object class is retrieved, the search is performed.
514 * {{F:<URL-ad>}}: is the name of the attribute which holds the search URI. It
515 has to be a subtype of {{F:labeledURI}}. The attributes and values present in
516 the search result are added to the entry unless {{F:member-ad}} is used (see
518 * {{F:member-ad}}: if present, changes the overlay behavior into a dynamic group.
519 Instead of inserting the results of the search in the entry, the distinguished name
520 of the results are added as values of this attribute.
522 Here is an example which will allow us to have an email alias which automatically
523 expands to all user's emails according to our LDAP filter:
525 In {{slapd.conf}}(5):
528 > dynlist-attrset nisMailAlias labeledURI
530 This means that whenever an entry which has the {{F:nisMailAlias}} object class is
531 retrieved, the search specified in the {{F:labeledURI}} attribute is performed.
533 Let's say we have this entry in our directory:
535 > cn=all,ou=aliases,dc=example,dc=com
537 > objectClass: nisMailAlias
538 > labeledURI: ldap:///ou=People,dc=example,dc=com?mail?one?(objectClass=inetOrgPerson)
540 If this entry is retrieved, the search specified in {{F:labeledURI}} will be
541 performed and the results will be added to the entry just as if they have always
542 been there. In this case, the search filter selects all entries directly
543 under {{F:ou=People}} that have the {{F:inetOrgPerson}} object class and retrieves
544 the {{F:mail}} attribute, if it exists.
546 This is what gets added to the entry when we have two users under {{F:ou=People}}
547 that match the filter:
548 !import "allmail-en.png"; align="center"; title="Dynamic list for email aliases"
549 FT[align="Center"] Figure X.Y: Dynamic List for all emails
551 The configuration for a dynamic group is similar. Let's see an example which would
552 automatically populate an {{F:allusers}} group with all the user accounts in the
555 In {{F:slapd.conf}}(5):
557 > include /path/to/dyngroup.schema
560 > dynlist-attrset groupOfURLs labeledURI member
562 +Note: We must include the {{F:dyngroup.schema}} file that defines the
563 +{{F:groupOfURLs}} objectClass used in this example.
565 Let's apply it to the following entry:
567 > cn=allusers,ou=group,dc=example,dc=com
569 > objectClass: groupOfURLs
570 > labeledURI: ldap:///ou=people,dc=example,dc=com??one?(objectClass=inetOrgPerson)
572 The behavior is similar to the dynamic list configuration we had before:
573 whenever an entry with the {{F:groupOfURLs}} object class is retrieved, the
574 search specified in the {{F:labeledURI}} attribute is performed. But this time,
575 only the distinguished names of the results are added, and as values of the
576 {{F:member}} attribute.
579 !import "allusersgroup-en.png"; align="center"; title="Dynamic group for all users"
580 FT[align="Center"] Figure X.Y: Dynamic Group for all users
582 Note that a side effect of this scheme of dynamic groups is that the members
583 need to be specified as full DNs. So, if you are planning in using this for
584 {{F:posixGroup}}s, be sure to use RFC2307bis and some attribute which can hold
585 distinguished names. The {{F:memberUid}} attribute used in the {{F:posixGroup}}
586 object class can hold only names, not DNs, and is therefore not suitable for
590 H3: Further Information
592 {{:slapo-dynlist(5)}}
595 H2: Reverse Group Membership Maintenance
599 In some scenarios, it may be desirable for a client to be able to determine
600 which groups an entry is a member of, without performing an additional search.
601 Examples of this are applications using the {{TERM:DIT}} for access control
602 based on group authorization.
604 The {{B:memberof}} overlay updates an attribute (by default {{B:memberOf}}) whenever
605 changes occur to the membership attribute (by default {{B:member}}) of entries of the
606 objectclass (by default {{B:groupOfNames}}) configured to trigger updates.
608 Thus, it provides maintenance of the list of groups an entry is a member of,
609 when usual maintenance of groups is done by modifying the members on the group
612 H3: Member Of Configuration
614 The typical use of this overlay requires just enabling the overlay for a
615 specific database. For example, with the following minimal slapd.conf:
617 > include /usr/share/openldap/schema/core.schema
618 > include /usr/share/openldap/schema/cosine.schema
620 > authz-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth"
621 > "cn=Manager,dc=example,dc=com"
623 > suffix "dc=example,dc=com"
624 > rootdn "cn=Manager,dc=example,dc=com"
626 > directory /var/lib/ldap2.4
628 > index objectClass eq
633 adding the following ldif:
636 > dn: dc=example,dc=com
637 > objectclass: domain
640 > dn: ou=Group,dc=example,dc=com
641 > objectclass: organizationalUnit
644 > dn: ou=People,dc=example,dc=com
645 > objectclass: organizationalUnit
648 > dn: uid=test1,ou=People,dc=example,dc=com
649 > objectclass: account
652 > dn: cn=testgroup,ou=Group,dc=example,dc=com
653 > objectclass: groupOfNames
655 > member: uid=test1,ou=People,dc=example,dc=com
657 Results in the following output from a search on the test1 user:
659 > # ldapsearch -LL -Y EXTERNAL -H ldapi:/// "(uid=test1)" -b dc=example,dc=com memberOf
660 > SASL/EXTERNAL authentication started
661 > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
665 > dn: uid=test1,ou=People,dc=example,dc=com
666 > memberOf: cn=testgroup,ou=Group,dc=example,dc=com
668 Note that the {{B:memberOf}} attribute is an operational attribute, so it must be
669 requested explicitly.
672 H3: Further Information
674 {{:slapo-memberof(5)}}
677 H2: The Proxy Cache Engine
679 {{TERM:LDAP}} servers typically hold one or more subtrees of a
680 {{TERM:DIT}}. Replica (or shadow) servers hold shadow copies of
681 entries held by one or more master servers. Changes are propagated
682 from the master server to replica (slave) servers using LDAP Sync
683 replication. An LDAP cache is a special type of replica which holds
684 entries corresponding to search filters instead of subtrees.
688 The proxy cache extension of slapd is designed to improve the
689 responsiveness of the ldap and meta backends. It handles a search
691 by first determining whether it is contained in any cached search
692 filter. Contained requests are answered from the proxy cache's local
693 database. Other requests are passed on to the underlying ldap or
694 meta backend and processed as usual.
696 E.g. {{EX:(shoesize>=9)}} is contained in {{EX:(shoesize>=8)}} and
697 {{EX:(sn=Richardson)}} is contained in {{EX:(sn=Richards*)}}
699 Correct matching rules and syntaxes are used while comparing
700 assertions for query containment. To simplify the query containment
701 problem, a list of cacheable "templates" (defined below) is specified
702 at configuration time. A query is cached or answered only if it
703 belongs to one of these templates. The entries corresponding to
704 cached queries are stored in the proxy cache local database while
705 its associated meta information (filter, scope, base, attributes)
706 is stored in main memory.
708 A template is a prototype for generating LDAP search requests.
709 Templates are described by a prototype search filter and a list of
710 attributes which are required in queries generated from the template.
711 The representation for prototype filter is similar to {{REF:RFC4515}},
712 except that the assertion values are missing. Examples of prototype
713 filters are: (sn=),(&(sn=)(givenname=)) which are instantiated by
714 search filters (sn=Doe) and (&(sn=Doe)(givenname=John)) respectively.
716 The cache replacement policy removes the least recently used (LRU)
717 query and entries belonging to only that query. Queries are allowed
718 a maximum time to live (TTL) in the cache thus providing weak
719 consistency. A background task periodically checks the cache for
720 expired queries and removes them.
722 The Proxy Cache paper
723 ({{URL:http://www.openldap.org/pub/kapurva/proxycaching.pdf}}) provides
724 design and implementation details.
727 H3: Proxy Cache Configuration
729 The cache configuration specific directives described below must
730 appear after a {{EX:overlay pcache}} directive within a
731 {{EX:"database meta"}} or {{EX:"database ldap"}} section of
732 the server's {{slapd.conf}}(5) file.
734 H4: Setting cache parameters
736 > pcache <DB> <maxentries> <nattrsets> <entrylimit> <period>
738 This directive enables proxy caching and sets general cache
739 parameters. The <DB> parameter specifies which underlying database
740 is to be used to hold cached entries. It should be set to
741 {{EX:bdb}} or {{EX:hdb}}. The <maxentries> parameter specifies the
742 total number of entries which may be held in the cache. The
743 <nattrsets> parameter specifies the total number of attribute sets
744 (as specified by the {{EX:pcacheAttrset}} directive) that may be
745 defined. The <entrylimit> parameter specifies the maximum number of
746 entries in a cacheable query. The <period> specifies the consistency
747 check period (in seconds). In each period, queries with expired
750 H4: Defining attribute sets
752 > pcacheAttrset <index> <attrs...>
754 Used to associate a set of attributes to an index. Each attribute
755 set is associated with an index number from 0 to <numattrsets>-1.
756 These indices are used by the pcacheTemplate directive to define
759 H4: Specifying cacheable templates
761 > pcacheTemplate <prototype_string> <attrset_index> <TTL>
763 Specifies a cacheable template and the "time to live" (in sec) <TTL>
764 for queries belonging to the template. A template is described by
765 its prototype filter string and set of required attributes identified
769 H4: Example for slapd.conf
771 An example {{slapd.conf}}(5) database section for a caching server
772 which proxies for the {{EX:"dc=example,dc=com"}} subtree held
773 at server {{EX:ldap.example.com}}.
776 > suffix "dc=example,dc=com"
777 > rootdn "dc=example,dc=com"
778 > uri ldap://ldap.example.com/
780 > pcache hdb 100000 1 1000 100
781 > pcacheAttrset 0 mail postaladdress telephonenumber
782 > pcacheTemplate (sn=) 0 3600
783 > pcacheTemplate (&(sn=)(givenName=)) 0 3600
784 > pcacheTemplate (&(departmentNumber=)(secretary=*)) 0 3600
787 > directory ./testrun/db.2.a
788 > index objectClass eq
789 > index cn,sn,uid,mail pres,eq,sub
791 H4: Example for slapd-config
793 The same example as a LDIF file for back-config for a caching server
794 which proxies for the {{EX:"dc=example,dc=com"}} subtree held
795 at server {{EX:ldap.example.com}}.
797 > dn: olcDatabase={2}ldap,cn=config
798 > objectClass: olcDatabaseConfig
799 > objectClass: olcLDAPConfig
800 > olcDatabase: {2}ldap
801 > olcSuffix: dc=example,dc=com
802 > olcRootDN: dc=example,dc=com
803 > olcDbURI: "ldap://ldap.example.com"
805 > dn: olcOverlay={0}pcache,olcDatabase={2}ldap,cn=config
806 > objectClass: olcOverlayConfig
807 > objectClass: olcPcacheConfig
808 > olcOverlay: {0}pcache
809 > olcPcache: hdb 100000 1 1000 100
810 > olcPcacheAttrset: 0 mail postalAddress telephoneNumber
811 > olcPcacheTemplate: "(sn=)" 0 3600 0 0 0
812 > olcPcacheTemplate: "(&(sn=)(givenName=))" 0 3600 0 0 0
813 > olcPcacheTemplate: "(&(departmentNumber=)(secretary=))" 0 3600
815 > dn: olcDatabase={0}mdb,olcOverlay={0}pcache,olcDatabase={2}ldap,cn=config
816 > objectClass: olcMdbConfig
817 > objectClass: olcPcacheDatabase
818 > olcDatabase: {0}mdb
819 > olcDbDirectory: ./testrun/db.2.a
821 > olcDbIndex: objectClass eq
822 > olcDbIndex: cn,sn,uid,mail pres,eq,sub
825 H5: Cacheable Queries
827 A LDAP search query is cacheable when its filter matches one of the
828 templates as defined in the "pcacheTemplate" statements and when it references
829 only the attributes specified in the corresponding attribute set.
830 In the example above the attribute set number 0 defines that only the
831 attributes: {{EX:mail postaladdress telephonenumber}} are cached for the following
836 > Filter: (&(sn=Richard*)(givenName=jack))
837 > Attrs: mail telephoneNumber
839 is cacheable, because it matches the template {{EX:(&(sn=)(givenName=))}} and its
840 attributes are contained in pcacheAttrset 0.
842 > Filter: (&(sn=Richard*)(telephoneNumber))
845 is not cacheable, because the filter does not match the template,
846 nor is the attribute givenName stored in the cache
848 > Filter: (|(sn=Richard*)(givenName=jack))
849 > Attrs: mail telephoneNumber
851 is not cacheable, because the filter does not match the template ( logical
852 OR "|" condition instead of logical AND "&" )
855 H3: Further Information
860 H2: Password Policies
865 This overlay follows the specifications contained in the draft RFC titled
866 draft-behera-ldap-password-policy-09. While the draft itself is expired, it has
867 been implemented in several directory servers, including slapd. Nonetheless,
868 it is important to note that it is a draft, meaning that it is subject to change
869 and is a work-in-progress.
871 The key abilities of the password policy overlay are as follows:
873 * Enforce a minimum length for new passwords
874 * Make sure passwords are not changed too frequently
875 * Cause passwords to expire, provide warnings before they need to be changed, and allow a fixed number of 'grace' logins to allow them to be changed after they have expired
876 * Maintain a history of passwords to prevent password re-use
877 * Prevent password guessing by locking a password for a specified period of time after repeated authentication failures
878 * Force a password to be changed at the next authentication
879 * Set an administrative lock on an account
880 * Support multiple password policies on a default or a per-object basis.
881 * Perform arbitrary quality checks using an external loadable module. This is a non-standard extension of the draft RFC.
884 H3: Password Policy Configuration
886 Instantiate the module in the database where it will be used, after adding the
887 new ppolicy schema and loading the ppolicy module. The following example shows
888 the ppolicy module being added to the database that handles the naming
889 context "dc=example,dc=com". In this example we are also specifying the DN of
890 a policy object to use if none other is specified in a user's object.
893 > suffix "dc=example,dc=com"
894 > [...additional database configuration directives go here...]
897 > ppolicy_default "cn=default,ou=policies,dc=example,dc=com"
900 Now we need a container for the policy objects. In our example the password
901 policy objects are going to be placed in a section of the tree called
902 "ou=policies,dc=example,dc=com":
904 > dn: ou=policies,dc=example,dc=com
905 > objectClass: organizationalUnit
910 The default policy object that we are creating defines the following policies:
912 * The user is allowed to change his own password. Note that the directory ACLs for this attribute can also affect this ability (pwdAllowUserChange: TRUE).
913 * The name of the password attribute is "userPassword" (pwdAttribute: userPassword). Note that this is the only value that is accepted by OpenLDAP for this attribute.
914 * The server will check the syntax of the password. If the server is unable to check the syntax (i.e., it was hashed or otherwise encoded by the client) it will return an error refusing the password (pwdCheckQuality: 2).
915 * When a client includes the Password Policy Request control with a bind request, the server will respond with a password expiration warning if it is going to expire in ten minutes or less (pwdExpireWarning: 600). The warnings themselves are returned in a Password Policy Response control.
916 * When the password for a DN has expired, the server will allow five additional "grace" logins (pwdGraceAuthNLimit: 5).
917 * The server will maintain a history of the last five passwords that were used for a DN (pwdInHistory: 5).
918 * The server will lock the account after the maximum number of failed bind attempts has been exceeded (pwdLockout: TRUE).
919 * When the server has locked an account, the server will keep it locked until an administrator unlocks it (pwdLockoutDuration: 0)
920 * The server will reset its failed bind count after a period of 30 seconds.
921 * Passwords will not expire (pwdMaxAge: 0).
922 * Passwords can be changed as often as desired (pwdMinAge: 0).
923 * Passwords must be at least 5 characters in length (pwdMinLength: 5).
924 * The password does not need to be changed at the first bind or when the administrator has reset the password (pwdMustChange: FALSE)
925 * The current password does not need to be included with password change requests (pwdSafeModify: FALSE)
926 * The server will only allow five failed binds in a row for a particular DN (pwdMaxFailure: 5).
929 The actual policy would be:
931 > dn: cn=default,ou=policies,dc=example,dc=com
933 > objectClass: pwdPolicy
934 > objectClass: person
936 > pwdAllowUserChange: TRUE
937 > pwdAttribute: userPassword
939 > pwdExpireWarning: 600
940 > pwdFailureCountInterval: 30
941 > pwdGraceAuthNLimit: 5
944 > pwdLockoutDuration: 0
949 > pwdMustChange: FALSE
950 > pwdSafeModify: FALSE
953 You can create additional policy objects as needed.
956 There are two ways password policy can be applied to individual objects:
958 1. The pwdPolicySubentry in a user's object - If a user's object has a
959 pwdPolicySubEntry attribute specifying the DN of a policy object, then
960 the policy defined by that object is applied.
962 2. Default password policy - If there is no specific pwdPolicySubentry set
963 for an object, and the password policy module was configured with the DN of a
964 default policy object and if that object exists, then the policy defined in
965 that object is applied.
967 Please see {{slapo-ppolicy(5)}} for complete explanations of features and discussion of
968 "Password Management Issues" at {{URL:http://www.symas.com/blog/?page_id=66}}
971 H3: Further Information
973 {{:slapo-ppolicy(5)}}
976 H2: Referential Integrity
981 This overlay can be used with a backend database such as slapd-bdb(5)
982 to maintain the cohesiveness of a schema which utilizes reference
985 Whenever a {{modrdn}} or {{delete}} is performed, that is, when an entry's DN
986 is renamed or an entry is removed, the server will search the directory for
987 references to this DN (in selected attributes: see below) and update them
988 accordingly. If it was a {{delete}} operation, the reference is deleted. If it
989 was a {{modrdn}} operation, then the reference is updated with the new DN.
991 For example, a very common administration task is to maintain group membership
992 lists, specially when users are removed from the directory. When an
993 user account is deleted or renamed, all groups this user is a member of have to be
994 updated. LDAP administrators usually have scripts for that. But we can use the
995 {{F:refint}} overlay to automate this task. In this example, if the user is
996 removed from the directory, the overlay will take care to remove the user from
997 all the groups he/she was a member of. No more scripting for this.
999 H3: Referential Integrity Configuration
1001 The configuration for this overlay is as follows:
1004 > refint_attributes <attribute [attribute ...]>
1005 > refint_nothing <string>
1007 * {{F:refint_attributes}}: this parameter specifies a space separated list of
1008 attributes which will have the referential integrity maintained. When an entry is
1009 removed or has its DN renamed, the server will do an internal search for any of the
1010 {{F:refint_attributes}} that point to the affected DN and update them accordingly. IMPORTANT:
1011 the attributes listed here must have the {{F:distinguishedName}} syntax, that is,
1013 * {{F:refint_nothing}}: some times, while trying to maintain the referential
1014 integrity, the server has to remove the last attribute of its kind from an
1015 entry. This may be prohibited by the schema: for example, the
1016 {{F:groupOfNames}} object class requires at least one member. In these cases,
1017 the server will add the attribute value specified in {{F:refint_nothing}}
1020 To illustrate this overlay, we will use the group membership scenario.
1022 In {{F:slapd.conf}}:
1025 > refint_attributes member
1026 > refint_nothing "cn=admin,dc=example,dc=com"
1028 This configuration tells the overlay to maintain the referential integrity of the {{F:member}}
1029 attribute. This attribute is used in the {{F:groupOfNames}} object class which always needs
1030 a member, so we add the {{F:refint_nothing}} directive to fill in the group with a standard
1031 member should all the members vanish.
1033 If we have the following group membership, the refint overlay will
1034 automatically remove {{F:john}} from the group if his entry is removed from the
1037 !import "refint.png"; align="center"; title="Group membership"
1038 FT[align="Center"] Figure X.Y: Maintaining referential integrity in groups
1040 Notice that if we rename ({{F:modrdn}}) the {{F:john}} entry to, say, {{F:jsmith}}, the refint
1041 overlay will also rename the reference in the {{F:member}} attribute, so the group membership
1044 If we removed all users from the directory who are a member of this group, then the end result
1045 would be a single member in the group: {{F:cn=admin,dc=example,dc=com}}. This is the
1046 {{F:refint_nothing}} parameter kicking into action so that the schema is not violated.
1048 The {{rootdn}} must be set for the database as refint runs as the {{rootdn}} to gain access to
1049 make its updates. The {{rootpw}} does not need to be set.
1051 H3: Further Information
1053 {{:slapo-refint(5)}}
1061 This overlay is useful to test the behavior of clients when
1062 server-generated erroneous and/or unusual responses occur,
1063 for example; error codes, referrals, excessive response times and so on.
1065 This would be classed as a debugging tool whilst developing client software
1066 or additional Overlays.
1068 For detailed information, please see the {{slapo-retcode(5)}} man page.
1071 H3: Return Code Configuration
1073 The retcode overlay utilizes the "return code" schema described in the man page.
1074 This schema is specifically designed for use with this overlay and is not intended
1075 to be used otherwise.
1077 Note: The necessary schema is loaded automatically by the overlay.
1079 An example configuration might be:
1082 > retcode-parent "ou=RetCodes,dc=example,dc=com"
1083 > include ./retcode.conf
1085 > retcode-item "cn=Unsolicited" 0x00 unsolicited="0"
1086 > retcode-item "cn=Notice of Disconnect" 0x00 unsolicited="1.3.6.1.4.1.1466.20036"
1087 > retcode-item "cn=Pre-disconnect" 0x34 flags="pre-disconnect"
1088 > retcode-item "cn=Post-disconnect" 0x34 flags="post-disconnect"
1090 Note: {{retcode.conf}} can be found in the openldap source at: {{F:tests/data/retcode.conf}}
1092 An excerpt of a {{F:retcode.conf}} would be something like:
1094 > retcode-item "cn=success" 0x00
1096 > retcode-item "cn=success w/ delay" 0x00 sleeptime=2
1098 > retcode-item "cn=operationsError" 0x01
1099 > retcode-item "cn=protocolError" 0x02
1100 > retcode-item "cn=timeLimitExceeded" 0x03 op=search
1101 > retcode-item "cn=sizeLimitExceeded" 0x04 op=search
1102 > retcode-item "cn=compareFalse" 0x05 op=compare
1103 > retcode-item "cn=compareTrue" 0x06 op=compare
1104 > retcode-item "cn=authMethodNotSupported" 0x07
1105 > retcode-item "cn=strongAuthNotSupported" 0x07 text="same as authMethodNotSupported"
1106 > retcode-item "cn=strongAuthRequired" 0x08
1107 > retcode-item "cn=strongerAuthRequired" 0x08 text="same as strongAuthRequired"
1109 Please see {{F:tests/data/retcode.conf}} for a complete {{F:retcode.conf}}
1112 H3: Further Information
1114 {{:slapo-retcode(5)}}
1122 It performs basic DN/data rewrite and objectClass/attributeType mapping. Its
1123 usage is mostly intended to provide virtual views of existing data either
1124 remotely, in conjunction with the proxy backend described in {{slapd-ldap(5)}},
1125 or locally, in conjunction with the relay backend described in {{slapd-relay(5)}}.
1127 This overlay is extremely configurable and advanced, therefore recommended
1128 reading is the {{slapo-rwm(5)}} man page.
1131 H3: Rewrite/Remap Configuration
1134 H3: Further Information
1144 This overlay implements the provider-side support for the LDAP Content Synchronization
1145 ({{REF:RFC4533}}) as well as syncrepl replication support, including persistent search functionality.
1147 H3: Sync Provider Configuration
1149 There is very little configuration needed for this overlay, in fact for many situations merely loading
1150 the overlay will suffice.
1152 However, because the overlay creates a contextCSN attribute in the root entry of the database which is
1153 updated for every write operation performed against the database and only updated in memory, it is
1154 recommended to configure a checkpoint so that the contextCSN is written into the underlying database to
1155 minimize recovery time after an unclean shutdown:
1158 > syncprov-checkpoint 100 10
1160 For every 100 operations or 10 minutes, which ever is sooner, the contextCSN will be checkpointed.
1162 The four configuration directives available are {{B:syncprov-checkpoint}}, {{B:syncprov-sessionlog}},
1163 {{B:syncprov-nopresent}} and {{B:syncprov-reloadhint}} which are covered in the man page discussing
1164 various other scenarios where this overlay can be used.
1166 H3: Further Information
1168 The {{:slapo-syncprov(5)}} man page and the {{SECT:Configuring the different replication types}} section
1171 H2: Translucent Proxy
1176 This overlay can be used with a backend database such as {{:slapd-bdb}}(5)
1177 to create a "translucent proxy".
1179 Entries retrieved from a remote LDAP server may have some or all attributes
1180 overridden, or new attributes added, by entries in the local database before
1181 being presented to the client.
1183 A search operation is first populated with entries from the remote LDAP server,
1184 the attributes of which are then overridden with any attributes defined in the
1185 local database. Local overrides may be populated with the add, modify, and
1186 modrdn operations, the use of which is restricted to the root user of the
1187 translucent local database.
1189 A compare operation will perform a comparison with attributes defined in the
1190 local database record (if any) before any comparison is made with data in the
1194 H3: Translucent Proxy Configuration
1196 There are various options available with this overlay, but for this example we
1197 will demonstrate adding new attributes to a remote entry and also searching
1198 against these newly added local attributes. For more information about overriding remote
1199 entries and search configuration, please see {{:slapo-translucent(5)}}
1201 Note: The Translucent Proxy overlay will disable schema checking in the local
1202 database, so that an entry consisting of overlay attributes need not adhere
1203 to the complete schema.
1205 First we configure the overlay in the normal manner:
1207 > include /usr/local/etc/openldap/schema/core.schema
1208 > include /usr/local/etc/openldap/schema/cosine.schema
1209 > include /usr/local/etc/openldap/schema/nis.schema
1210 > include /usr/local/etc/openldap/schema/inetorgperson.schema
1212 > pidfile ./slapd.pid
1213 > argsfile ./slapd.args
1216 > suffix "dc=suretecsystems,dc=com"
1217 > rootdn "cn=trans,dc=suretecsystems,dc=com"
1219 > directory ./openldap-data
1221 > index objectClass eq
1223 > overlay translucent
1224 > translucent_local carLicense
1226 > uri ldap://192.168.X.X:389
1228 > acl-bind binddn="cn=admin,dc=suretecsystems,dc=com" credentials="blahblah"
1230 You will notice the overlay directive and a directive to say what attribute we
1231 want to be able to search against in the local database. We must also load the
1232 ldap backend which will connect to the remote directory server.
1234 Now we take an example LDAP group:
1236 > # itsupport, Groups, suretecsystems.com
1237 > dn: cn=itsupport,ou=Groups,dc=suretecsystems,dc=com
1238 > objectClass: posixGroup
1239 > objectClass: sambaGroupMapping
1242 > sambaSID: S-1-5-21-XXX
1244 > displayName: itsupport
1246 > memberUid: joebloggs
1248 and create an LDIF file we can use to add our data to the local database, using
1249 some pretty strange choices of new attributes for demonstration purposes:
1251 > [ghenry@suretec test_configs]$ cat test-translucent-add.ldif
1252 > dn: cn=itsupport,ou=Groups,dc=suretecsystems,dc=com
1253 > businessCategory: frontend-override
1255 > employeeType: special
1256 > departmentNumber: 9999999
1257 > roomNumber: 41L-535
1259 Searching against the proxy gives:
1261 > [ghenry@suretec test_configs]$ ldapsearch -x -H ldap://127.0.0.1:9001 "(cn=itsupport)"
1262 > # itsupport, Groups, OxObjects, suretecsystems.com
1263 > dn: cn=itsupport,ou=Groups,ou=OxObjects,dc=suretecsystems,dc=com
1264 > objectClass: posixGroup
1265 > objectClass: sambaGroupMapping
1268 > SAMBASID: S-1-5-21-XXX
1270 > displayName: itsupport
1272 > memberUid: joebloggs
1273 > roomNumber: 41L-535
1274 > departmentNumber: 9999999
1275 > employeeType: special
1277 > businessCategory: frontend-override
1279 Here we can see that the 5 new attributes are added to the remote entry before
1280 being returned to the our client.
1282 Because we have configured a local attribute to search against:
1284 > overlay translucent
1285 > translucent_local carLicense
1287 we can also search for that to return the completely fabricated entry:
1289 > ldapsearch -x -H ldap://127.0.0.1:9001 (carLicense=LIVID)
1291 This is an extremely feature because you can then extend a remote directory server
1292 locally and also search against the local entries.
1294 Note: Because the translucent overlay does not perform any DN rewrites, the local
1295 and remote database instances must have the same suffix. Other configurations
1296 will probably fail with No Such Object and other errors
1298 H3: Further Information
1300 {{:slapo-translucent(5)}}
1303 H2: Attribute Uniqueness
1308 This overlay can be used with a backend database such as {{slapd-bdb(5)}}
1309 to enforce the uniqueness of some or all attributes within a subtree.
1312 H3: Attribute Uniqueness Configuration
1314 This overlay is only effective on new data from the point the overlay is enabled. To
1315 check uniqueness for existing data, you can export and import your data again via the
1316 LDAP Add operation, which will not be suitable for large amounts of data, unlike {{B:slapcat}}.
1318 For the following example, if uniqueness were enforced for the {{B:mail}} attribute,
1319 the subtree would be searched for any other records which also have a {{B:mail}} attribute
1320 containing the same value presented with an {{B:add}}, {{B:modify}} or {{B:modrdn}} operation
1321 which are unique within the configured scope. If any are found, the request is rejected.
1323 Note: If no attributes are specified, for example {{B:ldap:///??sub?}}, then the URI applies to all non-operational attributes. However,
1324 the keyword {{B:ignore}} can be specified to exclude certain non-operational attributes.
1326 To search at the base dn of the current backend database ensuring uniqueness of the {{B:mail}}
1327 attribute, we simply add the following configuration:
1330 > unique_uri ldap:///?mail?sub?
1332 For an existing entry of:
1334 > dn: cn=gavin,dc=suretecsystems,dc=com
1336 > objectClass: inetorgperson
1339 > mail: ghenry@suretecsystems.com
1341 and we then try to add a new entry of:
1343 > dn: cn=robert,dc=suretecsystems,dc=com
1345 > objectClass: inetorgperson
1348 > mail: ghenry@suretecsystems.com
1350 would result in an error like so:
1352 > adding new entry "cn=robert,dc=example,dc=com"
1353 > ldap_add: Constraint violation (19)
1354 > additional info: some attributes not unique
1356 The overlay can have multiple URIs specified within a domain, allowing complex
1357 selections of objects and also have multiple {{B:unique_uri}} statements or
1358 {{B:olcUniqueURI}} attributes which will create independent domains.
1360 For more information and details about the {{B:strict}} and {{B:ignore}} keywords,
1361 please see the {{:slapo-unique(5)}} man page.
1363 H3: Further Information
1365 {{:slapo-unique(5)}}
1373 The Value Sorting overlay can be used with a backend database to sort the
1374 values of specific multi-valued attributes within a subtree. The sorting occurs
1375 whenever the attributes are returned in a search response.
1377 H3: Value Sorting Configuration
1379 Sorting can be specified in ascending or descending order, using either numeric
1380 or alphanumeric sort methods. Additionally, a "weighted" sort can be specified,
1381 which uses a numeric weight prepended to the attribute values.
1383 The weighted sort is always performed in ascending order, but may be combined
1384 with the other methods for values that all have equal weights. The weight is
1385 specified by prepending an integer weight {<weight>} in front of each value
1386 of the attribute for which weighted sorting is desired. This weighting factor
1387 is stripped off and never returned in search results.
1389 Here are a few examples:
1391 > loglevel sync stats
1394 > suffix "dc=suretecsystems,dc=com"
1395 > directory /usr/local/var/openldap-data
1400 > valsort-attr memberUid ou=Groups,dc=suretecsystems,dc=com alpha-ascend
1402 For example, ascend:
1404 > # sharedemail, Groups, suretecsystems.com
1405 > dn: cn=sharedemail,ou=Groups,dc=suretecsystems,dc=com
1406 > objectClass: posixGroup
1411 > memberUid: dovecot
1413 > memberUid: suretec
1415 For weighted, we change our data to:
1417 > # sharedemail, Groups, suretecsystems.com
1418 > dn: cn=sharedemail,ou=Groups,dc=suretecsystems,dc=com
1419 > objectClass: posixGroup
1423 > memberUid: {4}admin
1424 > memberUid: {2}dovecot
1425 > memberUid: {1}laura
1426 > memberUid: {3}suretec
1428 and change the config to:
1431 > valsort-attr memberUid ou=Groups,dc=suretecsystems,dc=com weighted
1433 Searching now results in:
1435 > # sharedemail, Groups, OxObjects, suretecsystems.com
1436 > dn: cn=sharedemail,ou=Groups,ou=OxObjects,dc=suretecsystems,dc=com
1437 > objectClass: posixGroup
1442 > memberUid: dovecot
1443 > memberUid: suretec
1447 H3: Further Information
1449 {{:slapo-valsort(5)}}
1452 H2: Overlay Stacking
1457 Overlays can be stacked, which means that more than one overlay
1458 can be instantiated for each database, or for the {{EX:frontend}}.
1459 As a consequence, each overlays function is called, if defined,
1460 when overlay execution is invoked.
1461 Multiple overlays are executed in reverse order (as a stack)
1462 with respect to their definition in slapd.conf (5), or with respect
1463 to their ordering in the config database, as documented in slapd-config (5).
1466 H3: Example Scenarios