1SLAPD-SQL(5)                  File Formats Manual                 SLAPD-SQL(5)
2
3
4

NAME

6       slapd-sql - SQL backend to slapd
7

SYNOPSIS

9       /etc/openldap/slapd.conf
10

DESCRIPTION

12       The  primary purpose of this slapd(8) backend is to PRESENT information
13       stored in some RDBMS as an LDAP subtree without any  programming  (some
14       SQL and maybe stored procedures can't be considered programming, anyway
15       ;).
16
17       That is, for example, when you (some ISP) have account information  you
18       use  in an RDBMS, and want to use modern solutions that expect such in‐
19       formation in LDAP (to authenticate users, make email lookups etc.).  Or
20       you  want  to  synchronize  or distribute information between different
21       sites/applications that use RDBMSes and/or LDAP.  Or whatever else...
22
23       It is NOT designed as a general-purpose backend that uses RDBMS instead
24       of BerkeleyDB (as the standard BDB backend does), though it can be used
25       as  such  with  several  limitations.   You  can   take   a   look   at
26       http://www.openldap.org/faq/index.cgi?file=378                (OpenLDAP
27       FAQ-O-Matic/General LDAP FAQ/Directories vs. conventional databases) to
28       find out more on this point.
29
30       The  idea (detailed below) is to use some meta-information to translate
31       LDAP queries to SQL queries, leaving relational  schema  untouched,  so
32       that  old applications can continue using it without any modifications.
33       This allows SQL and LDAP applications to inter-operate without replica‐
34       tion, and exchange data as needed.
35
36       The  SQL  backend is designed to be tunable to virtually any relational
37       schema without having to change source (through  that  meta-information
38       mentioned).   Also,  it  uses ODBC to connect to RDBMSes, and is highly
39       configurable for SQL dialects RDBMSes may use, so it may  be  used  for
40       integration  and distribution of data on different RDBMSes, OSes, hosts
41       etc., in other words, in highly heterogeneous environment.
42
43       This backend is experimental.
44

CONFIGURATION

46       These slapd.conf options apply to the SQL backend database, which means
47       that  they must follow a "database sql" line and come before any subse‐
48       quent "backend" or "database" lines.  Other database options  not  spe‐
49       cific to this backend are described in the slapd.conf(5) manual page.
50

DATA SOURCE CONFIGURATION

52       dbname <datasource name>
53              The name of the ODBC datasource to use.
54
55       dbhost <hostname>
56       dbpasswd <password>
57       dbuser <username>
58              The three above options are generally unneeded, because this in‐
59              formation is taken from the datasource specified by  the  dbname
60              directive.   They  allow to override datasource settings.  Also,
61              several RDBMS' drivers  tend  to  require  explicit  passing  of
62              user/password,  even if those are given in datasource (Note: db‐
63              host is currently ignored).
64

SCOPING CONFIGURATION

