Training courses

Kernel and Embedded Linux

Bootlin training courses

Embedded Linux, kernel,
Yocto Project, Buildroot, real-time,
graphics, boot time, debugging...

Bootlin logo

Elixir Cross Referencer

    1
    2
    3
    4
    5
    6
    7
    8
    9
   10
   11
   12
   13
   14
   15
   16
   17
   18
   19
   20
   21
   22
   23
   24
   25
   26
   27
   28
   29
   30
   31
   32
   33
   34
   35
   36
   37
   38
   39
   40
   41
   42
   43
   44
   45
   46
   47
   48
   49
   50
   51
   52
   53
   54
   55
   56
   57
   58
   59
   60
   61
   62
   63
   64
   65
   66
   67
   68
   69
   70
   71
   72
   73
   74
   75
   76
   77
   78
   79
   80
   81
   82
   83
   84
   85
   86
   87
   88
   89
   90
   91
   92
   93
   94
   95
   96
   97
   98
   99
  100
  101
  102
  103
  104
  105
  106
  107
  108
  109
  110
  111
  112
  113
  114
  115
  116
  117
  118
  119
  120
  121
  122
  123
  124
  125
  126
  127
  128
  129
  130
  131
  132
  133
  134
  135
  136
  137
  138
  139
  140
  141
  142
  143
  144
  145
  146
  147
  148
  149
  150
  151
  152
  153
  154
  155
  156
  157
  158
  159
  160
  161
  162
  163
  164
  165
  166
  167
  168
  169
  170
  171
  172
  173
  174
  175
  176
  177
  178
  179
  180
  181
  182
  183
  184
  185
  186
  187
  188
  189
  190
  191
  192
  193
  194
  195
  196
  197
  198
  199
  200
  201
  202
  203
  204
  205
  206
  207
  208
  209
  210
  211
  212
  213
  214
  215
  216
  217
  218
  219
  220
  221
  222
  223
  224
  225
  226
  227
  228
  229
  230
  231
  232
  233
  234
  235
  236
  237
  238
  239
  240
  241
  242
  243
  244
  245
  246
  247
  248
  249
  250
  251
  252
  253
  254
  255
  256
  257
  258
  259
  260
  261
  262
  263
  264
  265
  266
  267
  268
  269
  270
  271
  272
  273
  274
  275
  276
  277
  278
  279
  280
  281
  282
  283
  284
  285
  286
  287
  288
  289
  290
  291
  292
  293
  294
  295
  296
  297
  298
  299
  300
  301
  302
  303
  304
  305
  306
  307
  308
  309
  310
  311
  312
  313
  314
  315
  316
  317
  318
  319
  320
  321
  322
  323
  324
  325
  326
  327
  328
  329
  330
  331
  332
  333
  334
  335
  336
  337
  338
  339
  340
  341
  342
  343
  344
  345
  346
  347
  348
  349
  350
  351
  352
  353
  354
  355
  356
  357
  358
  359
  360
  361
  362
  363
  364
  365
  366
  367
  368
  369
  370
  371
  372
  373
  374
  375
  376
  377
  378
  379
  380
  381
  382
  383
  384
  385
  386
  387
  388
  389
  390
  391
  392
  393
  394
  395
  396
  397
  398
  399
  400
  401
  402
  403
  404
  405
  406
  407
  408
  409
  410
  411
  412
  413
  414
  415
  416
  417
  418
  419
  420
  421
  422
  423
  424
  425
  426
  427
  428
  429
  430
  431
  432
  433
  434
  435
  436
  437
  438
  439
  440
  441
  442
  443
  444
  445
  446
  447
  448
  449
  450
  451
  452
  453
  454
  455
  456
  457
  458
  459
  460
  461
  462
  463
  464
  465
  466
  467
  468
  469
  470
  471
  472
  473
  474
  475
  476
  477
  478
  479
  480
  481
  482
  483
  484
  485
  486
  487
  488
  489
  490
  491
  492
  493
  494
  495
  496
  497
  498
  499
  500
  501
  502
  503
  504
  505
  506
  507
  508
  509
  510
  511
  512
  513
  514
  515
  516
  517
  518
  519
  520
  521
  522
  523
  524
  525
  526
  527
  528
  529
  530
  531
  532
  533
  534
  535
  536
  537
  538
  539
  540
  541
  542
  543
  544
  545
  546
  547
  548
  549
  550
  551
  552
  553
  554
  555
  556
  557
  558
  559
  560
  561
  562
  563
  564
  565
  566
  567
  568
  569
  570
  571
  572
  573
  574
  575
  576
  577
  578
  579
  580
  581
  582
  583
  584
  585
  586
  587
  588
  589
  590
  591
  592
  593
  594
  595
  596
  597
  598
  599
  600
  601
  602
  603
  604
  605
  606
  607
  608
  609
  610
  611
  612
  613
  614
  615
  616
  617
  618
  619
  620
  621
  622
  623
  624
  625
  626
  627
  628
  629
  630
  631
  632
  633
  634
  635
  636
  637
  638
  639
  640
  641
  642
  643
  644
  645
  646
  647
  648
  649
  650
  651
  652
  653
  654
  655
  656
  657
  658
  659
  660
  661
  662
  663
  664
  665
  666
  667
  668
  669
  670
  671
  672
  673
  674
  675
  676
  677
  678
  679
  680
  681
  682
  683
  684
  685
  686
  687
  688
  689
  690
  691
  692
  693
  694
  695
  696
  697
  698
  699
  700
  701
  702
  703
  704
  705
  706
  707
  708
  709
  710
  711
  712
  713
  714
  715
  716
  717
  718
  719
  720
  721
  722
  723
  724
  725
  726
  727
  728
  729
  730
  731
  732
  733
  734
  735
  736
  737
  738
  739
  740
  741
  742
  743
  744
  745
  746
  747
  748
  749
  750
  751
  752
  753
  754
  755
  756
  757
  758
  759
  760
  761
  762
  763
  764
  765
  766
  767
  768
  769
  770
  771
  772
  773
  774
  775
  776
  777
  778
  779
  780
  781
  782
  783
  784
  785
  786
  787
  788
  789
  790
  791
  792
  793
  794
  795
  796
  797
  798
  799
  800
  801
  802
  803
  804
  805
  806
  807
  808
  809
  810
  811
  812
  813
  814
  815
  816
  817
  818
  819
  820
  821
  822
  823
  824
  825
  826
  827
  828
  829
  830
  831
  832
  833
  834
  835
  836
  837
  838
  839
  840
  841
  842
  843
  844
  845
  846
  847
  848
  849
  850
  851
  852
  853
  854
  855
  856
  857
  858
  859
  860
  861
  862
  863
  864
  865
  866
  867
  868
  869
  870
  871
  872
  873
  874
  875
  876
  877
  878
  879
  880
  881
  882
  883
  884
  885
  886
  887
  888
  889
  890
  891
  892
  893
  894
  895
  896
  897
  898
  899
  900
  901
  902
  903
  904
  905
  906
  907
  908
  909
  910
  911
  912
  913
  914
  915
  916
  917
  918
  919
  920
  921
  922
  923
  924
  925
  926
  927
  928
  929
  930
  931
  932
  933
  934
  935
  936
  937
  938
  939
  940
  941
  942
  943
  944
  945
  946
  947
  948
  949
  950
  951
  952
  953
  954
  955
  956
  957
  958
  959
  960
  961
  962
  963
  964
  965
  966
  967
  968
  969
  970
  971
  972
  973
  974
  975
  976
  977
  978
  979
  980
  981
  982
  983
  984
  985
  986
  987
  988
  989
  990
  991
  992
  993
  994
  995
  996
  997
  998
  999
 1000
 1001
 1002
 1003
 1004
 1005
 1006
 1007
 1008
 1009
 1010
 1011
 1012
 1013
 1014
 1015
 1016
 1017
 1018
 1019
 1020
 1021
 1022
 1023
 1024
 1025
 1026
 1027
 1028
 1029
 1030
 1031
 1032
 1033
 1034
 1035
 1036
 1037
 1038
 1039
 1040
 1041
 1042
 1043
 1044
 1045
 1046
 1047
 1048
 1049
 1050
 1051
 1052
 1053
 1054
 1055
 1056
 1057
 1058
 1059
 1060
 1061
 1062
 1063
 1064
 1065
 1066
 1067
 1068
 1069
 1070
 1071
 1072
 1073
 1074
 1075
 1076
 1077
 1078
 1079
 1080
 1081
 1082
 1083
 1084
 1085
 1086
 1087
 1088
 1089
 1090
 1091
 1092
 1093
 1094
 1095
 1096
 1097
 1098
 1099
 1100
 1101
 1102
 1103
 1104
 1105
 1106
 1107
 1108
 1109
 1110
 1111
 1112
 1113
 1114
 1115
 1116
 1117
 1118
 1119
 1120
 1121
 1122
 1123
 1124
 1125
 1126
 1127
 1128
 1129
 1130
 1131
 1132
 1133
 1134
 1135
 1136
 1137
 1138
 1139
 1140
 1141
 1142
 1143
 1144
 1145
 1146
 1147
 1148
 1149
 1150
 1151
 1152
 1153
 1154
 1155
 1156
 1157
 1158
 1159
 1160
 1161
 1162
 1163
 1164
 1165
 1166
 1167
 1168
 1169
 1170
 1171
 1172
 1173
 1174
 1175
 1176
 1177
 1178
 1179
 1180
 1181
 1182
 1183
 1184
 1185
 1186
 1187
 1188
 1189
 1190
 1191
 1192
 1193
 1194
 1195
 1196
 1197
 1198
 1199
 1200
 1201
 1202
 1203
 1204
 1205
 1206
 1207
 1208
 1209
 1210
 1211
 1212
 1213
 1214
 1215
 1216
 1217
 1218
 1219
 1220
 1221
 1222
 1223
 1224
 1225
 1226
 1227
 1228
 1229
 1230
 1231
 1232
 1233
 1234
 1235
 1236
 1237
 1238
 1239
 1240
 1241
 1242
 1243
 1244
 1245
 1246
 1247
 1248
 1249
 1250
 1251
 1252
 1253
 1254
 1255
 1256
 1257
 1258
 1259
 1260
 1261
 1262
 1263
 1264
 1265
 1266
 1267
 1268
 1269
 1270
 1271
 1272
 1273
 1274
 1275
 1276
 1277
 1278
 1279
 1280
 1281
 1282
 1283
 1284
 1285
 1286
 1287
 1288
 1289
 1290
 1291
 1292
 1293
 1294
 1295
 1296
 1297
 1298
 1299
 1300
 1301
 1302
 1303
 1304
 1305
 1306
 1307
 1308
 1309
 1310
 1311
 1312
 1313
 1314
 1315
 1316
 1317
 1318
 1319
 1320
 1321
 1322
 1323
 1324
 1325
 1326
 1327
 1328
 1329
 1330
 1331
 1332
 1333
 1334
 1335
 1336
 1337
 1338
 1339
 1340
 1341
 1342
 1343
 1344
 1345
 1346
 1347
 1348
 1349
 1350
 1351
 1352
 1353
 1354
 1355
 1356
 1357
 1358
 1359
 1360
 1361
 1362
 1363
 1364
 1365
 1366
 1367
 1368
 1369
 1370
 1371
 1372
 1373
 1374
 1375
 1376
 1377
 1378
 1379
 1380
 1381
 1382
 1383
 1384
 1385
 1386
 1387
 1388
 1389
 1390
 1391
 1392
 1393
 1394
 1395
 1396
 1397
 1398
 1399
 1400
 1401
 1402
 1403
 1404
 1405
 1406
 1407
 1408
 1409
 1410
 1411
 1412
 1413
 1414
 1415
 1416
 1417
 1418
 1419
 1420
 1421
 1422
 1423
 1424
 1425
 1426
 1427
 1428
 1429
 1430
 1431
 1432
 1433
 1434
 1435
 1436
 1437
 1438
 1439
 1440
 1441
 1442
 1443
 1444
 1445
 1446
 1447
 1448
 1449
 1450
 1451
 1452
 1453
 1454
 1455
 1456
 1457
 1458
 1459
 1460
 1461
 1462
 1463
 1464
 1465
 1466
 1467
 1468
 1469
 1470
 1471
 1472
 1473
 1474
 1475
 1476
 1477
 1478
 1479
 1480
 1481
 1482
 1483
 1484
 1485
 1486
 1487
 1488
 1489
 1490
 1491
 1492
 1493
 1494
 1495
 1496
 1497
 1498
 1499
 1500
 1501
 1502
 1503
 1504
 1505
 1506
 1507
 1508
 1509
 1510
 1511
 1512
 1513
 1514
 1515
 1516
 1517
 1518
 1519
 1520
 1521
 1522
 1523
 1524
 1525
 1526
 1527
 1528
 1529
 1530
 1531
 1532
 1533
 1534
 1535
 1536
 1537
 1538
 1539
 1540
 1541
 1542
 1543
 1544
 1545
 1546
 1547
 1548
 1549
 1550
 1551
 1552
 1553
 1554
 1555
 1556
 1557
 1558
 1559
 1560
 1561
 1562
 1563
 1564
 1565
 1566
 1567
 1568
 1569
 1570
 1571
 1572
 1573
 1574
 1575
 1576
 1577
 1578
 1579
 1580
 1581
 1582
 1583
 1584
 1585
 1586
 1587
 1588
 1589
 1590
 1591
 1592
 1593
 1594
 1595
 1596
 1597
 1598
 1599
 1600
 1601
 1602
 1603
 1604
 1605
 1606
 1607
 1608
 1609
 1610
 1611
 1612
 1613
 1614
 1615
 1616
 1617
 1618
 1619
 1620
 1621
 1622
 1623
 1624
 1625
 1626
 1627
 1628
 1629
 1630
 1631
 1632
 1633
 1634
 1635
 1636
 1637
 1638
 1639
 1640
 1641
 1642
 1643
 1644
 1645
 1646
 1647
 1648
 1649
 1650
 1651
 1652
 1653
 1654
 1655
 1656
 1657
 1658
 1659
 1660
 1661
 1662
 1663
 1664
 1665
 1666
 1667
 1668
 1669
 1670
 1671
 1672
 1673
 1674
 1675
 1676
 1677
 1678
 1679
 1680
 1681
 1682
 1683
 1684
 1685
 1686
 1687
 1688
 1689
 1690
 1691
 1692
 1693
 1694
 1695
 1696
 1697
 1698
 1699
 1700
 1701
 1702
 1703
 1704
 1705
 1706
 1707
 1708
 1709
 1710
 1711
 1712
 1713
 1714
 1715
 1716
 1717
 1718
 1719
 1720
 1721
 1722
 1723
 1724
 1725
 1726
 1727
 1728
 1729
 1730
 1731
 1732
 1733
 1734
 1735
 1736
 1737
 1738
 1739
 1740
 1741
 1742
 1743
 1744
 1745
 1746
 1747
 1748
 1749
 1750
 1751
 1752
 1753
 1754
 1755
 1756
 1757
 1758
 1759
 1760
 1761
 1762
 1763
 1764
 1765
 1766
 1767
 1768
 1769
 1770
 1771
 1772
 1773
 1774
 1775
 1776
 1777
 1778
 1779
 1780
 1781
 1782
 1783
 1784
 1785
 1786
 1787
 1788
 1789
 1790
 1791
 1792
 1793
 1794
 1795
 1796
 1797
 1798
 1799
 1800
 1801
 1802
 1803
 1804
 1805
 1806
 1807
 1808
 1809
 1810
 1811
 1812
 1813
 1814
 1815
 1816
 1817
 1818
 1819
 1820
 1821
 1822
 1823
 1824
 1825
 1826
 1827
 1828
 1829
 1830
 1831
 1832
 1833
 1834
 1835
 1836
 1837
 1838
 1839
 1840
 1841
 1842
 1843
 1844
 1845
 1846
 1847
 1848
 1849
 1850
 1851
 1852
 1853
 1854
 1855
 1856
 1857
 1858
 1859
 1860
 1861
 1862
 1863
 1864
 1865
 1866
 1867
 1868
 1869
 1870
 1871
 1872
 1873
 1874
 1875
 1876
 1877
 1878
 1879
 1880
 1881
 1882
 1883
 1884
 1885
 1886
 1887
 1888
 1889
 1890
 1891
 1892
 1893
 1894
 1895
 1896
 1897
 1898
 1899
 1900
 1901
 1902
 1903
 1904
 1905
 1906
 1907
 1908
 1909
 1910
 1911
 1912
 1913
 1914
 1915
 1916
 1917
 1918
 1919
 1920
 1921
 1922
 1923
 1924
 1925
 1926
 1927
 1928
 1929
 1930
 1931
 1932
 1933
 1934
 1935
 1936
 1937
 1938
 1939
 1940
 1941
 1942
 1943
 1944
 1945
 1946
 1947
 1948
 1949
 1950
 1951
 1952
 1953
 1954
 1955
 1956
 1957
 1958
 1959
 1960
 1961
 1962
 1963
 1964
 1965
 1966
 1967
 1968
 1969
 1970
 1971
 1972
 1973
 1974
 1975
 1976
 1977
 1978
 1979
 1980
 1981
 1982
 1983
 1984
 1985
 1986
 1987
 1988
 1989
 1990
 1991
 1992
 1993
 1994
 1995
 1996
 1997
 1998
 1999
 2000
 2001
 2002
 2003
 2004
 2005
 2006
 2007
 2008
 2009
 2010
 2011
 2012
 2013
 2014
 2015
 2016
 2017
 2018
 2019
 2020
 2021
 2022
 2023
 2024
 2025
 2026
 2027
 2028
 2029
 2030
 2031
 2032
 2033
 2034
 2035
 2036
 2037
 2038
 2039
 2040
 2041
 2042
 2043
 2044
 2045
 2046
 2047
 2048
 2049
 2050
 2051
 2052
 2053
 2054
 2055
 2056
 2057
 2058
 2059
 2060
 2061
 2062
 2063
 2064
 2065
 2066
 2067
 2068
 2069
 2070
 2071
 2072
 2073
 2074
 2075
 2076
 2077
 2078
 2079
 2080
 2081
 2082
 2083
 2084
 2085
 2086
 2087
 2088
 2089
 2090
 2091
 2092
 2093
 2094
 2095
 2096
 2097
 2098
 2099
 2100
 2101
 2102
 2103
 2104
 2105
 2106
 2107
 2108
 2109
 2110
 2111
 2112
 2113
 2114
 2115
 2116
 2117
 2118
 2119
 2120
 2121
 2122
 2123
 2124
 2125
 2126
 2127
 2128
 2129
 2130
 2131
 2132
 2133
 2134
 2135
 2136
 2137
 2138
 2139
 2140
 2141
 2142
 2143
 2144
 2145
 2146
 2147
 2148
 2149
 2150
 2151
 2152
 2153
 2154
 2155
 2156
 2157
 2158
 2159
 2160
 2161
 2162
 2163
 2164
 2165
 2166
 2167
 2168
 2169
 2170
 2171
 2172
 2173
 2174
 2175
 2176
 2177
 2178
 2179
 2180
 2181
 2182
 2183
 2184
 2185
 2186
 2187
 2188
 2189
 2190
 2191
 2192
 2193
 2194
 2195
 2196
 2197
 2198
 2199
 2200
 2201
 2202
 2203
 2204
 2205
 2206
 2207
 2208
 2209
 2210
 2211
 2212
 2213
 2214
 2215
 2216
 2217
 2218
 2219
 2220
 2221
 2222
 2223
 2224
 2225
 2226
 2227
 2228
 2229
 2230
 2231
 2232
 2233
 2234
 2235
 2236
 2237
 2238
 2239
 2240
 2241
 2242
 2243
 2244
 2245
 2246
 2247
 2248
 2249
 2250
 2251
 2252
 2253
 2254
 2255
 2256
 2257
 2258
 2259
 2260
 2261
 2262
 2263
 2264
 2265
 2266
 2267
 2268
 2269
 2270
 2271
 2272
 2273
 2274
 2275
 2276
 2277
 2278
 2279
 2280
 2281
 2282
 2283
 2284
 2285
 2286
 2287
 2288
 2289
 2290
 2291
 2292
 2293
 2294
 2295
 2296
 2297
 2298
 2299
 2300
 2301
 2302
 2303
 2304
 2305
 2306
 2307
 2308
 2309
 2310
 2311
 2312
 2313
 2314
 2315
 2316
 2317
 2318
 2319
 2320
 2321
 2322
 2323
 2324
 2325
 2326
 2327
 2328
 2329
 2330
 2331
 2332
 2333
 2334
 2335
 2336
 2337
 2338
 2339
 2340
 2341
 2342
 2343
 2344
 2345
 2346
 2347
 2348
 2349
 2350
 2351
 2352
 2353
 2354
 2355
 2356
 2357
 2358
 2359
 2360
 2361
 2362
 2363
 2364
 2365
 2366
 2367
 2368
 2369
 2370
 2371
 2372
 2373
 2374
 2375
 2376
 2377
 2378
 2379
 2380
 2381
 2382
 2383
 2384
 2385
 2386
 2387
 2388
 2389
 2390
 2391
 2392
 2393
 2394
 2395
 2396
 2397
 2398
 2399
 2400
 2401
 2402
 2403
 2404
 2405
 2406
 2407
 2408
 2409
 2410
 2411
 2412
 2413
 2414
 2415
 2416
 2417
 2418
 2419
 2420
 2421
 2422
 2423
 2424
 2425
 2426
 2427
 2428
 2429
 2430
 2431
 2432
 2433
 2434
 2435
 2436
 2437
 2438
 2439
 2440
 2441
 2442
 2443
 2444
 2445
 2446
 2447
 2448
 2449
 2450
 2451
 2452
 2453
 2454
 2455
 2456
 2457
 2458
 2459
 2460
 2461
 2462
 2463
 2464
 2465
 2466
 2467
 2468
 2469
 2470
 2471
 2472
 2473
 2474
 2475
 2476
 2477
 2478
 2479
 2480
 2481
 2482
 2483
 2484
 2485
 2486
 2487
 2488
 2489
 2490
 2491
 2492
 2493
 2494
 2495
 2496
 2497
 2498
 2499
 2500
 2501
 2502
 2503
 2504
 2505
 2506
 2507
 2508
 2509
 2510
 2511
 2512
 2513
 2514
 2515
 2516
 2517
 2518
 2519
 2520
 2521
 2522
 2523
 2524
 2525
 2526
 2527
 2528
 2529
 2530
 2531
 2532
 2533
 2534
 2535
 2536
 2537
 2538
 2539
 2540
 2541
 2542
 2543
 2544
 2545
 2546
 2547
 2548
 2549
 2550
 2551
 2552
 2553
 2554
 2555
 2556
 2557
 2558
 2559
 2560
 2561
 2562
 2563
 2564
 2565
 2566
 2567
 2568
 2569
 2570
 2571
 2572
 2573
 2574
 2575
 2576
 2577
 2578
 2579
 2580
 2581
 2582
 2583
 2584
 2585
 2586
 2587
 2588
 2589
 2590
 2591
 2592
 2593
 2594
 2595
 2596
 2597
 2598
 2599
 2600
 2601
 2602
 2603
 2604
 2605
 2606
 2607
 2608
 2609
 2610
 2611
 2612
 2613
 2614
 2615
 2616
 2617
 2618
 2619
 2620
 2621
 2622
 2623
 2624
 2625
 2626
 2627
 2628
 2629
 2630
 2631
 2632
 2633
 2634
 2635
 2636
 2637
 2638
 2639
 2640
 2641
 2642
 2643
 2644
 2645
 2646
 2647
 2648
 2649
 2650
 2651
 2652
 2653
 2654
 2655
 2656
 2657
 2658
 2659
 2660
 2661
 2662
 2663
 2664
 2665
 2666
 2667
 2668
 2669
 2670
 2671
 2672
 2673
 2674
 2675
 2676
 2677
 2678
 2679
 2680
 2681
 2682
 2683
 2684
 2685
 2686
 2687
 2688
 2689
 2690
 2691
 2692
 2693
 2694
 2695
 2696
 2697
 2698
 2699
 2700
 2701
 2702
 2703
 2704
 2705
 2706
 2707
 2708
 2709
 2710
 2711
 2712
 2713
 2714
 2715
 2716
 2717
 2718
 2719
 2720
 2721
 2722
 2723
 2724
 2725
 2726
 2727
 2728
 2729
 2730
 2731
 2732
 2733
 2734
 2735
 2736
 2737
 2738
 2739
 2740
 2741
 2742
 2743
 2744
 2745
 2746
 2747
 2748
 2749
 2750
 2751
 2752
 2753
 2754
 2755
 2756
 2757
 2758
 2759
 2760
 2761
 2762
 2763
 2764
 2765
 2766
 2767
 2768
 2769
 2770
 2771
 2772
 2773
 2774
 2775
 2776
 2777
 2778
 2779
 2780
 2781
 2782
 2783
 2784
 2785
 2786
 2787
 2788
 2789
 2790
 2791
 2792
 2793
 2794
 2795
 2796
 2797
 2798
 2799
 2800
 2801
 2802
 2803
 2804
 2805
 2806
 2807
 2808
 2809
 2810
 2811
 2812
 2813
 2814
 2815
 2816
 2817
 2818
 2819
 2820
 2821
 2822
 2823
 2824
 2825
 2826
 2827
 2828
 2829
 2830
 2831
 2832
 2833
 2834
 2835
 2836
 2837
 2838
 2839
 2840
 2841
 2842
 2843
 2844
 2845
 2846
 2847
 2848
 2849
 2850
 2851
 2852
 2853
 2854
 2855
 2856
 2857
 2858
 2859
 2860
 2861
 2862
 2863
 2864
 2865
 2866
 2867
 2868
 2869
 2870
 2871
 2872
 2873
 2874
 2875
 2876
 2877
 2878
 2879
 2880
 2881
 2882
 2883
 2884
 2885
 2886
 2887
 2888
 2889
 2890
 2891
 2892
 2893
 2894
 2895
 2896
 2897
 2898
 2899
 2900
 2901
 2902
 2903
 2904
 2905
 2906
 2907
 2908
 2909
 2910
 2911
 2912
 2913
 2914
 2915
 2916
 2917
 2918
 2919
 2920
 2921
 2922
 2923
 2924
 2925
 2926
 2927
 2928
 2929
 2930
 2931
 2932
 2933
 2934
 2935
 2936
 2937
 2938
 2939
 2940
 2941
 2942
 2943
 2944
 2945
 2946
 2947
 2948
 2949
 2950
 2951
 2952
 2953
 2954
 2955
 2956
 2957
 2958
 2959
 2960
 2961
 2962
 2963
 2964
 2965
 2966
 2967
 2968
 2969
 2970
 2971
 2972
 2973
 2974
 2975
 2976
 2977
 2978
 2979
 2980
 2981
 2982
 2983
 2984
 2985
 2986
 2987
 2988
 2989
 2990
 2991
 2992
 2993
 2994
 2995
 2996
 2997
 2998
 2999
 3000
 3001
 3002
 3003
 3004
 3005
 3006
 3007
 3008
 3009
 3010
 3011
 3012
 3013
 3014
 3015
 3016
 3017
 3018
 3019
 3020
 3021
 3022
 3023
 3024
 3025
 3026
 3027
 3028
 3029
 3030
 3031
 3032
 3033
 3034
 3035
 3036
 3037
 3038
 3039
 3040
 3041
 3042
 3043
 3044
 3045
 3046
 3047
 3048
 3049
 3050
 3051
 3052
 3053
 3054
 3055
 3056
 3057
 3058
 3059
 3060
 3061
 3062
 3063
 3064
 3065
 3066
 3067
 3068
 3069
 3070
 3071
 3072
 3073
 3074
 3075
 3076
 3077
 3078
 3079
 3080
 3081
 3082
 3083
 3084
 3085
 3086
 3087
 3088
 3089
 3090
 3091
 3092
 3093
 3094
 3095
 3096
 3097
 3098
 3099
 3100
 3101
 3102
 3103
 3104
 3105
 3106
 3107
 3108
 3109
 3110
 3111
 3112
 3113
 3114
 3115
 3116
 3117
 3118
 3119
 3120
 3121
 3122
 3123
 3124
 3125
 3126
 3127
 3128
 3129
 3130
 3131
 3132
 3133
 3134
 3135
 3136
 3137
 3138
 3139
 3140
 3141
 3142
 3143
 3144
 3145
 3146
 3147
 3148
 3149
 3150
 3151
 3152
 3153
 3154
 3155
 3156
 3157
 3158
 3159
 3160
 3161
 3162
 3163
 3164
 3165
 3166
 3167
 3168
 3169
 3170
 3171
 3172
 3173
 3174
 3175
 3176
 3177
 3178
 3179
 3180
 3181
 3182
 3183
 3184
 3185
 3186
 3187
 3188
 3189
 3190
 3191
 3192
 3193
 3194
 3195
 3196
 3197
 3198
 3199
 3200
 3201
 3202
 3203
 3204
 3205
 3206
 3207
 3208
 3209
 3210
 3211
 3212
 3213
 3214
 3215
 3216
 3217
 3218
 3219
 3220
 3221
 3222
 3223
 3224
 3225
 3226
 3227
 3228
 3229
 3230
 3231
 3232
 3233
 3234
 3235
 3236
 3237
 3238
 3239
 3240
 3241
 3242
 3243
 3244
 3245
 3246
 3247
 3248
 3249
 3250
 3251
 3252
 3253
 3254
 3255
 3256
 3257
 3258
 3259
 3260
 3261
 3262
 3263
 3264
 3265
 3266
 3267
 3268
 3269
 3270
 3271
 3272
 3273
 3274
 3275
 3276
 3277
 3278
 3279
 3280
 3281
 3282
 3283
 3284
 3285
 3286
 3287
 3288
 3289
 3290
 3291
 3292
 3293
 3294
 3295
 3296
 3297
 3298
 3299
 3300
 3301
 3302
 3303
 3304
 3305
 3306
 3307
 3308
 3309
 3310
 3311
 3312
 3313
 3314
 3315
 3316
 3317
 3318
 3319
 3320
 3321
 3322
 3323
 3324
 3325
 3326
 3327
 3328
 3329
 3330
 3331
 3332
 3333
 3334
 3335
 3336
 3337
 3338
 3339
 3340
 3341
 3342
 3343
 3344
 3345
 3346
 3347
 3348
 3349
 3350
 3351
 3352
 3353
 3354
 3355
 3356
 3357
 3358
 3359
 3360
 3361
 3362
 3363
 3364
 3365
 3366
 3367
 3368
 3369
 3370
 3371
 3372
 3373
 3374
 3375
 3376
 3377
 3378
 3379
 3380
 3381
 3382
 3383
 3384
 3385
 3386
 3387
 3388
 3389
 3390
 3391
 3392
 3393
 3394
 3395
 3396
 3397
 3398
 3399
 3400
 3401
 3402
 3403
 3404
 3405
 3406
 3407
 3408
 3409
 3410
 3411
 3412
 3413
 3414
 3415
 3416
 3417
 3418
 3419
 3420
 3421
 3422
 3423
 3424
 3425
 3426
 3427
 3428
 3429
 3430
 3431
 3432
 3433
 3434
 3435
 3436
 3437
 3438
 3439
 3440
 3441
 3442
 3443
 3444
 3445
 3446
 3447
 3448
 3449
 3450
 3451
 3452
 3453
 3454
 3455
 3456
 3457
 3458
 3459
 3460
 3461
 3462
 3463
 3464
 3465
 3466
 3467
 3468
 3469
 3470
 3471
 3472
 3473
 3474
 3475
 3476
 3477
 3478
 3479
 3480
 3481
 3482
 3483
 3484
 3485
 3486
 3487
 3488
 3489
 3490
 3491
 3492
 3493
 3494
 3495
 3496
 3497
 3498
 3499
 3500
 3501
 3502
 3503
 3504
 3505
 3506
 3507
 3508
 3509
 3510
 3511
 3512
 3513
 3514
 3515
 3516
 3517
 3518
 3519
 3520
 3521
 3522
 3523
 3524
 3525
 3526
 3527
 3528
 3529
 3530
 3531
 3532
 3533
 3534
 3535
 3536
 3537
 3538
 3539
 3540
 3541
 3542
 3543
 3544
 3545
 3546
 3547
 3548
 3549
 3550
 3551
 3552
 3553
 3554
 3555
 3556
 3557
 3558
 3559
 3560
 3561
 3562
 3563
 3564
 3565
 3566
 3567
 3568
 3569
 3570
 3571
 3572
 3573
 3574
 3575
 3576
 3577
 3578
 3579
 3580
 3581
 3582
 3583
 3584
 3585
 3586
 3587
 3588
 3589
 3590
 3591
 3592
 3593
 3594
 3595
 3596
 3597
 3598
 3599
 3600
 3601
 3602
 3603
 3604
 3605
 3606
 3607
 3608
 3609
 3610
 3611
 3612
 3613
 3614
 3615
 3616
 3617
 3618
 3619
 3620
 3621
 3622
 3623
 3624
 3625
 3626
 3627
 3628
 3629
 3630
 3631
 3632
 3633
 3634
 3635
 3636
 3637
 3638
 3639
 3640
 3641
 3642
 3643
 3644
 3645
 3646
 3647
 3648
 3649
 3650
 3651
 3652
 3653
 3654
 3655
 3656
 3657
 3658
 3659
 3660
 3661
 3662
 3663
 3664
 3665
 3666
 3667
 3668
 3669
 3670
 3671
 3672
 3673
 3674
 3675
 3676
 3677
 3678
 3679
 3680
 3681
 3682
 3683
 3684
 3685
 3686
 3687
 3688
 3689
 3690
 3691
 3692
 3693
 3694
 3695
 3696
 3697
 3698
 3699
 3700
 3701
 3702
 3703
 3704
 3705
 3706
 3707
 3708
 3709
 3710
 3711
 3712
 3713
 3714
 3715
 3716
 3717
 3718
 3719
 3720
 3721
 3722
 3723
 3724
 3725
 3726
 3727
 3728
 3729
 3730
 3731
 3732
 3733
 3734
 3735
 3736
 3737
 3738
 3739
 3740
 3741
 3742
 3743
 3744
 3745
 3746
 3747
 3748
 3749
 3750
 3751
 3752
 3753
 3754
 3755
 3756
 3757
 3758
 3759
 3760
 3761
 3762
 3763
 3764
 3765
 3766
 3767
 3768
 3769
 3770
 3771
 3772
 3773
 3774
 3775
 3776
 3777
 3778
 3779
 3780
 3781
 3782
 3783
 3784
 3785
 3786
 3787
 3788
 3789
 3790
 3791
 3792
 3793
 3794
 3795
 3796
 3797
 3798
 3799
 3800
 3801
 3802
 3803
 3804
 3805
 3806
 3807
 3808
 3809
 3810
 3811
 3812
 3813
 3814
 3815
 3816
 3817
 3818
 3819
 3820
 3821
 3822
 3823
 3824
 3825
 3826
 3827
 3828
 3829
 3830
 3831
 3832
 3833
 3834
 3835
 3836
 3837
 3838
 3839
 3840
 3841
 3842
 3843
 3844
 3845
 3846
 3847
 3848
 3849
 3850
 3851
 3852
 3853
 3854
 3855
 3856
 3857
 3858
 3859
 3860
 3861
 3862
 3863
 3864
 3865
 3866
 3867
 3868
 3869
 3870
 3871
 3872
 3873
 3874
 3875
 3876
 3877
 3878
 3879
 3880
 3881
 3882
 3883
 3884
 3885
 3886
 3887
 3888
 3889
 3890
 3891
 3892
 3893
 3894
 3895
 3896
 3897
 3898
 3899
 3900
 3901
 3902
 3903
 3904
 3905
 3906
 3907
 3908
 3909
 3910
 3911
 3912
 3913
 3914
 3915
 3916
 3917
 3918
 3919
 3920
 3921
 3922
 3923
 3924
 3925
 3926
 3927
 3928
 3929
 3930
 3931
 3932
 3933
 3934
 3935
 3936
 3937
 3938
 3939
 3940
 3941
 3942
 3943
 3944
 3945
 3946
 3947
 3948
 3949
 3950
 3951
 3952
 3953
 3954
 3955
 3956
 3957
 3958
 3959
 3960
 3961
 3962
 3963
 3964
 3965
 3966
 3967
 3968
 3969
 3970
 3971
 3972
 3973
 3974
 3975
 3976
 3977
 3978
 3979
 3980
 3981
 3982
 3983
 3984
 3985
 3986
 3987
 3988
 3989
 3990
 3991
 3992
 3993
 3994
 3995
 3996
 3997
 3998
 3999
 4000
 4001
 4002
 4003
 4004
 4005
 4006
 4007
 4008
 4009
 4010
 4011
 4012
 4013
 4014
 4015
 4016
 4017
 4018
 4019
 4020
 4021
 4022
 4023
 4024
 4025
 4026
 4027
 4028
 4029
 4030
 4031
 4032
 4033
 4034
 4035
 4036
 4037
 4038
 4039
 4040
 4041
 4042
 4043
 4044
 4045
 4046
 4047
 4048
 4049
 4050
 4051
 4052
 4053
 4054
 4055
 4056
 4057
 4058
 4059
 4060
 4061
 4062
 4063
 4064
 4065
 4066
 4067
 4068
 4069
 4070
 4071
 4072
 4073
 4074
 4075
 4076
 4077
 4078
 4079
 4080
 4081
 4082
 4083
 4084
 4085
 4086
 4087
 4088
 4089
 4090
 4091
 4092
 4093
 4094
 4095
 4096
 4097
 4098
 4099
 4100
 4101
 4102
 4103
 4104
 4105
 4106
 4107
 4108
 4109
 4110
 4111
 4112
 4113
 4114
 4115
 4116
 4117
 4118
 4119
 4120
 4121
 4122
 4123
 4124
 4125
 4126
 4127
 4128
 4129
 4130
 4131
 4132
 4133
 4134
 4135
 4136
 4137
 4138
 4139
 4140
 4141
 4142
 4143
 4144
 4145
 4146
 4147
 4148
 4149
 4150
 4151
 4152
 4153
 4154
 4155
 4156
 4157
 4158
 4159
 4160
 4161
 4162
 4163
 4164
 4165
 4166
 4167
 4168
 4169
 4170
 4171
 4172
 4173
 4174
 4175
 4176
 4177
 4178
 4179
 4180
 4181
 4182
 4183
 4184
 4185
 4186
 4187
 4188
 4189
 4190
 4191
 4192
 4193
 4194
 4195
 4196
 4197
 4198
 4199
 4200
 4201
 4202
 4203
 4204
 4205
 4206
 4207
 4208
 4209
 4210
 4211
 4212
 4213
 4214
 4215
 4216
 4217
 4218
 4219
 4220
 4221
 4222
 4223
 4224
 4225
 4226
 4227
 4228
 4229
 4230
 4231
 4232
 4233
 4234
 4235
 4236
 4237
 4238
 4239
 4240
 4241
 4242
 4243
 4244
 4245
 4246
 4247
 4248
 4249
 4250
 4251
 4252
 4253
 4254
 4255
 4256
 4257
 4258
 4259
 4260
 4261
 4262
 4263
 4264
 4265
 4266
 4267
 4268
 4269
 4270
 4271
 4272
 4273
 4274
 4275
 4276
 4277
 4278
 4279
 4280
 4281
 4282
 4283
 4284
 4285
 4286
 4287
 4288
 4289
 4290
 4291
 4292
 4293
 4294
 4295
 4296
 4297
 4298
 4299
 4300
 4301
 4302
 4303
 4304
 4305
 4306
 4307
 4308
 4309
 4310
 4311
 4312
 4313
 4314
 4315
 4316
 4317
 4318
 4319
 4320
 4321
 4322
 4323
 4324
 4325
 4326
 4327
 4328
 4329
 4330
 4331
 4332
 4333
 4334
 4335
 4336
 4337
 4338
 4339
 4340
 4341
 4342
 4343
 4344
 4345
 4346
 4347
 4348
 4349
 4350
 4351
 4352
 4353
 4354
 4355
 4356
 4357
 4358
 4359
 4360
 4361
 4362
 4363
 4364
 4365
 4366
 4367
 4368
 4369
 4370
 4371
 4372
 4373
 4374
 4375
 4376
 4377
 4378
 4379
 4380
 4381
 4382
 4383
 4384
 4385
 4386
 4387
 4388
 4389
 4390
 4391
 4392
 4393
 4394
 4395
 4396
 4397
 4398
 4399
 4400
 4401
 4402
 4403
 4404
 4405
 4406
 4407
 4408
 4409
 4410
 4411
 4412
 4413
 4414
 4415
 4416
 4417
 4418
 4419
 4420
 4421
 4422
 4423
 4424
 4425
 4426
 4427
 4428
 4429
 4430
 4431
 4432
 4433
 4434
 4435
 4436
 4437
 4438
 4439
 4440
 4441
 4442
 4443
 4444
 4445
 4446
 4447
 4448
 4449
 4450
 4451
 4452
 4453
 4454
 4455
 4456
 4457
 4458
 4459
 4460
 4461
 4462
 4463
 4464
 4465
 4466
 4467
 4468
 4469
 4470
 4471
 4472
 4473
 4474
 4475
 4476
 4477
 4478
 4479
 4480
 4481
 4482
 4483
 4484
 4485
 4486
 4487
 4488
 4489
 4490
 4491
 4492
 4493
 4494
 4495
 4496
 4497
 4498
 4499
 4500
 4501
 4502
 4503
 4504
 4505
 4506
 4507
 4508
 4509
 4510
 4511
 4512
 4513
 4514
 4515
 4516
 4517
 4518
 4519
 4520
 4521
 4522
 4523
 4524
 4525
 4526
 4527
 4528
 4529
 4530
 4531
 4532
 4533
 4534
 4535
 4536
 4537
 4538
 4539
 4540
 4541
 4542
 4543
 4544
 4545
 4546
 4547
 4548
 4549
 4550
 4551
 4552
 4553
 4554
 4555
 4556
 4557
 4558
 4559
 4560
 4561
 4562
 4563
 4564
 4565
 4566
 4567
 4568
 4569
 4570
 4571
 4572
 4573
 4574
 4575
 4576
 4577
 4578
 4579
 4580
 4581
 4582
 4583
 4584
 4585
 4586
 4587
 4588
 4589
 4590
 4591
 4592
 4593
 4594
 4595
 4596
 4597
 4598
 4599
 4600
 4601
 4602
 4603
 4604
 4605
 4606
 4607
 4608
 4609
 4610
 4611
 4612
 4613
 4614
 4615
 4616
 4617
 4618
 4619
 4620
 4621
 4622
 4623
 4624
 4625
 4626
 4627
 4628
 4629
 4630
 4631
 4632
 4633
 4634
 4635
 4636
 4637
 4638
 4639
 4640
 4641
 4642
 4643
 4644
 4645
 4646
 4647
 4648
 4649
 4650
 4651
 4652
 4653
 4654
 4655
 4656
 4657
 4658
 4659
 4660
 4661
 4662
 4663
 4664
 4665
 4666
 4667
 4668
 4669
 4670
 4671
 4672
 4673
 4674
 4675
 4676
 4677
 4678
 4679
 4680
 4681
 4682
 4683
 4684
 4685
 4686
 4687
 4688
 4689
 4690
 4691
 4692
 4693
 4694
 4695
 4696
 4697
 4698
 4699
 4700
 4701
 4702
 4703
 4704
 4705
 4706
 4707
 4708
 4709
 4710
 4711
 4712
 4713
 4714
 4715
 4716
 4717
 4718
 4719
 4720
 4721
 4722
 4723
 4724
 4725
 4726
 4727
 4728
 4729
 4730
 4731
 4732
 4733
 4734
 4735
 4736
 4737
 4738
 4739
 4740
 4741
 4742
 4743
 4744
 4745
 4746
 4747
 4748
 4749
 4750
 4751
 4752
 4753
 4754
 4755
 4756
 4757
 4758
 4759
 4760
 4761
 4762
 4763
 4764
 4765
 4766
 4767
 4768
 4769
 4770
 4771
 4772
 4773
 4774
 4775
 4776
 4777
 4778
 4779
 4780
 4781
 4782
 4783
 4784
 4785
 4786
 4787
 4788
 4789
 4790
 4791
 4792
 4793
 4794
 4795
 4796
 4797
 4798
 4799
 4800
 4801
 4802
 4803
 4804
 4805
 4806
 4807
 4808
 4809
 4810
 4811
 4812
 4813
 4814
 4815
 4816
 4817
 4818
 4819
 4820
 4821
 4822
 4823
 4824
 4825
 4826
 4827
 4828
 4829
 4830
 4831
 4832
 4833
 4834
 4835
 4836
 4837
 4838
 4839
 4840
 4841
 4842
 4843
 4844
 4845
 4846
 4847
 4848
 4849
 4850
 4851
 4852
 4853
 4854
 4855
 4856
 4857
 4858
 4859
 4860
 4861
 4862
 4863
 4864
 4865
 4866
 4867
 4868
 4869
 4870
 4871
 4872
 4873
 4874
 4875
 4876
 4877
 4878
 4879
 4880
 4881
 4882
 4883
 4884
 4885
 4886
 4887
 4888
 4889
 4890
 4891
 4892
 4893
 4894
 4895
 4896
 4897
 4898
 4899
 4900
 4901
 4902
 4903
 4904
 4905
 4906
 4907
 4908
 4909
 4910
 4911
 4912
 4913
 4914
 4915
 4916
 4917
 4918
 4919
 4920
 4921
 4922
 4923
 4924
 4925
 4926
 4927
 4928
 4929
 4930
 4931
 4932
 4933
 4934
 4935
 4936
 4937
 4938
 4939
 4940
 4941
 4942
 4943
 4944
 4945
 4946
 4947
 4948
 4949
 4950
 4951
 4952
 4953
 4954
 4955
 4956
 4957
 4958
 4959
 4960
 4961
 4962
 4963
 4964
 4965
 4966
 4967
 4968
 4969
 4970
 4971
 4972
 4973
 4974
 4975
 4976
 4977
 4978
 4979
 4980
 4981
 4982
 4983
 4984
 4985
 4986
 4987
 4988
 4989
 4990
 4991
 4992
 4993
 4994
 4995
 4996
 4997
 4998
 4999
 5000
 5001
 5002
 5003
 5004
 5005
 5006
 5007
 5008
 5009
 5010
 5011
 5012
 5013
 5014
 5015
 5016
 5017
 5018
 5019
 5020
 5021
 5022
 5023
 5024
 5025
 5026
 5027
 5028
 5029
 5030
 5031
 5032
 5033
 5034
 5035
 5036
 5037
 5038
 5039
 5040
 5041
 5042
 5043
 5044
 5045
 5046
 5047
 5048
 5049
 5050
 5051
 5052
 5053
 5054
 5055
 5056
 5057
 5058
 5059
 5060
 5061
 5062
 5063
 5064
 5065
 5066
 5067
 5068
 5069
 5070
 5071
 5072
 5073
 5074
 5075
 5076
 5077
 5078
 5079
 5080
 5081
 5082
 5083
 5084
 5085
 5086
 5087
 5088
 5089
 5090
 5091
 5092
 5093
 5094
 5095
 5096
 5097
 5098
 5099
 5100
 5101
 5102
 5103
 5104
 5105
 5106
 5107
 5108
 5109
 5110
 5111
 5112
 5113
 5114
 5115
 5116
 5117
 5118
 5119
 5120
 5121
 5122
 5123
 5124
 5125
 5126
 5127
 5128
 5129
 5130
 5131
 5132
 5133
 5134
 5135
 5136
 5137
 5138
 5139
 5140
 5141
 5142
 5143
 5144
 5145
 5146
 5147
 5148
 5149
 5150
 5151
 5152
 5153
 5154
 5155
 5156
 5157
 5158
 5159
 5160
 5161
 5162
 5163
 5164
 5165
 5166
 5167
 5168
 5169
 5170
 5171
 5172
 5173
 5174
 5175
 5176
 5177
 5178
 5179
 5180
 5181
 5182
 5183
 5184
 5185
 5186
 5187
 5188
 5189
 5190
 5191
 5192
 5193
 5194
 5195
 5196
 5197
 5198
 5199
 5200
 5201
 5202
 5203
 5204
 5205
 5206
 5207
 5208
 5209
 5210
 5211
 5212
 5213
 5214
 5215
 5216
 5217
 5218
 5219
 5220
 5221
 5222
 5223
 5224
 5225
 5226
 5227
 5228
 5229
 5230
 5231
 5232
 5233
 5234
 5235
 5236
 5237
 5238
 5239
 5240
 5241
 5242
 5243
 5244
 5245
 5246
 5247
 5248
 5249
 5250
 5251
 5252
 5253
 5254
 5255
 5256
 5257
 5258
 5259
 5260
 5261
 5262
 5263
 5264
 5265
 5266
 5267
 5268
 5269
 5270
 5271
 5272
 5273
 5274
 5275
 5276
 5277
 5278
 5279
 5280
 5281
 5282
 5283
 5284
 5285
 5286
 5287
 5288
 5289
 5290
 5291
 5292
 5293
 5294
 5295
 5296
 5297
 5298
 5299
 5300
 5301
 5302
 5303
 5304
 5305
 5306
 5307
 5308
 5309
 5310
 5311
 5312
 5313
 5314
 5315
 5316
 5317
 5318
 5319
 5320
 5321
 5322
 5323
 5324
 5325
 5326
 5327
 5328
 5329
 5330
 5331
 5332
 5333
 5334
 5335
 5336
 5337
 5338
 5339
 5340
 5341
 5342
 5343
 5344
 5345
 5346
 5347
 5348
 5349
 5350
 5351
 5352
 5353
 5354
 5355
 5356
 5357
 5358
 5359
 5360
 5361
 5362
 5363
 5364
 5365
 5366
 5367
 5368
 5369
 5370
 5371
 5372
 5373
 5374
 5375
 5376
 5377
 5378
 5379
 5380
 5381
 5382
 5383
 5384
 5385
 5386
 5387
 5388
 5389
 5390
 5391
 5392
 5393
 5394
 5395
 5396
 5397
 5398
 5399
 5400
 5401
 5402
 5403
 5404
 5405
 5406
 5407
 5408
 5409
 5410
 5411
 5412
 5413
 5414
 5415
 5416
 5417
 5418
 5419
 5420
 5421
 5422
 5423
 5424
 5425
 5426
 5427
 5428
 5429
 5430
 5431
 5432
 5433
 5434
 5435
 5436
 5437
 5438
 5439
 5440
 5441
 5442
 5443
 5444
 5445
 5446
 5447
 5448
 5449
 5450
 5451
 5452
 5453
 5454
 5455
 5456
 5457
 5458
 5459
 5460
 5461
 5462
 5463
 5464
 5465
 5466
 5467
 5468
 5469
 5470
 5471
 5472
 5473
 5474
 5475
 5476
 5477
 5478
 5479
 5480
 5481
 5482
 5483
 5484
 5485
 5486
 5487
 5488
 5489
 5490
 5491
 5492
 5493
 5494
 5495
 5496
 5497
 5498
 5499
 5500
 5501
 5502
 5503
 5504
 5505
 5506
 5507
 5508
 5509
 5510
 5511
 5512
 5513
 5514
 5515
 5516
 5517
 5518
 5519
 5520
 5521
 5522
 5523
 5524
 5525
 5526
 5527
 5528
 5529
 5530
 5531
 5532
 5533
 5534
 5535
 5536
 5537
 5538
 5539
 5540
 5541
 5542
 5543
 5544
 5545
 5546
 5547
 5548
 5549
 5550
 5551
 5552
 5553
 5554
 5555
 5556
 5557
 5558
 5559
 5560
 5561
 5562
 5563
 5564
 5565
 5566
 5567
 5568
 5569
 5570
 5571
 5572
 5573
 5574
 5575
 5576
 5577
 5578
 5579
 5580
 5581
 5582
 5583
 5584
 5585
 5586
 5587
 5588
 5589
 5590
 5591
 5592
 5593
 5594
 5595
 5596
 5597
 5598
 5599
 5600
 5601
 5602
 5603
 5604
 5605
 5606
 5607
 5608
 5609
 5610
 5611
 5612
 5613
 5614
 5615
 5616
 5617
 5618
 5619
 5620
 5621
 5622
 5623
 5624
 5625
 5626
 5627
 5628
 5629
 5630
 5631
 5632
 5633
 5634
 5635
 5636
 5637
 5638
 5639
 5640
 5641
 5642
 5643
 5644
 5645
 5646
 5647
 5648
 5649
 5650
 5651
 5652
 5653
 5654
 5655
 5656
 5657
 5658
 5659
 5660
 5661
 5662
 5663
 5664
 5665
 5666
 5667
 5668
 5669
 5670
 5671
 5672
 5673
 5674
 5675
 5676
 5677
 5678
 5679
 5680
 5681
 5682
 5683
 5684
 5685
 5686
 5687
 5688
 5689
 5690
 5691
 5692
 5693
 5694
 5695
 5696
 5697
 5698
 5699
 5700
 5701
 5702
 5703
 5704
 5705
 5706
 5707
 5708
 5709
 5710
 5711
 5712
 5713
 5714
 5715
 5716
 5717
 5718
 5719
 5720
 5721
 5722
 5723
 5724
 5725
 5726
 5727
 5728
 5729
 5730
 5731
 5732
 5733
 5734
 5735
 5736
 5737
 5738
 5739
 5740
 5741
 5742
 5743
 5744
 5745
 5746
 5747
 5748
 5749
 5750
 5751
 5752
 5753
 5754
 5755
 5756
 5757
 5758
 5759
 5760
 5761
 5762
 5763
 5764
 5765
 5766
 5767
 5768
 5769
 5770
 5771
 5772
 5773
 5774
 5775
 5776
 5777
 5778
 5779
 5780
 5781
 5782
 5783
 5784
 5785
 5786
 5787
 5788
 5789
 5790
 5791
 5792
 5793
 5794
 5795
 5796
 5797
 5798
 5799
 5800
 5801
 5802
 5803
 5804
 5805
 5806
 5807
 5808
 5809
 5810
 5811
 5812
 5813
 5814
 5815
 5816
 5817
 5818
 5819
 5820
 5821
 5822
 5823
 5824
 5825
 5826
 5827
 5828
 5829
 5830
 5831
 5832
 5833
 5834
 5835
 5836
 5837
 5838
 5839
 5840
 5841
 5842
 5843
 5844
 5845
 5846
 5847
 5848
 5849
 5850
 5851
 5852
 5853
 5854
 5855
 5856
 5857
 5858
 5859
 5860
 5861
 5862
 5863
 5864
 5865
 5866
 5867
 5868
 5869
 5870
 5871
 5872
 5873
 5874
 5875
 5876
 5877
 5878
 5879
 5880
 5881
 5882
 5883
 5884
 5885
 5886
 5887
 5888
 5889
 5890
 5891
 5892
 5893
 5894
 5895
 5896
 5897
 5898
 5899
 5900
 5901
 5902
 5903
 5904
 5905
 5906
 5907
 5908
 5909
 5910
 5911
 5912
 5913
 5914
 5915
 5916
 5917
 5918
 5919
 5920
 5921
 5922
 5923
 5924
 5925
 5926
 5927
 5928
 5929
 5930
 5931
 5932
 5933
 5934
 5935
 5936
 5937
 5938
 5939
 5940
 5941
 5942
 5943
 5944
 5945
 5946
 5947
 5948
 5949
 5950
 5951
 5952
 5953
 5954
 5955
 5956
 5957
 5958
 5959
 5960
 5961
 5962
 5963
 5964
 5965
 5966
 5967
 5968
 5969
 5970
 5971
 5972
 5973
 5974
 5975
 5976
 5977
 5978
 5979
 5980
 5981
 5982
 5983
 5984
 5985
 5986
 5987
 5988
 5989
 5990
 5991
 5992
 5993
 5994
 5995
 5996
 5997
 5998
 5999
 6000
 6001
 6002
 6003
 6004
 6005
 6006
 6007
 6008
 6009
 6010
 6011
 6012
 6013
 6014
 6015
 6016
 6017
 6018
 6019
 6020
 6021
 6022
 6023
 6024
 6025
 6026
 6027
 6028
 6029
 6030
 6031
 6032
 6033
 6034
 6035
 6036
 6037
 6038
 6039
 6040
 6041
 6042
 6043
 6044
 6045
 6046
 6047
 6048
 6049
 6050
 6051
 6052
 6053
 6054
 6055
 6056
 6057
 6058
 6059
 6060
 6061
 6062
 6063
 6064
 6065
 6066
 6067
 6068
 6069
 6070
 6071
 6072
 6073
 6074
 6075
 6076
 6077
 6078
 6079
 6080
 6081
 6082
 6083
 6084
 6085
 6086
 6087
 6088
 6089
 6090
 6091
 6092
 6093
 6094
 6095
 6096
 6097
 6098
 6099
 6100
 6101
 6102
 6103
 6104
 6105
 6106
 6107
 6108
 6109
 6110
 6111
 6112
 6113
 6114
 6115
 6116
 6117
 6118
 6119
 6120
 6121
 6122
 6123
 6124
 6125
 6126
 6127
 6128
 6129
 6130
 6131
 6132
 6133
 6134
 6135
 6136
 6137
 6138
 6139
 6140
 6141
 6142
 6143
 6144
 6145
 6146
 6147
 6148
 6149
 6150
 6151
 6152
 6153
 6154
 6155
 6156
 6157
 6158
 6159
 6160
 6161
 6162
 6163
 6164
 6165
 6166
 6167
 6168
 6169
 6170
 6171
 6172
 6173
 6174
 6175
 6176
 6177
 6178
 6179
 6180
 6181
 6182
 6183
 6184
 6185
 6186
 6187
 6188
 6189
 6190
 6191
 6192
 6193
 6194
 6195
 6196
 6197
 6198
 6199
 6200
 6201
 6202
 6203
 6204
 6205
 6206
 6207
 6208
 6209
 6210
 6211
 6212
 6213
 6214
 6215
 6216
 6217
 6218
 6219
 6220
 6221
 6222
 6223
 6224
 6225
 6226
 6227
 6228
 6229
 6230
 6231
 6232
 6233
 6234
 6235
 6236
 6237
 6238
 6239
 6240
 6241
 6242
 6243
 6244
 6245
 6246
 6247
 6248
 6249
 6250
 6251
 6252
 6253
 6254
 6255
 6256
 6257
 6258
 6259
 6260
 6261
 6262
 6263
 6264
 6265
 6266
 6267
 6268
 6269
 6270
 6271
 6272
 6273
 6274
 6275
 6276
 6277
 6278
 6279
 6280
 6281
 6282
 6283
 6284
 6285
 6286
 6287
 6288
 6289
 6290
 6291
 6292
 6293
 6294
 6295
 6296
 6297
 6298
 6299
 6300
 6301
 6302
 6303
 6304
 6305
 6306
 6307
 6308
 6309
 6310
 6311
 6312
 6313
 6314
 6315
 6316
 6317
 6318
 6319
 6320
 6321
 6322
 6323
 6324
 6325
 6326
 6327
 6328
 6329
 6330
 6331
 6332
 6333
 6334
 6335
 6336
 6337
 6338
 6339
 6340
 6341
 6342
 6343
 6344
 6345
 6346
 6347
 6348
 6349
 6350
 6351
 6352
 6353
 6354
 6355
 6356
 6357
 6358
 6359
 6360
 6361
 6362
 6363
 6364
 6365
 6366
 6367
 6368
 6369
 6370
 6371
 6372
 6373
 6374
 6375
 6376
 6377
 6378
 6379
 6380
 6381
 6382
 6383
 6384
 6385
 6386
 6387
 6388
 6389
 6390
 6391
 6392
 6393
 6394
 6395
 6396
 6397
 6398
 6399
 6400
 6401
 6402
 6403
 6404
 6405
 6406
 6407
 6408
 6409
 6410
 6411
 6412
 6413
 6414
 6415
 6416
 6417
 6418
 6419
 6420
 6421
 6422
 6423
 6424
 6425
 6426
 6427
 6428
 6429
 6430
 6431
 6432
 6433
 6434
 6435
 6436
 6437
 6438
 6439
 6440
 6441
 6442
 6443
 6444
 6445
 6446
 6447
 6448
 6449
 6450
 6451
 6452
 6453
 6454
 6455
 6456
 6457
 6458
 6459
 6460
 6461
 6462
 6463
 6464
 6465
 6466
 6467
 6468
 6469
 6470
 6471
 6472
 6473
 6474
 6475
 6476
 6477
 6478
 6479
 6480
 6481
 6482
 6483
 6484
 6485
 6486
 6487
 6488
 6489
 6490
 6491
 6492
 6493
 6494
 6495
 6496
 6497
 6498
 6499
 6500
 6501
 6502
 6503
 6504
 6505
 6506
 6507
 6508
 6509
 6510
 6511
 6512
 6513
 6514
 6515
 6516
 6517
 6518
 6519
 6520
 6521
 6522
 6523
 6524
 6525
 6526
 6527
 6528
 6529
 6530
 6531
 6532
 6533
 6534
 6535
 6536
 6537
 6538
 6539
 6540
 6541
 6542
 6543
 6544
 6545
 6546
 6547
 6548
 6549
 6550
 6551
 6552
 6553
 6554
 6555
 6556
 6557
 6558
 6559
 6560
 6561
 6562
 6563
 6564
 6565
 6566
 6567
 6568
 6569
 6570
 6571
 6572
 6573
 6574
 6575
 6576
 6577
 6578
 6579
 6580
 6581
 6582
 6583
 6584
 6585
 6586
 6587
 6588
 6589
 6590
 6591
 6592
 6593
 6594
 6595
 6596
 6597
 6598
 6599
 6600
 6601
 6602
 6603
 6604
 6605
 6606
 6607
 6608
 6609
 6610
 6611
 6612
 6613
 6614
 6615
 6616
 6617
 6618
 6619
 6620
 6621
 6622
 6623
 6624
 6625
 6626
 6627
 6628
 6629
 6630
 6631
 6632
 6633
 6634
 6635
 6636
 6637
 6638
 6639
 6640
 6641
 6642
 6643
 6644
 6645
 6646
 6647
 6648
 6649
 6650
 6651
 6652
 6653
 6654
 6655
 6656
 6657
 6658
 6659
 6660
 6661
 6662
 6663
 6664
 6665
 6666
 6667
 6668
 6669
 6670
 6671
 6672
 6673
 6674
 6675
 6676
 6677
 6678
 6679
 6680
 6681
 6682
 6683
 6684
 6685
 6686
 6687
 6688
 6689
 6690
 6691
 6692
 6693
 6694
 6695
 6696
 6697
 6698
 6699
 6700
 6701
 6702
 6703
 6704
 6705
 6706
 6707
 6708
 6709
 6710
 6711
 6712
 6713
 6714
 6715
 6716
 6717
 6718
 6719
 6720
 6721
 6722
 6723
 6724
 6725
 6726
 6727
 6728
 6729
 6730
 6731
 6732
 6733
 6734
 6735
 6736
 6737
 6738
 6739
 6740
 6741
 6742
 6743
 6744
 6745
 6746
 6747
 6748
 6749
 6750
 6751
 6752
 6753
 6754
 6755
 6756
 6757
 6758
 6759
 6760
 6761
 6762
 6763
 6764
 6765
 6766
 6767
 6768
 6769
 6770
 6771
 6772
 6773
 6774
 6775
 6776
 6777
 6778
 6779
 6780
 6781
 6782
 6783
 6784
 6785
 6786
 6787
 6788
 6789
 6790
 6791
 6792
 6793
 6794
 6795
 6796
 6797
 6798
 6799
 6800
 6801
 6802
 6803
 6804
 6805
 6806
 6807
 6808
 6809
 6810
 6811
 6812
 6813
 6814
 6815
 6816
 6817
 6818
 6819
 6820
 6821
 6822
 6823
 6824
 6825
 6826
 6827
 6828
 6829
 6830
 6831
 6832
 6833
 6834
 6835
 6836
 6837
 6838
 6839
 6840
 6841
 6842
 6843
 6844
 6845
 6846
 6847
 6848
 6849
 6850
 6851
 6852
 6853
 6854
 6855
 6856
 6857
 6858
 6859
 6860
 6861
 6862
 6863
 6864
 6865
 6866
 6867
 6868
 6869
 6870
 6871
 6872
 6873
 6874
 6875
 6876
 6877
 6878
 6879
 6880
 6881
 6882
 6883
 6884
 6885
 6886
 6887
 6888
 6889
 6890
 6891
 6892
 6893
 6894
 6895
 6896
 6897
 6898
 6899
 6900
 6901
 6902
 6903
 6904
 6905
 6906
 6907
 6908
 6909
 6910
 6911
 6912
 6913
 6914
 6915
 6916
 6917
 6918
 6919
 6920
 6921
 6922
 6923
 6924
 6925
 6926
 6927
 6928
 6929
 6930
 6931
 6932
 6933
 6934
 6935
 6936
 6937
 6938
 6939
 6940
 6941
 6942
 6943
 6944
 6945
 6946
 6947
 6948
 6949
 6950
 6951
 6952
 6953
 6954
 6955
 6956
 6957
 6958
 6959
 6960
 6961
 6962
 6963
 6964
 6965
 6966
 6967
 6968
 6969
 6970
 6971
 6972
 6973
 6974
 6975
 6976
 6977
 6978
 6979
 6980
 6981
 6982
 6983
 6984
 6985
 6986
 6987
 6988
 6989
 6990
 6991
 6992
 6993
 6994
 6995
 6996
 6997
 6998
 6999
 7000
 7001
 7002
 7003
 7004
 7005
 7006
 7007
 7008
 7009
 7010
 7011
 7012
 7013
 7014
 7015
 7016
 7017
 7018
 7019
 7020
 7021
 7022
 7023
 7024
 7025
 7026
 7027
 7028
 7029
 7030
 7031
 7032
 7033
 7034
 7035
 7036
 7037
 7038
 7039
 7040
 7041
 7042
 7043
 7044
 7045
 7046
 7047
 7048
 7049
 7050
 7051
 7052
 7053
 7054
 7055
 7056
 7057
 7058
 7059
 7060
 7061
 7062
 7063
 7064
 7065
 7066
 7067
 7068
 7069
 7070
 7071
 7072
 7073
 7074
 7075
 7076
 7077
 7078
 7079
 7080
 7081
 7082
 7083
 7084
 7085
 7086
 7087
 7088
 7089
 7090
 7091
 7092
 7093
 7094
 7095
 7096
 7097
 7098
 7099
 7100
 7101
 7102
 7103
 7104
 7105
 7106
 7107
 7108
 7109
 7110
 7111
 7112
 7113
 7114
 7115
 7116
 7117
 7118
 7119
 7120
 7121
 7122
 7123
 7124
 7125
 7126
 7127
 7128
 7129
 7130
 7131
 7132
 7133
 7134
 7135
 7136
 7137
 7138
 7139
 7140
 7141
 7142
 7143
 7144
 7145
 7146
 7147
 7148
 7149
 7150
 7151
 7152
 7153
 7154
 7155
 7156
 7157
 7158
 7159
 7160
 7161
 7162
 7163
 7164
 7165
 7166
 7167
 7168
 7169
 7170
 7171
 7172
 7173
 7174
 7175
 7176
 7177
 7178
 7179
 7180
 7181
 7182
 7183
 7184
 7185
 7186
 7187
 7188
 7189
 7190
 7191
 7192
 7193
 7194
 7195
 7196
 7197
 7198
 7199
 7200
 7201
 7202
 7203
 7204
 7205
 7206
 7207
 7208
 7209
 7210
 7211
 7212
 7213
 7214
 7215
 7216
 7217
 7218
 7219
 7220
 7221
 7222
 7223
 7224
 7225
 7226
 7227
 7228
 7229
 7230
 7231
 7232
 7233
 7234
 7235
 7236
 7237
 7238
 7239
 7240
 7241
 7242
 7243
 7244
 7245
 7246
 7247
 7248
 7249
 7250
 7251
 7252
 7253
 7254
 7255
 7256
 7257
 7258
 7259
 7260
 7261
 7262
 7263
 7264
 7265
 7266
 7267
 7268
 7269
 7270
 7271
 7272
 7273
 7274
 7275
 7276
 7277
 7278
 7279
 7280
 7281
 7282
 7283
 7284
 7285
 7286
 7287
 7288
 7289
 7290
 7291
 7292
 7293
 7294
 7295
 7296
 7297
 7298
 7299
 7300
 7301
 7302
 7303
 7304
 7305
 7306
 7307
 7308
 7309
 7310
 7311
 7312
 7313
 7314
 7315
 7316
 7317
 7318
 7319
 7320
 7321
 7322
 7323
 7324
 7325
 7326
 7327
 7328
 7329
 7330
 7331
 7332
 7333
 7334
 7335
 7336
 7337
 7338
 7339
 7340
 7341
 7342
 7343
 7344
 7345
 7346
 7347
 7348
 7349
 7350
 7351
 7352
 7353
 7354
 7355
 7356
 7357
 7358
 7359
 7360
 7361
 7362
 7363
 7364
 7365
 7366
 7367
 7368
 7369
 7370
 7371
 7372
 7373
 7374
 7375
 7376
 7377
 7378
 7379
 7380
 7381
 7382
 7383
 7384
 7385
 7386
 7387
 7388
 7389
 7390
 7391
 7392
 7393
 7394
 7395
 7396
 7397
 7398
 7399
 7400
 7401
 7402
 7403
 7404
 7405
 7406
 7407
 7408
 7409
 7410
 7411
 7412
 7413
 7414
 7415
 7416
 7417
 7418
 7419
 7420
 7421
 7422
 7423
 7424
 7425
 7426
 7427
 7428
 7429
 7430
 7431
 7432
 7433
 7434
 7435
 7436
 7437
 7438
 7439
 7440
 7441
 7442
 7443
 7444
 7445
 7446
 7447
 7448
 7449
 7450
 7451
 7452
 7453
 7454
 7455
 7456
 7457
 7458
 7459
 7460
 7461
 7462
 7463
 7464
 7465
 7466
 7467
 7468
 7469
 7470
 7471
 7472
 7473
 7474
 7475
 7476
 7477
 7478
 7479
 7480
 7481
 7482
 7483
 7484
 7485
 7486
 7487
 7488
 7489
 7490
 7491
 7492
 7493
 7494
 7495
 7496
 7497
 7498
 7499
 7500
 7501
 7502
 7503
 7504
 7505
 7506
 7507
 7508
 7509
 7510
 7511
 7512
 7513
 7514
 7515
 7516
 7517
 7518
 7519
 7520
 7521
 7522
 7523
 7524
 7525
 7526
 7527
 7528
 7529
 7530
 7531
 7532
 7533
 7534
 7535
 7536
 7537
 7538
 7539
 7540
 7541
 7542
 7543
 7544
 7545
 7546
 7547
 7548
 7549
 7550
 7551
 7552
 7553
 7554
 7555
 7556
 7557
 7558
 7559
 7560
 7561
 7562
 7563
 7564
 7565
 7566
 7567
 7568
 7569
 7570
 7571
 7572
 7573
 7574
 7575
 7576
 7577
 7578
 7579
 7580
 7581
 7582
 7583
 7584
 7585
 7586
 7587
 7588
 7589
 7590
 7591
 7592
 7593
 7594
 7595
 7596
 7597
 7598
 7599
 7600
 7601
 7602
 7603
 7604
 7605
 7606
 7607
 7608
 7609
 7610
 7611
 7612
 7613
 7614
 7615
 7616
 7617
 7618
 7619
 7620
 7621
 7622
 7623
 7624
 7625
 7626
 7627
 7628
 7629
 7630
 7631
 7632
 7633
 7634
 7635
 7636
 7637
 7638
 7639
 7640
 7641
 7642
 7643
 7644
 7645
 7646
 7647
 7648
 7649
 7650
 7651
 7652
 7653
 7654
 7655
 7656
 7657
 7658
 7659
 7660
 7661
 7662
 7663
 7664
 7665
 7666
 7667
 7668
 7669
 7670
 7671
 7672
 7673
 7674
 7675
 7676
 7677
 7678
 7679
 7680
 7681
 7682
 7683
 7684
 7685
 7686
 7687
 7688
 7689
 7690
 7691
 7692
 7693
 7694
 7695
 7696
 7697
 7698
 7699
 7700
 7701
 7702
 7703
 7704
 7705
 7706
 7707
 7708
 7709
 7710
 7711
 7712
 7713
 7714
 7715
 7716
 7717
 7718
 7719
 7720
 7721
 7722
 7723
 7724
 7725
 7726
 7727
 7728
 7729
 7730
 7731
 7732
 7733
 7734
 7735
 7736
 7737
 7738
 7739
 7740
 7741
 7742
 7743
 7744
 7745
 7746
 7747
 7748
 7749
 7750
 7751
 7752
 7753
 7754
 7755
 7756
 7757
 7758
 7759
 7760
 7761
 7762
 7763
 7764
 7765
 7766
 7767
 7768
 7769
 7770
 7771
 7772
 7773
 7774
 7775
 7776
 7777
 7778
 7779
 7780
 7781
 7782
 7783
 7784
 7785
 7786
 7787
 7788
 7789
 7790
 7791
 7792
 7793
 7794
 7795
 7796
 7797
 7798
 7799
 7800
 7801
 7802
 7803
 7804
 7805
 7806
 7807
 7808
 7809
 7810
 7811
 7812
 7813
 7814
 7815
 7816
 7817
 7818
 7819
 7820
 7821
 7822
 7823
 7824
 7825
 7826
 7827
 7828
 7829
 7830
 7831
 7832
 7833
 7834
 7835
 7836
 7837
 7838
 7839
 7840
 7841
 7842
 7843
 7844
 7845
 7846
 7847
 7848
 7849
 7850
 7851
 7852
 7853
 7854
 7855
 7856
 7857
 7858
 7859
 7860
 7861
 7862
 7863
 7864
 7865
 7866
 7867
 7868
 7869
 7870
 7871
 7872
 7873
 7874
 7875
 7876
 7877
 7878
 7879
 7880
 7881
 7882
 7883
 7884
 7885
 7886
 7887
 7888
 7889
 7890
 7891
 7892
 7893
 7894
 7895
 7896
 7897
 7898
 7899
 7900
 7901
 7902
 7903
 7904
 7905
 7906
 7907
 7908
 7909
 7910
 7911
 7912
 7913
 7914
 7915
 7916
 7917
 7918
 7919
 7920
 7921
 7922
 7923
 7924
 7925
 7926
 7927
 7928
 7929
 7930
 7931
 7932
 7933
 7934
 7935
 7936
 7937
 7938
 7939
 7940
 7941
 7942
 7943
 7944
 7945
 7946
 7947
 7948
 7949
 7950
 7951
 7952
 7953
 7954
 7955
 7956
 7957
 7958
 7959
 7960
 7961
 7962
 7963
 7964
 7965
 7966
 7967
 7968
 7969
 7970
 7971
 7972
 7973
 7974
 7975
 7976
 7977
 7978
 7979
 7980
 7981
 7982
 7983
 7984
 7985
 7986
 7987
 7988
 7989
 7990
 7991
 7992
 7993
 7994
 7995
 7996
 7997
 7998
 7999
 8000
 8001
 8002
 8003
 8004
 8005
 8006
 8007
 8008
 8009
 8010
 8011
 8012
 8013
 8014
 8015
 8016
 8017
 8018
 8019
 8020
 8021
 8022
 8023
 8024
 8025
 8026
 8027
 8028
 8029
 8030
 8031
 8032
 8033
 8034
 8035
 8036
 8037
 8038
 8039
 8040
 8041
 8042
 8043
 8044
 8045
 8046
 8047
 8048
 8049
 8050
 8051
 8052
 8053
 8054
 8055
 8056
 8057
 8058
 8059
 8060
 8061
 8062
 8063
 8064
 8065
 8066
 8067
 8068
 8069
 8070
 8071
 8072
 8073
 8074
 8075
 8076
 8077
 8078
 8079
 8080
 8081
 8082
 8083
 8084
 8085
 8086
 8087
 8088
 8089
 8090
 8091
 8092
 8093
 8094
 8095
 8096
 8097
 8098
 8099
 8100
 8101
 8102
 8103
 8104
 8105
 8106
 8107
 8108
 8109
 8110
 8111
 8112
 8113
 8114
 8115
 8116
 8117
 8118
 8119
 8120
 8121
 8122
 8123
 8124
 8125
 8126
 8127
 8128
 8129
 8130
 8131
 8132
 8133
 8134
 8135
 8136
 8137
 8138
 8139
 8140
 8141
 8142
 8143
 8144
 8145
 8146
 8147
 8148
 8149
 8150
 8151
 8152
 8153
 8154
 8155
 8156
 8157
 8158
 8159
 8160
 8161
 8162
 8163
 8164
 8165
 8166
 8167
 8168
 8169
 8170
 8171
 8172
 8173
 8174
 8175
 8176
 8177
 8178
 8179
 8180
 8181
 8182
 8183
 8184
 8185
 8186
 8187
 8188
 8189
 8190
 8191
 8192
 8193
 8194
 8195
 8196
 8197
 8198
 8199
 8200
 8201
 8202
 8203
 8204
 8205
 8206
 8207
 8208
 8209
 8210
 8211
 8212
 8213
 8214
 8215
 8216
 8217
 8218
 8219
 8220
 8221
 8222
 8223
 8224
 8225
 8226
 8227
 8228
 8229
 8230
 8231
 8232
 8233
 8234
 8235
 8236
 8237
 8238
 8239
 8240
 8241
 8242
 8243
 8244
 8245
 8246
 8247
 8248
 8249
 8250
 8251
 8252
 8253
 8254
 8255
 8256
 8257
 8258
 8259
 8260
 8261
 8262
 8263
 8264
 8265
 8266
 8267
 8268
 8269
 8270
 8271
 8272
 8273
 8274
 8275
 8276
 8277
 8278
 8279
 8280
 8281
 8282
 8283
 8284
 8285
 8286
 8287
 8288
 8289
 8290
 8291
 8292
 8293
 8294
 8295
 8296
 8297
 8298
 8299
 8300
 8301
 8302
 8303
 8304
 8305
 8306
 8307
 8308
 8309
 8310
 8311
 8312
 8313
 8314
 8315
 8316
 8317
 8318
 8319
 8320
 8321
 8322
 8323
 8324
 8325
 8326
 8327
 8328
 8329
 8330
 8331
 8332
 8333
 8334
 8335
 8336
 8337
 8338
 8339
 8340
 8341
 8342
 8343
 8344
 8345
 8346
 8347
 8348
 8349
 8350
 8351
 8352
 8353
 8354
 8355
 8356
 8357
 8358
 8359
 8360
 8361
 8362
 8363
 8364
 8365
 8366
 8367
 8368
 8369
 8370
 8371
 8372
 8373
 8374
 8375
 8376
 8377
 8378
 8379
 8380
 8381
 8382
 8383
 8384
 8385
 8386
 8387
 8388
 8389
 8390
 8391
 8392
 8393
 8394
 8395
 8396
 8397
 8398
 8399
 8400
 8401
 8402
 8403
 8404
 8405
 8406
 8407
 8408
 8409
 8410
 8411
 8412
 8413
 8414
 8415
 8416
 8417
 8418
 8419
 8420
 8421
 8422
 8423
 8424
 8425
 8426
 8427
 8428
 8429
 8430
 8431
 8432
 8433
 8434
 8435
 8436
 8437
 8438
 8439
 8440
 8441
 8442
 8443
 8444
 8445
 8446
 8447
 8448
 8449
 8450
 8451
 8452
 8453
 8454
 8455
 8456
 8457
 8458
 8459
 8460
 8461
 8462
 8463
 8464
 8465
 8466
 8467
 8468
 8469
 8470
 8471
 8472
 8473
 8474
 8475
 8476
 8477
 8478
 8479
 8480
 8481
 8482
 8483
 8484
 8485
 8486
 8487
 8488
 8489
 8490
 8491
 8492
 8493
 8494
 8495
 8496
 8497
 8498
 8499
 8500
 8501
 8502
 8503
 8504
 8505
 8506
 8507
 8508
 8509
 8510
 8511
 8512
 8513
 8514
 8515
 8516
 8517
 8518
 8519
 8520
 8521
 8522
 8523
 8524
 8525
 8526
 8527
 8528
 8529
 8530
 8531
 8532
 8533
 8534
 8535
 8536
 8537
 8538
 8539
 8540
 8541
 8542
 8543
 8544
 8545
 8546
 8547
 8548
 8549
 8550
 8551
 8552
 8553
 8554
 8555
 8556
 8557
 8558
 8559
 8560
 8561
 8562
 8563
 8564
 8565
 8566
 8567
 8568
 8569
 8570
 8571
 8572
 8573
 8574
 8575
 8576
 8577
 8578
 8579
 8580
 8581
 8582
 8583
 8584
 8585
 8586
 8587
 8588
 8589
 8590
 8591
 8592
 8593
 8594
 8595
 8596
 8597
 8598
 8599
 8600
 8601
 8602
 8603
 8604
 8605
 8606
 8607
 8608
 8609
 8610
 8611
 8612
 8613
 8614
 8615
 8616
 8617
 8618
 8619
 8620
 8621
 8622
 8623
 8624
 8625
 8626
 8627
 8628
 8629
 8630
 8631
 8632
 8633
 8634
 8635
 8636
 8637
 8638
 8639
 8640
 8641
 8642
 8643
 8644
 8645
 8646
 8647
 8648
 8649
 8650
 8651
 8652
 8653
 8654
 8655
 8656
 8657
 8658
 8659
 8660
 8661
 8662
 8663
 8664
 8665
 8666
 8667
 8668
 8669
 8670
 8671
 8672
 8673
 8674
 8675
 8676
 8677
 8678
 8679
 8680
 8681
 8682
 8683
 8684
 8685
 8686
 8687
 8688
 8689
 8690
 8691
 8692
 8693
 8694
 8695
 8696
 8697
 8698
 8699
 8700
 8701
 8702
 8703
 8704
 8705
 8706
 8707
 8708
 8709
 8710
 8711
 8712
 8713
 8714
 8715
 8716
 8717
 8718
 8719
 8720
 8721
 8722
 8723
 8724
 8725
 8726
 8727
 8728
 8729
 8730
 8731
 8732
 8733
 8734
 8735
 8736
 8737
 8738
 8739
 8740
 8741
 8742
 8743
 8744
 8745
 8746
 8747
 8748
 8749
 8750
 8751
 8752
 8753
 8754
 8755
 8756
 8757
 8758
 8759
 8760
 8761
 8762
 8763
 8764
 8765
 8766
 8767
 8768
 8769
 8770
 8771
 8772
 8773
 8774
 8775
 8776
 8777
 8778
 8779
 8780
 8781
 8782
 8783
 8784
 8785
 8786
 8787
 8788
 8789
 8790
 8791
 8792
 8793
 8794
 8795
 8796
 8797
 8798
 8799
 8800
 8801
 8802
 8803
 8804
 8805
 8806
 8807
 8808
 8809
 8810
 8811
 8812
 8813
 8814
 8815
 8816
 8817
 8818
 8819
 8820
 8821
 8822
 8823
 8824
 8825
 8826
 8827
 8828
 8829
 8830
 8831
 8832
 8833
 8834
 8835
 8836
 8837
 8838
 8839
 8840
 8841
 8842
 8843
 8844
 8845
 8846
 8847
 8848
 8849
 8850
 8851
 8852
 8853
 8854
 8855
 8856
 8857
 8858
 8859
 8860
 8861
 8862
 8863
 8864
 8865
 8866
 8867
 8868
 8869
 8870
 8871
 8872
 8873
 8874
 8875
 8876
 8877
 8878
 8879
 8880
 8881
 8882
 8883
 8884
 8885
 8886
 8887
 8888
 8889
 8890
 8891
 8892
 8893
 8894
 8895
 8896
 8897
 8898
 8899
 8900
 8901
 8902
 8903
 8904
 8905
 8906
 8907
 8908
 8909
 8910
 8911
 8912
 8913
 8914
 8915
 8916
 8917
 8918
 8919
 8920
 8921
 8922
 8923
 8924
 8925
 8926
 8927
 8928
 8929
 8930
 8931
 8932
 8933
 8934
 8935
 8936
 8937
 8938
 8939
 8940
 8941
 8942
 8943
 8944
 8945
 8946
 8947
 8948
 8949
 8950
 8951
 8952
 8953
 8954
 8955
 8956
 8957
 8958
 8959
 8960
 8961
 8962
 8963
 8964
 8965
 8966
 8967
 8968
 8969
 8970
 8971
 8972
 8973
 8974
 8975
 8976
 8977
 8978
 8979
 8980
 8981
 8982
 8983
 8984
 8985
 8986
 8987
 8988
 8989
 8990
 8991
 8992
 8993
 8994
 8995
 8996
 8997
 8998
 8999
 9000
 9001
 9002
 9003
 9004
 9005
 9006
 9007
 9008
 9009
 9010
 9011
 9012
 9013
 9014
 9015
 9016
 9017
 9018
 9019
 9020
 9021
 9022
 9023
 9024
 9025
 9026
 9027
 9028
 9029
 9030
 9031
 9032
 9033
 9034
 9035
 9036
 9037
 9038
 9039
 9040
 9041
 9042
 9043
 9044
 9045
 9046
 9047
 9048
 9049
 9050
 9051
 9052
 9053
 9054
 9055
 9056
 9057
 9058
 9059
 9060
 9061
 9062
 9063
 9064
 9065
 9066
 9067
 9068
 9069
 9070
 9071
 9072
 9073
 9074
 9075
 9076
 9077
 9078
 9079
 9080
 9081
 9082
 9083
 9084
 9085
 9086
 9087
 9088
 9089
 9090
 9091
 9092
 9093
 9094
 9095
 9096
 9097
 9098
 9099
 9100
 9101
 9102
 9103
 9104
 9105
 9106
 9107
 9108
 9109
 9110
 9111
 9112
 9113
 9114
 9115
 9116
 9117
 9118
 9119
 9120
 9121
 9122
 9123
 9124
 9125
 9126
 9127
 9128
 9129
 9130
 9131
 9132
 9133
 9134
 9135
 9136
 9137
 9138
 9139
 9140
 9141
 9142
 9143
 9144
 9145
 9146
 9147
 9148
 9149
 9150
 9151
 9152
 9153
 9154
 9155
 9156
 9157
 9158
 9159
 9160
 9161
 9162
 9163
 9164
 9165
 9166
 9167
 9168
 9169
 9170
 9171
 9172
 9173
 9174
 9175
 9176
 9177
 9178
 9179
 9180
 9181
 9182
 9183
 9184
 9185
 9186
 9187
 9188
 9189
 9190
 9191
 9192
 9193
 9194
 9195
 9196
 9197
 9198
 9199
 9200
 9201
 9202
 9203
 9204
 9205
 9206
 9207
 9208
 9209
 9210
 9211
 9212
 9213
 9214
 9215
 9216
 9217
 9218
 9219
 9220
 9221
 9222
 9223
 9224
 9225
 9226
 9227
 9228
 9229
 9230
 9231
 9232
 9233
 9234
 9235
 9236
 9237
 9238
 9239
 9240
 9241
 9242
 9243
 9244
 9245
 9246
 9247
 9248
 9249
 9250
 9251
 9252
 9253
 9254
 9255
 9256
 9257
 9258
 9259
 9260
 9261
 9262
 9263
 9264
 9265
 9266
 9267
 9268
 9269
 9270
 9271
 9272
 9273
 9274
 9275
 9276
 9277
 9278
 9279
 9280
 9281
 9282
 9283
 9284
 9285
 9286
 9287
 9288
 9289
 9290
 9291
 9292
 9293
 9294
 9295
 9296
 9297
 9298
 9299
 9300
 9301
 9302
 9303
 9304
 9305
 9306
 9307
 9308
 9309
 9310
 9311
 9312
 9313
 9314
 9315
 9316
 9317
 9318
 9319
 9320
 9321
 9322
 9323
 9324
 9325
 9326
 9327
 9328
 9329
 9330
 9331
 9332
 9333
 9334
 9335
 9336
 9337
 9338
 9339
 9340
 9341
 9342
 9343
 9344
 9345
 9346
 9347
 9348
 9349
 9350
 9351
 9352
 9353
 9354
 9355
 9356
 9357
 9358
 9359
 9360
 9361
 9362
 9363
 9364
 9365
 9366
 9367
 9368
 9369
 9370
 9371
 9372
 9373
 9374
 9375
 9376
 9377
 9378
 9379
 9380
 9381
 9382
 9383
 9384
 9385
 9386
 9387
 9388
 9389
 9390
 9391
 9392
 9393
 9394
 9395
 9396
 9397
 9398
 9399
 9400
 9401
 9402
 9403
 9404
 9405
 9406
 9407
 9408
 9409
 9410
 9411
 9412
 9413
 9414
 9415
 9416
 9417
 9418
 9419
 9420
 9421
 9422
 9423
 9424
 9425
 9426
 9427
 9428
 9429
 9430
 9431
 9432
 9433
 9434
 9435
 9436
 9437
 9438
 9439
 9440
 9441
 9442
 9443
 9444
 9445
 9446
 9447
 9448
 9449
 9450
 9451
 9452
 9453
 9454
 9455
 9456
 9457
 9458
 9459
 9460
 9461
 9462
 9463
 9464
 9465
 9466
 9467
 9468
 9469
 9470
 9471
 9472
 9473
 9474
 9475
 9476
 9477
 9478
 9479
 9480
 9481
 9482
 9483
 9484
 9485
 9486
 9487
 9488
 9489
 9490
 9491
 9492
 9493
 9494
 9495
 9496
 9497
 9498
 9499
 9500
 9501
 9502
 9503
 9504
 9505
 9506
 9507
 9508
 9509
 9510
 9511
 9512
 9513
 9514
 9515
 9516
 9517
 9518
 9519
 9520
 9521
 9522
 9523
 9524
 9525
 9526
 9527
 9528
 9529
 9530
 9531
 9532
 9533
 9534
 9535
 9536
 9537
 9538
 9539
 9540
 9541
 9542
 9543
 9544
 9545
 9546
 9547
 9548
 9549
 9550
 9551
 9552
 9553
 9554
 9555
 9556
 9557
 9558
 9559
 9560
 9561
 9562
 9563
 9564
 9565
 9566
 9567
 9568
 9569
 9570
 9571
 9572
 9573
 9574
 9575
 9576
 9577
 9578
 9579
 9580
 9581
 9582
 9583
 9584
 9585
 9586
 9587
 9588
 9589
 9590
 9591
 9592
 9593
 9594
 9595
 9596
 9597
 9598
 9599
 9600
 9601
 9602
 9603
 9604
 9605
 9606
 9607
 9608
 9609
 9610
 9611
 9612
 9613
 9614
 9615
 9616
 9617
 9618
 9619
 9620
 9621
 9622
 9623
 9624
 9625
 9626
 9627
 9628
 9629
 9630
 9631
 9632
 9633
 9634
 9635
 9636
 9637
 9638
 9639
 9640
 9641
 9642
 9643
 9644
 9645
 9646
 9647
 9648
 9649
 9650
 9651
 9652
 9653
 9654
 9655
 9656
 9657
 9658
 9659
 9660
 9661
 9662
 9663
 9664
 9665
 9666
 9667
 9668
 9669
 9670
 9671
 9672
 9673
 9674
 9675
 9676
 9677
 9678
 9679
 9680
 9681
 9682
 9683
 9684
 9685
 9686
 9687
 9688
 9689
 9690
 9691
 9692
 9693
 9694
 9695
 9696
 9697
 9698
 9699
 9700
 9701
 9702
 9703
 9704
 9705
 9706
 9707
 9708
 9709
 9710
 9711
 9712
 9713
 9714
 9715
 9716
 9717
 9718
 9719
 9720
 9721
 9722
 9723
 9724
 9725
 9726
 9727
 9728
 9729
 9730
 9731
 9732
 9733
 9734
 9735
 9736
 9737
 9738
 9739
 9740
 9741
 9742
 9743
 9744
 9745
 9746
 9747
 9748
 9749
 9750
 9751
 9752
 9753
 9754
 9755
 9756
 9757
 9758
 9759
 9760
 9761
 9762
 9763
 9764
 9765
 9766
 9767
 9768
 9769
 9770
 9771
 9772
 9773
 9774
 9775
 9776
 9777
 9778
 9779
 9780
 9781
 9782
 9783
 9784
 9785
 9786
 9787
 9788
 9789
 9790
 9791
 9792
 9793
 9794
 9795
 9796
 9797
 9798
 9799
 9800
 9801
 9802
 9803
 9804
 9805
 9806
 9807
 9808
 9809
 9810
 9811
 9812
 9813
 9814
 9815
 9816
 9817
 9818
 9819
 9820
 9821
 9822
 9823
 9824
 9825
 9826
 9827
 9828
 9829
 9830
 9831
 9832
 9833
 9834
 9835
 9836
 9837
 9838
 9839
 9840
 9841
 9842
 9843
 9844
 9845
 9846
 9847
 9848
 9849
 9850
 9851
 9852
 9853
 9854
 9855
 9856
 9857
 9858
 9859
 9860
 9861
 9862
 9863
 9864
 9865
 9866
 9867
 9868
 9869
 9870
 9871
 9872
 9873
 9874
 9875
 9876
 9877
 9878
 9879
 9880
 9881
 9882
 9883
 9884
 9885
 9886
 9887
 9888
 9889
 9890
 9891
 9892
 9893
 9894
 9895
 9896
 9897
 9898
 9899
 9900
 9901
 9902
 9903
 9904
 9905
 9906
 9907
 9908
 9909
 9910
 9911
 9912
 9913
 9914
 9915
 9916
 9917
 9918
 9919
 9920
 9921
 9922
 9923
 9924
 9925
 9926
 9927
 9928
 9929
 9930
 9931
 9932
 9933
 9934
 9935
 9936
 9937
 9938
 9939
 9940
 9941
 9942
 9943
 9944
 9945
 9946
 9947
 9948
 9949
 9950
 9951
 9952
 9953
 9954
 9955
 9956
 9957
 9958
 9959
 9960
 9961
 9962
 9963
 9964
 9965
 9966
 9967
 9968
 9969
 9970
 9971
 9972
 9973
 9974
 9975
 9976
 9977
 9978
 9979
 9980
 9981
 9982
 9983
 9984
 9985
 9986
 9987
 9988
 9989
 9990
 9991
 9992
 9993
 9994
 9995
 9996
 9997
 9998
 9999
10000
10001
10002
10003
10004
10005
10006
10007
10008
10009
10010
10011
10012
10013
10014
10015
10016
10017
10018
10019
10020
10021
10022
10023
10024
10025
10026
10027
10028
10029
10030
10031
10032
10033
10034
10035
10036
10037
10038
10039
10040
10041
10042
10043
10044
10045
10046
10047
10048
10049
10050
10051
10052
10053
10054
10055
10056
10057
10058
10059
10060
10061
10062
10063
10064
10065
10066
10067
10068
10069
10070
10071
10072
10073
10074
10075
10076
10077
10078
10079
10080
10081
10082
10083
10084
10085
10086
10087
10088
10089
10090
10091
10092
10093
10094
10095
10096
10097
10098
10099
10100
10101
10102
10103
10104
10105
10106
10107
10108
10109
10110
10111
10112
10113
10114
10115
10116
10117
10118
10119
10120
10121
10122
10123
10124
10125
10126
10127
10128
10129
10130
10131
10132
10133
10134
10135
10136
10137
10138
10139
10140
10141
10142
10143
10144
10145
10146
10147
10148
10149
10150
10151
10152
10153
10154
10155
10156
10157
10158
10159
10160
10161
10162
10163
10164
10165
10166
10167
10168
10169
10170
10171
10172
10173
10174
10175
10176
10177
10178
10179
10180
10181
10182
10183
10184
10185
10186
10187
10188
10189
10190
10191
10192
10193
10194
10195
10196
10197
10198
10199
10200
10201
10202
10203
10204
10205
10206
10207
10208
10209
10210
10211
10212
10213
10214
10215
10216
10217
10218
10219
10220
10221
10222
10223
10224
10225
10226
10227
10228
10229
10230
10231
10232
10233
10234
10235
10236
10237
10238
10239
10240
10241
10242
10243
10244
10245
10246
10247
10248
10249
10250
10251
10252
10253
10254
10255
10256
10257
10258
10259
10260
10261
10262
10263
10264
10265
10266
10267
10268
10269
10270
10271
10272
10273
10274
10275
10276
10277
10278
10279
10280
10281
10282
10283
10284
10285
10286
10287
10288
10289
10290
10291
10292
10293
10294
10295
10296
10297
10298
10299
10300
10301
10302
10303
10304
10305
10306
10307
10308
10309
10310
10311
10312
10313
10314
10315
10316
10317
10318
10319
10320
10321
10322
10323
10324
10325
10326
10327
10328
10329
10330
10331
10332
10333
10334
10335
10336
10337
10338
10339
10340
10341
10342
10343
10344
10345
10346
10347
10348
10349
10350
10351
10352
10353
10354
10355
10356
10357
10358
10359
10360
10361
10362
10363
10364
10365
10366
10367
10368
10369
10370
10371
10372
10373
10374
10375
10376
10377
10378
10379
10380
10381
10382
10383
10384
10385
10386
10387
10388
10389
10390
10391
10392
10393
10394
10395
10396
10397
10398
10399
10400
10401
10402
10403
10404
10405
10406
10407
10408
10409
10410
10411
10412
10413
10414
10415
10416
10417
10418
10419
10420
10421
10422
10423
10424
10425
10426
10427
10428
10429
10430
10431
10432
10433
10434
10435
10436
10437
10438
10439
10440
10441
10442
10443
10444
10445
10446
10447
10448
10449
10450
10451
10452
10453
10454
10455
10456
10457
10458
10459
10460
10461
10462
10463
10464
10465
10466
10467
10468
10469
10470
10471
10472
10473
10474
10475
10476
10477
10478
10479
10480
10481
10482
10483
10484
10485
10486
10487
10488
10489
10490
10491
10492
10493
10494
10495
10496
10497
10498
10499
10500
10501
10502
10503
10504
10505
10506
10507
10508
10509
10510
10511
10512
10513
10514
10515
10516
10517
10518
10519
10520
10521
10522
10523
10524
10525
10526
10527
10528
10529
10530
10531
10532
10533
10534
10535
10536
10537
10538
10539
10540
10541
10542
10543
10544
10545
10546
10547
10548
10549
10550
10551
10552
10553
10554
10555
10556
10557
10558
10559
10560
10561
10562
10563
10564
10565
10566
10567
10568
10569
10570
10571
10572
10573
10574
10575
10576
10577
10578
10579
10580
10581
10582
10583
10584
10585
10586
10587
10588
10589
10590
10591
10592
10593
10594
10595
10596
10597
10598
10599
10600
10601
10602
10603
10604
10605
10606
10607
10608
10609
10610
10611
10612
10613
10614
10615
10616
10617
10618
10619
10620
10621
10622
10623
10624
10625
10626
10627
10628
10629
10630
10631
10632
10633
10634
10635
10636
10637
10638
10639
10640
10641
10642
10643
10644
10645
10646
10647
10648
10649
10650
10651
10652
10653
10654
10655
10656
10657
10658
10659
10660
10661
10662
10663
10664
10665
10666
10667
10668
10669
10670
10671
10672
10673
10674
10675
10676
10677
10678
10679
10680
10681
10682
10683
10684
10685
10686
10687
10688
10689
10690
10691
10692
10693
10694
10695
10696
10697
10698
10699
10700
10701
10702
10703
10704
10705
10706
10707
10708
10709
10710
10711
10712
10713
10714
10715
10716
10717
10718
10719
10720
10721
10722
10723
10724
10725
10726
10727
10728
10729
10730
10731
10732
10733
10734
10735
10736
10737
10738
10739
10740
10741
10742
10743
10744
10745
10746
10747
10748
10749
10750
10751
10752
10753
10754
10755
10756
10757
10758
10759
10760
10761
10762
10763
10764
10765
10766
10767
10768
10769
10770
10771
10772
10773
10774
10775
10776
10777
10778
10779
10780
10781
10782
10783
10784
10785
10786
10787
10788
10789
10790
10791
10792
10793
10794
10795
10796
10797
10798
10799
10800
10801
10802
10803
10804
10805
10806
10807
10808
10809
10810
10811
10812
10813
10814
10815
10816
10817
10818
10819
10820
10821
10822
10823
10824
10825
10826
10827
10828
10829
10830
10831
10832
10833
10834
10835
10836
10837
10838
10839
10840
10841
10842
10843
10844
10845
10846
10847
10848
10849
10850
10851
10852
10853
10854
10855
10856
10857
10858
10859
10860
10861
10862
10863
10864
10865
10866
10867
10868
10869
10870
10871
10872
10873
10874
10875
10876
10877
10878
10879
10880
10881
10882
10883
10884
10885
10886
10887
10888
10889
10890
10891
10892
10893
10894
10895
10896
10897
10898
10899
10900
10901
10902
10903
10904
10905
10906
10907
10908
10909
10910
10911
10912
10913
10914
10915
10916
10917
10918
10919
10920
10921
10922
10923
10924
10925
10926
10927
10928
10929
10930
10931
10932
10933
10934
10935
10936
10937
10938
10939
10940
10941
10942
10943
10944
10945
10946
10947
10948
10949
10950
10951
10952
10953
10954
10955
10956
10957
10958
10959
10960
10961
10962
10963
10964
10965
10966
10967
10968
10969
10970
10971
10972
10973
10974
10975
10976
10977
10978
10979
10980
10981
10982
10983
10984
10985
10986
10987
10988
10989
10990
10991
10992
10993
10994
10995
10996
10997
10998
10999
11000
11001
11002
11003
11004
11005
11006
11007
11008
11009
11010
11011
11012
11013
11014
11015
11016
11017
11018
11019
11020
11021
11022
11023
11024
11025
11026
11027
11028
11029
11030
11031
11032
11033
11034
11035
11036
11037
11038
11039
11040
11041
11042
11043
11044
11045
11046
11047
11048
11049
11050
11051
11052
11053
11054
11055
11056
11057
11058
11059
11060
11061
11062
11063
11064
11065
11066
11067
11068
11069
11070
11071
11072
11073
11074
11075
11076
11077
11078
11079
11080
11081
11082
11083
11084
11085
11086
11087
11088
11089
11090
11091
11092
11093
11094
11095
11096
11097
11098
11099
11100
11101
11102
11103
11104
11105
11106
11107
11108
11109
11110
11111
11112
11113
11114
11115
11116
11117
11118
11119
11120
11121
11122
11123
11124
11125
11126
11127
11128
11129
11130
11131
11132
11133
11134
11135
11136
11137
11138
11139
11140
11141
11142
11143
11144
11145
11146
11147
11148
11149
11150
11151
11152
11153
11154
11155
11156
11157
11158
11159
11160
11161
11162
11163
11164
11165
11166
11167
11168
11169
11170
11171
11172
11173
11174
11175
11176
11177
11178
11179
11180
11181
11182
11183
11184
11185
11186
11187
11188
11189
11190
11191
11192
11193
11194
11195
11196
11197
11198
11199
11200
11201
11202
11203
11204
11205
11206
11207
11208
11209
11210
11211
11212
11213
11214
11215
11216
11217
11218
11219
11220
11221
11222
11223
11224
11225
11226
11227
11228
11229
11230
11231
11232
11233
11234
11235
11236
11237
11238
11239
11240
11241
11242
11243
11244
11245
11246
11247
11248
11249
11250
11251
11252
11253
11254
11255
11256
11257
11258
11259
11260
11261
11262
11263
11264
11265
11266
11267
11268
11269
11270
11271
11272
11273
11274
11275
11276
11277
11278
11279
11280
11281
11282
11283
11284
11285
11286
11287
11288
11289
11290
11291
11292
11293
11294
11295
11296
11297
11298
11299
11300
11301
11302
11303
11304
11305
<!doctype html public "-//W30//DTD W3 HTML 2.0//EN">

<HTML>

<!-- This file was generated using SDF 2.001 by
     Ian Clatworthy (ianc@mincom.com). SDF is freely
     available from http://www.mincom.com/mtr/sdf. -->

<HEAD>
<TITLE>OpenLDAP Software 2.5 Administrator's Guide</TITLE>
</HEAD>
<BODY>

<DIV CLASS="header">
<A HREF="https://www.OpenLDAP.org/">
<P><IMG SRC="../images/LDAPlogo.gif" ALIGN="Left" BORDER=0></P>
</A>
<DIV CLASS="navigate">
<P ALIGN="Center"><A HREF="https://www.openldap.org/">Home</A> | <A HREF="../index.html">Catalog</A></P>
</DIV>
<BR CLEAR="Left">
</DIV>
<DIV CLASS="title">
<H1 CLASS="doc-title">OpenLDAP Software 2.5 Administrator's Guide</H1>
<ADDRESS CLASS="doc-author">The OpenLDAP Project &lt;<A HREF="https://www.openldap.org/">https://www.openldap.org/</A>&gt;</ADDRESS>
<ADDRESS CLASS="doc-modified">27 July 2021</ADDRESS>
<BR CLEAR="All">
</DIV>
<DIV CLASS="contents">
<HR>
<H2>Table of Contents</H2>
<UL>
<A HREF="#Preface">Preface</A>
<BR>
<A HREF="#Introduction to OpenLDAP Directory Services">1. Introduction to OpenLDAP Directory Services</A><UL>
<A HREF="#What is a directory service">1.1. What is a directory service?</A>
<BR>
<A HREF="#What is LDAP">1.2. What is LDAP?</A>
<BR>
<A HREF="#When should I use LDAP">1.3. When should I use LDAP?</A>
<BR>
<A HREF="#When should I not use LDAP">1.4. When should I not use LDAP?</A>
<BR>
<A HREF="#How does LDAP work">1.5. How does LDAP work?</A>
<BR>
<A HREF="#What about X.500">1.6. What about X.500?</A>
<BR>
<A HREF="#What is the difference between LDAPv2 and LDAPv3">1.7. What is the difference between LDAPv2 and LDAPv3?</A>
<BR>
<A HREF="#LDAP vs RDBMS">1.8. LDAP vs RDBMS</A>
<BR>
<A HREF="#What is slapd and what can it do">1.9. What is slapd and what can it do?</A></UL>
<BR>
<A HREF="#A Quick-Start Guide">2. A Quick-Start Guide</A>
<BR>
<A HREF="#The Big Picture - Configuration Choices">3. The Big Picture - Configuration Choices</A><UL>
<A HREF="#Local Directory Service">3.1. Local Directory Service</A>
<BR>
<A HREF="#Local Directory Service with Referrals">3.2. Local Directory Service with Referrals</A>
<BR>
<A HREF="#Replicated Directory Service">3.3. Replicated Directory Service</A>
<BR>
<A HREF="#Distributed Local Directory Service">3.4. Distributed Local Directory Service</A></UL>
<BR>
<A HREF="#Building and Installing OpenLDAP Software">4. Building and Installing OpenLDAP Software</A><UL>
<A HREF="#Obtaining and Extracting the Software">4.1. Obtaining and Extracting the Software</A>
<BR>
<A HREF="#Prerequisite software">4.2. Prerequisite software</A><UL>
<A HREF="#{{TERM[expand]TLS}}">4.2.1. <TERM>Transport Layer Security</TERM></A>
<BR>
<A HREF="#{{TERM[expand]SASL}}">4.2.2. <TERM>Simple Authentication and Security Layer</TERM></A>
<BR>
<A HREF="#{{TERM[expand]Kerberos}}">4.2.3. <TERM>Kerberos Authentication Service</TERM></A>
<BR>
<A HREF="#Database Software">4.2.4. Database Software</A>
<BR>
<A HREF="#Threads">4.2.5. Threads</A>
<BR>
<A HREF="#TCP Wrappers">4.2.6. TCP Wrappers</A></UL>
<BR>
<A HREF="#Running configure">4.3. Running configure</A>
<BR>
<A HREF="#Building the Software">4.4. Building the Software</A>
<BR>
<A HREF="#Testing the Software">4.5. Testing the Software</A>
<BR>
<A HREF="#Installing the Software">4.6. Installing the Software</A></UL>
<BR>
<A HREF="#Configuring slapd">5. Configuring slapd</A><UL>
<A HREF="#Configuration Layout">5.1. Configuration Layout</A>
<BR>
<A HREF="#Configuration Directives">5.2. Configuration Directives</A><UL>
<A HREF="#cn=config">5.2.1. cn=config</A>
<BR>
<A HREF="#cn=module">5.2.2. cn=module</A>
<BR>
<A HREF="#cn=schema">5.2.3. cn=schema</A>
<BR>
<A HREF="#Backend-specific Directives">5.2.4. Backend-specific Directives</A>
<BR>
<A HREF="#Database-specific Directives">5.2.5. Database-specific Directives</A>
<BR>
<A HREF="#MDB Backend Directives">5.2.6. MDB Backend Directives</A>
<BR>
<A HREF="#MDB Database Directives">5.2.7. MDB Database Directives</A></UL>
<BR>
<A HREF="#Configuration Example">5.3. Configuration Example</A>
<BR>
<A HREF="#Converting old style {{slapd.conf}}(5) file to {{cn=config}} format">5.4. Converting old style <EM>slapd.conf</EM>(5) file to <EM>cn=config</EM> format</A>
<BR>
<A HREF="#Recovering from a broken configuration">5.5. Recovering from a broken configuration</A><UL>
<A HREF="#Generate an ldif version of the configuration database and reload from that">5.5.1. Generate an ldif version of the configuration database and reload from that</A>
<BR>
<A HREF="#Modify config in-place">5.5.2. Modify config in-place</A>
<BR>
<A HREF="#Recover with plain back-ldif">5.5.3. Recover with plain back-ldif</A></UL></UL>
<BR>
<A HREF="#The slapd Configuration File">6. The slapd Configuration File</A><UL>
<A HREF="#Configuration File Format">6.1. Configuration File Format</A>
<BR>
<A HREF="#Configuration File Directives">6.2. Configuration File Directives</A><UL>
<A HREF="#Global Directives">6.2.1. Global Directives</A>
<BR>
<A HREF="#General Backend Directives">6.2.2. General Backend Directives</A>
<BR>
<A HREF="#General Database Directives">6.2.3. General Database Directives</A>
<BR>
<A HREF="#MDB Backend Directives">6.2.4. MDB Backend Directives</A>
<BR>
<A HREF="#MDB Database Directives">6.2.5. MDB Database Directives</A></UL>
<BR>
<A HREF="#Configuration File Example">6.3. Configuration File Example</A></UL>
<BR>
<A HREF="#Running slapd">7. Running slapd</A><UL>
<A HREF="#Command-Line Options">7.1. Command-Line Options</A>
<BR>
<A HREF="#Starting slapd">7.2. Starting slapd</A>
<BR>
<A HREF="#Stopping slapd">7.3. Stopping slapd</A></UL>
<BR>
<A HREF="#Access Control">8. Access Control</A><UL>
<A HREF="#Introduction">8.1. Introduction</A>
<BR>
<A HREF="#Access Control via Static Configuration">8.2. Access Control via Static Configuration</A><UL>
<A HREF="#What to control access to">8.2.1. What to control access to</A>
<BR>
<A HREF="#Who to grant access to">8.2.2. Who to grant access to</A>
<BR>
<A HREF="#The access to grant">8.2.3. The access to grant</A>
<BR>
<A HREF="#Access Control Evaluation">8.2.4. Access Control Evaluation</A>
<BR>
<A HREF="#Access Control Examples">8.2.5. Access Control Examples</A></UL>
<BR>
<A HREF="#Access Control via Dynamic Configuration">8.3. Access Control via Dynamic Configuration</A><UL>
<A HREF="#What to control access to">8.3.1. What to control access to</A>
<BR>
<A HREF="#Who to grant access to">8.3.2. Who to grant access to</A>
<BR>
<A HREF="#The access to grant">8.3.3. The access to grant</A>
<BR>
<A HREF="#Access Control Evaluation">8.3.4. Access Control Evaluation</A>
<BR>
<A HREF="#Access Control Examples">8.3.5. Access Control Examples</A>
<BR>
<A HREF="#Access Control Ordering">8.3.6. Access Control Ordering</A></UL>
<BR>
<A HREF="#Access Control Common Examples">8.4. Access Control Common Examples</A><UL>
<A HREF="#Basic ACLs">8.4.1. Basic ACLs</A>
<BR>
<A HREF="#Matching Anonymous and Authenticated users">8.4.2. Matching Anonymous and Authenticated users</A>
<BR>
<A HREF="#Controlling rootdn access">8.4.3. Controlling rootdn access</A>
<BR>
<A HREF="#Managing access with Groups">8.4.4. Managing access with Groups</A>
<BR>
<A HREF="#Granting access to a subset of attributes">8.4.5. Granting access to a subset of attributes</A>
<BR>
<A HREF="#Allowing a user write to all entries below theirs">8.4.6. Allowing a user write to all entries below theirs</A>
<BR>
<A HREF="#Allowing entry creation">8.4.7. Allowing entry creation</A>
<BR>
<A HREF="#Tips for using regular expressions in Access Control">8.4.8. Tips for using regular expressions in Access Control</A>
<BR>
<A HREF="#Granting and Denying access based on security strength factors (ssf)">8.4.9. Granting and Denying access based on security strength factors (ssf)</A>
<BR>
<A HREF="#When things aren\'t working as expected">8.4.10. When things aren't working as expected</A></UL>
<BR>
<A HREF="#Sets - Granting rights based on relationships">8.5. Sets - Granting rights based on relationships</A><UL>
<A HREF="#Groups of Groups">8.5.1. Groups of Groups</A>
<BR>
<A HREF="#Group ACLs without DN syntax">8.5.2. Group ACLs without DN syntax</A>
<BR>
<A HREF="#Following references">8.5.3. Following references</A></UL></UL>
<BR>
<A HREF="#Limits">9. Limits</A><UL>
<A HREF="#Introduction">9.1. Introduction</A>
<BR>
<A HREF="#Soft and Hard limits">9.2. Soft and Hard limits</A>
<BR>
<A HREF="#Global Limits">9.3. Global Limits</A><UL>
<A HREF="#Special Size Limits">9.3.1. Special Size Limits</A></UL>
<BR>
<A HREF="#Per-Database Limits">9.4. Per-Database Limits</A><UL>
<A HREF="#Specify who the limits apply to">9.4.1. Specify who the limits apply to</A>
<BR>
<A HREF="#Specify time limits">9.4.2. Specify time limits</A>
<BR>
<A HREF="#Specifying size limits">9.4.3. Specifying size limits</A></UL>
<BR>
<A HREF="#Example Limit Configurations">9.5. Example Limit Configurations</A><UL>
<A HREF="#Simple Global Limits">9.5.1. Simple Global Limits</A>
<BR>
<A HREF="#Global Hard and Soft Limits">9.5.2. Global Hard and Soft Limits</A>
<BR>
<A HREF="#Giving specific users larger limits">9.5.3. Giving specific users larger limits</A>
<BR>
<A HREF="#Limiting who can do paged searches">9.5.4. Limiting who can do paged searches</A></UL>
<BR>
<A HREF="#Glued/Subordinate database configurations When using subordinate databases, it is necessary for any limits that are to be applied across the parent and its subordinates to be defined in both the parent and its subordinates. Otherwise the settings on the subordinate databases are not honored">9.6. Glued/Subordinate database configurations When using subordinate databases, it is necessary for any limits that are to be applied across the parent and its subordinates to be defined in both the parent and its subordinates. Otherwise the settings on the subordinate databases are not honored.</A>
<BR>
<A HREF="#Further Information">9.7. Further Information</A></UL>
<BR>
<A HREF="#Database Creation and Maintenance Tools">10. Database Creation and Maintenance Tools</A><UL>
<A HREF="#Creating a database over LDAP">10.1. Creating a database over LDAP</A>
<BR>
<A HREF="#Creating a database off-line">10.2. Creating a database off-line</A><UL>
<A HREF="#The {{EX:slapadd}} program">10.2.1. The <TT>slapadd</TT> program</A>
<BR>
<A HREF="#The {{EX:slapindex}} program">10.2.2. The <TT>slapindex</TT> program</A>
<BR>
<A HREF="#The {{EX:slapcat}} program">10.2.3. The <TT>slapcat</TT> program</A></UL>
<BR>
<A HREF="#The LDIF text entry format">10.3. The LDIF text entry format</A></UL>
<BR>
<A HREF="#Backends">11. Backends</A><UL>
<A HREF="#LDAP">11.1. LDAP</A><UL>
<A HREF="#Overview">11.1.1. Overview</A>
<BR>
<A HREF="#back-ldap Configuration">11.1.2. back-ldap Configuration</A>
<BR>
<A HREF="#Further Information">11.1.3. Further Information</A></UL>
<BR>
<A HREF="#LDIF">11.2. LDIF</A><UL>
<A HREF="#Overview">11.2.1. Overview</A>
<BR>
<A HREF="#back-ldif Configuration">11.2.2. back-ldif Configuration</A>
<BR>
<A HREF="#Further Information">11.2.3. Further Information</A></UL>
<BR>
<A HREF="#LMDB">11.3. LMDB</A><UL>
<A HREF="#Overview">11.3.1. Overview</A>
<BR>
<A HREF="#back-mdb Configuration">11.3.2. back-mdb Configuration</A>
<BR>
<A HREF="#Further Information">11.3.3. Further Information</A></UL>
<BR>
<A HREF="#Metadirectory">11.4. Metadirectory</A><UL>
<A HREF="#Overview">11.4.1. Overview</A>
<BR>
<A HREF="#back-meta Configuration">11.4.2. back-meta Configuration</A>
<BR>
<A HREF="#Further Information">11.4.3. Further Information</A></UL>
<BR>
<A HREF="#Monitor">11.5. Monitor</A><UL>
<A HREF="#Overview">11.5.1. Overview</A>
<BR>
<A HREF="#back-monitor Configuration">11.5.2. back-monitor Configuration</A>
<BR>
<A HREF="#Further Information">11.5.3. Further Information</A></UL>
<BR>
<A HREF="#Null">11.6. Null</A><UL>
<A HREF="#Overview">11.6.1. Overview</A>
<BR>
<A HREF="#back-null Configuration">11.6.2. back-null Configuration</A>
<BR>
<A HREF="#Further Information">11.6.3. Further Information</A></UL>
<BR>
<A HREF="#Passwd">11.7. Passwd</A><UL>
<A HREF="#Overview">11.7.1. Overview</A>
<BR>
<A HREF="#back-passwd Configuration">11.7.2. back-passwd Configuration</A>
<BR>
<A HREF="#Further Information">11.7.3. Further Information</A></UL>
<BR>
<A HREF="#Perl">11.8. Perl</A><UL>
<A HREF="#Overview">11.8.1. Overview</A>
<BR>
<A HREF="#back-perl Configuration">11.8.2. back-perl Configuration</A>
<BR>
<A HREF="#Further Information">11.8.3. Further Information</A></UL>
<BR>
<A HREF="#Relay">11.9. Relay</A><UL>
<A HREF="#Overview">11.9.1. Overview</A>
<BR>
<A HREF="#back-relay Configuration">11.9.2. back-relay Configuration</A>
<BR>
<A HREF="#Further Information">11.9.3. Further Information</A></UL>
<BR>
<A HREF="#SQL">11.10. SQL</A><UL>
<A HREF="#Overview">11.10.1. Overview</A>
<BR>
<A HREF="#back-sql Configuration">11.10.2. back-sql Configuration</A>
<BR>
<A HREF="#Further Information">11.10.3. Further Information</A></UL></UL>
<BR>
<A HREF="#Overlays">12. Overlays</A><UL>
<A HREF="#Access Logging">12.1. Access Logging</A><UL>
<A HREF="#Overview">12.1.1. Overview</A>
<BR>
<A HREF="#Access Logging Configuration">12.1.2. Access Logging Configuration</A>
<BR>
<A HREF="#Further Information">12.1.3. Further Information</A></UL>
<BR>
<A HREF="#Audit Logging">12.2. Audit Logging</A><UL>
<A HREF="#Overview">12.2.1. Overview</A>
<BR>
<A HREF="#Audit Logging Configuration">12.2.2. Audit Logging Configuration</A>
<BR>
<A HREF="#Further Information">12.2.3. Further Information</A></UL>
<BR>
<A HREF="#Chaining">12.3. Chaining</A><UL>
<A HREF="#Overview">12.3.1. Overview</A>
<BR>
<A HREF="#Chaining Configuration">12.3.2. Chaining Configuration</A>
<BR>
<A HREF="#Handling Chaining Errors">12.3.3. Handling Chaining Errors</A>
<BR>
<A HREF="#Read-Back of Chained Modifications">12.3.4. Read-Back of Chained Modifications</A>
<BR>
<A HREF="#Further Information">12.3.5. Further Information</A></UL>
<BR>
<A HREF="#Constraints">12.4. Constraints</A><UL>
<A HREF="#Overview">12.4.1. Overview</A>
<BR>
<A HREF="#Constraint Configuration">12.4.2. Constraint Configuration</A>
<BR>
<A HREF="#Further Information">12.4.3. Further Information</A></UL>
<BR>
<A HREF="#Dynamic Directory Services">12.5. Dynamic Directory Services</A><UL>
<A HREF="#Overview">12.5.1. Overview</A>
<BR>
<A HREF="#Dynamic Directory Service Configuration">12.5.2. Dynamic Directory Service Configuration</A>
<BR>
<A HREF="#Further Information">12.5.3. Further Information</A></UL>
<BR>
<A HREF="#Dynamic Groups">12.6. Dynamic Groups</A><UL>
<A HREF="#Overview">12.6.1. Overview</A>
<BR>
<A HREF="#Dynamic Group Configuration">12.6.2. Dynamic Group Configuration</A></UL>
<BR>
<A HREF="#Dynamic Lists">12.7. Dynamic Lists</A><UL>
<A HREF="#Overview">12.7.1. Overview</A>
<BR>
<A HREF="#Dynamic List Configuration">12.7.2. Dynamic List Configuration</A>
<BR>
<A HREF="#Further Information">12.7.3. Further Information</A></UL>
<BR>
<A HREF="#Reverse Group Membership Maintenance">12.8. Reverse Group Membership Maintenance</A><UL>
<A HREF="#Overview">12.8.1. Overview</A>
<BR>
<A HREF="#Member Of Configuration">12.8.2. Member Of Configuration</A>
<BR>
<A HREF="#Further Information">12.8.3. Further Information</A></UL>
<BR>
<A HREF="#The Proxy Cache Engine">12.9. The Proxy Cache Engine</A><UL>
<A HREF="#Overview">12.9.1. Overview</A>
<BR>
<A HREF="#Proxy Cache Configuration">12.9.2. Proxy Cache Configuration</A>
<BR>
<A HREF="#Further Information">12.9.3. Further Information</A></UL>
<BR>
<A HREF="#Password Policies">12.10. Password Policies</A><UL>
<A HREF="#Overview">12.10.1. Overview</A>
<BR>
<A HREF="#Password Policy Configuration">12.10.2. Password Policy Configuration</A>
<BR>
<A HREF="#Further Information">12.10.3. Further Information</A></UL>
<BR>
<A HREF="#Referential Integrity">12.11. Referential Integrity</A><UL>
<A HREF="#Overview">12.11.1. Overview</A>
<BR>
<A HREF="#Referential Integrity Configuration">12.11.2. Referential Integrity Configuration</A>
<BR>
<A HREF="#Further Information">12.11.3. Further Information</A></UL>
<BR>
<A HREF="#Return Code">12.12. Return Code</A><UL>
<A HREF="#Overview">12.12.1. Overview</A>
<BR>
<A HREF="#Return Code Configuration">12.12.2. Return Code Configuration</A>
<BR>
<A HREF="#Further Information">12.12.3. Further Information</A></UL>
<BR>
<A HREF="#Rewrite/Remap">12.13. Rewrite/Remap</A><UL>
<A HREF="#Overview">12.13.1. Overview</A>
<BR>
<A HREF="#Rewrite/Remap Configuration">12.13.2. Rewrite/Remap Configuration</A>
<BR>
<A HREF="#Further Information">12.13.3. Further Information</A></UL>
<BR>
<A HREF="#Sync Provider">12.14. Sync Provider</A><UL>
<A HREF="#Overview">12.14.1. Overview</A>
<BR>
<A HREF="#Sync Provider Configuration">12.14.2. Sync Provider Configuration</A>
<BR>
<A HREF="#Further Information">12.14.3. Further Information</A></UL>
<BR>
<A HREF="#Translucent Proxy">12.15. Translucent Proxy</A><UL>
<A HREF="#Overview">12.15.1. Overview</A>
<BR>
<A HREF="#Translucent Proxy Configuration">12.15.2. Translucent Proxy Configuration</A>
<BR>
<A HREF="#Further Information">12.15.3. Further Information</A></UL>
<BR>
<A HREF="#Attribute Uniqueness">12.16. Attribute Uniqueness</A><UL>
<A HREF="#Overview">12.16.1. Overview</A>
<BR>
<A HREF="#Attribute Uniqueness Configuration">12.16.2. Attribute Uniqueness Configuration</A>
<BR>
<A HREF="#Further Information">12.16.3. Further Information</A></UL>
<BR>
<A HREF="#Value Sorting">12.17. Value Sorting</A><UL>
<A HREF="#Overview">12.17.1. Overview</A>
<BR>
<A HREF="#Value Sorting Configuration">12.17.2. Value Sorting Configuration</A>
<BR>
<A HREF="#Further Information">12.17.3. Further Information</A></UL>
<BR>
<A HREF="#Overlay Stacking">12.18. Overlay Stacking</A><UL>
<A HREF="#Overview">12.18.1. Overview</A>
<BR>
<A HREF="#Example Scenarios">12.18.2. Example Scenarios</A></UL></UL>
<BR>
<A HREF="#Schema Specification">13. Schema Specification</A><UL>
<A HREF="#Distributed Schema Files">13.1. Distributed Schema Files</A>
<BR>
<A HREF="#Extending Schema">13.2. Extending Schema</A><UL>
<A HREF="#Object Identifiers">13.2.1. Object Identifiers</A>
<BR>
<A HREF="#Naming Elements">13.2.2. Naming Elements</A>
<BR>
<A HREF="#Local schema file">13.2.3. Local schema file</A>
<BR>
<A HREF="#Attribute Type Specification">13.2.4. Attribute Type Specification</A>
<BR>
<A HREF="#Object Class Specification">13.2.5. Object Class Specification</A>
<BR>
<A HREF="#OID Macros">13.2.6. OID Macros</A></UL></UL>
<BR>
<A HREF="#Security Considerations">14. Security Considerations</A><UL>
<A HREF="#Network Security">14.1. Network Security</A><UL>
<A HREF="#Selective Listening">14.1.1. Selective Listening</A>
<BR>
<A HREF="#IP Firewall">14.1.2. IP Firewall</A>
<BR>
<A HREF="#TCP Wrappers">14.1.3. TCP Wrappers</A></UL>
<BR>
<A HREF="#Data Integrity and Confidentiality Protection">14.2. Data Integrity and Confidentiality Protection</A><UL>
<A HREF="#Security Strength Factors">14.2.1. Security Strength Factors</A></UL>
<BR>
<A HREF="#Authentication Methods">14.3. Authentication Methods</A><UL>
<A HREF="#&quot;simple&quot; method">14.3.1. &quot;simple&quot; method</A>
<BR>
<A HREF="#SASL method">14.3.2. SASL method</A></UL>
<BR>
<A HREF="#Password Storage">14.4. Password Storage</A><UL>
<A HREF="#SSHA password storage scheme">14.4.1. SSHA password storage scheme</A>
<BR>
<A HREF="#CRYPT password storage scheme">14.4.2. CRYPT password storage scheme</A>
<BR>
<A HREF="#MD5 password storage scheme">14.4.3. MD5 password storage scheme</A>
<BR>
<A HREF="#SMD5 password storage scheme">14.4.4. SMD5 password storage scheme</A>
<BR>
<A HREF="#SHA password storage scheme">14.4.5. SHA password storage scheme</A>
<BR>
<A HREF="#SASL password storage scheme">14.4.6. SASL password storage scheme</A></UL>
<BR>
<A HREF="#Pass-Through authentication">14.5. Pass-Through authentication</A><UL>
<A HREF="#Configuring slapd to use an authentication provider">14.5.1. Configuring slapd to use an authentication provider</A>
<BR>
<A HREF="#Configuring saslauthd">14.5.2. Configuring saslauthd</A>
<BR>
<A HREF="#Testing pass-through authentication">14.5.3. Testing pass-through authentication</A></UL></UL>
<BR>
<A HREF="#Using SASL">15. Using SASL</A><UL>
<A HREF="#SASL Security Considerations">15.1. SASL Security Considerations</A>
<BR>
<A HREF="#SASL Authentication">15.2. SASL Authentication</A><UL>
<A HREF="#GSSAPI">15.2.1. GSSAPI</A>
<BR>
<A HREF="#KERBEROS_V4">15.2.2. KERBEROS_V4</A>
<BR>
<A HREF="#DIGEST-MD5">15.2.3. DIGEST-MD5</A>
<BR>
<A HREF="#EXTERNAL">15.2.4. EXTERNAL</A>
<BR>
<A HREF="#Mapping Authentication Identities">15.2.5. Mapping Authentication Identities</A>
<BR>
<A HREF="#Direct Mapping">15.2.6. Direct Mapping</A>
<BR>
<A HREF="#Search-based mappings">15.2.7. Search-based mappings</A></UL>
<BR>
<A HREF="#SASL Proxy Authorization">15.3. SASL Proxy Authorization</A><UL>
<A HREF="#Uses of Proxy Authorization">15.3.1. Uses of Proxy Authorization</A>
<BR>
<A HREF="#SASL Authorization Identities">15.3.2. SASL Authorization Identities</A>
<BR>
<A HREF="#Proxy Authorization Rules">15.3.3. Proxy Authorization Rules</A></UL></UL>
<BR>
<A HREF="#Using TLS">16. Using TLS</A><UL>
<A HREF="#TLS Certificates">16.1. TLS Certificates</A><UL>
<A HREF="#Server Certificates">16.1.1. Server Certificates</A>
<BR>
<A HREF="#Client Certificates">16.1.2. Client Certificates</A></UL>
<BR>
<A HREF="#TLS Configuration">16.2. TLS Configuration</A><UL>
<A HREF="#Server Configuration">16.2.1. Server Configuration</A>
<BR>
<A HREF="#Client Configuration">16.2.2. Client Configuration</A></UL></UL>
<BR>
<A HREF="#Constructing a Distributed Directory Service">17. Constructing a Distributed Directory Service</A><UL>
<A HREF="#Subordinate Knowledge Information">17.1. Subordinate Knowledge Information</A>
<BR>
<A HREF="#Superior Knowledge Information">17.2. Superior Knowledge Information</A>
<BR>
<A HREF="#The ManageDsaIT Control">17.3. The ManageDsaIT Control</A></UL>
<BR>
<A HREF="#Replication">18. Replication</A><UL>
<A HREF="#Replication Technology">18.1. Replication Technology</A><UL>
<A HREF="#LDAP Sync Replication">18.1.1. LDAP Sync Replication</A></UL>
<BR>
<A HREF="#Deployment Alternatives">18.2. Deployment Alternatives</A><UL>
<A HREF="#Delta-syncrepl replication">18.2.1. Delta-syncrepl replication</A>
<BR>
<A HREF="#N-Way Multi-Provider Replication">18.2.2. N-Way Multi-Provider Replication</A>
<BR>
<A HREF="#Mirror mode replication">18.2.3. Mirror mode replication</A>
<BR>
<A HREF="#Syncrepl Proxy Mode">18.2.4. Syncrepl Proxy Mode</A></UL>
<BR>
<A HREF="#Configuring the different replication types">18.3. Configuring the different replication types</A><UL>
<A HREF="#Syncrepl">18.3.1. Syncrepl</A>
<BR>
<A HREF="#Delta-syncrepl">18.3.2. Delta-syncrepl</A>
<BR>
<A HREF="#N-Way Multi-Provider">18.3.3. N-Way Multi-Provider</A>
<BR>
<A HREF="#Mirror mode">18.3.4. Mirror mode</A>
<BR>
<A HREF="#Syncrepl Proxy">18.3.5. Syncrepl Proxy</A></UL></UL>
<BR>
<A HREF="#Maintenance">19. Maintenance</A><UL>
<A HREF="#Directory Backups">19.1. Directory Backups</A>
<BR>
<A HREF="#Checkpointing">19.2. Checkpointing</A>
<BR>
<A HREF="#Migration">19.3. Migration</A></UL>
<BR>
<A HREF="#Monitoring">20. Monitoring</A><UL>
<A HREF="#Monitor configuration via cn=config(5)">20.1. Monitor configuration via cn=config(5)</A>
<BR>
<A HREF="#Monitor configuration via slapd.conf(5)">20.2. Monitor configuration via slapd.conf(5)</A>
<BR>
<A HREF="#Accessing Monitoring Information">20.3. Accessing Monitoring Information</A>
<BR>
<A HREF="#Monitor Information">20.4. Monitor Information</A><UL>
<A HREF="#Backends">20.4.1. Backends</A>
<BR>
<A HREF="#Connections">20.4.2. Connections</A>
<BR>
<A HREF="#Databases">20.4.3. Databases</A>
<BR>
<A HREF="#Listener">20.4.4. Listener</A>
<BR>
<A HREF="#Log">20.4.5. Log</A>
<BR>
<A HREF="#Operations">20.4.6. Operations</A>
<BR>
<A HREF="#Overlays">20.4.7. Overlays</A>
<BR>
<A HREF="#SASL">20.4.8. SASL</A>
<BR>
<A HREF="#Statistics">20.4.9. Statistics</A>
<BR>
<A HREF="#Threads">20.4.10. Threads</A>
<BR>
<A HREF="#Time">20.4.11. Time</A>
<BR>
<A HREF="#TLS">20.4.12. TLS</A>
<BR>
<A HREF="#Waiters">20.4.13. Waiters</A></UL></UL>
<BR>
<A HREF="#Tuning">21. Tuning</A><UL>
<A HREF="#Performance Factors">21.1. Performance Factors</A><UL>
<A HREF="#Memory">21.1.1. Memory</A>
<BR>
<A HREF="#Disks">21.1.2. Disks</A>
<BR>
<A HREF="#Network Topology">21.1.3. Network Topology</A>
<BR>
<A HREF="#Directory Layout Design">21.1.4. Directory Layout Design</A>
<BR>
<A HREF="#Expected Usage">21.1.5. Expected Usage</A></UL>
<BR>
<A HREF="#Indexes">21.2. Indexes</A><UL>
<A HREF="#Understanding how a search works">21.2.1. Understanding how a search works</A>
<BR>
<A HREF="#What to index">21.2.2. What to index</A>
<BR>
<A HREF="#Presence indexing">21.2.3. Presence indexing</A>
<BR>
<A HREF="#Equality indexing">21.2.4. Equality indexing</A>
<BR>
<A HREF="#Substring indexing">21.2.5. Substring indexing</A></UL>
<BR>
<A HREF="#Logging">21.3. Logging</A><UL>
<A HREF="#What log level to use">21.3.1. What log level to use</A>
<BR>
<A HREF="#What to watch out for">21.3.2. What to watch out for</A>
<BR>
<A HREF="#Improving throughput">21.3.3. Improving throughput</A></UL>
<BR>
<A HREF="#{{slapd}}(8) Threads">21.4. <EM>slapd</EM>(8) Threads</A></UL>
<BR>
<A HREF="#Troubleshooting">22. Troubleshooting</A><UL>
<A HREF="#User or Software errors">22.1. User or Software errors?</A>
<BR>
<A HREF="#Checklist">22.2. Checklist</A>
<BR>
<A HREF="#OpenLDAP Bugs">22.3. OpenLDAP Bugs</A>
<BR>
<A HREF="#3rd party software error">22.4. 3rd party software error</A>
<BR>
<A HREF="#How to contact the OpenLDAP Project">22.5. How to contact the OpenLDAP Project</A>
<BR>
<A HREF="#How to present your problem">22.6. How to present your problem</A>
<BR>
<A HREF="#Debugging {{slapd}}(8)">22.7. Debugging <EM>slapd</EM>(8)</A>
<BR>
<A HREF="#Commercial Support">22.8. Commercial Support</A></UL>
<BR>
<A HREF="#Changes Since Previous Release">A. Changes Since Previous Release</A><UL>
<A HREF="#New Guide Sections">A.1. New Guide Sections</A>
<BR>
<A HREF="#New Features and Enhancements in 2.5">A.2. New Features and Enhancements in 2.5</A><UL>
<A HREF="#Better {{B:cn=config}} functionality">A.2.1. Better <B>cn=config</B> functionality</A>
<BR>
<A HREF="#Better {{B:cn=schema}} functionality">A.2.2. Better <B>cn=schema</B> functionality</A>
<BR>
<A HREF="#More sophisticated Syncrepl configurations">A.2.3. More sophisticated Syncrepl configurations</A>
<BR>
<A HREF="#Replicating {{slapd}} Configuration (syncrepl and {{B:cn=config}})">A.2.4. Replicating <EM>slapd</EM> Configuration (syncrepl and <B>cn=config</B>)</A>
<BR>
<A HREF="#More extensive TLS configuration control">A.2.5. More extensive TLS configuration control</A>
<BR>
<A HREF="#Performance enhancements">A.2.6. Performance enhancements</A>
<BR>
<A HREF="#New overlays">A.2.7. New overlays</A>
<BR>
<A HREF="#New features in existing Overlays">A.2.8. New features in existing Overlays</A>
<BR>
<A HREF="#New features in slapd">A.2.9. New features in slapd</A>
<BR>
<A HREF="#New features in libldap">A.2.10. New features in libldap</A>
<BR>
<A HREF="#New clients, tools and tool enhancements">A.2.11. New clients, tools and tool enhancements</A>
<BR>
<A HREF="#New build options">A.2.12. New build options</A></UL>
<BR>
<A HREF="#Obsolete Features Removed From 2.5">A.3. Obsolete Features Removed From 2.5</A><UL>
<A HREF="#back-bdb and back-hdb">A.3.1. back-bdb and back-hdb</A></UL></UL>
<BR>
<A HREF="#Upgrading from 2.4.x">B. Upgrading from 2.4.x</A><UL>
<A HREF="#{{B:cn=config}} olc* attributes">B.1. <B>cn=config</B> olc* attributes</A>
<BR>
<A HREF="#ppolicy overlay">B.2. ppolicy overlay</A>
<BR>
<A HREF="#unique overlay">B.3. unique overlay</A>
<BR>
<A HREF="#ldap and meta backends">B.4. ldap and meta backends</A>
<BR>
<A HREF="#shell backend">B.5. shell backend</A>
<BR>
<A HREF="#perl and sql backends">B.6. perl and sql backends</A>
<BR>
<A HREF="#hdb and bdb backends">B.7. hdb and bdb backends</A>
<BR>
<A HREF="#mdb backend">B.8. mdb backend</A></UL>
<BR>
<A HREF="#Common errors encountered when using OpenLDAP Software">C. Common errors encountered when using OpenLDAP Software</A><UL>
<A HREF="#Common causes of LDAP errors">C.1. Common causes of LDAP errors</A><UL>
<A HREF="#ldap_*: Can\'t contact LDAP server">C.1.1. ldap_*: Can't contact LDAP server</A>
<BR>
<A HREF="#ldap_*: No such object">C.1.2. ldap_*: No such object</A>
<BR>
<A HREF="#ldap_*: Can\'t chase referral">C.1.3. ldap_*: Can't chase referral</A>
<BR>
<A HREF="#ldap_*: server is unwilling to perform">C.1.4. ldap_*: server is unwilling to perform</A>
<BR>
<A HREF="#ldap_*: Insufficient access">C.1.5. ldap_*: Insufficient access</A>
<BR>
<A HREF="#ldap_*: Invalid DN syntax">C.1.6. ldap_*: Invalid DN syntax</A>
<BR>
<A HREF="#ldap_*: Referral hop limit exceeded">C.1.7. ldap_*: Referral hop limit exceeded</A>
<BR>
<A HREF="#ldap_*: operations error">C.1.8. ldap_*: operations error</A>
<BR>
<A HREF="#ldap_*: other error">C.1.9. ldap_*: other error</A>
<BR>
<A HREF="#ldap_add/modify: Invalid syntax">C.1.10. ldap_add/modify: Invalid syntax</A>
<BR>
<A HREF="#ldap_add/modify: Object class violation">C.1.11. ldap_add/modify: Object class violation</A>
<BR>
<A HREF="#ldap_add: No such object">C.1.12. ldap_add: No such object</A>
<BR>
<A HREF="#ldap add: invalid structural object class chain">C.1.13. ldap add: invalid structural object class chain</A>
<BR>
<A HREF="#ldap_add: no structuralObjectClass operational attribute">C.1.14. ldap_add: no structuralObjectClass operational attribute</A>
<BR>
<A HREF="#ldap_add/modify/rename: Naming violation">C.1.15. ldap_add/modify/rename: Naming violation</A>
<BR>
<A HREF="#ldap_add/delete/modify/rename: no global superior knowledge">C.1.16. ldap_add/delete/modify/rename: no global superior knowledge</A>
<BR>
<A HREF="#ldap_bind: Insufficient access">C.1.17. ldap_bind: Insufficient access</A>
<BR>
<A HREF="#ldap_bind: Invalid credentials">C.1.18. ldap_bind: Invalid credentials</A>
<BR>
<A HREF="#ldap_bind: Protocol error">C.1.19. ldap_bind: Protocol error</A>
<BR>
<A HREF="#ldap_modify: cannot modify object class">C.1.20. ldap_modify: cannot modify object class</A>
<BR>
<A HREF="#ldap_sasl_interactive_bind_s: ..">C.1.21. ldap_sasl_interactive_bind_s: ...</A>
<BR>
<A HREF="#ldap_sasl_interactive_bind_s: No such Object">C.1.22. ldap_sasl_interactive_bind_s: No such Object</A>
<BR>
<A HREF="#ldap_sasl_interactive_bind_s: No such attribute">C.1.23. ldap_sasl_interactive_bind_s: No such attribute</A>
<BR>
<A HREF="#ldap_sasl_interactive_bind_s: Unknown authentication method">C.1.24. ldap_sasl_interactive_bind_s: Unknown authentication method</A>
<BR>
<A HREF="#ldap_sasl_interactive_bind_s: Local error (82)">C.1.25. ldap_sasl_interactive_bind_s: Local error (82)</A>
<BR>
<A HREF="#ldap_search: Partial results and referral received">C.1.26. ldap_search: Partial results and referral received</A>
<BR>
<A HREF="#ldap_start_tls: Operations error">C.1.27. ldap_start_tls: Operations error</A></UL>
<BR>
<A HREF="#Other Errors">C.2. Other Errors</A><UL>
<A HREF="#ber_get_next on fd X failed errno=34 (Numerical result out of range)">C.2.1. ber_get_next on fd X failed errno=34 (Numerical result out of range)</A>
<BR>
<A HREF="#ber_get_next on fd X failed errno=11 (Resource temporarily unavailable)">C.2.2. ber_get_next on fd X failed errno=11 (Resource temporarily unavailable)</A>
<BR>
<A HREF="#daemon: socket() failed errno=97 (Address family not supported)">C.2.3. daemon: socket() failed errno=97 (Address family not supported)</A>
<BR>
<A HREF="#GSSAPI: gss_acquire_cred: Miscellaneous failure; Permission denied;">C.2.4. GSSAPI: gss_acquire_cred: Miscellaneous failure; Permission denied;</A>
<BR>
<A HREF="#access from unknown denied">C.2.5. access from unknown denied</A>
<BR>
<A HREF="#ldap_read: want=# error=Resource temporarily unavailable">C.2.6. ldap_read: want=# error=Resource temporarily unavailable</A>
<BR>
<A HREF="#`make test\' fails">C.2.7. `make test' fails</A>
<BR>
<A HREF="#ldap_*: Internal (implementation specific) error (80) - additional info: entry index delete failed">C.2.8. ldap_*: Internal (implementation specific) error (80) - additional info: entry index delete failed</A>
<BR>
<A HREF="#ldap_sasl_interactive_bind_s: Can\'t contact LDAP server (-1)">C.2.9. ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)</A></UL></UL>
<BR>
<A HREF="#Recommended OpenLDAP Software Dependency Versions">D. Recommended OpenLDAP Software Dependency Versions</A><UL>
<A HREF="#Dependency Versions">D.1. Dependency Versions</A></UL>
<BR>
<A HREF="#Real World OpenLDAP Deployments and Examples">E. Real World OpenLDAP Deployments and Examples</A>
<BR>
<A HREF="#OpenLDAP Software Contributions">F. OpenLDAP Software Contributions</A><UL>
<A HREF="#Client APIs">F.1. Client APIs</A><UL>
<A HREF="#ldapc++">F.1.1. ldapc++</A>
<BR>
<A HREF="#ldaptcl">F.1.2. ldaptcl</A></UL>
<BR>
<A HREF="#Overlays">F.2. Overlays</A><UL>
<A HREF="#acl">F.2.1. acl</A>
<BR>
<A HREF="#addpartial">F.2.2. addpartial</A>
<BR>
<A HREF="#allop">F.2.3. allop</A>
<BR>
<A HREF="#autogroup">F.2.4. autogroup</A>
<BR>
<A HREF="#comp_match">F.2.5. comp_match</A>
<BR>
<A HREF="#denyop">F.2.6. denyop</A>
<BR>
<A HREF="#dsaschema">F.2.7. dsaschema</A>
<BR>
<A HREF="#lastmod">F.2.8. lastmod</A>
<BR>
<A HREF="#nops">F.2.9. nops</A>
<BR>
<A HREF="#nssov">F.2.10. nssov</A>
<BR>
<A HREF="#passwd">F.2.11. passwd</A>
<BR>
<A HREF="#proxyOld">F.2.12. proxyOld</A>
<BR>
<A HREF="#smbk5pwd">F.2.13. smbk5pwd</A>
<BR>
<A HREF="#trace">F.2.14. trace</A>
<BR>
<A HREF="#usn">F.2.15. usn</A></UL>
<BR>
<A HREF="#Tools">F.3. Tools</A><UL>
<A HREF="#Statistic Logging">F.3.1. Statistic Logging</A></UL>
<BR>
<A HREF="#SLAPI Plugins">F.4. SLAPI Plugins</A><UL>
<A HREF="#addrdnvalues">F.4.1. addrdnvalues</A></UL></UL>
<BR>
<A HREF="#Configuration File Examples">G. Configuration File Examples</A><UL>
<A HREF="#slapd.conf">G.1. slapd.conf</A>
<BR>
<A HREF="#ldap.conf">G.2. ldap.conf</A>
<BR>
<A HREF="#a-n-other.conf">G.3. a-n-other.conf</A></UL>
<BR>
<A HREF="#LDAP Result Codes">H. LDAP Result Codes</A><UL>
<A HREF="#Non-Error Result Codes">H.1. Non-Error Result Codes</A>
<BR>
<A HREF="#Result Codes">H.2. Result Codes</A>
<BR>
<A HREF="#success (0)">H.3. success (0)</A>
<BR>
<A HREF="#operationsError (1)">H.4. operationsError (1)</A>
<BR>
<A HREF="#protocolError (2)">H.5. protocolError (2)</A>
<BR>
<A HREF="#timeLimitExceeded (3)">H.6. timeLimitExceeded (3)</A>
<BR>
<A HREF="#sizeLimitExceeded (4)">H.7. sizeLimitExceeded (4)</A>
<BR>
<A HREF="#compareFalse (5)">H.8. compareFalse (5)</A>
<BR>
<A HREF="#compareTrue (6)">H.9. compareTrue (6)</A>
<BR>
<A HREF="#authMethodNotSupported (7)">H.10. authMethodNotSupported (7)</A>
<BR>
<A HREF="#strongerAuthRequired (8)">H.11. strongerAuthRequired (8)</A>
<BR>
<A HREF="#referral (10)">H.12. referral (10)</A>
<BR>
<A HREF="#adminLimitExceeded (11)">H.13. adminLimitExceeded (11)</A>
<BR>
<A HREF="#unavailableCriticalExtension (12)">H.14. unavailableCriticalExtension (12)</A>
<BR>
<A HREF="#confidentialityRequired (13)">H.15. confidentialityRequired (13)</A>
<BR>
<A HREF="#saslBindInProgress (14)">H.16. saslBindInProgress (14)</A>
<BR>
<A HREF="#noSuchAttribute (16)">H.17. noSuchAttribute (16)</A>
<BR>
<A HREF="#undefinedAttributeType (17)">H.18. undefinedAttributeType (17)</A>
<BR>
<A HREF="#inappropriateMatching (18)">H.19. inappropriateMatching (18)</A>
<BR>
<A HREF="#constraintViolation (19)">H.20. constraintViolation (19)</A>
<BR>
<A HREF="#attributeOrValueExists (20)">H.21. attributeOrValueExists (20)</A>
<BR>
<A HREF="#invalidAttributeSyntax (21)">H.22. invalidAttributeSyntax (21)</A>
<BR>
<A HREF="#noSuchObject (32)">H.23. noSuchObject (32)</A>
<BR>
<A HREF="#aliasProblem (33)">H.24. aliasProblem (33)</A>
<BR>
<A HREF="#invalidDNSyntax (34)">H.25. invalidDNSyntax (34)</A>
<BR>
<A HREF="#aliasDereferencingProblem (36)">H.26. aliasDereferencingProblem (36)</A>
<BR>
<A HREF="#inappropriateAuthentication (48)">H.27. inappropriateAuthentication (48)</A>
<BR>
<A HREF="#invalidCredentials (49)">H.28. invalidCredentials (49)</A>
<BR>
<A HREF="#insufficientAccessRights (50)">H.29. insufficientAccessRights (50)</A>
<BR>
<A HREF="#busy (51)">H.30. busy (51)</A>
<BR>
<A HREF="#unavailable (52)">H.31. unavailable (52)</A>
<BR>
<A HREF="#unwillingToPerform (53)">H.32. unwillingToPerform (53)</A>
<BR>
<A HREF="#loopDetect (54)">H.33. loopDetect (54)</A>
<BR>
<A HREF="#namingViolation (64)">H.34. namingViolation (64)</A>
<BR>
<A HREF="#objectClassViolation (65)">H.35. objectClassViolation (65)</A>
<BR>
<A HREF="#notAllowedOnNonLeaf (66)">H.36. notAllowedOnNonLeaf (66)</A>
<BR>
<A HREF="#notAllowedOnRDN (67)">H.37. notAllowedOnRDN (67)</A>
<BR>
<A HREF="#entryAlreadyExists (68)">H.38. entryAlreadyExists (68)</A>
<BR>
<A HREF="#objectClassModsProhibited (69)">H.39. objectClassModsProhibited (69)</A>
<BR>
<A HREF="#affectsMultipleDSAs (71)">H.40. affectsMultipleDSAs (71)</A>
<BR>
<A HREF="#other (80)">H.41. other (80)</A></UL>
<BR>
<A HREF="#Glossary">I. Glossary</A><UL>
<A HREF="#Terms">I.1. Terms</A>
<BR>
<A HREF="#Related Organizations">I.2. Related Organizations</A>
<BR>
<A HREF="#Related Products">I.3. Related Products</A>
<BR>
<A HREF="#References">I.4. References</A></UL>
<BR>
<A HREF="#Generic configure Instructions">J. Generic configure Instructions</A>
<BR>
<A HREF="#OpenLDAP Software Copyright Notices">K. OpenLDAP Software Copyright Notices</A><UL>
<A HREF="#OpenLDAP Copyright Notice">K.1. OpenLDAP Copyright Notice</A>
<BR>
<A HREF="#Additional Copyright Notices">K.2. Additional Copyright Notices</A>
<BR>
<A HREF="#University of Michigan Copyright Notice">K.3. University of Michigan Copyright Notice</A></UL>
<BR>
<A HREF="#OpenLDAP Public License">L. OpenLDAP Public License</A></UL>
</DIV>
<DIV CLASS="main">
<P></P>
<HR>
<H1><A NAME="Preface">Preface</A></H1>
<H2>Copyright</H2>
<P>Copyright 1998-2013, The <A HREF="https://www.openldap.org/foundation/">OpenLDAP Foundation</A>, <EM>All Rights Reserved</EM>.</P>
<P>Copyright 1992-1996, Regents of the <A HREF="https://www.umich.edu/">University of Michigan</A>, <EM>All Rights Reserved</EM>.</P>
<P>This document is considered a part of OpenLDAP Software.  This document is subject to terms of conditions set forth in <A HREF="#OpenLDAP Software Copyright Notices">OpenLDAP Software Copyright Notices</A> and the <A HREF="#OpenLDAP Public License">OpenLDAP Public License</A>. Complete copies of the notices and associated license can be found in Appendix K and L, respectively.</P>
<P>Portions of OpenLDAP Software and this document may be copyright by other parties and/or subject to additional restrictions.  Individual source files should be consulted for additional copyright notices.</P>
<H2>Scope of this Document</H2>
<P>This document provides a guide for installing OpenLDAP Software 2.5 (<A HREF="http://www.openldap.org/software/">http://www.openldap.org/software/</A>) on <TERM>UNIX</TERM> (and UNIX-like) systems.  The document is aimed at experienced system administrators with basic understanding of <TERM>LDAP</TERM>-based directory services.</P>
<P>This document is meant to be used in conjunction with other OpenLDAP information resources provided with the software package and on the project's site (<A HREF="http://www.OpenLDAP.org/">http://www.OpenLDAP.org/</A>) on the <TERM>World Wide Web</TERM>.  The site makes available a number of resources.</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>OpenLDAP Resources</CAPTION>
<TR CLASS="heading">
<TD>
<STRONG>Resource</STRONG>
</TD>
<TD>
<STRONG>URL</STRONG>
</TD>
</TR>
<TR>
<TD>
Document Catalog
</TD>
<TD>
<A HREF="http://www.OpenLDAP.org/doc/">http://www.OpenLDAP.org/doc/</A>
</TD>
</TR>
<TR>
<TD>
Frequently Asked Questions
</TD>
<TD>
<A HREF="http://www.OpenLDAP.org/faq/">http://www.OpenLDAP.org/faq/</A>
</TD>
</TR>
<TR>
<TD>
Issue Tracking System
</TD>
<TD>
<A HREF="http://www.OpenLDAP.org/its/">http://www.OpenLDAP.org/its/</A>
</TD>
</TR>
<TR>
<TD>
Mailing Lists
</TD>
<TD>
<A HREF="http://www.OpenLDAP.org/lists/">http://www.OpenLDAP.org/lists/</A>
</TD>
</TR>
<TR>
<TD>
Manual Pages
</TD>
<TD>
<A HREF="http://www.OpenLDAP.org/software/man.cgi">http://www.OpenLDAP.org/software/man.cgi</A>
</TD>
</TR>
<TR>
<TD>
Software Pages
</TD>
<TD>
<A HREF="http://www.OpenLDAP.org/software/">http://www.OpenLDAP.org/software/</A>
</TD>
</TR>
<TR>
<TD>
Support Pages
</TD>
<TD>
<A HREF="http://www.OpenLDAP.org/support/">http://www.OpenLDAP.org/support/</A>
</TD>
</TR>
</TABLE>

<P>This document is not a complete reference for OpenLDAP software; the manual pages are the definitive documentation. For best results, you should use the manual pages that were installed on your system with your version of OpenLDAP software so that you're looking at documentation that matches the code. While the OpenLDAP web site also provides the manual pages for convenience, you can not assume that they correspond to the particular version you're running.</P>
<H2>Acknowledgments</H2>
<P>The <A HREF="https://www.openldap.org/project/">OpenLDAP Project</A> is comprised of a team of volunteers.  This document would not be possible without their contribution of time and energy.</P>
<P>The OpenLDAP Project would also like to thank the <A HREF="https://web.archive.org/web/20160302011357/http://www.umich.edu/~dirsvcs/ldap/ldap.html">University of Michigan LDAP Team</A> for building the foundation of LDAP software and information to which OpenLDAP Software is built upon.  This document is based upon University of Michigan document: <A HREF="https://web.archive.org/web/20170809071245/http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/guide.pdf">The SLAPD and SLURPD Administrators Guide</A>.</P>
<H2>Amendments</H2>
<P>Suggested enhancements and corrections to this document should be submitted using the <A HREF="https://www.openldap.org/">OpenLDAP</A> <TERM>Issue Tracking System</TERM> (<A HREF="http://www.openldap.org/its/">http://www.openldap.org/its/</A>).</P>
<H2>About this document</H2>
<P>This document was produced using the <TERM>Simple Document Format</TERM> (<TERM>SDF</TERM>) documentation system (<A HREF="http://search.cpan.org/src/IANC/sdf-2.001/doc/catalog.html">http://search.cpan.org/src/IANC/sdf-2.001/doc/catalog.html</A>) developed by <EM>Ian Clatworthy</EM>.  Tools for SDF are available from <A HREF="https://www.cpan.org/">CPAN</A> (<A HREF="http://search.cpan.org/search?query=SDF&amp;mode=dist">http://search.cpan.org/search?query=SDF&amp;mode=dist</A>).</P>
<P></P>
<HR>
<H1><A NAME="Introduction to OpenLDAP Directory Services">1. Introduction to OpenLDAP Directory Services</A></H1>
<P>This document describes how to build, configure, and operate <A HREF="https://www.openldap.org/">OpenLDAP</A> Software to provide directory services.  This includes details on how to configure and run the Standalone <TERM>LDAP</TERM> Daemon, <EM>slapd</EM>(8).  It is intended for new and experienced administrators alike.  This section provides a basic introduction to directory services and, in particular, the directory services provided by <EM>slapd</EM>(8).  This introduction is only intended to provide enough information so one might get started learning about <TERM>LDAP</TERM>, <TERM>X.500</TERM>, and directory services.</P>
<H2><A NAME="What is a directory service">1.1. What is a directory service?</A></H2>
<P>A directory is a specialized database specifically designed for searching and browsing, in additional to supporting basic lookup and update functions.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>A directory is defined by some as merely a database optimized for read access.  This definition, at best, is overly simplistic.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>Directories tend to contain descriptive, attribute-based information and support sophisticated filtering capabilities.  Directories generally do not support complicated transaction or roll-back schemes found in database management systems designed for handling high-volume complex updates.  Directory updates are typically simple all-or-nothing changes, if they are allowed at all.  Directories are generally tuned to give quick response to high-volume lookup or search operations. They may have the ability to replicate information widely in order to increase availability and reliability, while reducing response time.  When directory information is replicated, temporary inconsistencies between the consumers may be okay, as long as inconsistencies are resolved in a timely manner.</P>
<P>There are many different ways to provide a directory service. Different methods allow different kinds of information to be stored in the directory, place different requirements on how that information can be referenced, queried and updated, how it is protected from unauthorized access, etc.  Some directory services are <EM>local</EM>, providing service to a restricted context (e.g., the finger service on a single machine). Other services are global, providing service to a much broader context (e.g., the entire Internet).  Global services are usually <EM>distributed</EM>, meaning that the data they contain is spread across many machines, all of which cooperate to provide the directory service. Typically a global service defines a uniform <EM>namespace</EM> which gives the same view of the data no matter where you are in relation to the data itself.</P>
<P>A web directory, such as provided by the <EM>Curlie Project</EM> &lt;<A HREF="https://curlie.org">https://curlie.org</A>&gt;, is a good example of a directory service. These services catalog web pages and are specifically designed to support browsing and searching.</P>
<P>While some consider the Internet <TERM>Domain Name System</TERM> (DNS) is an example of a globally distributed directory service, DNS is not browsable nor searchable.  It is more properly described as a globally distributed <EM>lookup</EM> service.</P>
<H2><A NAME="What is LDAP">1.2. What is LDAP?</A></H2>
<P><TERM>LDAP</TERM> stands for <TERM>Lightweight Directory Access Protocol</TERM>.  As the name suggests, it is a lightweight protocol for accessing directory services, specifically <TERM>X.500</TERM>-based directory services.  LDAP runs over <TERM>TCP</TERM>/<TERM>IP</TERM> or other connection oriented transfer services.  LDAP is an <A HREF="https://www.ietf.org/">IETF</A> Standard Track protocol and is specified in &quot;Lightweight Directory Access Protocol (LDAP) Technical Specification Road Map&quot; <A HREF="https://www.rfc-editor.org/rfc/rfc4510.txt">RFC4510</A>.</P>
<P>This section gives an overview of LDAP from a user's perspective.</P>
<P><EM>What kind of information can be stored in the directory?</EM> The LDAP information model is based on <EM>entries</EM>. An entry is a collection of attributes that has a globally-unique <TERM>Distinguished Name</TERM> (DN).  The DN is used to refer to the entry unambiguously. Each of the entry's attributes has a <EM>type</EM> and one or more <EM>values</EM>. The types are typically mnemonic strings, like &quot;<TT>cn</TT>&quot; for common name, or &quot;<TT>mail</TT>&quot; for email address. The syntax of values depend on the attribute type.  For example, a <TT>cn</TT> attribute might contain the value <TT>Babs Jensen</TT>.  A <TT>mail</TT> attribute might contain the value &quot;<TT>babs@example.com</TT>&quot;. A <TT>jpegPhoto</TT> attribute would contain a photograph in the <TERM>JPEG</TERM> (binary) format.</P>
<P><EM>How is the information arranged?</EM> In LDAP, directory entries are arranged in a hierarchical tree-like structure.  Traditionally, this structure reflected the geographic and/or organizational boundaries.  Entries representing countries appear at the top of the tree. Below them are entries representing states and national organizations. Below them might be entries representing organizational units, people, printers, documents, or just about anything else you can think of.  Figure 1.1 shows an example LDAP directory tree using traditional naming.</P>
<P><CENTER><IMG SRC="intro_tree.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure 1.1: LDAP directory tree (traditional naming)</P>
<P>The tree may also be arranged based upon Internet domain names. This naming approach is becoming increasing popular as it allows for directory services to be located using the <EM>DNS</EM>. Figure 1.2 shows an example LDAP directory tree using domain-based naming.</P>
<P><CENTER><IMG SRC="intro_dctree.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure 1.2: LDAP directory tree (Internet naming)</P>
<P>In addition, LDAP allows you to control which attributes are required and allowed in an entry through the use of a special attribute called <TT>objectClass</TT>.  The values of the <TT>objectClass</TT> attribute determine the <EM>schema</EM> rules the entry must obey.</P>
<P><EM>How is the information referenced?</EM> An entry is referenced by its distinguished name, which is constructed by taking the name of the entry itself (called the <TERM>Relative Distinguished Name</TERM> or RDN) and concatenating the names of its ancestor entries. For example, the entry for Barbara Jensen in the Internet naming example above has an RDN of <TT>uid=babs</TT> and a DN of <TT>uid=babs,ou=People,dc=example,dc=com</TT>. The full DN format is described in <A HREF="https://www.rfc-editor.org/rfc/rfc4514.txt">RFC4514</A>, &quot;LDAP: String Representation of Distinguished Names.&quot;</P>
<P><EM>How is the information accessed?</EM> LDAP defines operations for interrogating and updating the directory.  Operations are provided for adding and deleting an entry from the directory, changing an existing entry, and changing the name of an entry. Most of the time, though, LDAP is used to search for information in the directory. The LDAP search operation allows some portion of the directory to be searched for entries that match some criteria specified by a search filter. Information can be requested from each entry that matches the criteria.</P>
<P>For example, you might want to search the entire directory subtree at and below <TT>dc=example,dc=com</TT> for people with the name <TT>Barbara Jensen</TT>, retrieving the email address of each entry found. LDAP lets you do this easily.  Or you might want to search the entries directly below the <TT>st=California,c=US</TT> entry for organizations with the string <TT>Acme</TT> in their name, and that have a fax number. LDAP lets you do this too. The next section describes in more detail what you can do with LDAP and how it might be useful to you.</P>
<P><EM>How is the information protected from unauthorized access?</EM> Some directory services provide no protection, allowing anyone to see the information. LDAP provides a mechanism for a client to authenticate, or prove its identity to a directory server, paving the way for rich access control to protect the information the server contains. LDAP also supports data security (integrity and confidentiality) services.</P>
<H2><A NAME="When should I use LDAP">1.3. When should I use LDAP?</A></H2>
<P>This is a very good question. In general, you should use a Directory server when you require data to be centrally managed, stored and accessible via standards based methods.</P>
<P>Some common examples found throughout the industry are, but not limited to:</P>
<UL>
<LI>Machine Authentication
<LI>User Authentication
<LI>User/System Groups
<LI>Address book
<LI>Organization Representation
<LI>Asset Tracking
<LI>Telephony Information Store
<LI>User resource management
<LI>E-mail address lookups
<LI>Application Configuration store
<LI>PBX Configuration store
<LI>etc.....</UL>
<P>There are various <A HREF="#Distributed Schema Files">Distributed Schema Files</A> that are standards based, but you can always create your own <A HREF="#Schema Specification">Schema Specification</A>.</P>
<P>There are always new ways to use a Directory and apply LDAP principles to address certain problems, therefore there is no simple answer to this question.</P>
<P>If in doubt, join the general LDAP forum for non-commercial discussions and information relating to LDAP at: <A HREF="http://www.umich.edu/~dirsvcs/ldap/mailinglist.html">http://www.umich.edu/~dirsvcs/ldap/mailinglist.html</A> and ask</P>
<H2><A NAME="When should I not use LDAP">1.4. When should I not use LDAP?</A></H2>
<P>When you start finding yourself bending the directory to do what you require, maybe a redesign is needed. Or if you only require one application to use and manipulate your data (for discussion of LDAP vs RDBMS, please read the <A HREF="#LDAP vs RDBMS">LDAP vs RDBMS</A> section).</P>
<P>It will become obvious when LDAP is the right tool for the job.</P>
<H2><A NAME="How does LDAP work">1.5. How does LDAP work?</A></H2>
<P>LDAP utilizes a <EM>client-server model</EM>. One or more LDAP servers contain the data making up the directory information tree (<TERM>DIT</TERM>). The client connects to servers and asks it a question.  The server responds with an answer and/or with a pointer to where the client can get additional information (typically, another LDAP server). No matter which LDAP server a client connects to, it sees the same view of the directory; a name presented to one LDAP server references the same entry it would at another LDAP server.  This is an important feature of a global directory service.</P>
<H2><A NAME="What about X.500">1.6. What about X.500?</A></H2>
<P>Technically, <TERM>LDAP</TERM> is a directory access protocol to an <TERM>X.500</TERM> directory service, the <TERM>OSI</TERM> directory service. Initially, LDAP clients accessed gateways to the X.500 directory service. This gateway ran LDAP between the client and gateway and X.500's <TERM>Directory Access Protocol</TERM> (<TERM>DAP</TERM>) between the gateway and the X.500 server.  DAP is a heavyweight protocol that operates over a full OSI protocol stack and requires a significant amount of computing resources.  LDAP is designed to operate over <TERM>TCP</TERM>/<TERM>IP</TERM> and provides most of the functionality of DAP at a much lower cost.</P>
<P>While LDAP is still used to access X.500 directory service via gateways, LDAP is now more commonly directly implemented in X.500 servers.</P>
<P>The Standalone LDAP Daemon, or <EM>slapd</EM>(8), can be viewed as a <EM>lightweight</EM> X.500 directory server.  That is, it does not implement the X.500's DAP nor does it support the complete X.500 models.</P>
<P>If you are already running a X.500 DAP service and you want to continue to do so, you can probably stop reading this guide.  This guide is all about running LDAP via <EM>slapd</EM>(8), without running X.500 DAP.  If you are not running X.500 DAP, want to stop running X.500 DAP, or have no immediate plans to run X.500 DAP, read on.</P>
<P>It is possible to replicate data from an LDAP directory server to a X.500 DAP <TERM>DSA</TERM>.  This requires an LDAP/DAP gateway. OpenLDAP Software does not include such a gateway.</P>
<H2><A NAME="What is the difference between LDAPv2 and LDAPv3">1.7. What is the difference between LDAPv2 and LDAPv3?</A></H2>
<P>LDAPv3 was developed in the late 1990's to replace LDAPv2. LDAPv3 adds the following features to LDAP:</P>
<UL>
<LI>Strong authentication and data security services via <TERM>SASL</TERM>
<LI>Certificate authentication and data security services via <TERM>TLS</TERM> (SSL)
<LI>Internationalization through the use of Unicode
<LI>Referrals and Continuations
<LI>Schema Discovery
<LI>Extensibility (controls, extended operations, and more)</UL>
<P>LDAPv2 is historic (<A HREF="https://www.rfc-editor.org/rfc/rfc3494.txt">RFC3494</A>).  As most <EM>so-called</EM> LDAPv2 implementations (including <EM>slapd</EM>(8)) do not conform to the LDAPv2 technical specification, interoperability amongst implementations claiming LDAPv2 support is limited.  As LDAPv2 differs significantly from LDAPv3, deploying both LDAPv2 and LDAPv3 simultaneously is quite problematic.  LDAPv2 should be avoided. LDAPv2 is disabled by default.</P>
<H2><A NAME="LDAP vs RDBMS">1.8. LDAP vs RDBMS</A></H2>
<P>This question is raised many times, in different forms. The most common, however, is: <EM>Why doesn't OpenLDAP use a relational database management system (RDBMS) instead of an embedded key/value store like LMDB?</EM> In general, expecting that the sophisticated algorithms implemented by commercial-grade RDBMS would make <EM>OpenLDAP</EM> be faster or somehow better and, at the same time, permitting sharing of data with other applications.</P>
<P>The short answer is that use of an embedded database and custom indexing system allows OpenLDAP to provide greater performance and scalability without loss of reliability. OpenLDAP uses <TERM>LMDB</TERM> concurrent / transactional database software.</P>
<P>Now for the long answer. We are all confronted all the time with the choice RDBMSes vs. directories. It is a hard choice and no simple answer exists.</P>
<P>It is tempting to think that having a RDBMS backend to the directory solves all problems. However, it is a pig. This is because the data models are very different. Representing directory data with a relational database is going to require splitting data into multiple tables.</P>
<P>Think for a moment about the person objectclass. Its definition requires attribute types objectclass, sn and cn and allows attribute types userPassword, telephoneNumber, seeAlso and description. All of these attributes are multivalued, so a normalization requires putting each attribute type in a separate table.</P>
<P>Now you have to decide on appropriate keys for those tables. The primary key might be a combination of the DN, but this becomes rather inefficient on most database implementations.</P>
<P>The big problem now is that accessing data from one entry requires seeking on different disk areas. On some applications this may be OK but in many applications performance suffers.</P>
<P>The only attribute types that can be put in the main table entry are those that are mandatory and single-value. You may add also the optional single-valued attributes and set them to NULL or something if not present.</P>
<P>But wait, the entry can have multiple objectclasses and they are organized in an inheritance hierarchy. An entry of objectclass organizationalPerson now has the attributes from person plus a few others and some formerly optional attribute types are now mandatory.</P>
<P>What to do? Should we have different tables for the different objectclasses? This way the person would have an entry on the person table, another on organizationalPerson, etc. Or should we get rid of person and put everything on the second table?</P>
<P>But what do we do with a filter like (cn=*) where cn is an attribute type that appears in many, many objectclasses. Should we search all possible tables for matching entries? Not very attractive.</P>
<P>Once this point is reached, three approaches come to mind. One is to do full normalization so that each attribute type, no matter what, has its own separate table. The simplistic approach where the DN is part of the primary key is extremely wasteful, and calls for an approach where the entry has a unique numeric id that is used instead for the keys and a main table that maps DNs to ids. The approach, anyway, is very inefficient when several attribute types from one or more entries are requested. Such a database, though cumbersomely, can be managed from SQL applications.</P>
<P>The second approach is to put the whole entry as a blob in a table shared by all entries regardless of the objectclass and have additional tables that act as indices for the first table. Index tables are not database indices, but are fully managed by the LDAP server-side implementation. However, the database becomes unusable from SQL. And, thus, a fully fledged database system provides little or no advantage. The full generality of the database is unneeded. Much better to use something light and fast, like <TERM>LMDB</TERM>.</P>
<P>A completely different way to see this is to give up any hopes of implementing the directory data model. In this case, LDAP is used as an access protocol to data that provides only superficially the directory data model. For instance, it may be read only or, where updates are allowed, restrictions are applied, such as making single-value attribute types that would allow for multiple values. Or the impossibility to add new objectclasses to an existing entry or remove one of those present. The restrictions span the range from allowed restrictions (that might be elsewhere the result of access control) to outright violations of the data model. It can be, however, a method to provide LDAP access to preexisting data that is used by other applications. But in the understanding that we don't really have a &quot;directory&quot;.</P>
<P>Existing commercial LDAP server implementations that use a relational database are either from the first kind or the third. I don't know of any implementation that uses a relational database to do inefficiently what LMDB does efficiently. For those who are interested in &quot;third way&quot; (exposing EXISTING data from RDBMS as LDAP tree, having some limitations compared to classic LDAP model, but making it possible to interoperate between LDAP and SQL applications):</P>
<P>OpenLDAP includes back-sql - the backend that makes it possible. It uses ODBC + additional metainformation about translating LDAP queries to SQL queries in your RDBMS schema, providing different levels of access - from read-only to full access depending on RDBMS you use, and your schema.</P>
<P>For more information on concept and limitations, see <EM>slapd-sql</EM>(5) man page, or the <A HREF="#Backends">Backends</A> section. There are also several examples for several RDBMSes in <TT>back-sql/rdbms_depend/*</TT> subdirectories.</P>
<H2><A NAME="What is slapd and what can it do">1.9. What is slapd and what can it do?</A></H2>
<P><EM>slapd</EM>(8) is an LDAP directory server that runs on many different platforms. You can use it to provide a directory service of your very own.  Your directory can contain pretty much anything you want to put in it. You can connect it to the global LDAP directory service, or run a service all by yourself. Some of slapd's more interesting features and capabilities include:</P>
<P><B>LDAPv3</B>: <EM>slapd</EM> implements version 3 of <TERM>Lightweight Directory Access Protocol</TERM>. <EM>slapd</EM> supports LDAP over both <TERM>IPv4</TERM> and <TERM>IPv6</TERM> and Unix <TERM>IPC</TERM>.</P>
<P><B><TERM>Simple Authentication and Security Layer</TERM></B>: <EM>slapd</EM> supports strong authentication and data security (integrity and confidentiality) services through the use of SASL.  <EM>slapd</EM>'s SASL implementation utilizes <A HREF="https://www.cyrusimap.org/sasl/">Cyrus SASL</A> software which supports a number of mechanisms including <TERM>DIGEST-MD5</TERM>, <TERM>EXTERNAL</TERM>, and <TERM>GSSAPI</TERM>.</P>
<P><B><TERM>Transport Layer Security</TERM></B>: <EM>slapd</EM> supports certificate-based authentication and data security (integrity and confidentiality) services through the use of TLS (or SSL).  <EM>slapd</EM>'s TLS implementation can utilize <A HREF="https://www.openssl.org/">OpenSSL</A> or <A HREF="https://gnutls.org/">GnuTLS</A>, software.</P>
<P><B>Topology control</B>: <EM>slapd</EM> can be configured to restrict access at the socket layer based upon network topology information. This feature utilizes <EM>TCP wrappers</EM>.</P>
<P><B>Access control</B>: <EM>slapd</EM> provides a rich and powerful access control facility, allowing you to control access to the information in your database(s). You can control access to entries based on LDAP authorization information, <TERM>IP</TERM> address, domain name and other criteria.  <EM>slapd</EM> supports both <EM>static</EM> and <EM>dynamic</EM> access control information.</P>
<P><B>Internationalization</B>: <EM>slapd</EM> supports Unicode and language tags.</P>
<P><B>Choice of database backends</B>: <EM>slapd</EM> comes with a variety of different database backends you can choose from. They include <TERM>MDB</TERM>, a hierarchical high-performance transactional database backend; and PASSWD, a simple backend interface to the <EM>passwd</EM>(5) file. The MDB backend utilizes <TERM>LMDB</TERM>.</P>
<P><B>Multiple database instances</B>: <EM>slapd</EM> can be configured to serve multiple databases at the same time. This means that a single <EM>slapd</EM> server can respond to requests for many logically different portions of the LDAP tree, using the same or different database backends.</P>
<P><B>Generic modules API</B>:  If you require even more customization, <EM>slapd</EM> lets you write your own modules easily. <EM>slapd</EM> consists of two distinct parts: a front end that handles protocol communication with LDAP clients; and modules which handle specific tasks such as database operations.  Because these two pieces communicate via a well-defined <TERM>C</TERM> <TERM>API</TERM>, you can write your own customized modules which extend <EM>slapd</EM> in numerous ways.  Also, a number of <EM>programmable database</EM> modules are provided.  These allow you to expose external data sources to <EM>slapd</EM> using popular programming languages (<A HREF="https://www.perl.org/">Perl</A>, and <TERM>SQL</TERM>).</P>
<P><B>Threads</B>: <EM>slapd</EM> is threaded for high performance.  A single multi-threaded <EM>slapd</EM> process handles all incoming requests using a pool of threads.  This reduces the amount of system overhead required while providing high performance.</P>
<P><B>Replication</B>: <EM>slapd</EM> can be configured to maintain shadow copies of directory information.  This <EM>single-provider/multiple-consumer</EM> replication scheme is vital in high-volume environments where a single <EM>slapd</EM> installation just doesn't provide the necessary availability or reliability.  For extremely demanding environments where a single point of failure is not acceptable, <EM>multi-provider</EM> replication is also available. With <EM>multi-provider</EM> replication two or more nodes can accept write operations allowing for redundancy at the provider level.</P>
<P><EM>slapd</EM> includes support for <EM>LDAP Sync</EM>-based replication.</P>
<P><B>Proxy Cache</B>: <EM>slapd</EM> can be configured as a caching LDAP proxy service.</P>
<P><B>Configuration</B>: <EM>slapd</EM> is highly configurable through a single configuration file which allows you to change just about everything you'd ever want to change.  Configuration options have reasonable defaults, making your job much easier. Configuration can also be performed dynamically using LDAP itself, which greatly improves manageability.</P>
<P></P>
<HR>
<H1><A NAME="A Quick-Start Guide">2. A Quick-Start Guide</A></H1>
<P>The following is a quick start guide to OpenLDAP Software 2.5, including the Standalone <TERM>LDAP</TERM> Daemon, <EM>slapd</EM>(8).</P>
<P>It is meant to walk you through the basic steps needed to install and configure <A HREF="https://www.openldap.org/software/">OpenLDAP Software</A>.  It should be used in conjunction with the other chapters of this document, manual pages, and other materials provided with the distribution (e.g. the <TT>INSTALL</TT> document) or on the <A HREF="https://www.openldap.org/">OpenLDAP</A> web site (<A HREF="http://www.OpenLDAP.org">http://www.OpenLDAP.org</A>), in particular the OpenLDAP Software <TERM>FAQ</TERM> (<A HREF="http://www.OpenLDAP.org/faq/?file=2">http://www.OpenLDAP.org/faq/?file=2</A>).</P>
<P>If you intend to run OpenLDAP Software seriously, you should review all of this document before attempting to install the software.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>This quick start guide does not use strong authentication nor any integrity or confidential protection services.  These services are described in other chapters of the OpenLDAP Administrator's Guide.
<HR WIDTH="80%" ALIGN="Left"></P>
<UL>
&nbsp;</UL><OL>
<LI><B>Get the software</B>
<BR>
You can obtain a copy of the software by following the instructions on the OpenLDAP Software download page (<A HREF="http://www.openldap.org/software/download/">http://www.openldap.org/software/download/</A>).  It is recommended that new users start with the latest <EM>release</EM>.
<BR>
&nbsp;
<LI><B>Unpack the distribution</B>
<BR>
Pick a directory for the source to live under, change directory to there, and unpack the distribution using the following commands:<UL>
<TT>gunzip -c openldap-VERSION.tgz | tar xvfB -</TT></UL>
<BR>
then relocate yourself into the distribution directory:<UL>
<TT>cd openldap-VERSION</TT></UL>
<BR>
You'll have to replace <TT>VERSION</TT> with the version name of the release.
<BR>
&nbsp;
<LI><B>Review documentation</B>
<BR>
You should now review the <TT>COPYRIGHT</TT>, <TT>LICENSE</TT>, <TT>README</TT> and <TT>INSTALL</TT> documents provided with the distribution. The <TT>COPYRIGHT</TT> and <TT>LICENSE</TT> provide information on acceptable use, copying, and limitation of warranty of OpenLDAP Software.
<BR>
&nbsp;
<BR>
You should also review other chapters of this document. In particular, the <A HREF="#Building and Installing OpenLDAP Software">Building and Installing OpenLDAP Software</A> chapter of this document provides detailed information on prerequisite software and installation procedures.
<BR>
&nbsp;
<LI><B>Run <TT>configure</TT></B>
<BR>
You will need to run the provided <TT>configure</TT> script to <EM>configure</EM> the distribution for building on your system.  The <TT>configure</TT> script accepts many command line options that enable or disable optional software features.  Usually the defaults are okay, but you may want to change them.  To get a complete list of options that <TT>configure</TT> accepts, use the <TT>--help</TT> option:<UL>
<TT>./configure --help</TT></UL>
<BR>
However, given that you are using this guide, we'll assume you are brave enough to just let <TT>configure</TT> determine what's best:<UL>
<TT>./configure</TT></UL>
<BR>
Assuming <TT>configure</TT> doesn't dislike your system, you can proceed with building the software.  If <TT>configure</TT> did complain, well, you'll likely need to go to the Software FAQ <EM>Installation</EM> section (<A HREF="http://www.openldap.org/faq/?file=8">http://www.openldap.org/faq/?file=8</A>) and/or actually read the <A HREF="#Building and Installing OpenLDAP Software">Building and Installing OpenLDAP Software</A> chapter of this document.
<BR>
&nbsp;
<LI><B>Build the software</B>.
<BR>
The next step is to build the software.  This step has two parts, first we construct dependencies and then we compile the software:<UL>
<TT>make depend</TT>
<BR>
<TT>make</TT></UL>
<BR>
Both makes should complete without error.
<BR>
&nbsp;
<LI><B>Test the build</B>.
<BR>
To ensure a correct build, you should run the test suite (it only takes a few minutes):<UL>
<TT>make test</TT></UL>
<BR>
Tests which apply to your configuration will run and they should pass.  Some tests, such as the replication test, may be skipped.
<BR>
&nbsp;
<LI><B>Install the software</B>.
<BR>
You are now ready to install the software; this usually requires <EM>super-user</EM> privileges:<UL>
<TT>su root -c 'make install'</TT></UL>
<BR>
Everything should now be installed under <TT>/usr/local</TT> (or whatever installation prefix was used by <TT>configure</TT>).
<BR>
&nbsp;
<LI><B>Edit the configuration file</B>.
<BR>
Use your favorite editor to edit the provided <EM>slapd.ldif</EM> example (usually installed as <TT>/usr/local/etc/openldap/slapd.ldif</TT>) to contain a MDB database definition of the form:<UL>
<TT>dn: olcDatabase=mdb,cn=config</TT>
<BR>
<TT>objectClass: olcDatabaseConfig</TT>
<BR>
<TT>objectClass: olcMdbConfig</TT>
<BR>
<TT>olcDatabase: mdb</TT>
<BR>
<TT>OlcDbMaxSize: 1073741824</TT>
<BR>
<TT>olcSuffix: dc=&lt;MY-DOMAIN&gt;,dc=&lt;COM&gt;</TT>
<BR>
<TT>olcRootDN: cn=Manager,dc=&lt;MY-DOMAIN&gt;,dc=&lt;COM&gt;</TT>
<BR>
<TT>olcRootPW: secret</TT>
<BR>
<TT>olcDbDirectory: /usr/local/var/openldap-data</TT>
<BR>
<TT>olcDbIndex: objectClass eq</TT></UL>
<BR>
Be sure to replace <TT>&lt;MY-DOMAIN&gt;</TT> and <TT>&lt;COM&gt;</TT> with the appropriate domain components of your domain name.  For example, for <TT>example.com</TT>, use:<UL>
<TT>dn: olcDatabase=mdb,cn=config</TT>
<BR>
<TT>objectClass: olcDatabaseConfig</TT>
<BR>
<TT>objectClass: olcMdbConfig</TT>
<BR>
<TT>olcDatabase: mdb</TT>
<BR>
<TT>OlcDbMaxSize: 1073741824</TT>
<BR>
<TT>olcSuffix: dc=example,dc=com</TT>
<BR>
<TT>olcRootDN: cn=Manager,dc=example,dc=com</TT>
<BR>
<TT>olcRootPW: secret</TT>
<BR>
<TT>olcDbDirectory: /usr/local/var/openldap-data</TT>
<BR>
<TT>olcDbIndex: objectClass eq</TT></UL>
<BR>
If your domain contains additional components, such as <TT>eng.uni.edu.eu</TT>, use:<UL>
<TT>dn: olcDatabase=mdb,cn=config</TT>
<BR>
<TT>objectClass: olcDatabaseConfig</TT>
<BR>
<TT>objectClass: olcMdbConfig</TT>
<BR>
<TT>olcDatabase: mdb</TT>
<BR>
<TT>OlcDbMaxSize: 1073741824</TT>
<BR>
<TT>olcSuffix: dc=eng,dc=uni,dc=edu,dc=eu</TT>
<BR>
<TT>olcRootDN: cn=Manager,dc=eng,dc=uni,dc=edu,dc=eu</TT>
<BR>
<TT>olcRootPW: secret</TT>
<BR>
<TT>olcDbDirectory: /usr/local/var/openldap-data</TT>
<BR>
<TT>olcDbIndex: objectClass eq</TT></UL>
<BR>
Details regarding configuring <EM>slapd</EM>(8) can be found in the <EM>slapd-config</EM>(5) manual page and the <A HREF="#Configuring slapd">Configuring slapd</A> chapter of this document.  Note that the specified olcDbDirectory must exist prior to starting <EM>slapd</EM>(8).
<BR>
&nbsp;
<LI><B>Import the configuration database</B>
<BR>
You are now ready to import your configuration database for use by <EM>slapd</EM>(8), by running the command:<UL>
<TT> su root -c /usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l /usr/local/etc/openldap/slapd.ldif</TT></UL>
<BR>
&nbsp;
<LI><B>Start SLAPD</B>.
<BR>
You are now ready to start the Standalone LDAP Daemon, <EM>slapd</EM>(8), by running the command:<UL>
<TT>su root -c /usr/local/libexec/slapd -F /usr/local/etc/slapd.d</TT></UL>
<BR>
To check to see if the server is running and configured correctly, you can run a search against it with <EM>ldapsearch</EM>(1).  By default, <EM>ldapsearch</EM> is installed as <TT>/usr/local/bin/ldapsearch</TT>:<UL>
<TT>ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts</TT></UL>
<BR>
Note the use of single quotes around command parameters to prevent special characters from being interpreted by the shell.  This should return:<UL>
<TT>dn:</TT>
<BR>
<TT>namingContexts: dc=example,dc=com</TT></UL>
<BR>
Details regarding running <EM>slapd</EM>(8) can be found in the <EM>slapd</EM>(8) manual page and the <A HREF="#Running slapd">Running slapd</A> chapter of this document.
<BR>
&nbsp;
<LI><B>Add initial entries to your directory</B>.
<BR>
You can use <EM>ldapadd</EM>(1) to add entries to your LDAP directory. <EM>ldapadd</EM> expects input in <TERM>LDIF</TERM> form.  We'll do it in two steps:<OL>
<LI>create an LDIF file
<LI>run ldapadd</OL>
<BR>
Use your favorite editor and create an LDIF file that contains:<UL>
<TT>dn: dc=&lt;MY-DOMAIN&gt;,dc=&lt;COM&gt;</TT>
<BR>
<TT>objectclass: dcObject</TT>
<BR>
<TT>objectclass: organization</TT>
<BR>
<TT>o: &lt;MY ORGANIZATION&gt;</TT>
<BR>
<TT>dc: &lt;MY-DOMAIN&gt;</TT>
<BR>
<TT></TT>
<BR>
<TT>dn: cn=Manager,dc=&lt;MY-DOMAIN&gt;,dc=&lt;COM&gt;</TT>
<BR>
<TT>objectclass: organizationalRole</TT>
<BR>
<TT>cn: Manager</TT></UL>
<BR>
Be sure to replace <TT>&lt;MY-DOMAIN&gt;</TT> and <TT>&lt;COM&gt;</TT> with the appropriate domain components of your domain name.  <TT>&lt;MY ORGANIZATION&gt;</TT> should be replaced with the name of your organization. When you cut and paste, be sure to trim any leading and trailing whitespace from the example.<UL>
<TT>dn: dc=example,dc=com</TT>
<BR>
<TT>objectclass: dcObject</TT>
<BR>
<TT>objectclass: organization</TT>
<BR>
<TT>o: Example Company</TT>
<BR>
<TT>dc: example</TT>
<BR>
<TT></TT>
<BR>
<TT>dn: cn=Manager,dc=example,dc=com</TT>
<BR>
<TT>objectclass: organizationalRole</TT>
<BR>
<TT>cn: Manager</TT></UL>
<BR>
Now, you may run <EM>ldapadd</EM>(1) to insert these entries into your directory.<UL>
<TT>ldapadd -x -D &quot;cn=Manager,dc=&lt;MY-DOMAIN&gt;,dc=&lt;COM&gt;&quot; -W -f example.ldif</TT></UL>
<BR>
Be sure to replace <TT>&lt;MY-DOMAIN&gt;</TT> and <TT>&lt;COM&gt;</TT> with the appropriate domain components of your domain name.  You will be prompted for the &quot;<TT>secret</TT>&quot; specified in <TT>slapd.conf</TT>. For example, for <TT>example.com</TT>, use:<UL>
<TT>ldapadd -x -D &quot;cn=Manager,dc=example,dc=com&quot; -W -f example.ldif</TT></UL>
<BR>
where <TT>example.ldif</TT> is the file you created above.<UL>
<TT> </TT></UL>
<BR>
Additional information regarding directory creation can be found in the <A HREF="#Database Creation and Maintenance Tools">Database Creation and Maintenance Tools</A> chapter of this document.
<BR>
&nbsp;
<LI><B>See if it works</B>.
<BR>
Now we're ready to verify the added entries are in your directory. You can use any LDAP client to do this, but our example uses the <EM>ldapsearch</EM>(1) tool.  Remember to replace <TT>dc=example,dc=com</TT> with the correct values for your site:<UL>
<TT>ldapsearch -x -b 'dc=example,dc=com' '(objectclass=*)'</TT></UL>
<BR>
This command will search for and retrieve every entry in the database.</OL>
<P>You are now ready to add more entries using <EM>ldapadd</EM>(1) or another LDAP client, experiment with various configuration options, backend arrangements, etc..</P>
<P>Note that by default, the <EM>slapd</EM>(8) database grants <EM>read access to everybody</EM> excepting the <EM>super-user</EM> (as specified by the <TT>rootdn</TT> configuration directive).  It is highly recommended that you establish controls to restrict access to authorized users. Access controls are discussed in the <A HREF="#Access Control">Access Control</A> chapter. You are also encouraged to read the <A HREF="#Security Considerations">Security Considerations</A>, <A HREF="#Using SASL">Using SASL</A> and <A HREF="#Using TLS">Using TLS</A> sections.</P>
<P>The following chapters provide more detailed information on making, installing, and running <EM>slapd</EM>(8).</P>
<P></P>
<HR>
<H1><A NAME="The Big Picture - Configuration Choices">3. The Big Picture - Configuration Choices</A></H1>
<P>This section gives a brief overview of various <TERM>LDAP</TERM> directory configurations, and how your Standalone LDAP Daemon <EM>slapd</EM>(8) fits in with the rest of the world.</P>
<H2><A NAME="Local Directory Service">3.1. Local Directory Service</A></H2>
<P>In this configuration, you run a <EM>slapd</EM>(8) instance which provides directory service for your local domain only. It does not interact with other directory servers in any way. This configuration is shown in Figure 3.1.</P>
<P><CENTER><IMG SRC="config_local.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure 3.1: Local service configuration.</P>
<P>Use this configuration if you are just starting out (it's the one the quick-start guide makes for you) or if you want to provide a local service and are not interested in connecting to the rest of the world. It's easy to upgrade to another configuration later if you want.</P>
<H2><A NAME="Local Directory Service with Referrals">3.2. Local Directory Service with Referrals</A></H2>
<P>In this configuration, you run a <EM>slapd</EM>(8) instance which provides directory service for your local domain and configure it to return referrals to other servers capable of handling requests.  You may run this service (or services) yourself or use one provided to you. This configuration is shown in Figure 3.2.</P>
<P><CENTER><IMG SRC="config_ref.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure 3.2: Local service with referrals</P>
<P>Use this configuration if you want to provide local service and participate in the Global Directory,  or you want to delegate responsibility for <EM>subordinate</EM> entries to another server.</P>
<H2><A NAME="Replicated Directory Service">3.3. Replicated Directory Service</A></H2>
<P>slapd(8) includes support for <EM>LDAP Sync</EM>-based replication, called <EM>syncrepl</EM>, which may be used to maintain shadow copies of directory information on multiple directory servers.   In its most basic configuration, the <EM>provider</EM> is a syncrepl provider and one or more <EM>consumer</EM> (or <EM>shadow</EM>) are syncrepl consumers.  An example provider-consumer configuration is shown in figure 3.3. Multi-Provider configurations are also supported.</P>
<P><CENTER><IMG SRC="config_repl.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure 3.3: Replicated Directory Services</P>
<P>This configuration can be used in conjunction with either of the first two configurations in situations where a single <EM>slapd</EM>(8) instance does not provide the required reliability or availability.</P>
<H2><A NAME="Distributed Local Directory Service">3.4. Distributed Local Directory Service</A></H2>
<P>In this configuration, the local service is partitioned into smaller services, each of which may be replicated, and <EM>glued</EM> together with <EM>superior</EM> and <EM>subordinate</EM> referrals.</P>
<P></P>
<HR>
<H1><A NAME="Building and Installing OpenLDAP Software">4. Building and Installing OpenLDAP Software</A></H1>
<P>This chapter details how to build and install the <A HREF="https://www.openldap.org/">OpenLDAP</A> Software package including <EM>slapd</EM>(8), the Standalone <TERM>LDAP</TERM> Daemon.  Building and installing OpenLDAP Software requires several steps: installing prerequisite software, configuring OpenLDAP Software itself, making, and finally installing.  The following sections describe this process in detail.</P>
<H2><A NAME="Obtaining and Extracting the Software">4.1. Obtaining and Extracting the Software</A></H2>
<P>You can obtain OpenLDAP Software from the project's download page at <A HREF="http://www.openldap.org/software/download/">http://www.openldap.org/software/download/</A> or directly from the project's <TERM>FTP</TERM> service at <A HREF="ftp://ftp.openldap.org/pub/OpenLDAP/">ftp://ftp.openldap.org/pub/OpenLDAP/</A>.</P>
<P>The project makes available two series of packages for <EM>general use</EM>.  The project makes <EM>releases</EM> as new features and bug fixes come available.  Though the project takes steps to improve stability of these releases, it is common for problems to arise only after <EM>release</EM>.  The <EM>stable</EM> release is the latest <EM>release</EM> which has demonstrated stability through general use.</P>
<P>Users of OpenLDAP Software can choose, depending on their desire for the <EM>latest features</EM> versus <EM>demonstrated stability</EM>, the most appropriate series to install.</P>
<P>After downloading OpenLDAP Software, you need to extract the distribution from the compressed archive file and change your working directory to the top directory of the distribution:</P>
<UL>
<TT>gunzip -c openldap-VERSION.tgz | tar xf -</TT>
<BR>
<TT>cd openldap-VERSION</TT></UL>
<P>You'll have to replace <TT>VERSION</TT> with the version name of the release.</P>
<P>You should now review the <TT>COPYRIGHT</TT>, <TT>LICENSE</TT>, <TT>README</TT> and <TT>INSTALL</TT> documents provided with the distribution.  The <TT>COPYRIGHT</TT> and <TT>LICENSE</TT> provide information on acceptable use, copying, and limitation of warranty of OpenLDAP Software. The <TT>README</TT> and <TT>INSTALL</TT> documents provide detailed information on prerequisite software and installation procedures.</P>
<H2><A NAME="Prerequisite software">4.2. Prerequisite software</A></H2>
<P>OpenLDAP Software relies upon a number of software packages distributed by third parties.  Depending on the features you intend to use, you may have to download and install a number of additional software packages.  This section details commonly needed third party software packages you might have to install.  However, for an up-to-date prerequisite information, the <TT>README</TT> document should be consulted.  Note that some of these third party packages may depend on additional software packages.  Install each package per the installation instructions provided with it.</P>
<H3><A NAME="{{TERM[expand]TLS}}">4.2.1. <TERM>Transport Layer Security</TERM></A></H3>
<P>OpenLDAP clients and servers require installation of <A HREF="https://www.openssl.org/">OpenSSL</A> or <A HREF="https://gnutls.org/">GnuTLS</A> <TERM>TLS</TERM> libraries to provide <TERM>Transport Layer Security</TERM> services.  Though some operating systems may provide these libraries as part of the base system or as an optional software component, OpenSSL and GnuTLS often require separate installation.</P>
<P>OpenSSL is available from <A HREF="http://www.openssl.org/">http://www.openssl.org/</A>. GnuTLS is available from <A HREF="http://www.gnu.org/software/gnutls/">http://www.gnu.org/software/gnutls/</A>.</P>
<P>OpenLDAP Software will not be fully LDAPv3 compliant unless OpenLDAP's <TT>configure</TT> detects a usable TLS library.</P>
<H3><A NAME="{{TERM[expand]SASL}}">4.2.2. <TERM>Simple Authentication and Security Layer</TERM></A></H3>
<P>OpenLDAP clients and servers require installation of <A HREF="https://www.cyrusimap.org/sasl/">Cyrus SASL</A> libraries to provide <TERM>Simple Authentication and Security Layer</TERM> services.  Though some operating systems may provide this library as part of the base system or as an optional software component, Cyrus SASL often requires separate installation.</P>
<P>Cyrus SASL is available from <A HREF="http://asg.web.cmu.edu/sasl/sasl-library.html">http://asg.web.cmu.edu/sasl/sasl-library.html</A>. Cyrus SASL will make use of OpenSSL and Kerberos/GSSAPI libraries if preinstalled.</P>
<P>OpenLDAP Software will not be fully LDAPv3 compliant unless OpenLDAP's configure detects a usable Cyrus SASL installation.</P>
<H3><A NAME="{{TERM[expand]Kerberos}}">4.2.3. <TERM>Kerberos Authentication Service</TERM></A></H3>
<P>OpenLDAP clients and servers support <TERM>Kerberos</TERM> authentication services.  In particular, OpenLDAP supports the Kerberos V <TERM>GSS-API</TERM> <TERM>SASL</TERM> authentication mechanism known as the <TERM>GSSAPI</TERM> mechanism.  This feature requires, in addition to Cyrus SASL libraries, either <A HREF="https://github.com/heimdal/">Heimdal</A> or <A HREF="https://web.mit.edu/kerberos/">MIT Kerberos</A> V libraries.</P>
<P>Heimdal Kerberos is available from <A HREF="http://www.pdc.kth.se/heimdal/">http://www.pdc.kth.se/heimdal/</A>. MIT Kerberos is available from <A HREF="http://web.mit.edu/kerberos/www/">http://web.mit.edu/kerberos/www/</A>.</P>
<P>Use of strong authentication services, such as those provided by Kerberos, is highly recommended.</P>
<H3><A NAME="Database Software">4.2.4. Database Software</A></H3>
<P>OpenLDAP's <EM>slapd</EM>(8) <TERM>MDB</TERM> primary database backend uses the <TERM>LMDB</TERM> software included with the OpenLDAP source.  There is no need to download any additional software to have <EM>MDB</EM> support.</P>
<H3><A NAME="Threads">4.2.5. Threads</A></H3>
<P>OpenLDAP is designed to take advantage of threads.  OpenLDAP supports POSIX <EM>pthreads</EM>, NT threads and a number of other varieties.  <TT>configure</TT> will complain if it cannot find a suitable thread subsystem.   If this occurs, please consult the <TT>Software|Installation|Platform Hints</TT> section of the OpenLDAP FAQ <A HREF="http://www.openldap.org/faq/">http://www.openldap.org/faq/</A>.</P>
<H3><A NAME="TCP Wrappers">4.2.6. TCP Wrappers</A></H3>
<P><EM>slapd</EM>(8) supports TCP Wrappers (IP level access control filters) if preinstalled.  Use of TCP Wrappers or other IP-level access filters (such as those provided by an IP-level firewall) is recommended for servers containing non-public information.</P>
<H2><A NAME="Running configure">4.3. Running configure</A></H2>
<P>Now you should probably run the <TT>configure</TT> script with the <TT>--help</TT> option. This will give you a list of options that you can change when building OpenLDAP.  Many of the features of OpenLDAP can be enabled or disabled using this method.</P>
<PRE>
        ./configure --help
</PRE>
<P>The <TT>configure</TT> script also looks for certain variables on the command line and in the environment.  These include:</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 4.1: Variables</CAPTION>
<TR CLASS="heading">
<TD>
<STRONG>Variable</STRONG>
</TD>
<TD>
<STRONG>Description</STRONG>
</TD>
</TR>
<TR>
<TD>
<TT>CC</TT>
</TD>
<TD>
Specify alternative C Compiler
</TD>
</TR>
<TR>
<TD>
<TT>CFLAGS</TT>
</TD>
<TD>
Specify additional compiler flags
</TD>
</TR>
<TR>
<TD>
<TT>CPPFLAGS</TT>
</TD>
<TD>
Specify C Preprocessor flags
</TD>
</TR>
<TR>
<TD>
<TT>LDFLAGS</TT>
</TD>
<TD>
Specify linker flags
</TD>
</TR>
<TR>
<TD>
<TT>LIBS</TT>
</TD>
<TD>
Specify additional libraries
</TD>
</TR>
</TABLE>

<P>Now run the configure script with any desired configuration options or variables.</P>
<PRE>
        ./configure [options] [variable=value ...]
</PRE>
<P>As an example, let's assume that we want to install OpenLDAP with MDB backend and TCP Wrappers support.  By default, MDB is enabled and TCP Wrappers is not.  So, we just need to specify <TT>--enable-wrappers</TT> to include TCP Wrappers support:</P>
<PRE>
        ./configure --enable-wrappers
</PRE>
<P>However, this will fail to locate dependent software not installed in system directories.  For example, if TCP Wrappers headers and libraries are installed in <TT>/usr/local/include</TT> and <TT>/usr/local/lib</TT> respectively, the <TT>configure</TT> script should typically be called as follows:</P>
<PRE>
        ./configure --enable-wrappers \
                CPPFLAGS=&quot;-I/usr/local/include&quot; \
                LDFLAGS=&quot;-L/usr/local/lib -Wl,-rpath,/usr/local/lib&quot;
</PRE>
<P>The <TT>configure</TT> script will normally auto-detect appropriate settings.  If you have problems at this stage, consult any platform specific hints and check your <TT>configure</TT> options, if any.</P>
<H2><A NAME="Building the Software">4.4. Building the Software</A></H2>
<P>Once you have run the <TT>configure</TT> script the last line of output should be:</P>
<PRE>
        Please &quot;make depend&quot; to build dependencies
</PRE>
<P>If the last line of output does not match, <TT>configure</TT> has failed, and you will need to review its output to determine what went wrong. You should not proceed until <TT>configure</TT> completes successfully.</P>
<P>To build dependencies, run:</P>
<PRE>
        make depend
</PRE>
<P>Now build the software, this step will actually compile OpenLDAP.</P>
<PRE>
        make
</PRE>
<P>You should examine the output of this command carefully to make sure everything is built correctly.  Note that this command builds the LDAP libraries and associated clients as well as <EM>slapd</EM>(8).</P>
<H2><A NAME="Testing the Software">4.5. Testing the Software</A></H2>
<P>Once the software has been properly configured and successfully made, you should run the test suite to verify the build.</P>
<PRE>
        make test
</PRE>
<P>Tests which apply to your configuration will run and they should pass. Some tests, such as the replication test, may be skipped if not supported by your configuration.</P>
<H2><A NAME="Installing the Software">4.6. Installing the Software</A></H2>
<P>Once you have successfully tested the software, you are ready to install it.  You will need to have write permission to the installation directories you specified when you ran configure.  By default OpenLDAP Software is installed in <TT>/usr/local</TT>.  If you changed this setting with the <TT>--prefix</TT> configure option, it will be installed in the location you provided.</P>
<P>Typically, the installation requires <EM>super-user</EM> privileges. From the top level OpenLDAP source directory, type:</P>
<PRE>
        su root -c 'make install'
</PRE>
<P>and enter the appropriate password when requested.</P>
<P>You should examine the output of this command carefully to make sure everything is installed correctly. You will find the configuration files for <EM>slapd</EM>(8) in <TT>/usr/local/etc/openldap</TT> by default.  See the chapter <A HREF="#Configuring slapd">Configuring slapd</A> for additional information.</P>
<P></P>
<HR>
<H1><A NAME="Configuring slapd">5. Configuring slapd</A></H1>
<P>Once the software has been built and installed, you are ready to configure <EM>slapd</EM>(8) for use at your site.</P>
<P>OpenLDAP 2.3 and later have transitioned to using a dynamic runtime configuration engine, <EM>slapd-config</EM>(5).  <EM>slapd-config</EM>(5)</P>
<UL>
<LI>is fully LDAP-enabled
<LI>is managed using the standard LDAP operations
<LI>stores its configuration data in an <TERM>LDIF</TERM> database, generally in the <TT>/usr/local/etc/openldap/slapd.d</TT> directory.
<LI>allows all of slapd's configuration options to be changed on the fly, generally without requiring a server restart for the changes to take effect.</UL>
<P>This chapter describes the general format of the <EM>slapd-config</EM>(5) configuration system, followed by a detailed description of commonly used settings.</P>
<P>The older style <EM>slapd.conf</EM>(5) file is still supported, but its use is deprecated and support for it will be withdrawn in a future OpenLDAP release.  Configuring <EM>slapd</EM>(8) via <EM>slapd.conf</EM>(5) is described in the next chapter.</P>
<P>Refer to <EM>slapd</EM>(8) for information on how to have slapd automatically convert from <EM>slapd.conf</EM>(5) to <EM>slapd-config</EM>(5).</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>Although the <EM>slapd-config</EM>(5) system stores its configuration as (text-based) LDIF files, you should <EM>never</EM> edit any of the LDIF files directly.  Configuration changes should be performed via LDAP operations, e.g. <EM>ldapadd</EM>(1), <EM>ldapdelete</EM>(1), or <EM>ldapmodify</EM>(1). For offline modifications (when the server is not running), use <EM>slapadd</EM>(8) and <EM>slapmodify</EM>(8).
<HR WIDTH="80%" ALIGN="Left"></P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>You will need to continue to use the older <EM>slapd.conf</EM>(5) configuration system if your OpenLDAP installation requires the use of one or more backends or overlays that have not been updated to use the <EM>slapd-config</EM>(5) system.  As of OpenLDAP 2.4.33, all of the official backends have been updated.  There may be additional contributed or experimental overlays that also have not been updated.
<HR WIDTH="80%" ALIGN="Left"></P>
<H2><A NAME="Configuration Layout">5.1. Configuration Layout</A></H2>
<P>The slapd configuration is stored as a special LDAP directory with a predefined schema and DIT. There are specific objectClasses used to carry global configuration options, schema definitions, backend and database definitions, and assorted other items. A sample config tree is shown in Figure 5.1.</P>
<P><CENTER><IMG SRC="config_dit.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure 5.1: Sample configuration tree.</P>
<P>Other objects may be part of the configuration but were omitted from the illustration for clarity.</P>
<P>The <EM>slapd-config</EM> configuration tree has a very specific structure. The root of the tree is named <TT>cn=config</TT> and contains global configuration settings. Additional settings are contained in separate child entries:</P>
<UL>
<LI>Dynamically loaded modules<UL>
These may only be used if the <TT>--enable-modules</TT> option was used to configure the software.</UL>
<LI>Schema definitions<UL>
The <TT>cn=schema,cn=config</TT> entry contains the system schema (all the schema that is hard-coded in slapd).
<BR>
Child entries of <TT>cn=schema,cn=config</TT> contain user schema as loaded from config files or added at runtime.</UL>
<LI>Backend-specific configuration
<LI>Database-specific configuration<UL>
Overlays are defined in children of the Database entry.
<BR>
Databases and Overlays may also have other miscellaneous children.</UL></UL>
<P>The usual rules for LDIF files apply to the configuration information: Comment lines beginning with a '<TT>#</TT>' character are ignored.  If a line begins with a single space, it is considered a continuation of the previous line (even if the previous line is a comment) and the single leading space is removed. Entries are separated by blank lines.</P>
<P>The general layout of the config LDIF is as follows:</P>
<PRE>
        # global configuration settings
        dn: cn=config
        objectClass: olcGlobal
        cn: config
        &lt;global config settings&gt;

        # schema definitions
        dn: cn=schema,cn=config
        objectClass: olcSchemaConfig
        cn: schema
        &lt;system schema&gt;

        dn: cn={X}core,cn=schema,cn=config
        objectClass: olcSchemaConfig
        cn: {X}core
        &lt;core schema&gt;

        # additional user-specified schema
        ...

        # backend definitions
        dn: olcBackend=&lt;typeA&gt;,cn=config
        objectClass: olcBackendConfig
        olcBackend: &lt;typeA&gt;
        &lt;backend-specific settings&gt;

        # database definitions
        dn: olcDatabase={X}&lt;typeA&gt;,cn=config
        objectClass: olcDatabaseConfig
        olcDatabase: {X}&lt;typeA&gt;
        &lt;database-specific settings&gt;

        # subsequent definitions and settings
        ...
</PRE>
<P>Some of the entries listed above have a numeric index <TT>&quot;{X}&quot;</TT> in their names. While most configuration settings have an inherent ordering dependency (i.e., one setting must take effect before a subsequent one may be set), LDAP databases are inherently unordered. The numeric index is used to enforce a consistent ordering in the configuration database, so that all ordering dependencies are preserved. In most cases the index does not have to be provided; it will be automatically generated based on the order in which entries are created.</P>
<P>Configuration directives are specified as values of individual attributes. Most of the attributes and objectClasses used in the slapd configuration have a prefix of <TT>&quot;olc&quot;</TT> (OpenLDAP Configuration) in their names. Generally there is a one-to-one correspondence between the attributes and the old-style <TT>slapd.conf</TT> configuration keywords, using the keyword as the attribute name, with the &quot;olc&quot; prefix attached.</P>
<P>A configuration directive may take arguments.  If so, the arguments are separated by whitespace.  If an argument contains whitespace, the argument should be enclosed in double quotes <TT>&quot;like this&quot;</TT>. In the descriptions that follow, arguments that should be replaced by actual text are shown in brackets <TT>&lt;&gt;</TT>.</P>
<P>The distribution contains an example configuration file that will be installed in the <TT>/usr/local/etc/openldap</TT> directory. A number of files containing schema definitions (attribute types and object classes) are also provided in the <TT>/usr/local/etc/openldap/schema</TT> directory.</P>
<H2><A NAME="Configuration Directives">5.2. Configuration Directives</A></H2>
<P>This section details commonly used configuration directives.  For a complete list, see the <EM>slapd-config</EM>(5) manual page.  This section will treat the configuration directives in a top-down order, starting with the global directives in the <TT>cn=config</TT> entry. Each directive will be described along with its default value (if any) and an example of its use.</P>
<H3><A NAME="cn=config">5.2.1. cn=config</A></H3>
<P>Directives contained in this entry generally apply to the server as a whole. Most of them are system or connection oriented, not database related. This entry must have the <TT>olcGlobal</TT> objectClass.</P>
<H4><A NAME="olcIdleTimeout: &lt;integer&gt;">5.2.1.1. olcIdleTimeout: &lt;integer&gt;</A></H4>
<P>Specify the number of seconds to wait before forcibly closing an idle client connection.  A value of 0, the default, disables this feature.</P>
<H4><A NAME="olcLogLevel: &lt;level&gt;">5.2.1.2. olcLogLevel: &lt;level&gt;</A></H4>
<P>This directive specifies the level at which log statements and operation statistics should be sent to syslog (currently logged to the <EM>syslogd</EM>(8) <TT>LOG_LOCAL4</TT> facility). You must have configured OpenLDAP <TT>--enable-debug</TT> (the default) for this to work, except for the two statistics levels, which are always enabled. Log levels may be specified as integers or by keyword. Multiple log levels may be used and the levels are additive. The possible values for &lt;level&gt; are:</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 5.1: Logging Levels</CAPTION>
<TR CLASS="heading">
<TD ALIGN='Right'>
<STRONG>Level</STRONG>
</TD>
<TD ALIGN='Left'>
<STRONG>Keyword</STRONG>
</TD>
<TD>
<STRONG>Description</STRONG>
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
-1
</TD>
<TD ALIGN='Left'>
any
</TD>
<TD>
enable all debugging
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
0
</TD>
<TD ALIGN='Left'>
&nbsp;
</TD>
<TD>
no debugging
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
1
</TD>
<TD ALIGN='Left'>
(0x1 trace)
</TD>
<TD>
trace function calls
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
2
</TD>
<TD ALIGN='Left'>
(0x2 packets)
</TD>
<TD>
debug packet handling
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
4
</TD>
<TD ALIGN='Left'>
(0x4 args)
</TD>
<TD>
heavy trace debugging
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
8
</TD>
<TD ALIGN='Left'>
(0x8 conns)
</TD>
<TD>
connection management
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
16
</TD>
<TD ALIGN='Left'>
(0x10 BER)
</TD>
<TD>
print out packets sent and received
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
32
</TD>
<TD ALIGN='Left'>
(0x20 filter)
</TD>
<TD>
search filter processing
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
64
</TD>
<TD ALIGN='Left'>
(0x40 config)
</TD>
<TD>
configuration processing
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
128
</TD>
<TD ALIGN='Left'>
(0x80 ACL)
</TD>
<TD>
access control list processing
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
256
</TD>
<TD ALIGN='Left'>
(0x100 stats)
</TD>
<TD>
stats log connections/operations/results
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
512
</TD>
<TD ALIGN='Left'>
(0x200 stats2)
</TD>
<TD>
stats log entries sent
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
1024
</TD>
<TD ALIGN='Left'>
(0x400 shell)
</TD>
<TD>
print communication with shell backends
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
2048
</TD>
<TD ALIGN='Left'>
(0x800 parse)
</TD>
<TD>
print entry parsing debugging
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
16384
</TD>
<TD ALIGN='Left'>
(0x4000 sync)
</TD>
<TD>
syncrepl consumer processing
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
32768
</TD>
<TD ALIGN='Left'>
(0x8000 none)
</TD>
<TD>
only messages that get logged regardless of configured log level
</TD>
</TR>
</TABLE>

<P>The desired log level can be input as a single integer that combines the (ORed) desired levels, both in decimal or in hexadecimal notation, as a list of integers (that are ORed internally), or as a list of the names that are shown between brackets, such that</P>
<PRE>
                olcLogLevel 129
                olcLogLevel 0x81
                olcLogLevel 128 1
                olcLogLevel 0x80 0x1
                olcLogLevel acl trace
</PRE>
<P>are equivalent.</P>
<P>Examples:</P>
<PRE>
 olcLogLevel -1
</PRE>
<P>This will enable all log levels.</P>
<PRE>
 olcLogLevel conns filter
</PRE>
<P>Just log the connection and search filter processing.</P>
<PRE>
 olcLogLevel none
</PRE>
<P>Log those messages that are logged regardless of the configured loglevel. This differs from setting the log level to 0, when no logging occurs. At least the <TT>None</TT> level is required to have high priority messages logged.</P>
<P>Default:</P>
<PRE>
 olcLogLevel stats
</PRE>
<P>Basic stats logging is configured by default.</P>
<H4><A NAME="olcReferral &lt;URI&gt;">5.2.1.3. olcReferral &lt;URI&gt;</A></H4>
<P>This directive specifies the referral to pass back when slapd cannot find a local database to handle a request.</P>
<P>Example:</P>
<PRE>
        olcReferral: ldap://root.openldap.org
</PRE>
<P>This will refer non-local queries to the global root LDAP server at the OpenLDAP Project. Smart LDAP clients can re-ask their query at that server, but note that most of these clients are only going to know how to handle simple LDAP URLs that contain a host part and optionally a distinguished name part.</P>
<H4><A NAME="Sample Entry">5.2.1.4. Sample Entry</A></H4>
<PRE>
dn: cn=config
objectClass: olcGlobal
cn: config
olcIdleTimeout: 30
olcLogLevel: Stats
olcReferral: ldap://root.openldap.org
</PRE>
<H3><A NAME="cn=module">5.2.2. cn=module</A></H3>
<P>If support for dynamically loaded modules was enabled when configuring slapd, <TT>cn=module</TT> entries may be used to specify sets of modules to load. Module entries must have the <TT>olcModuleList</TT> objectClass.</P>
<H4><A NAME="olcModuleLoad: &lt;filename&gt;">5.2.2.1. olcModuleLoad: &lt;filename&gt;</A></H4>
<P>Specify the name of a dynamically loadable module to load. The filename may be an absolute path name or a simple filename. Non-absolute names are searched for in the directories specified by the <TT>olcModulePath</TT> directive.</P>
<H4><A NAME="olcModulePath: &lt;pathspec&gt;">5.2.2.2. olcModulePath: &lt;pathspec&gt;</A></H4>
<P>Specify a list of directories to search for loadable modules. Typically the path is colon-separated but this depends on the operating system.</P>
<H4><A NAME="Sample Entries">5.2.2.3. Sample Entries</A></H4>
<PRE>
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: /usr/local/lib/smbk5pwd.la

dn: cn=module{1},cn=config
objectClass: olcModuleList
cn: module{1}
olcModulePath: /usr/local/lib:/usr/local/lib/slapd
olcModuleLoad: accesslog.la
olcModuleLoad: pcache.la
</PRE>
<H3><A NAME="cn=schema">5.2.3. cn=schema</A></H3>
<P>The cn=schema entry holds all of the schema definitions that are hard-coded in slapd. As such, the values in this entry are generated by slapd so no schema values need to be provided in the config file. The entry must still be defined though, to serve as a base for the user-defined schema to add in underneath. Schema entries must have the <TT>olcSchemaConfig</TT> objectClass.</P>
<H4><A NAME="olcAttributeTypes: &lt;{{REF:RFC4512}} Attribute Type Description&gt;"> </A>5.2.3.1. olcAttributeTypes: &lt;<A HREF="https://www.rfc-editor.org/rfc/rfc4512.txt">RFC4512</A> Attribute Type Description&gt;</H4>
<P>This directive defines an attribute type. Please see the <A HREF="#Schema Specification">Schema Specification</A> chapter for information regarding how to use this directive.</P>
<H4><A NAME="olcObjectClasses: &lt;{{REF:RFC4512}} Object Class Description&gt;"> </A>5.2.3.2. olcObjectClasses: &lt;<A HREF="https://www.rfc-editor.org/rfc/rfc4512.txt">RFC4512</A> Object Class Description&gt;</H4>
<P>This directive defines an object class. Please see the <A HREF="#Schema Specification">Schema Specification</A> chapter for information regarding how to use this directive.</P>
<H4><A NAME="Sample Entries">5.2.3.3. Sample Entries</A></H4>
<PRE>
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema

dn: cn=test,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: test
olcAttributeTypes: ( 1.1.1
  NAME 'testAttr'
  EQUALITY integerMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
olcAttributeTypes: ( 1.1.2 NAME 'testTwo' EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
olcObjectClasses: ( 1.1.3 NAME 'testObject'
  MAY ( testAttr $ testTwo ) AUXILIARY )
</PRE>
<H3><A NAME="Backend-specific Directives">5.2.4. Backend-specific Directives</A></H3>
<P>Backend directives apply to all database instances of the same type and, depending on the directive, may be overridden by database directives. Backend entries must have the <TT>olcBackendConfig</TT> objectClass.</P>
<H4><A NAME="olcBackend: &lt;type&gt;">5.2.4.1. olcBackend: &lt;type&gt;</A></H4>
<P>This directive names a backend-specific configuration entry. <TT>&lt;type&gt;</TT> should be one of the supported backend types listed in Table 5.2.</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 5.2: Database Backends</CAPTION>
<TR CLASS="heading">
<TD>
<STRONG>Types</STRONG>
</TD>
<TD>
<STRONG>Description</STRONG>
</TD>
</TR>
<TR>
<TD>
<TT>asyncmet</TT>
</TD>
<TD>
a       Asynchronous Metadirectory backend
</TD>
</TR>
<TR>
<TD>
<TT>config</TT>
</TD>
<TD>
Slapd configuration backend
</TD>
</TR>
<TR>
<TD>
<TT>dnssrv</TT>
</TD>
<TD>
DNS SRV backend
</TD>
</TR>
<TR>
<TD>
<TT>ldap</TT>
</TD>
<TD>
Lightweight Directory Access Protocol (Proxy) backend
</TD>
</TR>
<TR>
<TD>
<TT>ldif</TT>
</TD>
<TD>
Lightweight Data Interchange Format backend
</TD>
</TR>
<TR>
<TD>
<TT>mdb</TT>
</TD>
<TD>
Memory-Mapped DB backend
</TD>
</TR>
<TR>
<TD>
<TT>meta</TT>
</TD>
<TD>
Metadirectory backend
</TD>
</TR>
<TR>
<TD>
<TT>monitor</TT>
</TD>
<TD>
Monitor backend
</TD>
</TR>
<TR>
<TD>
<TT>ndb</TT>
</TD>
<TD>
MySQL NDB backend
</TD>
</TR>
<TR>
<TD>
<TT>null</TT>
</TD>
<TD>
Null backend
</TD>
</TR>
<TR>
<TD>
<TT>passwd</TT>
</TD>
<TD>
Provides read-only access to <EM>passwd</EM>(5)
</TD>
</TR>
<TR>
<TD>
<TT>perl</TT>
</TD>
<TD>
Perl Programmable backend
</TD>
</TR>
<TR>
<TD>
<TT>relay</TT>
</TD>
<TD>
Relay backend
</TD>
</TR>
<TR>
<TD>
<TT>sock</TT>
</TD>
<TD>
Socket backend
</TD>
</TR>
<TR>
<TD>
<TT>sql</TT>
</TD>
<TD>
SQL Programmable backend
</TD>
</TR>
<TR>
<TD>
<TT>wt</TT>
</TD>
<TD>
WiredTiger backend
</TD>
</TR>
</TABLE>

<P>Example:</P>
<PRE>
        olcBackend: mdb
</PRE>
<P>This marks the beginning of a new <TERM>MDB</TERM> backend definition. At present, only back-mdb implements any options of this type, so this setting is not needed for any other backends.</P>
<H4><A NAME="Sample Entry">5.2.4.2. Sample Entry</A></H4>
<PRE>
 dn: olcBackend=mdb,cn=config
 objectClass: olcBackendConfig
 olcBackend: mdb
 olcBkMdbIdlExp: 16
</PRE>
<H3><A NAME="Database-specific Directives">5.2.5. Database-specific Directives</A></H3>
<P>Directives in this section are supported by every type of database. Database entries must have the <TT>olcDatabaseConfig</TT> objectClass.</P>
<H4><A NAME="olcDatabase: [{&lt;index&gt;}]&lt;type&gt;">5.2.5.1. olcDatabase: [{&lt;index&gt;}]&lt;type&gt;</A></H4>
<P>This directive names a specific database instance. The numeric {&lt;index&gt;} may be provided to distinguish multiple databases of the same type. Usually the index can be omitted, and slapd will generate it automatically. <TT>&lt;type&gt;</TT> should be one of the supported backend types listed in Table 5.2 or the <TT>frontend</TT> type.</P>
<P>The <TT>frontend</TT> is a special database that is used to hold database-level options that should be applied to all the other databases. Subsequent database definitions may also override some frontend settings.</P>
<P>The <TT>config</TT> database is also special; both the <TT>config</TT> and the <TT>frontend</TT> databases are always created implicitly even if they are not explicitly configured, and they are created before any other databases.</P>
<P>Example:</P>
<PRE>
        olcDatabase: mdb
</PRE>
<P>This marks the beginning of a new <TERM>MDB</TERM> database instance.</P>
<H4><A NAME="olcAccess: to &lt;what&gt; [ by &lt;who&gt; [&lt;accesslevel&gt;] [&lt;control&gt;] ]+">5.2.5.2. olcAccess: to &lt;what&gt; [ by &lt;who&gt; [&lt;accesslevel&gt;] [&lt;control&gt;] ]+</A></H4>
<P>This directive grants access (specified by &lt;accesslevel&gt;) to a set of entries and/or attributes (specified by &lt;what&gt;) by one or more requestors (specified by &lt;who&gt;). See the <A HREF="#Access Control">Access Control</A> section of this guide for basic usage.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>If no <TT>olcAccess</TT> directives are specified, the default access control policy, <TT>to * by * read</TT>, allows all users (both authenticated and anonymous) read access.
<HR WIDTH="80%" ALIGN="Left"></P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>Access controls defined in the frontend are appended to all other databases' controls.
<HR WIDTH="80%" ALIGN="Left"></P>
<H4><A NAME="olcReadonly { TRUE | FALSE }">5.2.5.3. olcReadonly { TRUE | FALSE }</A></H4>
<P>This directive puts the database into &quot;read-only&quot; mode. Any attempts to modify the database will return an &quot;unwilling to perform&quot; error.  If set on a consumer, modifications sent by syncrepl will still occur.</P>
<P>Default:</P>
<PRE>
        olcReadonly: FALSE
</PRE>
<H4><A NAME="olcRootDN: &lt;DN&gt;">5.2.5.4. olcRootDN: &lt;DN&gt;</A></H4>
<P>This directive specifies the DN that is not subject to access control or administrative limit restrictions for operations on this database.  The DN need not refer to an entry in this database or even in the directory. The DN may refer to a SASL identity.</P>
<P>Entry-based Example:</P>
<PRE>
        olcRootDN: cn=Manager,dc=example,dc=com
</PRE>
<P>SASL-based Example:</P>
<PRE>
        olcRootDN: uid=root,cn=example.com,cn=digest-md5,cn=auth
</PRE>
<P>See the <A HREF="#SASL Authentication">SASL Authentication</A> section for information on SASL authentication identities.</P>
<H4><A NAME="olcRootPW: &lt;password&gt;">5.2.5.5. olcRootPW: &lt;password&gt;</A></H4>
<P>This directive can be used to specify a password for the DN for the rootdn (when the rootdn is set to a DN within the database).</P>
<P>Example:</P>
<PRE>
        olcRootPW: secret
</PRE>
<P>It is also permissible to provide a hash of the password in <A HREF="https://www.rfc-editor.org/rfc/rfc2307.txt">RFC2307</A> form.  <EM>slappasswd</EM>(8) may be used to generate the password hash.</P>
<P>Example:</P>
<PRE>
        olcRootPW: {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
</PRE>
<P>The hash was generated using the command <TT>slappasswd -s secret</TT>.</P>
<H4><A NAME="olcSizeLimit: &lt;integer&gt;">5.2.5.6. olcSizeLimit: &lt;integer&gt;</A></H4>
<P>This directive specifies the maximum number of entries to return from a search operation.</P>
<P>Default:</P>
<PRE>
        olcSizeLimit: 500
</PRE>
<P>See the <A HREF="#Limits">Limits</A> section of this guide and slapd-config(5) for more details.</P>
<H4><A NAME="olcSuffix: &lt;dn suffix&gt;">5.2.5.7. olcSuffix: &lt;dn suffix&gt;</A></H4>
<P>This directive specifies the DN suffix of queries that will be passed to this backend database. Multiple suffix lines can be given, and usually at least one is required for each database definition. (Some backend types, such as <TT>frontend</TT> and <TT>monitor</TT> use a hard-coded suffix which may not be overridden in the configuration.)</P>
<P>Example:</P>
<PRE>
        olcSuffix: dc=example,dc=com
</PRE>
<P>Queries with a DN ending in &quot;dc=example,dc=com&quot; will be passed to this backend.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>When the backend to pass a query to is selected, slapd looks at the suffix value(s) in each database definition in the order in which they were configured. Thus, if one database suffix is a prefix of another, it must appear after it in the configuration.
<HR WIDTH="80%" ALIGN="Left"></P>
<H4><A NAME="olcSyncrepl">5.2.5.8. olcSyncrepl</A></H4>
<PRE>
        olcSyncrepl: rid=&lt;replica ID&gt;
                provider=ldap[s]://&lt;hostname&gt;[:port]
                [type=refreshOnly|refreshAndPersist]
                [interval=dd:hh:mm:ss]
                [retry=[&lt;retry interval&gt; &lt;# of retries&gt;]+]
                searchbase=&lt;base DN&gt;
                [filter=&lt;filter str&gt;]
                [scope=sub|one|base]
                [attrs=&lt;attr list&gt;]
                [attrsonly]
                [sizelimit=&lt;limit&gt;]
                [timelimit=&lt;limit&gt;]
                [schemachecking=on|off]
                [bindmethod=simple|sasl]
                [binddn=&lt;DN&gt;]
                [saslmech=&lt;mech&gt;]
                [authcid=&lt;identity&gt;]
                [authzid=&lt;identity&gt;]
                [credentials=&lt;passwd&gt;]
                [realm=&lt;realm&gt;]
                [secprops=&lt;properties&gt;]
                [starttls=yes|critical]
                [tls_cert=&lt;file&gt;]
                [tls_key=&lt;file&gt;]
                [tls_cacert=&lt;file&gt;]
                [tls_cacertdir=&lt;path&gt;]
                [tls_reqcert=never|allow|try|demand]
                [tls_cipher_suite=&lt;ciphers&gt;]
                [tls_crlcheck=none|peer|all]
                [logbase=&lt;base DN&gt;]
                [logfilter=&lt;filter str&gt;]
                [syncdata=default|accesslog|changelog]
</PRE>
<P>This directive specifies the current database as a consumer of the provider content by establishing the current <EM>slapd</EM>(8) as a replication consumer site running a syncrepl replication engine. The provider database is located at the provider site specified by the <TT>provider</TT> parameter. The consumer database is kept up-to-date with the provider content using the LDAP Content Synchronization protocol. See <A HREF="https://www.rfc-editor.org/rfc/rfc4533.txt">RFC4533</A> for more information on the protocol.</P>
<P>The <TT>rid</TT> parameter is used for identification of the current <TT>syncrepl</TT> directive within the replication consumer server, where <TT>&lt;replica ID&gt;</TT> uniquely identifies the syncrepl specification described by the current <TT>syncrepl</TT> directive. <TT>&lt;replica ID&gt;</TT> is non-negative and is no more than three decimal digits in length.</P>
<P>The <TT>provider</TT> parameter specifies the replication provider site containing the provider content as an LDAP URI. The <TT>provider</TT> parameter specifies a scheme, a host and optionally a port where the provider slapd instance can be found. Either a domain name or IP address may be used for &lt;hostname&gt;. Examples are <TT>ldap://provider.example.com:389</TT> or <TT>ldaps://192.168.1.1:636</TT>. If &lt;port&gt; is not given, the standard LDAP port number (389 or 636) is used. Note that the syncrepl uses a consumer-initiated protocol, and hence its specification is located on the consumer.</P>
<P>The content of the syncrepl consumer is defined using a search specification as its result set. The consumer slapd will send search requests to the provider slapd according to the search specification. The search specification includes <TT>searchbase</TT>, <TT>scope</TT>, <TT>filter</TT>, <TT>attrs</TT>, <TT>attrsonly</TT>, <TT>sizelimit</TT>, and <TT>timelimit</TT> parameters as in the normal search specification. The <TT>searchbase</TT> parameter has no default value and must always be specified. The <TT>scope</TT> defaults to <TT>sub</TT>, the <TT>filter</TT> defaults to <TT>(objectclass=*)</TT>, <TT>attrs</TT> defaults to <TT>&quot;*,+&quot;</TT> to replicate all user and operational attributes, and <TT>attrsonly</TT> is unset by default. Both <TT>sizelimit</TT> and <TT>timelimit</TT> default to &quot;unlimited&quot;, and only positive integers or &quot;unlimited&quot; may be specified.</P>
<P>The <TERM>LDAP Content Synchronization</TERM> protocol has two operation types: <TT>refreshOnly</TT> and <TT>refreshAndPersist</TT>. The operation type is specified by the <TT>type</TT> parameter. In the <TT>refreshOnly</TT> operation, the next synchronization search operation is periodically rescheduled at an interval time after each synchronization operation finishes. The interval is specified by the <TT>interval</TT> parameter. It is set to one day by default. In the <TT>refreshAndPersist</TT> operation, a synchronization search remains persistent in the provider <EM>slapd</EM> instance. Further updates to the provider will generate <TT>searchResultEntry</TT> to the consumer slapd as the search responses to the persistent synchronization search.</P>
<P>If an error occurs during replication, the consumer will attempt to reconnect according to the retry parameter which is a list of the &lt;retry interval&gt; and &lt;# of retries&gt; pairs. For example, retry=&quot;60 10 300 3&quot; lets the consumer retry every 60 seconds for the first 10 times and then retry every 300 seconds for the next three times before stop retrying. + in &lt;#  of retries&gt; means indefinite number of retries until success.</P>
<P>The schema checking can be enforced at the LDAP Sync consumer site by turning on the <TT>schemachecking</TT> parameter. If it is turned on, every replicated entry will be checked for its schema as the entry is stored on the consumer. Every entry in the consumer should contain those attributes required by the schema definition. If it is turned off, entries will be stored without checking schema conformance. The default is off.</P>
<P>The <TT>binddn</TT> parameter gives the DN to bind as for the syncrepl searches to the provider slapd. It should be a DN which has read access to the replication content in the provider database.</P>
<P>The <TT>bindmethod</TT> is <TT>simple</TT> or <TT>sasl</TT>, depending on whether simple password-based authentication or <TERM>SASL</TERM> authentication is to be used when connecting to the provider <EM>slapd</EM> instance.</P>
<P>Simple authentication should not be used unless adequate data integrity and confidentiality protections are in place (e.g. TLS or IPsec). Simple authentication requires specification of <TT>binddn</TT> and <TT>credentials</TT> parameters.</P>
<P>SASL authentication is generally recommended.  SASL authentication requires specification of a mechanism using the <TT>saslmech</TT> parameter. Depending on the mechanism, an authentication identity and/or credentials can be specified using <TT>authcid</TT> and <TT>credentials</TT>, respectively.  The <TT>authzid</TT> parameter may be used to specify an authorization identity.</P>
<P>The <TT>realm</TT> parameter specifies a realm which a certain mechanisms authenticate the identity within. The <TT>secprops</TT> parameter specifies Cyrus SASL security properties.</P>
<P>The <TT>starttls</TT> parameter specifies use of the StartTLS extended operation to establish a TLS session before authenticating to the provider. If the <TT>critical</TT> argument is supplied, the session will be aborted if the StartTLS request fails.  Otherwise the syncrepl session continues without TLS.  The tls_reqcert setting defaults to <TT>&quot;demand&quot;</TT> and the other TLS settings default to the same as the main slapd TLS settings.</P>
<P>Rather than replicating whole entries, the consumer can query logs of data modifications.  This mode of operation is referred to as <EM>delta syncrepl</EM>.  In addition to the above parameters, the <TT>logbase</TT> and <TT>logfilter</TT> parameters must be set appropriately for the log that will be used. The <TT>syncdata</TT> parameter must be set to either <TT>&quot;accesslog&quot;</TT> if the log conforms to the <EM>slapo-accesslog</EM>(5) log format, or <TT>&quot;changelog&quot;</TT> if the log conforms to the obsolete <EM>changelog</EM> format. If the <TT>syncdata</TT> parameter is omitted or set to <TT>&quot;default&quot;</TT> then the log parameters are ignored.</P>
<P>The <EM>syncrepl</EM> replication mechanism is supported by the <EM>mdb</EM> backend.</P>
<P>See the <A HREF="#LDAP Sync Replication">LDAP Sync Replication</A> chapter of this guide for more information on how to use this directive.</P>
<H4><A NAME="olcTimeLimit: &lt;integer&gt;">5.2.5.9. olcTimeLimit: &lt;integer&gt;</A></H4>
<P>This directive specifies the maximum number of seconds (in real time) slapd will spend answering a search request. If a request is not finished in this time, a result indicating an exceeded timelimit will be returned.</P>
<P>Default:</P>
<PRE>
        olcTimeLimit: 3600
</PRE>
<P>See the <A HREF="#Limits">Limits</A> section of this guide and slapd-config(5) for more details.</P>
<H4><A NAME="olcUpdateref: &lt;URL&gt;">5.2.5.10. olcUpdateref: &lt;URL&gt;</A></H4>
<P>This directive is only applicable in a <EM>replica</EM> (or <EM>shadow</EM>) <EM>slapd</EM>(8) instance. It specifies the URL to return to clients which submit update requests upon the replica. If specified multiple times, each <TERM>URL</TERM> is provided.</P>
<P>Example:</P>
<PRE>
        olcUpdateref:   ldap://provider.example.net
</PRE>
<H4><A NAME="Sample Entries">5.2.5.11. Sample Entries</A></H4>
<PRE>
dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
olcReadOnly: FALSE

dn: olcDatabase=config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
olcRootDN: cn=Manager,dc=example,dc=com
</PRE>
<H3><A NAME="MDB Backend Directives">5.2.6. MDB Backend Directives</A></H3>
<P>Directives in this category only apply to the <TERM>MDB</TERM> database backend. They will apply to all &quot;database mdb&quot; instances in the configuration. For a complete reference of MDB backend configuration directives, see <EM>slapd-mdb</EM>(5).</P>
<H4><A NAME="olcBkMdbIdlExp &lt;exponent&gt;">5.2.6.1. olcBkMdbIdlExp &lt;exponent&gt;</A></H4>
<P>Specify a power of 2 for the maximum size of an index slot. The default is 16, yielding a maximum slot size of 2^16 or 65536. The specified value must be in the range of 16-31.</P>
<P>This setting helps with the case where certain search filters are slow to return results due to an index slot having collapsed to a range value.  This occurs when the number of candidate entries that match the filter for the index slot exceed the configured slot size.</P>
<P>If this setting is decreased on a server with existing <TERM>MDB</TERM> databases, each db will immediately need its indices to be rebuilt while slapd is offline with the &quot;slapindex -q -t&quot; command.</P>
<P>If this setting is increased on a server with existing <TERM>MDB</TERM> databases, each db will need its indices rebuilt to take advantage of the change for indices that have already been converted to ranges.</P>
<H3><A NAME="MDB Database Directives">5.2.7. MDB Database Directives</A></H3>
<P>Directives in this category apply to the <TERM>MDB</TERM> database backend. They are used in an olcDatabase entry in addition to the generic database directives defined above.  For a complete reference of MDB configuration directives, see <EM>slapd-mdb</EM>(5). In addition to the <TT>olcDatabaseConfig</TT> objectClass, MDB database entries must have the <TT>olcMdbConfig</TT> objectClass.</P>
<H4><A NAME="olcDbDirectory: &lt;directory&gt;">5.2.7.1. olcDbDirectory: &lt;directory&gt;</A></H4>
<P>This directive specifies the directory where the MDB files containing the database and associated indices live.</P>
<P>Default:</P>
<PRE>
        olcDbDirectory: /usr/local/var/openldap-data
</PRE>
<H4><A NAME="olcDbCheckpoint: &lt;kbyte&gt; &lt;min&gt;">5.2.7.2. olcDbCheckpoint: &lt;kbyte&gt; &lt;min&gt;</A></H4>
<P>This directive specifies the frequency for flushing the database disk buffers. This directive is only needed if the <EM>olcDbNoSync</EM> option is <TT>TRUE</TT>. The checkpoint will occur if either &lt;kbyte&gt; data has been written or &lt;min&gt; minutes have passed since the last checkpoint. Both arguments default to zero, in which case they are ignored. When the &lt;min&gt; argument is non-zero, an internal task will run every &lt;min&gt; minutes to perform the checkpoint. Note: currently the _kbyte_ setting is unimplemented.</P>
<P>Example:</P>
<PRE>
        olcDbCheckpoint: 1024 10
</PRE>
<H4><A NAME="olcDbEnvFlags: {nosync,nometasync,writemap,mapasync,nordahead}">5.2.7.3. olcDbEnvFlags: {nosync,nometasync,writemap,mapasync,nordahead}</A></H4>
<P>This option specifies flags for finer-grained control of  the  LMDB  library's operation.</P>
<UL>
<LI><TT>nosync</TT>: This is exactly the same as the dbnosync directive.
<LI><TT>nometasync</TT>: Flush the data on a commit, but skip the sync of the meta page. This mode is slightly faster than doing a full sync, but can potentially lose the last committed transaction if the operating system crashes. If both nometasync and nosync are set, the nosync flag takes precedence.
<LI><TT>writemap</TT>: Use a writable memory map instead of just read-only. This speeds up write operations but makes the database vulnerable to corruption in case any bugs in slapd cause stray writes into the mmap region.
<LI><TT>mapasync</TT>: When using a writable memory map and performing flushes on each commit, use an asynchronous flush instead of a synchronous flush (the default). This option has no effect if writemap has not been set. It also has no effect if nosync is set.
<LI><TT>nordahead</TT>: Turn off file readahead. Usually the OS performs readahead on every read request. This usually boosts read performance but can be harmful to random access read performance if the system's memory is full and the DB is larger than RAM. This option is not implemented on Windows.</UL>
<H4><A NAME="olcDbIndex: {&lt;attrlist&gt; | default} [pres,eq,approx,sub,none]">5.2.7.4. olcDbIndex: {&lt;attrlist&gt; | default} [pres,eq,approx,sub,none]</A></H4>
<P>This directive specifies the indices to maintain for the given attribute. If only an <TT>&lt;attrlist&gt;</TT> is given, the default indices are maintained. The index keywords correspond to the common types of matches that may be used in an LDAP search filter.</P>
<P>Example:</P>
<PRE>
        olcDbIndex: default pres,eq
        olcDbIndex: uid
        olcDbIndex: cn,sn pres,eq,sub
        olcDbIndex: objectClass eq
</PRE>
<P>The first line sets the default set of indices to maintain to present and equality.  The second line causes the default (pres,eq) set of indices to be maintained for the <TT>uid</TT> attribute type. The third line causes present, equality, and substring indices to be maintained for <TT>cn</TT> and <TT>sn</TT> attribute types.  The fourth line causes an equality index for the <TT>objectClass</TT> attribute type.</P>
<P>There is no index keyword for inequality matches. Generally these matches do not use an index. However, some attributes do support indexing for inequality matches, based on the equality index.</P>
<P>A substring index can be more explicitly specified as <TT>subinitial</TT>, <TT>subany</TT>, or <TT>subfinal</TT>, corresponding to the three possible components of a substring match filter. A subinitial index only indexes substrings that appear at the beginning of an attribute value. A subfinal index only indexes substrings that appear at the end of an attribute value, while subany indexes substrings that occur anywhere in a value.</P>
<P>Note that by default, setting an index for an attribute also affects every subtype of that attribute. E.g., setting an equality index on the <TT>name</TT> attribute causes <TT>cn</TT>, <TT>sn</TT>, and every other attribute that inherits from <TT>name</TT> to be indexed.</P>
<P>By default, no indices are maintained.  It is generally advised that minimally an equality index upon objectClass be maintained.</P>
<PRE>
        olcDbIndex: objectClass eq
</PRE>
<P>Additional indices should be configured corresponding to the most common searches that are used on the database. Presence indexing should not be configured for an attribute unless the attribute occurs very rarely in the database, and presence searches on the attribute occur very frequently during normal use of the directory. Most applications don't use presence searches, so usually presence indexing is not very useful.</P>
<P>If this setting is changed while slapd is running, an internal task will be run to generate the changed index data. All server operations can continue as normal while the indexer does its work.  If slapd is stopped before the index task completes, indexing will have to be manually completed using the slapindex tool.</P>
<H4><A NAME="olcDbMaxEntrySize: &lt;bytes&gt;">5.2.7.5. olcDbMaxEntrySize: &lt;bytes&gt;</A></H4>
<P>Specify the maximum size of an entry in bytes. Attempts to store an entry larger than this size will be rejected with the error LDAP_ADMINLIMIT_EXCEEDED. The default is 0, which is unlimited.</P>
<H4><A NAME="olcDbMaxReaders: &lt;integer&gt;">5.2.7.6. olcDbMaxReaders: &lt;integer&gt;</A></H4>
<P>This directive specifies the maximum number of threads that may have concurrent read access to the database. Tools such as slapcat count as a single thread, in addition to threads in any active slapd processes. The default is 126.</P>
<H4><A NAME="olcDbMaxSize: &lt;bytes&gt;">5.2.7.7. olcDbMaxSize: &lt;bytes&gt;</A></H4>
<P>This directive specifies the maximum size of the database in bytes. A memory map of this size is allocated at startup time and the database will not be allowed to grow beyond this size. The default is 10485760 bytes (10MB). This setting may be changed upward if the configured limit needs to be increased.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>It is important to set this to as large a value as possible, (relative to anticipated growth of the actual data over time) since growing the size later may not be practical when the system is under heavy load.
<HR WIDTH="80%" ALIGN="Left"></P>
<H4><A NAME="olcDbMode: { &lt;octal&gt; | &lt;symbolic&gt; }">5.2.7.8. olcDbMode: { &lt;octal&gt; | &lt;symbolic&gt; }</A></H4>
<P>This directive specifies the file protection mode that newly created database index files should have. This can be in the form <TT>0600</TT> or <TT>-rw-------</TT></P>
<P>Default:</P>
<PRE>
        olcDbMode: 0600
</PRE>
<H4><A NAME="olcDbMultival: { &lt;attrlist&gt; | default } &lt;integer&gt; hi,&lt;integer&gt; lo">5.2.7.9. olcDbMultival: { &lt;attrlist&gt; | default } &lt;integer&gt; hi,&lt;integer&gt; lo</A></H4>
<P>Specify the number of values for which a multivalued attribute is stored in a separate table. Normally entries are stored as a single blob inside the database. When an entry gets very large or contains attributes with a very large number of values, modifications on that entry may get very slow. Splitting the large attributes out to a separate table can improve the performance of modification operations. The threshold is specified as a pair of integers. If the number of values exceeds the hi threshold the values will be split out. If a modification deletes enough values to bring an attribute below the lo threshold the values will be removed from the separate table and merged back into the main entry blob. The threshold can be set for a specific list of attributes, or the default can be configured for all other attributes. The default value for both hi and lo thresholds is UINT_MAX, which keeps all attributes in the main blob.</P>
<P>In addition to increasing write performance of operations the use of multival can also decrease fragmentation of the primary <TERM>MDB</TERM> database.</P>
<H4><A NAME="olcDbRtxnsize: &lt;entries&gt;">5.2.7.10. olcDbRtxnsize: &lt;entries&gt;</A></H4>
<P>This directive specifies the maximum number of entries to process in a single read transaction when executing a large search. Long-lived read transactions prevent old database pages from being reused in write transactions, and so can cause significant growth of the database file when there is heavy write traffic. This setting causes the read transaction in large searches to be released and reacquired after the given number of entries has been read, to give writers the opportunity to reclaim old database pages. The default is 10000.</P>
<H4><A NAME="olcDbSearchStack: &lt;integer&gt;">5.2.7.11. olcDbSearchStack: &lt;integer&gt;</A></H4>
<P>Specify the depth of the stack used for search filter evaluation. Search filters are evaluated on a stack to accommodate nested <TT>AND</TT> / <TT>OR</TT> clauses. An individual stack is allocated for each server thread. The depth of the stack determines how complex a filter can be evaluated without requiring any additional memory allocation. Filters that are nested deeper than the search stack depth will cause a separate stack to be allocated for that particular search operation. These separate allocations can have a major negative impact on server performance, but specifying too much stack will also consume a great deal of memory. Each search uses 512K bytes per level on a 32-bit machine, or 1024K bytes per level on a 64-bit machine. The default stack depth is 16, thus 8MB or 16MB per thread is used on 32 and 64 bit machines, respectively. Also the 512KB size of a single stack slot is set by a compile-time constant which may be changed if needed; the code must be recompiled for the change to take effect.</P>
<P>Default:</P>
<PRE>
        olcDbSearchStack: 16
</PRE>
<H4><A NAME="olcDbNosync: { TRUE | FALSE }">5.2.7.12. olcDbNosync: { TRUE | FALSE }</A></H4>
<P>This directive causes on-disk database contents to not be immediately synchronized with in memory changes upon change.  Setting this option to <TT>TRUE</TT> may improve performance at the expense of data integrity.</P>
<H4><A NAME="Sample Entry">5.2.7.13. Sample Entry</A></H4>
<PRE>
dn: olcDatabase=mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcSuffix: dc=example,dc=com
olcDbDirectory: /usr/local/var/openldap-data
olcDbIndex: objectClass eq
</PRE>
<H2><A NAME="Configuration Example">5.3. Configuration Example</A></H2>
<P>The following is an example configuration, interspersed with explanatory text. It defines two databases to handle different parts of the <TERM>X.500</TERM> tree; both are <TERM>MDB</TERM> database instances. The line numbers shown are provided for reference only and are not included in the actual file. First, the global configuration section:</P>
<PRE>
  1.    # example config file - global configuration entry
  2.    dn: cn=config
  3.    objectClass: olcGlobal
  4.    cn: config
  5.    olcReferral: ldap://root.openldap.org
  6.
</PRE>
<P>Line 1 is a comment. Lines 2-4 identify this as the global configuration entry. The <TT>olcReferral:</TT> directive on line 5 means that queries not local to one of the databases defined below will be referred to the LDAP server running on the standard port (389) at the host <TT>root.openldap.org</TT>. Line 6 is a blank line, indicating the end of this entry.</P>
<PRE>
  7.    # internal schema
  8.    dn: cn=schema,cn=config
  9.    objectClass: olcSchemaConfig
 10.    cn: schema
 11.
</PRE>
<P>Line 7 is a comment. Lines 8-10 identify this as the root of the schema subtree. The actual schema definitions in this entry are hardcoded into slapd so no additional attributes are specified here. Line 11 is a blank line, indicating the end of this entry.</P>
<PRE>
 12.    # include the core schema
 13.    include: file:///usr/local/etc/openldap/schema/core.ldif
 14.
</PRE>
<P>Line 12 is a comment. Line 13 is an LDIF include directive which accesses the <EM>core</EM> schema definitions in LDIF format. Line 14 is a blank line.</P>
<P>Next comes the database definitions. The first database is the special <TT>frontend</TT> database whose settings are applied globally to all the other databases.</P>
<PRE>
 15.    # global database parameters
 16.    dn: olcDatabase=frontend,cn=config
 17.    objectClass: olcDatabaseConfig
 18.    olcDatabase: frontend
 19.    olcAccess: to * by * read
 20.
</PRE>
<P>Line 15 is a comment. Lines 16-18 identify this entry as the global database entry. Line 19 is a global access control. It applies to all entries (after any applicable database-specific access controls). Line 20 is a blank line.</P>
<P>The next entry defines the config backend.</P>
<PRE>
 21.    # set a rootpw for the config database so we can bind.
 22.    # deny access to everyone else.
 23.    dn: olcDatabase=config,cn=config
 24.    objectClass: olcDatabaseConfig
 25.    olcDatabase: config
 26.    olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
 27.    olcAccess: to * by * none
 28.
</PRE>
<P>Lines 21-22 are comments. Lines 23-25 identify this entry as the config database entry. Line 26 defines the <EM>super-user</EM> password for this database. (The DN defaults to <EM>&quot;cn=config&quot;</EM>.) Line 27 denies all access to this database, so only the super-user will be able to access it. (This is already the default access on the config database. It is just listed here for illustration, and to reiterate that unless a means to authenticate as the super-user is explicitly configured, the config database will be inaccessible.)</P>
<P>Line 28 is a blank line.</P>
<P>The next entry defines an MDB backend that will handle queries for things in the &quot;dc=example,dc=com&quot; portion of the tree. Indices are to be maintained for several attributes, and the <TT>userPassword</TT> attribute is to be protected from unauthorized access.</P>
<PRE>
 29.    # MDB definition for example.com
 30.    dn: olcDatabase=mdb,cn=config
 31.    objectClass: olcDatabaseConfig
 32.    objectClass: olcMdbConfig
 33.    olcDatabase: mdb
 34.    olcSuffix: dc=example,dc=com
 35.    olcDbDirectory: /usr/local/var/openldap-data
 36.    olcRootDN: cn=Manager,dc=example,dc=com
 37.    olcRootPW: secret
 38.    olcDbIndex: uid pres,eq
 39.    olcDbIndex: cn,sn pres,eq,approx,sub
 40.    olcDbIndex: objectClass eq
 41.    olcAccess: to attrs=userPassword
 42.      by self write
 43.      by anonymous auth
 44.      by dn.base=&quot;cn=Admin,dc=example,dc=com&quot; write
 45.      by * none
 46.    olcAccess: to *
 47.      by self write
 48.      by dn.base=&quot;cn=Admin,dc=example,dc=com&quot; write
 49.      by * read
 50.
</PRE>
<P>Line 29 is a comment. Lines 30-33 identify this entry as a MDB database configuration entry.  Line 34 specifies the DN suffix for queries to pass to this database. Line 35 specifies the directory in which the database files will live.</P>
<P>Lines 36 and 37 identify the database <EM>super-user</EM> entry and associated password. This entry is not subject to access control or size or time limit restrictions.</P>
<P>Lines 38 through 40 indicate the indices to maintain for various attributes.</P>
<P>Lines 41 through 49 specify access control for entries in this database. For all applicable entries, the <TT>userPassword</TT> attribute is writable by the entry itself and by the &quot;admin&quot; entry.  It may be used for authentication/authorization purposes, but is otherwise not readable. All other attributes are writable by the entry and the &quot;admin&quot; entry, but may be read by all users (authenticated or not).</P>
<P>Line 50 is a blank line, indicating the end of this entry.</P>
<P>The next entry defines another MDB database. This one handles queries involving the <TT>dc=example,dc=net</TT> subtree but is managed by the same entity as the first database.  Note that without line 60, the read access would be allowed due to the global access rule at line 19.</P>
<PRE>
 51.    # MDB definition for example.net
 52.    dn: olcDatabase=mdb,cn=config
 53.    objectClass: olcDatabaseConfig
 54.    objectClass: olcMdbConfig
 55.    olcDatabase: mdb
 56.    olcSuffix: dc=example,dc=net
 57.    olcDbDirectory: /usr/local/var/openldap-data-net
 58.    olcRootDN: cn=Manager,dc=example,dc=com
 59.    olcDbIndex: objectClass eq
 60.    olcAccess: to * by users read
</PRE>
<H2><A NAME="Converting old style {{slapd.conf}}(5) file to {{cn=config}} format">5.4. Converting old style <EM>slapd.conf</EM>(5) file to <EM>cn=config</EM> format</A></H2>
<P>Before converting to the <EM>cn=config</EM> format you should make sure that the config backend is properly configured in your existing config file. While the config backend is always present inside slapd, by default it is only accessible by its rootDN, and there are no default credentials assigned so unless you explicitly configure a means to authenticate to it, it will be unusable.</P>
<P>If you do not already have a <TT>database config</TT> section, add something like this to the end of <TT>slapd.conf</TT></P>
<PRE>
 database config
 rootpw VerySecret
</PRE>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>Since the config backend can be used to load arbitrary code into the slapd process, it is extremely important to carefully guard whatever credentials are used to access it. Since simple passwords are vulnerable to password guessing attacks, it is usually better to omit the rootpw and only use SASL authentication for the config rootDN.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>An existing <EM>slapd.conf</EM>(5) file can be converted to the new format using <EM>slaptest</EM>(8) or any of the slap tools:</P>
<PRE>
        slaptest -f /usr/local/etc/openldap/slapd.conf -F /usr/local/etc/openldap/slapd.d
</PRE>
<P>Test that you can access entries under <TT>cn=config</TT> using the default <EM>rootdn</EM> and the <EM>rootpw</EM> configured above:</P>
<PRE>
        ldapsearch -x -D cn=config -w VerySecret -b cn=config
</PRE>
<P>You can then discard the old <EM>slapd.conf</EM>(5) file. Make sure to launch <EM>slapd</EM>(8) with the <EM>-F</EM> option to specify the configuration directory if you are not using the default directory path.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>When converting from the slapd.conf format to slapd.d format, any included files will also be integrated into the resulting configuration database.
<HR WIDTH="80%" ALIGN="Left"></P>
<H2><A NAME="Recovering from a broken configuration">5.5. Recovering from a broken configuration</A></H2>
<P>If the server using <EM>cn=config</EM> does not start, either because the configuration does not represent the current version or because it has been corrupted, these actions are available, in the order of decreasing preference.</P>
<P>Make sure you have made a backup of the &quot;broken&quot; version before you attempt any of these:</P>
<H3><A NAME="Generate an ldif version of the configuration database and reload from that">5.5.1. Generate an ldif version of the configuration database and reload from that</A></H3>
<P>Most of the time, the configuration can be parsed and a text version generated with <EM>slapcat</EM>(8):</P>
<PRE>
 slapcat -F /usr/local/etc/openldap/slapd.d -n0 -l extracted_config.ldif
</PRE>
<P>After you have backed up and removed the old configuration database contents, this output ldif can be hand-edited to adjust or remove the offending entries and imported again:</P>
<PRE>
 slapadd -F /usr/local/etc/openldap/slapd.d -l updated_config.ldif
 slaptest -F /usr/local/etc/openldap/slapd.d
</PRE>
<H3><A NAME="Modify config in-place">5.5.2. Modify config in-place</A></H3>
<P>If the configuration can be parsed and you know exactly what you need to do, you can use <EM>slapmodify</EM>(8) to effect the required changes directly:</P>
<PRE>
 slapmodify -F /usr/local/etc/openldap/slapd.d
 dn: ..., cn=config
 changetype: ...
 ...
</PRE>
<H3><A NAME="Recover with plain back-ldif">5.5.3. Recover with plain back-ldif</A></H3>
<P>If the configuration contains items that <EM>slapd</EM>(8) cannot process as a <EM>cn=config</EM> database at all, the last resort is to disable schema checking and operate on it as a regular back-ldif database. This might cease to work with future versions of OpenLDAP without notice, attempt this only when all of the above fail.</P>
<P>First, create a directory to serve as the hosting DB and create the structure:</P>
<PRE>
 mkdir ./recovery ./recovery/cn=recovery
 cp /usr/local/etc/openldap/slapd.d/cn=config.ldif ./recovery/cn=recovery
 cp -r /usr/local/etc/openldap/slapd.d/cn=config ./recovery/cn=recovery
</PRE>
<P>Or, if you have already backed up your old configuration, you can symlink it into place:</P>
<PRE>
 mkdir ./recovery
 ln -s /usr/local/etc/openldap/slapd.d ./recovery/cn=recovery
</PRE>
<P>Next, create a trivial <EM>slapd.conf</EM>(5) to access the new database:</P>
<PRE>
 database ldif
 suffix cn=recovery
 directory ./recovery/
</PRE>
<P>Note the change of suffix, <TT>cn=config</TT> is hardcoded to correspond to an active config database, so we have to home it one level deeper - at <TT>cn=config,cn=recovery</TT>.</P>
<P>Now you can use <EM>slapmodify</EM>(8) to modify the database, it is most likely you will need to run with schema checking disabled:</P>
<PRE>
 slapmodify -f ./recovery.conf -s
</PRE>
<P>You can test the validity of your config with <EM>slaptest</EM>(8):</P>
<PRE>
 slaptest -F ./recovery/cn=recovery
</PRE>
<P>And generate a full ldif with <EM>slapcat</EM>(8):</P>
<PRE>
 slapcat -F ./recovery/cn=recovery -n0
</PRE>
<P></P>
<HR>
<H1><A NAME="The slapd Configuration File">6. The slapd Configuration File</A></H1>
<P>This chapter describes configuring <EM>slapd</EM>(8) via the <EM>slapd.conf</EM>(5) configuration file.  <EM>slapd.conf</EM>(5) has been deprecated and should only be used if your site requires one of the backends that hasn't yet been updated to work with the newer <EM>slapd-config</EM>(5) system.  Configuring <EM>slapd</EM>(8) via <EM>slapd-config</EM>(5) is described in the previous chapter.</P>
<P>The <EM>slapd.conf</EM>(5) file is normally installed in the <TT>/usr/local/etc/openldap</TT> directory.  An alternate configuration file location can be specified via a command-line option to <EM>slapd</EM>(8).</P>
<H2><A NAME="Configuration File Format">6.1. Configuration File Format</A></H2>
<P>The <EM>slapd.conf</EM>(5) file consists of three types of configuration information: global, backend specific, and database specific.  Global information is specified first, followed by information associated with a particular backend type, which is then followed by information associated with a particular database instance.  Global directives can be overridden in backend and/or database directives, and backend directives can be overridden by database directives.</P>
<P>Blank lines and comment lines beginning with a '<TT>#</TT>' character are ignored.  If a line begins with whitespace, it is considered a continuation of the previous line (even if the previous line is a comment).</P>
<P>The general format of slapd.conf is as follows:</P>
<PRE>
        # global configuration directives
        &lt;global config directives&gt;

        # backend definition
        backend &lt;typeA&gt;
        &lt;backend-specific directives&gt;

        # first database definition &amp; config directives
        database &lt;typeA&gt;
        &lt;database-specific directives&gt;

        # second database definition &amp; config directives
        database &lt;typeB&gt;
        &lt;database-specific directives&gt;

        # second database definition &amp; config directives
        database &lt;typeA&gt;
        &lt;database-specific directives&gt;

        # subsequent backend &amp; database definitions &amp; config directives
        ...
</PRE>
<P>A configuration directive may take arguments.  If so, they are separated by whitespace.  If an argument contains whitespace, the argument should be enclosed in double quotes <TT>&quot;like this&quot;</TT>. If an argument contains a double quote or a backslash character `<TT>\</TT>', the character should be preceded by a backslash character `<TT>\</TT>'.</P>
<P>The distribution contains an example configuration file that will be installed in the <TT>/usr/local/etc/openldap</TT> directory. A number of files containing schema definitions (attribute types and object classes) are also provided in the <TT>/usr/local/etc/openldap/schema</TT> directory.</P>
<H2><A NAME="Configuration File Directives">6.2. Configuration File Directives</A></H2>
<P>This section details commonly used configuration directives.  For a complete list, see the <EM>slapd.conf</EM>(5) manual page.  This section separates the configuration file directives into global, backend-specific and data-specific categories, describing each directive and its default value (if any), and giving an example of its use.</P>
<H3><A NAME="Global Directives">6.2.1. Global Directives</A></H3>
<P>Directives described in this section apply to all backends and databases unless specifically overridden in a backend or database definition.  Arguments that should be replaced by actual text are shown in brackets <TT>&lt;&gt;</TT>.</P>
<H4><A NAME="access to &lt;what&gt; [ by &lt;who&gt; [&lt;accesslevel&gt;] [&lt;control&gt;] ]+">6.2.1.1. access to &lt;what&gt; [ by &lt;who&gt; [&lt;accesslevel&gt;] [&lt;control&gt;] ]+</A></H4>
<P>This directive grants access (specified by &lt;accesslevel&gt;) to a set of entries and/or attributes (specified by &lt;what&gt;) by one or more requestors (specified by &lt;who&gt;).  See the <A HREF="#Access Control">Access Control</A> section of this guide for basic usage.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>If no <TT>access</TT> directives are specified, the default access control policy, <TT>access to * by * read</TT>, allows all both authenticated and anonymous users read access.
<HR WIDTH="80%" ALIGN="Left"></P>
<H4><A NAME="attributetype &lt;{{REF:RFC4512}} Attribute Type Description&gt;"> </A>6.2.1.2. attributetype &lt;<A HREF="https://www.rfc-editor.org/rfc/rfc4512.txt">RFC4512</A> Attribute Type Description&gt;</H4>
<P>This directive defines an attribute type. Please see the <A HREF="#Schema Specification">Schema Specification</A> chapter for information regarding how to use this directive.</P>
<H4><A NAME="idletimeout &lt;integer&gt;">6.2.1.3. idletimeout &lt;integer&gt;</A></H4>
<P>Specify the number of seconds to wait before forcibly closing an idle client connection.  An idletimeout of 0, the default, disables this feature.</P>
<H4><A NAME="include &lt;filename&gt;">6.2.1.4. include &lt;filename&gt;</A></H4>
<P>This directive specifies that slapd should read additional configuration information from the given file before continuing with the next line of the current file. The included file should follow the normal slapd config file format.  The file is commonly used to include files containing schema specifications.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>You should be careful when using this directive - there is no small limit on the number of nested include directives, and no loop detection is done.
<HR WIDTH="80%" ALIGN="Left"></P>
<H4><A NAME="loglevel &lt;level&gt;">6.2.1.5. loglevel &lt;level&gt;</A></H4>
<P>This directive specifies the level at which log statements and operation statistics should be sent to syslog (currently logged to the <EM>syslogd</EM>(8) <TT>LOG_LOCAL4</TT> facility). You must have configured OpenLDAP <TT>--enable-debug</TT> (the default) for this to work, except for the two statistics levels, which are always enabled. Log levels may be specified as integers or by keyword. Multiple log levels may be used and the levels are additive. The possible values for &lt;integer&gt; are:</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 6.1: Logging Levels</CAPTION>
<TR CLASS="heading">
<TD ALIGN='Right'>
<STRONG>Level</STRONG>
</TD>
<TD ALIGN='Left'>
<STRONG>Keyword</STRONG>
</TD>
<TD>
<STRONG>Description</STRONG>
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
-1
</TD>
<TD ALIGN='Left'>
any
</TD>
<TD>
enable all debugging
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
0
</TD>
<TD ALIGN='Left'>
&nbsp;
</TD>
<TD>
no debugging
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
1
</TD>
<TD ALIGN='Left'>
(0x1 trace)
</TD>
<TD>
trace function calls
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
2
</TD>
<TD ALIGN='Left'>
(0x2 packets)
</TD>
<TD>
debug packet handling
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
4
</TD>
<TD ALIGN='Left'>
(0x4 args)
</TD>
<TD>
heavy trace debugging
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
8
</TD>
<TD ALIGN='Left'>
(0x8 conns)
</TD>
<TD>
connection management
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
16
</TD>
<TD ALIGN='Left'>
(0x10 BER)
</TD>
<TD>
print out packets sent and received
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
32
</TD>
<TD ALIGN='Left'>
(0x20 filter)
</TD>
<TD>
search filter processing
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
64
</TD>
<TD ALIGN='Left'>
(0x40 config)
</TD>
<TD>
configuration processing
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
128
</TD>
<TD ALIGN='Left'>
(0x80 ACL)
</TD>
<TD>
access control list processing
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
256
</TD>
<TD ALIGN='Left'>
(0x100 stats)
</TD>
<TD>
stats log connections/operations/results
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
512
</TD>
<TD ALIGN='Left'>
(0x200 stats2)
</TD>
<TD>
stats log entries sent
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
1024
</TD>
<TD ALIGN='Left'>
(0x400 shell)
</TD>
<TD>
print communication with shell backends
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
2048
</TD>
<TD ALIGN='Left'>
(0x800 parse)
</TD>
<TD>
print entry parsing debugging
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
16384
</TD>
<TD ALIGN='Left'>
(0x4000 sync)
</TD>
<TD>
syncrepl consumer processing
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
32768
</TD>
<TD ALIGN='Left'>
(0x8000 none)
</TD>
<TD>
only messages that get logged regardless of configured log level
</TD>
</TR>
</TABLE>

<P>The desired log level can be input as a single integer that combines the (ORed) desired levels, both in decimal or in hexadecimal notation, as a list of integers (that are ORed internally), or as a list of the names that are shown between brackets, such that</P>
<PRE>
                loglevel 129
                loglevel 0x81
                loglevel 128 1
                loglevel 0x80 0x1
                loglevel acl trace
</PRE>
<P>are equivalent.</P>
<P>Examples:</P>
<PRE>
 loglevel -1
</PRE>
<P>This will enable all log levels.</P>
<PRE>
 loglevel conns filter
</PRE>
<P>Just log the connection and search filter processing.</P>
<PRE>
 loglevel none
</PRE>
<P>Log those messages that are logged regardless of the configured loglevel. This differs from setting the log level to 0, when no logging occurs. At least the <TT>None</TT> level is required to have high priority messages logged.</P>
<P>Default:</P>
<PRE>
 loglevel stats
</PRE>
<P>Basic stats logging is configured by default.</P>
<H4><A NAME="objectclass &lt;{{REF:RFC4512}} Object Class Description&gt;"> </A>6.2.1.6. objectclass &lt;<A HREF="https://www.rfc-editor.org/rfc/rfc4512.txt">RFC4512</A> Object Class Description&gt;</H4>
<P>This directive defines an object class. Please see the <A HREF="#Schema Specification">Schema Specification</A> chapter for information regarding how to use this directive.</P>
<H4><A NAME="referral &lt;URI&gt;">6.2.1.7. referral &lt;URI&gt;</A></H4>
<P>This directive specifies the referral to pass back when slapd cannot find a local database to handle a request.</P>
<P>Example:</P>
<PRE>
        referral ldap://root.openldap.org
</PRE>
<P>This will refer non-local queries to the global root LDAP server at the OpenLDAP Project. Smart LDAP clients can re-ask their query at that server, but note that most of these clients are only going to know how to handle simple LDAP URLs that contain a host part and optionally a distinguished name part.</P>
<H4><A NAME="sizelimit &lt;integer&gt;">6.2.1.8. sizelimit &lt;integer&gt;</A></H4>
<P>This directive specifies the maximum number of entries to return from a search operation.</P>
<P>Default:</P>
<PRE>
        sizelimit 500
</PRE>
<P>See the <A HREF="#Limits">Limits</A> section of this guide and <EM>slapd.conf</EM>(5) for more details.</P>
<H4><A NAME="timelimit &lt;integer&gt;">6.2.1.9. timelimit &lt;integer&gt;</A></H4>
<P>This directive specifies the maximum number of seconds (in real time) slapd will spend answering a search request. If a request is not finished in this time, a result indicating an exceeded timelimit will be returned.</P>
<P>Default:</P>
<PRE>
        timelimit 3600
</PRE>
<P>See the <A HREF="#Limits">Limits</A> section of this guide and <EM>slapd.conf</EM>(5) for more details.</P>
<H3><A NAME="General Backend Directives">6.2.2. General Backend Directives</A></H3>
<P>Directives in this section apply only to the backend in which they are defined. They are supported by every type of backend. Backend directives apply to all databases instances of the same type and, depending on the directive, may be overridden by database directives.</P>
<H4><A NAME="backend &lt;type&gt;">6.2.2.1. backend &lt;type&gt;</A></H4>
<P>This directive marks the beginning of a backend declaration. <TT>&lt;type&gt;</TT> should be one of the supported backend types listed in Table 6.2.</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 6.2: Database Backends</CAPTION>
<TR CLASS="heading">
<TD>
<STRONG>Types</STRONG>
</TD>
<TD>
<STRONG>Description</STRONG>
</TD>
</TR>
<TR>
<TD>
<TT>asyncmet</TT>
</TD>
<TD>
a       Asynchronous Metadirectory backend
</TD>
</TR>
<TR>
<TD>
<TT>config</TT>
</TD>
<TD>
Slapd configuration backend
</TD>
</TR>
<TR>
<TD>
<TT>dnssrv</TT>
</TD>
<TD>
DNS SRV backend
</TD>
</TR>
<TR>
<TD>
<TT>ldap</TT>
</TD>
<TD>
Lightweight Directory Access Protocol (Proxy) backend
</TD>
</TR>
<TR>
<TD>
<TT>ldif</TT>
</TD>
<TD>
Lightweight Data Interchange Format backend
</TD>
</TR>
<TR>
<TD>
<TT>mdb</TT>
</TD>
<TD>
Memory-Mapped DB backend
</TD>
</TR>
<TR>
<TD>
<TT>meta</TT>
</TD>
<TD>
Metadirectory backend
</TD>
</TR>
<TR>
<TD>
<TT>monitor</TT>
</TD>
<TD>
Monitor backend
</TD>
</TR>
<TR>
<TD>
<TT>ndb</TT>
</TD>
<TD>
MySQL NDB backend
</TD>
</TR>
<TR>
<TD>
<TT>null</TT>
</TD>
<TD>
Null backend
</TD>
</TR>
<TR>
<TD>
<TT>passwd</TT>
</TD>
<TD>
Provides read-only access to <EM>passwd</EM>(5)
</TD>
</TR>
<TR>
<TD>
<TT>perl</TT>
</TD>
<TD>
Perl Programmable backend
</TD>
</TR>
<TR>
<TD>
<TT>relay</TT>
</TD>
<TD>
Relay backend
</TD>
</TR>
<TR>
<TD>
<TT>sock</TT>
</TD>
<TD>
Socket backend
</TD>
</TR>
<TR>
<TD>
<TT>sql</TT>
</TD>
<TD>
SQL Programmable backend
</TD>
</TR>
<TR>
<TD>
<TT>wt</TT>
</TD>
<TD>
WiredTiger backend
</TD>
</TR>
</TABLE>

<P>Example:</P>
<PRE>
        backend mdb
        idlexp 16
</PRE>
<P>This marks the beginning of a new <TERM>MDB</TERM> backend definition. At present, only back-mdb implements any options of this type, so this setting is not needed for any other backends.</P>
<H3><A NAME="General Database Directives">6.2.3. General Database Directives</A></H3>
<P>Directives in this section apply only to the database in which they are defined. They are supported by every type of database.</P>
<H4><A NAME="database &lt;type&gt;">6.2.3.1. database &lt;type&gt;</A></H4>
<P>This directive marks the beginning of a database instance declaration. <TT>&lt;type&gt;</TT> should be one of the supported backend types listed in Table 6.2.</P>
<P>Example:</P>
<PRE>
        database mdb
</PRE>
<P>This marks the beginning of a new <TERM>MDB</TERM> database instance declaration.</P>
<H4><A NAME="limits &lt;selector&gt; &lt;limit&gt; [&lt;limit&gt; [...]]">6.2.3.2. limits &lt;selector&gt; &lt;limit&gt; [&lt;limit&gt; [...]]</A></H4>
<P>Specify time and size limits based on the operation's initiator or base DN.</P>
<P>See the <A HREF="#Limits">Limits</A> section of this guide and <EM>slapd.conf</EM>(5) for more details.</P>
<H4><A NAME="readonly { on | off }">6.2.3.3. readonly { on | off }</A></H4>
<P>This directive puts the database into &quot;read-only&quot; mode. Any attempts to modify the database will return an &quot;unwilling to perform&quot; error.  If set on a consumer, modifications sent by syncrepl will still occur.</P>
<P>Default:</P>
<PRE>
        readonly off
</PRE>
<H4><A NAME="rootdn &lt;DN&gt;">6.2.3.4. rootdn &lt;DN&gt;</A></H4>
<P>This directive specifies the DN that is not subject to access control or administrative limit restrictions for operations on this database.  The DN need not refer to an entry in this database or even in the directory. The DN may refer to a SASL identity.</P>
<P>Entry-based Example:</P>
<PRE>
        rootdn &quot;cn=Manager,dc=example,dc=com&quot;
</PRE>
<P>SASL-based Example:</P>
<PRE>
        rootdn &quot;uid=root,cn=example.com,cn=digest-md5,cn=auth&quot;
</PRE>
<P>See the <A HREF="#SASL Authentication">SASL Authentication</A> section for information on SASL authentication identities.</P>
<H4><A NAME="rootpw &lt;password&gt;">6.2.3.5. rootpw &lt;password&gt;</A></H4>
<P>This directive can be used to specifies a password for the DN for the rootdn (when the rootdn is set to a DN within the database).</P>
<P>Example:</P>
<PRE>
        rootpw secret
</PRE>
<P>It is also permissible to provide hash of the password in <A HREF="https://www.rfc-editor.org/rfc/rfc2307.txt">RFC2307</A> form.  <EM>slappasswd</EM>(8) may be used to generate the password hash.</P>
<P>Example:</P>
<PRE>
        rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
</PRE>
<P>The hash was generated using the command <TT>slappasswd -s secret</TT>.</P>
<H4><A NAME="suffix &lt;dn suffix&gt;">6.2.3.6. suffix &lt;dn suffix&gt;</A></H4>
<P>This directive specifies the DN suffix of queries that will be passed to this backend database. Multiple suffix lines can be given, and at least one is required for each database definition.</P>
<P>Example:</P>
<PRE>
        suffix &quot;dc=example,dc=com&quot;
</PRE>
<P>Queries with a DN ending in &quot;dc=example,dc=com&quot; will be passed to this backend.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>When the backend to pass a query to is selected, slapd looks at the suffix line(s) in each database definition in the order they appear in the file. Thus, if one database suffix is a prefix of another, it must appear after it in the config file.
<HR WIDTH="80%" ALIGN="Left"></P>
<H4><A NAME="syncrepl">6.2.3.7. syncrepl</A></H4>
<PRE>
        syncrepl rid=&lt;replica ID&gt;
                provider=ldap[s]://&lt;hostname&gt;[:port]
                searchbase=&lt;base DN&gt;
                [type=refreshOnly|refreshAndPersist]
                [interval=dd:hh:mm:ss]
                [retry=[&lt;retry interval&gt; &lt;# of retries&gt;]+]
                [filter=&lt;filter str&gt;]
                [scope=sub|one|base]
                [attrs=&lt;attr list&gt;]
                [exattrs=&lt;attr list&gt;]
                [attrsonly]
                [sizelimit=&lt;limit&gt;]
                [timelimit=&lt;limit&gt;]
                [schemachecking=on|off]
                [network-timeout=&lt;seconds&gt;]
                [timeout=&lt;seconds&gt;]
                [bindmethod=simple|sasl]
                [binddn=&lt;DN&gt;]
                [saslmech=&lt;mech&gt;]
                [authcid=&lt;identity&gt;]
                [authzid=&lt;identity&gt;]
                [credentials=&lt;passwd&gt;]
                [realm=&lt;realm&gt;]
                [secprops=&lt;properties&gt;]
                [keepalive=&lt;idle&gt;:&lt;probes&gt;:&lt;interval&gt;]
                [starttls=yes|critical]
                [tls_cert=&lt;file&gt;]
                [tls_key=&lt;file&gt;]
                [tls_cacert=&lt;file&gt;]
                [tls_cacertdir=&lt;path&gt;]
                [tls_reqcert=never|allow|try|demand]
                [tls_cipher_suite=&lt;ciphers&gt;]
                [tls_crlcheck=none|peer|all]
                [tls_protocol_min=&lt;major&gt;[.&lt;minor&gt;]]
                [suffixmassage=&lt;real DN&gt;]
                [logbase=&lt;base DN&gt;]
                [logfilter=&lt;filter str&gt;]
                [syncdata=default|accesslog|changelog]
</PRE>
<P>This directive specifies the current database as a consumer of the provider content by establishing the current <EM>slapd</EM>(8) as a replication consumer site running a syncrepl replication engine. The provider database is located at the replication provider site specified by the <TT>provider</TT> parameter. The consumer database is kept up-to-date with the provider content using the LDAP Content Synchronization protocol. See <A HREF="https://www.rfc-editor.org/rfc/rfc4533.txt">RFC4533</A> for more information on the protocol.</P>
<P>The <TT>rid</TT> parameter is used for identification of the current <TT>syncrepl</TT> directive within the replication consumer server, where <TT>&lt;replica ID&gt;</TT> uniquely identifies the syncrepl specification described by the current <TT>syncrepl</TT> directive. <TT>&lt;replica ID&gt;</TT> is non-negative and is no more than three decimal digits in length.</P>
<P>The <TT>provider</TT> parameter specifies the replication provider site containing the provider content as an LDAP URI. The <TT>provider</TT> parameter specifies a scheme, a host and optionally a port where the provider slapd instance can be found. Either a domain name or IP address may be used for &lt;hostname&gt;. Examples are <TT>ldap://provider.example.com:389</TT> or <TT>ldaps://192.168.1.1:636</TT>. If &lt;port&gt; is not given, the standard LDAP port number (389 or 636) is used. Note that the syncrepl uses a consumer-initiated protocol, and hence its specification is located on the consumer.</P>
<P>The content of the syncrepl consumer is defined using a search specification as its result set. The consumer slapd will send search requests to the provider slapd according to the search specification. The search specification includes <TT>searchbase</TT>, <TT>scope</TT>, <TT>filter</TT>, <TT>attrs</TT>, <TT>exattrs</TT>, <TT>attrsonly</TT>, <TT>sizelimit</TT>, and <TT>timelimit</TT> parameters as in the normal search specification. The <TT>searchbase</TT> parameter has no default value and must always be specified. The <TT>scope</TT> defaults to <TT>sub</TT>, the <TT>filter</TT> defaults to <TT>(objectclass=*)</TT>, <TT>attrs</TT> defaults to <TT>&quot;*,+&quot;</TT> to replicate all user and operational attributes, and <TT>attrsonly</TT> is unset by default. Both <TT>sizelimit</TT> and <TT>timelimit</TT> default to &quot;unlimited&quot;, and only positive integers or &quot;unlimited&quot; may be specified. The <TT>exattrs</TT> option may also be used to specify attributes that should be omitted from incoming entries.</P>
<P>The <TERM>LDAP Content Synchronization</TERM> protocol has two operation types: <TT>refreshOnly</TT> and <TT>refreshAndPersist</TT>. The operation type is specified by the <TT>type</TT> parameter. In the <TT>refreshOnly</TT> operation, the next synchronization search operation is periodically rescheduled at an interval time after each synchronization operation finishes. The interval is specified by the <TT>interval</TT> parameter. It is set to one day by default. In the <TT>refreshAndPersist</TT> operation, a synchronization search remains persistent in the provider <EM>slapd</EM> instance. Further updates to the provider will generate <TT>searchResultEntry</TT> to the consumer slapd as the search responses to the persistent synchronization search.</P>
<P>If an error occurs during replication, the consumer will attempt to reconnect according to the retry parameter which is a list of the &lt;retry interval&gt; and &lt;# of retries&gt; pairs. For example, retry=&quot;60 10 300 3&quot; lets the consumer retry every 60 seconds for the first 10 times and then retry every 300 seconds for the next three times before stop retrying. + in &lt;#  of retries&gt; means indefinite number of retries until success.</P>
<P>The schema checking can be enforced at the LDAP Sync consumer site by turning on the <TT>schemachecking</TT> parameter. If it is turned on, every replicated entry will be checked for its schema as the entry is stored on the consumer. Every entry in the consumer should contain those attributes required by the schema definition. If it is turned off, entries will be stored without checking schema conformance. The default is off.</P>
<P>The <TT>network-timeout</TT> parameter sets how long the consumer will wait to establish a network connection to the provider.  Once a connection is established, the <TT>timeout</TT> parameter determines how long the consumer will wait for the initial Bind request to complete.  The defaults for these parameters come from <EM>ldap.conf</EM>(5).</P>
<P>The <TT>binddn</TT> parameter gives the DN to bind as for the syncrepl searches to the provider slapd. It should be a DN which has read access to the replication content in the provider database.</P>
<P>The <TT>bindmethod</TT> is <TT>simple</TT> or <TT>sasl</TT>, depending on whether simple password-based authentication or <TERM>SASL</TERM> authentication is to be used when connecting to the provider <EM>slapd</EM> instance.</P>
<P>Simple authentication should not be used unless adequate data integrity and confidentiality protections are in place (e.g. TLS or IPsec). Simple authentication requires specification of <TT>binddn</TT> and <TT>credentials</TT> parameters.</P>
<P>SASL authentication is generally recommended.  SASL authentication requires specification of a mechanism using the <TT>saslmech</TT> parameter. Depending on the mechanism, an authentication identity and/or credentials can be specified using <TT>authcid</TT> and <TT>credentials</TT>, respectively.  The <TT>authzid</TT> parameter may be used to specify an authorization identity.</P>
<P>The <TT>realm</TT> parameter specifies a realm which a certain mechanisms authenticate the identity within. The <TT>secprops</TT> parameter specifies Cyrus SASL security properties.</P>
<P>The <TT>keepalive</TT> parameter sets the values of idle, probes, and interval used to check whether a socket is alive;  idle is the number of seconds a connection needs to remain idle before TCP starts sending keepalive probes; probes is the maximum number of keepalive probes TCP should send before dropping the connection; interval is interval in seconds between individual keepalive probes.  Only some systems support the customization of these values; the keepalive parameter is ignored otherwise, and system-wide settings are used. For example, keepalive=&quot;240:10:30&quot; will send a keepalive probe 10 times, every 30 seconds, after 240 seconds of idle activity.  If no response to the probes is received, the connection will be dropped.</P>
<P>The <TT>starttls</TT> parameter specifies use of the StartTLS extended operation to establish a TLS session before authenticating to the provider. If the <TT>critical</TT> argument is supplied, the session will be aborted if the StartTLS request fails.  Otherwise the syncrepl session continues without TLS.  The tls_reqcert setting defaults to <TT>&quot;demand&quot;</TT> and the other TLS settings default to the same as the main slapd TLS settings.</P>
<P>The <TT>suffixmassage</TT> parameter allows the consumer to pull entries from a remote directory whose DN suffix differs from the local directory. The portion of the remote entries' DNs that matches the searchbase will be replaced with the suffixmassage DN.</P>
<P>Rather than replicating whole entries, the consumer can query logs of data modifications.  This mode of operation is referred to as <EM>delta syncrepl</EM>.  In addition to the above parameters, the <TT>logbase</TT> and <TT>logfilter</TT> parameters must be set appropriately for the log that will be used. The <TT>syncdata</TT> parameter must be set to either <TT>&quot;accesslog&quot;</TT> if the log conforms to the <EM>slapo-accesslog</EM>(5) log format, or <TT>&quot;changelog&quot;</TT> if the log conforms to the obsolete <EM>changelog</EM> format. If the <TT>syncdata</TT> parameter is omitted or set to <TT>&quot;default&quot;</TT> then the log parameters are ignored.</P>
<P>The <EM>syncrepl</EM> replication mechanism is supported by the <EM>mdb</EM> backend.</P>
<P>See the <A HREF="#LDAP Sync Replication">LDAP Sync Replication</A> chapter of this guide for more information on how to use this directive.</P>
<H4><A NAME="updateref &lt;URL&gt;">6.2.3.8. updateref &lt;URL&gt;</A></H4>
<P>This directive is only applicable in a <EM>replica</EM> (or <EM>shadow</EM>) <EM>slapd</EM>(8) instance. It specifies the URL to return to clients which submit update requests upon the replica. If specified multiple times, each <TERM>URL</TERM> is provided.</P>
<P>Example:</P>
<PRE>
        updateref       ldap://provider.example.net
</PRE>
<H3><A NAME="MDB Backend Directives">6.2.4. MDB Backend Directives</A></H3>
<P>Directives in this category only apply to the <TERM>MDB</TERM> database backend. They will apply to all &quot;database mdb&quot; instances in the configuration. For a complete reference of MDB backend configuration directives, see <EM>slapd-mdb</EM>(5).</P>
<H4><A NAME="idlexp &lt;exponent&gt;">6.2.4.1. idlexp &lt;exponent&gt;</A></H4>
<P>Specify a power of 2 for the maximum size of an index slot. The default is 16, yielding a maximum slot size of 2^16 or 65536. The specified value must be in the range of 16-31.</P>
<P>This setting helps with the case where certain search filters are slow to return results due to an index slot having collapsed to a range value.  This occurs when the number of candidate entries that match the filter for the index slot exceed the configured slot size.</P>
<P>If this setting is decreased on a server with existing <TERM>MDB</TERM> databases, each db will immediately need its indices to be rebuilt while slapd is offline with the &quot;slapindex -q -t&quot; command.</P>
<P>If this setting is increased on a server with existing <TERM>MDB</TERM> databases, each db will need its indices rebuilt to take advantage of the change for indices that have already been converted to ranges.</P>
<H3><A NAME="MDB Database Directives">6.2.5. MDB Database Directives</A></H3>
<P>Directives in this category only apply to the <TERM>MDB</TERM> database backend. That is, they must follow a &quot;database mdb&quot; line and come before any subsequent &quot;backend&quot; or &quot;database&quot; lines. For a complete reference of MDB configuration directives, see <EM>slapd-mdb</EM>(5).</P>
<H4><A NAME="directory &lt;directory&gt;">6.2.5.1. directory &lt;directory&gt;</A></H4>
<P>This directive specifies the directory where the MDB files containing the database and associated indices live.</P>
<P>Default:</P>
<PRE>
        directory /usr/local/var/openldap-data
</PRE>
<H4><A NAME="checkpoint &lt;kbyte&gt; &lt;min&gt;">6.2.5.2. checkpoint &lt;kbyte&gt; &lt;min&gt;</A></H4>
<P>This directive specifies the frequency for flushing the database disk buffers. This directive is only needed if the <EM>dbnosync</EM> option is <TT>TRUE</TT>. The checkpoint will occur if either &lt;kbyte&gt; data has been written or &lt;min&gt; minutes have passed since the last checkpoint. Both arguments default to zero, in which case they are ignored. When the &lt;min&gt; argument is non-zero, an internal task will run every &lt;min&gt; minutes to perform the checkpoint. Note: currently the _kbyte_ setting is unimplemented.</P>
<P>Example:</P>
<PRE>
   checkpoint: 1024 10
</PRE>
<H4><A NAME="dbnosync: { TRUE | FALSE }">6.2.5.3. dbnosync: { TRUE | FALSE }</A></H4>
<P>This directive causes on-disk database contents to not be immediately synchronized with in memory changes upon change.  Setting this option to <TT>TRUE</TT> may improve performance at the expense of data integrity.</P>
<H4><A NAME="envflags: {nosync,nometasync,writemap,mapasync,nordahead}">6.2.5.4. envflags: {nosync,nometasync,writemap,mapasync,nordahead}</A></H4>
<P>This option specifies flags for finer-grained control of  the  LMDB  library's operation.</P>
<UL>
<LI><TT>nosync</TT>: This is exactly the same as the dbnosync directive.
<LI><TT>nometasync</TT>: Flush the data on a commit, but skip the sync of the meta page. This mode is slightly faster than doing a full sync, but can potentially lose the last committed transaction if the operating system crashes. If both nometasync and nosync are set, the nosync flag takes precedence.
<LI><TT>writemap</TT>: Use a writable memory map instead of just read-only. This speeds up write operations but makes the database vulnerable to corruption in case any bugs in slapd cause stray writes into the mmap region.
<LI><TT>mapasync</TT>: When using a writable memory map and performing flushes on each commit, use an asynchronous flush instead of a synchronous flush (the default). This option has no effect if writemap has not been set. It also has no effect if nosync is set.
<LI><TT>nordahead</TT>: Turn off file readahead. Usually the OS performs readahead on every read request. This usually boosts read performance but can be harmful to random access read performance if the system's memory is full and the DB is larger than RAM. This option is not implemented on Windows.</UL>
<H4><A NAME="index: {&lt;attrlist&gt; | default} [pres,eq,approx,sub,none]">6.2.5.5. index: {&lt;attrlist&gt; | default} [pres,eq,approx,sub,none]</A></H4>
<P>This directive specifies the indices to maintain for the given attribute. If only an <TT>&lt;attrlist&gt;</TT> is given, the default indices are maintained. The index keywords correspond to the common types of matches that may be used in an LDAP search filter.</P>
<P>Example:</P>
<PRE>
   index: default pres,eq
   index: uid
   index: cn,sn pres,eq,sub
   index: objectClass eq
</PRE>
<P>The first line sets the default set of indices to maintain to present and equality.  The second line causes the default (pres,eq) set of indices to be maintained for the <TT>uid</TT> attribute type. The third line causes present, equality, and substring indices to be maintained for <TT>cn</TT> and <TT>sn</TT> attribute types.  The fourth line causes an equality index for the <TT>objectClass</TT> attribute type.</P>
<P>There is no index keyword for inequality matches. Generally these matches do not use an index. However, some attributes do support indexing for inequality matches, based on the equality index.</P>
<P>A substring index can be more explicitly specified as <TT>subinitial</TT>, <TT>subany</TT>, or <TT>subfinal</TT>, corresponding to the three possible components of a substring match filter. A subinitial index only indexes substrings that appear at the beginning of an attribute value. A subfinal index only indexes substrings that appear at the end of an attribute value, while subany indexes substrings that occur anywhere in a value.</P>
<P>Note that by default, setting an index for an attribute also affects every subtype of that attribute. E.g., setting an equality index on the <TT>name</TT> attribute causes <TT>cn</TT>, <TT>sn</TT>, and every other attribute that inherits from <TT>name</TT> to be indexed.</P>
<P>By default, no indices are maintained.  It is generally advised that minimally an equality index upon objectClass be maintained.</P>
<PRE>
   index: objectClass eq
</PRE>
<P>Additional indices should be configured corresponding to the most common searches that are used on the database. Presence indexing should not be configured for an attribute unless the attribute occurs very rarely in the database, and presence searches on the attribute occur very frequently during normal use of the directory. Most applications don't use presence searches, so usually presence indexing is not very useful.</P>
<H4><A NAME="maxentrysize: &lt;bytes&gt;">6.2.5.6. maxentrysize: &lt;bytes&gt;</A></H4>
<P>Specify the maximum size of an entry in bytes. Attempts to store an entry larger than this size will be rejected with the error LDAP_ADMINLIMIT_EXCEEDED. The default is 0, which is unlimited.</P>
<H4><A NAME="maxreaders: &lt;integer&gt;">6.2.5.7. maxreaders: &lt;integer&gt;</A></H4>
<P>This directive specifies the maximum number of threads that may have concurrent read access to the database. Tools such as slapcat count as a single thread, in addition to threads in any active slapd processes. The default is 126.</P>
<H4><A NAME="maxsize: &lt;bytes&gt;">6.2.5.8. maxsize: &lt;bytes&gt;</A></H4>
<P>This directive specifies the maximum size of the database in bytes. A memory map of this size is allocated at startup time and the database will not be allowed to grow beyond this size. The default is 10485760 bytes (10MB). This setting may be changed upward if the configured limit needs to be increased.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>It is important to set this to as large a value as possible, (relative to anticipated growth of the actual data over time) since growing the size later may not be practical when the system is under heavy load.
<HR WIDTH="80%" ALIGN="Left"></P>
<H4><A NAME="mode: { &lt;octal&gt; | &lt;symbolic&gt; }">6.2.5.9. mode: { &lt;octal&gt; | &lt;symbolic&gt; }</A></H4>
<P>This directive specifies the file protection mode that newly created database index files should have. This can be in the form <TT>0600</TT> or <TT>-rw-------</TT></P>
<P>Default:</P>
<PRE>
   mode: 0600
</PRE>
<H4><A NAME="multival: { &lt;attrlist&gt; | default } &lt;integer&gt; hi,&lt;integer&gt; lo">6.2.5.10. multival: { &lt;attrlist&gt; | default } &lt;integer&gt; hi,&lt;integer&gt; lo</A></H4>
<P>Specify the number of values for which a multivalued attribute is stored in a separate table. Normally entries are stored as a single blob inside the database. When an entry gets very large or contains attributes with a very large number of values, modifications on that entry may get very slow. Splitting the large attributes out to a separate table can improve the performance of modification operations. The threshold is specified as a pair of integers. If the number of values exceeds the hi threshold the values will be split out. If a modification deletes enough values to bring an attribute below the lo threshold the values will be removed from the separate table and merged back into the main entry blob. The threshold can be set for a specific list of attributes, or the default can be configured for all other attributes. The default value for both hi and lo thresholds is UINT_MAX, which keeps all attributes in the main blob.</P>
<P>In addition to increasing write performance of operations the use of multival can also decrease fragmentation of the primary <TERM>MDB</TERM> database.</P>
<H4><A NAME="rtxnsize: &lt;entries&gt;">6.2.5.11. rtxnsize: &lt;entries&gt;</A></H4>
<P>This directive specifies the maximum number of entries to process in a single read transaction when executing a large search. Long-lived read transactions prevent old database pages from being reused in write transactions, and so can cause significant growth of the database file when there is heavy write traffic. This setting causes the read transaction in large searches to be released and reacquired after the given number of entries has been read, to give writers the opportunity to reclaim old database pages. The default is 10000.</P>
<H4><A NAME="searchstack: &lt;integer&gt;">6.2.5.12. searchstack: &lt;integer&gt;</A></H4>
<P>Specify the depth of the stack used for search filter evaluation. Search filters are evaluated on a stack to accommodate nested <TT>AND</TT> / <TT>OR</TT> clauses. An individual stack is allocated for each server thread. The depth of the stack determines how complex a filter can be evaluated without requiring any additional memory allocation. Filters that are nested deeper than the search stack depth will cause a separate stack to be allocated for that particular search operation. These separate allocations can have a major negative impact on server performance, but specifying too much stack will also consume a great deal of memory. Each search uses 512K bytes per level on a 32-bit machine, or 1024K bytes per level on a 64-bit machine. The default stack depth is 16, thus 8MB or 16MB per thread is used on 32 and 64 bit machines, respectively. Also the 512KB size of a single stack slot is set by a compile-time constant which may be changed if needed; the code must be recompiled for the change to take effect.</P>
<P>Default:</P>
<PRE>
   searchstack: 16
</PRE>
<H4><A NAME="Sample Entry">6.2.5.13. Sample Entry</A></H4>
<PRE>
database mdb
suffix: &quot;dc=example,dc=com&quot;
directory: /usr/local/var/openldap-data
index: objectClass eq
</PRE>
<H2><A NAME="Configuration File Example">6.3. Configuration File Example</A></H2>
<P>The following is an example configuration file, interspersed with explanatory text. It defines two databases to handle different parts of the <TERM>X.500</TERM> tree; both are <TERM>MDB</TERM> database instances. The line numbers shown are provided for reference only and are not included in the actual file. First, the global configuration section:</P>
<PRE>
  1.    # example config file - global configuration section
  2.    include /usr/local/etc/schema/core.schema
  3.    referral ldap://root.openldap.org
  4.    access to * by * read
</PRE>
<P>Line 1 is a comment. Line 2 includes another config file which contains <EM>core</EM> schema definitions. The <TT>referral</TT> directive on line 3 means that queries not local to one of the databases defined below will be referred to the LDAP server running on the standard port (389) at the host <TT>root.openldap.org</TT>.</P>
<P>Line 4 is a global access control.  It applies to all entries (after any applicable database-specific access controls).</P>
<P>The next section of the configuration file defines a MDB backend that will handle queries for things in the &quot;dc=example,dc=com&quot; portion of the tree. The database is to be replicated to two replica slapds, one on truelies, the other on judgmentday. Indices are to be maintained for several attributes, and the <TT>userPassword</TT> attribute is to be protected from unauthorized access.</P>
<PRE>
  5.    # MDB definition for the example.com
  6.    database mdb
  7.    suffix &quot;dc=example,dc=com&quot;
  8.    directory /usr/local/var/openldap-data
  9.    rootdn &quot;cn=Manager,dc=example,dc=com&quot;
 10.    rootpw secret
 11.    # indexed attribute definitions
 12.    index uid pres,eq
 13.    index cn,sn pres,eq,approx,sub
 14.    index objectClass eq
 15.    # database access control definitions
 16.    access to attrs=userPassword
 17.        by self write
 18.        by anonymous auth
 19.        by dn.base=&quot;cn=Admin,dc=example,dc=com&quot; write
 20.        by * none
 21.    access to *
 22.        by self write
 23.        by dn.base=&quot;cn=Admin,dc=example,dc=com&quot; write
 24.        by * read
</PRE>
<P>Line 5 is a comment. The start of the database definition is marked by the database keyword on line 6. Line 7 specifies the DN suffix for queries to pass to this database. Line 8 specifies the directory in which the database files will live.</P>
<P>Lines 9 and 10 identify the database <EM>super-user</EM> entry and associated password. This entry is not subject to access control or size or time limit restrictions.</P>
<P>Lines 12 through 14 indicate the indices to maintain for various attributes.</P>
<P>Lines 16 through 24 specify access control for entries in this database. For all applicable entries, the <TT>userPassword</TT> attribute is writable by the entry itself and by the &quot;admin&quot; entry.  It may be used for authentication/authorization purposes, but is otherwise not readable. All other attributes are writable by the entry and the &quot;admin&quot; entry, but may be read by all users (authenticated or not).</P>
<P>The next section of the example configuration file defines another MDB database. This one handles queries involving the <TT>dc=example,dc=net</TT> subtree but is managed by the same entity as the first database.  Note that without line 39, the read access would be allowed due to the global access rule at line 4.</P>
<PRE>
 33.    # MDB definition for example.net
 34.    database mdb
 35.    suffix &quot;dc=example,dc=net&quot;
 36.    directory /usr/local/var/openldap-data-net
 37.    rootdn &quot;cn=Manager,dc=example,dc=com&quot;
 38.    index objectClass eq
 39.    access to * by users read
</PRE>
<P></P>
<HR>
<H1><A NAME="Running slapd">7. Running slapd</A></H1>
<P><EM>slapd</EM>(8) is designed to be run as a standalone service.  This allows the server to take advantage of caching, manage concurrency issues with underlying databases, and conserve system resources. Running from <EM>inetd</EM>(8) is <EM>NOT</EM> an option.</P>
<H2><A NAME="Command-Line Options">7.1. Command-Line Options</A></H2>
<P><EM>slapd</EM>(8) supports a number of command-line options as detailed in the manual page.  This section details a few commonly used options.</P>
<PRE>
        -f &lt;filename&gt;
</PRE>
<P>This option specifies an alternate configuration file for slapd. The default is normally <TT>/usr/local/etc/openldap/slapd.conf</TT>.</P>
<PRE>
        -F &lt;slapd-config-directory&gt;
</PRE>
<P>Specifies the slapd configuration directory. The default is <TT>/usr/local/etc/openldap/slapd.d</TT>.</P>
<P>If both <TT>-f</TT> and <TT>-F</TT> are specified, the config file will be read and converted to config directory format and written to the specified directory. If neither option is specified, slapd will attempt to read the default config directory before trying to use the default config file. If a valid config directory exists then the default config file is ignored. All of the slap tools that use the config options observe this same behavior.</P>
<PRE>
        -h &lt;URLs&gt;
</PRE>
<P>This option specifies alternative listener configurations.  The default is <TT>ldap:///</TT> which implies <TERM>LDAP</TERM> over <TERM>TCP</TERM> on all interfaces on the default LDAP port 389.  You can specify specific host-port pairs or other protocol schemes (such as <TT>ldaps://</TT> or <TT>ldapi://</TT>). slapd supports the HAProxy proxy protocol version 2, which allows a load balancer or proxy server to provide the remote client IP address to slapd to be used for access control or logging. Listeners configured using either <TT>pldap:///</TT> or <TT>pldaps:///</TT> URLS will only accept connections that include the necessary proxy protocol header. Connections to the ports used by these listeners should be restricted at the network level to only trusted load balancers or proxies to avoid spoofing of client IP addresses by third parties.</P>
<TABLE CLASS="columns" BORDER>
<TR CLASS="heading">
<TD>
<STRONG>URL</STRONG>
</TD>
<TD>
<STRONG>Protocol</STRONG>
</TD>
<TD>
<STRONG>Transport</STRONG>
</TD>
</TR>
<TR>
<TD>
ldap:///
</TD>
<TD>
LDAP
</TD>
<TD>
TCP port 389
</TD>
</TR>
<TR>
<TD>
pldap:///
</TD>
<TD>
proxied LDAP
</TD>
<TD>
TCP port 389
</TD>
</TR>
<TR>
<TD>
ldaps:///
</TD>
<TD>
LDAP over SSL
</TD>
<TD>
TCP port 636
</TD>
</TR>
<TR>
<TD>
pldaps:///
</TD>
<TD>
proxied LDAP over SSL
</TD>
<TD>
TCP port 636
</TD>
</TR>
<TR>
<TD>
ldapi:///
</TD>
<TD>
LDAP
</TD>
<TD>
IPC (Unix-domain socket)
</TD>
</TR>
</TABLE>

<P>For example, <TT>-h &quot;ldaps:// ldap://127.0.0.1:666&quot;</TT> will create two listeners: one for the (non-standard) <TT>ldaps://</TT> scheme on all interfaces on the default <TT>ldaps://</TT> port 636, and one for the standard <TT>ldap://</TT> scheme on the <TT>localhost</TT> (<EM>loopback</EM>) interface on port 666.  Hosts may be specified using using hostnames or <TERM>IPv4</TERM> or <TERM>IPv6</TERM> addresses.  Port values must be numeric.</P>
<P>For LDAP over IPC, the pathname of the Unix-domain socket can be encoded in the URL. Note that directory separators must be URL-encoded, like any other characters that are special to URLs. Thus the socket <TT>/usr/local/var/ldapi</TT> must be encoded as</P>
<PRE>
        ldapi://%2Fusr%2Flocal%2Fvar%2Fldapi
</PRE>
<P>ldapi: is described in detail in <EM>Using LDAP Over IPC Mechanisms</EM> [<A HREF="https://tools.ietf.org/html/draft-chu-ldap-ldapi-00">Chu-LDAPI</A>]</P>
<P>Note that the ldapi:/// transport is not widely implemented: non-OpenLDAP clients may not be able to use it.</P>
<PRE>
        -n &lt;service-name&gt;
</PRE>
<P>This option specifies the service name used for logging and other purposes. The default service name is <TT>slapd</TT>.</P>
<PRE>
        -l &lt;syslog-local-user&gt;
</PRE>
<P>This option specifies the local user for the <EM>syslog</EM>(8) facility.  Values can be <TT>LOCAL0</TT>, <TT>LOCAL1</TT>, <TT>LOCAL2</TT>, ..., and <TT>LOCAL7</TT>.  The default is <TT>LOCAL4</TT>.  This option may not be supported on all systems.</P>
<PRE>
        -u user -g group
</PRE>
<P>These options specify the user and group, respectively, to run as.  <TT>user</TT> can be either a user name or uid.  <TT>group</TT> can be either a group name or gid.</P>
<PRE>
        -r directory
</PRE>
<P>This option specifies a run-time directory.  slapd will <EM>chroot</EM>(2) to this directory after opening listeners but before reading any configuration files or initializing any backends.</P>
<UL>
</UL>
<PRE>
        -d &lt;level&gt; | ?
</PRE>
<P>This option sets the slapd debug level to &lt;level&gt;. When level is a `?' character, the various debugging levels are printed and slapd exits, regardless of any other options you give it. Current debugging levels are</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 7.1: Debugging Levels</CAPTION>
<TR CLASS="heading">
<TD ALIGN='Right'>
<STRONG>Level</STRONG>
</TD>
<TD ALIGN='Left'>
<STRONG>Keyword</STRONG>
</TD>
<TD>
<STRONG>Description</STRONG>
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
-1
</TD>
<TD ALIGN='Left'>
any
</TD>
<TD>
enable all debugging
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
0
</TD>
<TD ALIGN='Left'>
&nbsp;
</TD>
<TD>
no debugging
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
1
</TD>
<TD ALIGN='Left'>
(0x1 trace)
</TD>
<TD>
trace function calls
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
2
</TD>
<TD ALIGN='Left'>
(0x2 packets)
</TD>
<TD>
debug packet handling
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
4
</TD>
<TD ALIGN='Left'>
(0x4 args)
</TD>
<TD>
heavy trace debugging
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
8
</TD>
<TD ALIGN='Left'>
(0x8 conns)
</TD>
<TD>
connection management
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
16
</TD>
<TD ALIGN='Left'>
(0x10 BER)
</TD>
<TD>
print out packets sent and received
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
32
</TD>
<TD ALIGN='Left'>
(0x20 filter)
</TD>
<TD>
search filter processing
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
64
</TD>
<TD ALIGN='Left'>
(0x40 config)
</TD>
<TD>
configuration processing
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
128
</TD>
<TD ALIGN='Left'>
(0x80 ACL)
</TD>
<TD>
access control list processing
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
256
</TD>
<TD ALIGN='Left'>
(0x100 stats)
</TD>
<TD>
stats log connections/operations/results
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
512
</TD>
<TD ALIGN='Left'>
(0x200 stats2)
</TD>
<TD>
stats log entries sent
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
1024
</TD>
<TD ALIGN='Left'>
(0x400 shell)
</TD>
<TD>
print communication with shell backends
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
2048
</TD>
<TD ALIGN='Left'>
(0x800 parse)
</TD>
<TD>
print entry parsing debugging
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
16384
</TD>
<TD ALIGN='Left'>
(0x4000 sync)
</TD>
<TD>
syncrepl consumer processing
</TD>
</TR>
<TR>
<TD ALIGN='Right'>
32768
</TD>
<TD ALIGN='Left'>
(0x8000 none)
</TD>
<TD>
only messages that get logged whatever log level is set
</TD>
</TR>
</TABLE>

<P>You may enable multiple levels by specifying the debug option once for each desired level.  Or, since debugging levels are additive, you can do the math yourself. That is, if you want to trace function calls and watch the config file being processed, you could set level to the sum of those two levels (in this case, <TT> -d 65</TT>).  Or, you can let slapd do the math, (e.g. <TT> -d 1 -d 64</TT>).  Consult <TT>&lt;ldap_log.h&gt;</TT> for more details.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>slapd must have been compiled with <TT>--enable-debug</TT>, which is the default, for any debugging information other than the stats and stats2 levels to be available as options.
<HR WIDTH="80%" ALIGN="Left"></P>
<H2><A NAME="Starting slapd">7.2. Starting slapd</A></H2>
<P>In general, slapd is run like this:</P>
<PRE>
        /usr/local/libexec/slapd [&lt;option&gt;]*
</PRE>
<P>where <TT>/usr/local/libexec</TT> is determined by <TT>configure</TT> and &lt;option&gt; is one of the options described above (or in <EM>slapd</EM>(8)). Unless you have specified a debugging level (including level <TT>0</TT>), slapd will automatically fork and detach itself from its controlling terminal and run in the background.</P>
<H2><A NAME="Stopping slapd">7.3. Stopping slapd</A></H2>
<P>To kill off <EM>slapd</EM>(8) safely, you should give a command like this</P>
<PRE>
        kill -INT `cat /usr/local/var/slapd.pid`
</PRE>
<P>where <TT>/usr/local/var</TT> is determined by <TT>configure</TT>.</P>
<P>Killing slapd by a more drastic method may cause information loss or database corruption.</P>
<P></P>
<HR>
<H1><A NAME="Access Control">8. Access Control</A></H1>
<H2><A NAME="Introduction">8.1. Introduction</A></H2>
<P>As the directory gets populated with more and more data of varying sensitivity, controlling the kinds of access granted to the directory becomes more and more critical. For instance, the directory may contain data of a confidential nature that you may need to protect by contract or by law. Or, if using the directory to control access to other services, inappropriate access to the directory may create avenues of attack to your sites security that result in devastating damage to your assets.</P>
<P>Access to your directory can be configured via two methods, the first using <A HREF="#The slapd Configuration File">The slapd Configuration File</A> and the second using the <EM>slapd-config</EM>(5) format (<A HREF="#Configuring slapd">Configuring slapd</A>).</P>
<P>The default access control policy is allow read by all clients. Regardless of what access control policy is defined, the <EM>rootdn</EM> is always allowed full rights (i.e. auth, search, compare, read and write) on everything and anything.</P>
<P>As a consequence, it's useless (and results in a performance penalty) to explicitly list the <EM>rootdn</EM> among the <EM>&lt;by&gt;</EM> clauses.</P>
<P>The following sections will describe Access Control Lists in greater depth and follow with some examples and recommendations. See <EM>slapd.access</EM>(5) for complete details.</P>
<H2><A NAME="Access Control via Static Configuration">8.2. Access Control via Static Configuration</A></H2>
<P>Access to entries and attributes is controlled by the access configuration file directive. The general form of an access line is:</P>
<PRE>
    &lt;access directive&gt; ::= access to &lt;what&gt;
        [by &lt;who&gt; [&lt;access&gt;] [&lt;control&gt;] ]+
    &lt;what&gt; ::= * |
        [dn[.&lt;basic-style&gt;]=&lt;regex&gt; | dn.&lt;scope-style&gt;=&lt;DN&gt;]
        [filter=&lt;ldapfilter&gt;] [attrs=&lt;attrlist&gt;]
    &lt;basic-style&gt; ::= regex | exact
    &lt;scope-style&gt; ::= base | one | subtree | children
    &lt;attrlist&gt; ::= &lt;attr&gt; [val[.&lt;basic-style&gt;]=&lt;regex&gt;] | &lt;attr&gt; , &lt;attrlist&gt;
    &lt;attr&gt; ::= &lt;attrname&gt; | entry | children
    &lt;who&gt; ::= * | [anonymous | users | self
            | dn[.&lt;basic-style&gt;]=&lt;regex&gt; | dn.&lt;scope-style&gt;=&lt;DN&gt;]
        [dnattr=&lt;attrname&gt;]
        [group[/&lt;objectclass&gt;[/&lt;attrname&gt;][.&lt;basic-style&gt;]]=&lt;regex&gt;]
        [peername[.&lt;basic-style&gt;]=&lt;regex&gt;]
        [sockname[.&lt;basic-style&gt;]=&lt;regex&gt;]
        [domain[.&lt;basic-style&gt;]=&lt;regex&gt;]
        [sockurl[.&lt;basic-style&gt;]=&lt;regex&gt;]
        [set=&lt;setspec&gt;]
        [aci=&lt;attrname&gt;]
    &lt;access&gt; ::= [self]{&lt;level&gt;|&lt;priv&gt;}
    &lt;level&gt; ::= none | disclose | auth | compare | search | read | write | manage
    &lt;priv&gt; ::= {=|+|-}{m|w|r|s|c|x|d|0}+
    &lt;control&gt; ::= [stop | continue | break]
</PRE>
<P>where the &lt;what&gt; part selects the entries and/or attributes to which the access applies, the <TT>&lt;who&gt;</TT> part specifies which entities are granted access, and the <TT>&lt;access&gt;</TT> part specifies the access granted. Multiple <TT>&lt;who&gt; &lt;access&gt; &lt;control&gt;</TT> triplets are supported, allowing many entities to be granted different access to the same set of entries and attributes. Not all of these access control options are described here; for more details see the <EM>slapd.access</EM>(5) man page.</P>
<H3><A NAME="What to control access to">8.2.1. What to control access to</A></H3>
<P>The &lt;what&gt; part of an access specification determines the entries and attributes to which the access control applies.  Entries are commonly selected in two ways: by DN and by filter.  The following qualifiers select entries by DN:</P>
<PRE>
    to *
    to dn[.&lt;basic-style&gt;]=&lt;regex&gt;
    to dn.&lt;scope-style&gt;=&lt;DN&gt;
</PRE>
<P>The first form is used to select all entries.  The second form may be used to select entries by matching a regular expression against the target entry's <EM>normalized DN</EM>.   (The second form is not discussed further in this document.)  The third form is used to select entries which are within the requested scope of DN.  The &lt;DN&gt; is a string representation of the Distinguished Name, as described in <A HREF="https://www.rfc-editor.org/rfc/rfc4514.txt">RFC4514</A>.</P>
<P>The scope can be either <TT>base</TT>, <TT>one</TT>, <TT>subtree</TT>, or <TT>children</TT>.  Where <TT>base</TT> matches only the entry with provided DN, <TT>one</TT> matches the entries whose parent is the provided DN, <TT>subtree</TT> matches all entries in the subtree whose root is the provided DN, and <TT>children</TT> matches all entries under the DN (but not the entry named by the DN).</P>
<P>For example, if the directory contained entries named:</P>
<PRE>
    0: o=suffix
    1: cn=Manager,o=suffix
    2: ou=people,o=suffix
    3: uid=kdz,ou=people,o=suffix
    4: cn=addresses,uid=kdz,ou=people,o=suffix
    5: uid=hyc,ou=people,o=suffix
</PRE>
<P>Then:</P>
<UL>
<TT>dn.base=&quot;ou=people,o=suffix&quot;</TT> match 2;
<BR>
<TT>dn.one=&quot;ou=people,o=suffix&quot;</TT> match 3, and 5;
<BR>
<TT>dn.subtree=&quot;ou=people,o=suffix&quot;</TT> match 2, 3, 4, and 5; and
<BR>
<TT>dn.children=&quot;ou=people,o=suffix&quot;</TT> match 3, 4, and 5.</UL>
<P>Entries may also be selected using a filter:</P>
<PRE>
    to filter=&lt;ldap filter&gt;
</PRE>
<P>where &lt;ldap filter&gt; is a string representation of an LDAP search filter, as described in <A HREF="https://www.rfc-editor.org/rfc/rfc4515.txt">RFC4515</A>.  For example:</P>
<PRE>
    to filter=(objectClass=person)
</PRE>
<P>Note that entries may be selected by both DN and filter by including both qualifiers in the &lt;what&gt; clause.</P>
<PRE>
    to dn.one=&quot;ou=people,o=suffix&quot; filter=(objectClass=person)
</PRE>
<P>Attributes within an entry are selected by including a comma-separated list of attribute names in the &lt;what&gt; selector:</P>
<PRE>
    attrs=&lt;attribute list&gt;
</PRE>
<P>A specific value of an attribute is selected by using a single attribute name and also using a value selector:</P>
<PRE>
    attrs=&lt;attribute&gt; val[.&lt;style&gt;]=&lt;regex&gt;
</PRE>
<P>There are two special <EM>pseudo</EM> attributes <TT>entry</TT> and <TT>children</TT>.  To read (and hence return) a target entry, the subject must have <TT>read</TT> access to the target's <EM>entry</EM> attribute.  To perform a search, the subject must have <TT>search</TT> access to the search base's <EM>entry</EM> attribute. To add or delete an entry, the subject must have <TT>write</TT> access to the entry's <TT>entry</TT> attribute AND must have <TT>write</TT> access to the entry's parent's <TT>children</TT> attribute.  To rename an entry, the subject must have <TT>write</TT> access to entry's <TT>entry</TT> attribute AND have <TT>write</TT> access to both the old parent's and new parent's <TT>children</TT> attributes.  The complete examples at the end of this section should help clear things up.</P>
<P>Lastly, there is a special entry selector <TT>&quot;*&quot;</TT> that is used to select any entry.  It is used when no other <TT>&lt;what&gt;</TT> selector has been provided.  It's equivalent to &quot;<TT>dn=.*</TT>&quot;</P>
<H3><A NAME="Who to grant access to">8.2.2. Who to grant access to</A></H3>
<P>The &lt;who&gt; part identifies the entity or entities being granted access. Note that access is granted to &quot;entities&quot; not &quot;entries.&quot; The following table summarizes entity specifiers:</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 6.3: Access Entity Specifiers</CAPTION>
<TR CLASS="heading">
<TD>
<STRONG>Specifier</STRONG>
</TD>
<TD>
<STRONG>Entities</STRONG>
</TD>
</TR>
<TR>
<TD>
<TT>*</TT>
</TD>
<TD>
All, including anonymous and authenticated users
</TD>
</TR>
<TR>
<TD>
<TT>anonymous</TT>
</TD>
<TD>
Anonymous (non-authenticated) users
</TD>
</TR>
<TR>
<TD>
<TT>users</TT>
</TD>
<TD>
Authenticated users
</TD>
</TR>
<TR>
<TD>
<TT>self</TT>
</TD>
<TD>
User associated with target entry
</TD>
</TR>
<TR>
<TD>
<TT>dn[.&lt;basic-style&gt;]=&lt;regex&gt;</TT>
</TD>
<TD>
Users matching a regular expression
</TD>
</TR>
<TR>
<TD>
<TT>dn.&lt;scope-style&gt;=&lt;DN&gt;</TT>
</TD>
<TD>
Users within scope of a DN
</TD>
</TR>
</TABLE>

<P>The DN specifier behaves much like &lt;what&gt; clause DN specifiers.</P>
<P>Other control factors are also supported.  For example, a <TT>&lt;who&gt;</TT> can be restricted by an entry listed in a DN-valued attribute in the entry to which the access applies:</P>
<PRE>
    dnattr=&lt;dn-valued attribute name&gt;
</PRE>
<P>The dnattr specification is used to give access to an entry whose DN is listed in an attribute of the entry (e.g., give access to a group entry to whoever is listed as the owner of the group entry).</P>
<P>Some factors may not be appropriate in all environments (or any). For example, the domain factor relies on IP to domain name lookups. As these can easily be spoofed, the domain factor should be avoided.</P>
<H3><A NAME="The access to grant">8.2.3. The access to grant</A></H3>
<P>The kind of &lt;access&gt; granted can be one of the following:</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 6.4: Access Levels</CAPTION>
<TR CLASS="heading">
<TD ALIGN='Left'>
<STRONG>Level</STRONG>
</TD>
<TD ALIGN='Right'>
<STRONG>Privileges</STRONG>
</TD>
<TD ALIGN='Left'>
<STRONG>Description</STRONG>
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>none        =</TT>
</TD>
<TD ALIGN='Right'>
<TT>0</TT>
</TD>
<TD ALIGN='Left'>
no access
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>disclose    =</TT>
</TD>
<TD ALIGN='Right'>
<TT>d</TT>
</TD>
<TD ALIGN='Left'>
needed for information disclosure on error
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>auth        =</TT>
</TD>
<TD ALIGN='Right'>
<TT>dx</TT>
</TD>
<TD ALIGN='Left'>
needed to authenticate (bind)
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>compare     =</TT>
</TD>
<TD ALIGN='Right'>
<TT>cdx</TT>
</TD>
<TD ALIGN='Left'>
needed to compare
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>search      =</TT>
</TD>
<TD ALIGN='Right'>
<TT>scdx</TT>
</TD>
<TD ALIGN='Left'>
needed to apply search filters
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>read        =</TT>
</TD>
<TD ALIGN='Right'>
<TT>rscdx</TT>
</TD>
<TD ALIGN='Left'>
needed to read search results
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>write       =</TT>
</TD>
<TD ALIGN='Right'>
<TT>wrscdx</TT>
</TD>
<TD ALIGN='Left'>
needed to modify/rename
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>manage      =</TT>
</TD>
<TD ALIGN='Right'>
<TT>mwrscdx</TT>
</TD>
<TD ALIGN='Left'>
needed to manage
</TD>
</TR>
</TABLE>

<P>Each level implies all lower levels of access. So, for example, granting someone <TT>write</TT> access to an entry also grants them <TT>read</TT>, <TT>search</TT>, <TT>compare</TT>, <TT>auth</TT> and <TT>disclose</TT> access.  However, one may use the privileges specifier to grant specific permissions.</P>
<H3><A NAME="Access Control Evaluation">8.2.4. Access Control Evaluation</A></H3>
<P>When evaluating whether some requester should be given access to an entry and/or attribute, slapd compares the entry and/or attribute to the <TT>&lt;what&gt;</TT> selectors given in the configuration file. For each entry, access controls provided in the database which holds the entry (or the global access directives if not held in any database) apply first, followed by the global access directives. However, when dealing with an access list, because the global access list is effectively appended to each per-database list, if the resulting list is non-empty then the access list will end with an implicit <TT>access to * by * none</TT> directive. If there are no access directives applicable to a backend, then a default read is used.</P>
<P>Within this priority, access directives are examined in the order in which they appear in the config file.  Slapd stops with the first <TT>&lt;what&gt;</TT> selector that matches the entry and/or attribute. The corresponding access directive is the one slapd will use to evaluate access.</P>
<P>Next, slapd compares the entity requesting access to the <TT>&lt;who&gt;</TT> selectors within the access directive selected above in the order in which they appear. It stops with the first <TT>&lt;who&gt;</TT> selector that matches the requester. This determines the access the entity requesting access has to the entry and/or attribute.</P>
<P>Finally, slapd compares the access granted in the selected <TT>&lt;access&gt;</TT> clause to the access requested by the client. If it allows greater or equal access, access is granted. Otherwise, access is denied.</P>
<P>The order of evaluation of access directives makes their placement in the configuration file important. If one access directive is more specific than another in terms of the entries it selects, it should appear first in the config file. Similarly, if one <TT>&lt;who&gt;</TT> selector is more specific than another it should come first in the access directive. The access control examples given below should help make this clear.</P>
<H3><A NAME="Access Control Examples">8.2.5. Access Control Examples</A></H3>
<P>The access control facility described above is quite powerful.  This section shows some examples of its use for descriptive purposes.</P>
<P>A simple example:</P>
<PRE>
    access to * by * read
</PRE>
<P>This access directive grants read access to everyone.</P>
<PRE>
    access to *
        by self write
        by anonymous auth
        by * read
</PRE>
<P>This directive allows the user to modify their entry, allows anonymous to authenticate against these entries, and allows all others to read these entries.  Note that only the first <TT>by &lt;who&gt;</TT> clause which matches applies.  Hence, the anonymous users are granted <TT>auth</TT>, not <TT>read</TT>.  The last clause could just as well have been &quot;<TT>by users read</TT>&quot;.</P>
<P>It is often desirable to restrict operations based upon the level of protection in place.  The following shows how security strength factors (SSF) can be used.</P>
<PRE>
    access to *
        by ssf=128 self write
        by ssf=64 anonymous auth
        by ssf=64 users read
</PRE>
<P>This directive allows users to modify their own entries if security protections have of strength 128 or better have been established, allows authentication access to anonymous users, and read access when 64 or better security protections have been established.  If client has not establish sufficient security protections, the implicit <TT>by * none</TT> clause would be applied.</P>
<P>The following example shows the use of a style specifiers to select the entries by DN in two access directives where ordering is significant.</P>
<PRE>
    access to dn.children=&quot;dc=example,dc=com&quot;
         by * search
    access to dn.children=&quot;dc=com&quot;
         by * read
</PRE>
<P>Read access is granted to entries under the <TT>dc=com</TT> subtree, except for those entries under the <TT>dc=example,dc=com</TT> subtree, to which search access is granted.  No access is granted to <TT>dc=com</TT> as neither access directive matches this DN.  If the order of these access directives was reversed, the trailing directive would never be reached, since all entries under <TT>dc=example,dc=com</TT> are also under <TT>dc=com</TT> entries.</P>
<P>Also note that if no <TT>access to</TT> directive matches or no <TT>by &lt;who&gt;</TT> clause, <B>access is denied</B>.  That is, every <TT>access to</TT> directive ends with an implicit <TT>by * none</TT> clause. When dealing with an access list, because the global access list is effectively appended to each per-database list, if the resulting list is non-empty then the access list will end with an implicit <TT>access to * by * none</TT> directive. If there are no access directives applicable to a backend, then a default read is used.</P>
<P>The next example again shows the importance of ordering, both of the access directives and the <TT>by &lt;who&gt;</TT> clauses.  It also shows the use of an attribute selector to grant access to a specific attribute and various <TT>&lt;who&gt;</TT> selectors.</P>
<PRE>
    access to dn.subtree=&quot;dc=example,dc=com&quot; attrs=homePhone
        by self write
        by dn.children=&quot;dc=example,dc=com&quot; search
        by peername.regex=IP=10\..+ read
    access to dn.subtree=&quot;dc=example,dc=com&quot;
        by self write
        by dn.children=&quot;dc=example,dc=com&quot; search
        by anonymous auth
</PRE>
<P>This example applies to entries in the &quot;<TT>dc=example,dc=com</TT>&quot; subtree. To all attributes except <TT>homePhone</TT>, an entry can write to itself, entries under <TT>example.com</TT> entries can search by them, anybody else has no access (implicit <TT>by * none</TT>) excepting for authentication/authorization (which is always done anonymously).  The <TT>homePhone</TT> attribute is writable by the entry, searchable by entries under <TT>example.com</TT>, readable by clients connecting from network 10, and otherwise not readable (implicit <TT>by * none</TT>).  All other access is denied by the implicit <TT>access to * by * none</TT>.</P>
<P>Sometimes it is useful to permit a particular DN to add or remove itself from an attribute. For example, if you would like to create a group and allow people to add and remove only their own DN from the member attribute, you could accomplish it with an access directive like this:</P>
<PRE>
    access to attrs=member,entry
         by dnattr=member selfwrite
</PRE>
<P>The dnattr <TT>&lt;who&gt;</TT> selector says that the access applies to entries listed in the <TT>member</TT> attribute. The <TT>selfwrite</TT> access selector says that such members can only add or delete their own DN from the attribute, not other values. The addition of the entry attribute is required because access to the entry is required to access any of the entry's attributes.</P>
<H2><A NAME="Access Control via Dynamic Configuration">8.3. Access Control via Dynamic Configuration</A></H2>
<P>Access to slapd entries and attributes is controlled by the olcAccess attribute, whose values are a sequence of access directives. The general form of the olcAccess configuration is:</P>
<PRE>
    olcAccess: &lt;access directive&gt;
    &lt;access directive&gt; ::= to &lt;what&gt;
        [by &lt;who&gt; [&lt;access&gt;] [&lt;control&gt;] ]+
    &lt;what&gt; ::= * |
        [dn[.&lt;basic-style&gt;]=&lt;regex&gt; | dn.&lt;scope-style&gt;=&lt;DN&gt;]
        [filter=&lt;ldapfilter&gt;] [attrs=&lt;attrlist&gt;]
    &lt;basic-style&gt; ::= regex | exact
    &lt;scope-style&gt; ::= base | one | subtree | children
    &lt;attrlist&gt; ::= &lt;attr&gt; [val[.&lt;basic-style&gt;]=&lt;regex&gt;] | &lt;attr&gt; , &lt;attrlist&gt;
    &lt;attr&gt; ::= &lt;attrname&gt; | entry | children
    &lt;who&gt; ::= * | [anonymous | users | self
            | dn[.&lt;basic-style&gt;]=&lt;regex&gt; | dn.&lt;scope-style&gt;=&lt;DN&gt;]
        [dnattr=&lt;attrname&gt;]
        [group[/&lt;objectclass&gt;[/&lt;attrname&gt;][.&lt;basic-style&gt;]]=&lt;regex&gt;]
        [peername[.&lt;basic-style&gt;]=&lt;regex&gt;]
        [sockname[.&lt;basic-style&gt;]=&lt;regex&gt;]
        [domain[.&lt;basic-style&gt;]=&lt;regex&gt;]
        [sockurl[.&lt;basic-style&gt;]=&lt;regex&gt;]
        [set=&lt;setspec&gt;]
        [aci=&lt;attrname&gt;]
    &lt;access&gt; ::= [self]{&lt;level&gt;|&lt;priv&gt;}
    &lt;level&gt; ::= none | disclose | auth | compare | search | read | write | manage
    &lt;priv&gt; ::= {=|+|-}{m|w|r|s|c|x|d|0}+
    &lt;control&gt; ::= [stop | continue | break]
</PRE>
<P>where the &lt;what&gt; part selects the entries and/or attributes to which the access applies, the <TT>&lt;who&gt;</TT> part specifies which entities are granted access, and the <TT>&lt;access&gt;</TT> part specifies the access granted. Multiple <TT>&lt;who&gt; &lt;access&gt; &lt;control&gt;</TT> triplets are supported, allowing many entities to be granted different access to the same set of entries and attributes. Not all of these access control options are described here; for more details see the <EM>slapd.access</EM>(5) man page.</P>
<H3><A NAME="What to control access to">8.3.1. What to control access to</A></H3>
<P>The &lt;what&gt; part of an access specification determines the entries and attributes to which the access control applies.  Entries are commonly selected in two ways: by DN and by filter.  The following qualifiers select entries by DN:</P>
<PRE>
    to *
    to dn[.&lt;basic-style&gt;]=&lt;regex&gt;
    to dn.&lt;scope-style&gt;=&lt;DN&gt;
</PRE>
<P>The first form is used to select all entries.  The second form may be used to select entries by matching a regular expression against the target entry's <EM>normalized DN</EM>.   (The second form is not discussed further in this document.)  The third form is used to select entries which are within the requested scope of DN.  The &lt;DN&gt; is a string representation of the Distinguished Name, as described in <A HREF="https://www.rfc-editor.org/rfc/rfc4514.txt">RFC4514</A>.</P>
<P>The scope can be either <TT>base</TT>, <TT>one</TT>, <TT>subtree</TT>, or <TT>children</TT>.  Where <TT>base</TT> matches only the entry with provided DN, <TT>one</TT> matches the entries whose parent is the provided DN, <TT>subtree</TT> matches all entries in the subtree whose root is the provided DN, and <TT>children</TT> matches all entries under the DN (but not the entry named by the DN).</P>
<P>For example, if the directory contained entries named:</P>
<PRE>
    0: o=suffix
    1: cn=Manager,o=suffix
    2: ou=people,o=suffix
    3: uid=kdz,ou=people,o=suffix
    4: cn=addresses,uid=kdz,ou=people,o=suffix
    5: uid=hyc,ou=people,o=suffix
</PRE>
<P>Then:</P>
<UL>
<TT>dn.base=&quot;ou=people,o=suffix&quot;</TT> match 2;
<BR>
<TT>dn.one=&quot;ou=people,o=suffix&quot;</TT> match 3, and 5;
<BR>
<TT>dn.subtree=&quot;ou=people,o=suffix&quot;</TT> match 2, 3, 4, and 5; and
<BR>
<TT>dn.children=&quot;ou=people,o=suffix&quot;</TT> match 3, 4, and 5.</UL>
<P>Entries may also be selected using a filter:</P>
<PRE>
    to filter=&lt;ldap filter&gt;
</PRE>
<P>where &lt;ldap filter&gt; is a string representation of an LDAP search filter, as described in <A HREF="https://www.rfc-editor.org/rfc/rfc4515.txt">RFC4515</A>.  For example:</P>
<PRE>
    to filter=(objectClass=person)
</PRE>
<P>Note that entries may be selected by both DN and filter by including both qualifiers in the &lt;what&gt; clause.</P>
<PRE>
    to dn.one=&quot;ou=people,o=suffix&quot; filter=(objectClass=person)
</PRE>
<P>Attributes within an entry are selected by including a comma-separated list of attribute names in the &lt;what&gt; selector:</P>
<PRE>
    attrs=&lt;attribute list&gt;
</PRE>
<P>A specific value of an attribute is selected by using a single attribute name and also using a value selector:</P>
<PRE>
    attrs=&lt;attribute&gt; val[.&lt;style&gt;]=&lt;regex&gt;
</PRE>
<P>There are two special <EM>pseudo</EM> attributes <TT>entry</TT> and <TT>children</TT>.  To read (and hence return) a target entry, the subject must have <TT>read</TT> access to the target's <EM>entry</EM> attribute.  To perform a search, the subject must have <TT>search</TT> access to the search base's <EM>entry</EM> attribute. To add or delete an entry, the subject must have <TT>write</TT> access to the entry's <TT>entry</TT> attribute AND must have <TT>write</TT> access to the entry's parent's <TT>children</TT> attribute.  To rename an entry, the subject must have <TT>write</TT> access to entry's <TT>entry</TT> attribute AND have <TT>write</TT> access to both the old parent's and new parent's <TT>children</TT> attributes.  The complete examples at the end of this section should help clear things up.</P>
<P>Lastly, there is a special entry selector <TT>&quot;*&quot;</TT> that is used to select any entry.  It is used when no other <TT>&lt;what&gt;</TT> selector has been provided.  It's equivalent to &quot;<TT>dn=.*</TT>&quot;</P>
<H3><A NAME="Who to grant access to">8.3.2. Who to grant access to</A></H3>
<P>The &lt;who&gt; part identifies the entity or entities being granted access. Note that access is granted to &quot;entities&quot; not &quot;entries.&quot; The following table summarizes entity specifiers:</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 5.3: Access Entity Specifiers</CAPTION>
<TR CLASS="heading">
<TD>
<STRONG>Specifier</STRONG>
</TD>
<TD>
<STRONG>Entities</STRONG>
</TD>
</TR>
<TR>
<TD>
<TT>*</TT>
</TD>
<TD>
All, including anonymous and authenticated users
</TD>
</TR>
<TR>
<TD>
<TT>anonymous</TT>
</TD>
<TD>
Anonymous (non-authenticated) users
</TD>
</TR>
<TR>
<TD>
<TT>users</TT>
</TD>
<TD>
Authenticated users
</TD>
</TR>
<TR>
<TD>
<TT>self</TT>
</TD>
<TD>
User associated with target entry
</TD>
</TR>
<TR>
<TD>
<TT>dn[.&lt;basic-style&gt;]=&lt;regex&gt;</TT>
</TD>
<TD>
Users matching a regular expression
</TD>
</TR>
<TR>
<TD>
<TT>dn.&lt;scope-style&gt;=&lt;DN&gt;</TT>
</TD>
<TD>
Users within scope of a DN
</TD>
</TR>
</TABLE>

<P>The DN specifier behaves much like &lt;what&gt; clause DN specifiers.</P>
<P>Other control factors are also supported.  For example, a <TT>&lt;who&gt;</TT> can be restricted by an entry listed in a DN-valued attribute in the entry to which the access applies:</P>
<PRE>
    dnattr=&lt;dn-valued attribute name&gt;
</PRE>
<P>The dnattr specification is used to give access to an entry whose DN is listed in an attribute of the entry (e.g., give access to a group entry to whoever is listed as the owner of the group entry).</P>
<P>Some factors may not be appropriate in all environments (or any). For example, the domain factor relies on IP to domain name lookups. As these can easily be spoofed, the domain factor should be avoided.</P>
<H3><A NAME="The access to grant">8.3.3. The access to grant</A></H3>
<P>The kind of &lt;access&gt; granted can be one of the following:</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 5.4: Access Levels</CAPTION>
<TR CLASS="heading">
<TD ALIGN='Left'>
<STRONG>Level</STRONG>
</TD>
<TD ALIGN='Right'>
<STRONG>Privileges</STRONG>
</TD>
<TD ALIGN='Left'>
<STRONG>Description</STRONG>
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>none</TT>
</TD>
<TD ALIGN='Right'>
<TT>=0</TT>
</TD>
<TD ALIGN='Left'>
no access
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>disclose</TT>
</TD>
<TD ALIGN='Right'>
<TT>=d</TT>
</TD>
<TD ALIGN='Left'>
needed for information disclosure on error
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>auth</TT>
</TD>
<TD ALIGN='Right'>
<TT>=dx</TT>
</TD>
<TD ALIGN='Left'>
needed to authenticate (bind)
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>compare</TT>
</TD>
<TD ALIGN='Right'>
<TT>=cdx</TT>
</TD>
<TD ALIGN='Left'>
needed to compare
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>search</TT>
</TD>
<TD ALIGN='Right'>
<TT>=scdx</TT>
</TD>
<TD ALIGN='Left'>
needed to apply search filters
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>read</TT>
</TD>
<TD ALIGN='Right'>
<TT>=rscdx</TT>
</TD>
<TD ALIGN='Left'>
needed to read search results
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>write</TT>
</TD>
<TD ALIGN='Right'>
<TT>=wrscdx</TT>
</TD>
<TD ALIGN='Left'>
needed to modify/rename
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>manage</TT>
</TD>
<TD ALIGN='Right'>
<TT>=mwrscdx</TT>
</TD>
<TD ALIGN='Left'>
needed to manage
</TD>
</TR>
</TABLE>

<P>Each level implies all lower levels of access. So, for example, granting someone <TT>write</TT> access to an entry also grants them <TT>read</TT>, <TT>search</TT>, <TT>compare</TT>, <TT>auth</TT> and <TT>disclose</TT> access.  However, one may use the privileges specifier to grant specific permissions.</P>
<H3><A NAME="Access Control Evaluation">8.3.4. Access Control Evaluation</A></H3>
<P>When evaluating whether some requester should be given access to an entry and/or attribute, slapd compares the entry and/or attribute to the <TT>&lt;what&gt;</TT> selectors given in the configuration.  For each entry, access controls provided in the database which holds the entry (or the global access directives if not held in any database) apply first, followed by the global access directives (which are held in the <TT>frontend</TT> database definition). However, when dealing with an access list, because the global access list is effectively appended to each per-database list, if the resulting list is non-empty then the access list will end with an implicit <TT>access to * by * none</TT> directive. If there are no access directives applicable to a backend, then a default read is used.</P>
<P>Within this priority, access directives are examined in the order in which they appear in the configuration attribute.  Slapd stops with the first <TT>&lt;what&gt;</TT> selector that matches the entry and/or attribute. The corresponding access directive is the one slapd will use to evaluate access.</P>
<P>Next, slapd compares the entity requesting access to the <TT>&lt;who&gt;</TT> selectors within the access directive selected above in the order in which they appear. It stops with the first <TT>&lt;who&gt;</TT> selector that matches the requester. This determines the access the entity requesting access has to the entry and/or attribute.</P>
<P>Finally, slapd compares the access granted in the selected <TT>&lt;access&gt;</TT> clause to the access requested by the client. If it allows greater or equal access, access is granted. Otherwise, access is denied.</P>
<P>The order of evaluation of access directives makes their placement in the configuration file important. If one access directive is more specific than another in terms of the entries it selects, it should appear first in the configuration. Similarly, if one <TT>&lt;who&gt;</TT> selector is more specific than another it should come first in the access directive. The access control examples given below should help make this clear.</P>
<H3><A NAME="Access Control Examples">8.3.5. Access Control Examples</A></H3>
<P>The access control facility described above is quite powerful.  This section shows some examples of its use for descriptive purposes.</P>
<P>A simple example:</P>
<PRE>
    olcAccess: to * by * read
</PRE>
<P>This access directive grants read access to everyone.</P>
<PRE>
    olcAccess: to *
        by self write
        by anonymous auth
        by * read
</PRE>
<P>This directive allows the user to modify their entry, allows anonymous to authenticate against these entries, and allows all others to read these entries.  Note that only the first <TT>by &lt;who&gt;</TT> clause which matches applies.  Hence, the anonymous users are granted <TT>auth</TT>, not <TT>read</TT>.  The last clause could just as well have been &quot;<TT>by users read</TT>&quot;.</P>
<P>It is often desirable to restrict operations based upon the level of protection in place.  The following shows how security strength factors (SSF) can be used.</P>
<PRE>
    olcAccess: to *
        by ssf=128 self write
        by ssf=64 anonymous auth
        by ssf=64 users read
</PRE>
<P>This directive allows users to modify their own entries if security protections of strength 128 or better have been established, allows authentication access to anonymous users, and read access when strength 64 or better security protections have been established.  If the client has not establish sufficient security protections, the implicit <TT>by * none</TT> clause would be applied.</P>
<P>The following example shows the use of style specifiers to select the entries by DN in two access directives where ordering is significant.</P>
<PRE>
    olcAccess: to dn.children=&quot;dc=example,dc=com&quot;
         by * search
    olcAccess: to dn.children=&quot;dc=com&quot;
         by * read
</PRE>
<P>Read access is granted to entries under the <TT>dc=com</TT> subtree, except for those entries under the <TT>dc=example,dc=com</TT> subtree, to which search access is granted.  No access is granted to <TT>dc=com</TT> as neither access directive matches this DN.  If the order of these access directives was reversed, the trailing directive would never be reached, since all entries under <TT>dc=example,dc=com</TT> are also under <TT>dc=com</TT> entries.</P>
<P>Also note that if no <TT>olcAccess: to</TT> directive matches or no <TT>by &lt;who&gt;</TT> clause, <B>access is denied</B>.  When dealing with an access list, because the global access list is effectively appended to each per-database list, if the resulting list is non-empty then the access list will end with an implicit <TT>access to * by * none</TT> directive. If there are no access directives applicable to a backend, then a default read is used.</P>
<P>The next example again shows the importance of ordering, both of the access directives and the <TT>by &lt;who&gt;</TT> clauses.  It also shows the use of an attribute selector to grant access to a specific attribute and various <TT>&lt;who&gt;</TT> selectors.</P>
<PRE>
    olcAccess: to dn.subtree=&quot;dc=example,dc=com&quot; attrs=homePhone
        by self write
        by dn.children=dc=example,dc=com&quot; search
        by peername.regex=IP=10\..+ read
    olcAccess: to dn.subtree=&quot;dc=example,dc=com&quot;
        by self write
        by dn.children=&quot;dc=example,dc=com&quot; search
        by anonymous auth
</PRE>
<P>This example applies to entries in the &quot;<TT>dc=example,dc=com</TT>&quot; subtree. To all attributes except <TT>homePhone</TT>, an entry can write to itself, entries under <TT>example.com</TT> entries can search by them, anybody else has no access (implicit <TT>by * none</TT>) excepting for authentication/authorization (which is always done anonymously).  The <TT>homePhone</TT> attribute is writable by the entry, searchable by entries under <TT>example.com</TT>, readable by clients connecting from network 10, and otherwise not readable (implicit <TT>by * none</TT>).  All other access is denied by the implicit <TT>access to * by * none</TT>.</P>
<P>Sometimes it is useful to permit a particular DN to add or remove itself from an attribute. For example, if you would like to create a group and allow people to add and remove only their own DN from the member attribute, you could accomplish it with an access directive like this:</P>
<PRE>
    olcAccess: to attrs=member,entry
         by dnattr=member selfwrite
</PRE>
<P>The dnattr <TT>&lt;who&gt;</TT> selector says that the access applies to entries listed in the <TT>member</TT> attribute. The <TT>selfwrite</TT> access selector says that such members can only add or delete their own DN from the attribute, not other values. The addition of the entry attribute is required because access to the entry is required to access any of the entry's attributes.</P>
<H3><A NAME="Access Control Ordering">8.3.6. Access Control Ordering</A></H3>
<P>Since the ordering of <TT>olcAccess</TT> directives is essential to their proper evaluation, but LDAP attributes normally do not preserve the ordering of their values, OpenLDAP uses a custom schema extension to maintain a fixed ordering of these values. This ordering is maintained by prepending a <TT>&quot;{X}&quot;</TT> numeric index to each value, similarly to the approach used for ordering the configuration entries. These index tags are maintained automatically by slapd and do not need to be specified when originally defining the values. For example, when you create the settings</P>
<PRE>
    olcAccess: to attrs=member,entry
         by dnattr=member selfwrite
    olcAccess: to dn.children=&quot;dc=example,dc=com&quot;
         by * search
    olcAccess: to dn.children=&quot;dc=com&quot;
         by * read
</PRE>
<P>when you read them back using slapcat or ldapsearch they will contain</P>
<PRE>
    olcAccess: {0}to attrs=member,entry
         by dnattr=member selfwrite
    olcAccess: {1}to dn.children=&quot;dc=example,dc=com&quot;
         by * search
    olcAccess: {2}to dn.children=&quot;dc=com&quot;
         by * read
</PRE>
<P>The numeric index may be used to specify a particular value to change when using ldapmodify to edit the access rules. This index can be used instead of (or in addition to) the actual access value. Using this numeric index is very helpful when multiple access rules are being managed.</P>
<P>For example, if we needed to change the second rule above to grant write access instead of search, we could try this LDIF:</P>
<PRE>
    changetype: modify
    delete: olcAccess
    olcAccess: to dn.children=&quot;dc=example,dc=com&quot; by * search
    -
    add: olcAccess
    olcAccess: to dn.children=&quot;dc=example,dc=com&quot; by * write
    -
</PRE>
<P>But this example <B>will not</B> guarantee that the existing values remain in their original order, so it will most likely yield a broken security configuration. Instead, the numeric index should be used:</P>
<PRE>
    changetype: modify
    delete: olcAccess
    olcAccess: {1}
    -
    add: olcAccess
    olcAccess: {1}to dn.children=&quot;dc=example,dc=com&quot; by * write
    -
</PRE>
<P>This example deletes whatever rule is in value #1 of the <TT>olcAccess</TT> attribute (regardless of its value) and adds a new value that is explicitly inserted as value #1. The result will be</P>
<PRE>
    olcAccess: {0}to attrs=member,entry
         by dnattr=member selfwrite
    olcAccess: {1}to dn.children=&quot;dc=example,dc=com&quot;
         by * write
    olcAccess: {2}to dn.children=&quot;dc=com&quot;
         by * read
</PRE>
<P>which is exactly what was intended.</P>
<H2><A NAME="Access Control Common Examples">8.4. Access Control Common Examples</A></H2>
<H3><A NAME="Basic ACLs">8.4.1. Basic ACLs</A></H3>
<P>Generally one should start with some basic ACLs such as:</P>
<PRE>
    access to attrs=userPassword
        by self =xw
        by anonymous auth
        by * none


      access to *
        by self write
        by users read
        by * none
</PRE>
<P>The first ACL allows users to update (but not read) their passwords, anonymous users to authenticate against this attribute, and (implicitly) denying all access to others.</P>
<P>The second ACL allows users full access to their entry, authenticated users read access to anything, and (implicitly) denying all access to others (in this case, anonymous users).</P>
<H3><A NAME="Matching Anonymous and Authenticated users">8.4.2. Matching Anonymous and Authenticated users</A></H3>
<P>An anonymous user has a empty DN. While the <EM>dn.exact=&quot;&quot;</EM> or <EM>dn.regex=&quot;^$&quot;</EM> could be used, <EM>slapd</EM>(8)) offers an anonymous shorthand which should be used instead.</P>
<PRE>
    access to *
      by anonymous none
      by * read
</PRE>
<P>denies all access to anonymous users while granting others read.</P>
<P>Authenticated users have a subject DN. While <EM>dn.regex=&quot;.+&quot;</EM> will match any authenticated user, OpenLDAP provides the users short hand which should be used instead.</P>
<PRE>
    access to *
      by users read
      by * none
</PRE>
<P>This ACL grants read permissions to authenticated users while denying others (i.e.: anonymous users).</P>
<H3><A NAME="Controlling rootdn access">8.4.3. Controlling rootdn access</A></H3>
<P>You could specify the <EM>rootdn</EM> in <EM>slapd.conf</EM>(5) or <EM>slapd.d</EM> without specifying a <EM>rootpw</EM>. Then you have to add an actual directory entry with the same dn, e.g.:</P>
<PRE>
    dn: cn=Manager,o=MyOrganization
    cn: Manager
    sn: Manager
    objectClass: person
    objectClass: top
    userPassword: {SSHA}someSSHAdata
</PRE>
<P>Then binding as the <EM>rootdn</EM> will require a regular bind to that DN, which in turn requires auth access to that entry's DN and <EM>userPassword</EM>, and this can be restricted via ACLs. E.g.:</P>
<PRE>
    access to dn.base=&quot;cn=Manager,o=MyOrganization&quot;
      by peername.regex=127\.0\.0\.1 auth
      by peername.regex=192\.168\.0\..* auth
      by users none
      by * none
</PRE>
<P>The ACLs above will only allow binding using rootdn from localhost and 192.168.0.0/24.</P>
<H3><A NAME="Managing access with Groups">8.4.4. Managing access with Groups</A></H3>
<P>There are a few ways to do this. One approach is illustrated here. Consider the following DIT layout:</P>
<PRE>
    +-dc=example,dc=com
    +---cn=administrators,dc=example,dc=com
    +---cn=fred blogs,dc=example,dc=com
</PRE>
<P>and the following group object (in LDIF format):</P>
<PRE>
    dn: cn=administrators,dc=example,dc=com
    cn: administrators of this region
    objectclass: groupOfNames  (important for the group acl feature)
    member: cn=fred blogs,dc=example,dc=com
    member: cn=somebody else,dc=example,dc=com
</PRE>
<P>One can then grant access to the members of this this group by adding appropriate <EM>by group</EM> clause to an access directive in <EM>slapd.conf</EM>(5). For instance,</P>
<PRE>
    access to dn.children=&quot;dc=example,dc=com&quot;
        by self write
        by group.exact=&quot;cn=Administrators,dc=example,dc=com&quot; write
        by * auth
</PRE>
<P>Like by <EM>dn</EM> clauses, one can also use <EM>expand</EM> to expand the group name based upon the regular expression matching of the target, that is, the to <EM>dn.regex</EM>). For instance,</P>
<PRE>
    access to dn.regex=&quot;(.+,)?ou=People,(dc=[^,]+,dc=[^,]+)$&quot;
             attrs=children,entry,uid
        by group.expand=&quot;cn=Managers,$2&quot; write
        by users read
        by * auth
</PRE>
<P>The above illustration assumed that the group members are to be found in the <EM>member</EM> attribute type of the <EM>groupOfNames</EM> object class. If you need to use a different group object and/or a different attribute type then use the following <EM>slapd.conf</EM>(5) (abbreviated) syntax:</P>
<PRE>
    access to &lt;what&gt;
            by group/&lt;objectclass&gt;/&lt;attributename&gt;=&lt;DN&gt; &lt;access&gt;
</PRE>
<P>For example:</P>
<PRE>
    access to *
      by group/organizationalRole/roleOccupant=&quot;cn=Administrator,dc=example,dc=com&quot; write
</PRE>
<P>In this case, we have an ObjectClass <EM>organizationalRole</EM> which contains the administrator DN's in the <EM>roleOccupant</EM> attribute. For instance:</P>
<PRE>
    dn: cn=Administrator,dc=example,dc=com
    cn: Administrator
    objectclass: organizationalRole
    roleOccupant: cn=Jane Doe,dc=example,dc=com
</PRE>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>the specified member attribute type MUST be of DN or <EM>NameAndOptionalUID</EM> syntax, and the specified object class SHOULD allow the attribute type.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>Dynamic Groups are also supported in Access Control. Please see <EM>slapo-dynlist</EM>(5) and the <A HREF="#Dynamic Lists">Dynamic Lists</A> overlay section.</P>
<H3><A NAME="Granting access to a subset of attributes">8.4.5. Granting access to a subset of attributes</A></H3>
<P>You can grant access to a set of attributes by specifying a list of attribute names in the ACL <EM>to</EM> clause. To be useful, you also need to grant access to the <EM>entry</EM> itself. Also note how <EM>children</EM> controls the ability to add, delete, and rename entries.</P>
<PRE>
    # mail: self may write, authenticated users may read
    access to attrs=mail
      by self write
      by users read
      by * none

    # cn, sn: self my write, all may read
    access to attrs=cn,sn
      by self write
      by * read

    # immediate children: only self can add/delete entries under this entry
    access to attrs=children
      by self write

    # entry itself: self may write, all may read
    access to attrs=entry
      by self write
      by * read

    # other attributes: self may write, others have no access
    access to *
      by self write
      by * none
</PRE>
<P>ObjectClass names may also be specified in this list, which will affect all the attributes that are required and/or allowed by that <EM>objectClass</EM>. Actually, names in <EM>attrlist</EM> that are prefixed by <EM>@</EM> are directly treated as objectClass names. A name prefixed by <EM>!</EM> is also treated as an objectClass, but in this case the access rule affects the attributes that are not required nor allowed by that <EM>objectClass</EM>.</P>
<H3><A NAME="Allowing a user write to all entries below theirs">8.4.6. Allowing a user write to all entries below theirs</A></H3>
<P>For a setup where a user can write to its own record and to all of its children:</P>
<PRE>
    access to dn.regex=&quot;(.+,)?(uid=[^,]+,o=Company)$&quot;
       by dn.exact,expand=&quot;$2&quot; write
       by anonymous auth
</PRE>
<P>(Add more examples for above)</P>
<H3><A NAME="Allowing entry creation">8.4.7. Allowing entry creation</A></H3>
<P>Let's say, you have it like this:</P>
<PRE>
        o=&lt;basedn&gt;
            ou=domains
                associatedDomain=&lt;somedomain&gt;
                    ou=users
                        uid=&lt;someuserid&gt;
                        uid=&lt;someotheruserid&gt;
                    ou=addressbooks
                        uid=&lt;someuserid&gt;
                            cn=&lt;someone&gt;
                            cn=&lt;someoneelse&gt;
</PRE>
<P>and, for another domain &lt;someotherdomain&gt;:</P>
<PRE>
        o=&lt;basedn&gt;
            ou=domains
                associatedDomain=&lt;someotherdomain&gt;
                    ou=users
                        uid=&lt;someuserid&gt;
                        uid=&lt;someotheruserid&gt;
                    ou=addressbooks
                        uid=&lt;someotheruserid&gt;
                            cn=&lt;someone&gt;
                            cn=&lt;someoneelse&gt;
</PRE>
<P>then, if you wanted user <EM>uid=&lt;someuserid&gt;</EM> to <B>ONLY</B> create an entry for its own thing, you could write an ACL like this:</P>
<PRE>
    # this rule lets users of &quot;associatedDomain=&lt;matcheddomain&gt;&quot;
    # write under &quot;ou=addressbook,associatedDomain=&lt;matcheddomain&gt;,ou=domains,o=&lt;basedn&gt;&quot;,
    # i.e. a user can write ANY entry below its domain's address book;
    # this permission is necessary, but not sufficient, the next
    # will restrict this permission further


    access to dn.regex=&quot;^ou=addressbook,associatedDomain=([^,]+),ou=domains,o=&lt;basedn&gt;$&quot; attrs=children
            by dn.regex=&quot;^uid=([^,]+),ou=users,associatedDomain=$1,ou=domains,o=&lt;basedn&gt;$$&quot; write
            by * none


    # Note that above the &quot;by&quot; clause needs a &quot;regex&quot; style to make sure
    # it expands to a DN that starts with a &quot;uid=&lt;someuserid&gt;&quot; pattern
    # while substituting the associatedDomain submatch from the &quot;what&quot; clause.


    # This rule lets a user with &quot;uid=&lt;matcheduid&gt;&quot; of &quot;&lt;associatedDomain=matcheddomain&gt;&quot;
    # write (i.e. add, modify, delete) the entry whose DN is exactly
    # &quot;uid=&lt;matcheduid&gt;,ou=addressbook,associatedDomain=&lt;matcheddomain&gt;,ou=domains,o=&lt;basedn&gt;&quot;
    # and ANY entry as subtree of it


    access to dn.regex=&quot;^(.+,)?uid=([^,]+),ou=addressbook,associatedDomain=([^,]+),ou=domains,o=&lt;basedn&gt;$&quot;
            by dn.exact,expand=&quot;uid=$2,ou=users,associatedDomain=$3,ou=domains,o=&lt;basedn&gt;&quot; write
            by * none


    # Note that above the &quot;by&quot; clause uses the &quot;exact&quot; style with the &quot;expand&quot;
    # modifier because now the whole pattern can be rebuilt by means of the
    # submatches from the &quot;what&quot; clause, so a &quot;regex&quot; compilation and evaluation
    # is no longer required.
</PRE>
<H3><A NAME="Tips for using regular expressions in Access Control">8.4.8. Tips for using regular expressions in Access Control</A></H3>
<P>Always use <EM>dn.regex=&lt;pattern&gt;</EM> when you intend to use regular expression matching. <EM>dn=&lt;pattern&gt;</EM> alone defaults to <EM>dn.exact&lt;pattern&gt;</EM>.</P>
<P>Use <EM>(.+)</EM> instead of <EM>(.*)</EM> when you want at least one char to be matched. <EM>(.*)</EM> matches the empty string as well.</P>
<P>Don't use regular expressions for matches that can be done otherwise in a safer and cheaper manner. Examples:</P>
<PRE>
    dn.regex=&quot;.*dc=example,dc=com&quot;
</PRE>
<P>is unsafe and expensive:</P>
<UL>
<LI>unsafe because any string containing <EM>dc=example,dc=com </EM>will match, not only those that end with the desired pattern; use <EM>.*dc=example,dc=com$</EM> instead.
<LI>unsafe also because it would allow any <EM>attributeType</EM> ending with <EM>dc</EM> as naming attribute for the first RDN in the string, e.g. a custom attributeType <EM>mydc</EM> would match as well. If you really need a regular expression that allows just <EM>dc=example,dc=com</EM> or any of its subtrees, use <EM>^(.+,)?dc=example,dc=com$</EM>, which means: anything to the left of dc=..., if any (the question mark after the pattern within brackets), must end with a comma;
<LI>expensive because if you don't need submatches, you could use scoping styles, e.g.</UL>
<PRE>
    dn.subtree=&quot;dc=example,dc=com&quot;
</PRE>
<P>to include <EM>dc=example,dc=com</EM> in the matching patterns,</P>
<PRE>
    dn.children=&quot;dc=example,dc=com&quot;
</PRE>
<P>to exclude <EM>dc=example,dc=com</EM> from the matching patterns, or</P>
<PRE>
    dn.onelevel=&quot;dc=example,dc=com&quot;
</PRE>
<P>to allow exactly one sublevel matches only.</P>
<P>Always use <EM>^</EM> and <EM>$</EM> in regexes, whenever appropriate, because <EM>ou=(.+),ou=(.+),ou=addressbooks,o=basedn</EM> will match <EM>something=bla,ou=xxx,ou=yyy,ou=addressbooks,o=basedn,ou=addressbooks,o=basedn,dc=some,dc=org</EM></P>
<P>Always use <EM>([^,]+)</EM> to indicate exactly one RDN, because <EM>(.+)</EM> can include any number of RDNs; e.g. <EM>ou=(.+),dc=example,dc=com</EM> will match <EM>ou=My,o=Org,dc=example,dc=com</EM>, which might not be what you want.</P>
<P>Never add the rootdn to the by clauses. ACLs are not even processed for operations performed with rootdn identity (otherwise there would be no reason to define a rootdn at all).</P>
<P>Use shorthands. The user directive matches authenticated users and the anonymous directive matches anonymous users.</P>
<P>Don't use the <EM>dn.regex</EM> form for &lt;by&gt; clauses if all you need is scoping and/or substring replacement; use scoping styles (e.g. <EM>exact</EM>, <EM>onelevel</EM>, <EM>children</EM> or <EM>subtree</EM>) and the style modifier expand to cause substring expansion.</P>
<P>For instance,</P>
<PRE>
    access to dn.regex=&quot;.+,dc=([^,]+),dc=([^,]+)$&quot;
      by dn.regex=&quot;^[^,],ou=Admin,dc=$1,dc=$2$$&quot; write
</PRE>
<P>although correct, can be safely and efficiently replaced by</P>
<PRE>
    access to dn.regex=&quot;.+,(dc=[^,]+,dc=[^,]+)$&quot;
      by dn.onelevel,expand=&quot;ou=Admin,$1&quot; write
</PRE>
<P>where the regex in the <EM>&lt;what&gt;</EM> clause is more compact, and the one in the <EM>&lt;by&gt;</EM> clause is replaced by a much more efficient scoping style of onelevel with substring expansion.</P>
<H3><A NAME="Granting and Denying access based on security strength factors (ssf)">8.4.9. Granting and Denying access based on security strength factors (ssf)</A></H3>
<P>You can restrict access based on the security strength factor (SSF)</P>
<PRE>
    access to dn=&quot;cn=example,cn=edu&quot;
          by * ssf=256 read
</PRE>
<P>0 (zero) implies no protection, 1 implies integrity protection only, 56 DES or other weak ciphers, 112 triple DES and similar ciphers, 128 RC4, Blowfish and other similar ciphers, 256 modern ciphers.</P>
<P>Other possibilities:</P>
<PRE>
    transport_ssf=&lt;n&gt;
    tls_ssf=&lt;n&gt;
    sasl_ssf=&lt;n&gt;
</PRE>
<P>256 is recommended.</P>
<P>See <EM>slapd.conf</EM>(5) for information on <EM>ssf</EM>.</P>
<H3><A NAME="When things aren\'t working as expected">8.4.10. When things aren't working as expected</A></H3>
<P>Consider this example:</P>
<PRE>
    access to *
      by anonymous auth

    access to *
      by self write

    access to *
      by users read
</PRE>
<P>You may think this will allow any user to login, to read everything and change his own data if he is logged in. But in this example only the login works and an ldapsearch returns no data. The Problem is that SLAPD goes through its access config line by line and stops as soon as it finds a match in the part of the access rule.(here: <EM>to *</EM>)</P>
<P>To get what we wanted the file has to read:</P>
<PRE>
    access to *
      by anonymous auth
      by self write
      by users read
</PRE>
<P>The general rule is: &quot;special access rules first, generic access rules last&quot;</P>
<P>See also <EM>slapd.access</EM>(5), loglevel 128 and <EM>slapacl</EM>(8) for debugging information.</P>
<H2><A NAME="Sets - Granting rights based on relationships">8.5. Sets - Granting rights based on relationships</A></H2>
<P>Sets are best illustrated via examples. The following sections will present a few set ACL examples in order to facilitate their understanding.</P>
<P>(Sets in Access Controls FAQ Entry: <A HREF="http://www.openldap.org/faq/data/cache/1133.html">http://www.openldap.org/faq/data/cache/1133.html</A>)</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>Sets are considered experimental.
<HR WIDTH="80%" ALIGN="Left"></P>
<H3><A NAME="Groups of Groups">8.5.1. Groups of Groups</A></H3>
<P>The OpenLDAP ACL for groups doesn't expand groups within groups, which are groups that have another group as a member. For example:</P>
<PRE>
 dn: cn=sudoadm,ou=group,dc=example,dc=com
 cn: sudoadm
 objectClass: groupOfNames
 member: uid=john,ou=people,dc=example,dc=com
 member: cn=accountadm,ou=group,dc=example,dc=com

 dn: cn=accountadm,ou=group,dc=example,dc=com
 cn: accountadm
 objectClass: groupOfNames
 member: uid=mary,ou=people,dc=example,dc=com
</PRE>
<P>If we use standard group ACLs with the above entries and allow members of the <TT>sudoadm</TT> group to write somewhere, <TT>mary</TT> won't be included:</P>
<PRE>
 access to dn.subtree=&quot;ou=sudoers,dc=example,dc=com&quot;
         by group.exact=&quot;cn=sudoadm,ou=group,dc=example,dc=com&quot; write
         by * read
</PRE>
<P>With sets we can make the ACL be recursive and consider group within groups. So for each member that is a group, it is further expanded:</P>
<PRE>
 access to dn.subtree=&quot;ou=sudoers,dc=example,dc=com&quot;
       by set=&quot;[cn=sudoadm,ou=group,dc=example,dc=com]/member* &amp; user&quot; write
       by * read
</PRE>
<P>This set ACL means: take the <TT>cn=sudoadm</TT> DN, check its <TT>member</TT> attribute(s) (where the &quot;<TT>*</TT>&quot; means recursively) and intersect the result with the authenticated user's DN. If the result is non-empty, the ACL is considered a match and write access is granted.</P>
<P>The following drawing explains how this set is built:</P>
<P><CENTER><IMG SRC="set-recursivegroup.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure X.Y: Populating a recursive group set</P>
<P>First we get the <TT>uid=john</TT> DN. This entry doesn't have a <TT>member</TT> attribute, so the expansion stops here.  Now we get to <TT>cn=accountadm</TT>. This one does have a <TT>member</TT> attribute, which is <TT>uid=mary</TT>. The <TT>uid=mary</TT> entry, however, doesn't have member, so we stop here again. The end comparison is:</P>
<PRE>
 {&quot;uid=john,ou=people,dc=example,dc=com&quot;,&quot;uid=mary,ou=people,dc=example,dc=com&quot;} &amp; user
</PRE>
<P>If the authenticated user's DN is any one of those two, write access is granted. So this set will include <TT>mary</TT> in the <TT>sudoadm</TT> group and she will be allowed the write access.</P>
<H3><A NAME="Group ACLs without DN syntax">8.5.2. Group ACLs without DN syntax</A></H3>
<P>The traditional group ACLs, and even the previous example about recursive groups, require that the members are specified as DNs instead of just usernames.</P>
<P>With sets, however, it's also possible to use simple names in group ACLs, as this example will show.</P>
<P>Let's say we want to allow members of the <TT>sudoadm</TT> group to write to the <TT>ou=sudoers</TT> branch of our tree. But our group definition now is using <TT>memberUid</TT> for the group members:</P>
<PRE>
 dn: cn=sudoadm,ou=group,dc=example,dc=com
 cn: sudoadm
 objectClass: posixGroup
 gidNumber: 1000
 memberUid: john
</PRE>
<P>With this type of group, we can't use group ACLs. But with a set ACL we can grant the desired access:</P>
<PRE>
 access to dn.subtree=&quot;ou=sudoers,dc=example,dc=com&quot;
       by set=&quot;[cn=sudoadm,ou=group,dc=example,dc=com]/memberUid &amp; user/uid&quot; write
       by * read
</PRE>
<P>We use a simple intersection where we compare the <TT>uid</TT> attribute of the connecting (and authenticated) user with the <TT>memberUid</TT> attributes of the group. If they match, the intersection is non-empty and the ACL will grant write access.</P>
<P>This drawing illustrates this set when the connecting user is authenticated as <TT>uid=john,ou=people,dc=example,dc=com</TT>:</P>
<P><CENTER><IMG SRC="set-memberUid.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure X.Y: Sets with <TT>memberUid</TT></P>
<P>In this case, it's a match. If it were <TT>mary</TT> authenticating, however, she would be denied write access to <TT>ou=sudoers</TT> because her <TT>uid</TT> attribute is not listed in the group's <TT>memberUid</TT>.</P>
<H3><A NAME="Following references">8.5.3. Following references</A></H3>
<P>We will now show a quite powerful example of what can be done with sets. This example tends to make OpenLDAP administrators smile after they have understood it and its implications.</P>
<P>Let's start with an user entry:</P>
<PRE>
 dn: uid=john,ou=people,dc=example,dc=com
 uid: john
 objectClass: inetOrgPerson
 givenName: John
 sn: Smith
 cn: john
 manager: uid=mary,ou=people,dc=example,dc=com
</PRE>
<P>Writing an ACL to allow the manager to update some attributes is quite simple using sets:</P>
<PRE>
 access to dn.exact=&quot;uid=john,ou=people,dc=example,dc=com&quot;
    attrs=carLicense,homePhone,mobile,pager,telephoneNumber
    by self write
    by set=&quot;this/manager &amp; user&quot; write
    by * read
</PRE>
<P>In that set, <TT>this</TT> expands to the entry being accessed, so that <TT>this/manager</TT> expands to <TT>uid=mary,ou=people,dc=example,dc=com</TT> when john's entry is accessed.  If the manager herself is accessing John's entry, the ACL will match and write access to those attributes will be granted.</P>
<P>So far, this same behavior can be obtained with the <TT>dnattr</TT> keyword. With sets, however, we can further enhance this ACL. Let's say we want to allow the secretary of the manager to also update these attributes. This is how we do it:</P>
<PRE>
 access to dn.exact=&quot;uid=john,ou=people,dc=example,dc=com&quot;
    attrs=carLicense,homePhone,mobile,pager,telephoneNumber
    by self write
    by set=&quot;this/manager &amp; user&quot; write
    by set=&quot;this/manager/secretary &amp; user&quot; write
    by * read
</PRE>
<P>Now we need a picture to help explain what is happening here (entries shortened for clarity):</P>
<P><CENTER><IMG SRC="set-following-references.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure X.Y: Sets jumping through entries</P>
<P>In this example, Jane is the secretary of Mary, which is the manager of John. This whole relationship is defined with the <TT>manager</TT> and <TT>secretary</TT> attributes, which are both of the distinguishedName syntax (i.e., full DNs). So, when the <TT>uid=john</TT> entry is being accessed, the <TT>this/manager/secretary</TT> set becomes <TT>{&quot;uid=jane,ou=people,dc=example,dc=com&quot;</TT>} (follow the references in the picture):</P>
<PRE>
 this = [uid=john,ou=people,dc=example,dc=com]
 this/manager = \
   [uid=john,ou=people,dc=example,dc=com]/manager = uid=mary,ou=people,dc=example,dc=com
 this/manager/secretary = \
   [uid=mary,ou=people,dc=example,dc=com]/secretary = uid=jane,ou=people,dc=example,dc=com
</PRE>
<P>The end result is that when Jane accesses John's entry, she will be granted write access to the specified attributes. Better yet, this will happen to any entry she accesses which has Mary as the manager.</P>
<P>This is all cool and nice, but perhaps gives too much power to secretaries. Maybe we need to further restrict it. For example, let's only allow executive secretaries to have this power:</P>
<PRE>
 access to dn.exact=&quot;uid=john,ou=people,dc=example,dc=com&quot;
   attrs=carLicense,homePhone,mobile,pager,telephoneNumber
   by self write
   by set=&quot;this/manager &amp; user&quot; write
   by set=&quot;this/manager/secretary &amp;
           [cn=executive,ou=group,dc=example,dc=com]/member* &amp;
           user&quot; write
   by * read
</PRE>
<P>It's almost the same ACL as before, but we now also require that the connecting user be a member of the (possibly nested) <TT>cn=executive</TT> group.</P>
<P></P>
<HR>
<H1><A NAME="Limits">9. Limits</A></H1>
<H2><A NAME="Introduction">9.1. Introduction</A></H2>
<P>It is usually desirable to limit the server resources that can be consumed by each LDAP client. OpenLDAP provides two sets of limits: a size limit, which can restrict the <EM>number</EM> of entries that a client can retrieve in a single operation, and a time limit which restricts the length of time that an operation may continue. Both types of limit can be given different values depending on who initiated the operation.</P>
<H2><A NAME="Soft and Hard limits">9.2. Soft and Hard limits</A></H2>
<P>The server administrator can specify both <EM>soft limits</EM> and <EM>hard limits</EM>. Soft limits can be thought of as being the default limit value. Hard limits cannot be exceeded by ordinary LDAP users.</P>
<P>LDAP clients can specify their own size and time limits when issuing search operations. This feature has been present since the earliest version of X.500.</P>
<P>If the client specifies a limit then the lower of the requested value and the <EM>hard limit</EM> will become the limit for the operation.</P>
<P>If the client does not specify a limit then the server applies the <EM>soft limit</EM>.</P>
<P>Soft and Hard limits are often referred to together as <EM>administrative limits</EM>. Thus, if an LDAP client requests a search that would return more results than the limits allow it will get an <EM>adminLimitExceeded</EM> error. Note that the server will usually return some results even if the limit has been exceeded: this feature is useful to clients that just want to check for the existence of some entries without needing to see them all.</P>
<P>The <EM>rootdn</EM> is not subject to any limits.</P>
<H2><A NAME="Global Limits">9.3. Global Limits</A></H2>
<P>Limits specified in the global part of the server configuration act as defaults which are used if no database has more specific limits set.</P>
<P>In a <EM>slapd.conf</EM>(5) configuration the keywords are <TT>sizelimit</TT> and <TT>timelimit</TT>. When using the <EM>slapd config</EM> backend, the corresponding attributes are <TT>olcSizeLimit</TT> and <TT>olcTimeLimit</TT>. The syntax of these values are the same in both cases.</P>
<P>The simple form sets both soft and hard limits to the same value:</P>
<PRE>
   sizelimit {&lt;integer&gt;|unlimited}
   timelimit {&lt;integer&gt;|unlimited}
</PRE>
<P>The default sizelimit is 500 entries and the default timelimit is 3600 seconds.</P>
<P>An extended form allows soft and hard limits to be set separately:</P>
<PRE>
   sizelimit size[.{soft|hard}]=&lt;integer&gt; [...]
   timelimit time[.{soft|hard}]=&lt;integer&gt; [...]
</PRE>
<P>Thus, to set a soft sizelimit of 10 entries and a hard limit of 75 entries:</P>
<PRE>
  sizelimit size.soft=10 size.hard=75
</PRE>
<H3><A NAME="Special Size Limits">9.3.1. Special Size Limits</A></H3>
<P>There are other forms of size limits in addition to the soft and hard limits. Note that when using the simple <EM>sizelimit</EM> form, none of these special limits are changed.</P>
<H4><A NAME="Unchecked Limits">9.3.1.1. Unchecked Limits</A></H4>
<P>The <EM>unchecked</EM> keyword sets a limit on how many entries the server will examine after doing index lookups but before evaluating filter matches. If the set of candidates exceeds this limit, the search is aborted. The purpose is to avoid causing excessive workload on <EM>slapd</EM> if a filter uses attributes that are not properly indexed, and can be critical for very large directories.</P>
<PRE>
   sizelimit size.unchecked={&lt;integer&gt;|unlimited|disabled}
</PRE>
<P>The default is unlimited. The <EM>disabled</EM> setting prevents a search from being performed at all. This may be useful in the per-database limits described below, to disallow searches for a specific set of users.</P>
<H4><A NAME="Paged Results Limits">9.3.1.2. Paged Results Limits</A></H4>
<P>If the LDAP client adds the <EM>pagedResultsControl</EM> to the search operation, the hard size limit is used by default, because the request for a specific page size is considered an explicit request for a limitation on the number of entries to be returned. However, the size limit applies to the total count of entries returned within the search, and not to a single page.</P>
<P>Additional size limits may be enforced for paged searches.</P>
<P>The <TT>size.pr</TT> limit controls the maximum page size:</P>
<PRE>
   sizelimit size.pr={&lt;integer&gt;|noEstimate|unlimited}
</PRE>
<P><TT>&lt;integer&gt;</TT> is the maximum page size if no explicit size is set. <TT>noEstimate</TT> has no effect in the current implementation as the server does not return an estimate of the result size anyway. <TT>unlimited</TT> indicates that no limit is applied to the maximum page size.</P>
<P>The <TT>size.prtotal</TT> limit controls the total number of entries that can be returned by a paged search. By default the limit is the same as the normal <TT>size.hard</TT> limit.</P>
<PRE>
   size.prtotal={&lt;integer&gt;|unlimited|disabled}
</PRE>
<P><TT>unlimited</TT> removes the limit on the number of entries that can be returned by a paged search. <TT>disabled</TT> can be used to selectively disable paged result searches.</P>
<H2><A NAME="Per-Database Limits">9.4. Per-Database Limits</A></H2>
<P>Each database can have its own set of limits that override the global ones. The syntax is more flexible, and it allows different limits to be applied to different entities. Note that an <EM>entity</EM> is different from an <EM>entry</EM>: the term <EM>entity</EM> is used here to indicate the ID of the person or process that has initiated the LDAP operation.</P>
<P>In a <EM>slapd.conf</EM>(5) configuration the keyword is <TT>limits</TT>. When using the <EM>slapd config</EM> backend, the corresponding attribute is <TT>olcLimits</TT>. The syntax of the values is the same in both cases.</P>
<PRE>
   limits &lt;selector&gt; &lt;limit&gt; [&lt;limit&gt; [...]]
</PRE>
<P>The <EM>limits</EM> clause can be specified multiple times to apply different limits to different initiators. The server examines each clause in turn until it finds one that matches the operation's initiator or base DN. If no match is found, the global limits will be used.</P>
<H3><A NAME="Specify who the limits apply to">9.4.1. Specify who the limits apply to</A></H3>
<P>The <TT>&lt;selector&gt;</TT> part of the <EM>limits</EM> clause can take any of these values:</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 9.1: Limits Entity Specifiers</CAPTION>
<TR CLASS="heading">
<TD>
<STRONG>Specifier</STRONG>
</TD>
<TD>
<STRONG>Entities</STRONG>
</TD>
</TR>
<TR>
<TD>
<TT>*</TT>
</TD>
<TD>
All, including anonymous and authenticated users
</TD>
</TR>
<TR>
<TD>
<TT>anonymous</TT>
</TD>
<TD>
Anonymous (non-authenticated) users
</TD>
</TR>
<TR>
<TD>
<TT>users</TT>
</TD>
<TD>
Authenticated users
</TD>
</TR>
<TR>
<TD>
<TT>dn[.&lt;type&gt;][.&lt;style&gt;]=&lt;pattern&gt;]</TT>
</TD>
<TD>
Entry or entries within a scope that match &lt;pattern&gt;
</TD>
</TR>
<TR>
<TD>
<TT>group[/oc[/at]]=&lt;pattern&gt;</TT>
</TD>
<TD>
Members of a group
</TD>
</TR>
</TABLE>

<P>Where</P>
<P><EM>type</EM> can be one of self or this and</P>
<P><EM>style</EM> can be one of exact, base, onelevel, subtree, children, regex, or anonymous</P>
<P>More information can be found in the <EM>slapd.conf</EM>(5) or <EM>slapd-config</EM>(5) manual pages.</P>
<H3><A NAME="Specify time limits">9.4.2. Specify time limits</A></H3>
<P>The syntax for time limits is</P>
<PRE>
   time[.{soft|hard}]=&lt;integer&gt;
</PRE>
<P>where integer is the number of seconds slapd will spend answering a search request.</P>
<P>If neither <EM>soft</EM> nor <EM>hard</EM> is specified, the value is used for both, e.g.:</P>
<PRE>
   limits anonymous time=27
</PRE>
<P>The value <EM>unlimited</EM> may be used to remove the hard time limit entirely, e.g.:</P>
<PRE>
   limits dn.exact=&quot;cn=anyuser,dc=example,dc=org&quot; time.hard=unlimited
</PRE>
<H3><A NAME="Specifying size limits">9.4.3. Specifying size limits</A></H3>
<P>The syntax for size limit is</P>
<PRE>
   size[.{soft|hard}]=&lt;integer&gt;
</PRE>
<P>where <TT>&lt;integer&gt;</TT> is the maximum number of entries slapd will return when answering a search request.</P>
<P>In addition to soft and hard limits, other limits are also available, with the same meanings described for the global limits configuration above.</P>
<H2><A NAME="Example Limit Configurations">9.5. Example Limit Configurations</A></H2>
<H3><A NAME="Simple Global Limits">9.5.1. Simple Global Limits</A></H3>
<P>This simple global configuration fragment applies size and time limits to all searches by all users except <EM>rootdn</EM>. It limits searches to 50 results and sets an overall time limit of 10 seconds.</P>
<PRE>
   sizelimit 50
   timelimit 10
</PRE>
<H3><A NAME="Global Hard and Soft Limits">9.5.2. Global Hard and Soft Limits</A></H3>
<P>It is sometimes useful to limit the size of result sets but to allow clients to request a higher limit where needed. This can be achieved by setting separate hard and soft limits.</P>
<PRE>
   sizelimit size.soft=5 size.hard=100
</PRE>
<P>To prevent clients from doing very inefficient non-indexed searches, add the <EM>unchecked</EM> limit:</P>
<PRE>
   sizelimit size.soft=5 size.hard=100 size.unchecked=100
</PRE>
<H3><A NAME="Giving specific users larger limits">9.5.3. Giving specific users larger limits</A></H3>
<P>Having set appropriate default limits in the global configuration, you may want to give certain users the ability to retrieve larger result sets. Here is a way to do that in the per-database configuration:</P>
<PRE>
   limits dn.exact=&quot;cn=anyuser,dc=example,dc=org&quot; size=100000
   limits dn.exact=&quot;cn=personnel,dc=example,dc=org&quot; size=100000
   limits dn.exact=&quot;cn=dirsync,dc=example,dc=org&quot; size=100000
</PRE>
<P>It is generally best to avoid mentioning specific users in the server configuration. A better way is to give the higher limits to a group:</P>
<PRE>
   limits group/groupOfNames/member=&quot;cn=bigwigs,dc=example,dc=org&quot; size=100000
</PRE>
<H3><A NAME="Limiting who can do paged searches">9.5.4. Limiting who can do paged searches</A></H3>
<P>It may be required that certain applications need very large result sets that they retrieve using paged searches, but that you do not want ordinary LDAP users to use the pagedResults control. The <EM>pr</EM> and <EM>prtotal</EM> limits can help:</P>
<PRE>
   limits group/groupOfNames/member=&quot;cn=dirsync,dc=example,dc=org&quot; size.prtotal=unlimited
   limits users size.soft=5 size.hard=100 size.prtotal=disabled
   limits anonymous size.soft=2 size.hard=5 size.prtotal=disabled
</PRE>
<H2><A NAME="Glued/Subordinate database configurations When using subordinate databases, it is necessary for any limits that are to be applied across the parent and its subordinates to be defined in both the parent and its subordinates. Otherwise the settings on the subordinate databases are not honored">9.6. Glued/Subordinate database configurations When using subordinate databases, it is necessary for any limits that are to be applied across the parent and its subordinates to be defined in both the parent and its subordinates. Otherwise the settings on the subordinate databases are not honored.</A></H2>
<H2><A NAME="Further Information">9.7. Further Information</A></H2>
<P>For further information please see <EM>slapd.conf</EM>(5), <EM>ldapsearch</EM>(1) and <EM>slapd.access</EM>(5)</P>
<P></P>
<HR>
<H1><A NAME="Database Creation and Maintenance Tools">10. Database Creation and Maintenance Tools</A></H1>
<P>This section tells you how to create a slapd database from scratch, and how to do trouble shooting if you run into problems. There are two ways to create a database. First, you can create the database on-line using <TERM>LDAP</TERM>. With this method, you simply start up slapd and add entries using the LDAP client of your choice. This method is fine for relatively small databases (a few hundred or thousand entries, depending on your requirements). This method works for database types which support updates.</P>
<P>The second method of database creation is to do it off-line using special utilities provided with <EM>slapd</EM>(8). This method is best if you have many thousands of entries to create, which would take an unacceptably long time using the LDAP method, or if you want to ensure the database is not accessed while it is being created. Note that not all database types support these utilities.</P>
<H2><A NAME="Creating a database over LDAP">10.1. Creating a database over LDAP</A></H2>
<P>With this method, you use the LDAP client of your choice (e.g., the <EM>ldapadd</EM>(1)) to add entries, just like you would once the database is created.  You should be sure to set the following options in the configuration file before starting <EM>slapd</EM>(8).</P>
<PRE>
        suffix &lt;dn&gt;
</PRE>
<P>As described in the <A HREF="#General Database Directives">General Database Directives</A> section, this option defines which entries are to be held by this database. You should set this to the DN of the root of the subtree you are trying to create.  For example:</P>
<PRE>
        suffix &quot;dc=example,dc=com&quot;
</PRE>
<P>You should be sure to specify a directory where the index files should be created:</P>
<PRE>
        directory &lt;directory&gt;
</PRE>
<P>For example:</P>
<PRE>
        directory /usr/local/var/openldap-data
</PRE>
<P>You need to create this directory with appropriate permissions such that slapd can write to it.</P>
<P>You need to configure slapd so that you can connect to it as a directory user with permission to add entries. You can configure the directory to support a special <EM>super-user</EM> or <EM>root</EM> user just for this purpose. This is done through the following two options in the database definition:</P>
<PRE>
        rootdn &lt;dn&gt;
        rootpw &lt;passwd&gt;
</PRE>
<P>For example:</P>
<PRE>
        rootdn &quot;cn=Manager,dc=example,dc=com&quot;
        rootpw secret
</PRE>
<P>These options specify a DN and password that can be used to authenticate as the <EM>super-user</EM> entry of the database (i.e., the entry allowed to do anything). The DN and password specified here will always work, regardless of whether the entry named actually exists or has the password given. This solves the chicken-and-egg problem of how to authenticate and add entries before any entries yet exist.</P>
<P>Finally, you should make sure that the database definition contains the index definitions you want:</P>
<PRE>
        index {&lt;attrlist&gt; | default} [pres,eq,approx,sub,none]
</PRE>
<P>For example, to index the <TT>cn</TT>, <TT>sn</TT>, <TT>uid</TT> and <TT>objectclass</TT> attributes, the following <TT>index</TT> directives could be used:</P>
<PRE>
        index cn,sn,uid pres,eq,approx,sub
        index objectClass eq
</PRE>
<P>This would create presence, equality, approximate, and substring indices for the <TT>cn</TT>, <TT>sn</TT>, and <TT>uid</TT> attributes and an equality index for the <TT>objectClass</TT> attribute.  Note that not all index types are available with all attribute types.  See <A HREF="#The slapd Configuration File">The slapd Configuration File</A> section for more information on this option.</P>
<P>Once you have configured things to your liking, start up slapd, connect with your LDAP client, and start adding entries.  For example, to add an organization entry and an organizational role entry using the <I>ldapadd</I> tool, you could create an <TERM>LDIF</TERM> file called <TT>entries.ldif</TT> with the contents:</P>
<PRE>
        # Organization for Example Corporation
        dn: dc=example,dc=com
        objectClass: dcObject
        objectClass: organization
        dc: example
        o: Example Corporation
        description: The Example Corporation

        # Organizational Role for Directory Manager
        dn: cn=Manager,dc=example,dc=com
        objectClass: organizationalRole
        cn: Manager
        description: Directory Manager
</PRE>
<P>and then use a command like this to actually create the entry:</P>
<PRE>
        ldapadd -f entries.ldif -x -D &quot;cn=Manager,dc=example,dc=com&quot; -w secret
</PRE>
<P>The above command assumes settings provided in the above examples.</P>
<H2><A NAME="Creating a database off-line">10.2. Creating a database off-line</A></H2>
<P>The second method of database creation is to do it off-line, using the slapd database tools described below. This method is best if you have many thousands of entries to create, which would take an unacceptably long time to add using the LDAP method described above. These tools read the slapd configuration file and an input file containing a text representation of the entries to add. For database types which support the tools, they produce the database files directly (otherwise you must use the on-line method above). Also, the input file must be completely valid, as these tools do fewer consistency checks than the on-line method.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>this Guide is not meant to provide exhaustive documentation on the software. The tool descriptions here only list a few of the available options for each command. Read the associated manpages for complete documentation on all of the available options.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>There are several important configuration options you will want to be sure and set in the config file database definition first:</P>
<PRE>
        suffix &lt;dn&gt;
</PRE>
<P>As described in the <A HREF="#General Database Directives">General Database Directives</A> section, this option defines which entries are to be held by this database. You should set this to the DN of the root of the subtree you are trying to create.  For example:</P>
<PRE>
        suffix &quot;dc=example,dc=com&quot;
</PRE>
<P>You should be sure to specify a directory where the index files should be created:</P>
<PRE>
        directory &lt;directory&gt;
</PRE>
<P>For example:</P>
<PRE>
        directory /usr/local/var/openldap-data
</PRE>
<P>Finally, you need to specify which indices you want to build.  This is done by one or more index options.</P>
<PRE>
        index {&lt;attrlist&gt; | default} [pres,eq,approx,sub,none]
</PRE>
<P>For example:</P>
<PRE>
        index cn,sn,uid pres,eq,approx,sub
        index objectClass eq
</PRE>
<P>This would create presence, equality, approximate, and substring indices for the <TT>cn</TT>, <TT>sn</TT>, and <TT>uid</TT> attributes and an equality index for the <TT>objectClass</TT> attribute.  Note that not all index types are available with all attribute types.  See <A HREF="#The slapd Configuration File">The slapd Configuration File</A> section for more information on this option.</P>
<H3><A NAME="The {{EX:slapadd}} program">10.2.1. The <TT>slapadd</TT> program</A></H3>
<P>Once you've configured things to your liking, you create the primary database and associated indices by running the <EM>slapadd</EM>(8) program:</P>
<PRE>
        slapadd -l &lt;inputfile&gt; -f &lt;slapdconfigfile&gt;
                [-d &lt;debuglevel&gt;] [-n &lt;integer&gt;|-b &lt;suffix&gt;]
</PRE>
<P>The arguments have the following meanings:</P>
<PRE>
        -l &lt;inputfile&gt;
</PRE>
<P>Specifies the <TERM>LDIF</TERM> input file containing the entries to add in text form (described below in the <A HREF="#The LDIF text entry format">The LDIF text entry format</A> section).</P>
<PRE>
        -f &lt;slapdconfigfile&gt;
</PRE>
<P>Specifies the slapd configuration file that tells where to create the indices, what indices to create, etc.</P>
<PRE>
        -F &lt;slapdconfdirectory&gt;
</PRE>
<P>Specifies a config directory.  If both <TT>-f</TT> and <TT>-F</TT> are specified, the config file will be read and converted to config  directory format and written to the specified directory.  If neither option is specified, an attempt to read the default config directory will be made before trying to use the default config file. If a valid config directory exists then the default config file is ignored. If dryrun mode is also specified, no conversion will occur.</P>
<PRE>
        -d &lt;debuglevel&gt;
</PRE>
<P>Turn on debugging, as specified by <TT>&lt;debuglevel&gt;</TT>. The debug levels are the same as for slapd.  See the <A HREF="#Command-Line Options">Command-Line Options</A> section in <A HREF="#Running slapd">Running slapd</A>.</P>
<PRE>
        -n &lt;databasenumber&gt;
</PRE>
<P>An optional argument that specifies which database to modify.  The first database listed in the configuration file is <TT>1</TT>, the second <TT>2</TT>, etc. By default, the first database in the configuration file is used. Should not be used in conjunction with <TT>-b</TT>.</P>
<PRE>
        -b &lt;suffix&gt;
</PRE>
<P>An optional argument that specifies which database to modify.  The provided suffix is matched against a database <TT>suffix</TT> directive to determine the database number. Should not be used in conjunction with <TT>-n</TT>.</P>
<H3><A NAME="The {{EX:slapindex}} program">10.2.2. The <TT>slapindex</TT> program</A></H3>
<P>Sometimes it may be necessary to regenerate indices (such as after modifying <EM>slapd.conf</EM>(5)). This is possible using the <EM>slapindex</EM>(8) program.  <EM>slapindex</EM> is invoked like this</P>
<PRE>
        slapindex -f &lt;slapdconfigfile&gt;
                [-d &lt;debuglevel&gt;] [-n &lt;databasenumber&gt;|-b &lt;suffix&gt;] [attr...]
</PRE>
<P>Where the <TT>-f</TT>, <TT>-d</TT>, <TT>-n</TT> and <TT>-b</TT> options are the same as for the <EM>slapadd</EM>(1) program.  If no specific attributes are listed, <EM>slapindex</EM> rebuilds all indices based upon the current database contents.</P>
<H3><A NAME="The {{EX:slapcat}} program">10.2.3. The <TT>slapcat</TT> program</A></H3>
<P>The <TT>slapcat</TT> program is used to dump the database to an <TERM>LDIF</TERM> file.  This can be useful when you want to make a human-readable backup of your database or when you want to edit your database off-line.  The program is invoked like this:</P>
<PRE>
        slapcat -l &lt;filename&gt; -f &lt;slapdconfigfile&gt;
                [-d &lt;debuglevel&gt;] [-n &lt;databasenumber&gt;|-b &lt;suffix&gt;]
</PRE>
<P>where <TT>-n</TT> or <TT>-b</TT> is used to select the database in the <EM>slapd.conf</EM>(5) specified using <TT>-f</TT>.  The corresponding <TERM>LDIF</TERM> output is written to standard output or to the file specified using the <TT>-l</TT> option.</P>
<H2><A NAME="The LDIF text entry format">10.3. The LDIF text entry format</A></H2>
<P>The <TERM>LDAP Data Interchange Format</TERM> (LDIF) is used to represent LDAP entries in a simple text format.  This section provides a brief description of the LDIF entry format which complements <EM>ldif</EM>(5) and the technical specification <A HREF="https://www.rfc-editor.org/rfc/rfc2849.txt">RFC2849</A>.</P>
<P>The basic form of an entry is:</P>
<PRE>
        # comment
        dn: &lt;distinguished name&gt;
        &lt;attrdesc&gt;: &lt;attrvalue&gt;
        &lt;attrdesc&gt;: &lt;attrvalue&gt;

        ...
</PRE>
<P>Lines starting with a '<TT>#</TT>' character are comments.  An attribute description may be a simple attribute type like <TT>cn</TT> or <TT>objectClass</TT> or <TT>1.2.3</TT> (an <TERM>OID</TERM> associated with an attribute type) or may include options such as <TT>cn;lang_en_US</TT> or <TT>userCertificate;binary</TT>.</P>
<P>A line may be continued by starting the next line with a <EM>single</EM> space or tab character.  For example:</P>
<PRE>
        dn: cn=Barbara J Jensen,dc=example,dc=
         com
        cn: Barbara J
          Jensen
</PRE>
<P>is equivalent to:</P>
<PRE>
        dn: cn=Barbara J Jensen,dc=example,dc=com
        cn: Barbara J Jensen
</PRE>
<P>Multiple attribute values are specified on separate lines. e.g.,</P>
<PRE>
        cn: Barbara J Jensen
        cn: Babs Jensen
</PRE>
<P>If an <TT>&lt;attrvalue&gt;</TT> contains non-printing characters or begins with a space, a colon ('<TT>:</TT>'), or a less than ('<TT>&lt;</TT>'), the <TT>&lt;attrdesc&gt;</TT> is followed by a double colon and the base64 encoding of the value.  For example, the value &quot;<TT> begins with a space</TT>&quot; would be encoded like this:</P>
<PRE>
        cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U=
</PRE>
<P>You can also specify a <TERM>URL</TERM> containing the attribute value. For example, the following specifies the <TT>jpegPhoto</TT> value should be obtained from the file <TT>/path/to/file.jpeg</TT>.</P>
<PRE>
        jpegPhoto:&lt; file:///path/to/file.jpeg
</PRE>
<P>Multiple entries within the same LDIF file are separated by blank lines. Here's an example of an LDIF file containing three entries.</P>
<PRE>
        # Barbara's Entry
        dn: cn=Barbara J Jensen,dc=example,dc=com
        cn: Barbara J Jensen
        cn: Babs Jensen
        objectClass: person
        sn: Jensen

        # Bjorn's Entry
        dn: cn=Bjorn J Jensen,dc=example,dc=com
        cn: Bjorn J Jensen
        cn: Bjorn Jensen
        objectClass: person
        sn: Jensen
        # Base64 encoded JPEG photo
        jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD
         A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ
         ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG

        # Jennifer's Entry
        dn: cn=Jennifer J Jensen,dc=example,dc=com
        cn: Jennifer J Jensen
        cn: Jennifer Jensen
        objectClass: person
        sn: Jensen
        # JPEG photo from file
        jpegPhoto:&lt; file:///path/to/file.jpeg
</PRE>
<P>Notice that the <TT>jpegPhoto</TT> in Bjorn's entry is base 64 encoded and the <TT>jpegPhoto</TT> in Jennifer's entry is obtained from the location indicated by the URL.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>Trailing spaces are not trimmed from values in an LDIF file. Nor are multiple internal spaces compressed. If you don't want them in your data, don't put them there.
<HR WIDTH="80%" ALIGN="Left"></P>
<P></P>
<HR>
<H1><A NAME="Backends">11. Backends</A></H1>
<P>Backends do the actual work of storing or retrieving data in response to LDAP requests. Backends may be compiled statically into <EM>slapd</EM>, or when module support is enabled, they may be dynamically loaded.</P>
<P>If your installation uses dynamic modules, you may need to add the relevant <EM>moduleload</EM> directives to the examples that follow. The name of the module for a backend is usually of the form:</P>
<PRE>
        back_&lt;backend name&gt;.la
</PRE>
<P>So for example, if you need to load the <EM>mdb</EM> backend, you would configure</P>
<PRE>
        moduleload back_mdb.la
</PRE>
<H2><A NAME="LDAP">11.1. LDAP</A></H2>
<H3><A NAME="Overview">11.1.1. Overview</A></H3>
<P>The LDAP backend to <EM>slapd</EM>(8) is not an actual database; instead it acts as a proxy to forward incoming requests to another LDAP server. While processing requests it will also chase referrals, so that referrals are fully processed instead of being returned to the <EM>slapd</EM> client.</P>
<P>Sessions that explicitly <EM>Bind</EM> to the <EM>back-ldap</EM> database always create their own private connection to the remote LDAP server. Anonymous sessions will share a single anonymous connection to the remote server. For sessions bound through other mechanisms, all sessions with the same DN will share the same connection. This connection pooling strategy can enhance the proxy's efficiency by reducing the overhead of repeatedly making/breaking multiple connections.</P>
<P>The ldap database can also act as an information service, i.e. the identity of locally authenticated clients is asserted to the remote server, possibly in some modified form. For this purpose, the proxy binds to the remote server with some administrative identity, and, if required, authorizes the asserted identity.</P>
<P>It is heavily used by a lot of other <A HREF="#Backends">Backends</A> and <A HREF="#Overlays">Overlays</A>.</P>
<H3><A NAME="back-ldap Configuration">11.1.2. back-ldap Configuration</A></H3>
<P>As previously mentioned, <EM>slapd-ldap(5)</EM> is used behind the scenes by many other <A HREF="#Backends">Backends</A> and <A HREF="#Overlays">Overlays</A>. Some of them merely provide a few configuration directive themselves, but have available to the administrator the whole of the <EM>slapd-ldap(5)</EM> options.</P>
<P>For example, the <A HREF="#Translucent Proxy">Translucent Proxy</A>, which retrieves entries from a remote LDAP server that can be partially overridden by the defined database, has only four specific <EM>translucent-</EM> directives, but can be configured using any of the normal <EM>slapd-ldap(5)</EM> options. See {[slapo-translucent(5)}} for details.</P>
<P>Other <A HREF="#Overlays">Overlays</A> allow you to tag directives in front of a normal <EM>slapd-ldap(5)</EM> directive. For example, the <EM>slapo-chain(5)</EM> overlay does this:</P>
<P><EM>&quot;There are very few chain overlay specific directives; however, directives related to the instances of the ldap backend that may be implicitly instantiated by the overlay may assume a special meaning when used in conjunction with this overlay.  They are described in slapd-ldap(5), and they also need to be prefixed by chain-.&quot;</EM></P>
<P>You may have also seen the <EM>slapd-ldap(5)</EM> backend used and described in the <A HREF="#Push Based">Push Based</A> <A HREF="#Replication">Replication</A> section of the guide.</P>
<P>It should therefore be obvious that the <EM>slapd-ldap(5)</EM> backend is extremely flexible and heavily used throughout the OpenLDAP Suite.</P>
<P>The following is a very simple example, but already the power of the <EM>slapd-ldap(5)</EM> backend is seen by use of a <EM>uri list</EM>:</P>
<PRE>
        database        ldap
        suffix          &quot;dc=suretecsystems,dc=com&quot;
        rootdn          &quot;cn=slapd-ldap&quot;
        uri             ldap://localhost/ ldap://remotehost ldap://remotehost2
</PRE>
<P>The URI list is space or comma-separated. Whenever the server that responds is not the first one in the list, the list is rearranged and the responsive server is moved to the head, so that it will be first contacted the next time a connection needs be created.</P>
<P>This feature can be used to provide a form of load balancing when using <A HREF="#Mirror mode replication">Mirror mode replication</A>.</P>
<H3><A NAME="Further Information">11.1.3. Further Information</A></H3>
<P><EM>slapd-ldap</EM>(5)</P>
<H2><A NAME="LDIF">11.2. LDIF</A></H2>
<H3><A NAME="Overview">11.2.1. Overview</A></H3>
<P>The LDIF backend to <EM>slapd</EM>(8) is a basic storage backend that stores entries in text files in LDIF format, and exploits the filesystem to create the tree structure of the database. It is intended as a cheap, low performance easy to use backend.</P>
<P>When using the <EM>cn=config</EM> dynamic configuration database with persistent storage, the configuration data is stored using this backend. See <EM>slapd-config</EM>(5) for more information</P>
<H3><A NAME="back-ldif Configuration">11.2.2. back-ldif Configuration</A></H3>
<P>Like many other backends, the LDIF backend can be instantiated with very few configuration lines:</P>
<PRE>
        include ./schema/core.schema

        database  ldif
        directory ./ldif
        suffix    &quot;dc=suretecsystems,dc=com&quot;
        rootdn    &quot;cn=LDIF,dc=suretecsystems,dc=com&quot;
        rootpw    LDIF
</PRE>
<P>If we add the <EM>dcObject</EM> for <EM>dc=suretecsystems,dc=com</EM>, you can see how this is added behind the scenes on the file system:</P>
<PRE>
   dn: dc=suretecsystems,dc=com
   objectClass: dcObject
   objectClass: organization
   dc: suretecsystems
   o: Suretec Systems Ltd
</PRE>
<P>Now we add it to the directory:</P>
<PRE>
   ldapadd -x -H ldap://localhost:9011 -f suretec.ldif -D &quot;cn=LDIF,dc=suretecsystems,dc=com&quot; -w LDIF
   adding new entry &quot;dc=suretecsystems,dc=com&quot;
</PRE>
<P>And inside <TT>./ldif</TT> we have:</P>
<PRE>
   ls ./ldif
   dc=suretecsystems,dc=com.ldif
</PRE>
<P>which again contains:</P>
<PRE>
   cat ldif/dc\=suretecsystems\,dc\=com.ldif

   dn: dc=suretecsystems
   objectClass: dcObject
   objectClass: organization
   dc: suretecsystems
   o: Suretec Systems Ltd.
   structuralObjectClass: organization
   entryUUID: 2134b714-e3a1-102c-9a15-f96ee263886d
   creatorsName: cn=LDIF,dc=suretecsystems,dc=com
   createTimestamp: 20080711142643Z
   entryCSN: 20080711142643.661124Z#000000#000#000000
   modifiersName: cn=LDIF,dc=suretecsystems,dc=com
   modifyTimestamp: 20080711142643Z
</PRE>
<P>This is the complete format you would get when exporting your directory using <TT>slapcat</TT> etc.</P>
<H3><A NAME="Further Information">11.2.3. Further Information</A></H3>
<P><EM>slapd-ldif</EM>(5)</P>
<H2><A NAME="LMDB">11.3. LMDB</A></H2>
<H3><A NAME="Overview">11.3.1. Overview</A></H3>
<P>The <EM>mdb</EM> backend to <EM>slapd</EM>(8) is the recommended primary backend for a normal <EM>slapd</EM> database.  It uses OpenLDAP's own Lightning Memory-Mapped Database (<TERM>LMDB</TERM>) library to store data and replaces the BerkeleyDB backends used in older OpenLDAP releases.</P>
<P>It supports indexing, it uses no caching, and requires no tuning to deliver maximum search performance.  It is fully hierarchical and supports subtree renames in constant time.</P>
<H3><A NAME="back-mdb Configuration">11.3.2. back-mdb Configuration</A></H3>
<P>The <EM>mdb</EM> backend can be instantiated with very few configuration lines:</P>
<PRE>
        include ./schema/core.schema

        database  mdb
        directory ./mdb
        suffix    &quot;dc=suretecsystems,dc=com&quot;
        rootdn    &quot;cn=mdb,dc=suretecsystems,dc=com&quot;
        rootpw    mdb
        maxsize   1073741824
</PRE>
<P>In addition to the usual parameters that a minimal configuration requires, the <EM>mdb</EM> backend requires a maximum size to be set. This should be the largest that the database is ever anticipated to grow (in bytes). The filesystem must also provide enough free space to accommodate this size.</P>
<H3><A NAME="Further Information">11.3.3. Further Information</A></H3>
<P><EM>slapd-mdb</EM>(5)</P>
<H2><A NAME="Metadirectory">11.4. Metadirectory</A></H2>
<H3><A NAME="Overview">11.4.1. Overview</A></H3>
<P>The meta backend to <EM>slapd</EM>(8) performs basic LDAP proxying with respect to a set of remote LDAP servers, called &quot;targets&quot;. The information contained in these servers can be presented as belonging to a single Directory Information Tree (<TERM>DIT</TERM>).</P>
<P>A basic knowledge of the functionality of the <EM>slapd-ldap</EM>(5) backend is recommended. This backend has been designed as an enhancement of the ldap backend. The two backends share many features (actually they also share portions of code). While the ldap backend is intended to proxy operations directed to a single server, the meta backend is mainly intended for proxying of multiple servers and possibly naming context  masquerading.</P>
<P>These features, although useful in many scenarios, may result in excessive overhead for some applications, so its use should be carefully considered.</P>
<H3><A NAME="back-meta Configuration">11.4.2. back-meta Configuration</A></H3>
<P>LATER</P>
<H3><A NAME="Further Information">11.4.3. Further Information</A></H3>
<P><EM>slapd-meta</EM>(5)</P>
<H2><A NAME="Monitor">11.5. Monitor</A></H2>
<H3><A NAME="Overview">11.5.1. Overview</A></H3>
<P>The monitor backend to <EM>slapd</EM>(8) is not an actual database; if enabled, it is automatically generated and dynamically maintained by slapd with information about the running status of the daemon.</P>
<P>To inspect all monitor information, issue a subtree search with base <EM>cn=Monitor</EM>, requesting that attributes &quot;+&quot; and &quot;*&quot; are returned. The monitor backend produces mostly operational attributes, and LDAP only returns operational attributes that are explicitly requested.  Requesting attribute &quot;+&quot; is an extension which requests all operational attributes.</P>
<P>See the <A HREF="#Monitoring">Monitoring</A> section.</P>
<H3><A NAME="back-monitor Configuration">11.5.2. back-monitor Configuration</A></H3>
<P>The monitor database can be instantiated only once, i.e. only one occurrence of &quot;database monitor&quot; can occur in the <EM>slapd.conf(5)</EM> file.  Also the suffix is automatically set to <EM>&quot;cn=Monitor&quot;</EM>.</P>
<P>You can however set a <EM>rootdn</EM> and <EM>rootpw</EM>. The following is all that is needed to instantiate a monitor backend:</P>
<PRE>
        include ./schema/core.schema

        database monitor
        rootdn &quot;cn=monitoring,cn=Monitor&quot;
        rootpw monitoring
</PRE>
<P>You can also apply Access Control to this database like any other database, for example:</P>
<PRE>
        access to dn.subtree=&quot;cn=Monitor&quot;
             by dn.exact=&quot;uid=Admin,dc=my,dc=org&quot; write
             by users read
             by * none
</PRE>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>The <TT>core.schema</TT> must be loaded for the monitor database to work.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>A small example of the data returned via <EM>ldapsearch</EM> would be:</P>
<PRE>
        ldapsearch -x -H ldap://localhost:9011 -b 'cn=Monitor'
        # extended LDIF
        #
        # LDAPv3
        # base &lt;cn=Monitor&gt; with scope subtree
        # filter: (objectclass=*)
        # requesting: ALL
        #

        # Monitor
        dn: cn=Monitor
        objectClass: monitorServer
        cn: Monitor
        description: This subtree contains monitoring/managing objects.
        description: This object contains information about this server.
        description: Most of the information is held in operational attributes, which
         must be explicitly requested.

        # Backends, Monitor
        dn: cn=Backends,cn=Monitor
        objectClass: monitorContainer
        cn: Backends
        description: This subsystem contains information about available backends.
</PRE>
<P>Please see the <A HREF="#Monitoring">Monitoring</A> section for complete examples of information available via this backend.</P>
<H3><A NAME="Further Information">11.5.3. Further Information</A></H3>
<P><EM>slapd-monitor</EM>(5)</P>
<H2><A NAME="Null">11.6. Null</A></H2>
<H3><A NAME="Overview">11.6.1. Overview</A></H3>
<P>The Null backend to <EM>slapd</EM>(8) is surely the most useful part of slapd:</P>
<UL>
<LI>Searches return success but no entries.
<LI>Compares return compareFalse.
<LI>Updates return success (unless readonly is on) but do nothing.
<LI>Binds other than as the rootdn fail unless the database option &quot;bind on&quot; is given.
<LI>The slapadd(8) and slapcat(8) tools are equally exciting.</UL>
<P>Inspired by the <TT>/dev/null</TT> device.</P>
<H3><A NAME="back-null Configuration">11.6.2. back-null Configuration</A></H3>
<P>This has to be one of the shortest configurations you'll ever do. In order to test this, your <TT>slapd.conf</TT> file would look like:</P>
<PRE>
        database null
        suffix &quot;cn=Nothing&quot;
        bind on
</PRE>
<P><EM>bind on</EM> means:</P>
<P><EM>&quot;Allow binds as any DN in this backend's suffix, with any password. The default is &quot;off&quot;.&quot;</EM></P>
<P>To test this backend with <EM>ldapsearch</EM>:</P>
<PRE>
        ldapsearch -x -H ldap://localhost:9011 -D &quot;uid=none,cn=Nothing&quot; -w testing -b 'cn=Nothing'
        # extended LDIF
        #
        # LDAPv3
        # base &lt;cn=Nothing&gt; with scope subtree
        # filter: (objectclass=*)
        # requesting: ALL
        #

        # search result
        search: 2
        result: 0 Success

        # numResponses: 1
</PRE>
<H3><A NAME="Further Information">11.6.3. Further Information</A></H3>
<P><EM>slapd-null</EM>(5)</P>
<H2><A NAME="Passwd">11.7. Passwd</A></H2>
<H3><A NAME="Overview">11.7.1. Overview</A></H3>
<P>The PASSWD backend to <EM>slapd</EM>(8) serves up the user account information listed in the system <EM>passwd</EM>(5) file (defaulting to <TT>/etc/passwd</TT>).</P>
<P>This backend is provided for demonstration purposes only. The DN of each entry is &quot;uid=&lt;username&gt;,&lt;suffix&gt;&quot;.</P>
<H3><A NAME="back-passwd Configuration">11.7.2. back-passwd Configuration</A></H3>
<P>The configuration using <TT>slapd.conf</TT> a slightly longer, but not much. For example:</P>
<PRE>
        include ./schema/core.schema

        database passwd
        suffix &quot;cn=passwd&quot;
</PRE>
<P>Again, testing this with <EM>ldapsearch</EM> would result in something like:</P>
<PRE>
        ldapsearch -x -H ldap://localhost:9011 -b 'cn=passwd'
        # extended LDIF
        #
        # LDAPv3
        # base &lt;cn=passwd&gt; with scope subtree
        # filter: (objectclass=*)
        # requesting: ALL
        #

        # passwd
        dn: cn=passwd
        cn: passwd
        objectClass: organizationalUnit

        # root, passwd
        dn: uid=root,cn=passwd
        objectClass: person
        objectClass: uidObject
        uid: root
        cn: root
        sn: root
        description: root
</PRE>
<H3><A NAME="Further Information">11.7.3. Further Information</A></H3>
<P><EM>slapd-passwd</EM>(5)</P>
<H2><A NAME="Perl">11.8. Perl</A></H2>
<H3><A NAME="Overview">11.8.1. Overview</A></H3>
<P>The Perl backend to <EM>slapd</EM>(8) works by embedding a <EM>perl</EM>(1) interpreter into <EM>slapd</EM>(8). Any perl database section of the configuration file <EM>slapd.conf</EM>(5) must then specify what Perl module to use. Slapd then creates a new Perl object that handles all the requests for that particular instance of the backend.</P>
<H3><A NAME="back-perl Configuration">11.8.2. back-perl Configuration</A></H3>
<P>LATER</P>
<H3><A NAME="Further Information">11.8.3. Further Information</A></H3>
<P><EM>slapd-perl</EM>(5)</P>
<H2><A NAME="Relay">11.9. Relay</A></H2>
<H3><A NAME="Overview">11.9.1. Overview</A></H3>
<P>The primary purpose of this <EM>slapd</EM>(8) backend is to map a naming context defined in a database running in the same <EM>slapd</EM>(8) instance into a virtual naming context, with attributeType and objectClass manipulation, if required. It requires the rwm overlay.</P>
<P>This backend and the above mentioned overlay are experimental.</P>
<H3><A NAME="back-relay Configuration">11.9.2. back-relay Configuration</A></H3>
<P>LATER</P>
<H3><A NAME="Further Information">11.9.3. Further Information</A></H3>
<P><EM>slapd-relay</EM>(5)</P>
<H2><A NAME="SQL">11.10. SQL</A></H2>
<H3><A NAME="Overview">11.10.1. Overview</A></H3>
<P>The primary purpose of this <EM>slapd</EM>(8) backend is to PRESENT information stored in some RDBMS as an LDAP subtree without any programming (some SQL and maybe stored procedures can't be considered programming, anyway ;).</P>
<P>That is, for example, when you (some ISP) have account information you use in an RDBMS, and want to use modern solutions that expect such information in LDAP (to authenticate users, make email lookups etc.). Or you want to synchronize or distribute information between different sites/applications that use RDBMSes and/or LDAP. Or whatever else...</P>
<P>It is <B>NOT</B> designed as a general-purpose backend that uses RDBMS instead of LMDB (as the standard back-mdb backend does), though it can be used as such with several limitations. Please see <A HREF="#LDAP vs RDBMS">LDAP vs RDBMS</A> for discussion.</P>
<P>The idea is to use some meta-information to translate LDAP queries to SQL queries, leaving relational schema untouched, so that old applications can continue using it without any modifications. This allows SQL and LDAP applications to interoperate without replication, and exchange data as needed.</P>
<P>The SQL backend is designed to be tunable to virtually any relational schema without having to change source (through that meta-information mentioned). Also, it uses ODBC to connect to RDBMSes, and is highly configurable for SQL dialects RDBMSes may use, so it may be used for integration and distribution of data on different RDBMSes, OSes, hosts etc., in other words, in highly heterogeneous environments.</P>
<P>This backend is experimental and deprecated.</P>
<H3><A NAME="back-sql Configuration">11.10.2. back-sql Configuration</A></H3>
<P>This backend has to be one of the most abused and complex backends there is. Therefore, we will go through a simple, small example that comes with the OpenLDAP source and can be found in <TT>servers/slapd/back-sql/rdbms_depend/README</TT></P>
<P>For this example we will be using PostgreSQL.</P>
<P>First, we add to <TT>/etc/odbc.ini</TT> a block of the form:</P>
<PRE>
        [example]                        &lt;===
        Description         = Example for OpenLDAP's back-sql
        Driver              = PostgreSQL
        Trace               = No
        Database            = example    &lt;===
        Servername          = localhost
        UserName            = manager    &lt;===
        Password            = secret     &lt;===
        Port                = 5432
        ;Protocol            = 6.4
        ReadOnly            = No
        RowVersioning       = No
        ShowSystemTables    = No
        ShowOidColumn       = No
        FakeOidIndex        = No
        ConnSettings        =
</PRE>
<P>The relevant information for our test setup is highlighted with '&lt;===' on the right above.</P>
<P>Next, we add to <TT>/etc/odbcinst.ini</TT> a block of the form:</P>
<PRE>
        [PostgreSQL]
        Description     = ODBC for PostgreSQL
        Driver          = /usr/lib/libodbcpsql.so
        Setup           = /usr/lib/libodbcpsqlS.so
        FileUsage       = 1
</PRE>
<P>We will presume you know how to create a database and user in PostgreSQL and how to set a password. Also, we'll presume you can populate the 'example' database you've just created with the following files, as found in <TT>servers/slapd/back-sql/rdbms_depend/pgsql </TT></P>
<PRE>
        backsql_create.sql, testdb_create.sql, testdb_data.sql, testdb_metadata.sql
</PRE>
<P>Lastly, run the test:</P>
<PRE>
        [root@localhost]# cd $SOURCES/tests
        [root@localhost]# SLAPD_USE_SQL=pgsql ./run sql-test000
</PRE>
<P>Briefly, you should see something like (cut short for space):</P>
<PRE>
        Cleaning up test run directory leftover from previous run.
        Running ./scripts/sql-test000-read...
        running defines.sh
        Starting slapd on TCP/IP port 9011...
        Testing SQL backend read operations...
        Waiting 5 seconds for slapd to start...
        Testing correct bind... dn:cn=Mitya Kovalev,dc=example,dc=com
        Testing incorrect bind (should fail)... ldap_bind: Invalid credentials (49)

        ......

        Filtering original ldif...
        Comparing filter output...
        &gt;&gt;&gt;&gt;&gt; Test succeeded
</PRE>
<P>The test is basically readonly; this can be performed by all RDBMSes (listed above).</P>
<P>There is another test, sql-test900-write, which is currently enabled only for PostgreSQL and IBM db2.</P>
<P>Using <TT>sql-test000</TT>, files in <TT>servers/slapd/back-sql/rdbms_depend/pgsql/</TT> and the man page, you should be set.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>This backend is experimental and deprecated.
<HR WIDTH="80%" ALIGN="Left"></P>
<H3><A NAME="Further Information">11.10.3. Further Information</A></H3>
<P><EM>slapd-sql</EM>(5) and <TT>servers/slapd/back-sql/rdbms_depend/README</TT></P>
<P></P>
<HR>
<H1><A NAME="Overlays">12. Overlays</A></H1>
<P>Overlays are software components that provide hooks to functions analogous to those provided by backends, which can be stacked on top of the backend calls and as callbacks on top of backend responses to alter their behavior.</P>
<P>Overlays may be compiled statically into <EM>slapd</EM>, or when module support is enabled, they may be dynamically loaded. Most of the overlays are only allowed to be configured on individual databases.</P>
<P>Some can be stacked on the <TT>frontend</TT> as well, for global use. This means that they can be executed after a request is parsed and validated, but right before the appropriate database is selected. The main purpose is to affect operations regardless of the database they will be handled by, and, in some cases, to influence the selection of the database by massaging the request DN.</P>
<P>Essentially, overlays represent a means to:</P>
<UL>
<LI>customize the behavior of existing backends without changing the backend code and without requiring one to write a new custom backend with complete functionality
<LI>write functionality of general usefulness that can be applied to different backend types</UL>
<P>When using <EM>slapd.conf</EM>(5), overlays that are configured before any other databases are considered global, as mentioned above. In fact they are implicitly stacked on top of the <TT>frontend</TT> database. They can also be explicitly configured as such:</P>
<PRE>
        database frontend
        overlay &lt;overlay name&gt;
</PRE>
<P>Overlays are usually documented by separate specific man pages in section 5; the naming convention is</P>
<PRE>
        slapo-&lt;overlay name&gt;
</PRE>
<P>All distributed core overlays have a man page. Feel free to contribute to any, if you think there is anything missing in describing the behavior of the component and the implications of all the related configuration directives.</P>
<P>Official overlays are located in</P>
<PRE>
        servers/slapd/overlays/
</PRE>
<P>That directory also contains the file slapover.txt, which describes the rationale of the overlay implementation, and may serve as a guideline for the development of custom overlays.</P>
<P>Contribware overlays are located in</P>
<PRE>
        contrib/slapd-modules/&lt;overlay name&gt;/
</PRE>
<P>along with other types of run-time loadable components; they are officially distributed, but not maintained by the project.</P>
<P>All the current overlays in OpenLDAP are listed and described in detail in the following sections.</P>
<H2><A NAME="Access Logging">12.1. Access Logging</A></H2>
<H3><A NAME="Overview">12.1.1. Overview</A></H3>
<P>This overlay can record accesses to a given backend database on another database.</P>
<P>This allows all of the activity on a given database to be reviewed using arbitrary LDAP queries, instead of just logging to local flat text files. Configuration options are available for selecting a subset of operation types to log, and to automatically prune older log records from the logging database. Log records are stored with audit schema to assure their readability whether viewed as LDIF or in raw form.</P>
<P>It is also used for <A HREF="#delta-syncrepl replication">delta-syncrepl replication</A></P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>An accesslog database is unique to a given provider. It should never be replicated.
<HR WIDTH="80%" ALIGN="Left"></P>
<H3><A NAME="Access Logging Configuration">12.1.2. Access Logging Configuration</A></H3>
<P>The following is a basic example that implements Access Logging:</P>
<PRE>
        database mdb
        suffix dc=example,dc=com
        ...
        overlay accesslog
        logdb cn=log
        logops writes reads
        logold (objectclass=person)

        database mdb
        suffix cn=log
        ...
        index reqStart eq
        access to *
          by dn.base=&quot;cn=admin,dc=example,dc=com&quot; read
</PRE>
<P>The following is an example used for <A HREF="#delta-syncrepl replication">delta-syncrepl replication</A>:</P>
<PRE>
        database mdb
        suffix cn=accesslog
        directory /usr/local/var/openldap-accesslog
        rootdn cn=accesslog
        index default eq
        index entryCSN,objectClass,reqEnd,reqResult,reqStart,reqDN
</PRE>
<P>Accesslog overlay definitions for the primary db</P>
<PRE>
        database mdb
        suffix dc=example,dc=com
        ...
        overlay accesslog
        logdb cn=accesslog
        logops writes
        logsuccess TRUE
        # scan the accesslog DB every day, and purge entries older than 7 days
        logpurge 07+00:00 01+00:00
</PRE>
<P>An example search result against <B>cn=accesslog</B> might look like:</P>
<PRE>
        [ghenry@suretec ghenry]# ldapsearch -x -b cn=accesslog
        # extended LDIF
        #
        # LDAPv3
        # base &lt;cn=accesslog&gt; with scope subtree
        # filter: (objectclass=*)
        # requesting: ALL
        #

        # accesslog
        dn: cn=accesslog
        objectClass: auditContainer
        cn: accesslog

        # 20080110163829.000004Z, accesslog
        dn: reqStart=20080110163829.000004Z,cn=accesslog
        objectClass: auditModify
        reqStart: 20080110163829.000004Z
        reqEnd: 20080110163829.000005Z
        reqType: modify
        reqSession: 196696
        reqAuthzID: cn=admin,dc=suretecsystems,dc=com
        reqDN: uid=suretec-46022f8$,ou=Users,dc=suretecsystems,dc=com
        reqResult: 0
        reqMod: sambaPwdCanChange:- ###CENSORED###
        reqMod: sambaPwdCanChange:+ ###CENSORED###
        reqMod: sambaNTPassword:- ###CENSORED###
        reqMod: sambaNTPassword:+ ###CENSORED###
        reqMod: sambaPwdLastSet:- ###CENSORED###
        reqMod: sambaPwdLastSet:+ ###CENSORED###
        reqMod: entryCSN:= 20080110163829.095157Z#000000#000#000000
        reqMod: modifiersName:= cn=admin,dc=suretecsystems,dc=com
        reqMod: modifyTimestamp:= 20080110163829Z

        # search result
        search: 2
        result: 0 Success

        # numResponses: 3
        # numEntries: 2
</PRE>
<H3><A NAME="Further Information">12.1.3. Further Information</A></H3>
<P><EM>slapo-accesslog(5)</EM> and the <A HREF="#delta-syncrepl replication">delta-syncrepl replication</A> section.</P>
<H2><A NAME="Audit Logging">12.2. Audit Logging</A></H2>
<P>The Audit Logging overlay can be used to record all changes on a given backend database to a specified log file.</P>
<H3><A NAME="Overview">12.2.1. Overview</A></H3>
<P>If the need arises whereby changes need to be logged as standard LDIF, then the auditlog overlay <B>slapo-auditlog (5)</B> can be used. Full examples are available in the man page <B>slapo-auditlog (5)</B></P>
<H3><A NAME="Audit Logging Configuration">12.2.2. Audit Logging Configuration</A></H3>
<P>If the directory is running vi <TT>slapd.d</TT>, then the following LDIF could be used to add the overlay to the overlay list in <B>cn=config</B> and set what file the <TERM>LDIF</TERM> gets logged to (adjust to suit)</P>
<PRE>
       dn: olcOverlay=auditlog,olcDatabase={1}mdb,cn=config
       changetype: add
       objectClass: olcOverlayConfig
       objectClass: olcAuditLogConfig
       olcOverlay: auditlog
       olcAuditlogFile: /tmp/auditlog.ldif
</PRE>
<P>In this example for testing, we are logging changes to <TT>/tmp/auditlog.ldif</TT></P>
<P>A typical <TERM>LDIF</TERM> file created by <B>slapo-auditlog(5)</B> would look like:</P>
<PRE>
       # add 1196797576 dc=suretecsystems,dc=com cn=admin,dc=suretecsystems,dc=com
       dn: dc=suretecsystems,dc=com
       changetype: add
       objectClass: dcObject
       objectClass: organization
       dc: suretecsystems
       o: Suretec Systems Ltd.
       structuralObjectClass: organization
       entryUUID: 1606f8f8-f06e-1029-8289-f0cc9d81e81a
       creatorsName: cn=admin,dc=suretecsystems,dc=com
       modifiersName: cn=admin,dc=suretecsystems,dc=com
       createTimestamp: 20051123130912Z
       modifyTimestamp: 20051123130912Z
       entryCSN: 20051123130912.000000Z#000001#000#000000
       auditContext: cn=accesslog
       # end add 1196797576

       # add 1196797577 dc=suretecsystems,dc=com cn=admin,dc=suretecsystems,dc=com
       dn: ou=Groups,dc=suretecsystems,dc=com
       changetype: add
       objectClass: top
       objectClass: organizationalUnit
       ou: Groups
       structuralObjectClass: organizationalUnit
       entryUUID: 160aaa2a-f06e-1029-828a-f0cc9d81e81a
       creatorsName: cn=admin,dc=suretecsystems,dc=com
       modifiersName: cn=admin,dc=suretecsystems,dc=com
       createTimestamp: 20051123130912Z
       modifyTimestamp: 20051123130912Z
       entryCSN: 20051123130912.000000Z#000002#000#000000
       # end add 1196797577
</PRE>
<H3><A NAME="Further Information">12.2.3. Further Information</A></H3>
<P><EM>slapo-auditlog(5)</EM></P>
<H2><A NAME="Chaining">12.3. Chaining</A></H2>
<H3><A NAME="Overview">12.3.1. Overview</A></H3>
<P>The chain overlay provides basic chaining capability to the underlying database.</P>
<P>What is chaining? It indicates the capability of a DSA to follow referrals on behalf of the client, so that distributed systems are viewed as a single virtual DSA by clients that are otherwise unable to &quot;chase&quot; (i.e. follow) referrals by themselves.</P>
<P>The chain overlay is built on top of the ldap backend; it is compiled by default when <B>--enable-ldap</B>.</P>
<H3><A NAME="Chaining Configuration">12.3.2. Chaining Configuration</A></H3>
<P>In order to demonstrate how this overlay works, we shall discuss a typical scenario which might be one provider server and three Syncrepl replicas.</P>
<P>On each replica, add this near the top of the <EM>slapd.conf</EM>(5) file (global), before any database definitions:</P>
<PRE>
        overlay                    chain
        chain-uri                  &quot;ldap://ldapprovider.example.com&quot;
        chain-idassert-bind        bindmethod=&quot;simple&quot;
                                   binddn=&quot;cn=Manager,dc=example,dc=com&quot;
                                   credentials=&quot;&lt;secret&gt;&quot;
                                   mode=&quot;self&quot;
        chain-tls                  start
        chain-return-error         TRUE
</PRE>
<P>Add this below your <EM>syncrepl</EM> statement:</P>
<PRE>
        updateref                  &quot;ldap://ldapprovider.example.com/&quot;
</PRE>
<P>The <B>chain-tls</B> statement enables TLS from the replica to the ldap provider. The DITs are exactly the same between these machines, therefore whatever user bound to the replica will also exist on the provider. If that DN does not have update privileges on the provider, nothing will happen.</P>
<P>You will need to restart the replica after these <EM>slapd.conf</EM> changes. Then, if you are using <EM>loglevel stats</EM> (256), you can monitor an <EM>ldapmodify</EM> on the replica and the provider. (If you're using <EM>cn=config</EM> no restart is required.)</P>
<P>Now start an <EM>ldapmodify</EM> on the replica and watch the logs. You should expect something like:</P>
<PRE>
        Sep  6 09:27:25 replica1 slapd[29274]: conn=11 fd=31 ACCEPT from IP=143.199.102.216:45181 (IP=143.199.102.216:389)
        Sep  6 09:27:25 replica1 slapd[29274]: conn=11 op=0 STARTTLS
        Sep  6 09:27:25 replica1 slapd[29274]: conn=11 op=0 RESULT oid= err=0 text=
        Sep  6 09:27:25 replica1 slapd[29274]: conn=11 fd=31 TLS established tls_ssf=256 ssf=256
        Sep  6 09:27:28 replica1 slapd[29274]: conn=11 op=1 BIND dn=&quot;uid=user1,ou=people,dc=example,dc=com&quot; method=128
        Sep  6 09:27:28 replica1 slapd[29274]: conn=11 op=1 BIND dn=&quot;uid=user1,ou=People,dc=example,dc=com&quot; mech=SIMPLE ssf=0
        Sep  6 09:27:28 replica1 slapd[29274]: conn=11 op=1 RESULT tag=97 err=0 text=
        Sep  6 09:27:28 replica1 slapd[29274]: conn=11 op=2 MOD dn=&quot;uid=user1,ou=People,dc=example,dc=com&quot;
        Sep  6 09:27:28 replica1 slapd[29274]: conn=11 op=2 MOD attr=mail
        Sep  6 09:27:28 replica1 slapd[29274]: conn=11 op=2 RESULT tag=103 err=0 text=
        Sep  6 09:27:28 replica1 slapd[29274]: conn=11 op=3 UNBIND
        Sep  6 09:27:28 replica1 slapd[29274]: conn=11 fd=31 closed
        Sep  6 09:27:28 replica1 slapd[29274]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
        Sep  6 09:27:28 replica1 slapd[29274]: syncrepl_entry: be_search (0)
        Sep  6 09:27:28 replica1 slapd[29274]: syncrepl_entry: uid=user1,ou=People,dc=example,dc=com
        Sep  6 09:27:28 replica1 slapd[29274]: syncrepl_entry: be_modify (0)
</PRE>
<P>And on the provider you will see this:</P>
<PRE>
        Sep  6 09:23:57 ldapprovider slapd[2961]: conn=55902 op=3 PROXYAUTHZ dn=&quot;uid=user1,ou=people,dc=example,dc=com&quot;
        Sep  6 09:23:57 ldapprovider slapd[2961]: conn=55902 op=3 MOD dn=&quot;uid=user1,ou=People,dc=example,dc=com&quot;
        Sep  6 09:23:57 ldapprovider slapd[2961]: conn=55902 op=3 MOD attr=mail
        Sep  6 09:23:57 ldapprovider slapd[2961]: conn=55902 op=3 RESULT tag=103 err=0 text=
</PRE>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>You can clearly see the PROXYAUTHZ line on the provider, indicating the proper identity assertion for the update on the provider. Also note the replica immediately receiving the Syncrepl update from the provider.
<HR WIDTH="80%" ALIGN="Left"></P>
<H3><A NAME="Handling Chaining Errors">12.3.3. Handling Chaining Errors</A></H3>
<P>By default, if chaining fails, the original referral is returned to the client under the assumption that the client might want to try and follow the referral.</P>
<P>With the following directive however, if the chaining fails at the provider side, the actual error is returned to the client.</P>
<PRE>
        chain-return-error TRUE
</PRE>
<H3><A NAME="Read-Back of Chained Modifications">12.3.4. Read-Back of Chained Modifications</A></H3>
<P>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</B> control to ensure they are directed to the authoritative source for that piece of data.</P>
<P>This control usually causes a referral to the actual source of the data to be returned.  However, when the <EM>slapo-chain(5)</EM> overlay is used, it intercepts the referral being returned in response to the <B>dontusecopy</B> control, and tries to fetch the requested data.</P>
<H3><A NAME="Further Information">12.3.5. Further Information</A></H3>
<P><EM>slapo-chain(5)</EM></P>
<H2><A NAME="Constraints">12.4. Constraints</A></H2>
<H3><A NAME="Overview">12.4.1. Overview</A></H3>
<P>This overlay enforces a regular expression constraint on all values of specified attributes during an LDAP modify request that contains add or modify commands. It is used to enforce a more rigorous syntax when the underlying attribute syntax is too general.</P>
<H3><A NAME="Constraint Configuration">12.4.2. Constraint Configuration</A></H3>
<P>Configuration via <EM>slapd.conf</EM>(5) would look like:</P>
<PRE>
        overlay constraint
        constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$
        constraint_attribute title uri
        ldap:///dc=catalog,dc=example,dc=com?title?sub?(objectClass=titleCatalog)
</PRE>
<P>A specification like the above would reject any <EM>mail</EM> attribute which did not look like <EM>&lt;alphanumeric string&gt;@mydomain.com</EM>.</P>
<P>It would also reject any title attribute whose values were not listed in the title attribute of any <EM>titleCatalog</EM> entries in the given scope.</P>
<P>An example for use with <EM>cn=config</EM>:</P>
<PRE>
       dn: olcOverlay=constraint,olcDatabase={1}mdb,cn=config
       changetype: add
       objectClass: olcOverlayConfig
       objectClass: olcConstraintConfig
       olcOverlay: constraint
       olcConstraintAttribute: mail regex ^[[:alnum:]]+@mydomain.com$
       olcConstraintAttribute: title uri ldap:///dc=catalog,dc=example,dc=com?title?sub?(objectClass=titleCatalog)
</PRE>
<H3><A NAME="Further Information">12.4.3. Further Information</A></H3>
<P><EM>slapo-constraint(5)</EM></P>
<H2><A NAME="Dynamic Directory Services">12.5. Dynamic Directory Services</A></H2>
<H3><A NAME="Overview">12.5.1. Overview</A></H3>
<P>The <EM>dds</EM> overlay to <EM>slapd</EM>(8) implements dynamic objects as per <A HREF="https://www.rfc-editor.org/rfc/rfc2589.txt">RFC2589</A>. The name <EM>dds</EM> stands for Dynamic Directory Services. It allows to define dynamic objects, characterized by the <EM>dynamicObject</EM> objectClass.</P>
<P>Dynamic objects have a limited lifetime, determined by a time-to-live (TTL) that can be refreshed by means of a specific refresh extended operation. This operation allows to set the Client Refresh Period (CRP), namely the period between refreshes that is required to preserve the dynamic object from expiration. The expiration time is computed by adding the requested TTL to the current time. When dynamic objects reach the end of their lifetime without being further refreshed, they are automatically <EM>deleted</EM>. There is no guarantee of immediate deletion, so clients should not count on it.</P>
<H3><A NAME="Dynamic Directory Service Configuration">12.5.2. Dynamic Directory Service Configuration</A></H3>
<P>A usage of dynamic objects might be to implement dynamic meetings; in this case, all the participants to the meeting are allowed to refresh the meeting object, but only the creator can delete it (otherwise it will be deleted when the TTL expires).</P>
<P>If we add the overlay to an example database, specifying a Max TTL of 1 day, a min of 10 seconds, with a default TTL of 1 hour. We'll also specify an interval of 120 (less than 60s might be too small) seconds between expiration checks and a tolerance of 5 second (lifetime of a dynamic object will be <EM>entryTtl + tolerance</EM>).</P>
<PRE>
       overlay dds
       dds-max-ttl     1d
       dds-min-ttl     10s
       dds-default-ttl 1h
       dds-interval    120s
       dds-tolerance   5s
</PRE>
<P>and add an index:</P>
<PRE>
       entryExpireTimestamp
</PRE>
<P>Creating a meeting is as simple as adding the following:</P>
<PRE>
       dn: cn=OpenLDAP Documentation Meeting,ou=Meetings,dc=example,dc=com
       objectClass: groupOfNames
       objectClass: dynamicObject
       cn: OpenLDAP Documentation Meeting
       member: uid=ghenry,ou=People,dc=example,dc=com
       member: uid=hyc,ou=People,dc=example,dc=com
</PRE>
<H4><A NAME="Dynamic Directory Service ACLs">12.5.2.1. Dynamic Directory Service ACLs</A></H4>
<P>Allow users to start a meeting and to join it; restrict refresh to the <EM>member</EM>; restrict delete to the creator:</P>
<PRE>
       access to attrs=userPassword
          by self write
          by * read

       access to dn.base=&quot;ou=Meetings,dc=example,dc=com&quot;
                 attrs=children
            by users write

       access to dn.onelevel=&quot;ou=Meetings,dc=example,dc=com&quot;
                 attrs=entry
            by dnattr=creatorsName write
            by * read

       access to dn.onelevel=&quot;ou=Meetings,dc=example,dc=com&quot;
                 attrs=participant
            by dnattr=creatorsName write
            by users selfwrite
            by * read

       access to dn.onelevel=&quot;ou=Meetings,dc=example,dc=com&quot;
                 attrs=entryTtl
            by dnattr=member manage
            by * read
</PRE>
<P>In simple terms, the user who created the <EM>OpenLDAP Documentation Meeting</EM> can add new attendees, refresh the meeting using (basically complete control):</P>
<PRE>
       ldapexop -x -H ldap://ldaphost &quot;refresh&quot; &quot;cn=OpenLDAP Documentation Meeting,ou=Meetings,dc=example,dc=com&quot; &quot;120&quot; -D &quot;uid=ghenry,ou=People,dc=example,dc=com&quot; -W
</PRE>
<P>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.</P>
<H3><A NAME="Further Information">12.5.3. Further Information</A></H3>
<P><EM>slapo-dds(5)</EM></P>
<H2><A NAME="Dynamic Groups">12.6. Dynamic Groups</A></H2>
<H3><A NAME="Overview">12.6.1. Overview</A></H3>
<P>This overlay extends the Compare operation to detect members of a dynamic group. This overlay is now deprecated as all of its functions are available using the <A HREF="#Dynamic Lists">Dynamic Lists</A> overlay.</P>
<H3><A NAME="Dynamic Group Configuration">12.6.2. Dynamic Group Configuration</A></H3>
<H2><A NAME="Dynamic Lists">12.7. Dynamic Lists</A></H2>
<H3><A NAME="Overview">12.7.1. Overview</A></H3>
<P>This overlay allows expansion of dynamic groups and lists. Instead of having the group members or list attributes hard coded, this overlay allows us to define an LDAP search whose results will make up the group or list.</P>
<H3><A NAME="Dynamic List Configuration">12.7.2. Dynamic List Configuration</A></H3>
<P>This module can behave both as a dynamic list and dynamic group, depending on the configuration. The syntax is as follows:</P>
<PRE>
       overlay dynlist
       dynlist-attrset &lt;group-oc&gt; &lt;URL-ad&gt; [member-ad]
</PRE>
<P>The parameters to the <TT>dynlist-attrset</TT> directive have the following meaning:</P>
<UL>
<LI><TT>&lt;group-oc&gt;</TT>: specifies which object class triggers the subsequent LDAP search. Whenever an entry with this object class is retrieved, the search is performed.
<LI><TT>&lt;URL-ad&gt;</TT>: is the name of the attribute which holds the search URI. It has to be a subtype of <TT>labeledURI</TT>. The attributes and values present in the search result are added to the entry unless <TT>member-ad</TT> is used (see below).
<LI><TT>member-ad</TT>: if present, changes the overlay behavior into a dynamic group. Instead of inserting the results of the search in the entry, the distinguished name of the results are added as values of this attribute.</UL>
<P>Here is an example which will allow us to have an email alias which automatically expands to all user's emails according to our LDAP filter:</P>
<P>In <EM>slapd.conf</EM>(5):</P>
<PRE>
       overlay dynlist
       dynlist-attrset nisMailAlias labeledURI
</PRE>
<P>This means that whenever an entry which has the <TT>nisMailAlias</TT> object class is retrieved, the search specified in the <TT>labeledURI</TT> attribute is performed.</P>
<P>Let's say we have this entry in our directory:</P>
<PRE>
       cn=all,ou=aliases,dc=example,dc=com
       cn: all
       objectClass: nisMailAlias
       labeledURI: ldap:///ou=People,dc=example,dc=com?mail?one?(objectClass=inetOrgPerson)
</PRE>
<P>If this entry is retrieved, the search specified in <TT>labeledURI</TT> will be performed and the results will be added to the entry just as if they have always been there. In this case, the search filter selects all entries directly under <TT>ou=People</TT> that have the <TT>inetOrgPerson</TT> object class and retrieves the <TT>mail</TT> attribute, if it exists.</P>
<P>This is what gets added to the entry when we have two users under <TT>ou=People</TT> that match the filter:</P>
<P><CENTER><IMG SRC="allmail-en.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure X.Y: Dynamic List for all emails</P>
<P>The configuration for a dynamic group is similar. Let's see an example which would automatically populate an <TT>allusers</TT> group with all the user accounts in the directory.</P>
<P>In <TT>slapd.conf</TT>(5):</P>
<PRE>
       include /path/to/dyngroup.schema
       ...
       overlay dynlist
       dynlist-attrset groupOfURLs labeledURI member
</PRE>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>We must include the <TT>dyngroup.schema</TT> file that defines the <TT>groupOfURLs</TT> objectClass used in this example.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>Let's apply it to the following entry:</P>
<PRE>
       cn=allusers,ou=group,dc=example,dc=com
       cn: all
       objectClass: groupOfURLs
       labeledURI: ldap:///ou=people,dc=example,dc=com??one?(objectClass=inetOrgPerson)
</PRE>
<P>The behavior is similar to the dynamic list configuration we had before: whenever an entry with the <TT>groupOfURLs</TT> object class is retrieved, the search specified in the <TT>labeledURI</TT> attribute is performed. But this time, only the distinguished names of the results are added, and as values of the <TT>member</TT> attribute.</P>
<P>This is what we get:</P>
<P><CENTER><IMG SRC="allusersgroup-en.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure X.Y: Dynamic Group for all users</P>
<P>Note that a side effect of this scheme of dynamic groups is that the members need to be specified as full DNs. So, if you are planning in using this for <TT>posixGroup</TT>s, be sure to use RFC2307bis and some attribute which can hold distinguished names. The <TT>memberUid</TT> attribute used in the <TT>posixGroup</TT> object class can hold only names, not DNs, and is therefore not suitable for dynamic groups.</P>
<H3><A NAME="Further Information">12.7.3. Further Information</A></H3>
<P><EM>slapo-dynlist(5)</EM></P>
<H2><A NAME="Reverse Group Membership Maintenance">12.8. Reverse Group Membership Maintenance</A></H2>
<H3><A NAME="Overview">12.8.1. Overview</A></H3>
<P>In some scenarios, it may be desirable for a client to be able to determine which groups an entry is a member of, without performing an additional search. Examples of this are applications using the <TERM>DIT</TERM> for access control based on group authorization.</P>
<P>The <B>memberof</B> overlay updates an attribute (by default <B>memberOf</B>) whenever changes occur to the membership attribute (by default <B>member</B>) of entries of the objectclass (by default <B>groupOfNames</B>) configured to trigger updates.</P>
<P>Thus, it provides maintenance of the list of groups an entry is a member of, when usual maintenance of groups is done by modifying the members on the group entry.</P>
<H3><A NAME="Member Of Configuration">12.8.2. Member Of Configuration</A></H3>
<P>The typical use of this overlay requires just enabling the overlay for a specific database. For example, with the following minimal slapd.conf:</P>
<PRE>
        include /usr/share/openldap/schema/core.schema
        include /usr/share/openldap/schema/cosine.schema

        authz-regexp &quot;gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth&quot;
                &quot;cn=Manager,dc=example,dc=com&quot;
        database        mdb
        suffix          &quot;dc=example,dc=com&quot;
        rootdn          &quot;cn=Manager,dc=example,dc=com&quot;
        rootpw          secret
        directory       /var/lib/ldap2.5
        checkpoint 256 5
        index   objectClass   eq
        index   uid           eq,sub

        overlay memberof
</PRE>
<P>adding the following ldif:</P>
<PRE>
        cat memberof.ldif
        dn: dc=example,dc=com
        objectclass: domain
        dc: example

        dn: ou=Group,dc=example,dc=com
        objectclass: organizationalUnit
        ou: Group

        dn: ou=People,dc=example,dc=com
        objectclass: organizationalUnit
        ou: People

        dn: uid=test1,ou=People,dc=example,dc=com
        objectclass: account
        uid: test1

        dn: cn=testgroup,ou=Group,dc=example,dc=com
        objectclass: groupOfNames
        cn: testgroup
        member: uid=test1,ou=People,dc=example,dc=com
</PRE>
<P>Results in the following output from a search on the test1 user:</P>
<PRE>
 # ldapsearch -LL -Y EXTERNAL -H ldapi:/// &quot;(uid=test1)&quot; -b dc=example,dc=com memberOf
 SASL/EXTERNAL authentication started
 SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
 SASL SSF: 0
 version: 1

 dn: uid=test1,ou=People,dc=example,dc=com
 memberOf: cn=testgroup,ou=Group,dc=example,dc=com
</PRE>
<P>Note that the <B>memberOf</B> attribute is an operational attribute, so it must be requested explicitly.</P>
<H3><A NAME="Further Information">12.8.3. Further Information</A></H3>
<P><EM>slapo-memberof(5)</EM></P>
<H2><A NAME="The Proxy Cache Engine">12.9. The Proxy Cache Engine</A></H2>
<P><TERM>LDAP</TERM> servers typically hold one or more subtrees of a <TERM>DIT</TERM>. Replica (or shadow) servers hold shadow copies of entries held by one or more provider servers.  Changes are propagated from the provider server to replica servers using LDAP Sync replication.  An LDAP cache is a special type of replica which holds entries corresponding to search filters instead of subtrees.</P>
<H3><A NAME="Overview">12.9.1. Overview</A></H3>
<P>The proxy cache extension of slapd is designed to improve the responsiveness of the ldap and meta backends. It handles a search request (query) by first determining whether it is contained in any cached search filter. Contained requests are answered from the proxy cache's local database. Other requests are passed on to the underlying ldap or meta backend and processed as usual.</P>
<P>E.g. <TT>(shoesize&gt;=9)</TT> is contained in <TT>(shoesize&gt;=8)</TT> and <TT>(sn=Richardson)</TT> is contained in <TT>(sn=Richards*)</TT></P>
<P>Correct matching rules and syntaxes are used while comparing assertions for query containment. To simplify the query containment problem, a list of cacheable &quot;templates&quot; (defined below) is specified at configuration time. A query is cached or answered only if it belongs to one of these templates. The entries corresponding to cached queries are stored in the proxy cache local database while its associated meta information (filter, scope, base, attributes) is stored in main memory.</P>
<P>A template is a prototype for generating LDAP search requests. Templates are described by a prototype search filter and a list of attributes which are required in queries generated from the template. The representation for prototype filter is similar to <A HREF="https://www.rfc-editor.org/rfc/rfc4515.txt">RFC4515</A>, except that the assertion values are missing. Examples of prototype filters are: (sn=),(&amp;(sn=)(givenname=)) which are instantiated by search filters (sn=Doe) and (&amp;(sn=Doe)(givenname=John)) respectively.</P>
<P>The cache replacement policy removes the least recently used (LRU) query and entries belonging to only that query. Queries are allowed a maximum time to live (TTL) in the cache thus providing weak consistency. A background task periodically checks the cache for expired queries and removes them.</P>
<P>The Proxy Cache paper (<A HREF="http://www.openldap.org/pub/kapurva/proxycaching.pdf">http://www.openldap.org/pub/kapurva/proxycaching.pdf</A>) provides design and implementation details.</P>
<H3><A NAME="Proxy Cache Configuration">12.9.2. Proxy Cache Configuration</A></H3>
<P>The cache configuration specific directives described below must appear after a <TT>overlay pcache</TT> directive within a <TT>&quot;database meta&quot;</TT> or <TT>&quot;database ldap&quot;</TT> section of the server's <EM>slapd.conf</EM>(5) file.</P>
<H4><A NAME="Setting cache parameters">12.9.2.1. Setting cache parameters</A></H4>
<PRE>
 pcache &lt;DB&gt; &lt;maxentries&gt; &lt;nattrsets&gt; &lt;entrylimit&gt; &lt;period&gt;
</PRE>
<P>This directive enables proxy caching and sets general cache parameters.  The &lt;DB&gt; parameter specifies which underlying database is to be used to hold cached entries.  It should be set to <TT>mdb</TT>.  The &lt;maxentries&gt; parameter specifies the total number of entries which may be held in the cache.  The &lt;nattrsets&gt; parameter specifies the total number of attribute sets (as specified by the <TT>pcacheAttrset</TT> directive) that may be defined.  The &lt;entrylimit&gt; parameter specifies the maximum number of entries in a cacheable query.  The &lt;period&gt; specifies the consistency check period (in seconds).  In each period, queries with expired TTLs are removed.</P>
<H4><A NAME="Defining attribute sets">12.9.2.2. Defining attribute sets</A></H4>
<PRE>
 pcacheAttrset &lt;index&gt; &lt;attrs...&gt;
</PRE>
<P>Used to associate a set of attributes to an index. Each attribute set is associated with an index number from 0 to &lt;numattrsets&gt;-1. These indices are used by the pcacheTemplate directive to define cacheable templates.</P>
<H4><A NAME="Specifying cacheable templates">12.9.2.3. Specifying cacheable templates</A></H4>
<PRE>
 pcacheTemplate &lt;prototype_string&gt; &lt;attrset_index&gt; &lt;TTL&gt;
</PRE>
<P>Specifies a cacheable template and the &quot;time to live&quot; (in sec) &lt;TTL&gt; for queries belonging to the template. A template is described by its prototype filter string and set of required attributes identified by &lt;attrset_index&gt;.</P>
<H4><A NAME="Example for slapd.conf">12.9.2.4. Example for slapd.conf</A></H4>
<P>An example <EM>slapd.conf</EM>(5) database section for a caching server which proxies for the <TT>&quot;dc=example,dc=com&quot;</TT> subtree held at server <TT>ldap.example.com</TT>.</P>
<PRE>
        database        ldap
        suffix          &quot;dc=example,dc=com&quot;
        rootdn          &quot;dc=example,dc=com&quot;
        uri             ldap://ldap.example.com/
        overlay pcache
        pcache         mdb 100000 1 1000 100
        pcacheAttrset  0 mail postaladdress telephonenumber
        pcacheTemplate (sn=) 0 3600
        pcacheTemplate (&amp;(sn=)(givenName=)) 0 3600
        pcacheTemplate (&amp;(departmentNumber=)(secretary=*)) 0 3600

        cachesize 20
        directory ./testrun/db.2.a
        index       objectClass eq
        index       cn,sn,uid,mail  pres,eq,sub
</PRE>
<H4><A NAME="Example for slapd-config">12.9.2.5. Example for slapd-config</A></H4>
<P>The same example as a LDIF file for back-config for a caching server which proxies for the <TT>&quot;dc=example,dc=com&quot;</TT> subtree held at server <TT>ldap.example.com</TT>.</P>
<PRE>
   dn: olcDatabase={2}ldap,cn=config
   objectClass: olcDatabaseConfig
   objectClass: olcLDAPConfig
   olcDatabase: {2}ldap
   olcSuffix: dc=example,dc=com
   olcRootDN: dc=example,dc=com
   olcDbURI: &quot;ldap://ldap.example.com&quot;

   dn: olcOverlay={0}pcache,olcDatabase={2}ldap,cn=config
   objectClass: olcOverlayConfig
   objectClass: olcPcacheConfig
   olcOverlay: {0}pcache
   olcPcache: mdb 100000 1 1000 100
   olcPcacheAttrset: 0 mail postalAddress telephoneNumber
   olcPcacheTemplate: &quot;(sn=)&quot; 0 3600 0 0 0
   olcPcacheTemplate: &quot;(&amp;(sn=)(givenName=))&quot; 0 3600 0 0 0
   olcPcacheTemplate: &quot;(&amp;(departmentNumber=)(secretary=))&quot; 0 3600

   dn: olcDatabase={0}mdb,olcOverlay={0}pcache,olcDatabase={2}ldap,cn=config
   objectClass: olcMdbConfig
   objectClass: olcPcacheDatabase
   olcDatabase: {0}mdb
   olcDbDirectory: ./testrun/db.2.a
   olcDbCacheSize: 20
   olcDbIndex: objectClass eq
   olcDbIndex: cn,sn,uid,mail  pres,eq,sub
</PRE>
<H5><A NAME="Cacheable Queries">12.9.2.5.1. Cacheable Queries</A></H5>
<P>A LDAP search query is cacheable when its filter matches one of the templates as defined in the &quot;pcacheTemplate&quot; 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: <TT>mail postaladdress telephonenumber</TT> are cached for the following pcacheTemplates.</P>
<H5><A NAME="Examples:">12.9.2.5.2. Examples:</A></H5>
<PRE>
        Filter: (&amp;(sn=Richard*)(givenName=jack))
        Attrs: mail telephoneNumber
</PRE>
<P>is cacheable, because it matches the template <TT>(&amp;(sn=)(givenName=))</TT> and its attributes are contained in pcacheAttrset 0.</P>
<PRE>
        Filter: (&amp;(sn=Richard*)(telephoneNumber))
        Attrs: givenName
</PRE>
<P>is not cacheable, because the filter does not match the template, nor is the attribute givenName stored in the cache</P>
<PRE>
        Filter: (|(sn=Richard*)(givenName=jack))
        Attrs: mail telephoneNumber
</PRE>
<P>is not cacheable, because the filter does not match the template ( logical OR &quot;|&quot; condition instead of logical AND &quot;&amp;&quot; )</P>
<H3><A NAME="Further Information">12.9.3. Further Information</A></H3>
<P><EM>slapo-pcache(5)</EM></P>
<H2><A NAME="Password Policies">12.10. Password Policies</A></H2>
<H3><A NAME="Overview">12.10.1. Overview</A></H3>
<P>This overlay follows the specifications contained in the draft RFC titled draft-behera-ldap-password-policy-09. While the draft itself is expired, it has been implemented in several directory servers, including slapd. Nonetheless, it is important to note that it is a draft, meaning that it is subject to change and is a work-in-progress.</P>
<P>The key abilities of the password policy overlay are as follows:</P>
<UL>
<LI>Enforce a minimum length for new passwords
<LI>Make sure passwords are not changed too frequently
<LI>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
<LI>Maintain a history of passwords to prevent password re-use
<LI>Prevent password guessing by locking a password for a specified period of time after repeated authentication failures
<LI>Force a password to be changed at the next authentication
<LI>Set an administrative lock on an account
<LI>Support multiple password policies on a default or a per-object basis.
<LI>Perform arbitrary quality checks using an external loadable module. This is a non-standard extension of the draft RFC.</UL>
<H3><A NAME="Password Policy Configuration">12.10.2. Password Policy Configuration</A></H3>
<P>Instantiate the module in the database where it will be used, after adding the new ppolicy schema and loading the ppolicy module. The following example shows the ppolicy module being added to the database that handles the naming context &quot;dc=example,dc=com&quot;. In this example we are also specifying the DN of a policy object to use if none other is specified in a user's object.</P>
<PRE>
       database mdb
       suffix &quot;dc=example,dc=com&quot;
       [...additional database configuration directives go here...]

       overlay ppolicy
       ppolicy_default &quot;cn=default,ou=policies,dc=example,dc=com&quot;
</PRE>
<P>Now we need a container for the policy objects. In our example the password policy objects are going to be placed in a section of the tree called &quot;ou=policies,dc=example,dc=com&quot;:</P>
<PRE>
       dn: ou=policies,dc=example,dc=com
       objectClass: organizationalUnit
       objectClass: top
       ou: policies
</PRE>
<P>The default policy object that we are creating defines the following policies:</P>
<UL>
<LI>The user is allowed to change his own password. Note that the directory ACLs for this attribute can also affect this ability (pwdAllowUserChange: TRUE).
<LI>The name of the password attribute is &quot;userPassword&quot; (pwdAttribute: userPassword). Note that this is the only value that is accepted by OpenLDAP for this attribute.
<LI>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).
<LI>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.
<LI>When the password for a DN has expired, the server will allow five additional &quot;grace&quot; logins (pwdGraceAuthNLimit: 5).
<LI>The server will maintain a history of the last five passwords that were used for a DN (pwdInHistory: 5).
<LI>The server will lock the account after the maximum number of failed bind attempts has been exceeded (pwdLockout: TRUE).
<LI>When the server has locked an account, the server will keep it locked until an administrator unlocks it (pwdLockoutDuration: 0)
<LI>The server will reset its failed bind count after a period of 30 seconds.
<LI>Passwords will not expire (pwdMaxAge: 0).
<LI>Passwords can be changed as often as desired (pwdMinAge: 0).
<LI>Passwords must be at least 5 characters in length (pwdMinLength: 5).
<LI>The password does not need to be changed at the first bind or when the administrator has reset the password (pwdMustChange: FALSE)
<LI>The current password does not need to be included with password change requests (pwdSafeModify: FALSE)
<LI>The server will only allow five failed binds in a row for a particular DN (pwdMaxFailure: 5).</UL>
<P>The actual policy would be:</P>
<PRE>
       dn: cn=default,ou=policies,dc=example,dc=com
       cn: default
       objectClass: pwdPolicy
       objectClass: namedPolicy
       objectClass: top
       pwdAllowUserChange: TRUE
       pwdAttribute: userPassword
       pwdCheckQuality: 2
       pwdExpireWarning: 600
       pwdFailureCountInterval: 30
       pwdGraceAuthNLimit: 5
       pwdInHistory: 5
       pwdLockout: TRUE
       pwdLockoutDuration: 0
       pwdMaxAge: 0
       pwdMaxFailure: 5
       pwdMinAge: 0
       pwdMinLength: 5
       pwdMustChange: FALSE
       pwdSafeModify: FALSE
</PRE>
<P>You can create additional policy objects as needed.</P>
<P>The namedPolicy object class is present because the policy entry requires a structural object class.</P>
<P>There are two ways password policy can be applied to individual objects:</P>
<P>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.</P>
<P>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.</P>
<P>Please see <EM>slapo-ppolicy(5)</EM> for a complete explanation of its features.</P>
<P>A guiding philosophy for OpenLDAP and directory servers in general has been that they always hand back exactly what they were given, without modification. For example, if the cn attribute of an object was set to fOObaR, the server will return that exact string during a search. Values of attributes of a sensitive nature, such as userPassword, are often hashed to conceal their values. Since the userPassword values are used internally by the directory server to authenticate users, any hash algorithm that is applied to the value must be compatible with the directory server. Historically this problem has been solved by making the LDAP client application be able to hash the userPassword attribute value in a way that is compatible with the directory server, but this solution has the obvious drawback of requiring tight coupling between the LDAP client and server, and limits the choices of usable hashing algorithms to those that are accommodated by both. This is clearly a sub-optimal solution.</P>
<P>In 2001 RFC 3062 became a standard that specified an LDAP extended operation for cases like this. Extended operations are not bound by the return-what-you-are-given philosophy and so are free to do things to attribute values that the add and modify operations cannot. The change password extended operation accepts a plaintext password and hashes it based on a specification that is contained in the server. This allows the server to be in control of the hashing algorithm which, in turn, ensures that any hashes applied to userPassword attribute values will not prevent users from being authenticated.</P>
<P>The password policy module's ppolicy_hash_cleartext flag addresses this problem by intercepting LDAP modify operations that include the userPassword attribute and converting them to change password extended operations so they can be hashed according to the specification contained in slapd's configuration. When this flag is set, LDAP applications that modify the userPassword attribute can send the password in cleartext form to the server using a standard LDAP modify command and the server will hash the value according to the password-hash directive before storing it. It goes without saying that steps need to be taken to protect the cleartext password in transit, such as using SSL, TLS, or some other link encryption method.</P>
<P>The following example shows the ppolicy module configured to hash cleartext passwords:</P>
<PRE>
       database mdb
       suffix &quot;dc=example,dc=com&quot;
       [...additional database configuration directives go here...]

       overlay ppolicy
       ppolicy_default &quot;cn=default,ou=policies,dc=example,dc=com&quot;
       ppolicy_hash_cleartext
</PRE>
<H3><A NAME="Further Information">12.10.3. Further Information</A></H3>
<P><EM>slapo-ppolicy(5)</EM></P>
<H2><A NAME="Referential Integrity">12.11. Referential Integrity</A></H2>
<H3><A NAME="Overview">12.11.1. Overview</A></H3>
<P>This overlay can be used with a backend database such as slapd-mdb(5) to maintain the cohesiveness of a schema which utilizes reference attributes.</P>
<P>Whenever a <EM>modrdn</EM> or <EM>delete</EM> is performed, that is, when an entry's DN is renamed or an entry is removed, the server will search the directory for references to this DN (in selected attributes: see below) and update them accordingly. If it was a <EM>delete</EM> operation, the reference is deleted. If it was a <EM>modrdn</EM> operation, then the reference is updated with the new DN.</P>
<P>For example, a very common administration task is to maintain group membership lists, specially when users are removed from the directory. When an user account is deleted or renamed, all groups this user is a member of have to be updated. LDAP administrators usually have scripts for that. But we can use the <TT>refint</TT> overlay to automate this task. In this example, if the user is removed from the directory, the overlay will take care to remove the user from all the groups he/she was a member of. No more scripting for this.</P>
<H3><A NAME="Referential Integrity Configuration">12.11.2. Referential Integrity Configuration</A></H3>
<P>The configuration for this overlay is as follows:</P>
<PRE>
       overlay refint
       refint_attributes &lt;attribute [attribute ...]&gt;
       refint_nothing &lt;string&gt;
</PRE>
<UL>
<LI><TT>refint_attributes</TT>: this parameter specifies a space separated list of attributes which will have the referential integrity maintained. When an entry is removed or has its DN renamed, the server will do an internal search for any of the <TT>refint_attributes</TT> that point to the affected DN and update them accordingly. IMPORTANT: the attributes listed here must have the <TT>distinguishedName</TT> syntax, that is, hold DNs as values.
<LI><TT>refint_nothing</TT>: some times, while trying to maintain the referential integrity, the server has to remove the last attribute of its kind from an entry. This may be prohibited by the schema: for example, the <TT>groupOfNames</TT> object class requires at least one member. In these cases, the server will add the attribute value specified in <TT>refint_nothing</TT> to the entry.</UL>
<P>To illustrate this overlay, we will use the group membership scenario.</P>
<P>In <TT>slapd.conf</TT>:</P>
<PRE>
       overlay refint
       refint_attributes member
       refint_nothing &quot;cn=admin,dc=example,dc=com&quot;
</PRE>
<P>This configuration tells the overlay to maintain the referential integrity of the <TT>member</TT> attribute. This attribute is used in the <TT>groupOfNames</TT> object class which always needs a member, so we add the <TT>refint_nothing</TT> directive to fill in the group with a standard member should all the members vanish.</P>
<P>If we have the following group membership, the refint overlay will automatically remove <TT>john</TT> from the group if his entry is removed from the directory:</P>
<P><CENTER><IMG SRC="refint.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure X.Y: Maintaining referential integrity in groups</P>
<P>Notice that if we rename (<TT>modrdn</TT>) the <TT>john</TT> entry to, say, <TT>jsmith</TT>, the refint overlay will also rename the reference in the <TT>member</TT> attribute, so the group membership stays correct.</P>
<P>If we removed all users from the directory who are a member of this group, then the end result would be a single member in the group: <TT>cn=admin,dc=example,dc=com</TT>. This is the <TT>refint_nothing</TT> parameter kicking into action so that the schema is not violated.</P>
<P>The <EM>rootdn</EM> must be set for the database as refint runs as the <EM>rootdn</EM> to gain access to make its updates.  The <EM>rootpw</EM> does not need to be set.</P>
<H3><A NAME="Further Information">12.11.3. Further Information</A></H3>
<P><EM>slapo-refint(5)</EM></P>
<H2><A NAME="Return Code">12.12. Return Code</A></H2>
<H3><A NAME="Overview">12.12.1. Overview</A></H3>
<P>This overlay is useful to test the behavior of clients when server-generated erroneous and/or unusual responses occur, for example; error codes, referrals, excessive response times and so on.</P>
<P>This would be classed as a debugging tool whilst developing client software or additional Overlays.</P>
<P>For detailed information, please see the <EM>slapo-retcode(5)</EM> man page.</P>
<H3><A NAME="Return Code Configuration">12.12.2. Return Code Configuration</A></H3>
<P>The retcode overlay utilizes the &quot;return code&quot; schema described in the man page. This schema is specifically designed for use with this overlay and is not intended to be used otherwise.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>The necessary schema is loaded automatically by the overlay.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>An example configuration might be:</P>
<PRE>
       overlay         retcode
       retcode-parent  &quot;ou=RetCodes,dc=example,dc=com&quot;
       include         ./retcode.conf

       retcode-item    &quot;cn=Unsolicited&quot;                0x00 unsolicited=&quot;0&quot;
       retcode-item    &quot;cn=Notice of Disconnect&quot;       0x00 unsolicited=&quot;1.3.6.1.4.1.1466.20036&quot;
       retcode-item    &quot;cn=Pre-disconnect&quot;             0x34 flags=&quot;pre-disconnect&quot;
       retcode-item    &quot;cn=Post-disconnect&quot;            0x34 flags=&quot;post-disconnect&quot;
</PRE>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG><EM>retcode.conf</EM> can be found in the openldap source at: <TT>tests/data/retcode.conf</TT>
<HR WIDTH="80%" ALIGN="Left"></P>
<P>An excerpt of a <TT>retcode.conf</TT> would be something like:</P>
<PRE>
       retcode-item    &quot;cn=success&quot;                            0x00

       retcode-item    &quot;cn=success w/ delay&quot;                   0x00    sleeptime=2

       retcode-item    &quot;cn=operationsError&quot;                    0x01
       retcode-item    &quot;cn=protocolError&quot;                      0x02
       retcode-item    &quot;cn=timeLimitExceeded&quot;                  0x03    op=search
       retcode-item    &quot;cn=sizeLimitExceeded&quot;                  0x04    op=search
       retcode-item    &quot;cn=compareFalse&quot;                       0x05    op=compare
       retcode-item    &quot;cn=compareTrue&quot;                        0x06    op=compare
       retcode-item    &quot;cn=authMethodNotSupported&quot;             0x07
       retcode-item    &quot;cn=strongAuthNotSupported&quot;             0x07    text=&quot;same as authMethodNotSupported&quot;
       retcode-item    &quot;cn=strongAuthRequired&quot;                 0x08
       retcode-item    &quot;cn=strongerAuthRequired&quot;               0x08    text=&quot;same as strongAuthRequired&quot;
</PRE>
<P>Please see <TT>tests/data/retcode.conf</TT> for a complete <TT>retcode.conf</TT></P>
<H3><A NAME="Further Information">12.12.3. Further Information</A></H3>
<P><EM>slapo-retcode(5)</EM></P>
<H2><A NAME="Rewrite/Remap">12.13. Rewrite/Remap</A></H2>
<H3><A NAME="Overview">12.13.1. Overview</A></H3>
<P>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 <EM>slapd-ldap(5)</EM>, or locally, in conjunction with the relay backend described in <EM>slapd-relay(5)</EM>.</P>
<P>This overlay is extremely configurable and advanced, therefore recommended reading is the <EM>slapo-rwm(5)</EM> man page.</P>
<H3><A NAME="Rewrite/Remap Configuration">12.13.2. Rewrite/Remap Configuration</A></H3>
<H3><A NAME="Further Information">12.13.3. Further Information</A></H3>
<P><EM>slapo-rwm(5)</EM></P>
<H2><A NAME="Sync Provider">12.14. Sync Provider</A></H2>
<H3><A NAME="Overview">12.14.1. Overview</A></H3>
<P>This overlay implements the provider-side support for the LDAP Content Synchronization (<A HREF="https://www.rfc-editor.org/rfc/rfc4533.txt">RFC4533</A>) as well as syncrepl replication support, including persistent search functionality.</P>
<H3><A NAME="Sync Provider Configuration">12.14.2. Sync Provider Configuration</A></H3>
<P>There is very little configuration needed for this overlay, in fact for many situations merely loading the overlay will suffice.</P>
<P>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:</P>
<PRE>
       overlay syncprov
       syncprov-checkpoint 100 10
</PRE>
<P>For every 100 operations or 10 minutes, which ever is sooner, the contextCSN will be checkpointed.</P>
<P>The four configuration directives available are <B>syncprov-checkpoint</B>, <B>syncprov-sessionlog</B>, <B>syncprov-nopresent</B> and <B>syncprov-reloadhint</B> which are covered in the man page discussing various other scenarios where this overlay can be used.</P>
<H3><A NAME="Further Information">12.14.3. Further Information</A></H3>
<P>The <EM>slapo-syncprov(5)</EM> man page and the <A HREF="#Configuring the different replication types">Configuring the different replication types</A> section</P>
<H2><A NAME="Translucent Proxy">12.15. Translucent Proxy</A></H2>
<H3><A NAME="Overview">12.15.1. Overview</A></H3>
<P>This overlay can be used with a backend database such as <EM>slapd-mdb</EM>(5) to create a &quot;translucent proxy&quot;.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<H3><A NAME="Translucent Proxy Configuration">12.15.2. Translucent Proxy Configuration</A></H3>
<P>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 <EM>slapo-translucent(5)</EM></P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>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.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>First we configure the overlay in the normal manner:</P>
<PRE>
       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    mdb
       suffix      &quot;dc=suretecsystems,dc=com&quot;
       rootdn      &quot;cn=trans,dc=suretecsystems,dc=com&quot;
       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=&quot;cn=admin,dc=suretecsystems,dc=com&quot; credentials=&quot;blahblah&quot;
</PRE>
<P>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.</P>
<P>Now we take an example LDAP group:</P>
<PRE>
       # 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
</PRE>
<P>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:</P>
<PRE>
       [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
</PRE>
<P>Searching against the proxy gives:</P>
<PRE>
       [ghenry@suretec test_configs]$ ldapsearch -x -H ldap://127.0.0.1:9001 &quot;(cn=itsupport)&quot;
       # 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
</PRE>
<P>Here we can see that the 5 new attributes are added to the remote entry before being returned to the our client.</P>
<P>Because we have configured a local attribute to search against:</P>
<PRE>
       overlay     translucent
       translucent_local carLicense
</PRE>
<P>we can also search for that to return the completely fabricated entry:</P>
<PRE>
       ldapsearch -x -H ldap://127.0.0.1:9001 (carLicense=LIVID)
</PRE>
<P>This is an extremely useful feature because you can then extend a remote directory server locally and also search against the local entries.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>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
<HR WIDTH="80%" ALIGN="Left"></P>
<H3><A NAME="Further Information">12.15.3. Further Information</A></H3>
<P><EM>slapo-translucent(5)</EM></P>
<H2><A NAME="Attribute Uniqueness">12.16. Attribute Uniqueness</A></H2>
<H3><A NAME="Overview">12.16.1. Overview</A></H3>
<P>This overlay can be used with a backend database such as <EM>slapd-mdb(5)</EM> to enforce the uniqueness of some or all attributes within a subtree.</P>
<H3><A NAME="Attribute Uniqueness Configuration">12.16.2. Attribute Uniqueness Configuration</A></H3>
<P>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</B>.</P>
<P>For the following example, if uniqueness were enforced for the <B>mail</B> attribute, the subtree would be searched for any other records which also have a <B>mail</B> attribute containing the same value presented with an <B>add</B>, <B>modify</B> or <B>modrdn</B> operation which are unique within the configured scope. If any are found, the request is rejected.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>If no attributes are specified, for example <B>ldap:///??sub?</B>, then the URI applies to all non-operational attributes. However, the keyword <B>ignore</B> can be specified to exclude certain non-operational attributes.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>To search at the base dn of the current backend database ensuring uniqueness of the <B>mail</B> attribute, we simply add the following configuration:</P>
<PRE>
       overlay unique
       unique_uri ldap:///?mail?sub?
</PRE>
<P>For an existing entry of:</P>
<PRE>
       dn: cn=gavin,dc=suretecsystems,dc=com
       objectClass: top
       objectClass: inetorgperson
       cn: gavin
       sn: henry
       mail: ghenry@suretecsystems.com
</PRE>
<P>and we then try to add a new entry of:</P>
<PRE>
       dn: cn=robert,dc=suretecsystems,dc=com
       objectClass: top
       objectClass: inetorgperson
       cn: robert
       sn: jones
       mail: ghenry@suretecsystems.com
</PRE>
<P>would result in an error like so:</P>
<PRE>
       adding new entry &quot;cn=robert,dc=example,dc=com&quot;
       ldap_add: Constraint violation (19)
               additional info: some attributes not unique
</PRE>
<P>The overlay can have multiple URIs specified within a domain, allowing complex selections of objects and also have multiple <B>unique_uri</B> statements or <B>olcUniqueURI</B> attributes which will create independent domains.</P>
<P>For more information and details about the <B>strict</B> and <B>ignore</B> keywords, please see the <EM>slapo-unique(5)</EM> man page.</P>
<H3><A NAME="Further Information">12.16.3. Further Information</A></H3>
<P><EM>slapo-unique(5)</EM></P>
<H2><A NAME="Value Sorting">12.17. Value Sorting</A></H2>
<H3><A NAME="Overview">12.17.1. Overview</A></H3>
<P>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.</P>
<H3><A NAME="Value Sorting Configuration">12.17.2. Value Sorting Configuration</A></H3>
<P>Sorting can be specified in ascending or descending order, using either numeric or alphanumeric sort methods. Additionally, a &quot;weighted&quot; sort can be specified, which uses a numeric weight prepended to the attribute values.</P>
<P>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 {&lt;weight&gt;} 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.</P>
<P>Here are a few examples:</P>
<PRE>
       loglevel    sync stats

       database    mdb
       suffix      &quot;dc=suretecsystems,dc=com&quot;
       directory   /usr/local/var/openldap-data

       ......

       overlay valsort
       valsort-attr memberUid ou=Groups,dc=suretecsystems,dc=com alpha-ascend
</PRE>
<P>For example, ascend:</P>
<PRE>
       # 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
</PRE>
<P>For weighted, we change our data to:</P>
<PRE>
       # 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
</PRE>
<P>and change the config to:</P>
<PRE>
       overlay valsort
       valsort-attr memberUid ou=Groups,dc=suretecsystems,dc=com weighted
</PRE>
<P>Searching now results in:</P>
<PRE>
       # 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
</PRE>
<H3><A NAME="Further Information">12.17.3. Further Information</A></H3>
<P><EM>slapo-valsort(5)</EM></P>
<H2><A NAME="Overlay Stacking">12.18. Overlay Stacking</A></H2>
<H3><A NAME="Overview">12.18.1. Overview</A></H3>
<P>Overlays can be stacked, which means that more than one overlay can be instantiated for each database, or for the <TT>frontend</TT>. As a consequence, each overlays function is called, if defined, when overlay execution is invoked. Multiple overlays are executed in reverse order (as a stack) with respect to their definition in slapd.conf (5), or with respect to their ordering in the config database, as documented in slapd-config (5).</P>
<H3><A NAME="Example Scenarios">12.18.2. Example Scenarios</A></H3>
<H4><A NAME="Samba">12.18.2.1. Samba</A></H4>
<P></P>
<HR>
<H1><A NAME="Schema Specification">13. Schema Specification</A></H1>
<P>This chapter describes how to extend the user schema used by <EM>slapd</EM>(8).  The chapter assumes the reader is familiar with the <TERM>LDAP</TERM>/<TERM>X.500</TERM> information model.</P>
<P>The first section, <A HREF="#Distributed Schema Files">Distributed Schema Files</A> details optional schema definitions provided in the distribution and where to obtain other definitions. The second section, <A HREF="#Extending Schema">Extending Schema</A>, details how to define new schema items.</P>
<P>This chapter does not discuss how to extend system schema used by <EM>slapd</EM>(8) as this requires source code modification.  System schema includes all operational attribute types or any object class which allows or requires an operational attribute (directly or indirectly).</P>
<H2><A NAME="Distributed Schema Files">13.1. Distributed Schema Files</A></H2>
<P>OpenLDAP Software is distributed with a set of schema specifications for your use.  Each set is defined in a file suitable for inclusion (using the <TT>include</TT> directive) in your <EM>slapd.conf</EM>(5) file.  These schema files are normally installed in the <TT>/usr/local/etc/openldap/schema</TT> directory.</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 8.1: Provided Schema Specifications</CAPTION>
<TR CLASS="heading">
<TD ALIGN='Left'>
<STRONG>File</STRONG>
</TD>
<TD ALIGN='Right'>
<STRONG>Description</STRONG>
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>core.schema</TT>
</TD>
<TD ALIGN='Right'>
OpenLDAP <EM>core</EM> (required)
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>cosine.schema</TT>
</TD>
<TD ALIGN='Right'>
Cosine and Internet X.500 (useful)
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>inetorgperson.schema</TT>
</TD>
<TD ALIGN='Right'>
InetOrgPerson (useful)
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>misc.schema</TT>
</TD>
<TD ALIGN='Right'>
Assorted (experimental)
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>nis.schema</TT>
</TD>
<TD ALIGN='Right'>
Network Information Services (FYI)
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>openldap.schema</TT>
</TD>
<TD ALIGN='Right'>
OpenLDAP Project (experimental)
</TD>
</TR>
</TABLE>

<P>To use any of these schema files, you only need to include the desired file in the global definitions portion of your <EM>slapd.conf</EM>(5) file.  For example:</P>
<PRE>
        # include schema
        include /usr/local/etc/openldap/schema/core.schema
        include /usr/local/etc/openldap/schema/cosine.schema
        include /usr/local/etc/openldap/schema/inetorgperson.schema
</PRE>
<P>Additional files may be available.  Please consult the OpenLDAP <TERM>FAQ</TERM> (<A HREF="http://www.openldap.org/faq/">http://www.openldap.org/faq/</A>).</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>You should not modify any of the schema items defined in provided files.
<HR WIDTH="80%" ALIGN="Left"></P>
<H2><A NAME="Extending Schema">13.2. Extending Schema</A></H2>
<P>Schema used by <EM>slapd</EM>(8) may be extended to support additional syntaxes, matching rules, attribute types, and object classes.  This chapter details how to add user application attribute types and object classes using the syntaxes and matching rules already supported by slapd.  slapd can also be extended to support additional syntaxes, matching rules and system schema, but this requires some programming and hence is not discussed here.</P>
<P>There are five steps to defining new schema:</P>
<OL>
<LI>obtain Object Identifier
<LI>choose a name prefix
<LI>create local schema file
<LI>define custom attribute types (if necessary)
<LI>define custom object classes</OL>
<H3><A NAME="Object Identifiers">13.2.1. Object Identifiers</A></H3>
<P>Each schema element is identified by a globally unique <TERM>Object Identifier</TERM> (OID).  OIDs are also used to identify other objects.  They are commonly found in protocols described by <TERM>ASN.1</TERM>.  In particular, they are heavily used by the <TERM>Simple Network Management Protocol</TERM> (SNMP). As OIDs are hierarchical, your organization can obtain one OID and branch it as needed.  For example, if your organization were assigned OID <TT>1.1</TT>, you could branch the tree as follows:</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 8.2: Example OID hierarchy</CAPTION>
<TR CLASS="heading">
<TD ALIGN='Left'>
<STRONG>OID</STRONG>
</TD>
<TD ALIGN='Right'>
<STRONG>Assignment</STRONG>
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>1.1</TT>
</TD>
<TD ALIGN='Right'>
Organization's OID
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>1.1.1</TT>
</TD>
<TD ALIGN='Right'>
SNMP Elements
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>1.1.2</TT>
</TD>
<TD ALIGN='Right'>
LDAP Elements
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>1.1.2.1</TT>
</TD>
<TD ALIGN='Right'>
AttributeTypes
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>1.1.2.1.1</TT>
</TD>
<TD ALIGN='Right'>
x-my-Attribute
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>1.1.2.2</TT>
</TD>
<TD ALIGN='Right'>
ObjectClasses
</TD>
</TR>
<TR>
<TD ALIGN='Left'>
<TT>1.1.2.2.1</TT>
</TD>
<TD ALIGN='Right'>
x-my-ObjectClass
</TD>
</TR>
</TABLE>

<P>You are, of course, free to design a hierarchy suitable to your organizational needs under your organization's OID. No matter what hierarchy you choose, you should maintain a registry of assignments you make.  This can be a simple flat file or something more sophisticated such as the <EM>OpenLDAP OID Registry</EM> (<A HREF="http://www.openldap.org/faq/index.cgi?file=197">http://www.openldap.org/faq/index.cgi?file=197</A>).</P>
<P>For more information about Object Identifiers (and a listing service) see <A HREF="http://www.alvestrand.no/objectid/">http://www.alvestrand.no/objectid/</A>.</P>
<UL>
<EM>Under no circumstances should you hijack OID namespace!</EM></UL>
<P>To obtain a registered OID at <EM>no cost</EM>, apply for a OID under the <A HREF="https://www.iana.org/">Internet Assigned Numbers Authority</A> (ORG:IANA) maintained <EM>Private Enterprise</EM> arc. Any private enterprise (organization) may request a <TERM>Private Enterprise Number</TERM> (PEN) to be assigned under this arc. Just fill out the IANA form at <A HREF="http://pen.iana.org/pen/PenApplication.page">http://pen.iana.org/pen/PenApplication.page</A> and your official PEN will be sent to you usually within a few days. Your base OID will be something like <TT>1.3.6.1.4.1.X</TT> where <TT>X</TT> is an integer.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>PENs obtained using this form may be used for any purpose including identifying LDAP schema elements.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>Alternatively, OID name space may be available from a national authority (e.g., <A HREF="https://www.ansi.org/">ANSI</A>, <A HREF="https://www.bsigroup.com/en-GB/">BSI</A>).</P>
<H3><A NAME="Naming Elements">13.2.2. Naming Elements</A></H3>
<P>In addition to assigning a unique object identifier to each schema element, you should provide at least one textual name for each element.  Names should be registered with the <A HREF="https://www.iana.org/">IANA</A> or prefixed with &quot;x-&quot; to place in the &quot;private use&quot; name space.</P>
<P>The name should be both descriptive and not likely to clash with names of other schema elements.  In particular, any name you choose should not clash with present or future Standard Track names (this is assured if you registered names or use names beginning with &quot;x-&quot;).</P>
<P>It is noted that you can obtain your own registered name prefix so as to avoid having to register your names individually. See <A HREF="https://www.rfc-editor.org/rfc/rfc4520.txt">RFC4520</A> for details.</P>
<P>In the examples below, we have used a short prefix '<TT>x-my-</TT>'. Such a short prefix would only be suitable for a very large, global organization.  In general, we recommend something like '<TT>x-de-Firm-</TT>' (German company) or '<TT>x-com-Example</TT>' (elements associated with organization associated with <TT>example.com</TT>).</P>
<H3><A NAME="Local schema file">13.2.3. Local schema file</A></H3>
<P>The <TT>objectclass</TT> and <TT>attributeTypes</TT> configuration file directives can be used to define schema rules on entries in the directory.  It is customary to create a file to contain definitions of your custom schema items.  We recommend you create a file <TT>local.schema</TT> in <TT>/usr/local/etc/openldap/schema/local.schema</TT> and then include this file in your <EM>slapd.conf</EM>(5) file immediately after other schema <TT>include</TT> directives.</P>
<PRE>
        # include schema
        include /usr/local/etc/openldap/schema/core.schema
        include /usr/local/etc/openldap/schema/cosine.schema
        include /usr/local/etc/openldap/schema/inetorgperson.schema
        # include local schema
        include /usr/local/etc/openldap/schema/local.schema
</PRE>
<H3><A NAME="Attribute Type Specification">13.2.4. Attribute Type Specification</A></H3>
<P>The <EM>attributetype</EM> directive is used to define a new attribute type.  The directive uses the same Attribute Type Description (as defined in <A HREF="https://www.rfc-editor.org/rfc/rfc4512.txt">RFC4512</A>) used by the attributeTypes attribute found in the subschema subentry, e.g.:</P>
<PRE>
        attributetype &lt;<A HREF="https://www.rfc-editor.org/rfc/rfc4512.txt">RFC4512</A> Attribute Type Description&gt;
</PRE>
<P>where Attribute Type Description is defined by the following <TERM>ABNF</TERM>:</P>
<PRE>
      AttributeTypeDescription = &quot;(&quot; whsp
            numericoid whsp              ; AttributeType identifier
          [ &quot;NAME&quot; qdescrs ]             ; name used in AttributeType
          [ &quot;DESC&quot; qdstring ]            ; description
          [ &quot;OBSOLETE&quot; whsp ]
          [ &quot;SUP&quot; woid ]                 ; derived from this other
                                         ; AttributeType
          [ &quot;EQUALITY&quot; woid              ; Matching Rule name
          [ &quot;ORDERING&quot; woid              ; Matching Rule name
          [ &quot;SUBSTR&quot; woid ]              ; Matching Rule name
          [ &quot;SYNTAX&quot; whsp noidlen whsp ] ; Syntax OID
          [ &quot;SINGLE-VALUE&quot; whsp ]        ; default multi-valued
          [ &quot;COLLECTIVE&quot; whsp ]          ; default not collective
          [ &quot;NO-USER-MODIFICATION&quot; whsp ]; default user modifiable
          [ &quot;USAGE&quot; whsp AttributeUsage ]; default userApplications
          whsp &quot;)&quot;

      AttributeUsage =
          &quot;userApplications&quot;     /
          &quot;directoryOperation&quot;   /
          &quot;distributedOperation&quot; / ; DSA-shared
          &quot;dSAOperation&quot;          ; DSA-specific, value depends on server

</PRE>
<P>where whsp is a space ('<TT> </TT>'), numericoid is a globally unique OID in dotted-decimal form (e.g. <TT>1.1.0</TT>), qdescrs is one or more names, woid is either the name or OID optionally followed by a length specifier (e.g <TT>{10</TT>}).</P>
<P>For example, the attribute types <TT>name</TT> and <TT>cn</TT> are defined in <TT>core.schema</TT> as:</P>
<PRE>
        attributeType ( 2.5.4.41 NAME 'name'
                DESC 'name(s) associated with the object'
                EQUALITY caseIgnoreMatch
                SUBSTR caseIgnoreSubstringsMatch
                SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
        attributeType ( 2.5.4.3 NAME ( 'cn' 'commonName' )
                DESC 'common name(s) associated with the object'
                SUP name )
</PRE>
<P>Notice that each defines the attribute's OID, provides a short name, and a brief description.  Each name is an alias for the OID. <EM>slapd</EM>(8) returns the first listed name when returning results.</P>
<P>The first attribute, <TT>name</TT>, holds values of <TT>directoryString</TT> (<TERM>UTF-8</TERM> encoded Unicode) syntax.  The syntax is specified by OID (1.3.6.1.4.1.1466.115.121.1.15 identifies the directoryString syntax).  A length recommendation of 32768 is specified.  Servers should support values of this length, but may support longer values. The field does NOT specify a size constraint, so is ignored on servers (such as slapd) which don't impose such size limits.  In addition, the equality and substring matching uses case ignore rules.  Below are tables listing commonly used syntax and matching rules (<EM>slapd</EM>(8) supports these and many more).</P>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 8.3: Commonly Used Syntaxes</CAPTION>
<TR CLASS="heading">
<TD>
<STRONG>Name</STRONG>
</TD>
<TD>
<STRONG>OID</STRONG>
</TD>
<TD>
<STRONG>Description</STRONG>
</TD>
</TR>
<TR>
<TD>
<TT>boolean</TT>
</TD>
<TD>
<TT>1.3.6.1.4.1.1466.115.121.1.7</TT>
</TD>
<TD>
boolean value
</TD>
</TR>
<TR>
<TD>
<TT>directoryString</TT>
</TD>
<TD>
<TT>1.3.6.1.4.1.1466.115.121.1.15</TT>
</TD>
<TD>
Unicode (UTF-8) string
</TD>
</TR>
<TR>
<TD>
<TT>distinguishedName</TT>
</TD>
<TD>
<TT>1.3.6.1.4.1.1466.115.121.1.12</TT>
</TD>
<TD>
LDAP <TERM>DN</TERM>
</TD>
</TR>
<TR>
<TD>
<TT>integer</TT>
</TD>
<TD>
<TT>1.3.6.1.4.1.1466.115.121.1.27</TT>
</TD>
<TD>
integer
</TD>
</TR>
<TR>
<TD>
<TT>numericString</TT>
</TD>
<TD>
<TT>1.3.6.1.4.1.1466.115.121.1.36</TT>
</TD>
<TD>
numeric string
</TD>
</TR>
<TR>
<TD>
<TT>OID</TT>
</TD>
<TD>
<TT>1.3.6.1.4.1.1466.115.121.1.38</TT>
</TD>
<TD>
object identifier
</TD>
</TR>
<TR>
<TD>
<TT>octetString</TT>
</TD>
<TD>
<TT>1.3.6.1.4.1.1466.115.121.1.40</TT>
</TD>
<TD>
arbitrary octets
</TD>
</TR>
</TABLE>

<PRE>

</PRE>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 8.4: Commonly Used Matching Rules</CAPTION>
<TR CLASS="heading">
<TD>
<STRONG>Name</STRONG>
</TD>
<TD>
<STRONG>Type</STRONG>
</TD>
<TD>
<STRONG>Description</STRONG>
</TD>
</TR>
<TR>
<TD>
<TT>booleanMatch</TT>
</TD>
<TD>
equality
</TD>
<TD>
boolean
</TD>
</TR>
<TR>
<TD>
<TT>caseIgnoreMatch</TT>
</TD>
<TD>
equality
</TD>
<TD>
case insensitive, space insensitive
</TD>
</TR>
<TR>
<TD>
<TT>caseIgnoreOrderingMatch</TT>
</TD>
<TD>
ordering
</TD>
<TD>
case insensitive, space insensitive
</TD>
</TR>
<TR>
<TD>
<TT>caseIgnoreSubstringsMatch</TT>
</TD>
<TD>
substrings
</TD>
<TD>
case insensitive, space insensitive
</TD>
</TR>
<TR>
<TD>
<TT>caseExactMatch</TT>
</TD>
<TD>
equality
</TD>
<TD>
case sensitive, space insensitive
</TD>
</TR>
<TR>
<TD>
<TT>caseExactOrderingMatch</TT>
</TD>
<TD>
ordering
</TD>
<TD>
case sensitive, space insensitive
</TD>
</TR>
<TR>
<TD>
<TT>caseExactSubstringsMatch</TT>
</TD>
<TD>
substrings
</TD>
<TD>
case sensitive, space insensitive
</TD>
</TR>
<TR>
<TD>
<TT>distinguishedNameMatch</TT>
</TD>
<TD>
equality
</TD>
<TD>
distinguished name
</TD>
</TR>
<TR>
<TD>
<TT>integerMatch</TT>
</TD>
<TD>
equality
</TD>
<TD>
integer
</TD>
</TR>
<TR>
<TD>
<TT>integerOrderingMatch</TT>
</TD>
<TD>
ordering
</TD>
<TD>
integer
</TD>
</TR>
<TR>
<TD>
<TT>numericStringMatch</TT>
</TD>
<TD>
equality
</TD>
<TD>
numerical
</TD>
</TR>
<TR>
<TD>
<TT>numericStringOrderingMatch</TT>
</TD>
<TD>
ordering
</TD>
<TD>
numerical
</TD>
</TR>
<TR>
<TD>
<TT>numericStringSubstringsMatch</TT>
</TD>
<TD>
substrings
</TD>
<TD>
numerical
</TD>
</TR>
<TR>
<TD>
<TT>octetStringMatch</TT>
</TD>
<TD>
equality
</TD>
<TD>
octet string
</TD>
</TR>
<TR>
<TD>
<TT>octetStringOrderingMatch</TT>
</TD>
<TD>
ordering
</TD>
<TD>
octet string
</TD>
</TR>
<TR>
<TD>
<TT>octetStringSubstringsMatch      ordering</TT>
</TD>
<TD>
octet st
</TD>
<TD>
ring
</TD>
</TR>
<TR>
<TD>
<TT>objectIdentiferMatch</TT>
</TD>
<TD>
equality
</TD>
<TD>
object identifier
</TD>
</TR>
</TABLE>

<P>The second attribute, <TT>cn</TT>, is a subtype of <TT>name</TT> hence it inherits the syntax, matching rules, and usage of <TT>name</TT>. <TT>commonName</TT> is an alternative name.</P>
<P>Neither attribute is restricted to a single value.  Both are meant for usage by user applications.  Neither is obsolete nor collective.</P>
<P>The following subsections provide a couple of examples.</P>
<H4><A NAME="x-my-UniqueName">13.2.4.1. x-my-UniqueName</A></H4>
<P>Many organizations maintain a single unique name for each user. Though one could use <TT>displayName</TT> (<A HREF="https://www.rfc-editor.org/rfc/rfc2798.txt">RFC2798</A>), this attribute is really meant to be controlled by the user, not the organization.  We could just copy the definition of <TT>displayName</TT> from <TT>inetorgperson.schema</TT> and replace the OID, name, and description, e.g:</P>
<PRE>
        attributetype ( 1.1.2.1.1 NAME 'x-my-UniqueName'
                DESC 'unique name with my organization'
                EQUALITY caseIgnoreMatch
                SUBSTR caseIgnoreSubstringsMatch
                SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
                SINGLE-VALUE )
</PRE>
<P>However, if we want this name to be used in <TT>name</TT> assertions, e.g. <TT>(name=*Jane*)</TT>, the attribute could alternatively be defined as a subtype of <TT>name</TT>, e.g.:</P>
<PRE>
        attributetype ( 1.1.2.1.1 NAME 'x-my-UniqueName'
                DESC 'unique name with my organization'
                SUP name )
</PRE>
<H4><A NAME="x-my-Photo">13.2.4.2. x-my-Photo</A></H4>
<P>Many organizations maintain a photo of each each user.  A <TT>x-my-Photo</TT> attribute type could be defined to hold a photo. Of course, one could use just use <TT>jpegPhoto</TT> (<A HREF="https://www.rfc-editor.org/rfc/rfc2798.txt">RFC2798</A>) (or a subtype) to hold the photo.  However, you can only do this if the photo is in <EM>JPEG File Interchange Format</EM>. Alternatively, an attribute type which uses the <EM>Octet String</EM> syntax can be defined, e.g.:</P>
<PRE>
        attributetype ( 1.1.2.1.2 NAME 'x-my-Photo'
                DESC 'a photo (application defined format)'
                SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
                SINGLE-VALUE )
</PRE>
<P>In this case, the syntax doesn't specify the format of the photo. It's assumed (maybe incorrectly) that all applications accessing this attribute agree on the handling of values.</P>
<P>If you wanted to support multiple photo formats, you could define a separate attribute type for each format, prefix the photo with some typing information, or describe the value using <TERM>ASN.1</TERM> and use the <TT>;binary</TT> transfer option.</P>
<P>Another alternative is for the attribute to hold a <TERM>URI</TERM> pointing to the photo.  You can model such an attribute after <TT>labeledURI</TT> (<A HREF="https://www.rfc-editor.org/rfc/rfc2079.txt">RFC2079</A>) or simply create a subtype, e.g.:</P>
<PRE>
        attributetype ( 1.1.2.1.3 NAME 'x-my-PhotoURI'
                DESC 'URI and optional label referring to a photo'
                SUP labeledURI )
</PRE>
<H3><A NAME="Object Class Specification">13.2.5. Object Class Specification</A></H3>
<P>The <EM>objectclasses</EM> directive is used to define a new object class.  The directive uses the same Object Class Description (as defined in <A HREF="https://www.rfc-editor.org/rfc/rfc4512.txt">RFC4512</A>) used by the objectClasses attribute found in the subschema subentry, e.g.:</P>
<PRE>
        objectclass &lt;<A HREF="https://www.rfc-editor.org/rfc/rfc4512.txt">RFC4512</A> Object Class Description&gt;
</PRE>
<P>where Object Class Description is defined by the following <TERM>ABNF</TERM>:</P>
<PRE>
        ObjectClassDescription = &quot;(&quot; whsp
                numericoid whsp      ; ObjectClass identifier
                [ &quot;NAME&quot; qdescrs ]
                [ &quot;DESC&quot; qdstring ]
                [ &quot;OBSOLETE&quot; whsp ]
                [ &quot;SUP&quot; oids ]       ; Superior ObjectClasses
                [ ( &quot;ABSTRACT&quot; / &quot;STRUCTURAL&quot; / &quot;AUXILIARY&quot; ) whsp ]
                        ; default structural
                [ &quot;MUST&quot; oids ]      ; AttributeTypes
                [ &quot;MAY&quot; oids ]       ; AttributeTypes
                whsp &quot;)&quot;
</PRE>
<P>where whsp is a space ('<TT> </TT>'), numericoid is a globally unique OID in dotted-decimal form (e.g. <TT>1.1.0</TT>), qdescrs is one or more names, and oids is one or more names and/or OIDs.</P>
<H4><A NAME="x-my-PhotoObject">13.2.5.1. x-my-PhotoObject</A></H4>
<P>To define an <EM>auxiliary</EM> object class which allows x-my-Photo to be added to any existing entry.</P>
<PRE>
        objectclass ( 1.1.2.2.1 NAME 'x-my-PhotoObject'
                DESC 'mixin x-my-Photo'
                AUXILIARY
                MAY x-my-Photo )
</PRE>
<H4><A NAME="x-my-Person">13.2.5.2. x-my-Person</A></H4>
<P>If your organization would like have a private <EM>structural</EM> object class to instantiate users, you can subclass one of the existing person classes, such as <TT>inetOrgPerson</TT> (<A HREF="https://www.rfc-editor.org/rfc/rfc2798.txt">RFC2798</A>), and add any additional attributes which you desire.</P>
<PRE>
        objectclass ( 1.1.2.2.2 NAME 'x-my-Person'
                DESC 'my person'
                SUP inetOrgPerson
                MUST ( x-my-UniqueName $ givenName )
                MAY x-my-Photo )
</PRE>
<P>The object class inherits the required/allowed attribute types of <TT>inetOrgPerson</TT> but requires <TT>x-my-UniqueName</TT> and <TT>givenName</TT> and allows <TT>x-my-Photo</TT>.</P>
<H3><A NAME="OID Macros">13.2.6. OID Macros</A></H3>
<P>To ease the management and use of OIDs, <EM>slapd</EM>(8) supports <EM>Object Identifier</EM> macros.  The <TT>objectIdentifier</TT> directive is used to equate a macro (name) with a OID.  The OID may possibly be derived from a previously defined OID macro.   The <EM>slapd.conf</EM>(5) syntax is:</P>
<PRE>
        objectIdentifier &lt;name&gt; { &lt;oid&gt; | &lt;name&gt;[:&lt;suffix&gt;] }
</PRE>
<P>The following demonstrates definition of a set of OID macros and their use in defining schema elements:</P>
<PRE>
        objectIdentifier myOID  1.1
        objectIdentifier mySNMP myOID:1
        objectIdentifier myLDAP myOID:2
        objectIdentifier myAttributeType        myLDAP:1
        objectIdentifier myObjectClass  myLDAP:2
        attributetype ( myAttributeType:3 NAME 'x-my-PhotoURI'
                DESC 'URI and optional label referring to a photo'
                SUP labeledURI )
        objectclass ( myObjectClass:1 NAME 'x-my-PhotoObject'
                DESC 'mixin x-my-Photo'
                AUXILIARY
                MAY x-my-Photo )
</PRE>
<P></P>
<HR>
<H1><A NAME="Security Considerations">14. Security Considerations</A></H1>
<P>OpenLDAP Software is designed to run in a wide variety of computing environments from tightly-controlled closed networks to the global Internet.  Hence, OpenLDAP Software supports many different security mechanisms.  This chapter describes these mechanisms and discusses security considerations for using OpenLDAP Software.</P>
<H2><A NAME="Network Security">14.1. Network Security</A></H2>
<H3><A NAME="Selective Listening">14.1.1. Selective Listening</A></H3>
<P>By default, <EM>slapd</EM>(8) will listen on both the IPv4 and IPv6 &quot;any&quot; addresses.  It is often desirable to have <EM>slapd</EM> listen on select address/port pairs.  For example, listening only on the IPv4 address <TT>127.0.0.1</TT> will disallow remote access to the directory server. E.g.:</P>
<PRE>
        slapd -h ldap://127.0.0.1
</PRE>
<P>While the server can be configured to listen on a particular interface address, this doesn't necessarily restrict access to the server to only those networks accessible via that interface.   To selective restrict remote access, it is recommend that an <A HREF="#IP Firewall">IP Firewall</A> be used to restrict access.</P>
<P>See <A HREF="#Command-line Options">Command-line Options</A> and <EM>slapd</EM>(8) for more information.</P>
<H3><A NAME="IP Firewall">14.1.2. IP Firewall</A></H3>
<P><TERM>IP</TERM> firewall capabilities of the server system can be used to restrict access based upon the client's IP address and/or network interface used to communicate with the client.</P>
<P>Generally, <EM>slapd</EM>(8) listens on port 389/tcp for <A HREF="ldap://">ldap://</A> sessions and port 636/tcp for <A HREF="ldaps://">ldaps://</A>) sessions.  <EM>slapd</EM>(8) may be configured to listen on other ports.</P>
<P>As specifics of how to configure IP firewall are dependent on the particular kind of IP firewall used, no examples are provided here. See the document associated with your IP firewall.</P>
<H3><A NAME="TCP Wrappers">14.1.3. TCP Wrappers</A></H3>
<P><EM>slapd</EM>(8) supports <TERM>TCP</TERM> Wrappers.  TCP Wrappers provide a rule-based access control system for controlling TCP/IP access to the server.  For example, the <EM>host_options</EM>(5) rule:</P>
<PRE>
        slapd: 10.0.0.0/255.0.0.0 127.0.0.1 : ALLOW
        slapd: ALL : DENY
</PRE>
<P>allows only incoming connections from the private network <TT>10.0.0.0</TT> and localhost (<TT>127.0.0.1</TT>) to access the directory service.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>IP addresses are used as <EM>slapd</EM>(8) is not normally configured to perform reverse lookups.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>It is noted that TCP wrappers require the connection to be accepted. As significant processing is required just to deny a connection, it is generally advised that IP firewall protection be used instead of TCP wrappers.</P>
<P>See <EM>hosts_access</EM>(5) for more information on TCP wrapper rules.</P>
<H2><A NAME="Data Integrity and Confidentiality Protection">14.2. Data Integrity and Confidentiality Protection</A></H2>
<P><TERM>Transport Layer Security</TERM> (TLS) can be used to provide data integrity and confidentiality protection.  OpenLDAP supports negotiation of <TERM>TLS</TERM> (<TERM>SSL</TERM>) via both StartTLS and <A HREF="ldaps://">ldaps://</A>. See the <A HREF="#Using TLS">Using TLS</A> chapter for more information.  StartTLS is the standard track mechanism.</P>
<P>A number of <TERM>Simple Authentication and Security Layer</TERM> (SASL) mechanisms, such as <TERM>DIGEST-MD5</TERM> and <TERM>GSSAPI</TERM>, also provide data integrity and confidentiality protection.  See the <A HREF="#Using SASL">Using SASL</A> chapter for more information.</P>
<H3><A NAME="Security Strength Factors">14.2.1. Security Strength Factors</A></H3>
<P>The server uses <TERM>Security Strength Factor</TERM>s (SSF) to indicate the relative strength of protection.  A SSF of zero (0) indicates no protections are in place.  A SSF of one (1) indicates integrity protection are in place.  A SSF greater than one (&gt;1) roughly correlates to the effective encryption key length.  For example, <TERM>DES</TERM> is 56, <TERM>3DES</TERM> is 112, and <TERM>AES</TERM> 128, 192, or 256.</P>
<P>A number of administrative controls rely on SSFs associated with TLS and SASL protection in place on an LDAP session.</P>
<P><TT>security</TT> controls disallow operations when appropriate protections are not in place.  For example:</P>
<PRE>
        security ssf=1 update_ssf=112
</PRE>
<P>requires integrity protection for all operations and encryption protection, 3DES equivalent, for update operations (e.g. add, delete, modify, etc.).  See <EM>slapd.conf</EM>(5) for details.</P>
<P>For fine-grained control, SSFs may be used in access controls. See the <A HREF="#Access Control">Access Control</A> section for more information.</P>
<H2><A NAME="Authentication Methods">14.3. Authentication Methods</A></H2>
<H3><A NAME="&quot;simple&quot; method">14.3.1. &quot;simple&quot; method</A></H3>
<P>The LDAP &quot;simple&quot; method has three modes of operation:</P>
<UL>
<LI>anonymous,
<LI>unauthenticated, and
<LI>user/password authenticated.</UL>
<P>Anonymous access is requested by providing no name and no password to the &quot;simple&quot; bind operation.  Unauthenticated access is requested by providing a name but no password.  Authenticated access is requested by providing a valid name and password.</P>
<P>An anonymous bind results in an <EM>anonymous</EM> authorization association.  Anonymous bind mechanism is enabled by default, but can be disabled by specifying &quot;<TT>disallow bind_anon</TT>&quot; in <EM>slapd.conf</EM>(5).</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>Disabling the anonymous bind mechanism does not prevent anonymous access to the directory. To require authentication to access the directory, one should instead specify &quot;<TT>require authc</TT>&quot;.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>An unauthenticated bind also results in an <EM>anonymous</EM> authorization association.  Unauthenticated bind mechanism is disabled by default, but can be enabled by specifying &quot;<TT>allow bind_anon_cred</TT>&quot; in <EM>slapd.conf</EM>(5).  As a number of LDAP applications mistakenly generate unauthenticated bind request when authenticated access was intended (that is, they do not ensure a password was provided), this mechanism should generally remain disabled.</P>
<P>A successful user/password authenticated bind results in a user authorization identity, the provided name, being associated with the session.  User/password authenticated bind is enabled by default. However, as this mechanism itself offers no eavesdropping protection (e.g., the password is set in the clear), it is recommended that it be used only in tightly controlled systems or when the LDAP session is protected by other means (e.g., TLS, <TERM>IPsec</TERM>). Where the administrator relies on TLS to protect the password, it is recommended that unprotected authentication be disabled.  This is done using the <TT>security</TT> directive's <TT>simple_bind</TT> option, which provides fine grain control over the level of confidential protection to require for <EM>simple</EM> user/password authentication. E.g., using <TT>security simple_bind=56</TT> would require <EM>simple</EM> binds to use encryption of DES equivalent or better.</P>
<P>The user/password authenticated bind mechanism can be completely disabled by setting &quot;<TT>disallow bind_simple</TT>&quot;.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>An unsuccessful bind always results in the session having an <EM>anonymous</EM> authorization association.
<HR WIDTH="80%" ALIGN="Left"></P>
<H3><A NAME="SASL method">14.3.2. SASL method</A></H3>
<P>The LDAP <TERM>SASL</TERM> method allows the use of any SASL authentication mechanism. The <A HREF="#Using SASL">Using SASL</A> section discusses the use of SASL.</P>
<H2><A NAME="Password Storage">14.4. Password Storage</A></H2>
<P>LDAP passwords are normally stored in the <EM>userPassword</EM> attribute. <A HREF="https://www.rfc-editor.org/rfc/rfc4519.txt">RFC4519</A> specifies that passwords are not stored in encrypted (or hashed) form.  This allows a wide range of password-based authentication mechanisms, such as <TT>DIGEST-MD5</TT> to be used. This is also the most interoperable storage scheme.</P>
<P>However, it may be desirable to store a hash of password instead. <EM>slapd</EM>(8) supports a variety of storage schemes for the administrator to choose from.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>Values of password attributes, regardless of storage scheme used, should be protected as if they were clear text.  Hashed passwords are subject to <EM>dictionary attacks</EM> and <EM>brute-force attacks</EM>.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>The <EM>userPassword</EM> attribute is allowed to have more than one value, and it is possible for each value to be stored in a different form. During authentication, <EM>slapd</EM> will iterate through the values until it finds one that matches the offered password or until it runs out of values to inspect.  The storage scheme is stored as a prefix on the value, so a hashed password using the Salted SHA1 (<TT>SSHA</TT>) scheme looks like:</P>
<PRE>
 userPassword: {SSHA}DkMTwBl+a/3DQTxCYEApdUtNXGgdUac3
</PRE>
<P>The advantage of hashed passwords is that an attacker which discovers the hash does not have direct access to the actual password. Unfortunately, as dictionary and brute force attacks are generally quite easy for attackers to successfully mount, this advantage is marginal at best (this is why all modern Unix systems use shadow password files).</P>
<P>The disadvantages of hashed storage is that they are non-standard, may cause interoperability problem, and generally preclude the use of stronger than Simple (or SASL/PLAIN) password-based authentication mechanisms such as <TT>DIGEST-MD5</TT>.</P>
<H3><A NAME="SSHA password storage scheme">14.4.1. SSHA password storage scheme</A></H3>
<P>This is the salted version of the SHA scheme. It is believed to be the most secure password storage scheme supported by <EM>slapd</EM>.</P>
<P>These values represent the same password:</P>
<PRE>
 userPassword: {SSHA}DkMTwBl+a/3DQTxCYEApdUtNXGgdUac3
 userPassword: {SSHA}d0Q0626PSH9VUld7yWpR0k6BlpQmtczb
</PRE>
<H3><A NAME="CRYPT password storage scheme">14.4.2. CRYPT password storage scheme</A></H3>
<P>This scheme uses the operating system's <EM>crypt(3)</EM> hash function. It normally produces the traditional Unix-style 13 character hash, but on systems with <TT>glibc2</TT> it can also generate the more secure 34-byte MD5 hash.</P>
<PRE>
 userPassword: {CRYPT}aUihad99hmev6
 userPassword: {CRYPT}$1$czBJdDqS$TmkzUAb836oMxg/BmIwN.1
</PRE>
<P>The advantage of the CRYPT scheme is that passwords can be transferred to or from an existing Unix password file without having to know the cleartext form. Both forms of <EM>crypt</EM> include salt so they have some resistance to dictionary attacks.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>Since this scheme uses the operating system's <EM>crypt(3)</EM> hash function, it is therefore operating system specific.
<HR WIDTH="80%" ALIGN="Left"></P>
<H3><A NAME="MD5 password storage scheme">14.4.3. MD5 password storage scheme</A></H3>
<P>This scheme simply takes the MD5 hash of the password and stores it in base64 encoded form:</P>
<PRE>
 userPassword: {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==
</PRE>
<P>Although safer than cleartext storage, this is not a very secure scheme. The MD5 algorithm is fast, and because there is no salt the scheme is vulnerable to a dictionary attack.</P>
<H3><A NAME="SMD5 password storage scheme">14.4.4. SMD5 password storage scheme</A></H3>
<P>This improves on the basic MD5 scheme by adding salt (random data which means that there are many possible representations of a given plaintext password). For example, both of these values represent the same password:</P>
<PRE>
 userPassword: {SMD5}4QWGWZpj9GCmfuqEvm8HtZhZS6E=
 userPassword: {SMD5}g2/J/7D5EO6+oPdklp5p8YtNFk4=
</PRE>
<H3><A NAME="SHA password storage scheme">14.4.5. SHA password storage scheme</A></H3>
<P>Like the MD5 scheme, this simply feeds the password through an SHA hash process. SHA is thought to be more secure than MD5, but the lack of salt leaves the scheme exposed to dictionary attacks.</P>
<PRE>
 userPassword: {SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=
</PRE>
<H3><A NAME="SASL password storage scheme">14.4.6. SASL password storage scheme</A></H3>
<P>This is not really a password storage scheme at all. It uses the value of the <EM>userPassword</EM> attribute to delegate password verification to another process. See below for more information.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>This is not the same as using SASL to authenticate the LDAP session.
<HR WIDTH="80%" ALIGN="Left"></P>
<H2><A NAME="Pass-Through authentication">14.5. Pass-Through authentication</A></H2>
<P>Since OpenLDAP 2.0 <EM>slapd</EM> has had the ability to delegate password verification to a separate process. This uses the <EM>sasl_checkpass(3)</EM> function so it can use any back-end server that Cyrus SASL supports for checking passwords. The choice is very wide, as one option is to use <EM>saslauthd(8)</EM> which in turn can use local files, Kerberos, an IMAP server, another LDAP server, or anything supported by the PAM mechanism.</P>
<P>The server must be built with the <TT>--enable-spasswd</TT> configuration option to enable pass-through authentication.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>This is not the same as using a SASL mechanism to authenticate the LDAP session.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>Pass-Through authentication works only with plaintext passwords, as used in the &quot;simple bind&quot; and &quot;SASL PLAIN&quot; authentication mechanisms.}}</P>
<P>Pass-Through authentication is selective: it only affects users whose <EM>userPassword</EM> attribute has a value marked with the &quot;{SASL}&quot; scheme. The format of the attribute is:</P>
<PRE>
 userPassword: {SASL}username@realm
</PRE>
<P>The <EM>username</EM> and <EM>realm</EM> are passed to the SASL authentication mechanism and are used to identify the account whose password is to be verified. This allows arbitrary mapping between entries in OpenLDAP and accounts known to the backend authentication service.</P>
<P>It would be wise to use access control to prevent users from changing their passwords through LDAP where they have pass-through authentication enabled.</P>
<H3><A NAME="Configuring slapd to use an authentication provider">14.5.1. Configuring slapd to use an authentication provider</A></H3>
<P>Where an entry has a &quot;{SASL}&quot; password value, OpenLDAP delegates the whole process of validating that entry's password to Cyrus SASL. All the configuration is therefore done in SASL config files.</P>
<P>The first file to be considered is confusingly named <EM>slapd.conf</EM> and is typically found in the SASL library directory, often <TT>/usr/lib/sasl2/slapd.conf</TT> This file governs the use of SASL when talking LDAP to <EM>slapd</EM> as well as the use of SASL backends for pass-through authentication. See <TT>options.html</TT> in the <A HREF="https://www.cyrusimap.org/sasl/">Cyrus SASL</A> docs for full details. Here is a simple example for a server that will use <EM>saslauthd</EM> to verify passwords:</P>
<PRE>
 mech_list: plain
 pwcheck_method: saslauthd
 saslauthd_path: /var/run/sasl2/mux
</PRE>
<H3><A NAME="Configuring saslauthd">14.5.2. Configuring saslauthd</A></H3>
<P><EM>saslauthd</EM> is capable of using many different authentication services: see <EM>saslauthd(8)</EM> for details. A common requirement is to delegate some or all authentication to another LDAP server. Here is a sample <TT>saslauthd.conf</TT> that uses Microsoft Active Directory (AD):</P>
<PRE>
 ldap_servers: ldap://dc1.example.com/ ldap://dc2.example.com/

 ldap_search_base: cn=Users,DC=ad,DC=example,DC=com
 ldap_filter: (userPrincipalName=%u)

 ldap_bind_dn: cn=saslauthd,cn=Users,DC=ad,DC=example,DC=com
 ldap_password: secret
</PRE>
<P>In this case, <EM>saslauthd</EM> is run with the <TT>ldap</TT> authentication mechanism and is set to combine the SASL realm with the login name:</P>
<PRE>
 saslauthd -a ldap -r
</PRE>
<P>This means that the &quot;username@realm&quot; string from the <EM>userPassword</EM> attribute ends up being used to search AD for &quot;userPrincipalName=username@realm&quot; - the password is then verified by attempting to bind to AD using the entry found by the search and the password supplied by the LDAP client.</P>
<H3><A NAME="Testing pass-through authentication">14.5.3. Testing pass-through authentication</A></H3>
<P>It is usually best to start with the back-end authentication provider and work through <EM>saslauthd</EM> and <EM>slapd</EM> towards the LDAP client.</P>
<P>In the AD example above, first check that the DN and password that <EM>saslauthd</EM> will use when it connects to AD are valid:</P>
<PRE>
 ldapsearch -x -H ldap://dc1.example.com/ \
      -D cn=saslauthd,cn=Users,DC=ad,DC=example,DC=com \
      -w secret \
      -b '' \
      -s base
</PRE>
<P>Next check that a sample AD user can be found:</P>
<PRE>
 ldapsearch -x -H ldap://dc1.example.com/ \
      -D cn=saslauthd,cn=Users,DC=ad,DC=example,DC=com \
      -w secret \
      -b cn=Users,DC=ad,DC=example,DC=com \
      &quot;(userPrincipalName=user@ad.example.com)&quot;
</PRE>
<P>Check that the user can bind to AD:</P>
<PRE>
 ldapsearch -x -H ldap://dc1.example.com/ \
      -D cn=user,cn=Users,DC=ad,DC=example,DC=com \
      -w userpassword \
      -b cn=user,cn=Users,DC=ad,DC=example,DC=com \
      -s base \
        &quot;(objectclass=*)&quot;
</PRE>
<P>If all that works then <EM>saslauthd</EM> should be able to do the same:</P>
<PRE>
 testsaslauthd -u user@ad.example.com -p userpassword
 testsaslauthd -u user@ad.example.com -p wrongpassword
</PRE>
<P>Now put the magic token into an entry in OpenLDAP:</P>
<PRE>
 userPassword: {SASL}user@ad.example.com
</PRE>
<P>It should now be possible to bind to OpenLDAP using the DN of that entry and the password of the AD user.</P>
<P></P>
<HR>
<H1><A NAME="Using SASL">15. Using SASL</A></H1>
<P>OpenLDAP clients and servers are capable of authenticating via the <TERM>Simple Authentication and Security Layer</TERM> (<TERM>SASL</TERM>) framework, which is detailed in <A HREF="https://www.rfc-editor.org/rfc/rfc4422.txt">RFC4422</A>.   This chapter describes how to make use of SASL in OpenLDAP.</P>
<P>There are several industry standard authentication mechanisms that can be used with SASL, including <TERM>GSSAPI</TERM> for <TERM>Kerberos</TERM> V, <TERM>DIGEST-MD5</TERM>, and <TERM>PLAIN</TERM> and <TERM>EXTERNAL</TERM> for use with <TERM>Transport Layer Security</TERM> (TLS).</P>
<P>The standard client tools provided with OpenLDAP Software, such as <EM>ldapsearch</EM>(1) and <EM>ldapmodify</EM>(1), will by default attempt to authenticate the user to the <TERM>LDAP</TERM> directory server using SASL.  Basic authentication service can be set up by the LDAP administrator with a few steps, allowing users to be authenticated to the slapd server as their LDAP entry.  With a few extra steps, some users and services can be allowed to exploit SASL's proxy authorization feature, allowing them to authenticate themselves and then switch their identity to that of another user or service.</P>
<P>This chapter assumes you have read <EM>Cyrus SASL for System Administrators</EM>, provided with the <A HREF="https://www.cyrusimap.org/sasl/">Cyrus SASL</A> package (in <TT>doc/sysadmin.html</TT>) and have a working Cyrus SASL installation.  You should use the Cyrus SASL <TT>sample_client</TT> and <TT>sample_server</TT> to test your SASL installation before attempting to make use of it with OpenLDAP Software.</P>
<P>Note that in the following text the term <EM>user</EM> is used to describe a person or application entity who is connecting to the LDAP server via an LDAP client, such as <EM>ldapsearch</EM>(1).  That is, the term <EM>user</EM> not only applies to both an individual using an LDAP client, but to an application entity which issues LDAP client operations without direct user control.  For example, an e-mail server which uses LDAP operations to access information held in an LDAP server is an application entity.</P>
<H2><A NAME="SASL Security Considerations">15.1. SASL Security Considerations</A></H2>
<P>SASL offers many different authentication mechanisms.  This section briefly outlines security considerations.</P>
<P>Some mechanisms, such as PLAIN and LOGIN, offer no greater security over LDAP <EM>simple</EM> authentication.  Like LDAP <EM>simple</EM> authentication, such mechanisms should not be used unless you have adequate security protections in place.  It is recommended that these mechanisms be used only in conjunction with <TERM>Transport Layer Security</TERM> (TLS).  Use of PLAIN and LOGIN are not discussed further in this document.</P>
<P>The DIGEST-MD5 mechanism is the mandatory-to-implement authentication mechanism for LDAPv3.  Though DIGEST-MD5 is not a strong authentication mechanism in comparison with trusted third party authentication systems (such as <TERM>Kerberos</TERM> or public key systems), it does offer significant protections against a number of attacks.  Unlike the <TERM>CRAM-MD5</TERM> mechanism, it prevents chosen plaintext attacks.  DIGEST-MD5 is favored over the use of plaintext password mechanisms.  The CRAM-MD5 mechanism is deprecated in favor of DIGEST-MD5.  Use of <A HREF="#DIGEST-MD5">DIGEST-MD5</A> is discussed below.</P>
<P>The GSSAPI mechanism utilizes <TERM>GSS-API</TERM> <TERM>Kerberos</TERM> V to provide secure authentication services.  The KERBEROS_V4 mechanism is available for those using Kerberos IV.  Kerberos is viewed as a secure, distributed authentication system suitable for both small and large enterprises.  Use of <A HREF="#GSSAPI">GSSAPI</A> and <A HREF="#KERBEROS_V4">KERBEROS_V4</A> are discussed below.</P>
<P>The EXTERNAL mechanism utilizes authentication services provided by lower level network services such as <TERM>Transport Layer Security</TERM> (<TERM>TLS</TERM>).  When used in conjunction with <TERM>TLS</TERM> <TERM>X.509</TERM>-based public key technology, EXTERNAL offers strong authentication. TLS is discussed in the <A HREF="#Using TLS">Using TLS</A> chapter.</P>
<P>EXTERNAL can also be used with the <TT>ldapi:///</TT> transport, as Unix-domain sockets can report the UID and GID of the client process.</P>
<P>There are other strong authentication mechanisms to choose from, including <TERM>OTP</TERM> (one time passwords) and <TERM>SRP</TERM> (secure remote passwords).  These mechanisms are not discussed in this document.</P>
<H2><A NAME="SASL Authentication">15.2. SASL Authentication</A></H2>
<P>Getting basic SASL authentication running involves a few steps. The first step configures your slapd server environment so that it can communicate with client programs using the security system in place at your site. This usually involves setting up a service key, a public key, or other form of secret. The second step concerns mapping authentication identities to LDAP <TERM>DN</TERM>'s, which depends on how entries are laid out in your directory. An explanation of the first step will be given in the next section using Kerberos V4 as an example mechanism. The steps necessary for your site's authentication mechanism will be similar, but a guide to every mechanism available under SASL is beyond the scope of this chapter. The second step is described in the section <A HREF="#Mapping Authentication Identities">Mapping Authentication Identities</A>.</P>
<H3><A NAME="GSSAPI">15.2.1. GSSAPI</A></H3>
<P>This section describes the use of the SASL GSSAPI mechanism and Kerberos V with OpenLDAP.  It will be assumed that you have Kerberos V deployed, you are familiar with the operation of the system, and that your users are trained in its use.  This section also assumes you have familiarized yourself with the use of the GSSAPI mechanism by reading <EM>Configuring GSSAPI and Cyrus SASL</EM> (provided with Cyrus SASL in the <TT>doc/gssapi</TT> file) and successfully experimented with the Cyrus provided <TT>sample_server</TT> and <TT>sample_client</TT> applications.  General information about Kerberos is available at <A HREF="http://web.mit.edu/kerberos/www/">http://web.mit.edu/kerberos/www/</A>.</P>
<P>To use the GSSAPI mechanism with <EM>slapd</EM>(8) one must create a service key with a principal for <EM>ldap</EM> service within the realm for the host on which the service runs.  For example, if you run <EM>slapd</EM> on <TT>directory.example.com</TT> and your realm is <TT>EXAMPLE.COM</TT>, you need to create a service key with the principal:</P>
<PRE>
        ldap/directory.example.com@EXAMPLE.COM
</PRE>
<P>When <EM>slapd</EM>(8) runs, it must have access to this key.  This is generally done by placing the key into a keytab file, <TT>/etc/krb5.keytab</TT>.  See your Kerberos and Cyrus SASL documentation for information regarding keytab location settings.</P>
<P>To use the GSSAPI mechanism to authenticate to the directory, the user obtains a Ticket Granting Ticket (TGT) prior to running the LDAP client.  When using OpenLDAP client tools, the user may mandate use of the GSSAPI mechanism by specifying <TT>-Y GSSAPI</TT> as a command option.</P>
<P>For the purposes of authentication and authorization, <EM>slapd</EM>(8) associates an authentication request DN of the form:</P>
<PRE>
        uid=&lt;primary[/instance][@realm]&gt;,cn=gssapi,cn=auth
</PRE>
<P>The realm is omitted by Cyrus SASL if it's equal to the default realm of the server in <TT>/etc/krb5.conf</TT>.</P>
<P>Continuing our example, a user with the Kerberos principal <TT>kurt@EXAMPLE.COM</TT> would have the associated DN:</P>
<PRE>
        uid=kurt,cn=gssapi,cn=auth
</PRE>
<P>and the principal <TT>ursula/admin@FOREIGN.REALM</TT> would have the associated DN:</P>
<PRE>
        uid=ursula/admin@foreign.realm,cn=gssapi,cn=auth
</PRE>
<P>The authentication request DN can be used directly in ACLs and <TT>groupOfNames</TT> &quot;member&quot; attributes, since it is of legitimate LDAP DN format.  Or alternatively, the authentication DN could be mapped before use.  See the section <A HREF="#Mapping Authentication Identities">Mapping Authentication Identities</A> for details.</P>
<P>If you configure the <EM>olcSaslRealm</EM> then it will be inserted as an extra component in the authorization DN, regardless of any Kerberos realms in use. For example, if you set olcSaslRealm to <TT>example.com</TT> then you will get:</P>
<PRE>
        uid=kurt,cn=example.com,cn=gssapi,cn=auth
        uid=ursula/admin@foreign.realm,cn=example.com,cn=gssapi,cn=auth
</PRE>
<H3><A NAME="KERBEROS_V4">15.2.2. KERBEROS_V4</A></H3>
<P>This section describes the use of the SASL KERBEROS_V4 mechanism with OpenLDAP.  It will be assumed that you are familiar with the workings of the Kerberos IV security system, and that your site has Kerberos IV deployed.  Your users should be familiar with authentication policy, how to receive credentials in a Kerberos ticket cache, and how to refresh expired credentials.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>KERBEROS_V4 and Kerberos IV are deprecated in favor of GSSAPI and Kerberos V.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>Client programs will need to be able to obtain a session key for use when connecting to your LDAP server. This allows the LDAP server to know the identity of the user, and allows the client to know it is connecting to a legitimate server. If encryption layers are to be used, the session key can also be used to help negotiate that option.</P>
<P>The slapd server runs the service called &quot;<EM>ldap</EM>&quot;, and the server will require a srvtab file with a service key.  SASL aware client programs will be obtaining an &quot;ldap&quot; service ticket with the user's ticket granting ticket (TGT), with the instance of the ticket matching the hostname of the OpenLDAP server. For example, if your realm is named <TT>EXAMPLE.COM</TT> and the slapd server is running on the host named <TT>directory.example.com</TT>, the <TT>/etc/srvtab</TT> file on the server will have a service key</P>
<PRE>
        ldap.directory@EXAMPLE.COM
</PRE>
<P>When an LDAP client is authenticating a user to the directory using the KERBEROS_IV mechanism, it will request a session key for that same principal, either from the ticket cache or by obtaining a new one from the Kerberos server.  This will require the TGT to be available and valid in the cache as well.  If it is not present or has expired, the client may print out the message:</P>
<PRE>
        ldap_sasl_interactive_bind_s: Local error
</PRE>
<P>When the service ticket is obtained, it will be passed to the LDAP server as proof of the user's identity.  The server will extract the identity and realm out of the service ticket using SASL library calls, and convert them into an <EM>authentication request DN</EM> of the form</P>
<PRE>
        uid=&lt;username&gt;,cn=&lt;realm&gt;,cn=&lt;mechanism&gt;,cn=auth
</PRE>
<P>So in our above example, if the user's name were &quot;adamson&quot;, the authentication request DN would be:</P>
<PRE>
        uid=adamson,cn=example.com,cn=kerberos_v4,cn=auth
</PRE>
<P>This authentication request DN can be used directly ACLs or, alternatively, mapped prior to use.  See the section <A HREF="#Mapping Authentication Identities">Mapping Authentication Identities</A> for details.</P>
<H3><A NAME="DIGEST-MD5">15.2.3. DIGEST-MD5</A></H3>
<P>This section describes the use of the SASL DIGEST-MD5 mechanism using secrets stored either in the directory itself or in Cyrus SASL's own database. DIGEST-MD5 relies on the client and the server sharing a &quot;secret&quot;, usually a password. The server generates a challenge and the client a response proving that it knows the shared secret. This is much more secure than simply sending the secret over the wire.</P>
<P>Cyrus SASL supports several shared-secret mechanisms. To do this, it needs access to the plaintext password (unlike mechanisms which pass plaintext passwords over the wire, where the server can store a hashed version of the password).</P>
<P>The server's copy of the shared-secret may be stored in Cyrus SASL's own <EM>sasldb</EM> database, in an external system accessed via <EM>saslauthd</EM>, or in LDAP database itself.  In either case it is very important to apply file access controls and LDAP access controls to prevent exposure of the passwords.  The configuration and commands discussed in this section assume the use of Cyrus SASL 2.1.</P>
<P>To use secrets stored in <EM>sasldb</EM>, simply add users with the <EM>saslpasswd2</EM> command:</P>
<PRE>
       saslpasswd2 -c &lt;username&gt;
</PRE>
<P>The passwords for such users must be managed with the <EM>saslpasswd2</EM> command.</P>
<P>To use secrets stored in the LDAP directory, place plaintext passwords in the <TT>userPassword</TT> attribute.  It will be necessary to add an option to <TT>slapd.conf</TT> to make sure that passwords set using the LDAP Password Modify Operation are stored in plaintext:</P>
<PRE>
       password-hash   {CLEARTEXT}
</PRE>
<P>Passwords stored in this way can be managed either with <EM>ldappasswd</EM>(1) or by simply modifying the <TT>userPassword</TT> attribute.  Regardless of where the passwords are stored, a mapping will be needed from authentication request DN to user's DN.</P>
<P>The DIGEST-MD5 mechanism produces authentication IDs of the form:</P>
<PRE>
        uid=&lt;username&gt;,cn=&lt;realm&gt;,cn=digest-md5,cn=auth
</PRE>
<P>If the default realm is used, the realm name is omitted from the ID, giving:</P>
<PRE>
        uid=&lt;username&gt;,cn=digest-md5,cn=auth
</PRE>
<P>See <A HREF="#Mapping Authentication Identities">Mapping Authentication Identities</A> below for information on optional mapping of identities.</P>
<P>With suitable mappings in place, users can specify SASL IDs when performing LDAP operations, and the password stored in <EM>sasldb</EM> or in the directory itself will be used to verify the authentication. For example, the user identified by the directory entry:</P>
<PRE>
       dn: cn=Andrew Findlay+uid=u000997,dc=example,dc=com
       objectclass: inetOrgPerson
       objectclass: person
       sn: Findlay
       uid: u000997
       userPassword: secret
</PRE>
<P>can issue commands of the form:</P>
<PRE>
       ldapsearch -Y DIGEST-MD5 -U u000997 ...
</PRE>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>in each of the above cases, no authorization identity (e.g. <TT>-X</TT>) was provided.   Unless you are attempting <A HREF="#SASL Proxy Authorization">SASL Proxy Authorization</A>, no authorization identity should be specified. The server will infer an authorization identity from authentication identity (as described below).
<HR WIDTH="80%" ALIGN="Left"></P>
<H3><A NAME="EXTERNAL">15.2.4. EXTERNAL</A></H3>
<P>The SASL EXTERNAL mechanism makes use of an authentication performed by a lower-level protocol: usually <TERM>TLS</TERM> or Unix <TERM>IPC</TERM></P>
<P>Each transport protocol returns Authentication Identities in its own format:</P>
<H4><A NAME="TLS Authentication Identity Format">15.2.4.1. TLS Authentication Identity Format</A></H4>
<P>This is the Subject DN from the client-side certificate. Note that DNs are displayed differently by LDAP and by X.509, so a certificate issued to</P>
<PRE>
        C=gb, O=The Example Organisation, CN=A Person
</PRE>
<P>will produce an authentication identity of:</P>
<PRE>
        cn=A Person,o=The Example Organisation,c=gb
</PRE>
<P>Note that you must set a suitable value for TLSVerifyClient to make the server request the use of a client-side certificate. Without this, the SASL EXTERNAL mechanism will not be offered. Refer to the <A HREF="#Using TLS">Using TLS</A> chapter for details.</P>
<H4><A NAME="IPC (ldapi:///) Identity Format">15.2.4.2. IPC (ldapi:///) Identity Format</A></H4>
<P>This is formed from the Unix UID and GID of the client process:</P>
<PRE>
        gidNumber=&lt;number&gt;+uidNumber=&lt;number&gt;,cn=peercred,cn=external,cn=auth
</PRE>
<P>Thus, a client process running as <TT>root</TT> will be:</P>
<PRE>
        gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
</PRE>
<H3><A NAME="Mapping Authentication Identities">15.2.5. Mapping Authentication Identities</A></H3>
<P>The authentication mechanism in the slapd server will use SASL library calls to obtain the authenticated user's &quot;username&quot;, based on whatever underlying authentication mechanism was used.  This username is in the namespace of the authentication mechanism, and not in the normal LDAP namespace. As stated in the sections above, that username is reformatted into an authentication request DN of the form</P>
<PRE>
        uid=&lt;username&gt;,cn=&lt;realm&gt;,cn=&lt;mechanism&gt;,cn=auth
</PRE>
<P>or</P>
<PRE>
        uid=&lt;username&gt;,cn=&lt;mechanism&gt;,cn=auth
</PRE>
<P>depending on whether or not &lt;mechanism&gt; employs the concept of &quot;realms&quot;.  Note also that the realm part will be omitted if the default realm was used in the authentication.</P>
<P>The <EM>ldapwhoami</EM>(1) command may be used to determine the identity associated with the user.  It is very useful for determining proper function of mappings.</P>
<P>It is not intended that you should add LDAP entries of the above form to your LDAP database.  Chances are you have an LDAP entry for each of the persons that will be authenticating to LDAP, laid out in your directory tree, and the tree does not start at cn=auth. But if your site has a clear mapping between the &quot;username&quot; and an LDAP entry for the person, you will be able to configure your LDAP server to automatically map a authentication request DN to the user's <EM>authentication DN</EM>.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>it is not required that the authentication request DN nor the user's authentication DN resulting from the mapping refer to an entry held in the directory.  However, additional capabilities become available (see below).
<HR WIDTH="80%" ALIGN="Left"></P>
<P>The LDAP administrator will need to tell the slapd server how to map an authentication request DN to a user's authentication DN. This is done by adding one or more <TT>authz-regexp</TT> directives to the <EM>slapd.conf</EM>(5) file.  This directive takes two arguments:</P>
<PRE>
        authz-regexp   &lt;search pattern&gt;   &lt;replacement pattern&gt;
</PRE>
<P>The authentication request DN is compared to the search pattern using the regular expression functions <EM>regcomp</EM>() and <EM>regexec</EM>(), and if it matches, it is rewritten as the replacement pattern. If there are multiple <TT>authz-regexp</TT> directives, only the first whose search pattern matches the authentication identity is used. The string that is output from the replacement pattern should be the authentication DN of the user or an LDAP URL.  If replacement string produces a DN, the entry named by this DN need not be held by this server.  If the replace string produces an LDAP URL, that LDAP URL must evaluate to one and only one entry held by this server.</P>
<P>The search pattern can contain any of the regular expression characters listed in <EM>regexec</EM>(3C). The main characters of note are dot &quot;.&quot;, asterisk &quot;*&quot;, and the open and close parenthesis &quot;(&quot; and &quot;)&quot;.  Essentially, the dot matches any character, the asterisk allows zero or more repeats of the immediately preceding character or pattern, and terms in parenthesis are remembered for the replacement pattern.</P>
<P>The replacement pattern will produce either a DN or URL referring to the user.  Anything from the authentication request DN that matched a string in parenthesis in the search pattern is stored in the variable &quot;$1&quot;. That variable &quot;$1&quot; can appear in the replacement pattern, and will be replaced by the string from the authentication request DN. If there were multiple sets of parentheses in the search pattern, the variables $2, $3, etc are used.</P>
<H3><A NAME="Direct Mapping">15.2.6. Direct Mapping</A></H3>
<P>Where possible, direct mapping of the authentication request DN to the user's DN is generally recommended.  Aside from avoiding the expense of searching for the user's DN, it allows mapping to DNs which refer to entries not held by this server.</P>
<P>Suppose the authentication request DN is written as:</P>
<PRE>
        uid=adamson,cn=example.com,cn=gssapi,cn=auth
</PRE>
<P>and the user's actual LDAP entry is:</P>
<PRE>
        uid=adamson,ou=people,dc=example,dc=com
</PRE>
<P>then the following <TT>authz-regexp</TT> directive in <EM>slapd.conf</EM>(5) would provide for direct mapping.</P>
<PRE>
        authz-regexp
          uid=([^,]*),cn=example.com,cn=gssapi,cn=auth
          uid=$1,ou=people,dc=example,dc=com
</PRE>
<P>An even more lenient rule could be written as</P>
<PRE>
        authz-regexp
          uid=([^,]*),cn=[^,]*,cn=auth
          uid=$1,ou=people,dc=example,dc=com
</PRE>
<P>Be careful about setting the search pattern too leniently, however, since it may mistakenly allow persons to become authenticated as a DN to which they should not have access.  It is better to write several strict directives than one lenient directive which has security holes.  If there is only one authentication mechanism in place at your site, and zero or one realms in use, you might be able to map between authentication identities and LDAP DN's with a single <TT>authz-regexp</TT> directive.</P>
<P>Don't forget to allow for the case where the realm is omitted as well as the case with an explicitly specified realm. This may well require a separate <TT>authz-regexp</TT> directive for each case, with the explicit-realm entry being listed first.</P>
<H3><A NAME="Search-based mappings">15.2.7. Search-based mappings</A></H3>
<P>There are a number of cases where mapping to a LDAP URL may be appropriate.  For instance, some sites may have person objects located in multiple areas of the LDAP tree, such as if there were an <TT>ou=accounting</TT> tree and an <TT>ou=engineering</TT> tree, with persons interspersed between them.  Or, maybe the desired mapping must be based upon information in the user's information. Consider the need to map the above authentication request DN to user whose entry is as follows:</P>
<PRE>
        dn: cn=Mark Adamson,ou=People,dc=Example,dc=COM
        objectclass: person
        cn: Mark Adamson
        uid: adamson
</PRE>
<P>The information in the authentication request DN is insufficient to allow the user's DN to be directly derived, instead the user's DN must be searched for.  For these situations, a replacement pattern which produces a LDAP URL can be used in the <TT>authz-regexp</TT> directives.  This URL will then be used to perform an internal search of the LDAP database to find the person's authentication DN.</P>
<P>An LDAP URL, similar to other URL's, is of the form</P>
<PRE>
        ldap://&lt;host&gt;/&lt;base&gt;?&lt;attrs&gt;?&lt;scope&gt;?&lt;filter&gt;
</PRE>
<P>This contains all of the elements necessary to perform an LDAP search:  the name of the server &lt;host&gt;, the LDAP DN search base &lt;base&gt;, the LDAP attributes to retrieve &lt;attrs&gt;, the search scope &lt;scope&gt; which is one of the three options &quot;base&quot;, &quot;one&quot;, or &quot;sub&quot;, and lastly an LDAP search filter &lt;filter&gt;.  Since the search is for an LDAP DN within the current server, the &lt;host&gt; portion should be empty.  The &lt;attrs&gt; field is also ignored since only the DN is of concern.  These two elements are left in the format of the URL to maintain the clarity of what information goes where in the string.</P>
<P>Suppose that the person in the example from above did in fact have an authentication username of &quot;adamson&quot; and that information was kept in the attribute &quot;uid&quot; in their LDAP entry. The <TT>authz-regexp</TT> directive might be written as</P>
<PRE>
        authz-regexp
          uid=([^,]*),cn=example.com,cn=gssapi,cn=auth
          ldap:///ou=people,dc=example,dc=com??one?(uid=$1)
</PRE>
<P>This will initiate an internal search of the LDAP database inside the slapd server. If the search returns exactly one entry, it is accepted as being the DN of the user. If there are more than one entries returned, or if there are zero entries returned, the authentication fails and the user's connection is left bound as the authentication request DN.</P>
<P>The attributes that are used in the search filter &lt;filter&gt; in the URL should be indexed to allow faster searching. If they are not, the authentication step alone can take uncomfortably long periods, and users may assume the server is down.</P>
<P>A more complex site might have several realms in use, each mapping to a different subtree in the directory.  These can be handled with statements of the form:</P>
<PRE>
        # Match Engineering realm
        authz-regexp
           uid=([^,]*),cn=engineering.example.com,cn=digest-md5,cn=auth
           ldap:///dc=eng,dc=example,dc=com??one?(&amp;(uid=$1)(objectClass=person))

        # Match Accounting realm
        authz-regexp
           uid=([^,].*),cn=accounting.example.com,cn=digest-md5,cn=auth
           ldap:///dc=accounting,dc=example,dc=com??one?(&amp;(uid=$1)(objectClass=person))

        # Default realm is customers.example.com
        authz-regexp
           uid=([^,]*),cn=digest-md5,cn=auth
           ldap:///dc=customers,dc=example,dc=com??one?(&amp;(uid=$1)(objectClass=person))
</PRE>
<P>Note that the explicitly-named realms are handled first, to avoid the realm name becoming part of the UID.  Also note the use of scope and filters to limit matching to desirable entries.</P>
<P>Note as well that <TT>authz-regexp</TT> internal search are subject to access controls.  Specifically, the authentication identity must have <TT>auth</TT> access.</P>
<P>See <EM>slapd.conf</EM>(5) for more detailed information.</P>
<H2><A NAME="SASL Proxy Authorization">15.3. SASL Proxy Authorization</A></H2>
<P>The SASL offers a feature known as <EM>proxy authorization</EM>, which allows an authenticated user to request that they act on the behalf of another user.  This step occurs after the user has obtained an authentication DN, and involves sending an authorization identity to the server. The server will then make a decision on whether or not to allow the authorization to occur. If it is allowed, the user's LDAP connection is switched to have a binding DN derived from the authorization identity, and the LDAP session proceeds with the access of the new authorization DN.</P>
<P>The decision to allow an authorization to proceed depends on the rules and policies of the site where LDAP is running, and thus cannot be made by SASL alone. The SASL library leaves it up to the server to make the decision. The LDAP administrator sets the guidelines of who can authorize to what identity by adding information into the LDAP database entries. By default, the authorization features are disabled, and must be explicitly configured by the LDAP administrator before use.</P>
<H3><A NAME="Uses of Proxy Authorization">15.3.1. Uses of Proxy Authorization</A></H3>
<P>This sort of service is useful when one entity needs to act on the behalf of many other users. For example, users may be directed to a web page to make changes to their personal information in their LDAP entry. The users authenticate to the web server to establish their identity, but the web server CGI cannot authenticate to the LDAP server as that user to make changes for them. Instead, the web server authenticates itself to the LDAP server as a service identity, say,</P>
<PRE>
        cn=WebUpdate,dc=example,dc=com
</PRE>
<P>and then it will SASL authorize to the DN of the user. Once so authorized, the CGI makes changes to the LDAP entry of the user, and as far as the slapd server can tell for its ACLs, it is the user themself on the other end of the connection. The user could have connected to the LDAP server directly and authenticated as themself, but that would require the user to have more knowledge of LDAP clients, knowledge which the web page provides in an easier format.</P>
<P>Proxy authorization can also be used to limit access to an account that has greater access to the database. Such an account, perhaps even the root DN specified in <EM>slapd.conf</EM>(5), can have a strict list of people who can authorize to that DN. Changes to the LDAP database could then be only allowed by that DN, and in order to become that DN, users must first authenticate as one of the persons on the list. This allows for better auditing of who made changes to the LDAP database.  If people were allowed to authenticate directly to the privileged account, possibly through the <TT>rootpw</TT> <EM>slapd.conf</EM>(5) directive or through a <TT>userPassword</TT> attribute, then auditing becomes more difficult.</P>
<P>Note that after a successful proxy authorization, the original authentication DN of the LDAP connection is overwritten by the new DN from the authorization request. If a service program is able to authenticate itself as its own authentication DN and then authorize to other DN's, and it is planning on switching to several different identities during one LDAP session, it will need to authenticate itself each time before authorizing to another DN (or use a different proxy authorization mechanism).  The slapd server does not keep record of the service program's ability to switch to other DN's. On authentication mechanisms like Kerberos this will not require multiple connections being made to the Kerberos server, since the user's TGT and &quot;ldap&quot; session key are valid for multiple uses for the several hours of the ticket lifetime.</P>
<H3><A NAME="SASL Authorization Identities">15.3.2. SASL Authorization Identities</A></H3>
<P>The SASL authorization identity is sent to the LDAP server via the <TT>-X</TT> switch for <EM>ldapsearch</EM>(1) and other tools, or in the <TT>*authzid</TT> parameter to the <EM>lutil_sasl_defaults</EM>() call. The identity can be in one of two forms, either</P>
<PRE>
        u:&lt;username&gt;
</PRE>
<P>or</P>
<PRE>
        dn:&lt;dn&gt;
</PRE>
<P>In the first form, the &lt;username&gt; is from the same namespace as the authentication identities above. It is the user's username as it is referred to by the underlying authentication mechanism. Authorization identities of this form are converted into a DN format by the same function that the authentication process used, producing an <EM>authorization request DN</EM> of the form</P>
<PRE>
        uid=&lt;username&gt;,cn=&lt;realm&gt;,cn=&lt;mechanism&gt;,cn=auth
</PRE>
<P>That authorization request DN is then run through the same <TT>authz-regexp</TT> process to convert it into a legitimate authorization DN from the database. If it cannot be converted due to a failed search from an LDAP URL, the authorization request fails with &quot;inappropriate access&quot;.  Otherwise, the DN string is now a legitimate authorization DN ready to undergo approval.</P>
<P>If the authorization identity was provided in the second form, with a <TT>&quot;dn:&quot;</TT> prefix, the string after the prefix is already in authorization DN form, ready to undergo approval.</P>
<H3><A NAME="Proxy Authorization Rules">15.3.3. Proxy Authorization Rules</A></H3>
<P>Once slapd has the authorization DN, the actual approval process begins. There are two attributes that the LDAP administrator can put into LDAP entries to allow authorization:</P>
<PRE>
        authzTo
        authzFrom
</PRE>
<P>Both can be multivalued.  The <TT>authzTo</TT> attribute is a source rule, and it is placed into the entry associated with the authentication DN to tell what authorization DNs the authenticated DN is allowed to assume.  The second attribute is a destination rule, and it is placed into the entry associated with the requested authorization DN to tell which authenticated DNs may assume it.</P>
<P>The choice of which authorization policy attribute to use is up to the administrator.  Source rules are checked first in the person's authentication DN entry, and if none of the <TT>authzTo</TT> rules specify the authorization is permitted, the <TT>authzFrom</TT> rules in the authorization DN entry are then checked. If neither case specifies that the request be honored, the request is denied. Since the default behavior is to deny authorization requests, rules only specify that a request be allowed; there are no negative rules telling what authorizations to deny.</P>
<P>The value(s) in the two attributes are of the same form as the output of the replacement pattern of a <TT>authz-regexp</TT> directive: either a DN or an LDAP URL. For example, if a <TT>authzTo</TT> value is a DN, that DN is one the authenticated user can authorize to. On the other hand, if the <TT>authzTo</TT> value is an LDAP URL, the URL is used as an internal search of the LDAP database, and the authenticated user can become ANY DN returned by the search. If an LDAP entry looked like:</P>
<PRE>
        dn: cn=WebUpdate,dc=example,dc=com
        authzTo: ldap:///dc=example,dc=com??sub?(objectclass=person)
</PRE>
<P>then any user who authenticated as <TT>cn=WebUpdate,dc=example,dc=com</TT> could authorize to any other LDAP entry under the search base <TT>dc=example,dc=com</TT> which has an objectClass of <TT>Person</TT>.</P>
<H4><A NAME="Notes on Proxy Authorization Rules">15.3.3.1. Notes on Proxy Authorization Rules</A></H4>
<P>An LDAP URL in a <TT>authzTo</TT> or <TT>authzFrom</TT> attribute will return a set of DNs.  Each DN returned will be checked.  Searches which return a large set can cause the authorization process to take an uncomfortably long time. Also, searches should be performed on attributes that have been indexed by slapd.</P>
<P>To help produce more sweeping rules for <TT>authzFrom</TT> and <TT>authzTo</TT>, the values of these attributes are allowed to be DNs with regular expression characters in them. This means a source rule like</P>
<PRE>
        authzTo: dn.regex:^uid=[^,]*,dc=example,dc=com$
</PRE>
<P>would allow that authenticated user to authorize to any DN that matches the regular expression pattern given. This regular expression comparison can be evaluated much faster than an LDAP search for <TT>(uid=*)</TT>.</P>
<P>Also note that the values in an authorization rule must be one of the two forms: an LDAP URL or a DN (with or without regular expression characters). Anything that does not begin with &quot;<TT>ldap://</TT>&quot; is taken as a DN. It is not permissible to enter another authorization identity of the form &quot;<TT>u:&lt;username&gt;</TT>&quot; as an authorization rule.</P>
<H4><A NAME="Policy Configuration">15.3.3.2. Policy Configuration</A></H4>
<P>The decision of which type of rules to use, <TT>authzFrom</TT> or <TT>authzTo</TT>, will depend on the site's situation. For example, if the set of people who may become a given identity can easily be written as a search filter, then a single destination rule could be written. If the set of people is not easily defined by a search filter, and the set of people is small, it may be better to write a source rule in the entries of each of those people who should be allowed to perform the proxy authorization.</P>
<P>By default, processing of proxy authorization rules is disabled. The <TT>authz-policy</TT> directive must be set in the <EM>slapd.conf</EM>(5) file to enable authorization. This directive can be set to <TT>none</TT> for no rules (the default), <TT>to</TT> for source rules, <TT>from</TT> for destination rules, or <TT>both</TT> for both source and destination rules.</P>
<P>Source rules are extremely powerful. If ordinary users have access to write the <TT>authzTo</TT> attribute in their own entries, then they can write rules that would allow them to authorize as anyone else.  As such, when using source rules, the <TT>authzTo</TT> attribute should be protected with an ACL that only allows privileged users to set its values.</P>
<P></P>
<HR>
<H1><A NAME="Using TLS">16. Using TLS</A></H1>
<P>OpenLDAP clients and servers are capable of using the <TERM>Transport Layer Security</TERM> (<TERM>TLS</TERM>) framework to provide integrity and confidentiality protections and to support LDAP authentication using the <TERM>SASL</TERM> <TERM>EXTERNAL</TERM> mechanism. TLS is defined in <A HREF="https://www.rfc-editor.org/rfc/rfc4346.txt">RFC4346</A>.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>For generating certificates, please reference <A HREF="http://www.openldap.org/faq/data/cache/185.html">http://www.openldap.org/faq/data/cache/185.html</A>
<HR WIDTH="80%" ALIGN="Left"></P>
<H2><A NAME="TLS Certificates">16.1. TLS Certificates</A></H2>
<P>TLS uses <TERM>X.509</TERM> certificates to carry client and server identities.  All servers are required to have valid certificates, whereas client certificates are optional.  Clients must have a valid certificate in order to authenticate via SASL EXTERNAL. For more information on creating and managing certificates, see the <A HREF="https://www.openssl.org/">OpenSSL</A> or <A HREF="https://gnutls.org/">GnuTLS</A> documentation, depending on which TLS implementation libraries you are using.</P>
<H3><A NAME="Server Certificates">16.1.1. Server Certificates</A></H3>
<P>The <TERM>DN</TERM> of a server certificate must use the <TT>CN</TT> attribute to name the server, and the <TT>CN</TT> must carry the server's fully qualified domain name. Additional alias names and wildcards may be present in the <TT>subjectAltName</TT> certificate extension.  More details on server certificate names are in <A HREF="https://www.rfc-editor.org/rfc/rfc4513.txt">RFC4513</A>.</P>
<H3><A NAME="Client Certificates">16.1.2. Client Certificates</A></H3>
<P>The DN of a client certificate can be used directly as an authentication DN. Since X.509 is a part of the <TERM>X.500</TERM> standard and LDAP is also based on X.500, both use the same DN formats and generally the DN in a user's X.509 certificate should be identical to the DN of their LDAP entry. However, sometimes the DNs may not be exactly the same, and so the mapping facility described in <A HREF="#Mapping Authentication Identities">Mapping Authentication Identities</A> can be applied to these DNs as well.</P>
<H2><A NAME="TLS Configuration">16.2. TLS Configuration</A></H2>
<P>After obtaining the required certificates, a number of options must be configured on both the client and the server to enable TLS and make use of the certificates.  At a minimum, the clients must be configured with the name of the file containing all of the <TERM>Certificate Authority</TERM> (CA) certificates it will trust. The server must be configured with the <TERM>CA</TERM> certificates and also its own server certificate and private key.</P>
<P>Typically a single CA will have issued the server certificate and all of the trusted client certificates, so the server only needs to trust that one signing CA. However, a client may wish to connect to a variety of secure servers managed by different organizations, with server certificates generated by many different CAs. As such, a client is likely to need a list of many different trusted CAs in its configuration.</P>
<H3><A NAME="Server Configuration">16.2.1. Server Configuration</A></H3>
<P>The configuration directives for slapd belong in the global directives section of <EM>slapd.conf</EM>(5).</P>
<H4><A NAME="TLSCACertificateFile &lt;filename&gt;">16.2.1.1. TLSCACertificateFile &lt;filename&gt;</A></H4>
<P>This directive specifies the <TERM>PEM</TERM>-format file containing certificates for the CA's that slapd will trust. The certificate for the CA that signed the server certificate must be included among these certificates. If the signing CA was not a top-level (root) CA, certificates for the entire sequence of CA's from the signing CA to the top-level CA should be present. Multiple certificates are simply appended to the file; the order is not significant.</P>
<H4><A NAME="TLSCACertificatePath &lt;path&gt;">16.2.1.2. TLSCACertificatePath &lt;path&gt;</A></H4>
<P>This directive specifies the path of a directory that contains individual <TERM>CA</TERM> certificates in separate files.  In addition, this directory must be specially managed using the OpenSSL <EM>rehash</EM> command. When using this feature, the OpenSSL library will attempt to locate certificate files based on a hash of their name and serial number. The OpenSSL <EM>rehash</EM> command is used to generate symbolic links with the hashed names that point to the actual certificate files. As such, this option can only be used with a filesystem that actually supports symbolic links. In general, it is simpler to use the <TT>TLSCACertificateFile</TT> directive instead.</P>
<H4><A NAME="TLSCertificateFile &lt;filename&gt;">16.2.1.3. TLSCertificateFile &lt;filename&gt;</A></H4>
<P>This directive specifies the file that contains the slapd server certificate. Certificates are generally public information and require no special protection.</P>
<H4><A NAME="TLSCertificateKeyFile &lt;filename&gt;">16.2.1.4. TLSCertificateKeyFile &lt;filename&gt;</A></H4>
<P>This directive specifies the file that contains the private key that matches the certificate stored in the <TT>TLSCertificateFile</TT> file. Private keys themselves are sensitive data and are usually password encrypted for protection. However, the current implementation doesn't support encrypted keys so the key must not be encrypted and the file itself must be protected carefully.</P>
<H4><A NAME="TLSCipherSuite &lt;cipher-suite-spec&gt;">16.2.1.5. TLSCipherSuite &lt;cipher-suite-spec&gt;</A></H4>
<P>This directive configures what ciphers will be accepted and the preference order. <TT>&lt;cipher-suite-spec&gt;</TT> should be a cipher specification for OpenSSL. You can use the command</P>
<PRE>
        openssl ciphers -v ALL
</PRE>
<P>to obtain a verbose list of available cipher specifications.</P>
<P>Besides the individual cipher names, the specifiers <TT>HIGH</TT>, <TT>MEDIUM</TT>, <TT>LOW</TT>, <TT>EXPORT</TT>, and <TT>EXPORT40</TT> may be helpful, along with <TT>TLSv1</TT>, <TT>SSLv3</TT>, and <TT>SSLv2</TT>.</P>
<P>To obtain the list of ciphers in GnuTLS use:</P>
<PRE>
        gnutls-cli -l
</PRE>
<H4><A NAME="TLSRandFile &lt;filename&gt;">16.2.1.6. TLSRandFile &lt;filename&gt;</A></H4>
<P>This directive specifies the file to obtain random bits from when <TT>/dev/urandom</TT> is not available. If the system provides <TT>/dev/urandom</TT> then this option is not needed, otherwise a source of random data must be configured.  Some systems (e.g. Linux) provide <TT>/dev/urandom</TT> by default, while others (e.g. Solaris) require the installation of a patch to provide it, and others may not support it at all. In the latter case, EGD or PRNGD should be installed, and this directive should specify the name of the EGD/PRNGD socket. The environment variable <TT>RANDFILE</TT> can also be used to specify the filename. Also, in the absence of these options, the <TT>.rnd</TT> file in the slapd user's home directory may be used if it exists. To use the <TT>.rnd</TT> file, just create the file and copy a few hundred bytes of arbitrary data into the file. The file is only used to provide a seed for the pseudo-random number generator, and it doesn't need very much data to work.</P>
<P>This directive is ignored with GnuTLS.</P>
<H4><A NAME="TLSDHParamFile &lt;filename&gt;">16.2.1.7. TLSDHParamFile &lt;filename&gt;</A></H4>
<P>This directive specifies the file that contains parameters for Diffie-Hellman ephemeral key exchange.  This is required in order to use DHE-based cipher suites, including all DSA-based suites (i.e. <TT>TLSCertificateKeyFile</TT> points to a DSA key), and RSA when the 'key encipherment' key usage is not specified in the certificate.  Parameters can be generated using the following command</P>
<PRE>
        openssl dhparam [-dsaparam] -out &lt;filename&gt; &lt;numbits&gt; or
        certtool --generate-dh-params --bits &lt;numbits&gt; --outfile &lt;filename&gt;
</PRE>
<H4><A NAME="TLSECName &lt;name&gt;">16.2.1.8. TLSECName &lt;name&gt;</A></H4>
<P>This directive specifies the curve to use for Elliptic Curve Diffie-Hellman ephemeral key exchange.  This is required in order to use ECDHE-based cipher suites in OpenSSL.  The names of supported curves may be shown using the following command</P>
<PRE>
        openssl ecparam -list_curves
</PRE>
<P>This directive is not used for GnuTLS. For GnuTLS the curves may be specified in the ciphersuite.</P>
<H4><A NAME="TLSVerifyClient { never | allow | try | demand }">16.2.1.9. TLSVerifyClient { never | allow | try | demand }</A></H4>
<P>This directive specifies what checks to perform on client certificates in an incoming TLS session, if any. This option is set to <TT>never</TT> by default, in which case the server never asks the client for a certificate. With a setting of <TT>allow</TT> the server will ask for a client certificate; if none is provided the session proceeds normally. If a certificate is provided but the server is unable to verify it, the certificate is ignored and the session proceeds normally, as if no certificate had been provided. With a setting of <TT>try</TT> the certificate is requested, and if none is provided, the session proceeds normally. If a certificate is provided and it cannot be verified, the session is immediately terminated. With a setting of <TT>demand</TT> the certificate is requested and a valid certificate must be provided, otherwise the session is immediately terminated.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>The server must request a client certificate in order to use the SASL EXTERNAL authentication mechanism with a TLS session. As such, a non-default <TT>TLSVerifyClient</TT> setting must be configured before SASL EXTERNAL authentication may be attempted, and the SASL EXTERNAL mechanism will only be offered to the client if a valid client certificate was received.
<HR WIDTH="80%" ALIGN="Left"></P>
<H3><A NAME="Client Configuration">16.2.2. Client Configuration</A></H3>
<P>Most of the client configuration directives parallel the server directives. The names of the directives are different, and they go into <EM>ldap.conf</EM>(5) instead of <EM>slapd.conf</EM>(5), but their functionality is mostly the same. Also, while most of these options may be configured on a system-wide basis, they may all be overridden by individual users in their <EM>.ldaprc</EM> files.</P>
<P>The LDAP Start TLS operation is used in LDAP to initiate TLS negotiation.  All OpenLDAP command line tools support a <TT>-Z</TT> and <TT>-ZZ</TT> flag to indicate whether a Start TLS operation is to be issued.  The latter flag indicates that the tool is to cease processing if TLS cannot be started while the former allows the command to continue.</P>
<P>In LDAPv2 environments, TLS is normally started using the LDAP Secure URI scheme (<TT>ldaps://</TT>) instead of the normal LDAP URI scheme (<TT>ldap://</TT>).  OpenLDAP command line tools allow either scheme to used with the <TT>-H</TT> flag and with the <TT>URI</TT> <EM>ldap.conf</EM>(5) option.</P>
<H4><A NAME="TLS_CACERT &lt;filename&gt;">16.2.2.1. TLS_CACERT &lt;filename&gt;</A></H4>
<P>This is equivalent to the server's <TT>TLSCACertificateFile</TT> option. As noted in the <A HREF="#TLS Configuration">TLS Configuration</A> section, a client typically may need to know about more CAs than a server, but otherwise the same considerations apply.</P>
<H4><A NAME="TLS_CACERTDIR &lt;path&gt;">16.2.2.2. TLS_CACERTDIR &lt;path&gt;</A></H4>
<P>This is equivalent to the server's <TT>TLSCACertificatePath</TT> option. The specified directory must be managed with the OpenSSL <EM>rehash</EM> command as well.</P>
<H4><A NAME="TLS_CERT &lt;filename&gt;">16.2.2.3. TLS_CERT &lt;filename&gt;</A></H4>
<P>This directive specifies the file that contains the client certificate. This is a user-only directive and can only be specified in a user's <EM>.ldaprc</EM> file.</P>
<H4><A NAME="TLS_KEY &lt;filename&gt;">16.2.2.4. TLS_KEY &lt;filename&gt;</A></H4>
<P>This directive specifies the file that contains the private key that matches the certificate stored in the <TT>TLS_CERT</TT> file. The same constraints mentioned for <TT>TLSCertificateKeyFile</TT> apply here. This is also a user-only directive.</P>
<H4><A NAME="TLS_RANDFILE &lt;filename&gt;">16.2.2.5. TLS_RANDFILE &lt;filename&gt;</A></H4>
<P>This directive is the same as the server's <TT>TLSRandFile</TT> option.</P>
<H4><A NAME="TLS_REQCERT { never | allow | try | demand }">16.2.2.6. TLS_REQCERT { never | allow | try | demand }</A></H4>
<P>This directive is equivalent to the server's <TT>TLSVerifyClient</TT> option. However, for clients the default value is <TT>demand</TT> and there generally is no good reason to change this setting.</P>
<P></P>
<HR>
<H1><A NAME="Constructing a Distributed Directory Service">17. Constructing a Distributed Directory Service</A></H1>
<P>For many sites, running one or more <EM>slapd</EM>(8) that hold an entire subtree of data is sufficient. But often it is desirable to have one <EM>slapd</EM> refer to other directory services for a certain part of the tree (which may or may not be running <EM>slapd</EM>).</P>
<P><EM>slapd</EM> supports <EM>subordinate</EM> and <EM>superior</EM> knowledge information. Subordinate knowledge information is held in <TT>referral</TT> objects (<A HREF="https://www.rfc-editor.org/rfc/rfc3296.txt">RFC3296</A>).</P>
<H2><A NAME="Subordinate Knowledge Information">17.1. Subordinate Knowledge Information</A></H2>
<P>Subordinate knowledge information may be provided to delegate a subtree. Subordinate knowledge information is maintained in the directory as a special <EM>referral</EM> object at the delegate point. The referral object acts as a delegation point, gluing two services together. This mechanism allows for hierarchical directory services to be constructed.</P>
<P>A referral object has a structural object class of <TT>referral</TT> and has the same <TERM>Distinguished Name</TERM> as the delegated subtree.  Generally, the referral object will also provide the auxiliary object class <TT>extensibleObject</TT>. This allows the entry to contain appropriate <TERM>Relative Distinguished Name</TERM> values.  This is best demonstrated by example.</P>
<P>If the server <TT>a.example.net</TT> holds <TT>dc=example,dc=net</TT> and wished to delegate the subtree <TT>ou=subtree,dc=example,dc=net</TT> to another server <TT>b.example.net</TT>, the following named referral object would be added to <TT>a.example.net</TT>:</P>
<PRE>
        dn: dc=subtree,dc=example,dc=net
        objectClass: referral
        objectClass: extensibleObject
        dc: subtree
        ref: ldap://b.example.net/dc=subtree,dc=example,dc=net
</PRE>
<P>The server uses this information to generate referrals and search continuations to subordinate servers.</P>
<P>For those familiar with <TERM>X.500</TERM>, a <EM>named referral</EM> object is similar to an X.500 knowledge reference held in a <EM>subr</EM> <TERM>DSE</TERM>.</P>
<H2><A NAME="Superior Knowledge Information">17.2. Superior Knowledge Information</A></H2>
<P>Superior knowledge information may be specified using the <TT>referral</TT> directive.  The value is a list of <TERM>URI</TERM>s referring to superior directory services.  For servers without immediate superiors, such as for <TT>a.example.net</TT> in the example above, the server can be configured to use a directory service with <EM>global knowledge</EM>, such as the <EM>OpenLDAP Root Service</EM> (<A HREF="http://www.openldap.org/faq/index.cgi?file=393">http://www.openldap.org/faq/index.cgi?file=393</A>).</P>
<PRE>
        referral        ldap://root.openldap.org/
</PRE>
<P>However, as <TT>a.example.net</TT> is the <EM>immediate superior</EM> to <TT>b.example.net</TT>, <EM>b.example.net</EM> would be configured as follows:</P>
<PRE>
        referral        ldap://a.example.net/
</PRE>
<P>The server uses this information to generate referrals for operations acting upon entries not within or subordinate to any of the naming contexts held by the server.</P>
<P>For those familiar with <TERM>X.500</TERM>, this use of the <TT>ref</TT> attribute is similar to an X.500 knowledge reference held in a <EM>Supr</EM> <TERM>DSE</TERM>.</P>
<H2><A NAME="The ManageDsaIT Control">17.3. The ManageDsaIT Control</A></H2>
<P>Adding, modifying, and deleting referral objects is generally done using <EM>ldapmodify</EM>(1) or similar tools which support the ManageDsaIT control.  The ManageDsaIT control informs the server that you intend to manage the referral object as a regular entry.  This keeps the server from sending a referral result for requests which interrogate or update referral objects.</P>
<P>The ManageDsaIT control should not be specified when managing regular entries.</P>
<P>The <TT>-M</TT> option of <EM>ldapmodify</EM>(1) (and other tools) enables ManageDsaIT.  For example:</P>
<PRE>
        ldapmodify -M -f referral.ldif -x -D &quot;cn=Manager,dc=example,dc=net&quot; -W
</PRE>
<P>or with <EM>ldapsearch</EM>(1):</P>
<PRE>
        ldapsearch -M -b &quot;dc=example,dc=net&quot; -x &quot;(objectclass=referral)&quot; '*' ref
</PRE>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>the <TT>ref</TT> attribute is operational and must be explicitly requested when desired in search results.
<HR WIDTH="80%" ALIGN="Left"></P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>the use of referrals to construct a Distributed Directory Service is extremely clumsy and not well supported by common clients. If an existing installation has already been built using referrals, the use of the <EM>chain</EM> overlay to hide the referrals will greatly improve the usability of the Directory system. A better approach would be to use explicitly defined local and proxy databases in <EM>subordinate</EM> configurations to provide a seamless view of the Distributed Directory.
<HR WIDTH="80%" ALIGN="Left"></P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>LDAP operations, even subtree searches, normally access only one database. That can be changed by gluing databases together with the <B>subordinate</B>/<B>olcSubordinate</B> keyword. Please see <EM>slapd.conf</EM>(5) and <EM>slapd-config</EM>(5).
<HR WIDTH="80%" ALIGN="Left"></P>
<P></P>
<HR>
<H1><A NAME="Replication">18. Replication</A></H1>
<P>Replicated directories are a fundamental requirement for delivering a resilient enterprise deployment.</P>
<P><A HREF="https://www.openldap.org/">OpenLDAP</A> has various configuration options for creating a replicated directory. In previous releases, replication was discussed in terms of a <EM>master</EM> server and some number of <EM>slave</EM> servers. A master accepted directory updates from other clients, and a slave only accepted updates from a (single) master. The replication structure was rigidly defined and any particular database could only fulfill a single role, either master or slave. Another historic term introduced with OpenLDAP 2.4 was multimaster.</P>
<P>As OpenLDAP now supports a wide variety of replication topologies, these terms have been deprecated in favor of <EM>provider</EM>/<EM>multi-provider</EM> and <EM>consumer</EM>: A provider can accept external write operations and make them available for retrieval by consumers; consumers request replication updates from providers. Unlike the rigidly defined master/slave relationships, provider/consumer roles are quite fluid: replication updates received in a consumer can be further propagated by that consumer to other servers, so a consumer can also act simultaneously as a provider. Also, a consumer need not be an actual LDAP server; it may be just an LDAP client.</P>
<P>The following sections will describe the replication technology and discuss the various replication options that are available.</P>
<H2><A NAME="Replication Technology">18.1. Replication Technology</A></H2>
<H3><A NAME="LDAP Sync Replication">18.1.1. LDAP Sync Replication</A></H3>
<P>The <TERM>LDAP Sync</TERM> Replication engine, <TERM>syncrepl</TERM> for short, is a consumer-side replication engine that enables the consumer <TERM>LDAP</TERM> server to maintain a shadow copy of a <TERM>DIT</TERM> fragment. A syncrepl engine resides at the consumer and executes as one of the <EM>slapd</EM>(8) threads. It creates and maintains a replica by connecting to the replication provider to perform the initial DIT content load followed either by periodic content polling or by timely updates upon content changes.</P>
<P>Syncrepl uses the LDAP Content Synchronization protocol (or LDAP Sync for short) as the consumer synchronization protocol.  LDAP Sync provides a stateful replication which supports both pull-based and push-based synchronization and does not mandate the use of a history store. In pull-based replication the consumer periodically polls the provider for updates. In push-based replication the consumer listens for updates that are sent by the provider in realtime. Since the protocol does not require a history store, the provider does not need to maintain any log of updates it has received (Note that the syncrepl engine is extensible and additional replication protocols may be supported in the future.).</P>
<P>Syncrepl keeps track of the status of the replication content by maintaining and exchanging synchronization cookies. Because the syncrepl consumer and provider maintain their content status, the consumer can poll the provider content to perform incremental synchronization by asking for the entries required to make the consumer up-to-date with the provider content. Syncrepl also enables convenient management of consumers by maintaining replication status.  The consumer database can be constructed from a consumer-side or a provider-side backup at any synchronization status. Syncrepl can automatically resynchronize the consumer database to be up-to-date with the current provider content.</P>
<P>Syncrepl supports both pull-based and push-based synchronization. In its basic refreshOnly synchronization mode, the provider uses pull-based synchronization where the consumer servers need not be tracked and no history information is maintained.  The information required for the provider to process periodic polling requests is contained in the synchronization cookie of the request itself.  To optimize the pull-based synchronization, syncrepl utilizes the present phase of the LDAP Sync protocol as well as its delete phase, instead of falling back on frequent full reloads. To further optimize the pull-based synchronization, the provider can maintain a per-scope session log as a history store. In its refreshAndPersist mode of synchronization, the provider uses a push-based synchronization. The provider keeps track of the consumer servers that have requested a persistent search and sends them necessary updates as the provider replication content gets modified.</P>
<P>With syncrepl, a consumer can create a replication agreement without changing the provider's configurations and without restarting the provider server, if the consumer server has appropriate access privileges for the DIT fragment to be replicated. The consumer server can stop the replication also without the need for provider-side changes and restart.</P>
<P>Syncrepl supports partial, sparse, and fractional replications.  The shadow DIT fragment is defined by a general search criteria consisting of base, scope, filter, and attribute list.  The consumer content is also subject to the access privileges of the bind identity of the syncrepl replication connection.</P>
<H4><A NAME="The LDAP Content Synchronization Protocol">18.1.1.1. The LDAP Content Synchronization Protocol</A></H4>
<P>The LDAP Sync protocol allows a client to maintain a synchronized copy of a DIT fragment. The LDAP Sync operation is defined as a set of controls and other protocol elements which extend the LDAP search operation. This section introduces the LDAP Content Sync protocol only briefly.  For more information, refer to <A HREF="https://www.rfc-editor.org/rfc/rfc4533.txt">RFC4533</A>.</P>
<P>The LDAP Sync protocol supports both polling and listening for changes by defining two respective synchronization operations: <EM>refreshOnly</EM> and <EM>refreshAndPersist</EM>.  Polling is implemented by the <EM>refreshOnly</EM> operation. The consumer polls the provider using an LDAP Search request with an LDAP Sync control attached. The consumer copy is synchronized to the provider copy at the time of polling using the information returned in the search.  The provider finishes the search operation by returning <EM>SearchResultDone</EM> at the end of the search operation as in the normal search.  Listening is implemented by the <EM>refreshAndPersist</EM> operation. As the name implies, it begins with a search, like refreshOnly. Instead of finishing the search after returning all entries currently matching the search criteria, the synchronization search remains persistent in the provider. Subsequent updates to the synchronization content in the provider cause additional entry updates to be sent to the consumer.</P>
<P>The <EM>refreshOnly</EM> operation and the refresh stage of the <EM>refreshAndPersist</EM> operation can be performed with a present phase or a delete phase.</P>
<P>In the present phase, the provider sends the consumer the entries updated within the search scope since the last synchronization. The provider sends all requested attributes, be they changed or not, of the updated entries.  For each unchanged entry which remains in the scope, the provider sends a present message consisting only of the name of the entry and the synchronization control representing state present. The present message does not contain any attributes of the entry. After the consumer receives all update and present entries, it can reliably determine the new consumer copy by adding the entries added to the provider, by replacing the entries modified at the provider, and by deleting entries in the consumer copy which have not been updated nor specified as being present at the provider.</P>
<P>The transmission of the updated entries in the delete phase is the same as in the present phase. The provider sends all the requested attributes of the entries updated within the search scope since the last synchronization to the consumer. In the delete phase, however, the provider sends a delete message for each entry deleted from the search scope, instead of sending present messages.  The delete message consists only of the name of the entry and the synchronization control representing state delete.  The new consumer copy can be determined by adding, modifying, and removing entries according to the synchronization control attached to the <EM>SearchResultEntry</EM> message.</P>
<P>In the case that the LDAP Sync provider maintains a history store and can determine which entries are scoped out of the consumer copy since the last synchronization time, the provider can use the delete phase. If the provider does not maintain any history store, cannot determine the scoped-out entries from the history store, or the history store does not cover the outdated synchronization state of the consumer, the provider should use the present phase.  The use of the present phase is much more efficient than a full content reload in terms of the synchronization traffic.  To reduce the synchronization traffic further, the LDAP Sync protocol also provides several optimizations such as the transmission of the normalized <TT>entryUUID</TT>s and the transmission of multiple <TT>entryUUIDs</TT> in a single <EM>syncIdSet</EM> message.</P>
<P>At the end of the <EM>refreshOnly</EM> synchronization, the provider sends a synchronization cookie to the consumer as a state indicator of the consumer copy after the synchronization is completed.  The consumer will present the received cookie when it requests the next incremental synchronization to the provider.</P>
<P>When <EM>refreshAndPersist</EM> synchronization is used, the provider sends a synchronization cookie at the end of the refresh stage by sending a Sync Info message with refreshDone=TRUE.  It also sends a synchronization cookie by attaching it to <EM>SearchResultEntry</EM> messages generated in the persist stage of the synchronization search. During the persist stage, the provider can also send a Sync Info message containing the synchronization cookie at any time the provider wants to update the consumer-side state indicator.</P>
<P>In the LDAP Sync protocol, entries are uniquely identified by the <TT>entryUUID</TT> attribute value. It can function as a reliable identifier of the entry. The DN of the entry, on the other hand, can be changed over time and hence cannot be considered as the reliable identifier.  The <TT>entryUUID</TT> is attached to each <EM>SearchResultEntry</EM> or <EM>SearchResultReference</EM> as a part of the synchronization control.</P>
<H4><A NAME="Syncrepl Details">18.1.1.2. Syncrepl Details</A></H4>
<P>The syncrepl engine utilizes both the <EM>refreshOnly</EM> and the <EM>refreshAndPersist</EM> operations of the LDAP Sync protocol.  If a syncrepl specification is included in a database definition, <EM>slapd</EM>(8) launches a syncrepl engine as a <EM>slapd</EM>(8) thread and schedules its execution. If the <EM>refreshOnly</EM> operation is specified, the syncrepl engine will be rescheduled at the interval time after a synchronization operation is completed.  If the <EM>refreshAndPersist</EM> operation is specified, the engine will remain active and process the persistent synchronization messages from the provider.</P>
<P>The syncrepl engine utilizes both the present phase and the delete phase of the refresh synchronization. It is possible to configure a session log in the provider which stores the <TT>entryUUID</TT>s of a finite number of entries deleted from a database. Multiple consumers share the same session log. The syncrepl engine uses the delete phase if the session log is present and the state of the consumer server is recent enough that no session log entries are truncated after the last synchronization of the client.  The syncrepl engine uses the present phase if no session log is configured for the replication content or if the consumer is too outdated to be covered by the session log.  The current design of the session log store is memory based, so the information contained in the session log is not persistent over multiple provider invocations. It is not currently supported to access the session log store by using LDAP operations. It is also not currently supported to impose access control to the session log.</P>
<P>As a further optimization, even in the case the synchronization search is not associated with any session log, no entries will be transmitted to the consumer server when there has been no update in the replication context.</P>
<P>The syncrepl engine, which is a consumer-side replication engine, can work with any backends. The LDAP Sync provider can be configured as an overlay on any backend, but works best with the <EM>back-mdb</EM> backend.</P>
<P>The LDAP Sync provider maintains a <TT>contextCSN</TT> for each database as the current synchronization state indicator of the provider content.  It is the largest <TT>entryCSN</TT> in the provider context such that no transactions for an entry having smaller <TT>entryCSN</TT> value remains outstanding.  The <TT>contextCSN</TT> could not just be set to the largest issued <TT>entryCSN</TT> because <TT>entryCSN</TT> is obtained before a transaction starts and transactions are not committed in the issue order.</P>
<P>The provider stores the <TT>contextCSN</TT> of a context in the <TT>contextCSN</TT> attribute of the context suffix entry. The attribute is not written to the database after every update operation though; instead it is maintained primarily in memory. At database start time the provider reads the last saved <TT>contextCSN</TT> into memory and uses the in-memory copy exclusively thereafter. By default, changes to the <TT>contextCSN</TT> as a result of database updates will not be written to the database until the server is cleanly shut down. A checkpoint facility exists to cause the <TT>contextCSN</TT> to be written out more frequently if desired.</P>
<P>Note that at startup time, if the provider is unable to read a <TT>contextCSN</TT> from the suffix entry, it will scan the entire database to determine the value, and this scan may take quite a long time on a large database. When a <TT>contextCSN</TT> value is read, the database will still be scanned for any <TT>entryCSN</TT> values greater than it, to make sure the <TT>contextCSN</TT> value truly reflects the greatest committed <TT>entryCSN</TT> in the database. On databases which support inequality indexing, setting an eq index on the <TT>entryCSN</TT> attribute and configuring <EM>contextCSN</EM> checkpoints will greatly speed up this scanning step.</P>
<P>If no <TT>contextCSN</TT> can be determined by reading and scanning the database, a new value will be generated. Also, if scanning the database yielded a greater <TT>entryCSN</TT> than was previously recorded in the suffix entry's <TT>contextCSN</TT> attribute, a checkpoint will be immediately written with the new value.</P>
<P>The consumer also stores its replication state, which is the provider's <TT>contextCSN</TT> received as a synchronization cookie, in the <TT>contextCSN</TT> attribute of the suffix entry.  The replication state maintained by a consumer server is used as the synchronization state indicator when it performs subsequent incremental synchronization with the provider server. It is also used as a provider-side synchronization state indicator when it functions as a secondary provider server in a cascading replication configuration.  Since the consumer and provider state information are maintained in the same location within their respective databases, any consumer can be promoted to a provider (and vice versa) without any special actions.</P>
<P>Because a general search filter can be used in the syncrepl specification, some entries in the context may be omitted from the synchronization content.  The syncrepl engine creates a glue entry to fill in the holes in the consumer context if any part of the consumer content is subordinate to the holes. The glue entries will not be returned in the search result unless <EM>ManageDsaIT</EM> control is provided.</P>
<P>Also as a consequence of the search filter used in the syncrepl specification, it is possible for a modification to remove an entry from the replication scope even though the entry has not been deleted on the provider. Logically the entry must be deleted on the consumer but in <EM>refreshOnly</EM> mode the provider cannot detect and propagate this change without the use of the session log on the provider.</P>
<P>For configuration, please see the <A HREF="#Syncrepl">Syncrepl</A> section.</P>
<H2><A NAME="Deployment Alternatives">18.2. Deployment Alternatives</A></H2>
<P>While the LDAP Sync specification only defines a narrow scope for replication, the OpenLDAP implementation is extremely flexible and supports a variety of operating modes to handle other scenarios not explicitly addressed in the spec.</P>
<H3><A NAME="Delta-syncrepl replication">18.2.1. Delta-syncrepl replication</A></H3>
<UL>
<LI>Disadvantages of LDAP Sync replication:</UL>
<P>LDAP Sync replication is an object-based replication mechanism. When any attribute value in a replicated object is changed on the provider, each consumer fetches and processes the complete changed object, including <B>both the changed and unchanged attribute values</B> during replication. One advantage of this approach is that when multiple changes occur to a single object, the precise sequence of those changes need not be preserved; only the final state of the entry is significant. But this approach may have drawbacks when the usage pattern involves single changes to multiple objects.</P>
<P>For example, suppose you have a database consisting of 102,400 objects of 1 KB each. Further, suppose you routinely run a batch job to change the value of a single two-byte attribute value that appears in each of the 102,400 objects on the provider. Not counting LDAP and TCP/IP protocol overhead, each time you run this job each consumer will transfer and process <B>100 MB</B> of data to process <B>200KB of changes!</B></P>
<P>99.98% of the data that is transmitted and processed in a case like this will be redundant, since it represents values that did not change. This is a waste of valuable transmission and processing bandwidth and can cause an unacceptable replication backlog to develop. While this situation is extreme, it serves to demonstrate a very real problem that is encountered in some LDAP deployments.</P>
<UL>
<LI>Where Delta-syncrepl comes in:</UL>
<P>Delta-syncrepl, a changelog-based variant of syncrepl, is designed to address situations like the one described above. Delta-syncrepl works by maintaining a changelog of a selectable depth in a separate database on the provider. The replication consumer checks the changelog for the changes it needs and, as long as the changelog contains the needed changes, the consumer fetches the changes from the changelog and applies them to its database. If, however, a consumer is too far out of sync (or completely empty), conventional syncrepl is used to bring it up to date and replication then switches back to the delta-syncrepl mode.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>since the database state is stored in both the changelog DB and the main DB on the provider, it is important to backup/restore both the changelog DB and the main DB using slapcat/slapadd when restoring a DB or copying it to another machine.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>For configuration, please see the <A HREF="#Delta-syncrepl">Delta-syncrepl</A> section.</P>
<H3><A NAME="N-Way Multi-Provider Replication">18.2.2. N-Way Multi-Provider Replication</A></H3>
<P>Multi-Provider replication is a replication technique using Syncrepl to replicate data to multiple provider (&quot;Provider&quot;) Directory servers.</P>
<H4><A NAME="Valid Arguments for Multi-Provider replication">18.2.2.1. Valid Arguments for Multi-Provider replication</A></H4>
<UL>
<LI>If any provider fails, other providers will continue to accept updates
<LI>Avoids a single point of failure
<LI>Providers can be located in several physical sites i.e. distributed across the network/globe.
<LI>Good for Automatic failover/High Availability</UL>
<H4><A NAME="Invalid Arguments for Multi-Provider replication">18.2.2.2. Invalid Arguments for Multi-Provider replication</A></H4>
<P>(These are often claimed to be advantages of Multi-Provider replication but those claims are false):</P>
<UL>
<LI>It has <B>NOTHING</B> to do with load balancing
<LI>Providers <B>must</B> propagate writes to <B>all</B> the other servers, which means the network traffic and write load spreads across all of the servers the same as for single-provider.
<LI>Server utilization and performance are at best identical for Multi-Provider and Single-Provider replication; at worst Single-Provider is superior because indexing can be tuned differently to optimize for the different usage patterns between the provider and the consumers.</UL>
<H4><A NAME="Arguments against Multi-Provider replication">18.2.2.3. Arguments against Multi-Provider replication</A></H4>
<UL>
<LI>Breaks the data consistency guarantees of the directory model
<LI><A HREF="http://www.openldap.org/faq/data/cache/1240.html">http://www.openldap.org/faq/data/cache/1240.html</A>
<LI>If connectivity with a provider is lost because of a network partition, then &quot;automatic failover&quot; can just compound the problem
<LI>Typically, a particular machine cannot distinguish between losing contact with a peer because that peer crashed, or because the network link has failed
<LI>If a network is partitioned and multiple clients start writing to each of the &quot;providers&quot; then reconciliation will be a pain; it may be best to simply deny writes to the clients that are partitioned from the single provider</UL>
<P>For configuration, please see the <A HREF="#N-Way Multi-Provider">N-Way Multi-Provider</A> section below</P>
<H3><A NAME="Mirror mode replication">18.2.3. Mirror mode replication</A></H3>
<P>Mirror mode is a hybrid configuration that provides all of the consistency guarantees of single-provider replication, while also providing the high availability of multi-provider. In Mirror mode two providers are set up to replicate from each other (as a multi-provider configuration), but an external frontend is employed to direct all writes to only one of the two servers. The second provider will only be used for writes if the first provider crashes, at which point the frontend will switch to directing all writes to the second provider. When a crashed provider is repaired and restarted it will automatically catch up to any changes on the running provider and resync.</P>
<H4><A NAME="Arguments for Mirror mode">18.2.3.1. Arguments for Mirror mode</A></H4>
<UL>
<LI>Provides a high-availability (HA) solution for directory writes (replicas handle reads)
<LI>As long as one provider is operational, writes can safely be accepted
<LI>Provider nodes replicate from each other, so they are always up to date and can be ready to take over (hot standby)
<LI>Syncrepl also allows the provider nodes to re-synchronize after any downtime</UL>
<H4><A NAME="Arguments against Mirror mode">18.2.3.2. Arguments against Mirror mode</A></H4>
<UL>
<LI>Mirror mode is not what is termed as a Multi-Provider solution. This is because writes have to go to just one of the mirror nodes at a time
<LI>Mirror mode can be termed as Active-Active Hot-Standby, therefore an external server (slapd in proxy mode) or device (hardware load balancer) is needed to manage which provider is currently active
<LI>Backups are managed slightly differently</UL>
<P>For configuration, please see the <A HREF="#Mirror mode">Mirror mode</A> section below</P>
<H3><A NAME="Syncrepl Proxy Mode">18.2.4. Syncrepl Proxy Mode</A></H3>
<P>While the LDAP Sync protocol supports both pull- and push-based replication, the push mode (refreshAndPersist) must still be initiated from the consumer before the provider can begin pushing changes. In some network configurations, particularly where firewalls restrict the direction in which connections can be made, a provider-initiated push mode may be needed.</P>
<P>This mode can be configured with the aid of the LDAP Backend (<A HREF="#Backends">Backends</A> and <EM>slapd-ldap(8)</EM>). Instead of running the syncrepl engine on the actual consumer, a slapd-ldap proxy is set up near (or collocated with) the provider that points to the consumer, and the syncrepl engine runs on the proxy.</P>
<P>For configuration, please see the <A HREF="#Syncrepl Proxy">Syncrepl Proxy</A> section.</P>
<H2><A NAME="Configuring the different replication types">18.3. Configuring the different replication types</A></H2>
<H3><A NAME="Syncrepl">18.3.1. Syncrepl</A></H3>
<H4><A NAME="Syncrepl configuration">18.3.1.1. Syncrepl configuration</A></H4>
<P>Because syncrepl is a consumer-side replication engine, the syncrepl specification is defined in <EM>slapd.conf</EM>(5) of the consumer server, not in the provider server's configuration file.  The initial loading of the consumer content can be performed either by starting the syncrepl engine with no synchronization cookie or by populating the consumer by loading an <TERM>LDIF</TERM> file dumped as a backup at the provider.</P>
<P>When loading from a backup, it is not required to perform the initial loading from the up-to-date backup of the provider content. The syncrepl engine will automatically synchronize the initial consumer to the current provider content. As a result, it is not required to stop the provider server in order to avoid the replication inconsistency caused by the updates to the provider content during the content backup and loading process.</P>
<P>When replicating a large scale directory, especially in a bandwidth constrained environment, it is advised to load the consumer from a backup instead of performing a full initial load using syncrepl.</P>
<H4><A NAME="Set up the provider slapd">18.3.1.2. Set up the provider slapd</A></H4>
<P>The provider is implemented as an overlay, so the overlay itself must first be configured in <EM>slapd.conf</EM>(5) before it can be used. The provider has two primary configuration directives and two secondary directives for when delta-syncrepl is being used. Because the LDAP Sync search is subject to access control, proper access control privileges should be set up for the replicated content.</P>
<P>The two primary options to configure are the checkpoint and sessionlog behaviors.</P>
<P>The <TT>contextCSN</TT> checkpoint is configured by the</P>
<PRE>
        syncprov-checkpoint &lt;ops&gt; &lt;minutes&gt;
</PRE>
<P>directive. Checkpoints are only tested after successful write operations. If <EM>&lt;ops&gt;</EM> operations or more than <EM>&lt;minutes&gt;</EM> time has passed since the last checkpoint, a new checkpoint is performed. Checkpointing is disabled by default.</P>
<P>The session log is configured by the</P>
<PRE>
        syncprov-sessionlog &lt;ops&gt;
</PRE>
<P>directive, where <EM>&lt;ops&gt;</EM> is the maximum number of session log entries the session log can record. All write operations (except Adds) are recorded in the log.</P>
<P>Note that using the session log requires searching on the <EM>entryUUID</EM> attribute. Setting an eq index on this attribute will greatly benefit the performance of the session log on the provider.</P>
<P>The reloadhint option is configured by the</P>
<PRE>
        syncprov-reloadhint &lt;TRUE|FALSE&gt;
</PRE>
<P>directive. It must be set TRUE when using the accesslog overlay for delta-based syncrepl replication support. The default is FALSE.</P>
<P>The nonpresent option should only be configured if the overlay is being placed on top of a log database, such as when used with delta-syncrepl.</P>
<P>The nonpresent option is configured by the</P>
<PRE>
        syncprov-nopresent &lt;TRUE|FALSE&gt;
</PRE>
<P>directive. This value should only be set TRUE for a syncprov instance on top of a log database (such as one managed by the accesslog overlay). The default is FALSE.</P>
<P>A more complete example of the <EM>slapd.conf</EM>(5) content is thus:</P>
<PRE>
        database mdb
        maxsize 1073741824
        suffix dc=Example,dc=com
        rootdn dc=Example,dc=com
        directory /var/ldap/db
        index objectclass,entryCSN,entryUUID eq

        overlay syncprov
        syncprov-checkpoint 100 10
        syncprov-sessionlog 100
</PRE>
<H4><A NAME="Set up the consumer slapd">18.3.1.3. Set up the consumer slapd</A></H4>
<P>The syncrepl directive is specified in the database section of <EM>slapd.conf</EM>(5) for the consumer context. The syncrepl engine is backend independent and the directive can be defined with any database type.</P>
<PRE>
        database mdb
        maxsize 1073741824
        suffix dc=Example,dc=com
        rootdn dc=Example,dc=com
        directory /var/ldap/db
        index objectclass,entryCSN,entryUUID eq

        syncrepl rid=123
                provider=ldap://provider.example.com:389
                type=refreshOnly
                interval=01:00:00:00
                searchbase=&quot;dc=example,dc=com&quot;
                filter=&quot;(objectClass=organizationalPerson)&quot;
                scope=sub
                attrs=&quot;cn,sn,ou,telephoneNumber,title,l&quot;
                schemachecking=off
                bindmethod=simple
                binddn=&quot;cn=syncuser,dc=example,dc=com&quot;
                credentials=secret
</PRE>
<P>In this example, the consumer will connect to the provider <EM>slapd</EM>(8) at port 389 of <A HREF="ldap://provider.example.com">ldap://provider.example.com</A> to perform a polling (<EM>refreshOnly</EM>) mode of synchronization once a day.  It will bind as <TT>cn=syncuser,dc=example,dc=com</TT> using simple authentication with password &quot;secret&quot;.  Note that the access control privilege of <TT>cn=syncuser,dc=example,dc=com</TT> should be set appropriately in the provider to retrieve the desired replication content. Also the search limits must be high enough on the provider to allow the syncuser to retrieve a complete copy of the requested content.  The consumer uses the rootdn to write to its database so it always has full permissions to write all content.</P>
<P>The synchronization search in the above example will search for the entries whose objectClass is organizationalPerson in the entire subtree rooted at <TT>dc=example,dc=com</TT>. The requested attributes are <TT>cn</TT>, <TT>sn</TT>, <TT>ou</TT>, <TT>telephoneNumber</TT>, <TT>title</TT>, and <TT>l</TT>. The schema checking is turned off, so that the consumer <EM>slapd</EM>(8) will not enforce entry schema checking when it processes updates from the provider <EM>slapd</EM>(8).</P>
<P>For more detailed information on the syncrepl directive, see the <A HREF="#syncrepl">syncrepl</A> section of <A HREF="#The slapd Configuration File">The slapd Configuration File</A> chapter of this admin guide.</P>
<H4><A NAME="Start the provider and the consumer slapd">18.3.1.4. Start the provider and the consumer slapd</A></H4>
<P>The provider <EM>slapd</EM>(8) is not required to be restarted. <EM>contextCSN</EM> is automatically generated as needed: it might be originally contained in the <TERM>LDIF</TERM> file, generated by <EM>slapadd</EM> (8), generated upon changes in the context, or generated when the first LDAP Sync search arrives at the provider.  If an LDIF file is being loaded which did not previously contain the <EM>contextCSN</EM>, the <EM>-w</EM> option should be used with <EM>slapadd</EM> (8) to cause it to be generated. This will allow the server to startup a little quicker the first time it runs.</P>
<P>When starting a consumer <EM>slapd</EM>(8), it is possible to provide a synchronization cookie as the <EM>-c cookie</EM> command line option in order to start the synchronization from a specific state.  The cookie is a comma separated list of name=value pairs. Currently supported syncrepl cookie fields are <EM>csn=&lt;csn&gt;</EM> and <EM>rid=&lt;rid&gt;</EM>. <EM>&lt;csn&gt;</EM> represents the current synchronization state of the consumer. <EM>&lt;rid&gt;</EM> identifies a consumer locally within the consumer server. It is used to relate the cookie to the syncrepl definition in <EM>slapd.conf</EM>(5) which has the matching <EM>&lt;rid&gt;</EM>.  The <EM>&lt;rid&gt;</EM> must have no more than 3 decimal digits.  The command line cookie overrides the synchronization cookie stored in the consumer database.</P>
<H3><A NAME="Delta-syncrepl">18.3.2. Delta-syncrepl</A></H3>
<H4><A NAME="Delta-syncrepl Provider configuration">18.3.2.1. Delta-syncrepl Provider configuration</A></H4>
<P>Setting up delta-syncrepl requires configuration changes on both the provider and replica servers:</P>
<PRE>
     # Give the replicator DN unlimited read access.  This ACL needs to be
     # merged with other ACL statements, and/or moved within the scope
     # of a database.  The &quot;by * break&quot; portion causes evaluation of
     # subsequent rules.  See slapd.access(5) for details.
     access to *
        by dn.base=&quot;cn=replicator,dc=example,dc=com&quot; read
        by * break

     # Set the module path location
     modulepath /opt/symas/lib/openldap

     # Load the mdb backend
     moduleload back_mdb.la

     # Load the accesslog overlay
     moduleload accesslog.la

     #Load the syncprov overlay
     moduleload syncprov.la

     # Accesslog database definitions
     database mdb
     suffix cn=accesslog
     directory /db/accesslog
     rootdn cn=accesslog
     index default eq
     index entryCSN,objectClass,reqEnd,reqResult,reqStart,reqDN

     overlay syncprov
     syncprov-nopresent TRUE
     syncprov-reloadhint TRUE

     # Let the replicator DN have limitless searches
     limits dn.exact=&quot;cn=replicator,dc=example,dc=com&quot; time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

     # Primary database definitions
     database mdb
     suffix &quot;dc=symas,dc=com&quot;
     rootdn &quot;cn=manager,dc=symas,dc=com&quot;

     ## Whatever other configuration options are desired

     # syncprov specific indexing
     index entryCSN eq
     index entryUUID eq

     # syncrepl Provider for primary db
     overlay syncprov
     syncprov-checkpoint 1000 60

     # accesslog overlay definitions for primary db
     overlay accesslog
     logdb cn=accesslog
     logops writes
     logsuccess TRUE
     # scan the accesslog DB every day, and purge entries older than 7 days
     logpurge 07+00:00 01+00:00

     # Let the replicator DN have limitless searches
     limits dn.exact=&quot;cn=replicator,dc=example,dc=com&quot; time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
</PRE>
<P>For more information, always consult the relevant man pages (<EM>slapo-accesslog</EM>(5) and <EM>slapd.conf</EM>(5))</P>
<H4><A NAME="Delta-syncrepl Consumer configuration">18.3.2.2. Delta-syncrepl Consumer configuration</A></H4>
<PRE>
     # Replica database configuration
     database mdb
     suffix &quot;dc=symas,dc=com&quot;
     rootdn &quot;cn=manager,dc=symas,dc=com&quot;

     ## Whatever other configuration bits for the replica, like indexing
     ## that you want

     # syncrepl specific indices
     index entryUUID eq

     # syncrepl directives
     syncrepl  rid=0
               provider=ldap://ldapprovider.example.com:389
               bindmethod=simple
               binddn=&quot;cn=replicator,dc=example,dc=com&quot;
               credentials=secret
               searchbase=&quot;dc=example,dc=com&quot;
               logbase=&quot;cn=accesslog&quot;
               logfilter=&quot;(&amp;(objectClass=auditWriteObject)(reqResult=0))&quot;
               schemachecking=on
               type=refreshAndPersist
               retry=&quot;60 +&quot;
               syncdata=accesslog

     # Refer updates to the provider
     updateref               ldap://ldapprovider.example.com
</PRE>
<P>The above configuration assumes that you have a replicator identity defined in your database that can be used to bind to the provider.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>An accesslog database is unique to a given provider. It should never be replicated.
<HR WIDTH="80%" ALIGN="Left"></P>
<H3><A NAME="N-Way Multi-Provider">18.3.3. N-Way Multi-Provider</A></H3>
<P>For the following example we will be using 3 Provider nodes. Keeping in line with <B>test050-syncrepl-multiprovider</B> of the OpenLDAP test suite, we will be configuring <EM>slapd(8)</EM> via <B>cn=config</B></P>
<P>This sets up the config database:</P>
<PRE>
     dn: cn=config
     objectClass: olcGlobal
     cn: config
     olcServerID: 1

     dn: olcDatabase={0}config,cn=config
     objectClass: olcDatabaseConfig
     olcDatabase: {0}config
     olcRootPW: secret
</PRE>
<P>Each server must have a unique server ID (<TT>SID</TT>), so second and third servers will have a different <TT>olcServerID</TT> obviously:</P>
<PRE>
     dn: cn=config
     objectClass: olcGlobal
     cn: config
     olcServerID: 2

     dn: olcDatabase={0}config,cn=config
     objectClass: olcDatabaseConfig
     olcDatabase: {0}config
     olcRootPW: secret
</PRE>
<P>This sets up syncrepl as a provider (since these are all providers):</P>
<PRE>
     dn: cn=module,cn=config
     objectClass: olcModuleList
     cn: module
     olcModulePath: /usr/local/libexec/openldap
     olcModuleLoad: syncprov.la
</PRE>
<P>Now we setup the first Provider Node (replace $URI1, $URI2 and $URI3 etc. with your actual ldap urls):</P>
<PRE>
     dn: cn=config
     changetype: modify
     replace: olcServerID
     olcServerID: 1 $URI1
     olcServerID: 2 $URI2
     olcServerID: 3 $URI3

     dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
     changetype: add
     objectClass: olcOverlayConfig
     objectClass: olcSyncProvConfig
     olcOverlay: syncprov

     dn: olcDatabase={0}config,cn=config
     changetype: modify
     add: olcSyncRepl
     olcSyncRepl: rid=001 provider=$URI1 binddn=&quot;cn=config&quot; bindmethod=simple
       credentials=secret searchbase=&quot;cn=config&quot; type=refreshAndPersist
       retry=&quot;5 5 300 5&quot; timeout=1
     olcSyncRepl: rid=002 provider=$URI2 binddn=&quot;cn=config&quot; bindmethod=simple
       credentials=secret searchbase=&quot;cn=config&quot; type=refreshAndPersist
       retry=&quot;5 5 300 5&quot; timeout=1
     olcSyncRepl: rid=003 provider=$URI3 binddn=&quot;cn=config&quot; bindmethod=simple
       credentials=secret searchbase=&quot;cn=config&quot; type=refreshAndPersist
       retry=&quot;5 5 300 5&quot; timeout=1
     -
     add: olcMultiProvider
     olcMultiProvider: TRUE
</PRE>
<P>Now start up the provider and a consumer/s, also add the above LDIF to the first consumer, second consumer etc. It will then replicate <B>cn=config</B>. You now have N-Way Multi-Provider on the config database.</P>
<P>We still have to replicate the actual data, not just the config, so add to the provider (all active and configured consumers/providers will pull down this config, as they are all syncing). Also, replace all <EM>${</EM>} variables with whatever is applicable to your setup:</P>
<PRE>
     dn: olcDatabase={1}$BACKEND,cn=config
     objectClass: olcDatabaseConfig
     objectClass: olc${BACKEND}Config
     olcDatabase: {1}$BACKEND
     olcSuffix: $BASEDN
     olcDbDirectory: ./db
     olcRootDN: $MANAGERDN
     olcRootPW: $PASSWD
     olcLimits: dn.exact=&quot;$MANAGERDN&quot; time.soft=unlimited time.hard=unlimited
       size.soft=unlimited size.hard=unlimited
     olcSyncRepl: rid=004 provider=$URI1 binddn=&quot;$MANAGERDN&quot; bindmethod=simple
       credentials=$PASSWD searchbase=&quot;$BASEDN&quot; type=refreshOnly
       interval=00:00:00:10 retry=&quot;5 5 300 5&quot; timeout=1
     olcSyncRepl: rid=005 provider=$URI2 binddn=&quot;$MANAGERDN&quot; bindmethod=simple
       credentials=$PASSWD searchbase=&quot;$BASEDN&quot; type=refreshOnly
       interval=00:00:00:10 retry=&quot;5 5 300 5&quot; timeout=1
     olcSyncRepl: rid=006 provider=$URI3 binddn=&quot;$MANAGERDN&quot; bindmethod=simple
       credentials=$PASSWD searchbase=&quot;$BASEDN&quot; type=refreshOnly
       interval=00:00:00:10 retry=&quot;5 5 300 5&quot; timeout=1
     olcMultiProvider: TRUE

     dn: olcOverlay=syncprov,olcDatabase={1}${BACKEND},cn=config
     changetype: add
     objectClass: olcOverlayConfig
     objectClass: olcSyncProvConfig
     olcOverlay: syncprov
</PRE>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>All of your servers' clocks must be tightly synchronized using e.g. NTP <A HREF="http://www.ntp.org/">http://www.ntp.org/</A>, atomic clock, or some other reliable time reference.
<HR WIDTH="80%" ALIGN="Left"></P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>As stated in <EM>slapd-config</EM>(5), URLs specified in <EM>olcSyncRepl</EM> directives are the URLs of the servers from which to replicate. These must exactly match the URLs <EM>slapd</EM> listens on (<EM>-h</EM> in <A HREF="#Command-Line Options">Command-Line Options</A>). Otherwise slapd may attempt to replicate from itself, causing a loop.
<HR WIDTH="80%" ALIGN="Left"></P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>The <EM>entryCSN</EM> and <EM>contextCSN</EM> attributes are used to track changes to an entry and naming context, respectively. The <TT>SID</TT> which must be unique for each replication provider is a component of these CSNs. If you're using <EM>slapadd</EM> to load a database and there are no entryCSNs already present in the input LDIF, <EM>slapadd</EM> will generate them with a <EM>SID</EM> of <TT>000</TT>. This is not a valid <EM>SID</EM> for multi-provider replication, and you should use the <TT>-S</TT> option of <EM>slapadd</EM> (8) to specify a valid <EM>SID</EM> for these generated CSNs. If there are existing entryCSNs in the input LDIF, <EM>slapadd</EM> will not change them.
<HR WIDTH="80%" ALIGN="Left"></P>
<H3><A NAME="Mirror mode">18.3.4. Mirror mode</A></H3>
<P>Mirror mode configuration is actually very easy. If you have ever setup a normal slapd syncrepl provider, then the only change is the following two directives:</P>
<PRE>
       multiprovider  on
       serverID    1
</PRE>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>You need to make sure that the <EM>serverID</EM> of each provider node is different and add it as a global configuration option.
<HR WIDTH="80%" ALIGN="Left"></P>
<H4><A NAME="Mirror Node Configuration">18.3.4.1. Mirror Node Configuration</A></H4>
<P>The first step is to configure the syncrepl provider the same as in the <A HREF="#Set up the provider slapd">Set up the provider slapd</A> section.</P>
<P>Here's a specific cut down example using <A HREF="#LDAP Sync Replication">LDAP Sync Replication</A> in <EM>refreshAndPersist</EM> mode:</P>
<P>Mirror mode node 1:</P>
<PRE>
       # Global section
       serverID    1
       # database section

       # syncrepl directive
       syncrepl      rid=001
                     provider=ldap://ldap-sid2.example.com
                     bindmethod=simple
                     binddn=&quot;cn=mirrormode,dc=example,dc=com&quot;
                     credentials=mirrormode
                     searchbase=&quot;dc=example,dc=com&quot;
                     schemachecking=on
                     type=refreshAndPersist
                     retry=&quot;60 +&quot;

       multiprovider on
</PRE>
<P>Mirror mode node 2:</P>
<PRE>
       # Global section
       serverID    2
       # database section

       # syncrepl directive
       syncrepl      rid=001
                     provider=ldap://ldap-sid1.example.com
                     bindmethod=simple
                     binddn=&quot;cn=mirrormode,dc=example,dc=com&quot;
                     credentials=mirrormode
                     searchbase=&quot;dc=example,dc=com&quot;
                     schemachecking=on
                     type=refreshAndPersist
                     retry=&quot;60 +&quot;

       multiprovider on
</PRE>
<P>It's simple really; each Mirror mode node is setup <B>exactly</B> the same, except that the <EM>serverID</EM> is unique, and each consumer is pointed to the other server.</P>
<H5><A NAME="Failover Configuration">18.3.4.1.1. Failover Configuration</A></H5>
<P>There are generally 2 choices for this; 1.  Hardware proxies/load-balancing or dedicated proxy software, 2. using a Back-LDAP proxy as a syncrepl provider</P>
<P>A typical enterprise example might be:</P>
<P><CENTER><IMG SRC="dual_dc.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure X.Y: Mirror mode in a Dual Data Center Configuration</P>
<H5><A NAME="Normal Consumer Configuration">18.3.4.1.2. Normal Consumer Configuration</A></H5>
<P>This is exactly the same as the <A HREF="#Set up the consumer slapd">Set up the consumer slapd</A> section. It can either setup in normal <A HREF="#syncrepl replication">syncrepl replication</A> mode, or in <A HREF="#delta-syncrepl replication">delta-syncrepl replication</A> mode.</P>
<H4><A NAME="Mirror mode Summary">18.3.4.2. Mirror mode Summary</A></H4>
<P>You will now have a directory architecture that provides all of the consistency guarantees of single-provider replication, while also providing the high availability of multi-provider replication.</P>
<H3><A NAME="Syncrepl Proxy">18.3.5. Syncrepl Proxy</A></H3>
<P><CENTER><IMG SRC="push-based-complete.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure X.Y: Replacing slurpd</P>
<P>The following example is for a self-contained push-based replication solution:</P>
<PRE>
        #######################################################################
        # Standard OpenLDAP Provider
        #######################################################################

        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

        include     /usr/local/etc/openldap/slapd.acl

        modulepath  /usr/local/libexec/openldap
        moduleload  back_mdb.la
        moduleload  syncprov.la
        moduleload  back_ldap.la

        pidfile     /usr/local/var/slapd.pid
        argsfile    /usr/local/var/slapd.args

        loglevel    sync stats

        database    mdb
        suffix      &quot;dc=suretecsystems,dc=com&quot;
        directory   /usr/local/var/openldap-data

        checkpoint      1024 5

        index       objectClass eq
        # rest of indexes
        index       default     sub

        rootdn          &quot;cn=admin,dc=suretecsystems,dc=com&quot;
        rootpw          testing

        # syncprov specific indexing
        index entryCSN eq
        index entryUUID eq

        # syncrepl Provider for primary db
        overlay syncprov
        syncprov-checkpoint 1000 60

        # Let the replicator DN have limitless searches
        limits dn.exact=&quot;cn=replicator,dc=suretecsystems,dc=com&quot; time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

        database    monitor

        database    config
        rootpw          testing

        ##############################################################################
        # Consumer Proxy that pulls in data via Syncrepl and pushes out via slapd-ldap
        ##############################################################################

        database        ldap
        # ignore conflicts with other databases, as we need to push out to same suffix
        hidden              on
        suffix          &quot;dc=suretecsystems,dc=com&quot;
        rootdn          &quot;cn=slapd-ldap&quot;
        uri             ldap://localhost:9012/

        lastmod         on

        # We don't need any access to this DSA
        restrict        all

        acl-bind        bindmethod=simple
                        binddn=&quot;cn=replicator,dc=suretecsystems,dc=com&quot;
                        credentials=testing

        syncrepl        rid=001
                        provider=ldap://localhost:9011/
                        binddn=&quot;cn=replicator,dc=suretecsystems,dc=com&quot;
                        bindmethod=simple
                        credentials=testing
                        searchbase=&quot;dc=suretecsystems,dc=com&quot;
                        type=refreshAndPersist
                        retry=&quot;5 5 300 5&quot;

        overlay         syncprov
</PRE>
<P>A replica configuration for this type of setup could be:</P>
<PRE>
        #######################################################################
        # Standard OpenLDAP Replica without Syncrepl
        #######################################################################

        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

        include     /usr/local/etc/openldap/slapd.acl

        modulepath  /usr/local/libexec/openldap
        moduleload  back_mdb.la
        moduleload  syncprov.la
        moduleload  back_ldap.la

        pidfile     /usr/local/var/slapd.pid
        argsfile    /usr/local/var/slapd.args

        loglevel    sync stats

        database    mdb
        suffix      &quot;dc=suretecsystems,dc=com&quot;
        directory   /usr/local/var/openldap-consumer/data

        maxsize         85899345920
        checkpoint      1024 5

        index       objectClass eq
        # rest of indexes
        index       default     sub

        rootdn          &quot;cn=admin,dc=suretecsystems,dc=com&quot;
        rootpw          testing

        # Let the replicator DN have limitless searches
        limits dn.exact=&quot;cn=replicator,dc=suretecsystems,dc=com&quot; time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

        updatedn &quot;cn=replicator,dc=suretecsystems,dc=com&quot;

        # Refer updates to the provider
        updateref   ldap://localhost:9011

        database    monitor

        database    config
        rootpw          testing
</PRE>
<P>You can see we use the <EM>updatedn</EM> directive here and example ACLs (<TT>usr/local/etc/openldap/slapd.acl</TT>) for this could be:</P>
<PRE>
        # Give the replicator DN unlimited read access.  This ACL may need to be
        # merged with other ACL statements.

        access to *
             by dn.base=&quot;cn=replicator,dc=suretecsystems,dc=com&quot; write
             by * break

        access to dn.base=&quot;&quot;
                by * read

        access to dn.base=&quot;cn=Subschema&quot;
                by * read

        access to dn.subtree=&quot;cn=Monitor&quot;
            by dn.exact=&quot;uid=admin,dc=suretecsystems,dc=com&quot; write
            by users read
            by * none

        access to *
                by self write
                by * read
</PRE>
<P>In order to support more replicas, just add more <EM>database ldap</EM> sections and increment the <EM>syncrepl rid</EM> number accordingly.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>You must populate the Provider and Replica directories with the same data, unlike when using normal Syncrepl
<HR WIDTH="80%" ALIGN="Left"></P>
<P>If you do not have access to modify the provider directory configuration you can configure a standalone ldap proxy, which might look like:</P>
<P><CENTER><IMG SRC="push-based-standalone.png" ALIGN="center"></CENTER></P>
<P ALIGN="Center">Figure X.Y: Replacing slurpd with a standalone version</P>
<P>The following configuration is an example of a standalone LDAP Proxy:</P>
<PRE>
        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

        include     /usr/local/etc/openldap/slapd.acl

        modulepath  /usr/local/libexec/openldap
        moduleload  syncprov.la
        moduleload  back_ldap.la

        ##############################################################################
        # Consumer Proxy that pulls in data via Syncrepl and pushes out via slapd-ldap
        ##############################################################################

        database        ldap
        # ignore conflicts with other databases, as we need to push out to same suffix
        hidden              on
        suffix          &quot;dc=suretecsystems,dc=com&quot;
        rootdn          &quot;cn=slapd-ldap&quot;
        uri             ldap://localhost:9012/

        lastmod         on

        # We don't need any access to this DSA
        restrict        all

        acl-bind        bindmethod=simple
                        binddn=&quot;cn=replicator,dc=suretecsystems,dc=com&quot;
                        credentials=testing

        syncrepl        rid=001
                        provider=ldap://localhost:9011/
                        binddn=&quot;cn=replicator,dc=suretecsystems,dc=com&quot;
                        bindmethod=simple
                        credentials=testing
                        searchbase=&quot;dc=suretecsystems,dc=com&quot;
                        type=refreshAndPersist
                        retry=&quot;5 5 300 5&quot;

        overlay         syncprov
</PRE>
<P>As you can see, you can let your imagination go wild using Syncrepl and <EM>slapd-ldap(8)</EM> tailoring your replication to fit your specific network topology.</P>
<P></P>
<HR>
<H1><A NAME="Maintenance">19. Maintenance</A></H1>
<P>System Administration is all about maintenance, so it is only fair that we discuss how to correctly maintain an OpenLDAP deployment.</P>
<H2><A NAME="Directory Backups">19.1. Directory Backups</A></H2>
<P>Backup strategies largely depend on the amount of change in the database and how much of that change an administrator might be willing to lose in a catastrophic failure. There are two basic methods that can be used:</P>
<P>1. Backup the LMDB database itself</P>
<P>The LMDB database can be copied live using the mdb_copy command.  If the database is a sparse file via the use of the &quot;writemap&quot; environment flag, the resulting copy will be the actual size of the database rather than a sparse copy.</P>
<P>2. Periodically run slapcat and back up the LDIF file:</P>
<P>Slapcat can be run while slapd is active. However, one runs the risk of an inconsistent database- not from the point of slapd, but from the point of the applications using LDAP. For example, if a provisioning application performed tasks that consisted of several LDAP operations, and the slapcat took place concurrently with those operations, then there might be inconsistencies in the LDAP database from the point of view of that provisioning application and applications that depended on it. One must, therefore, be convinced something like that won't happen. One way to do that would be to put the database in read-only mode while performing the slapcat. The other disadvantage of this approach is that the generated LDIF files can be rather large and the accumulation of the day's backups could add up to a substantial amount of space.</P>
<P>You can use <EM>slapcat</EM>(8) to generate an LDIF file for each of your <EM>slapd</EM>(8) back-mdb databases.</P>
<PRE>
    slapcat -f slapd.conf -b &quot;dc=example,dc=com&quot;
</PRE>
<P>For back-mdb this command may be ran while slapd(8) is running.</P>
<H2><A NAME="Checkpointing">19.2. Checkpointing</A></H2>
<P>Setting a checkpoint is only necessary when back-mdb has the dbnosync flag set. Otherwise it has no effect. With back-mdb the kbyte option is not implemented, meaning it will only run a checkpoint based on the elapsed amount of minutes flag.</P>
<H2><A NAME="Migration">19.3. Migration</A></H2>
<P>The simplest steps needed to migrate between versions or upgrade, depending on your deployment type are:</P>
<UL>
&nbsp;</UL><OL>
<LI><B>Stop the current server when convenient</B>
<BR>
&nbsp;
<LI><B>slapcat the current data out</B>
<BR>
&nbsp;
<LI><B>Clear out the current data directory (/usr/local/var/openldap-data/)</B>
<BR>
&nbsp;
<LI><B>Perform the software upgrades</B>
<BR>
&nbsp;
<LI><B>slapadd the exported data back into the directory</B>
<BR>
&nbsp;
<LI><B>Start the server</B></OL>
<P>Obviously this doesn't cater for any complicated deployments with <A HREF="#N-Way Multi-Provider">N-Way Multi-Provider</A>, but following the above sections and using either commercial support or community support should help. Also check the <A HREF="#Troubleshooting">Troubleshooting</A> section.</P>
<P></P>
<HR>
<H1><A NAME="Monitoring">20. Monitoring</A></H1>
<P><EM>slapd</EM>(8) supports an optional <TERM>LDAP</TERM> monitoring interface you can use to obtain information regarding the current state of your <EM>slapd</EM> instance.  For instance, the interface allows you to determine how many clients are connected to the server currently. The monitoring information is provided by a specialized backend, the <EM>monitor</EM> backend.  A manual page, <EM>slapd-monitor</EM>(5) is available.</P>
<P>When the monitoring interface is enabled, LDAP clients may be used to access information provided by the <EM>monitor</EM> backend, subject to access and other controls.</P>
<P>When enabled, the <EM>monitor</EM> backend dynamically generates and returns objects in response to search requests in the <EM>cn=Monitor</EM> subtree.  Each object contains information about a particular aspect of the server.  The information is held in a combination of user applications and operational attributes.   This information can be access with <EM>ldapsearch(1)</EM>, with any general-purpose LDAP browser, or with specialized monitoring tools.  The <A HREF="#Accessing Monitoring Information">Accessing Monitoring Information</A> section provides a brief tutorial on how to use <EM>ldapsearch</EM>(1) to access monitoring information, while the <A HREF="#Monitor information">Monitor information</A> section details monitoring information base and its organization.</P>
<P>While support for the monitor backend is included in default builds of slapd(8), this support requires some configuration to become active.  This may be done using either <TT>cn=config</TT> or <EM>slapd.conf</EM>(5).  The former is discussed in the <A HREF="#Monitor configuration via cn=config">Monitor configuration via cn=config</A> section of this of this chapter.  The latter is discussed in the <A HREF="#Monitor configuration via slapd.conf(5)">Monitor configuration via slapd.conf(5)</A> section of this chapter.  These sections assume monitor backend is built into <EM>slapd</EM> (e.g., <TT>--enable-monitor=yes</TT>, the default).  If the monitor backend was built as a module (e.g., <TT>--enable-monitor=mod</TT>, this module must loaded.  Loading of modules is discussed in the <A HREF="#Configuring slapd">Configuring slapd</A> and <A HREF="#The slapd Configuration File">The slapd Configuration File</A> chapters.</P>
<H2><A NAME="Monitor configuration via cn=config(5)">20.1. Monitor configuration via cn=config(5)</A></H2>
<P>The <EM>monitor backend</EM> is statically built into slapd and can be instantiated via ldapadd.</P>
<PRE>
 dn: olcDatabase=monitor,cn=config
 objectClass: olcDatabaseConfig
 olcDatabase: monitor
</PRE>
<H2><A NAME="Monitor configuration via slapd.conf(5)">20.2. Monitor configuration via slapd.conf(5)</A></H2>
<P>Configuration of the slapd.conf(5) to support LDAP monitoring is quite simple.</P>
<P>First, ensure <EM>core.schema</EM> schema configuration file is included by your <EM>slapd.conf</EM>(5) file.  The <EM>monitor</EM> backend requires it.</P>
<P>Second, instantiate the <EM>monitor backend</EM> by adding a <EM>database monitor</EM> directive below your existing database sections.  For instance:</P>
<PRE>
        database monitor
</PRE>
<P>Lastly, add additional global or database directives as needed.</P>
<P>Like most other database backends, the monitor backend does honor slapd(8) access and other administrative controls.   As some monitor information may be sensitive, it is generally recommend access to cn=monitor be restricted to directory administrators and their monitoring agents.  Adding an <EM>access</EM> directive immediately below the <EM>database monitor</EM> directive is a clear and effective approach for controlling access.  For instance, the addition of the following <EM>access</EM> directive immediately below the <EM>database monitor</EM> directive restricts access to monitoring information to the specified directory manager.</P>
<PRE>
        access to *
                by dn.exact=&quot;cn=Manager,dc=example,dc=com
                by * none
</PRE>
<P>More information on <EM>slapd</EM>(8) access controls, see <EM>The access Control Directive</EM> section of the <A HREF="#The slapd Configuration File">The slapd Configuration File</A> chapter and <EM>slapd.access</EM>(5).</P>
<P>After restarting <EM>slapd</EM>(8), you are ready to start exploring the monitoring information provided in <TT>cn=config</TT> as discussed in the <A HREF="#Accessing Monitoring Information">Accessing Monitoring Information</A> section of this chapter.</P>
<P>One can verify slapd(8) is properly configured to provide monitoring information by attempting to read the <TT>cn=monitor</TT> object. For instance, if the following <EM>ldapsearch</EM>(1) command returns the cn=monitor object (with, as requested, no attributes), it's working.</P>
<PRE>
        ldapsearch -x -D 'cn=Manager,dc=example,dc=com' -W \
                -b 'cn=Monitor' -s base 1.1
</PRE>
<P>Note that unlike general purpose database backends, the database suffix is hardcoded.  It's always <TT>cn=Monitor</TT>.  So no <EM>suffix</EM> directive should be provided.  Also note that general purpose database backends, the monitor backend cannot be instantiated multiple times.  That is, there can only be one (or zero) occurrences of <TT>database monitor</TT> in the server's configuration.</P>
<H2><A NAME="Accessing Monitoring Information">20.3. Accessing Monitoring Information</A></H2>
<P>As previously discussed, when enabled, the <EM>monitor</EM> backend dynamically generates and returns objects in response to search requests in the <EM>cn=Monitor</EM> subtree.  Each object contains information about a particular aspect of the server.  The information is held in a combination of user applications and operational attributes.  This information can be accessed with <EM>ldapsearch(1)</EM>, with any general-purpose LDAP browser, or with specialized monitoring tools.</P>
<P>This section provides a provides a brief tutorial on how to use <EM>ldapsearch</EM>(1) to access monitoring information.</P>
<P>To inspect any particular monitor object, one performs search operation on the object with a baseObject scope and a <TT>(objectClass=*)</TT> filter.  As the monitoring information is contained in a combination of user applications and operational attributes, the return all user applications attributes (e.g., <TT>'*'</TT>) and all operational attributes (e.g., <TT>'+'</TT>) should be requested.   For instance, to read the <TT>cn=Monitor</TT> object itself, the <EM>ldapsearch</EM>(1) command (modified to fit your configuration) can be used:</P>
<PRE>
        ldapsearch -x -D 'cn=Manager,dc=example,dc=com' -W \
                -b 'cn=Monitor' -s base '(objectClass=*)' '*' '+'
</PRE>
<P>When run against your server, this should produce output similar to:</P>
<PRE>
        dn: cn=Monitor
        objectClass: monitorServer
        structuralObjectClass: monitorServer
        cn: Monitor
        creatorsName:
        modifiersName:
        createTimestamp: 20061208223558Z
        modifyTimestamp: 20061208223558Z
        description: This subtree contains monitoring/managing objects.
        description: This object contains information about this server.
        description: Most of the information is held in operational attributes, which
         must be explicitly requested.
        monitoredInfo: OpenLDAP: slapd 2.5 (Dec  7 2006 17:30:29)
        entryDN: cn=Monitor
        subschemaSubentry: cn=Subschema
        hasSubordinates: TRUE
</PRE>
<P>To reduce the number of uninteresting attributes returned, one can be more selective when requesting which attributes are to be returned.  For instance, one could request the return of all attributes allowed by the <EM>monitorServer</EM> object class (e.g., <TT>@objectClass</TT>) instead of all user and all operational attributes:</P>
<PRE>
        ldapsearch -x -D 'cn=Manager,dc=example,dc=com' -W \
                -b 'cn=Monitor' -s base '(objectClass=*)' '@monitorServer'
</PRE>
<P>This limits the output as follows:</P>
<PRE>
        dn: cn=Monitor
        objectClass: monitorServer
        cn: Monitor
        description: This subtree contains monitoring/managing objects.
        description: This object contains information about this server.
        description: Most of the information is held in operational attributes, which
         must be explicitly requested.
        monitoredInfo: OpenLDAP: slapd 2.X (Dec  7 2006 17:30:29)
</PRE>
<P>To return the names of all the monitoring objects, one performs a search of <TT>cn=Monitor</TT> with subtree scope and <TT>(objectClass=*)</TT> filter and requesting no attributes (e.g., <TT>1.1</TT>) be returned.</P>
<PRE>
        ldapsearch -x -D 'cn=Manager,dc=example,dc=com' -W -b 'cn=Monitor' -s sub 1.1
</PRE>
<P>If you run this command you will discover that there are many objects in the <EM>cn=Monitor</EM> subtree.  The following section describes some of the commonly available monitoring objects.</P>
<H2><A NAME="Monitor Information">20.4. Monitor Information</A></H2>
<P>The <EM>monitor</EM> backend provides a wealth of information useful for monitoring the slapd(8) contained in set of monitor objects. Each object contains information about a particular aspect of the server, such as a backends, a connection, or a thread. Some objects serve as containers for other objects and used to construct a hierarchy of objects.</P>
<P>In this hierarchy, the most superior object is {cn=Monitor}. While this object primarily serves as a container for other objects, most of which are containers, this object provides information about this server.  In particular, it provides the slapd(8) version string.  Example:</P>
<PRE>
        dn: cn=Monitor
        monitoredInfo: OpenLDAP: slapd 2.X (Dec  7 2006 17:30:29)
</PRE>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>Examples in this section (and its subsections) have been trimmed to show only key information.
<HR WIDTH="80%" ALIGN="Left"></P>
<H3><A NAME="Backends">20.4.1. Backends</A></H3>
<P>The <TT>cn=Backends,cn=Monitor</TT> object, itself, provides a list of available backends.  The list of available backends all builtin backends, as well as backends loaded by modules.  For example:</P>
<PRE>
        dn: cn=Backends,cn=Monitor
        monitoredInfo: config
        monitoredInfo: ldif
        monitoredInfo: monitor
        monitoredInfo: mdb
</PRE>
<P>This indicates the <EM>config</EM>, <EM>ldif</EM>, <EM>monitor</EM>, and <EM>mdb</EM> backends are available.</P>
<P>The <TT>cn=Backends,cn=Monitor</TT> object is also a container for available backend objects.  Each available backend object contains information about a particular backend.  For example:</P>
<PRE>
        dn: cn=Backend 0,cn=Backends,cn=Monitor
        monitoredInfo: config
        monitorRuntimeConfig: TRUE
        supportedControl: 2.16.840.1.113730.3.4.2
        seeAlso: cn=Database 0,cn=Databases,cn=Monitor

        dn: cn=Backend 1,cn=Backends,cn=Monitor
        monitoredInfo: ldif
        monitorRuntimeConfig: TRUE
        supportedControl: 2.16.840.1.113730.3.4.2

        dn: cn=Backend 2,cn=Backends,cn=Monitor
        monitoredInfo: monitor
        monitorRuntimeConfig: TRUE
        supportedControl: 2.16.840.1.113730.3.4.2
        seeAlso: cn=Database 2,cn=Databases,cn=Monitor

        dn: cn=Backend 3,cn=Backends,cn=Monitor
        monitoredInfo: mdb
        monitorRuntimeConfig: TRUE
        supportedControl: 1.3.6.1.1.12
        supportedControl: 2.16.840.1.113730.3.4.2
        supportedControl: 1.3.6.1.4.1.4203.666.5.2
        supportedControl: 1.2.840.113556.1.4.319
        supportedControl: 1.3.6.1.1.13.1
        supportedControl: 1.3.6.1.1.13.2
        supportedControl: 1.3.6.1.4.1.4203.1.10.1
        supportedControl: 1.2.840.113556.1.4.1413
        supportedControl: 1.3.6.1.4.1.4203.666.11.7.2
</PRE>
<P>For each of these objects, monitorInfo indicates which backend the information in the object is about.  For instance, the <TT>cn=Backend 5,cn=Backends,cn=Monitor</TT> object contains (in the example) information about the <EM>mdb</EM> backend.</P>
<TABLE CLASS="columns" BORDER>
<TR CLASS="heading">
<TD>
<STRONG>Attribute</STRONG>
</TD>
<TD>
<STRONG>Description</STRONG>
</TD>
</TR>
<TR>
<TD>
monitoredInfo
</TD>
<TD>
Name of backend
</TD>
</TR>
<TR>
<TD>
supportedControl
</TD>
<TD>
supported LDAP control extensions
</TD>
</TR>
<TR>
<TD>
seeAlso
</TD>
<TD>
Database objects of instances of this backend
</TD>
</TR>
</TABLE>

<H3><A NAME="Connections">20.4.2. Connections</A></H3>
<P>The main entry is empty; it should contain some statistics on the number of connections.</P>
<P>Dynamic child entries are created for each open connection, with stats on the activity on that connection (the format will be detailed later). There are two special child entries that show the number of total and current connections respectively.</P>
<P>For example:</P>
<P>Total Connections:</P>
<PRE>
   dn: cn=Total,cn=Connections,cn=Monitor
   structuralObjectClass: monitorCounterObject
   monitorCounter: 4
   entryDN: cn=Total,cn=Connections,cn=Monitor
   subschemaSubentry: cn=Subschema
   hasSubordinates: FALSE
</PRE>
<P>Current Connections:</P>
<PRE>
   dn: cn=Current,cn=Connections,cn=Monitor
   structuralObjectClass: monitorCounterObject
   monitorCounter: 2
   entryDN: cn=Current,cn=Connections,cn=Monitor
   subschemaSubentry: cn=Subschema
   hasSubordinates: FALSE
</PRE>
<H3><A NAME="Databases">20.4.3. Databases</A></H3>
<P>The main entry contains the naming context of each configured database; the child entries contain, for each database, the type and the naming context.</P>
<P>For example:</P>
<PRE>
   dn: cn=Database 2,cn=Databases,cn=Monitor
   structuralObjectClass: monitoredObject
   monitoredInfo: monitor
   monitorIsShadow: FALSE
   monitorContext: cn=Monitor
   readOnly: FALSE
   entryDN: cn=Database 2,cn=Databases,cn=Monitor
   subschemaSubentry: cn=Subschema
   hasSubordinates: FALSE
</PRE>
<H3><A NAME="Listener">20.4.4. Listener</A></H3>
<P>It contains the description of the devices the server is currently listening on:</P>
<PRE>
   dn: cn=Listener 0,cn=Listeners,cn=Monitor
   structuralObjectClass: monitoredObject
   monitorConnectionLocalAddress: IP=0.0.0.0:389
   entryDN: cn=Listener 0,cn=Listeners,cn=Monitor
   subschemaSubentry: cn=Subschema
   hasSubordinates: FALSE
</PRE>
<H3><A NAME="Log">20.4.5. Log</A></H3>
<P>It contains the currently active log items.  The <EM>Log</EM> subsystem allows user modify operations on the <EM>description</EM> attribute, whose values <EM>MUST</EM> be in the list of admittable log switches:</P>
<PRE>
   Trace
   Packets
   Args
   Conns
   BER
   Filter
   Config
   ACL
   Stats
   Stats2
   Shell
   Parse
   Sync
</PRE>
<P>These values can be added, replaced or deleted; they affect what messages are sent to the syslog device. Custom values could be added by custom modules.</P>
<H3><A NAME="Operations">20.4.6. Operations</A></H3>
<P>It shows some statistics on the operations performed by the server:</P>
<PRE>
   Initiated
   Completed
</PRE>
<P>and for each operation type, i.e.:</P>
<PRE>
   Bind
   Unbind
   Add
   Delete
   Modrdn
   Modify
   Compare
   Search
   Abandon
   Extended
</PRE>
<P>There are too many types to list example here, so please try for yourself using <A HREF="#Monitor search example">Monitor search example</A></P>
<H3><A NAME="Overlays">20.4.7. Overlays</A></H3>
<P>The main entry contains the type of overlays available at run-time; the child entries, for each overlay, contain the type of the overlay.</P>
<P>It should also contain the modules that have been loaded if dynamic overlays are enabled:</P>
<PRE>
   # Overlays, Monitor
   dn: cn=Overlays,cn=Monitor
   structuralObjectClass: monitorContainer
   monitoredInfo: syncprov
   monitoredInfo: accesslog
   monitoredInfo: glue
   entryDN: cn=Overlays,cn=Monitor
   subschemaSubentry: cn=Subschema
   hasSubordinates: TRUE
</PRE>
<H3><A NAME="SASL">20.4.8. SASL</A></H3>
<P>Currently empty.</P>
<H3><A NAME="Statistics">20.4.9. Statistics</A></H3>
<P>It shows some statistics on the data sent by the server:</P>
<PRE>
   Bytes
   PDU
   Entries
   Referrals
</PRE>
<P>e.g.</P>
<PRE>
   # Entries, Statistics, Monitor
   dn: cn=Entries,cn=Statistics,cn=Monitor
   structuralObjectClass: monitorCounterObject
   monitorCounter: 612248
   entryDN: cn=Entries,cn=Statistics,cn=Monitor
   subschemaSubentry: cn=Subschema
   hasSubordinates: FALSE
</PRE>
<H3><A NAME="Threads">20.4.10. Threads</A></H3>
<P>It contains the maximum number of threads enabled at startup and the current backload.</P>
<P>e.g.</P>
<PRE>
   # Max, Threads, Monitor
   dn: cn=Max,cn=Threads,cn=Monitor
   structuralObjectClass: monitoredObject
   monitoredInfo: 16
   entryDN: cn=Max,cn=Threads,cn=Monitor
   subschemaSubentry: cn=Subschema
   hasSubordinates: FALSE
</PRE>
<H3><A NAME="Time">20.4.11. Time</A></H3>
<P>It contains two child entries with the start time and the current time of the server.</P>
<P>e.g.</P>
<P>Start time:</P>
<PRE>
   dn: cn=Start,cn=Time,cn=Monitor
   structuralObjectClass: monitoredObject
   monitorTimestamp: 20061205124040Z
   entryDN: cn=Start,cn=Time,cn=Monitor
   subschemaSubentry: cn=Subschema
   hasSubordinates: FALSE
</PRE>
<P>Current time:</P>
<PRE>
   dn: cn=Current,cn=Time,cn=Monitor
   structuralObjectClass: monitoredObject
   monitorTimestamp: 20061207120624Z
   entryDN: cn=Current,cn=Time,cn=Monitor
   subschemaSubentry: cn=Subschema
   hasSubordinates: FALSE
</PRE>
<H3><A NAME="TLS">20.4.12. TLS</A></H3>
<P>Currently empty.</P>
<H3><A NAME="Waiters">20.4.13. Waiters</A></H3>
<P>It contains the number of current read waiters.</P>
<P>e.g.</P>
<P>Read waiters:</P>
<PRE>
   dn: cn=Read,cn=Waiters,cn=Monitor
   structuralObjectClass: monitorCounterObject
   monitorCounter: 7
   entryDN: cn=Read,cn=Waiters,cn=Monitor
   subschemaSubentry: cn=Subschema
   hasSubordinates: FALSE
</PRE>
<P>Write waiters:</P>
<PRE>
   dn: cn=Write,cn=Waiters,cn=Monitor
   structuralObjectClass: monitorCounterObject
   monitorCounter: 0
   entryDN: cn=Write,cn=Waiters,cn=Monitor
   subschemaSubentry: cn=Subschema
   hasSubordinates: FALSE
</PRE>
<P>Add new monitored things here and discuss, referencing man pages and present examples</P>
<P></P>
<HR>
<H1><A NAME="Tuning">21. Tuning</A></H1>
<P>This is perhaps one of the most important chapters in the guide, because if you have not tuned <EM>slapd</EM>(8) correctly or grasped how to design your directory and environment, you can expect very poor performance.</P>
<P>Reading, understanding and experimenting using the instructions and information in the following sections, will enable you to fully understand how to tailor your directory server to your specific requirements.</P>
<P>It should be noted that the following information has been collected over time from our community based FAQ. So obviously the benefit of this real world experience and advice should be of great value to the reader.</P>
<H2><A NAME="Performance Factors">21.1. Performance Factors</A></H2>
<P>Various factors can play a part in how your directory performs on your chosen hardware and environment. We will attempt to discuss these here.</P>
<H3><A NAME="Memory">21.1.1. Memory</A></H3>
<P>Scale your cache to use available memory and increase system memory if you can.</P>
<H3><A NAME="Disks">21.1.2. Disks</A></H3>
<P>Use fast filesystems, and conduct your own testing to see which filesystem types perform best with your workload. (On our own Linux testing, EXT2 and JFS tend to provide better write performance than everything else, including newer filesystems like EXT4, BTRFS, etc.)</P>
<P>Use fast subsystems. Put each database on separate disks.</P>
<H3><A NAME="Network Topology">21.1.3. Network Topology</A></H3>
<P>http://www.openldap.org/faq/data/cache/363.html</P>
<P>Drawing here.</P>
<H3><A NAME="Directory Layout Design">21.1.4. Directory Layout Design</A></H3>
<P>Reference to other sections and good/bad drawing here.</P>
<H3><A NAME="Expected Usage">21.1.5. Expected Usage</A></H3>
<P>Discussion.</P>
<H2><A NAME="Indexes">21.2. Indexes</A></H2>
<H3><A NAME="Understanding how a search works">21.2.1. Understanding how a search works</A></H3>
<P>If you're searching on a filter that has been indexed, then the search reads the index and pulls exactly the entries that are referenced by the index. If the filter term has not been indexed, then the search must read every single entry in the target scope and test to see if each entry matches the filter. Obviously indexing can save a lot of work when it's used correctly.</P>
<P>In back-mdb, indexes can only track a certain number of entries per key (by default that number is 2^16 = 65536). If more entries' values hash to this key, some/all of them will have to be represented by a range of candidates, making the index less useful over time as deletions cannot usually be tracked accurately.</P>
<H3><A NAME="What to index">21.2.2. What to index</A></H3>
<P>As a general rule, to make any use of indexes, you must set up an equality index on objectClass:</P>
<PRE>
        index objectClass eq
</PRE>
<P>Then you should create indices to match the actual filter terms used in search queries.</P>
<PRE>
        index cn,sn,givenname,mail eq
</PRE>
<P>Each attribute index can be tuned further by selecting the set of index types to generate. For example, substring and approximate search for organizations (o) may make little sense (and isn't like done very often). And searching for <EM>userPassword</EM> likely makes no sense what so ever.</P>
<P>General rule: don't go overboard with indexes. Unused indexes must be maintained and hence can only slow things down.</P>
<P>See <EM>slapd.conf</EM>(5) and <EM>slapdindex</EM>(8) for more information</P>
<H3><A NAME="Presence indexing">21.2.3. Presence indexing</A></H3>
<P>If your client application uses presence filters and if the target attribute exists on the majority of entries in your target scope, then all of those entries are going to be read anyway, because they are valid members of the result set. In a subtree where 100% of the entries are going to contain the same attributes, the presence index does absolutely NOTHING to benefit the search, because 100% of the entries match that presence filter. As an example, setting a presence index on objectClass provides no benefit since it is present on every entry.</P>
<P>So the resource cost of generating the index is a complete waste of CPU time, disk, and memory. Don't do it unless you know that it will be used, and that the attribute in question occurs very infrequently in the target data.</P>
<P>Almost no applications use presence filters in their search queries. Presence indexing is pointless when the target attribute exists on the majority of entries in the database. In most LDAP deployments, presence indexing should not be done, it's just wasted overhead.</P>
<P>See the <EM>Logging</EM> section below on what to watch out for if you have a frequently searched for attribute that is unindexed.</P>
<H3><A NAME="Equality indexing">21.2.4. Equality indexing</A></H3>
<P>Similarly to presence indexes, equality indexes are most useful if the values searched for are uncommon. Most OpenLDAP indexes work by hashing the normalised value and using the hash as the key. Hashing behaviour depends on the matching rule syntax, some matching rules also implement indexers that help speed up inequality (lower than, ...) queries.</P>
<P>Check the documentation and other parts of this guide if some indexes are mandatory - e.g. to enable replication, it is expected you index certain operational attributes, likewise if you rely on filters in ACL processing.</P>
<P>Approximate indexes are usually identical to equality indexes unless a matching rule explicitly implements it. As of OpenLDAP 2.5, only directoryStringApproxMatch and IA5StringApproxMatch matchers and indexers are implemented, currently using soundex or metaphone, with metaphone being the default.</P>
<H3><A NAME="Substring indexing">21.2.5. Substring indexing</A></H3>
<P>Substring indexes work on splitting the value into short chunks and then indexing those in a similar way to how equality index does. The storage space needed to store all of this data is analogous to the amount of data being indexed, which makes the indexes extremely heavy-handed in most scenarios.</P>
<H2><A NAME="Logging">21.3. Logging</A></H2>
<H3><A NAME="What log level to use">21.3.1. What log level to use</A></H3>
<P>The default of <EM>loglevel stats</EM> (256) is really the best bet. There's a corollary to this when problems *do* arise, don't try to trace them using syslog. Use the debug flag instead, and capture slapd's stderr output. syslog is too slow for debug tracing, and it's inherently lossy - it will throw away messages when it can't keep up. See <EM>slapd.conf</EM>(5) or <EM>slapd-config</EM>(5) for more information on how to configure the loglevel.</P>
<P>Contrary to popular belief, <EM>loglevel 0</EM> is not ideal for production as you won't be able to track when problems first arise.</P>
<H3><A NAME="What to watch out for">21.3.2. What to watch out for</A></H3>
<P>The most common message you'll see that you should pay attention to is:</P>
<PRE>
       &quot;&lt;= mdb_equality_candidates: (foo) index_param failed (18)&quot;
</PRE>
<P>That means that some application tried to use an equality filter (<EM>foo=&lt;somevalue&gt;</EM>) and attribute <EM>foo</EM> does not have an equality index. If you see a lot of these messages, you should add the index. If you see one every month or so, it may be acceptable to ignore it.</P>
<P>The default syslog level is stats (256) which logs the basic parameters of each request; it usually produces 1-3 lines of output. On Solaris and systems that only provide synchronous syslog, you may want to turn it off completely, but usually you want to leave it enabled so that you'll be able to see index messages whenever they arise. On Linux you can configure syslogd to run asynchronously, in which case the performance hit for moderate syslog traffic pretty much disappears.</P>
<H3><A NAME="Improving throughput">21.3.3. Improving throughput</A></H3>
<P>You can improve logging performance on some systems by configuring syslog not to sync the file system with every write (<EM>man syslogd/syslog.conf</EM>). In Linux, you can prepend the log file name with a &quot;-&quot; in <EM>syslog.conf</EM>. For example, if you are using the default LOCAL4 logging you could try:</P>
<PRE>
       # LDAP logs
       LOCAL4.*         -/var/log/ldap
</PRE>
<P>For syslog-ng, add or modify the following line in <EM>syslog-ng.conf</EM>:</P>
<PRE>
       options { sync(n); };
</PRE>
<P>where n is the number of lines which will be buffered before a write.</P>
<H2><A NAME="{{slapd}}(8) Threads">21.4. <EM>slapd</EM>(8) Threads</A></H2>
<P><EM>slapd</EM>(8) can process requests via a configurable number of threads, which in turn affects the in/out rate of connections.</P>
<P>This value should generally be a function of the number of &quot;real&quot; cores on the system, for example on a server with 2 CPUs with one core each, set this to 8, or 4 threads per real core.  This is a &quot;read&quot; maximized value. The more threads that are configured per core, the slower <EM>slapd</EM>(8) responds for &quot;read&quot; operations.  On the flip side, it appears to handle write operations faster in a heavy write/low read scenario.</P>
<P>The upper bound for good read performance appears to be 16 threads (which also happens to be the default setting).</P>
<P></P>
<HR>
<H1><A NAME="Troubleshooting">22. Troubleshooting</A></H1>
<P>If you're having trouble using OpenLDAP, get onto the OpenLDAP-Software mailing list, or:</P>
<UL>
<LI>Browse the list archives at <A HREF="http://www.openldap.org/lists/#archives">http://www.openldap.org/lists/#archives</A>
<LI>Search the FAQ at <A HREF="http://www.openldap.org/faq/">http://www.openldap.org/faq/</A>
<LI>Search the Issue Tracking System at <A HREF="http://www.openldap.org/its/">http://www.openldap.org/its/</A></UL>
<P>Chances are the problem has been solved and explained in detail many times before.</P>
<H2><A NAME="User or Software errors">22.1. User or Software errors?</A></H2>
<P>More often than not, an error is caused by a configuration problem or a misunderstanding of what you are trying to implement and/or achieve.</P>
<P>We will now attempt to discuss common user errors.</P>
<H2><A NAME="Checklist">22.2. Checklist</A></H2>
<P>The following checklist can help track down your problem. Please try to use if <B>before</B> posting to the list, or in the rare circumstances of reporting a bug.</P>
<UL>
&nbsp;</UL><OL>
<LI><B>Use the <EM>slaptest</EM> tool to verify configurations before starting <EM>slapd</EM></B>
<BR>
&nbsp;
<LI><B>Verify that <EM>slapd</EM> is listening to the specified port(s) (389 and 636, generally) before trying the <EM>ldapsearch</EM></B>
<BR>
&nbsp;
<LI><B>Can you issue an <EM>ldapsearch</EM>?</B>
<BR>
&nbsp;
<LI><B>If not, have you enabled complex ACLs without fully understanding them?</B>
<BR>
&nbsp;
<LI><B>Do you have a system wide LDAP setting pointing to the wrong LDAP Directory?</B>
<BR>
&nbsp;
<LI><B>Are you using TLS?</B>
<BR>
&nbsp;
<LI><B>Have your certificates expired?</B></OL>
<H2><A NAME="OpenLDAP Bugs">22.3. OpenLDAP Bugs</A></H2>
<P>Sometimes you may encounter an actual OpenLDAP bug, in which case please visit our Issue Tracking system <A HREF="http://www.openldap.org/its/">http://www.openldap.org/its/</A> and report it. However, make sure it's not already a known bug or a common user problem.</P>
<UL>
<LI>bugs in historic versions of OpenLDAP will not be considered;
<LI>bugs in released versions that are no longer present in the Git master branch, either because they have been fixed or because they no longer apply, will not be considered as well;
<LI>bugs in distributions of OpenLDAP software that are not related to the software as provided by OpenLDAP will not be considered; in those cases please refer to the distributor.</UL>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>Our Issue Tracking system is <B>NOT</B> for OpenLDAP <B>Support</B>, please join our mailing Lists: <A HREF="http://www.openldap.org/lists/">http://www.openldap.org/lists/</A> for that.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>The information you should provide in your bug report is discussed in our FAQ-O-MATIC at <A HREF="http://www.openldap.org/faq/data/cache/59.html">http://www.openldap.org/faq/data/cache/59.html</A></P>
<H2><A NAME="3rd party software error">22.4. 3rd party software error</A></H2>
<P>The OpenLDAP Project only supports OpenLDAP software.</P>
<P>You may however seek commercial support (<A HREF="http://www.openldap.org/support/">http://www.openldap.org/support/</A>) or join the general LDAP forum for non-commercial discussions and information relating to LDAP at: <A HREF="http://www.umich.edu/~dirsvcs/ldap/mailinglist.html">http://www.umich.edu/~dirsvcs/ldap/mailinglist.html</A></P>
<H2><A NAME="How to contact the OpenLDAP Project">22.5. How to contact the OpenLDAP Project</A></H2>
<UL>
<LI>Mailing Lists: <A HREF="http://www.openldap.org/lists/">http://www.openldap.org/lists/</A>
<LI>Project: <A HREF="http://www.openldap.org/project/">http://www.openldap.org/project/</A>
<LI>Issue Tracking: <A HREF="http://www.openldap.org/its/">http://www.openldap.org/its/</A></UL>
<H2><A NAME="How to present your problem">22.6. How to present your problem</A></H2>
<H2><A NAME="Debugging {{slapd}}(8)">22.7. Debugging <EM>slapd</EM>(8)</A></H2>
<P>After reading through the above sections and before e-mailing the OpenLDAP lists, you might want to try out some of the following to track down the cause of your problems:</P>
<UL>
<LI>A loglevel of stats (256) is generally a good first loglevel to use for getting information useful to list members on issues. This is the default loglevel if none is configured.
<LI>Running <EM>slapd -d -1</EM> can often track down fairly simple issues, such as missing schemas and incorrect file permissions for the <EM>slapd</EM> user to things like certs
<LI>Check your logs for errors, as discussed at <A HREF="http://www.openldap.org/faq/data/cache/358.html">http://www.openldap.org/faq/data/cache/358.html</A></UL>
<H2><A NAME="Commercial Support">22.8. Commercial Support</A></H2>
<P>The firms listed at <A HREF="http://www.openldap.org/support/">http://www.openldap.org/support/</A> offer technical support services catering to OpenLDAP community.</P>
<P>The listing of any given firm should not be viewed as an endorsement or recommendation of any kind, nor as otherwise indicating there exists a business relationship or an affiliation between any listed firm and the OpenLDAP Foundation or the OpenLDAP Project or its contributors.</P>
<P></P>
<HR>
<H1><A NAME="Changes Since Previous Release">A. Changes Since Previous Release</A></H1>
<P>The following sections attempt to summarize the new features and changes in OpenLDAP software since the 2.4.x release and the OpenLDAP Admin Guide.</P>
<H2><A NAME="New Guide Sections">A.1. New Guide Sections</A></H2>
<P>In order to make the Admin Guide more thorough and cover the majority of questions asked on the OpenLDAP mailing lists and scenarios discussed there, we have added the following new sections:</P>
<UL>
<LI><A HREF="#When should I use LDAP">When should I use LDAP?</A>
<LI><A HREF="#When should I not use LDAP">When should I not use LDAP?</A>
<LI><A HREF="#LDAP vs RDBMS">LDAP vs RDBMS</A>
<LI><A HREF="#Access Control">Access Control</A>
<LI><A HREF="#Backends">Backends</A>
<LI><A HREF="#Overlays">Overlays</A>
<LI><A HREF="#Replication">Replication</A>
<LI><A HREF="#Maintenance">Maintenance</A>
<LI><A HREF="#Monitoring">Monitoring</A>
<LI><A HREF="#Tuning">Tuning</A>
<LI><A HREF="#Troubleshooting">Troubleshooting</A>
<LI><A HREF="#Changes Since Previous Release">Changes Since Previous Release</A>
<LI><A HREF="#Upgrading from 2.4.x">Upgrading from 2.4.x</A>
<LI><A HREF="#Common errors encountered when using OpenLDAP Software">Common errors encountered when using OpenLDAP Software</A>
<LI><A HREF="#Recommended OpenLDAP Software Dependency Versions">Recommended OpenLDAP Software Dependency Versions</A>
<LI><A HREF="#Real World OpenLDAP Deployments and Examples">Real World OpenLDAP Deployments and Examples</A>
<LI><A HREF="#OpenLDAP Software Contributions">OpenLDAP Software Contributions</A>
<LI><A HREF="#Configuration File Examples">Configuration File Examples</A>
<LI><A HREF="#LDAP Result Codes">LDAP Result Codes</A>
<LI><A HREF="#Glossary">Glossary</A></UL>
<P>Also, the table of contents is now 3 levels deep to ease navigation.</P>
<H2><A NAME="New Features and Enhancements in 2.5">A.2. New Features and Enhancements in 2.5</A></H2>
<H3><A NAME="Better {{B:cn=config}} functionality">A.2.1. Better <B>cn=config</B> functionality</A></H3>
<H3><A NAME="Better {{B:cn=schema}} functionality">A.2.2. Better <B>cn=schema</B> functionality</A></H3>
<H3><A NAME="More sophisticated Syncrepl configurations">A.2.3. More sophisticated Syncrepl configurations</A></H3>
<H3><A NAME="Replicating {{slapd}} Configuration (syncrepl and {{B:cn=config}})">A.2.4. Replicating <EM>slapd</EM> Configuration (syncrepl and <B>cn=config</B>)</A></H3>
<H3><A NAME="More extensive TLS configuration control">A.2.5. More extensive TLS configuration control</A></H3>
<H3><A NAME="Performance enhancements">A.2.6. Performance enhancements</A></H3>
<H3><A NAME="New overlays">A.2.7. New overlays</A></H3>
<H3><A NAME="New features in existing Overlays">A.2.8. New features in existing Overlays</A></H3>
<H3><A NAME="New features in slapd">A.2.9. New features in slapd</A></H3>
<H3><A NAME="New features in libldap">A.2.10. New features in libldap</A></H3>
<H3><A NAME="New clients, tools and tool enhancements">A.2.11. New clients, tools and tool enhancements</A></H3>
<H3><A NAME="New build options">A.2.12. New build options</A></H3>
<H2><A NAME="Obsolete Features Removed From 2.5">A.3. Obsolete Features Removed From 2.5</A></H2>
<P>These features were strongly deprecated in 2.4 and removed in 2.5.</P>
<H3><A NAME="back-bdb and back-hdb">A.3.1. back-bdb and back-hdb</A></H3>
<P>back-bdb and back-hdb were significantly slower than back-mdb and required significant tuning of multiple parameters to maximize performance. back-mdb requires no tuning and provides all the functionality previously provided via back-bdb and back-hdb.</P>
<P></P>
<HR>
<H1><A NAME="Upgrading from 2.4.x">B. Upgrading from 2.4.x</A></H1>
<P>The following sections attempt to document the steps you will need to take in order to upgrade from the latest 2.4.x OpenLDAP version.</P>
<P>The normal upgrade procedure, as discussed in the <A HREF="#Maintenance">Maintenance</A> section, should of course still be followed prior to doing any of this.</P>
<H2><A NAME="{{B:cn=config}} olc* attributes">B.1. <B>cn=config</B> olc* attributes</A></H2>
<H2><A NAME="ppolicy overlay">B.2. ppolicy overlay</A></H2>
<P>The overlay now implements version 10 of the ppolicy draft in full. This includes the notion of a password administrator where applicable (as determined by having a <EM>manage</EM> permission to the <EM>userPassword</EM> attribute) and skips certain processing when there is no valid policy in effect or where the operation is initiated by a password administrator. Many attributes are now tagged with <EM>NO-USER-MODIFICATION</EM> in the schema, requiring the use of <EM>relax</EM> control to modify them.</P>
<P>In OpenLDAP 2.4 the <EM>slapo-ppolicy</EM>(5) overlay relied on a separate schema file to be included for it to function. This schema is now implemented internally in the slapo-ppolicy module. When upgrading <EM>slapd.conf</EM>(5) deployments the include statement for the schema must be removed.  For <EM>slapd-config</EM>(5) deployments, the config database must be exported via slapcat and the old ppolicy schema removed from the export.  The resulting config database can then be imported.</P>
<H2><A NAME="unique overlay">B.3. unique overlay</A></H2>
<P>In OpenLDAP 2.4 it was possible to bypass <EM>slapo-unique</EM>(5) checks by using the manageDSAIT control as a part of the request. This is no longer possible. To achieve the same functionality the relax control must be used instead, and the binding identity must have manage permissions on the entry being modified.</P>
<P>With OpenLDAP 2.5 a new keyword &quot;serialize&quot; has been added as a part of the unique_uri configuration parameter. This will cause all write operations requiring uniqueness to be serialized so as to avoid the scenario where multiple concurrent updates can prevent uniqueness from being enforced. See the <EM>slapo-unique</EM>(5) man page for further details.</P>
<H2><A NAME="ldap and meta backends">B.4. ldap and meta backends</A></H2>
<P>Several deprecated configuration directives for <EM>slapd-ldap</EM>(5) and <EM>slapd-meta</EM>(5) have been removed. Configurations using those directive must be updated to use supported directives prior to upgrade.  See the <EM>slapd-ldap</EM>(5) and <EM>slapd-meta</EM>(5) man pages from OpenLDAP 2.4 for a list of deprecated directives.</P>
<H2><A NAME="shell backend">B.5. shell backend</A></H2>
<P>This deprecated backend has been removed from OpenLDAP 2.5. Configurations making use of this backend must remove it prior to upgrade. The <EM>slapd-sock</EM>(5) backend is recommended as an alternative.</P>
<H2><A NAME="perl and sql backends">B.6. perl and sql backends</A></H2>
<P>The <EM>slapd-perl</EM>(5) and <EM>slapd-sql</EM>(5) backends are now deprecated and no longer automatically enabled with the --enable-backends configure flag.</P>
<H2><A NAME="hdb and bdb backends">B.7. hdb and bdb backends</A></H2>
<P>The Berkeley DB based slapd-bdb and slapd-hdb backends have been removed from OpenLDAP 2.5. Deployments making use of these backends must migrate their configurations to use <EM>slapd-mdb</EM>(5) prior to upgrade.</P>
<H2><A NAME="mdb backend">B.8. mdb backend</A></H2>
<P>Due to database format changes between OpenLDAP 2.4 and OpenLDAP 2.5 it is mandatory for existing <EM>slapd-mdb</EM>(5) databases to be exported via an OpenLDAP 2.4 slapcat prior to upgrade. They must then be reloaded via an OpenLDAP 2.5 slapadd after the binaries are updated. It is also advised to determine if the new <EM>slapd-mdb</EM>(5) idlexp backend directive and/or the multival database directive should be added to the OpenLDAP 2.5 configuration prior to import.</P>
<P></P>
<HR>
<H1><A NAME="Common errors encountered when using OpenLDAP Software">C. Common errors encountered when using OpenLDAP Software</A></H1>
<P>The following sections attempt to summarize the most common causes of LDAP errors when using OpenLDAP</P>
<H2><A NAME="Common causes of LDAP errors">C.1. Common causes of LDAP errors</A></H2>
<H3><A NAME="ldap_*: Can\'t contact LDAP server">C.1.1. ldap_*: Can't contact LDAP server</A></H3>
<P>The <B>Can't contact LDAP server</B> error is usually returned when the LDAP server cannot be contacted. This may occur for many reasons:</P>
<UL>
<LI>the LDAP server is not running; this can be checked by running, for example,</UL>
<PRE>
      telnet &lt;host&gt; &lt;port&gt;
</PRE>
<P>replacing <EM>&lt;host&gt;</EM> and <EM>&lt;port&gt;</EM> with the hostname and the port the server is supposed to listen on.</P>
<UL>
<LI>the client has not been instructed to contact a running server; with OpenLDAP command-line tools this is accomplished by providing the -H switch, whose argument is a valid LDAP url corresponding to the interface the server is supposed to be listening on.</UL>
<H3><A NAME="ldap_*: No such object">C.1.2. ldap_*: No such object</A></H3>
<P>The <B>no such object</B> error is generally returned when the target DN of the operation cannot be located. This section details reasons common to all operations. You should also look for answers specific to the operation (as indicated in the error message).</P>
<P>The most common reason for this error is non-existence of the named object. First, check for typos.</P>
<P>Also note that, by default, a new directory server holds no objects (except for a few system entries). So, if you are setting up a new directory server and get this message, it may simply be that you have yet to add the object you are trying to locate.</P>
<P>The error commonly occurs because a DN was not specified and a default was not properly configured.</P>
<P>If you have a suffix specified in slapd.conf eg.</P>
<PRE>
      suffix &quot;dc=example,dc=com&quot;
</PRE>
<P>You should use</P>
<PRE>
      ldapsearch -b 'dc=example,dc=com' '(cn=jane*)'
</PRE>
<P>to tell it where to start the search.</P>
<P>The <TT>-b</TT> should be specified for all LDAP commands unless you have an <EM>ldap.conf</EM>(5) default configured.</P>
<P>See <EM>ldapsearch</EM>(1), <EM>ldapmodify</EM>(1)</P>
<P>Also, <EM>slapadd</EM>(8) and its ancillary programs are very strict about the syntax of the LDIF file.</P>
<P>Some liberties in the LDIF file may result in an apparently successful creation of the database, but accessing some parts of it may be difficult.</P>
<P>One known common error in database creation is putting a blank line before the first entry in the LDIF file. <B>There must be no leading blank lines in the LDIF file.</B></P>
<P>It is generally recommended that <EM>ldapadd</EM>(1) be used instead of <EM>slapadd</EM>(8) when adding new entries your directory. <EM>slapadd</EM>(8) should be used to bulk load entries known to be valid.</P>
<P>Another cause of this message is a referral ({SECT:Constructing a Distributed Directory Service}}) entry to an unpopulated directory.</P>
<P>Either remove the referral, or add a single record with the referral base DN to the empty directory.</P>
<P>This error may also occur when slapd is unable to access the contents of its database because of file permission problems. For instance, on a Red Hat Linux system, slapd runs as user 'ldap'. When slapadd is run as root to create a database from scratch, the contents of <TT>/var/lib/ldap</TT> are created with user and group root and with permission 600, making the contents inaccessible to the slapd server.</P>
<H3><A NAME="ldap_*: Can\'t chase referral">C.1.3. ldap_*: Can't chase referral</A></H3>
<P>This is caused by the line</P>
<PRE>
      referral        ldap://root.openldap.org
</PRE>
<P>In <TT>slapd.conf</TT>, it was provided as an example for how to use referrals in the original file. However if your machine is not permanently connected to the Internet, it will fail to find the server, and hence produce an error message.</P>
<P>To resolve, just place a # in front of line and restart slapd or point it to an available ldap server.</P>
<P>See also: <EM>ldapadd</EM>(1), <EM>ldapmodify</EM>(1) and <EM>slapd.conf</EM>(5)</P>
<H3><A NAME="ldap_*: server is unwilling to perform">C.1.4. ldap_*: server is unwilling to perform</A></H3>
<P>slapd will return an unwilling to perform error if the backend holding the target entry does not support the given operation.</P>
<P>The password backend is only willing to perform searches. It will return an unwilling to perform error for all other operations.</P>
<H3><A NAME="ldap_*: Insufficient access">C.1.5. ldap_*: Insufficient access</A></H3>
<P>This error occurs when server denies the operation due to insufficient access. This is usually caused by binding to a DN with insufficient privileges (or binding anonymously) to perform the operation.</P>
<P>You can bind as the rootdn/rootpw specified in <EM>slapd.conf</EM>(5) to gain full access. Otherwise, you must bind to an entry which has been granted the appropriate rights through access controls.</P>
<H3><A NAME="ldap_*: Invalid DN syntax">C.1.6. ldap_*: Invalid DN syntax</A></H3>
<P>The target (or other) DN of the operation is invalid. This implies that either the string representation of the DN is not in the required form, one of the types in the attribute value assertions is not defined, or one of the values in the attribute value assertions does not conform to the appropriate syntax.</P>
<H3><A NAME="ldap_*: Referral hop limit exceeded">C.1.7. ldap_*: Referral hop limit exceeded</A></H3>
<P>This error generally occurs when the client chases a referral which refers itself back to a server it already contacted. The server responds as it did before and the client loops. This loop is detected when the hop limit is exceeded.</P>
<P>This is most often caused through misconfiguration of the server's default referral. The default referral should not be itself:</P>
<P>That is, on <A HREF="ldap://myldap/">ldap://myldap/</A> the default referral should not be <A HREF="ldap://myldap/">ldap://myldap/</A> (or any hostname/ip which is equivalent to myldap).</P>
<H3><A NAME="ldap_*: operations error">C.1.8. ldap_*: operations error</A></H3>
<P>In some versions of <EM>slapd</EM>(8), <EM>operationsError</EM> was returned instead of other.</P>
<H3><A NAME="ldap_*: other error">C.1.9. ldap_*: other error</A></H3>
<P>The other result code indicates an internal error has occurred. While the additional information provided with the result code might provide some hint as to the problem, often one will need to consult the server's log files.</P>
<H3><A NAME="ldap_add/modify: Invalid syntax">C.1.10. ldap_add/modify: Invalid syntax</A></H3>
<P>This error is reported when a value of an attribute does not conform to syntax restrictions. Additional information is commonly provided stating which value of which attribute was found to be invalid. Double check this value and other values (the server will only report the first error it finds).</P>
<P>Common causes include:</P>
<UL>
<LI>extraneous whitespace (especially trailing whitespace)
<LI>improperly encoded characters (LDAPv3 uses UTF-8 encoded Unicode)
<LI>empty values (few syntaxes allow empty values)</UL>
<P>For certain syntax, like OBJECT IDENTIFIER (OID), this error can indicate that the OID descriptor (a &quot;short name&quot;) provided is unrecognized. For instance, this error is returned if the <EM>objectClass</EM> value provided is unrecognized.</P>
<H3><A NAME="ldap_add/modify: Object class violation">C.1.11. ldap_add/modify: Object class violation</A></H3>
<P>This error is returned with the entry to be added or the entry as modified violates the object class schema rules. Normally additional information is returned the error detailing the violation. Some of these are detailed below.</P>
<P>Violations related to the entry's attributes:</P>
<PRE>
      Attribute not allowed
</PRE>
<P>A provided attribute is not allowed by the entry's object class(es).</P>
<PRE>
      Missing required attribute
</PRE>
<P>An attribute required by the entry's object class(es) was not provided.</P>
<P>Violations related to the entry's class(es):</P>
<PRE>
      Entry has no objectClass attribute
</PRE>
<P>The entry did not state which object classes it belonged to.</P>
<PRE>
      Unrecognized objectClass
</PRE>
<P>One (or more) of the listed objectClass values is not recognized.</P>
<PRE>
      No structural object class provided
</PRE>
<P>None of the listed objectClass values is structural.</P>
<PRE>
      Invalid structural object class chain
</PRE>
<P>Two or more structural objectClass values are not in same structural object class chain.</P>
<PRE>
      Structural object class modification
</PRE>
<P>Modify operation attempts to change the structural class of the entry.</P>
<PRE>
      Instantiation of abstract objectClass.
</PRE>
<P>An abstract class is not subordinate to any listed structural or auxiliary class.</P>
<PRE>
      Invalid structural object class
</PRE>
<P>Other structural object class problem.</P>
<PRE>
      No structuralObjectClass operational attribute
</PRE>
<P>This is commonly returned when a shadow server is provided an entry which does not contain the structuralObjectClass operational attribute.</P>
<P>Note that the above error messages as well as the above answer assumes basic knowledge of LDAP/X.500 schema.</P>
<H3><A NAME="ldap_add: No such object">C.1.12. ldap_add: No such object</A></H3>
<P>The &quot;ldap_add: No such object&quot; error is commonly returned if parent of the entry being added does not exist. Add the parent entry first...</P>
<P>For example, if you are adding &quot;cn=bob,dc=domain,dc=com&quot; and you get:</P>
<PRE>
      ldap_add: No such object
</PRE>
<P>The entry &quot;dc=domain,dc=com&quot; likely doesn't exist. You can use ldapsearch to see if does exist:</P>
<PRE>
      ldapsearch -b 'dc=domain,dc=com' -s base '(objectclass=*)'
</PRE>
<P>If it doesn't, add it. See <A HREF="#A Quick-Start Guide">A Quick-Start Guide</A> for assistance.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>if the entry being added is the same as database suffix, it's parent isn't required. i.e.: if your suffix is &quot;dc=domain,dc=com&quot;, &quot;dc=com&quot; doesn't need to exist to add &quot;dc=domain,dc=com&quot;.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>This error will also occur if you try to add any entry that the server is not configured to hold.</P>
<P>For example, if your database suffix is &quot;dc=domain,dc=com&quot; and you attempt to add &quot;dc=domain2,dc=com&quot;, &quot;dc=com&quot;, &quot;dc=domain,dc=org&quot;, &quot;o=domain,c=us&quot;, or an other DN in the &quot;dc=domain,dc=com&quot; subtree, the server will return a &quot;No such object&quot; (or referral) error.</P>
<P><EM>slapd</EM>(8) will generally return &quot;no global superior knowledge&quot; as additional information indicating its return noSuchObject instead of a referral as the server is not configured with knowledge of a global superior server.</P>
<H3><A NAME="ldap add: invalid structural object class chain">C.1.13. ldap add: invalid structural object class chain</A></H3>
<P>This particular error refers to the rule about STRUCTURAL objectclasses, which states that an object is of one STRUCTURAL class, the structural class of the object. The object is said to belong to this class, zero or more auxiliaries classes, and their super classes.</P>
<P>While all of these classes are commonly listed in the objectClass attribute of the entry, one of these classes is the structural object class of the entry. Thus, it is OK for an objectClass attribute to contain inetOrgPerson, organizationalPerson, and person because they inherit one from another to form a single super class chain. That is, inetOrgPerson SUPs organizationPerson SUPs person. On the other hand, it is invalid for both inetOrgPerson and account to be listed in objectClass as inetOrgPerson and account are not part of the same super class chain (unless some other class is also listed with is a subclass of both).</P>
<P>To resolve this problem, one must determine which class will better serve structural object class for the entry, adding this class to the objectClass attribute (if not already present), and remove any other structural class from the entry's objectClass attribute which is not a super class of the structural object class.</P>
<P>Which object class is better depends on the particulars of the situation. One generally should consult the documentation for the applications one is using for help in making the determination.</P>
<H3><A NAME="ldap_add: no structuralObjectClass operational attribute">C.1.14. ldap_add: no structuralObjectClass operational attribute</A></H3>
<P>ldapadd(1) may error:</P>
<PRE>
      adding new entry &quot;uid=XXX,ou=People,o=campus,c=ru&quot;
        ldap_add: Internal (implementation specific) error (80)
           additional info: no structuralObjectClass operational attribute
</PRE>
<P>when slapd(8) cannot determine, based upon the contents of the objectClass attribute, what the structural class of the object should be.</P>
<H3><A NAME="ldap_add/modify/rename: Naming violation">C.1.15. ldap_add/modify/rename: Naming violation</A></H3>
<P>OpenLDAP's slapd checks for naming attributes and distinguished values consistency, according to RFC 4512.</P>
<P>Naming attributes are those attributeTypes that appear in an entry's RDN; distinguished values are the values of the naming attributes that appear in an entry's RDN, e.g, in</P>
<PRE>
      cn=Someone+mail=someone@example.com,dc=example,dc=com
</PRE>
<P>the naming attributes are cn and mail, and the distinguished values are Someone and someone@example.com.</P>
<P>OpenLDAP's slapd checks for consistency when:</P>
<UL>
<LI>adding an entry
<LI>modifying an entry, if the values of the naming attributes are changed
<LI>renaming an entry, if the RDN of the entry changes</UL>
<P>Possible causes of error are:</P>
<UL>
<LI>the naming attributes are not present in the entry; for example:</UL>
<PRE>
                dn: dc=example,dc=com
                objectClass: organization
                o: Example
                # note: &quot;dc: example&quot; is missing
</PRE>
<UL>
<LI>the naming attributes are present in the entry, but in the attributeType definition they are marked as:<UL>
<LI>collective
<LI>operational
<LI>obsolete</UL>
<LI>the naming attributes are present in the entry, but the distinguished values are not; for example:</UL>
<PRE>
                dn: dc=example,dc=com
                objectClass: domain
                dc: foobar
                # note: &quot;dc&quot; is present, but the value is not &quot;example&quot;
</PRE>
<UL>
<LI>the naming attributes are present in the entry, with the distinguished values, but the naming attributes:<UL>
<LI>do not have an equality field, so equality cannot be asserted
<LI>the matching rule is not supported (yet)
<LI>the matching rule is not appropriate</UL>
<LI>the given distinguished values do not comply with their syntax
<LI>other errors occurred during the validation/normalization/match process; this is a catchall: look at previous logs for details in case none of the above apply to your case.</UL>
<P>In any case, make sure that the attributeType definition for the naming attributes contains an appropriate EQUALITY field; or that of the superior, if they are defined based on a superior attributeType (look at the SUP field). See RFC 4512 for details.</P>
<H3><A NAME="ldap_add/delete/modify/rename: no global superior knowledge">C.1.16. ldap_add/delete/modify/rename: no global superior knowledge</A></H3>
<P>If the target entry name places is not within any of the databases the server is configured to hold and the server has no knowledge of a global superior, the server will indicate it is unwilling to perform the operation and provide the text &quot;no global superior knowledge&quot; as additional text.</P>
<P>Likely the entry name is incorrect, or the server is not properly configured to hold the named entry, or, in distributed directory environments, a default referral was not configured.</P>
<H3><A NAME="ldap_bind: Insufficient access">C.1.17. ldap_bind: Insufficient access</A></H3>
<P>Current versions of slapd(8) requires that clients have authentication permission to attribute types used for authentication purposes before accessing them to perform the bind operation. As all bind operations are done anonymously (regardless of previous bind success), the auth access must be granted to anonymous.</P>
<P>In the example ACL below grants the following access:</P>
<UL>
<LI>to anonymous users:<UL>
<LI>permission to authenticate using values of userPassword</UL>
<LI>to authenticated users:<UL>
<LI>permission to update (but not read) their userPassword
<LI>permission to read any object excepting values of userPassword</UL></UL>
<P>All other access is denied.</P>
<PRE>
        access to attr=userPassword
          by self =w
          by anonymous auth
        access *
          by self write
          by users read
</PRE>
<H3><A NAME="ldap_bind: Invalid credentials">C.1.18. ldap_bind: Invalid credentials</A></H3>
<P>The error usually occurs when the credentials (password) provided does not match the userPassword held in entry you are binding to.</P>
<P>The error can also occur when the bind DN specified is not known to the server.</P>
<P>Check both! In addition to the cases mentioned above you should check if the server denied access to userPassword on selected parts of the directory. In fact, slapd always returns &quot;Invalid credentials&quot; in case of failed bind, regardless of the failure reason, since other return codes could reveal the validity of the user's name.</P>
<P>To debug access rules defined in slapd.conf, add &quot;ACL&quot; to log level.</P>
<H3><A NAME="ldap_bind: Protocol error">C.1.19. ldap_bind: Protocol error</A></H3>
<P>There error is generally occurs when the LDAP version requested by the client is not supported by the server.</P>
<P>The OpenLDAP Software 2.x server, by default, only accepts version 3 LDAP Bind requests but can be configured to accept a version 2 LDAP Bind request.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>The 2.x server expects LDAPv3 [RFC4510] to be used when the client requests version 3 and expects a limited LDAPv3 variant (basically, LDAPv3 syntax and semantics in an LDAPv2 PDUs) to be used when version 2 is expected.
<HR WIDTH="80%" ALIGN="Left"></P>
<P>This variant is also sometimes referred to as LDAPv2+, but differs from the U-Mich LDAP variant in a number of ways.</P>
<H3><A NAME="ldap_modify: cannot modify object class">C.1.20. ldap_modify: cannot modify object class</A></H3>
<P>This message is commonly returned when attempting to modify the objectClass attribute in a manner inconsistent with the LDAP/X.500 information model. In particular, it commonly occurs when one tries to change the structure of the object from one class to another, for instance, trying to change an 'apple' into a 'pear' or a 'fruit' into a 'pear'.</P>
<P>Such changes are disallowed by the slapd(8) in accordance with LDAP and X.500 restrictions.</P>
<H3><A NAME="ldap_sasl_interactive_bind_s: ..">C.1.21. ldap_sasl_interactive_bind_s: ...</A></H3>
<P>If you intended to bind using a DN and password and get an error from ldap_sasl_interactive_bind_s, you likely forgot to provide a '-x' option to the command. By default, SASL authentication is used. '-x' is necessary to select &quot;simple&quot; authentication.</P>
<H3><A NAME="ldap_sasl_interactive_bind_s: No such Object">C.1.22. ldap_sasl_interactive_bind_s: No such Object</A></H3>
<P>This indicates that LDAP SASL authentication function could not read the Root DSE. The error will occur when the server doesn't provide a root DSE. This may be due to access controls.</P>
<H3><A NAME="ldap_sasl_interactive_bind_s: No such attribute">C.1.23. ldap_sasl_interactive_bind_s: No such attribute</A></H3>
<P>This indicates that LDAP SASL authentication function could read the Root DSE but it contained no supportedSASLMechanism attribute.</P>
<P>The supportedSASLmechanism attribute lists mechanisms currently available. The list may be empty because none of the supported mechanisms are currently available. For example, EXTERNAL is listed only if the client has established its identity by authenticating at a lower level (e.g. TLS).</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>the attribute may not be visible due to access controls
<HR WIDTH="80%" ALIGN="Left"></P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>SASL bind is the default for all OpenLDAP tools, e.g. ldapsearch(1), ldapmodify(1). To force use of &quot;simple&quot; bind, use the &quot;-x&quot; option. Use of &quot;simple&quot; bind is not recommended unless one has adequate confidentiality protection in place (e.g. TLS/SSL, IPSEC).
<HR WIDTH="80%" ALIGN="Left"></P>
<H3><A NAME="ldap_sasl_interactive_bind_s: Unknown authentication method">C.1.24. ldap_sasl_interactive_bind_s: Unknown authentication method</A></H3>
<P>This indicates that none of the SASL authentication supported by the server are supported by the client, or that they are too weak or otherwise inappropriate for use by the client. Note that the default security options disallows the use of certain mechanisms such as ANONYMOUS and PLAIN (without TLS).</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>SASL bind is the default for all OpenLDAP tools. To force use of &quot;simple&quot; bind, use the &quot;-x&quot; option. Use of &quot;simple&quot; bind is not recommended unless one has adequate confidentiality protection in place (e.g. TLS/SSL, IPSEC).
<HR WIDTH="80%" ALIGN="Left"></P>
<H3><A NAME="ldap_sasl_interactive_bind_s: Local error (82)">C.1.25. ldap_sasl_interactive_bind_s: Local error (82)</A></H3>
<P>Apparently not having forward and reverse DNS entries for the LDAP server can result in this error.</P>
<H3><A NAME="ldap_search: Partial results and referral received">C.1.26. ldap_search: Partial results and referral received</A></H3>
<P>This error is returned with the server responses to an LDAPv2 search query with both results (zero or more matched entries) and references (referrals to other servers). See also: ldapsearch(1).</P>
<P>If the updatedn on the replica does not exist, a referral will be returned. It may do this as well if the ACL needs tweaking.</P>
<H3><A NAME="ldap_start_tls: Operations error">C.1.27. ldap_start_tls: Operations error</A></H3>
<P>ldapsearch(1) and other tools will return</P>
<PRE>
        ldap_start_tls: Operations error (1)
              additional info: TLS already started
</PRE>
<P>When the user (though command line options and/or ldap.conf(5)) has requested TLS (SSL) be started twice. For instance, when specifying both &quot;-H ldaps://server.do.main&quot; and &quot;-ZZ&quot;.</P>
<H2><A NAME="Other Errors">C.2. Other Errors</A></H2>
<H3><A NAME="ber_get_next on fd X failed errno=34 (Numerical result out of range)">C.2.1. ber_get_next on fd X failed errno=34 (Numerical result out of range)</A></H3>
<P>This slapd error generally indicates that the client sent a message that exceeded an administrative limit. See sockbuf_max_incoming and sockbuf_max_incoming_auth configuration directives in slapd.conf(5).</P>
<H3><A NAME="ber_get_next on fd X failed errno=11 (Resource temporarily unavailable)">C.2.2. ber_get_next on fd X failed errno=11 (Resource temporarily unavailable)</A></H3>
<P>This message is not indicative of abnormal behavior or error. It simply means that expected data is not yet available from the resource, in this context, a network socket. slapd(8) will process the data once it does becomes available.</P>
<H3><A NAME="daemon: socket() failed errno=97 (Address family not supported)">C.2.3. daemon: socket() failed errno=97 (Address family not supported)</A></H3>
<P>This message indicates that the operating system does not support one of the (protocol) address families which slapd(8) was configured to support. Most commonly, this occurs when slapd(8) was configured to support IPv6 yet the operating system kernel wasn't. In such cases, the message can be ignored.</P>
<H3><A NAME="GSSAPI: gss_acquire_cred: Miscellaneous failure; Permission denied;">C.2.4. GSSAPI: gss_acquire_cred: Miscellaneous failure; Permission denied;</A></H3>
<P>This message means that slapd is not running as root and, thus, it cannot get its Kerberos 5 key from the keytab, usually file /etc/krb5.keytab.</P>
<P>A keytab file is used to store keys that are to be used by services or daemons that are started at boot time. It is very important that these secrets are kept beyond reach of intruders.</P>
<P>That's why the default keytab file is owned by root and protected from being read by others. Do not mess with these permissions, build a different keytab file for slapd instead, and make sure it is owned by the user that slapd runs as.</P>
<P>To do this, start kadmin, and enter the following commands:</P>
<PRE>
     addprinc -randkey ldap/ldap.example.com@EXAMPLE.COM
     ktadd -k /etc/openldap/ldap.keytab ldap/ldap.example.com@EXAMPLE.COM
</PRE>
<P>Then, on the shell, do:</P>
<PRE>
     chown ldap:ldap /etc/openldap/ldap.keytab
     chmod 600 /etc/openldap/ldap.keytab
</PRE>
<P>Now you have to tell slapd (well, actually tell the gssapi library in Kerberos 5 that is invoked by Cyrus SASL) where to find the new keytab. You do this by setting the environment variable KRB5_KTNAME like this:</P>
<PRE>
     export KRB5_KTNAME=&quot;FILE:/etc/openldap/ldap.keytab&quot;
</PRE>
<P>Set that environment variable on the slapd start script (Red Hat users might find /etc/sysconfig/ldap a perfect place).</P>
<P>This only works if you are using MIT kerberos. It doesn't work with Heimdal, for instance.</P>
<P>In Heimdal there is a function gsskrb5_register_acceptor_identity() that sets the path of the keytab file you want to use. In Cyrus SASL 2 you can add</P>
<PRE>
    keytab: /path/to/file
</PRE>
<P>to your application's SASL config file to use this feature. This only works with Heimdal.</P>
<H3><A NAME="access from unknown denied">C.2.5. access from unknown denied</A></H3>
<P>This related to TCP wrappers. See hosts_access(5) for more information. in the log file: &quot;access from unknown denied&quot; This related to TCP wrappers. See hosts_access(5) for more information. for example: add the line &quot;slapd: .hosts.you.want.to.allow&quot; in /etc/hosts.allow to get rid of the error.</P>
<H3><A NAME="ldap_read: want=# error=Resource temporarily unavailable">C.2.6. ldap_read: want=# error=Resource temporarily unavailable</A></H3>
<P>This message occurs normally. It means that pending data is not yet available from the resource, a network socket. slapd(8) will process the data once it becomes available.</P>
<H3><A NAME="`make test\' fails">C.2.7. `make test' fails</A></H3>
<P>Some times, `make test' fails at the very first test with an obscure message like</P>
<PRE>
    make test
    make[1]: Entering directory `/ldap_files/openldap-2.5.0/tests'
    make[2]: Entering directory `/ldap_files/openldap-2.5.0/tests'
    Initiating LDAP tests for MDB...
    Cleaning up test run directory leftover from previous run.
     Running ./scripts/all...
    &gt;&gt;&gt;&gt;&gt; Executing all LDAP tests for mdb
    &gt;&gt;&gt;&gt;&gt; Starting test000-rootdse ...
    running defines.sh
    Starting slapd on TCP/IP port 9011...
    Using ldapsearch to retrieve the root DSE...
    Waiting 5 seconds for slapd to start...
    ./scripts/test000-rootdse: line 40: 10607 Segmentation fault $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING &gt;$LOG1 2&gt;&amp;1
    Waiting 5 seconds for slapd to start...
    Waiting 5 seconds for slapd to start...
    Waiting 5 seconds for slapd to start...
    Waiting 5 seconds for slapd to start...
    Waiting 5 seconds for slapd to start...
    ./scripts/test000-rootdse: kill: (10607) - No such pid
    ldap_sasl_bind_s: Can't contact LDAP server (-1)
    &gt;&gt;&gt;&gt;&gt; Test failed
    &gt;&gt;&gt;&gt;&gt; ./scripts/test000-rootdse failed (exit 1)
    make[2]: *** [mdb-yes] Error 1
    make[2]: Leaving directory `/ldap_files/openldap-2.5.0/tests'
    make[1]: *** [test] Error 2
    make[1]: Leaving directory `/ldap_files/openldap-2.5.0/tests'
    make: *** [test] Error 2
</PRE>
<P>or so. Usually, the five lines</P>
<P>Waiting 5 seconds for slapd to start...</P>
<P>indicate that slapd didn't start at all.</P>
<P>In tests/testrun/slapd.1.log there is a full log of what slapd wrote while trying to start. The log level can be increased by setting the environment variable SLAPD_DEBUG to the corresponding value; see loglevel in slapd.conf(5) for the meaning of log levels.</P>
<P>A typical reason for this behavior is a runtime link problem, i.e. slapd cannot find some dynamic libraries it was linked against. Try running ldd(1) on slapd (for those architectures that support runtime linking).</P>
<P>There might well be other reasons; the contents of the log file should help clarifying them.</P>
<P>Tests that fire up multiple instances of slapd typically log to tests/testrun/slapd.&lt;n&gt;.log, with a distinct &lt;n&gt; for each instance of slapd; list tests/testrun/ for possible values of &lt;n&gt;.</P>
<H3><A NAME="ldap_*: Internal (implementation specific) error (80) - additional info: entry index delete failed">C.2.8. ldap_*: Internal (implementation specific) error (80) - additional info: entry index delete failed</A></H3>
<P>This seems to be related with wrong ownership of the MDB's dir (/var/lib/ldap) and files. The files must be owned by the user that slapd runs as.</P>
<PRE>
    chown -R ldap:ldap /var/lib/ldap
</PRE>
<P>fixes it in Debian</P>
<H3><A NAME="ldap_sasl_interactive_bind_s: Can\'t contact LDAP server (-1)">C.2.9. ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)</A></H3>
<P>Using SASL, when a client contacts LDAP server, the slapd service dies immediately and client gets an error :</P>
<PRE>
     SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
</PRE>
<P>Then check the slapd service, it stopped.</P>
<P></P>
<HR>
<H1><A NAME="Recommended OpenLDAP Software Dependency Versions">D. Recommended OpenLDAP Software Dependency Versions</A></H1>
<P>This appendix details the recommended versions of the software that OpenLDAP depends on.</P>
<P>Please read the <A HREF="#Prerequisite software">Prerequisite software</A> section for more information on the following software dependencies.</P>
<H2><A NAME="Dependency Versions">D.1. Dependency Versions</A></H2>
<TABLE CLASS="columns" BORDER ALIGN='Center'>
<CAPTION ALIGN=top>Table 8.5: OpenLDAP Software Dependency Versions</CAPTION>
<TR CLASS="heading">
<TD>
<STRONG>Feature</STRONG>
</TD>
<TD>
<STRONG>Software</STRONG>
</TD>
<TD>
<STRONG>Version</STRONG>
</TD>
</TR>
<TR>
<TD>
&nbsp;<TERM>Transport Layer Security</TERM>:
</TD>
<TD>
<TT>&nbsp;</TT>
</TD>
<TD>
<TT>&nbsp;</TT>
</TD>
</TR>
<TR>
<TD>
&nbsp;
</TD>
<TD>
<TT>&nbsp;<A HREF="https://www.openssl.org/">OpenSSL</A></TT>
</TD>
<TD>
<TT>1.1.1+</TT>
</TD>
</TR>
<TR>
<TD>
&nbsp;
</TD>
<TD>
<TT>&nbsp;<A HREF="https://gnutls.org/">GnuTLS</A></TT>
</TD>
<TD>
<TT>3.6.0+</TT>
</TD>
</TR>
<TR>
<TD>
&nbsp;<TERM>Simple Authentication and Security Layer</TERM>
</TD>
<TD>
<TT>&nbsp;<A HREF="https://www.cyrusimap.org/sasl/">Cyrus SASL</A></TT>
</TD>
<TD>
<TT>2.1.27+</TT>
</TD>
</TR>
<TR>
<TD>
&nbsp;<TERM>LDAP Load Balancer</TERM>
</TD>
<TD>
<TT>&nbsp;<A HREF="https://libevent.org/">libevent</A></TT>
</TD>
<TD>
<TT>2.1+</TT>
</TD>
</TR>
<TR>
<TD>
Threads:
</TD>
<TD>
<TT>POSIX <EM>pthreads</EM></TT>
</TD>
<TD>
<TT>Version</TT>
</TD>
</TR>
</TABLE>

<P></P>
<HR>
<H1><A NAME="Real World OpenLDAP Deployments and Examples">E. Real World OpenLDAP Deployments and Examples</A></H1>
<P>Examples and discussions</P>
<P></P>
<HR>
<H1><A NAME="OpenLDAP Software Contributions">F. OpenLDAP Software Contributions</A></H1>
<P>The following sections attempt to summarize the various contributions in OpenLDAP software, as found in <TT>openldap_src/contrib</TT></P>
<H2><A NAME="Client APIs">F.1. Client APIs</A></H2>
<P>Intro and discuss</P>
<H3><A NAME="ldapc++">F.1.1. ldapc++</A></H3>
<P>Intro and discuss</P>
<H3><A NAME="ldaptcl">F.1.2. ldaptcl</A></H3>
<P>Intro and discuss</P>
<H2><A NAME="Overlays">F.2. Overlays</A></H2>
<H3><A NAME="acl">F.2.1. acl</A></H3>
<P>Plugins that implement access rules.  Currently only posixGroup, which implements access control based on posixGroup membership.</P>
<H3><A NAME="addpartial">F.2.2. addpartial</A></H3>
<P>Treat Add requests as Modify requests if the entry exists.</P>
<H3><A NAME="allop">F.2.3. allop</A></H3>
<P>Return operational attributes for root DSE even when not requested, since some clients expect this.</P>
<H3><A NAME="autogroup">F.2.4. autogroup</A></H3>
<P>Automated updates of group memberships.</P>
<H3><A NAME="comp_match">F.2.5. comp_match</A></H3>
<P>Component Matching rules (RFC 3687).</P>
<H3><A NAME="denyop">F.2.6. denyop</A></H3>
<P>Deny selected operations, returning <EM>unwillingToPerform</EM>.</P>
<H3><A NAME="dsaschema">F.2.7. dsaschema</A></H3>
<P>Permit loading DSA-specific schema, including operational attrs.</P>
<H3><A NAME="lastmod">F.2.8. lastmod</A></H3>
<P>Track the time of the last write operation to a database.</P>
<H3><A NAME="nops">F.2.9. nops</A></H3>
<P>Remove null operations, e.g. changing a value to same as before.</P>
<H3><A NAME="nssov">F.2.10. nssov</A></H3>
<P>Handle NSS lookup requests through a local Unix Domain socket.</P>
<H3><A NAME="passwd">F.2.11. passwd</A></H3>
<P>Support additional password mechanisms.</P>
<H3><A NAME="proxyOld">F.2.12. proxyOld</A></H3>
<P>Proxy Authorization compatibility with obsolete internet-draft.</P>
<H3><A NAME="smbk5pwd">F.2.13. smbk5pwd</A></H3>
<P>Make the PasswordModify Extended Operation update Kerberos keys and Samba password hashes as well as <EM>userPassword</EM>.</P>
<H3><A NAME="trace">F.2.14. trace</A></H3>
<P>Trace overlay invocation.</P>
<H3><A NAME="usn">F.2.15. usn</A></H3>
<P>Maintain <EM>usnCreated</EM> and <EM>usnChanged</EM> attrs similar to Microsoft AD.</P>
<H2><A NAME="Tools">F.3. Tools</A></H2>
<P>Intro and discuss</P>
<H3><A NAME="Statistic Logging">F.3.1. Statistic Logging</A></H3>
<P>statslog</P>
<H2><A NAME="SLAPI Plugins">F.4. SLAPI Plugins</A></H2>
<P>Intro and discuss</P>
<H3><A NAME="addrdnvalues">F.4.1. addrdnvalues</A></H3>
<P>More</P>
<P></P>
<HR>
<H1><A NAME="Configuration File Examples">G. Configuration File Examples</A></H1>
<H2><A NAME="slapd.conf">G.1. slapd.conf</A></H2>
<H2><A NAME="ldap.conf">G.2. ldap.conf</A></H2>
<H2><A NAME="a-n-other.conf">G.3. a-n-other.conf</A></H2>
<P></P>
<HR>
<H1><A NAME="LDAP Result Codes">H. LDAP Result Codes</A></H1>
<P>For the purposes of this guide, we have incorporated the standard LDAP result codes from <EM>Appendix A.  LDAP Result Codes</EM> of <A HREF="https://www.rfc-editor.org/rfc/rfc4511.txt">RFC4511</A>, a copy of which can be found in <TT>doc/rfc</TT> of the OpenLDAP source code.</P>
<P>We have expanded the description of each error in relation to the OpenLDAP toolsets. LDAP extensions may introduce extension-specific result codes, which are not part of RFC4511. OpenLDAP returns the result codes related to extensions it implements. Their meaning is documented in the extension they are related to.</P>
<H2><A NAME="Non-Error Result Codes">H.1. Non-Error Result Codes</A></H2>
<P>These result codes (called &quot;non-error&quot; result codes) do not indicate an error condition:</P>
<PRE>
        success (0),
        compareFalse (5),
        compareTrue (6),
        referral (10), and
        saslBindInProgress (14).
</PRE>
<P>The <EM>success</EM>, <EM>compareTrue</EM>, and <EM>compareFalse</EM> result codes indicate successful completion (and, hence, are referred to as &quot;successful&quot; result codes).</P>
<P>The <EM>referral</EM> and <EM>saslBindInProgress</EM> result codes indicate the client needs to take additional action to complete the operation.</P>
<H2><A NAME="Result Codes">H.2. Result Codes</A></H2>
<P>Existing LDAP result codes are described as follows:</P>
<H2><A NAME="success (0)">H.3. success (0)</A></H2>
<P>Indicates the successful completion of an operation.</P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>this code is not used with the Compare operation.  See <A HREF="#compareFalse (5)">compareFalse (5)</A> and <A HREF="#compareTrue (6)">compareTrue (6)</A>.
<HR WIDTH="80%" ALIGN="Left"></P>
<H2><A NAME="operationsError (1)">H.4. operationsError (1)</A></H2>
<P>Indicates that the operation is not properly sequenced with relation to other operations (of same or different type).</P>
<P>For example, this code is returned if the client attempts to StartTLS (<A HREF="https://www.rfc-editor.org/rfc/rfc4511.txt">RFC4511</A> Section 4.14) while there are other uncompleted operations or if a TLS layer was already installed.</P>
<H2><A NAME="protocolError (2)">H.5. protocolError (2)</A></H2>
<P>Indicates the server received data that is not well-formed.</P>
<P>For Bind operation only, this code is also used to indicate that the server does not support the requested protocol version.</P>
<P>For Extended operations only, this code is also used to indicate that the server does not support (by design or configuration) the Extended operation associated with the <EM>requestName</EM>.</P>
<P>For request operations specifying multiple controls, this may be used to indicate that the server cannot ignore the order of the controls as specified, or that the combination of the specified controls is invalid or unspecified.</P>
<H2><A NAME="timeLimitExceeded (3)">H.6. timeLimitExceeded (3)</A></H2>
<P>Indicates that the time limit specified by the client was exceeded before the operation could be completed.</P>
<H2><A NAME="sizeLimitExceeded (4)">H.7. sizeLimitExceeded (4)</A></H2>
<P>Indicates that the size limit specified by the client was exceeded before the operation could be completed.</P>
<H2><A NAME="compareFalse (5)">H.8. compareFalse (5)</A></H2>
<P>Indicates that the Compare operation has successfully completed and the assertion has evaluated to FALSE or Undefined.</P>
<H2><A NAME="compareTrue (6)">H.9. compareTrue (6)</A></H2>
<P>Indicates that the Compare operation has successfully completed and the assertion has evaluated to TRUE.</P>
<H2><A NAME="authMethodNotSupported (7)">H.10. authMethodNotSupported (7)</A></H2>
<P>Indicates that the authentication method or mechanism is not supported.</P>
<H2><A NAME="strongerAuthRequired (8)">H.11. strongerAuthRequired (8)</A></H2>
<P>Indicates the server requires strong(er) authentication in order to complete the operation.</P>
<P>When used with the Notice of Disconnection operation, this code indicates that the server has detected that an established security association between the client and server has unexpectedly failed or been compromised.</P>
<H2><A NAME="referral (10)">H.12. referral (10)</A></H2>
<P>Indicates that a referral needs to be chased to complete the operation (see <A HREF="https://www.rfc-editor.org/rfc/rfc4511.txt">RFC4511</A> Section 4.1.10).</P>
<H2><A NAME="adminLimitExceeded (11)">H.13. adminLimitExceeded (11)</A></H2>
<P>Indicates that an administrative limit has been exceeded.</P>
<H2><A NAME="unavailableCriticalExtension (12)">H.14. unavailableCriticalExtension (12)</A></H2>
<P>Indicates a critical control is unrecognized (see <A HREF="https://www.rfc-editor.org/rfc/rfc4511.txt">RFC4511</A> Section 4.1.11).</P>
<H2><A NAME="confidentialityRequired (13)">H.15. confidentialityRequired (13)</A></H2>
<P>Indicates that data confidentiality protections are required.</P>
<H2><A NAME="saslBindInProgress (14)">H.16. saslBindInProgress (14)</A></H2>
<P>Indicates the server requires the client to send a new bind request, with the same SASL mechanism, to continue the authentication process (see <A HREF="https://www.rfc-editor.org/rfc/rfc4511.txt">RFC4511</A> Section 4.2).</P>
<H2><A NAME="noSuchAttribute (16)">H.17. noSuchAttribute (16)</A></H2>
<P>Indicates that the named entry does not contain the specified attribute or attribute value.</P>
<H2><A NAME="undefinedAttributeType (17)">H.18. undefinedAttributeType (17)</A></H2>
<P>Indicates that a request field contains an unrecognized attribute description.</P>
<H2><A NAME="inappropriateMatching (18)">H.19. inappropriateMatching (18)</A></H2>
<P>Indicates that an attempt was made (e.g., in an assertion) to use a matching rule not defined for the attribute type concerned.</P>
<H2><A NAME="constraintViolation (19)">H.20. constraintViolation (19)</A></H2>
<P>Indicates that the client supplied an attribute value that does not conform to the constraints placed upon it by the data model.</P>
<P>For example, this code is returned when multiple values are supplied to an attribute that has a SINGLE-VALUE constraint.</P>
<H2><A NAME="attributeOrValueExists (20)">H.21. attributeOrValueExists (20)</A></H2>
<P>Indicates that the client supplied an attribute or value to be added to an entry, but the attribute or value already exists.</P>
<H2><A NAME="invalidAttributeSyntax (21)">H.22. invalidAttributeSyntax (21)</A></H2>
<P>Indicates that a purported attribute value does not conform to the syntax of the attribute.</P>
<H2><A NAME="noSuchObject (32)">H.23. noSuchObject (32)</A></H2>
<P>Indicates that the object does not exist in the DIT.</P>
<H2><A NAME="aliasProblem (33)">H.24. aliasProblem (33)</A></H2>
<P>Indicates that an alias problem has occurred.  For example, the code may used to indicate an alias has been dereferenced that names no object.</P>
<H2><A NAME="invalidDNSyntax (34)">H.25. invalidDNSyntax (34)</A></H2>
<P>Indicates that an LDAPDN or RelativeLDAPDN field (e.g., search base, target entry, ModifyDN newrdn, etc.) of a request does not conform to the required syntax or contains attribute values that do not conform to the syntax of the attribute's type.</P>
<H2><A NAME="aliasDereferencingProblem (36)">H.26. aliasDereferencingProblem (36)</A></H2>
<P>Indicates that a problem occurred while dereferencing an alias.  Typically, an alias was encountered in a situation where it was not allowed or where access was denied.</P>
<H2><A NAME="inappropriateAuthentication (48)">H.27. inappropriateAuthentication (48)</A></H2>
<P>Indicates the server requires the client that had attempted to bind anonymously or without supplying credentials to provide some form of credentials.</P>
<H2><A NAME="invalidCredentials (49)">H.28. invalidCredentials (49)</A></H2>
<P>Indicates that the provided credentials (e.g., the user's name and password) are invalid.</P>
<H2><A NAME="insufficientAccessRights (50)">H.29. insufficientAccessRights (50)</A></H2>
<P>Indicates that the client does not have sufficient access rights to perform the operation.</P>
<H2><A NAME="busy (51)">H.30. busy (51)</A></H2>
<P>Indicates that the server is too busy to service the operation.</P>
<H2><A NAME="unavailable (52)">H.31. unavailable (52)</A></H2>
<P>Indicates that the server is shutting down or a subsystem necessary to complete the operation is offline.</P>
<H2><A NAME="unwillingToPerform (53)">H.32. unwillingToPerform (53)</A></H2>
<P>Indicates that the server is unwilling to perform the operation.</P>
<H2><A NAME="loopDetect (54)">H.33. loopDetect (54)</A></H2>
<P>Indicates that the server has detected an internal loop (e.g., while dereferencing aliases or chaining an operation).</P>
<H2><A NAME="namingViolation (64)">H.34. namingViolation (64)</A></H2>
<P>Indicates that the entry's name violates naming restrictions.</P>
<H2><A NAME="objectClassViolation (65)">H.35. objectClassViolation (65)</A></H2>
<P>Indicates that the entry violates object class restrictions.</P>
<H2><A NAME="notAllowedOnNonLeaf (66)">H.36. notAllowedOnNonLeaf (66)</A></H2>
<P>Indicates that the operation is inappropriately acting upon a non-leaf entry.</P>
<H2><A NAME="notAllowedOnRDN (67)">H.37. notAllowedOnRDN (67)</A></H2>
<P>Indicates that the operation is inappropriately attempting to remove a value that forms the entry's relative distinguished name.</P>
<H2><A NAME="entryAlreadyExists (68)">H.38. entryAlreadyExists (68)</A></H2>
<P>Indicates that the request cannot be fulfilled (added, moved, or renamed) as the target entry already exists.</P>
<H2><A NAME="objectClassModsProhibited (69)">H.39. objectClassModsProhibited (69)</A></H2>
<P>Indicates that an attempt to modify the object class(es) of an entry's 'objectClass' attribute is prohibited.</P>
<P>For example, this code is returned when a client attempts to modify the structural object class of an entry.</P>
<H2><A NAME="affectsMultipleDSAs (71)">H.40. affectsMultipleDSAs (71)</A></H2>
<P>Indicates that the operation cannot be performed as it would affect multiple servers (DSAs).</P>
<H2><A NAME="other (80)">H.41. other (80)</A></H2>
<P>Indicates the server has encountered an internal error.</P>
<P></P>
<HR>
<H1><A NAME="Glossary">I. Glossary</A></H1>
<H2><A NAME="Terms">I.1. Terms</A></H2>
<TABLE CLASS="plain">
<TR CLASS="heading">
<TD>
<STRONG>Term</STRONG>
</TD>
<TD>
<STRONG>Definition</STRONG>
</TD>
</TR>
<TR>
<TD>
3DES
</TD>
<TD>
Triple DES
</TD>
</TR>
<TR>
<TD>
ABNF
</TD>
<TD>
Augmented Backus-Naur Form
</TD>
</TR>
<TR>
<TD>
ACDF
</TD>
<TD>
Access Control Decision Function
</TD>
</TR>
<TR>
<TD>
ACE
</TD>
<TD>
ASCII Compatible Encoding
</TD>
</TR>
<TR>
<TD>
ASCII
</TD>
<TD>
American Standard Code for Information Interchange
</TD>
</TR>
<TR>
<TD>
ACID
</TD>
<TD>
Atomicity, Consistency, Isolation, and Durability
</TD>
</TR>
<TR>
<TD>
ACI
</TD>
<TD>
Access Control Information
</TD>
</TR>
<TR>
<TD>
ACL
</TD>
<TD>
Access Control List
</TD>
</TR>
<TR>
<TD>
AES
</TD>
<TD>
Advance Encryption Standard
</TD>
</TR>
<TR>
<TD>
ABI
</TD>
<TD>
Application Binary Interface
</TD>
</TR>
<TR>
<TD>
API
</TD>
<TD>
Application Program Interface
</TD>
</TR>
<TR>
<TD>
ASN.1
</TD>
<TD>
Abstract Syntax Notation - One
</TD>
</TR>
<TR>
<TD>
AVA
</TD>
<TD>
Attribute Value Assertion
</TD>
</TR>
<TR>
<TD>
AuthcDN
</TD>
<TD>
Authentication DN
</TD>
</TR>
<TR>
<TD>
AuthcId
</TD>
<TD>
Authentication Identity
</TD>
</TR>
<TR>
<TD>
AuthzDN
</TD>
<TD>
Authorization DN
</TD>
</TR>
<TR>
<TD>
AuthzId
</TD>
<TD>
Authorization Identity
</TD>
</TR>
<TR>
<TD>
BCP
</TD>
<TD>
Best Current Practice
</TD>
</TR>
<TR>
<TD>
BER
</TD>
<TD>
Basic Encoding Rules
</TD>
</TR>
<TR>
<TD>
BNF
</TD>
<TD>
Backus-Naur Form
</TD>
</TR>
<TR>
<TD>
C
</TD>
<TD>
The C Programming Language
</TD>
</TR>
<TR>
<TD>
CA
</TD>
<TD>
Certificate Authority
</TD>
</TR>
<TR>
<TD>
CER
</TD>
<TD>
Canonical Encoding Rules
</TD>
</TR>
<TR>
<TD>
CLDAP
</TD>
<TD>
Connection-less LDAP
</TD>
</TR>
<TR>
<TD>
CN
</TD>
<TD>
Common Name
</TD>
</TR>
<TR>
<TD>
CRAM-MD5
</TD>
<TD>
SASL MD5 Challenge/Response Authentication Mechanism
</TD>
</TR>
<TR>
<TD>
CRL
</TD>
<TD>
Certificate Revocation List
</TD>
</TR>
<TR>
<TD>
DAP
</TD>
<TD>
Directory Access Protocol
</TD>
</TR>
<TR>
<TD>
DC
</TD>
<TD>
Domain Component
</TD>
</TR>
<TR>
<TD>
DER
</TD>
<TD>
Distinguished Encoding Rules
</TD>
</TR>
<TR>
<TD>
DES
</TD>
<TD>
Data Encryption Standard
</TD>
</TR>
<TR>
<TD>
DIB
</TD>
<TD>
Directory Information Base
</TD>
</TR>
<TR>
<TD>
DIGEST-MD5
</TD>
<TD>
SASL Digest MD5 Authentication Mechanism
</TD>
</TR>
<TR>
<TD>
DISP
</TD>
<TD>
Directory Information Shadowing Protocol
</TD>
</TR>
<TR>
<TD>
DIT
</TD>
<TD>
Directory Information Tree
</TD>
</TR>
<TR>
<TD>
DNS
</TD>
<TD>
Domain Name System
</TD>
</TR>
<TR>
<TD>
DN
</TD>
<TD>
Distinguished Name
</TD>
</TR>
<TR>
<TD>
DOP
</TD>
<TD>
Directory Operational Binding Management Protocol
</TD>
</TR>
<TR>
<TD>
DSAIT
</TD>
<TD>
DSA Information Tree
</TD>
</TR>
<TR>
<TD>
DSA
</TD>
<TD>
Directory System Agent
</TD>
</TR>
<TR>
<TD>
DSE
</TD>
<TD>
DSA-specific Entry
</TD>
</TR>
<TR>
<TD>
DSP
</TD>
<TD>
Directory System Protocol
</TD>
</TR>
<TR>
<TD>
DS
</TD>
<TD>
Draft Standard
</TD>
</TR>
<TR>
<TD>
DUA
</TD>
<TD>
Directory User Agent
</TD>
</TR>
<TR>
<TD>
EXTERNAL
</TD>
<TD>
SASL External Authentication Mechanism
</TD>
</TR>
<TR>
<TD>
FAQ
</TD>
<TD>
Frequently Asked Questions
</TD>
</TR>
<TR>
<TD>
FTP
</TD>
<TD>
File Transfer Protocol
</TD>
</TR>
<TR>
<TD>
FYI
</TD>
<TD>
For Your Information
</TD>
</TR>
<TR>
<TD>
GSER
</TD>
<TD>
Generic String Encoding Rules
</TD>
</TR>
<TR>
<TD>
GSS-API
</TD>
<TD>
Generic Security Service Application Program Interface
</TD>
</TR>
<TR>
<TD>
GSSAPI
</TD>
<TD>
SASL Kerberos V GSS-API Authentication Mechanism
</TD>
</TR>
<TR>
<TD>
I-D
</TD>
<TD>
Internet-Draft
</TD>
</TR>
<TR>
<TD>
IA5
</TD>
<TD>
International Alphabet 5
</TD>
</TR>
<TR>
<TD>
IDNA
</TD>
<TD>
Internationalized Domain Names in Applications
</TD>
</TR>
<TR>
<TD>
IDN
</TD>
<TD>
Internationalized Domain Name
</TD>
</TR>
<TR>
<TD>
ID
</TD>
<TD>
Identifier
</TD>
</TR>
<TR>
<TD>
IDL
</TD>
<TD>
Index Data Lookups
</TD>
</TR>
<TR>
<TD>
IP
</TD>
<TD>
Internet Protocol
</TD>
</TR>
<TR>
<TD>
IPC
</TD>
<TD>
Inter-process communication
</TD>
</TR>
<TR>
<TD>
IPsec
</TD>
<TD>
Internet Protocol Security
</TD>
</TR>
<TR>
<TD>
IPv4
</TD>
<TD>
Internet Protocol, version 4
</TD>
</TR>
<TR>
<TD>
IPv6
</TD>
<TD>
Internet Protocol, version 6
</TD>
</TR>
<TR>
<TD>
ITS
</TD>
<TD>
Issue Tracking System
</TD>
</TR>
<TR>
<TD>
JPEG
</TD>
<TD>
Joint Photographic Experts Group
</TD>
</TR>
<TR>
<TD>
Kerberos
</TD>
<TD>
Kerberos Authentication Service
</TD>
</TR>
<TR>
<TD>
LBER
</TD>
<TD>
Lightweight BER
</TD>
</TR>
<TR>
<TD>
LDAP
</TD>
<TD>
Lightweight Directory Access Protocol
</TD>
</TR>
<TR>
<TD>
LDAP Sync
</TD>
<TD>
LDAP Content Synchronization
</TD>
</TR>
<TR>
<TD>
LDAPv3
</TD>
<TD>
LDAP, version 3
</TD>
</TR>
<TR>
<TD>
LDIF
</TD>
<TD>
LDAP Data Interchange Format
</TD>
</TR>
<TR>
<TD>
LMDB
</TD>
<TD>
Lightning Memory-Mapped Database
</TD>
</TR>
<TR>
<TD>
MD5
</TD>
<TD>
Message Digest 5
</TD>
</TR>
<TR>
<TD>
MDB
</TD>
<TD>
Memory-Mapped Database (Backend)
</TD>
</TR>
<TR>
<TD>
MIB
</TD>
<TD>
Management Information Base
</TD>
</TR>
<TR>
<TD>
MODDN
</TD>
<TD>
Modify DN
</TD>
</TR>
<TR>
<TD>
MODRDN
</TD>
<TD>
Modify RDN
</TD>
</TR>
<TR>
<TD>
NSSR
</TD>
<TD>
Non-specific Subordinate Reference
</TD>
</TR>
<TR>
<TD>
OID
</TD>
<TD>
Object Identifier
</TD>
</TR>
<TR>
<TD>
OSI
</TD>
<TD>
Open Systems Interconnect
</TD>
</TR>
<TR>
<TD>
OTP
</TD>
<TD>
One Time Password
</TD>
</TR>
<TR>
<TD>
PDU
</TD>
<TD>
Protocol Data Unit
</TD>
</TR>
<TR>
<TD>
PEM
</TD>
<TD>
Privacy Enhanced eMail
</TD>
</TR>
<TR>
<TD>
PEN
</TD>
<TD>
Private Enterprise Number
</TD>
</TR>
<TR>
<TD>
PKCS
</TD>
<TD>
Public Key Cryptosystem
</TD>
</TR>
<TR>
<TD>
PKI
</TD>
<TD>
Public Key Infrastructure
</TD>
</TR>
<TR>
<TD>
PKIX
</TD>
<TD>
Public Key Infrastructure (X.509)
</TD>
</TR>
<TR>
<TD>
PLAIN
</TD>
<TD>
SASL Plaintext Password Authentication Mechanism
</TD>
</TR>
<TR>
<TD>
POSIX
</TD>
<TD>
Portable Operating System Interface
</TD>
</TR>
<TR>
<TD>
PS
</TD>
<TD>
Proposed Standard
</TD>
</TR>
<TR>
<TD>
RDN
</TD>
<TD>
Relative Distinguished Name
</TD>
</TR>
<TR>
<TD>
RFC
</TD>
<TD>
Request for Comments
</TD>
</TR>
<TR>
<TD>
RPC
</TD>
<TD>
Remote Procedure Call
</TD>
</TR>
<TR>
<TD>
RXER
</TD>
<TD>
Robust XML Encoding Rules
</TD>
</TR>
<TR>
<TD>
SASL
</TD>
<TD>
Simple Authentication and Security Layer
</TD>
</TR>
<TR>
<TD>
SDF
</TD>
<TD>
Simple Document Format
</TD>
</TR>
<TR>
<TD>
SDSE
</TD>
<TD>
Shadowed DSE
</TD>
</TR>
<TR>
<TD>
SHA1
</TD>
<TD>
Secure Hash Algorithm 1
</TD>
</TR>
<TR>
<TD>
SLAPD
</TD>
<TD>
Standalone LDAP Daemon
</TD>
</TR>
<TR>
<TD>
SLURPD
</TD>
<TD>
Standalone LDAP Update Replication Daemon
</TD>
</TR>
<TR>
<TD>
SMTP
</TD>
<TD>
Simple Mail Transfer Protocol
</TD>
</TR>
<TR>
<TD>
SNMP
</TD>
<TD>
Simple Network Management Protocol
</TD>
</TR>
<TR>
<TD>
SQL
</TD>
<TD>
Structured Query Language
</TD>
</TR>
<TR>
<TD>
SRP
</TD>
<TD>
Secure Remote Password
</TD>
</TR>
<TR>
<TD>
SSF
</TD>
<TD>
Security Strength Factor
</TD>
</TR>
<TR>
<TD>
SSL
</TD>
<TD>
Secure Socket Layer
</TD>
</TR>
<TR>
<TD>
STD
</TD>
<TD>
Internet Standard
</TD>
</TR>
<TR>
<TD>
TCP
</TD>
<TD>
Transmission Control Protocol
</TD>
</TR>
<TR>
<TD>
TLS
</TD>
<TD>
Transport Layer Security
</TD>
</TR>
<TR>
<TD>
UCS
</TD>
<TD>
Universal Multiple-Octet Coded Character Set
</TD>
</TR>
<TR>
<TD>
UDP
</TD>
<TD>
User Datagram Protocol
</TD>
</TR>
<TR>
<TD>
UID
</TD>
<TD>
User Identifier
</TD>
</TR>
<TR>
<TD>
Unicode
</TD>
<TD>
The Unicode Standard
</TD>
</TR>
<TR>
<TD>
UNIX
</TD>
<TD>
Unix
</TD>
</TR>
<TR>
<TD>
URI
</TD>
<TD>
Uniform Resource Identifier
</TD>
</TR>
<TR>
<TD>
URL
</TD>
<TD>
Uniform Resource Locator
</TD>
</TR>
<TR>
<TD>
URN
</TD>
<TD>
Uniform Resource Name
</TD>
</TR>
<TR>
<TD>
UTF-8
</TD>
<TD>
8-bit UCS/Unicode Transformation Format
</TD>
</TR>
<TR>
<TD>
UTR
</TD>
<TD>
Unicode Technical Report
</TD>
</TR>
<TR>
<TD>
UUID
</TD>
<TD>
Universally Unique Identifier
</TD>
</TR>
<TR>
<TD>
WWW
</TD>
<TD>
World Wide Web
</TD>
</TR>
<TR>
<TD>
X.500
</TD>
<TD>
X.500 Directory Services
</TD>
</TR>
<TR>
<TD>
X.509
</TD>
<TD>
X.509 Public Key and Attribute Certificate Frameworks
</TD>
</TR>
<TR>
<TD>
XED
</TD>
<TD>
XML Enabled Directory
</TD>
</TR>
<TR>
<TD>
XER
</TD>
<TD>
XML Encoding Rules
</TD>
</TR>
<TR>
<TD>
XML
</TD>
<TD>
Extensible Markup Language
</TD>
</TR>
<TR>
<TD>
syncrepl
</TD>
<TD>
LDAP Sync-based Replication
</TD>
</TR>
<TR>
<TD>
lloadd
</TD>
<TD>
LDAP Load Balancer
</TD>
</TR>
</TABLE>

<H2><A NAME="Related Organizations">I.2. Related Organizations</A></H2>
<TABLE CLASS="plain">
<TR CLASS="heading">
<TD>
<STRONG>Name</STRONG>
</TD>
<TD>
<STRONG>Long</STRONG>
</TD>
<TD>
<STRONG>Jump</STRONG>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.ansi.org/">ANSI</A>
</TD>
<TD>
American National Standards Institute
</TD>
<TD>
<A HREF="https://www.ansi.org/">https://www.ansi.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.bsigroup.com/en-GB/">BSI</A>
</TD>
<TD>
British Standards Institute
</TD>
<TD>
<A HREF="https://www.bsigroup.com/en-GB/">https://www.bsigroup.com/en-GB/</A>
</TD>
</TR>
<TR>
<TD>
<ORG>COSINE</ORG>
</TD>
<TD>
Co-operation and Open Systems Interconnection in Europe
</TD>
<TD>
<JUMP>&nbsp;</JUMP>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.cpan.org/">CPAN</A>
</TD>
<TD>
Comprehensive Perl Archive Network
</TD>
<TD>
<A HREF="https://www.cpan.org/">https://www.cpan.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.cyrusimap.org/">Cyrus</A>
</TD>
<TD>
Project Cyrus
</TD>
<TD>
<A HREF="https://www.cyrusimap.org/">https://www.cyrusimap.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.fsf.org/">FSF</A>
</TD>
<TD>
Free Software Foundation
</TD>
<TD>
<A HREF="https://www.fsf.org/">https://www.fsf.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.gnu.org/">GNU</A>
</TD>
<TD>
GNU Not Unix Project
</TD>
<TD>
<A HREF="https://www.gnu.org/">https://www.gnu.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.iab.org/">IAB</A>
</TD>
<TD>
Internet Architecture Board
</TD>
<TD>
<A HREF="https://www.iab.org/">https://www.iab.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.iana.org/">IANA</A>
</TD>
<TD>
Internet Assigned Numbers Authority
</TD>
<TD>
<A HREF="https://www.iana.org/">https://www.iana.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.ieee.org">IEEE</A>
</TD>
<TD>
Institute of Electrical and Electronics Engineers
</TD>
<TD>
<A HREF="https://www.ieee.org">https://www.ieee.org</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.ietf.org/about/groups/iesg/">IESG</A>
</TD>
<TD>
Internet Engineering Steering Group
</TD>
<TD>
<A HREF="https://www.ietf.org/about/groups/iesg/">https://www.ietf.org/about/groups/iesg/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.ietf.org/">IETF</A>
</TD>
<TD>
Internet Engineering Task Force
</TD>
<TD>
<A HREF="https://www.ietf.org/">https://www.ietf.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://irtf.org/">IRTF</A>
</TD>
<TD>
Internet Research Task Force
</TD>
<TD>
<A HREF="https://irtf.org/">https://irtf.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.iso.org/">ISO</A>
</TD>
<TD>
International Standards Organisation
</TD>
<TD>
<A HREF="https://www.iso.org/">https://www.iso.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.internetsociety.org/">ISOC</A>
</TD>
<TD>
Internet Society
</TD>
<TD>
<A HREF="https://www.internetsociety.org/">https://www.internetsociety.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.itu.int/">ITU</A>
</TD>
<TD>
International Telecommunication Union
</TD>
<TD>
<A HREF="https://www.itu.int/">https://www.itu.int/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.openldap.org/foundation/">OLF</A>
</TD>
<TD>
OpenLDAP Foundation
</TD>
<TD>
<A HREF="https://www.openldap.org/foundation/">https://www.openldap.org/foundation/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.openldap.org/project/">OLP</A>
</TD>
<TD>
OpenLDAP Project
</TD>
<TD>
<A HREF="https://www.openldap.org/project/">https://www.openldap.org/project/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.openssl.org/">OpenSSL</A>
</TD>
<TD>
OpenSSL Project
</TD>
<TD>
<A HREF="https://www.openssl.org/">https://www.openssl.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/">RFC Editor</A>
</TD>
<TD>
RFC Editor
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/">https://www.rfc-editor.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.oracle.com/">Oracle</A>
</TD>
<TD>
Oracle Corporation
</TD>
<TD>
<A HREF="https://www.oracle.com/">https://www.oracle.com/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.umich.edu/">UM</A>
</TD>
<TD>
University of Michigan
</TD>
<TD>
<A HREF="https://www.umich.edu/">https://www.umich.edu/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://web.archive.org/web/20160302011357/http://www.umich.edu/~dirsvcs/ldap/ldap.html">UMLDAP</A>
</TD>
<TD>
University of Michigan LDAP Team
</TD>
<TD>
<A HREF="https://web.archive.org/web/20160302011357/http://www.umich.edu/~dirsvcs/ldap/ldap.html">https://web.archive.org/web/20160302011357/http://www.umich.edu/~dirsvcs/ldap/ldap.html</A>
</TD>
</TR>
</TABLE>

<H2><A NAME="Related Products">I.3. Related Products</A></H2>
<TABLE CLASS="plain">
<TR CLASS="heading">
<TD>
<STRONG>Name</STRONG>
</TD>
<TD>
<STRONG>Jump</STRONG>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://metacpan.org/release/sdf">SDF</A>
</TD>
<TD>
<A HREF="https://metacpan.org/release/sdf">https://metacpan.org/release/sdf</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.cyrusimap.org/">Cyrus</A>
</TD>
<TD>
<A HREF="https://www.cyrusimap.org/">https://www.cyrusimap.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.cyrusimap.org/sasl/">Cyrus SASL</A>
</TD>
<TD>
<A HREF="https://www.cyrusimap.org/sasl/">https://www.cyrusimap.org/sasl/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://git-scm.com/">Git</A>
</TD>
<TD>
<A HREF="https://git-scm.com/">https://git-scm.com/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.gnu.org/software/">GNU</A>
</TD>
<TD>
<A HREF="https://www.gnu.org/software/">https://www.gnu.org/software/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://gnutls.org/">GnuTLS</A>
</TD>
<TD>
<A HREF="https://gnutls.org/">https://gnutls.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://github.com/heimdal/">Heimdal</A>
</TD>
<TD>
<A HREF="https://github.com/heimdal/">https://github.com/heimdal/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.openldap.org/jldap/">JLDAP</A>
</TD>
<TD>
<A HREF="https://www.openldap.org/jldap/">https://www.openldap.org/jldap/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://libevent.org/">libevent</A>
</TD>
<TD>
<A HREF="https://libevent.org/">https://libevent.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://web.mit.edu/kerberos/">MIT Kerberos</A>
</TD>
<TD>
<A HREF="https://web.mit.edu/kerberos/">https://web.mit.edu/kerberos/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.openldap.org/">OpenLDAP</A>
</TD>
<TD>
<A HREF="https://www.openldap.org/">https://www.openldap.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.openldap.org/faq/">OpenLDAP FAQ</A>
</TD>
<TD>
<A HREF="https://www.openldap.org/faq/">https://www.openldap.org/faq/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://bugs.openldap.org/">OpenLDAP ITS</A>
</TD>
<TD>
<A HREF="https://bugs.openldap.org/">https://bugs.openldap.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.openldap.org/software/">OpenLDAP Software</A>
</TD>
<TD>
<A HREF="https://www.openldap.org/software/">https://www.openldap.org/software/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.openssl.org/">OpenSSL</A>
</TD>
<TD>
<A HREF="https://www.openssl.org/">https://www.openssl.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.perl.org/">Perl</A>
</TD>
<TD>
<A HREF="https://www.perl.org/">https://www.perl.org/</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://web.archive.org/web/20160302011357/http://www.umich.edu/~dirsvcs/ldap/ldap.html">UMLDAP</A>
</TD>
<TD>
<A HREF="https://web.archive.org/web/20160302011357/http://www.umich.edu/~dirsvcs/ldap/ldap.html">https://web.archive.org/web/20160302011357/http://www.umich.edu/~dirsvcs/ldap/ldap.html</A>
</TD>
</TR>
</TABLE>

<H2><A NAME="References">I.4. References</A></H2>
<TABLE CLASS="plain">
<TR CLASS="heading">
<TD>
<STRONG>Reference</STRONG>
</TD>
<TD>
<STRONG>Document</STRONG>
</TD>
<TD>
<STRONG>Status</STRONG>
</TD>
<TD>
<STRONG>Jump</STRONG>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://web.archive.org/web/20170809071245/http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/guide.pdf">UM-GUIDE</A>
</TD>
<TD>
The SLAPD and SLURPD Administrators Guide
</TD>
<TD>
O
</TD>
<TD>
<A HREF="https://web.archive.org/web/20170809071245/http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/guide.pdf">https://web.archive.org/web/20170809071245/http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/guide.pdf</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc2079.txt">RFC2079</A>
</TD>
<TD>
Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc2079.txt">https://www.rfc-editor.org/rfc/rfc2079.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc2296.txt">RFC2296</A>
</TD>
<TD>
Use of Language Codes in LDAP
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc2296.txt">https://www.rfc-editor.org/rfc/rfc2296.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc2307.txt">RFC2307</A>
</TD>
<TD>
An Approach for Using LDAP as a Network Information Service
</TD>
<TD>
X
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc2307.txt">https://www.rfc-editor.org/rfc/rfc2307.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc2589.txt">RFC2589</A>
</TD>
<TD>
Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc2589.txt">https://www.rfc-editor.org/rfc/rfc2589.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc2798.txt">RFC2798</A>
</TD>
<TD>
Definition of the inetOrgPerson LDAP Object Class
</TD>
<TD>
I
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc2798.txt">https://www.rfc-editor.org/rfc/rfc2798.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc2831.txt">RFC2831</A>
</TD>
<TD>
Using Digest Authentication as a SASL Mechanism
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc2831.txt">https://www.rfc-editor.org/rfc/rfc2831.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc2849.txt">RFC2849</A>
</TD>
<TD>
The LDAP Data Interchange Format
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc2849.txt">https://www.rfc-editor.org/rfc/rfc2849.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc3088.txt">RFC3088</A>
</TD>
<TD>
OpenLDAP Root Service
</TD>
<TD>
X
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc3088.txt">https://www.rfc-editor.org/rfc/rfc3088.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc3296.txt">RFC3296</A>
</TD>
<TD>
Named Subordinate References in LDAP
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc3296.txt">https://www.rfc-editor.org/rfc/rfc3296.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc3384.txt">RFC3384</A>
</TD>
<TD>
Lightweight Directory Access Protocol (version 3) Replication Requirements
</TD>
<TD>
I
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc3384.txt">https://www.rfc-editor.org/rfc/rfc3384.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc3494.txt">RFC3494</A>
</TD>
<TD>
Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status
</TD>
<TD>
I
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc3494.txt">https://www.rfc-editor.org/rfc/rfc3494.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4013.txt">RFC4013</A>
</TD>
<TD>
SASLprep: Stringprep Profile for User Names and Passwords
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4013.txt">https://www.rfc-editor.org/rfc/rfc4013.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4346.txt">RFC4346</A>
</TD>
<TD>
The Transport Layer Security (TLS) Protocol, Version 1.1
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4346.txt">https://www.rfc-editor.org/rfc/rfc4346.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4422.txt">RFC4422</A>
</TD>
<TD>
Simple Authentication and Security Layer (SASL)
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4422.txt">https://www.rfc-editor.org/rfc/rfc4422.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4510.txt">RFC4510</A>
</TD>
<TD>
Lightweight Directory Access Protocol (LDAP): Technical Specification Roadmap
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4510.txt">https://www.rfc-editor.org/rfc/rfc4510.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4511.txt">RFC4511</A>
</TD>
<TD>
Lightweight Directory Access Protocol (LDAP): The Protocol
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4511.txt">https://www.rfc-editor.org/rfc/rfc4511.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4512.txt">RFC4512</A>
</TD>
<TD>
Lightweight Directory Access Protocol (LDAP): Directory Information Models
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4512.txt">https://www.rfc-editor.org/rfc/rfc4512.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4513.txt">RFC4513</A>
</TD>
<TD>
Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4513.txt">https://www.rfc-editor.org/rfc/rfc4513.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4514.txt">RFC4514</A>
</TD>
<TD>
Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4514.txt">https://www.rfc-editor.org/rfc/rfc4514.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4515.txt">RFC4515</A>
</TD>
<TD>
Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4515.txt">https://www.rfc-editor.org/rfc/rfc4515.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4516.txt">RFC4516</A>
</TD>
<TD>
Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4516.txt">https://www.rfc-editor.org/rfc/rfc4516.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4517.txt">RFC4517</A>
</TD>
<TD>
Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4517.txt">https://www.rfc-editor.org/rfc/rfc4517.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4518.txt">RFC4518</A>
</TD>
<TD>
Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4518.txt">https://www.rfc-editor.org/rfc/rfc4518.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4519.txt">RFC4519</A>
</TD>
<TD>
Lightweight Directory Access Protocol (LDAP): Schema for User Applications
</TD>
<TD>
PS
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4519.txt">https://www.rfc-editor.org/rfc/rfc4519.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4520.txt">RFC4520</A>
</TD>
<TD>
IANA Considerations for LDAP
</TD>
<TD>
BCP
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4520.txt">https://www.rfc-editor.org/rfc/rfc4520.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4533.txt">RFC4533</A>
</TD>
<TD>
The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation
</TD>
<TD>
X
</TD>
<TD>
<A HREF="https://www.rfc-editor.org/rfc/rfc4533.txt">https://www.rfc-editor.org/rfc/rfc4533.txt</A>
</TD>
</TR>
<TR>
<TD>
<A HREF="https://tools.ietf.org/html/draft-chu-ldap-ldapi-00">Chu-LDAPI</A>
</TD>
<TD>
Using LDAP Over IPC Mechanisms
</TD>
<TD>
ID
</TD>
<TD>
<A HREF="https://tools.ietf.org/html/draft-chu-ldap-ldapi-00">https://tools.ietf.org/html/draft-chu-ldap-ldapi-00</A>
</TD>
</TR>
</TABLE>

<P></P>
<HR>
<H1><A NAME="Generic configure Instructions">J. Generic configure Instructions</A></H1>
<PRE>
Basic Installation
==================

   These are generic installation instructions.

   The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation.  It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions.  Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, a file
`config.cache' that saves the results of its tests to speed up
reconfiguring, and a file `config.log' containing compiler output
(useful mainly for debugging `configure').

   If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release.  If at some point `config.cache'
contains results you don't want to keep, you may remove or edit it.

   The file `configure.in' is used to create `configure' by a program
called `autoconf'.  You only need `configure.in' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.

The simplest way to compile this package is:

  1. `cd' to the directory containing the package's source code and type
     `./configure' to configure the package for your system.  If you're
     using `csh' on an old version of System V, you might need to type
     `sh ./configure' instead to prevent `csh' from trying to execute
     `configure' itself.

     Running `configure' takes awhile.  While running, it prints some
     messages telling which features it is checking for.

  2. Type `make' to compile the package.

  3. Optionally, type `make check' to run any self-tests that come with
     the package.

  4. Type `make install' to install the programs and any data files and
     documentation.

  5. You can remove the program binaries and object files from the
     source code directory by typing `make clean'.  To also remove the
     files that `configure' created (so you can compile the package for
     a different kind of computer), type `make distclean'.  There is
     also a `make maintainer-clean' target, but that is intended mainly
     for the package's developers.  If you use it, you may have to get
     all sorts of other programs in order to regenerate files that came
     with the distribution.

Compilers and Options
=====================

   Some systems require unusual options for compilation or linking that
the `configure' script does not know about.  You can give `configure'
initial values for variables by setting them in the environment.  Using
a Bourne-compatible shell, you can do that on the command line like
this:
     CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure

Or on systems that have the `env' program, you can do it like this:
     env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure

Compiling For Multiple Architectures
====================================

   You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory.  To do this, you must use a version of `make' that
supports the `VPATH' variable, such as GNU `make'.  `cd' to the
directory where you want the object files and executables to go and run
the `configure' script.  `configure' automatically checks for the
source code in the directory that `configure' is in and in `..'.

   If you have to use a `make' that does not supports the `VPATH'
variable, you have to compile the package for one architecture at a time
in the source code directory.  After you have installed the package for
one architecture, use `make distclean' before reconfiguring for another
architecture.

Installation Names
==================

   By default, `make install' will install the package's files in
`/usr/local/bin', `/usr/local/man', etc.  You can specify an
installation prefix other than `/usr/local' by giving `configure' the
option `--prefix=PATH'.

   You can specify separate installation prefixes for
architecture-specific files and architecture-independent files.  If you
give `configure' the option `--exec-prefix=PATH', the package will use
PATH as the prefix for installing programs and libraries.
Documentation and other data files will still use the regular prefix.

   In addition, if you use an unusual directory layout you can give
options like `--bindir=PATH' to specify different values for particular
kinds of files.  Run `configure --help' for a list of the directories
you can set and what kinds of files go in them.

   If the package supports it, you can cause programs to be installed
with an extra prefix or suffix on their names by giving `configure' the
option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.

Optional Features
=================

   Some packages pay attention to `--enable-FEATURE' options to
`configure', where FEATURE indicates an optional part of the package.
They may also pay attention to `--with-PACKAGE' options, where PACKAGE
is something like `gnu-as' or `x' (for the X Window System).  The
`README' should mention any `--enable-' and `--with-' options that the
package recognizes.

   For packages that use the X Window System, `configure' can usually
find the X include and library files automatically, but if it doesn't,
you can use the `configure' options `--x-includes=DIR' and
`--x-libraries=DIR' to specify their locations.

Specifying the System Type
==========================

   There may be some features `configure' can not figure out
automatically, but needs to determine by the type of host the package
will run on.  Usually `configure' can figure that out, but if it prints
a message saying it can not guess the host type, give it the
`--host=TYPE' option.  TYPE can either be a short name for the system
type, such as `sun4', or a canonical name with three fields:
     CPU-COMPANY-SYSTEM

See the file `config.sub' for the possible values of each field.  If
`config.sub' isn't included in this package, then this package doesn't
need to know the host type.

   If you are building compiler tools for cross-compiling, you can also
use the `--target=TYPE' option to select the type of system they will
produce code for and the `--build=TYPE' option to select the type of
system on which you are compiling the package.

Sharing Defaults
================

   If you want to set default values for `configure' scripts to share,
you can create a site shell script called `config.site' that gives
default values for variables like `CC', `cache_file', and `prefix'.
`configure' looks for `PREFIX/share/config.site' if it exists, then
`PREFIX/etc/config.site' if it exists.  Or, you can set the
`CONFIG_SITE' environment variable to the location of the site script.
A warning: not all `configure' scripts look for a site script.

Operation Controls
==================

   `configure' recognizes the following options to control how it
operates.

`--cache-file=FILE'
     Use and save the results of the tests in FILE instead of
     `./config.cache'.  Set FILE to `/dev/null' to disable caching, for
     debugging `configure'.

`--help'
     Print a summary of the options to `configure', and exit.

`--quiet'
`--silent'
`-q'
     Do not print messages saying which checks are being made.  To
     suppress all normal output, redirect it to `/dev/null' (any error
     messages will still be shown).

`--srcdir=DIR'
     Look for the package's source code in directory DIR.  Usually
     `configure' can determine that directory automatically.

`--version'
     Print the version of Autoconf used to generate the `configure'
     script, and exit.

`configure' also accepts some other, not widely useful, options.

</PRE>
<P></P>
<HR>
<H1><A NAME="OpenLDAP Software Copyright Notices">K. OpenLDAP Software Copyright Notices</A></H1>
<H2><A NAME="OpenLDAP Copyright Notice">K.1. OpenLDAP Copyright Notice</A></H2>
<P>Copyright 1998-2013 The OpenLDAP Foundation.<BR><EM>All rights reserved.</EM></P>
<P>Redistribution and use in source and binary forms, with or without modification, are permitted <EM>only as authorized</EM> by the <A HREF="#OpenLDAP Public License">OpenLDAP Public License</A>.</P>
<P>A copy of this license is available in file <TT>LICENSE</TT> in the top-level directory of the distribution or, alternatively, at &lt;<A HREF="http://www.OpenLDAP.org/license.html">http://www.OpenLDAP.org/license.html</A>&gt;.</P>
<P>OpenLDAP is a registered trademark of the OpenLDAP Foundation.</P>
<P>Individual files and/or contributed packages may be copyright by other parties and their use subject to additional restrictions.</P>
<P>This work is derived from the University of Michigan LDAP v3.3 distribution.  Information concerning this software is available at &lt;<A HREF="http://www.umich.edu/~dirsvcs/ldap/ldap.html">http://www.umich.edu/~dirsvcs/ldap/ldap.html</A>&gt;.</P>
<P>This work also contains materials derived from public sources.</P>
<P>Additional information about OpenLDAP software can be obtained at &lt;<A HREF="http://www.OpenLDAP.org/">http://www.OpenLDAP.org/</A>&gt;.</P>
<H2><A NAME="Additional Copyright Notices">K.2. Additional Copyright Notices</A></H2>
<P>Portions Copyright 1998-2013 Kurt D. Zeilenga.<BR>Portions Copyright 1998-2006 Net Boolean Incorporated.<BR>Portions Copyright 2001-2006 IBM Corporation.<BR><EM>All rights reserved.</EM></P>
<P>Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the <A HREF="#OpenLDAP Public License">OpenLDAP Public License</A>.</P>
<P>Portions Copyright 1999-2008 Howard Y.H. Chu.<BR>Portions Copyright 1999-2008 Symas Corporation.<BR>Portions Copyright 1998-2003 Hallvard B. Furuseth.<BR>Portions Copyright 2007-2011 Gavin Henry.<BR>Portions Copyright 2007-2011 Suretec Systems Limited.<BR><EM>All rights reserved.</EM></P>
<P>Redistribution and use in source and binary forms, with or without modification, are permitted provided that this notice is preserved. The names of the copyright holders may not be used to endorse or promote products derived from this software without their specific prior written permission.  This software is provided ``as is'' without express or implied warranty.</P>
<H2><A NAME="University of Michigan Copyright Notice">K.3. University of Michigan Copyright Notice</A></H2>
<P>Portions Copyright 1992-1996 Regents of the University of Michigan.<BR><EM>All rights reserved.</EM></P>
<P>Redistribution and use in source and binary forms are permitted provided that this notice is preserved and that due credit is given to the University of Michigan at Ann Arbor. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. This software is provided ``as is'' without express or implied warranty.</P>
<P></P>
<HR>
<H1><A NAME="OpenLDAP Public License">L. OpenLDAP Public License</A></H1>
<PRE>
The OpenLDAP Public License
  Version 2.8, 17 August 2003

Redistribution and use of this software and associated documentation
(&quot;Software&quot;), with or without modification, are permitted provided
that the following conditions are met:

1. Redistributions in source form must retain copyright statements
   and notices,

2. Redistributions in binary form must reproduce applicable copyright
   statements and notices, this list of conditions, and the following
   disclaimer in the documentation and/or other materials provided
   with the distribution, and

3. Redistributions must contain a verbatim copy of this document.

The OpenLDAP Foundation may revise this license from time to time.
Each revision is distinguished by a version number.  You may use
this Software under terms of this license revision or under the
terms of any subsequent revision of the license.

THIS SOFTWARE IS PROVIDED BY THE OPENLDAP FOUNDATION AND ITS
CONTRIBUTORS ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT
SHALL THE OPENLDAP FOUNDATION, ITS CONTRIBUTORS, OR THE AUTHOR(S)
OR OWNER(S) OF THE SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

The names of the authors and copyright holders must not be used in
advertising or otherwise to promote the sale, use or other dealing
in this Software without specific, written prior permission.  Title
to copyright in this Software shall at all times remain with copyright
holders.

OpenLDAP is a registered trademark of the OpenLDAP Foundation.

Copyright 1999-2003 The OpenLDAP Foundation, Redwood City,
California, USA.  All Rights Reserved.  Permission to copy and
distribute verbatim copies of this document is granted.
</PRE>
</DIV>
<DIV CLASS="footer">
<HR>
<DIV CLASS="navigate">
<P ALIGN="Center"><A HREF="https://www.openldap.org/">Home</A> | <A HREF="../index.html">Catalog</A></P>
</DIV>
<P>
<FONT COLOR="#808080" FACE="Arial,Verdana,Helvetica" SIZE="1"><B>
________________<BR>
<SMALL>&copy; Copyright 2011-2021, <A HREF="https://www.OpenLDAP.org/foundation/">OpenLDAP Foundation</A>, <A HREF="mailto:info@OpenLDAP.org">info@OpenLDAP.org</A></SMALL></B></FONT>

</DIV>

</BODY>
</HTML>