66       These options specify SQL query templates for scoping searches.
67
68
69       subtree_cond <SQL expression>
70              Specifies a where-clause template used to form a subtree  search
71              condition  (dn="(.+,)?<dn>$").   It  may differ from one SQL di‐
72              alect to another (see samples).  By default, it  is  constructed
73              based  on  the  knowledge about how to normalize DN values (e.g.
74              "<upper_func>(ldap_entries.dn)  LIKE  CONCAT('%',?)");  see  up‐
75              per_func,  upper_needs_cast,  concat_pattern and strcast_func in
76              "HELPER CONFIGURATION" for details.
77
78
79       children_cond <SQL expression>
80              Specifies a where-clause template used to form a children search
81              condition  (dn=".+,<dn>$").   It may differ from one SQL dialect
82              to another (see samples).  By default, it is  constructed  based
83              on  the  knowledge about how to normalize DN values (e.g.  "<up‐
84              per_func>(ldap_entries.dn)  LIKE   CONCAT('%,',?)");   see   up‐
85              per_func,  upper_needs_cast,  concat_pattern and strcast_func in
86              "HELPER CONFIGURATION" for details.
87
88
89       use_subtree_shortcut { YES | no }
90              Do not use the subtree condition  when  the  searchBase  is  the
91              database  suffix,  and  the scope is subtree; rather collect all
92              entries.
93
94

STATEMENT CONFIGURATION

96       These options specify SQL query templates for  loading  schema  mapping
97       meta-information,  adding  and  deleting  entries to ldap_entries, etc.
98       All these and subtree_cond should have the given default  values.   For
99       the  current  value it is recommended to look at the sources, or in the
100       log output when slapd starts with "-d 5" or greater.  Note that the pa‐
101       rameter number and order must not be changed.
102
103
104       oc_query <SQL expression>
105              The  query  that is used to collect the objectClass mapping data
106              from table ldap_oc_mappings; see "METAINFORMATION USED" for  de‐
107              tails.   The  default  is "SELECT id, name, keytbl, keycol, cre‐
108              ate_proc, delete_proc, expect_return FROM ldap_oc_mappings".
109
110
111       at_query <SQL expression>
112              The query that is used to collect the attributeType mapping data
113              from  table  ldap_attr_mappings;  see "METAINFORMATION USED" for
114              details.  The default  is  "SELECT  name,  sel_expr,  from_tbls,
115              join_where,  add_proc,  delete_proc,  param_order, expect_return
116              FROM ldap_attr_mappings WHERE oc_map_id=?".
117
118
119       id_query <SQL expression>
120              The query that is used to map a DN to an entry in table ldap_en‐
121              tries;  see  "METAINFORMATION USED" for details.  The default is
122              "SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE <DN match
123              expr>", where <DN match expr> is constructed based on the knowl‐
124              edge about how to normalize DN values (e.g. "dn=?" if  no  means
125              to   uppercase   strings   are   available;   typically,   "<up‐
126              per_func>(dn)=?" is  used);  see  upper_func,  upper_needs_cast,
127              concat_pattern  and  strcast_func  in "HELPER CONFIGURATION" for
128              details.
129
130
131       insentry_stmt <SQL expression>
132              The statement that is used  to  insert  a  new  entry  in  table
133              ldap_entries;  see  "METAINFORMATION USED" for details.  The de‐
134              fault is "INSERT INTO ldap_entries (dn, oc_map_id, parent,  key‐
135              val) VALUES (?, ?, ?, ?)".
136
137
138       delentry_stmt <SQL expression>
139              The  statement that is used to delete an existing entry from ta‐
140              ble ldap_entries; see "METAINFORMATION USED" for  details.   The
141              default is "DELETE FROM ldap_entries WHERE id=?".
142
143
144       delobjclasses_stmt <SQL expression>
145              The statement that is used to delete an existing entry's ID from
146              table ldap_objclasses; see "METAINFORMATION USED"  for  details.
147              The  default  is  "DELETE  FROM  ldap_entry_objclasses WHERE en‐
148              try_id=?".
149
150

HELPER CONFIGURATION

152       These statements are used to modify the default behavior of the backend
153       according to issues of the dialect of the RDBMS.  The first options es‐
154       sentially refer to string and DN normalization when  building  filters.
155       LDAP  normalization  is  more than upper- (or lower-)casing everything;
156       however, as a reasonable  trade-off,  for  case-sensitive  RDBMSes  the
157       backend can be instructed to uppercase strings and DNs by providing the
158       upper_func directive.  Some RDBMSes, to use functions on arbitrary data
159       types,  e.g.  string  constants, requires a cast, which is triggered by
160       the upper_needs_cast directive.  If required, a  string  cast  function
161       can be provided as well, by using the strcast_func directive.  Finally,
162       a custom string concatenation pattern may be required; it  is  provided
163       by the concat_pattern directive.
164
165
166       upper_func <SQL function name>
167              Specifies  the name of a function that converts a given value to
168              uppercase.  This is used for case insensitive matching when  the
169              RDBMS  is case sensitive.  It may differ from one SQL dialect to
170              another (e.g. UCASE, UPPER or whatever; see  samples).   By  de‐
171              fault, none is used, i.e. strings are not uppercased, so matches
172              may be case sensitive.
173
174
175       upper_needs_cast { NO | yes }
176              Set this directive to yes if upper_func needs an  explicit  cast
177              when applied to literal strings.  A cast in the form CAST (<arg>
178              AS VARCHAR(<max DN length>)) is used, where <max DN  length>  is
179              builtin  in  back-sql;  see  macro BACKSQL_MAX_DN_LEN (currently
180              255;   note   that   slapd's    builtin    limit,    in    macro
181              SLAP_LDAPDN_MAXLEN,  is  set to 8192).  This is experimental and
182              may change in future releases.
183
184
185       strcast_func <SQL function name>
186              Specifies the name of a function that converts a given value  to
187              a string for appropriate ordering.  This is used in "SELECT DIS‐
188              TINCT" statements for strongly typed  RDBMSes  with  little  im‐
189              plicit casting (like PostgreSQL), when a literal string is spec‐
190              ified.  This is experimental and may change in future releases.
191
192
193       concat_pattern <pattern>
194              This statement defines the pattern that is used  to  concatenate
195              strings.  The pattern MUST contain two question marks, '?', that
196              will be replaced by the two strings that must  be  concatenated.
197              The  default  value  is  CONCAT(?,?); a form that is known to be
198              highly portable (IBM db2, PostgreSQL) is ?||?, but  an  explicit
199              cast   may  be  required  when  operating  on  literal  strings:
200              CAST(?||? AS VARCHAR(<length>)).   On  some  RDBMSes  (IBM  db2,
201              MSSQL)  the form ?+?  is known to work as well.  Carefully check
202              the documentation of your RDBMS or stay with  the  examples  for
203              supported  ones.   This is experimental and may change in future
204              releases.
205
206
207       aliasing_keyword <string>
208              Define the aliasing keyword.  Some RDBMSes  use  the  word  "AS"
209              (the default), others don't use any.
210
211
212       aliasing_quote <string>
213              Define  the  quoting char of the aliasing keyword.  Some RDBMSes
214              don't require any (the default), others may  require  single  or
215              double quotes.
216
217
218       has_ldapinfo_dn_ru { NO | yes }
219              Explicitly  inform  the  backend whether the dn_ru column (DN in
220              reverse uppercased  form)  is  present  in  table  ldap_entries.
221              Overrides  automatic  check  (this is required, for instance, by
222              PostgreSQL/unixODBC).  This is experimental and  may  change  in
223              future releases.
224
225
226       fail_if_no_mapping { NO | yes }
227              When  set to yes it forces attribute write operations to fail if
228              no appropriate mapping between LDAP attributes and SQL  data  is
229              available.  The default behavior is to ignore those changes that
230              cannot be mapped.  It has no impact on objectClass mapping, i.e.
231              if the structuralObjectClass of an entry cannot be mapped to SQL
232              by looking up its name in  ldap_oc_mappings,  an  add  operation
233              will  fail regardless of the fail_if_no_mapping switch; see sec‐
234              tion "METAINFORMATION USED" for details.  This  is  experimental
235              and may change in future releases.
236
237
238       allow_orphans { NO | yes }
239              When  set to yes orphaned entries (i.e. without the parent entry
240              in the database) can be added.  This option should be used  with
241              care,  possibly  in  conjunction  with  some special rule on the
242              RDBMS side that dynamically creates the missing parent.
243
244
245       baseObject [ <filename> ]
246              Instructs the database to create and manage an in-memory baseOb‐
247              ject entry instead of looking for one in the RDBMS.  If the (op‐
248              tional) <filename> argument is given, the  entry  is  read  from
249              that  file  in  LDIF(5) format; otherwise, an entry with object‐
250              Class extensibleObject is created based on the contents  of  the
251              RDN  of  the  baseObject.   This  is  particularly  useful  when
252              ldap_entries information is stored in a view rather  than  in  a
253              table,  and  union  is not supported for views, so that the view
254              can only specify one rule to compute the entry structure for one
255              objectClass.    This  topic  is  discussed  further  in  section
256              "METAINFORMATION USED".  This is experimental and may change  in
257              future releases.
258
259
260       create_needs_select { NO | yes }
261              Instructs  the  database  whether or not entry creation in table
262              ldap_entries needs a subsequent select to collect the  automati‐
263              cally  assigned ID, instead of being returned by a stored proce‐
264              dure.
265
266
267       fetch_attrs <attrlist>
268       fetch_all_attrs { NO | yes }
269              The first statement allows one to provide a list  of  attributes
270              that  must  always  be fetched in addition to those requested by
271              any specific operation, because they are required for the proper
272              usage of the backend.  For instance, all attributes used in ACLs
273              should be listed here.  The second statement is  a  shortcut  to
274              require  all  attributes to be always loaded.  Note that the dy‐
275              namically generated attributes,  e.g.  hasSubordinates,  entryDN
276              and  other implementation dependent attributes are NOT generated
277              at this point, for consistency with the rest of slapd.  This may
278              change in the future.
279
280
281       check_schema { YES | no }
282              Instructs  the database to check schema adherence of entries af‐
283              ter modifications, and structural objectClass chain when entries
284              are built.  By default it is set to yes.
285
286
287       sqllayer <name> [...]
288              Loads  the layer <name> onto a stack of helpers that are used to
289              map DNs from LDAP to SQL representation and vice-versa.   Subse‐
290              quent  args are passed to the layer configuration routine.  This
291              is highly experimental and should be  used  with  extreme  care.
292              The API of the layers is not frozen yet, so it is unpublished.
293
294
295       autocommit { NO | yes }
296              Activates autocommit; by default, it is off.
297
298

METAINFORMATION USED

300       Almost everything mentioned later is illustrated in examples located in
301       the  servers/slapd/back-sql/rdbms_depend/  directory  in  the  OpenLDAP
302       source  tree,  and  contains scripts for generating sample database for
303       Oracle, MS SQL Server, mySQL and more  (including  PostgreSQL  and  IBM
304       db2).
305
306       The  first  thing  that  one  must  arrange  is what set of LDAP object
307       classes can present your RDBMS information.
308
309       The easiest way is to create an objectClass for each entity you had  in
310       ER-diagram  when  designing  your  relational  schema.   Any relational
311       schema, no matter how normalized it is, was designed after  some  model
312       of  your application's domain (for instance, accounts, services etc. in
313       ISP), and is used in terms of its entities, not just tables of  normal‐
314       ized  schema.  It means that for every attribute of every such instance
315       there is an effective SQL query that loads its values.
316
317       Also you might want your object classes to conform to some of the stan‐
318       dard schemas like inetOrgPerson etc.
319
320       Nevertheless,  when you think it out, we must define a way to translate
321       LDAP operation requests to (a series of) SQL queries.  Let us deal with
322       the SEARCH operation.
323
324       Example:  Let's suppose that we store information about persons working
325       in our organization in two tables:
326
327         PERSONS              PHONES
328         ----------           -------------
329         id integer           id integer
330         first_name varchar   pers_id integer references persons(id)
331         last_name varchar    phone
332         middle_name varchar
333         ...
334
335       (PHONES contains telephone numbers associated with persons).  A  person
336       can  have  several  numbers,  then PHONES contains several records with
337       corresponding pers_id, or no numbers (and no  records  in  PHONES  with
338       such  pers_id).   An LDAP objectclass to present such information could
339       look like this:
340
341         person
342         -------
343         MUST cn
344         MAY telephoneNumber $ firstName $ lastName
345         ...
346
347       To fetch all values for cn attribute given person ID, we construct  the
348       query:
349
350         SELECT CONCAT(persons.first_name,' ',persons.last_name)
351             AS cn FROM persons WHERE persons.id=?
352
353       for telephoneNumber we can use:
354
355         SELECT phones.phone AS telephoneNumber FROM persons,phones
356             WHERE persons.id=phones.pers_id AND persons.id=?
357
358       If  we wanted to service LDAP requests with filters like (telephoneNum‐
359       ber=123*), we would construct something like:
360
361         SELECT ... FROM persons,phones
362             WHERE persons.id=phones.pers_id
363                 AND persons.id=?
364                 AND phones.phone like '%1%2%3%'
365
366       (note how the telephoneNumber match is expanded in  multiple  wildcards
367       to account for interspersed ininfluential chars like spaces, dashes and
368       so; this occurs by design because telephoneNumber is  defined  after  a
369       specially recognized syntax).  So, if we had information about what ta‐
370       bles contain values for each attribute, how to join  these  tables  and
371       arrange  these  values,  we  could  try  to automatically generate such
372       statements, and translate search filters to SQL WHERE clauses.
373
374       To store such information, we add three more tables to our  schema  and
375       fill it with data (see samples):
376
377         ldap_oc_mappings (some columns are not listed for clarity)
378         ---------------
379         id=1
380         name="person"
381         keytbl="persons"
382         keycol="id"
383
384       This  table defines a mapping between objectclass (its name held in the
385       "name" column), and a table that holds the primary key for  correspond‐
386       ing  entities.   For instance, in our example, the person entity, which
387       we are trying to present as "person" objectclass, resides in two tables
388       (persons  and phones), and is identified by the persons.id column (that
389       we will call the primary key for this entity).  Keytbl and keycol  thus
390       contain "persons" (name of the table), and "id" (name of the column).
391
392         ldap_attr_mappings (some columns are not listed for clarity)
393         -----------
394         id=1
395         oc_map_id=1
396         name="cn"
397         sel_expr="CONCAT(persons.first_name,' ',persons.last_name)"
398         from_tbls="persons"
399         join_where=NULL
400         ************
401         id=<n>
402         oc_map_id=1
403         name="telephoneNumber"
404         sel_expr="phones.phone"
405         from_tbls="persons,phones"
406         join_where="phones.pers_id=persons.id"
407
408       This  table  defines  mappings  between LDAP attributes and SQL queries
409       that load their values.  Note that, unlike LDAP schema, these  are  not
410       attribute  types - the attribute "cn" for "person" objectclass can have
411       its values in different tables than "cn" for some other objectclass, so
412       attribute  mappings  depend  on  objectclass mappings (unlike attribute
413       types in LDAP schema, which are indifferent to  objectclasses).   Thus,
414       we have oc_map_id column with link to oc_mappings table.
415
416       Now we cut the SQL query that loads values for a given attribute into 3
417       parts.  First goes into sel_expr column - this is the expression we had
418       between  SELECT and FROM keywords, which defines WHAT to load.  Next is
419       table list - text between FROM and  WHERE  keywords.   It  may  contain
420       aliases  for convenience (see examples).  The last is part of the where
421       clause, which (if it exists at all) expresses the condition for joining
422       the  table  containing values with the table containing the primary key
423       (foreign key equality and such).  If values are in the  same  table  as
424       the  primary  key,  then  this column is left NULL (as for cn attribute
425       above).
426
427       Having this information in parts, we are able  to  not  only  construct
428       queries  that  load  attribute values by id of entry (for this we could
429       store SQL query as a whole), but to construct queries that load id's of
430       objects  that  correspond to a given search filter (or at least part of
431       it).  See below for examples.
432
433         ldap_entries
434         ------------
435         id=1
436         dn=<dn you choose>
437         oc_map_id=...
438         parent=<parent record id>
439         keyval=<value of primary key>
440
441       This table defines mappings between DNs of entries in your  LDAP  tree,
442       and  values  of primary keys for corresponding relational data.  It has
443       recursive structure (parent column references id column of the same ta‐
444       ble),  which allows you to add any tree structure(s) to your flat rela‐
445       tional data.  Having id of objectclass mapping, we can determine  table
446       and  column for primary key, and keyval stores value of it, thus defin‐
447       ing the exact tuple corresponding to the LDAP entry with this DN.
448
449       Note that such design (see exact SQL table creation query) implies  one
450       important constraint - the key must be an integer.  But all that I know
451       about well-designed schemas makes me think that it's not very narrow ;)
452       If  anyone  needs support for different types for keys - he may want to
453       write a patch, and submit it to OpenLDAP ITS, then I'll include it.
454
455       Also, several users complained that they don't really need very  struc‐
456       tured  trees,  and  they don't want to update one more table every time
457       they add or delete an instance in the relational schema.  Those  people
458       can use a view instead of a real table for ldap_entries, something like
459       this (by Robin Elfrink):
460
461         CREATE VIEW ldap_entries (id, dn, oc_map_id, parent, keyval)
462             AS
463                 SELECT 0, UPPER('o=MyCompany,c=NL'),
464                     3, 0, 'baseObject' FROM unixusers WHERE userid='root'
465             UNION
466                 SELECT (1000000000+userid),
467                     UPPER(CONCAT(CONCAT('cn=',gecos),',o=MyCompany,c=NL')),
468                     1, 0, userid FROM unixusers
469             UNION
470                 SELECT (2000000000+groupnummer),
471                     UPPER(CONCAT(CONCAT('cn=',groupnaam),',o=MyCompany,c=NL')),
472                     2, 0, groupnummer FROM groups;
473
474
475       If your RDBMS does not support unions in views,  only  one  objectClass
476       can be mapped in ldap_entries, and the baseObject cannot be created; in
477       this case, see the baseObject directive for a possible workaround.
478
479

TYPICAL SQL BACKEND OPERATION

481       Having meta-information loaded, the SQL backend uses  these  tables  to
482       determine  a  set  of  primary  keys of candidates (depending on search
483       scope and filter).  It tries to do it for each  objectclass  registered
484       in ldap_objclasses.
485
486       Example:  for our query with filter (telephoneNumber=123*) we would get
487       the following query generated (which loads candidate IDs)
488
489         SELECT ldap_entries.id,persons.id, 'person' AS objectClass,
490                ldap_entries.dn AS dn
491           FROM ldap_entries,persons,phones
492          WHERE persons.id=ldap_entries.keyval
493            AND ldap_entries.objclass=?
494            AND ldap_entries.parent=?
495            AND phones.pers_id=persons.id
496            AND (phones.phone LIKE '%1%2%3%')
497
498       (for ONELEVEL search) or "... AND dn=?" (for BASE search) or  "...  AND
499       dn LIKE '%?'" (for SUBTREE)
500
501       Then,  for  each candidate, we load the requested attributes using per-
502       attribute queries like
503
504         SELECT phones.phone AS telephoneNumber
505           FROM persons,phones
506          WHERE persons.id=? AND phones.pers_id=persons.id
507
508       Then, we use test_filter() from the frontend API to test the entry  for
509       a full LDAP search filter match (since we cannot effectively make sense
510       of SYNTAX of corresponding LDAP schema attribute, we translate the fil‐
511       ter into the most relaxed SQL condition to filter candidates), and send
512       it to the user.
513
514       ADD, DELETE, MODIFY and MODRDN operations are also performed on per-at‐
515       tribute  meta-information  (add_proc  etc.).   In  those fields one can
516       specify an SQL statement or stored procedure call  which  can  add,  or
517       delete  given values of a given attribute, using the given entry keyval
518       (see examples -- mostly PostgreSQL, ORACLE and MSSQL - since as of this
519       writing there are no stored procs in MySQL).
520
521       We  just  add  more columns to ldap_oc_mappings and ldap_attr_mappings,
522       holding statements to execute  (like  create_proc,  add_proc,  del_proc
523       etc.),  and  flags  governing  the  order of parameters passed to those
524       statements.  Please see samples to find out  what  are  the  parameters
525       passed,  and  other information on this matter - they are self-explana‐
526       tory for those familiar with the concepts expressed above.
527

COMMON TECHNIQUES

529       First of all, let's recall that among other major  differences  to  the
530       complete  LDAP  data  model, the above illustrated concept does not di‐
531       rectly support such features as multiple objectclasses per  entry,  and
532       referrals.   Fortunately,  they  are easy to adopt in this scheme.  The
533       SQL backend requires that one  more  table  is  added  to  the  schema:
534       ldap_entry_objectclasses(entry_id,oc_name).
535
536       That  table contains any number of objectclass names that corresponding
537       entries will possess, in addition to that mentioned  in  mapping.   The
538       SQL  backend automatically adds attribute mapping for the "objectclass"
539       attribute to each objectclass mapping that loads values from  this  ta‐
540       ble.   So, you may, for instance, have a mapping for inetOrgPerson, and
541       use it for queries for "person" objectclass...
542
543       Referrals used to be implemented in a loose manner by adding  an  extra
544       table  that  allowed  any entry to host a "ref" attribute, along with a
545       "referral" extra objectClass in table  ldap_entry_objclasses.   In  the
546       current  implementation,  referrals are treated like any other user-de‐
547       fined schema, since "referral" is a structural objectclass.   The  sug‐
548       gested  practice  is  to define a "referral" entry in ldap_oc_mappings,
549       holding a naming attribute, e.g. "ou" or "cn", a "ref" attribute,  con‐
550       taining  the  url;  in  case multiple referrals per entry are needed, a
551       separate table for urls can be created, where urls are  mapped  to  the
552       respective  entries.   The use of the naming attribute usually requires
553       to add an "extensibleObject" value to ldap_entry_objclasses.
554
555

CAVEATS

557       As previously stated, this backend should not be considered a  replace‐
558       ment  of  other data storage backends, but rather a gateway to existing
559       RDBMS storages that need to be published in LDAP form.
560
561       The hasSubordintes operational attribute  is  honored  by  back-sql  in
562       search  results and in compare operations; it is partially honored also
563       in filtering.  Owing to design limitations, a (brain-dead?)  filter  of
564       the  form (!(hasSubordinates=TRUE)) will give no results instead of re‐
565       turning all the leaf entries, because it actually expands into ...  AND
566       NOT  (1=1).  If you need to find all the leaf entries, please use (has‐
567       Subordinates=FALSE) instead.
568
569       A directoryString value of the  form  "__First___Last_"  (where  under‐
570       scores  mean  spaces,  ASCII  0x20  char) corresponds to its prettified
571       counterpart "First_Last"; this is not currently honored by back-sql  if
572       non-prettified  data  is written via RDBMS; when non-prettified data is
573       written through back-sql, the prettified values are actually  used  in‐
574       stead.
575
576

BUGS

578       When  the  ldap_entry_objclasses table is empty, filters on the object‐
579       Class attribute erroneously result in no candidates.  A workaround con‐
580       sists  in  adding at least one row to that table, no matter if valid or
581       not.
582
583

PROXY CACHE OVERLAY

585       The  proxy  cache  overlay  allows  caching  of  LDAP  search  requests
586       (queries) in a local database.  See slapo-pcache(5) for details.
587

EXAMPLES

589       There  are  example SQL modules in the slapd/back-sql/rdbms_depend/ di‐
590       rectory in the OpenLDAP source tree.
591

ACCESS CONTROL

593       The sql  backend  honors  access  control  semantics  as  indicated  in
594       slapd.access(5)  (including  the disclose access privilege when enabled
595       at compile time).
596

FILES

598       /etc/openldap/slapd.conf
599              default slapd configuration file
600

SEE ALSO

602       slapd.conf(5), slapd(8).
603
604
605
606OpenLDAP                          2021/06/03                      SLAPD-SQL(5)
Impressum