نام (NAME)

slapd-config - موتور پیکربندی پویا بر پایه cn=config در slapd

خلاصه دستور (SYNOPSIS)

/etc/ldap/slapd.d

توضیحات (DESCRIPTION)

بخش slapd-config نحوه پیکربندی پویا و زمان اجرای سرور slapd را با استفاده از پایگاهداده داخلی cn=config تشریح میکند.

بک‌اند config تمام اطلاعات پیکربندی دیمن slapd(8) را مدیریت می‌کند. این اطلاعات پیکربندی همچنین توسط ابزارهای SLAPD شامل slapacl(8)، slapadd(8)، slapauth(8)، slapcat(8)، slapdn(8)، slapindex(8)، slapmodify(8) و slaptest(8) استفاده می‌شود.

بک‌اند config با فایل قدیمی‌تر slapd.conf(5) سازگار به عقب است، اما امکان تغییر پویای پیکربندی در زمان اجرا را فراهم می‌سازد. اگر slapd تنها با یک فایل slapd.conf اجرا شود، تغییرات پویا مجاز خواهند بود اما پس از راه‌اندازی مجدد سرور پابرجا نخواهند ماند. تغییرات پویا تنها زمانی ذخیره می‌شوند که slapd از درون یک پوشه پیکربندی slapd.d در حال اجرا باشد.

برخلاف سایر بک‌اندها، تنها یک نمونه از بک‌اند config می‌تواند وجود داشته باشد، و بیشتر ساختار آن از پیش تعریف شده است. ریشه این پایگاه‌داده به صورت ثابت روی cn=config تنظیم شده است و این مدخل ریشه شامل تنظیمات سراسری برای slapd است. چندین مدخل فرزند در زیر مدخل ریشه برای نگهداری تنظیمات مختلف دیگر استفاده می‌شوند:

cn=Module: ماژول‌های بارگذاری‌شده به‌صورت پویا
cn=Schema: تعاریف اسکِما
olcBackend=xxx: تنظیمات خاص بک‌اند
olcDatabase=xxx: تنظیمات خاص پایگاه‌داده

مدخل‌های cn=Module تنها در پیکربندی‌هایی ظاهر می‌شوند که slapd با پشتیبانی از ماژول‌های بارگذاری‌پذیر پویا کامپایل شده باشد. می‌تواند چندین مدخل وجود داشته باشد، یکی برای هر مسیر ماژول پیکربندی‌شده. درون هر مدخل مقادیری برای هر ماژول بارگذاری‌شده در یک مسیر مشخص ثبت می‌شود. این مدخل‌ها هیچ فرزندی ندارند.

مدخل cn=Schema شامل تمام عناصر اسکِمای کدگذاری‌شده ثابت در برنامه است. فرزندان این مدخل شامل تمام عناصر اسکِمای تعریف‌شده توسط کاربر هستند. در اسکِماهایی که از فایل‌های include بارگذاری شده‌اند، مدخل فرزند به نام فایل include که اسکِما از آن بارگذاری شده نام‌گذاری می‌شود. معمولاً اولین فرزند در این زیردرخت cn=core,cn=schema,cn=config خواهد بود.

مدخل‌های olcBackend برای ذخیره تنظیمات خاص یک نوع بک‌اند منفرد (و بنابراین سراسری برای تمام نمونه‌های پایگاه‌داده از آن نوع) هستند. در حال حاضر، تنها back-mdb گزینه‌هایی از این نوع را پیاده‌سازی می‌کند، بنابراین این تنظیم برای هیچ بک‌اند دیگری نیاز نیست.

مدخل‌های olcDatabase تنظیمات خاص یک نمونه پایگاه‌داده منفرد را ذخیره می‌کنند. این مدخل‌ها ممکن است مدخل‌های فرزند olcOverlay مربوط به هر اورلی پیکربندی‌شده روی پایگاه‌داده را داشته باشند. مدخل‌های olcDatabase و olcOverlay همچنین ممکن است مدخل‌های فرزند متفرقه دیگری برای سایر تنظیمات در صورت نیاز داشته باشند. دو مدخل پایگاه‌داده ویژه از پیش تعریف شده وجود دارد - یکی مدخلی برای خود پایگاه‌داده config است، و دیگری برای پایگاه‌داده "frontend" می‌باشد. تنظیمات پایگاه‌داده frontend توسط سایر پایگاه‌های داده به ارث برده می‌شوند، مگر اینکه به صراحت در یک پایگاه‌داده خاص بازنویسی (override) شوند.

گزینه‌های پیکربندی خاص موجود در بخش‌های گزینه‌های پیکربندی سراسری، گزینه‌های عمومی بک‌اند، و گزینه‌های عمومی پایگاه‌داده در ادامه مورد بحث قرار گرفته‌اند. گزینه‌ها با تعریف مشخصه‌های LDAP با مقادیر مشخص تنظیم می‌شوند. به‌طور کلی نام‌های مشخصه‌های LDAP همان کلیدواژه‌های متناظر در slapd.conf هستند که پیشوند "olc" به آن‌ها اضافه شده است.

تجزیه‌کننده (parser) بسیاری از این مشخصه‌ها مشابه موردی است که برای تجزیه کلیدواژه‌های slapd.conf استفاده می‌شود. به این ترتیب، کلیدواژه‌های slapd.conf که اجازه می‌دهند چندین مورد در یک خط جدا شده با فاصله مشخص شوند، امکان تعیین چندین مورد را در مقدار یک مشخصه نیز می‌دهند. با این حال، هنگام خواندن مشخصه از طریق LDAP، موارد به‌صورت مقادیر مشخصه جداگانه بازگردانده خواهند شد.

گزینه‌های خاص هر بک‌اند در صفحات راهنمای slapd-<backend>(5) مورد بحث قرار گرفته‌اند. برای جزئیات بیشتر در مورد پیکربندی slapd به "راهنمای مدیر OpenLDAP" مراجعه کنید.

گزینه‌های پیکربندی سراسری (GLOBAL CONFIGURATION OPTIONS)

گزینه‌های تشریح‌شده در این بخش برای کل سرور اعمال می‌شوند. آرگومان‌هایی که باید با متن واقعی جایگزین شوند داخل علامت‌های <> نشان داده شده‌اند.

این گزینه‌ها فقط می‌توانند در مدخل cn=config مشخص شوند. این مدخل باید کلاس شیء (objectClass) از نوع olcGlobal داشته باشد.

olcAllows: <features>

مجموعه‌ای از قابلیت‌ها را برای مجاز بودن مشخص می‌کند (پیش‌فرض هیچ‌کدام است). bind_v2 پذیرش درخواست‌های bind نسخه LDAPv2 را مجاز می‌کند. توجه داشته باشید که slapd(8) به‌طور واقعی LDAPv2 (استاندارد RFC 1777 که اکنون تاریخی RFC 3494 است) را پیاده‌سازی نمی‌کند. bind_anon_cred اتصال ناشناس را هنگامی که اعتبارنامه‌ها خالی نیستند (مثلاً هنگامی که DN خالی است) مجاز می‌سازد. bind_anon_dn اتصال غیراحرازشده (ناشناس) را هنگامی که DN خالی نیست مجاز می‌سازد. update_anon پردازش عملیات به‌روزرسانی غیراحرازشده (ناشناس) را مجاز می‌کند (مشروط به کنترل‌های دسترسی و سایر محدودیت‌های مدیریتی). proxy_authz_anon پردازش کنترل مجوز پروکسی غیراحرازشده (ناشناس) را مجاز می‌کند (مشروط به کنترل‌های دسترسی، اعطای مجوز و سایر محدودیت‌های مدیریتی).

olcArgsFile: <filename>

نام (مطلق) فایلی که خط فرمان سرور slapd (نام برنامه و گزینه‌ها) را در خود نگه می‌دارد.

olcAttributeOptions: <option-name>...

گزینه‌های مشخصه برچسب‌گذاری یا پیشوندهای برچسب/محدوده گزینه را تعریف می‌کند. گزینه‌ها نباید به `-' ختم شوند؛ پیشوندها باید به `-' ختم شوند. پیشوند `lang-' از پیش تعریف شده است. اگر از دستور olcAttributeOptions استفاده کنید، `lang-' دیگر تعریف نخواهد بود و اگر بخواهید تعریف شود باید آن را صریحاً مشخص کنید.

توصیف یک مشخصه با یک گزینه برچسب‌گذاری، یک زیرنوع از آن توصیف مشخصه بدون گزینه است. به جز این، گزینه‌های تعریف‌شده به این روش معنای خاص دیگری ندارند. پیشوندهای تعریف‌شده به این روش مانند گزینه‌های `lang-' عمل می‌کنند: آن‌ها یک پیشوند برای گزینه‌های برچسب‌گذاری که با آن پیشوند شروع می‌شوند تعریف می‌کنند. به این معنی که اگر پیشوند `x-foo-' را تعریف کنید، می‌توانید از گزینه `x-foo-bar' استفاده کنید. علاوه بر این، در یک جستجو یا مقایسه، یک پیشوند یا نام محدوده (با یک `-' پایانی) با تمام گزینه‌هایی که با آن نام شروع می‌شوند، و همچنین با گزینه بدون `-' پایانی مطابقت دارد. یعنی `x-foo-bar-' با `x-foo-bar' و `x-foo-bar-baz' تطابق پیدا می‌کند.

استاندارد RFC 4520 گزینه‌هایی را که با `x-' شروع می‌شوند برای آزمایش‌های خصوصی رزرو کرده است. سایر گزینه‌ها باید در IANA ثبت شوند، به بخش ۳.۵ از RFC 4520 مراجعه کنید. همچنین OpenLDAP گزینه `binary' را به‌طور داخلی در خود دارد، اما این یک گزینه انتقال است، نه گزینه برچسب‌گذاری.

olcAuthIDRewrite: <rewrite-rule>

توسط چارچوب احراز هویت برای تبدیل نام‌های کاربری ساده به یک DN در LDAP به منظور اهداف مجوزدهی استفاده می‌شود. هدف آن مشابه هدف olcAuthzRegexp (در زیر ببینید) است. مورد rewrite-rule مجموعه‌ای از قوانین مشابه موارد شرح‌داده‌شده در slapo-rwm(5) برای بازنویسی داده‌ها است (پس از حذف پیشوند rwm-). olcAuthIDRewrite و olcAuthzRegexp نباید با یکدیگر ترکیب شوند.

olcAuthzPolicy: <policy>

برای تعیین قوانینی که باید برای مجوز پروکسی (Proxy Authorization) استفاده شوند، به‌کار می‌رود. مجوز پروکسی به کلاینت اجازه می‌دهد تا با استفاده از اعتبارنامه یک کاربر با سرور احراز هویت کند، اما هویت متفاوتی را برای اهداف صدور مجوز و کنترل دسترسی تعیین کند. این اساساً به کاربر A اجازه می‌دهد تا به عنوان کاربر B، با استفاده از گذرواژه کاربر A وارد سیستم شود. فلگ none مجوز پروکسی را غیرفعال می‌کند. این تنظیم پیش‌فرض است. فلگ from از قوانین موجود در مشخصه authzFrom مربوط به DN مجوز استفاده خواهد کرد. فلگ to از قوانین موجود در مشخصه authzTo مربوط به DN احراز هویت استفاده خواهد کرد. فلگ any، یک نام مستعار برای مقدار منسوخ‌شده both، به هر یک از موارد فوق که ابتدا موفق شود اجازه می‌دهد (با توالی بررسی to سپس from). فلگ all نیازمند موفقیت هر دو مجوز است.

قوانین، سازوکارهایی برای مشخص کردن این هستند که کدام هویت‌ها مجاز به انجام مجوز پروکسی هستند. مشخصه authzFrom در یک مدخل مشخص می‌کند که چه کاربران دیگری مجاز به ورود پروکسی به این مدخل هستند. مشخصه authzTo در یک مدخل مشخص می‌کند که این کاربر می‌تواند به عنوان چه کاربران دیگری مجوز بگیرد. استفاده از قوانین authzTo در صورتی که کاربران مجاز به نوشتن مقادیر دلخواه روی این مشخصه باشند می‌تواند به راحتی مورد سوءاستفاده قرار گیرد. به‌طور کلی مشخصه authzTo باید با فهرست‌های کنترل دسترسی (ACL) محافظت شود به‌طوری که فقط کاربران ممتاز بتوانند آن را تغییر دهند. مقدار authzFrom و authzTo یک هویت یا مجموعه‌ای از هویت‌ها را توصیف می‌کند؛ این مقدار می‌تواند پنج شکل داشته باشد:

ldap:///<base>??[<scope>]?<filter>

dn[.<dnstyle>]:<pattern>

u[.<mech>[<realm>]]:<pattern>

group[/objectClass[/attributeType]]:<pattern>

<pattern>

<dnstyle>:={exact|onelevel|children|subtree|regex}

شکل اول یک URI معتبر LDAP است که در آن بخش‌های <host>:<port>، <attrs> و <extensions> باید غایب باشند، تا جستجو به‌صورت محلی بر روی authzFrom یا authzTo انجام شود.

شکل دوم یک DN است، با اصلاح‌کننده‌های اختیاری سبک شامل exact، onelevel، children و subtree برای تطابق دقیق، یک‌سطحی، فرزندان و زیردرخت، که باعث می‌شود <pattern> بر اساس قوانین عادی‌سازی DN نرمال شود، یا سبک ویژه regex که باعث می‌شود <pattern> به‌عنوان یک عبارت منظم (توسعه‌یافته) POSIX در نظر گرفته شود، همان‌طور که در regex(7) یا re_format(7) بحث شده است. الگوی * به معنای هر DN غیرناشناس است.

شکل سوم یک id مربوط به SASL است، با فیلدهای اختیاری <mech> و <realm> که امکان تعیین یک مکانیزم SASL و نهایتاً یک قلمرو (realm) SASL را برای مکانیزم‌هایی که از آن پشتیبانی می‌کنند فراهم می‌سازد. نیاز به امکان تعیین مکانیزم هنوز مورد بحث است و کاربران اکیداً از تکیه بر این امکان منع می‌شوند.

شکل چهارم مشخصه یک گروه است. این شکل شامل کلیدواژه group است که اختیاری با مشخص کردن objectClass و attributeType گروه همراه می‌شود. مقدار پیش‌فرض objectClass برابر با groupOfNames است. مقدار پیش‌فرض attributeType برابر با member است. گروه با DN معادل <pattern> با دامنه پایه (base scope) و فیلتر روی objectClass مشخص‌شده جستجو می‌شود. مقادیر attributeType حاصل برای DN اظهارشده جستجو می‌شوند.

شکل پنجم برای سازگاری با گذشته ارائه شده است. اگر هیچ نوع هویتی ارائه نشود، یعنی فقط <pattern> وجود داشته باشد، یک DN دقیق فرض می‌شود؛ در نتیجه، <pattern> تحت عادی‌سازی DN قرار می‌گیرد.

از آنجا که تفسیر authzFrom و authzTo می‌تواند بر امنیت تأثیر بگذارد، به کاربران اکیداً توصیه می‌شود که صریحاً نوع تعیین هویت مورد استفاده را مشخص کنند. زیرمجموعه‌ای از این قوانین می‌تواند به‌عنوان آرگومان سوم در دستور olcAuthzRegexp (در زیر ببینید) استفاده شود؛ به‌ویژه شکل‌های URI (به شرطی که دقیقاً به یک مدخل منجر شود) و dn.exact:<dn>.

olcAuthzRegexp: <match> <replace>: توسط چارچوب احراز هویت برای تبدیل نام‌های کاربری ساده، مانند نام‌های ارائه‌شده توسط زیرسیستم SASL، یا استخراج‌شده از گواهی‌ها در صورت SASL EXTERNAL مبتنی بر گواهی، یا ارائه‌شده در کنترل "مجوز پروکسی‌شده" RFC 4370، به یک DN در LDAP برای اهداف صدور مجوز استفاده می‌شود. توجه داشته باشید که DN حاصل برای معتبر شناخته شدن نیازی به ارجاع به یک مدخل موجود ندارد. هنگامی که یک درخواست مجوز از زیرسیستم SASL دریافت می‌شود، مقادیر USERNAME، REALM و MECHANISM مربوط به SASL در صورت موجود بودن اخذ شده و در یک نام به شکل زیر ترکیب می‌شوند:

UID=<username>[[,CN=<realm>],CN=<mechanism>],CN=auth

این نام سپس با عبارت منظم (توسعه‌یافته) POSIX در match مقایسه می‌شود و اگر تطابق موفقیت‌آمیز باشد، نام با رشته replace جایگزین می‌شود. اگر رشته‌های عام (wildcard) در عبارت منظم match وجود داشته باشند که در پرانتز قرار گرفته‌اند، مثلاً:

UID=([^,]*),CN=.*

آنگاه بخشی از نام که با علامت عام مطابقت دارد در متغیر نگه‌دارنده شماره‌دار $1 ذخیره می‌شود. اگر رشته‌های عام دیگری در پرانتز وجود داشته باشند، رشته‌های منطبق در $2، $3، تا $9 قرار می‌گیرند. سپس نگه‌دارنده‌ها می‌توانند در رشته replace استفاده شوند، مثلاً:

UID=$1,OU=Accounts,DC=example,DC=com

نام جایگزین‌شده می‌تواند یک DN باشد، یعنی رشته‌ای با پیشوند "dn:"، یا یک URI مربوط به LDAP. اگر دومی باشد، سرور از این URI برای جستجوی پایگاه(های) داده خود استفاده می‌کند و اگر جستجو دقیقاً یک مدخل را بازگرداند، نام با DN آن مدخل جایگزین می‌شود. URI مربوط به LDAP نباید هیچ مؤلفه hostport، attrs، یا extensions داشته باشد، اما فیلتر اجباری است، مثلاً:

ldap:///OU=Accounts,DC=example,DC=com??one?(UID=$1)

بخش پروتکل URI باید دقیقاً ldap باشد. توجه داشته باشید که این جستجو مشروط به کنترل‌های دسترسی است. به‌طور خاص، هویت احراز هویت باید دسترسی "auth" را در موضوع داشته باشد.

چندین مقدار olcAuthzRegexp می‌تواند برای الگوهای تطابق و جایگزینی متعدد مشخص شود. الگوهای تطابق به ترتیبی که در مشخصه ظاهر می‌شوند بررسی می‌شوند و در اولین تطابق موفق متوقف می‌شوند.

olcConcurrency: <integer>: سطح همروندی مورد نظر را مشخص می‌کند. به‌عنوان یک راهنمایی (hint) به سیستم نخ‌های زیرین ارائه می‌شود. پیش‌فرض این است که هیچ راهنمایی ارائه نشود. این تنظیم تنها در برخی پلتفرم‌ها که در آن‌ها تناظر یک‌به‌یک بین نخ‌های کاربر و نخ‌های هسته وجود ندارد معنادار است.
olcConnMaxPending: <integer>: حداکثر تعداد درخواست‌های معلق برای یک نشست ناشناس را مشخص می‌کند. اگر درخواست‌ها سریع‌تر از توانایی پردازش سرور ارسال شوند، تا این محدودیت در صف قرار می‌گیرند. اگر از حد مجاز فراتر رود، نشست بسته می‌شود. پیش‌فرض 100 است.
olcConnMaxPendingAuth: <integer>: حداکثر تعداد درخواست‌های معلق برای یک نشست احرازشده را مشخص می‌کند. پیش‌فرض 1000 است.
olcDisallows: <features>: مجموعه‌ای از قابلیت‌ها را برای غیرمجاز کردن مشخص می‌کند (پیش‌فرض هیچ‌کدام است). bind_anon پذیرش درخواست‌های اتصال ناشناس را غیرفعال می‌کند. توجه داشته باشید که این تنظیم مانع از دسترسی ناشناس به فهرست راهنما نمی‌شود (به "require authc" مراجعه کنید). bind_simple احراز هویت ساده (bind) را غیرفعال می‌کند. tls_2_anon اجبار نشست به وضعیت ناشناس در هنگام دریافت عملیات StartTLS را غیرفعال می‌کند (همچنین به tls_authc مراجعه کنید). tls_authc در صورت احراز هویت شدن، عملیات StartTLS را غیرمجاز می‌کند (همچنین به tls_2_anon مراجعه کنید). proxy_authz_non_critical پذیرش کنترل مجوز پروکسی‌شده (RFC 4370) با بحرانی بودن تنظیم‌شده روی FALSE را غیرفعال می‌کند. dontusecopy_non_critical پذیرش کنترل dontUseCopy (یک کار در حال پیشرفت) با بحرانی بودن تنظیم‌شده روی FALSE را غیرفعال می‌کند.
olcGentleHUP: { TRUE | FALSE }: سیگنال SIGHUP تنها باعث تلاش برای خاموش شدن 'ملایم' می‌شود: Slapd گوش دادن به اتصالات جدید را متوقف می‌کند، اما اتصالات کلاینت‌های فعلی را نمی‌بندد. با این حال، عملیات نوشتن بعدی خطای unwilling-to-perform را برمی‌گردانند. Slapd زمانی خاتمه می‌یابد که همه کلاینت‌ها اتصالات خود را ببندند (اگر اصلاً ببندند)، یا - مانند قبل - اگر سیگنال SIGTERM دریافت کند. این می‌تواند زمانی مفید باشد که بخواهید سرور را خاتمه دهید و سرور slapd جدیدی را با پایگاه‌داده دیگری بدون ایجاد اختلال برای کلاینت‌های فعال فعلی راه‌اندازی کنید. پیش‌فرض FALSE است. ممکن است بخواهید از olcIdleTimeout همراه با این گزینه استفاده کنید.
olcIdleTimeout: <integer>: تعداد ثانیه‌های انتظار قبل از بستن اجباری یک اتصال کلاینت غیرفعال (idle) را مشخص می‌کند. مقدار 0 این قابلیت را غیرفعال می‌کند. پیش‌فرض 0 است. ممکن است بخواهید گزینه olcWriteTimeout را نیز تنظیم کنید.
olcIndexHash64: { TRUE | FALSE }: استفاده از هش ۶۴ بیتی برای نمایه‌سازی. پیش‌فرض استفاده از هش‌های ۳۲ بیتی است. این هش‌ها برای نمایه‌سازی برابری و زیررشته استفاده می‌شوند. نسخه ۶۴ بیتی ممکن است برای جلوگیری از برخورد نمایه زمانی که تعداد مقادیر نمایه‌شده از حدود ۶۴ میلیون فراتر می‌رود مورد نیاز باشد. (توجه داشته باشید که نمایه‌سازی زیررشته به ازای هر مقدار مشخصه واقعی، چندین مقدار نمایه تولید می‌کند.) نمایه‌های تولیدشده با هش‌های ۳۲ بیتی با نسخه ۶۴ بیتی ناسازگار هستند و برعکس. هنگام تغییر این تنظیم، هر پایگاه‌داده موجود باید به‌طور کامل دوباره بارگذاری شود. این دستور تنها بر روی پردازنده‌های ۶۴ بیتی پشتیبانی می‌شود.
olcIndexIntLen: <integer>: طول کلید را برای نمایه‌های اعداد صحیح مرتب‌شده مشخص می‌کند. پرارزش‌ترین بایت‌های عدد صحیح باینری برای کلیدهای نمایه استفاده می‌شوند. مقدار پیش‌فرض 4 است که نمایه‌سازی دقیق را برای مقادیر ۳۱ بیتی فراهم می‌کند. برای نمایه‌سازی مقادیر بسیار بزرگ از یک نمایش ممیز شناور استفاده می‌شود.
olcIndexSubstrIfMaxlen: <integer>: حداکثر طول را برای نمایه‌های زیرآغازین و زیرپایانی (subinitial و subfinal) مشخص می‌کند. تنها این تعداد کاراکتر از یک مقدار مشخصه توسط توابع نمایه‌سازی پردازش می‌شوند؛ هر کاراکتر اضافی نادیده گرفته می‌شود. پیش‌فرض 4 است.
olcIndexSubstrIfMinlen: <integer>: حداقل طول را برای نمایه‌های زیرآغازین و زیرپایانی مشخص می‌کند. یک مقدار مشخصه باید حداقل این تعداد کاراکتر داشته باشد تا توسط توابع نمایه‌سازی پردازش شود. پیش‌فرض 2 است.
olcIndexSubstrAnyLen: <integer>: طول استفاده‌شده برای نمایه‌های subany را مشخص می‌کند. یک مقدار مشخصه برای پردازش باید حداقل این تعداد کاراکتر داشته باشد. مقادیر مشخصه طولانی‌تر از این طول در بخش‌هایی به این طول پردازش می‌شوند. پیش‌فرض 4 است. نمایه subany همچنین در جستجوهای نمایه subinitial و subfinal زمانی که رشته فیلتر طولانی‌تر از مقدار olcIndexSubstrIfMaxlen باشد استفاده خواهد شد.
olcIndexSubstrAnyStep: <integer>: گام‌های استفاده‌شده در جستجوهای نمایه subany را مشخص می‌کند. این مقدار آفست را برای بخش‌هایی از رشته فیلتر که برای جستجوی نمایه subany پردازش می‌شوند تنظیم می‌کند. پیش‌فرض 2 است. به عنوان مثال، با مقادیر پیش‌فرض، جستجویی با استفاده از فیلتر "cn=*abcdefgh*" جستجوهای نمایه‌ای را برای "abcd"، "cdef" و "efgh" تولید می‌کند.

توجه: پشتیبانی از نمایه‌سازی بستگی به بک‌اند مورد استفاده دارد. همچنین، تغییر این تنظیمات معمولاً نیازمند حذف هر نمایه‌ای است که به این پارامترها وابسته است و ایجاد مجدد آن‌ها با slapindex(8) می‌باشد.

olcListenerThreads: <integer>: تعداد نخ‌های مورد استفاده برای مدیر اتصال را مشخص می‌کند. پیش‌فرض 1 است و این معمولاً برای حداکثر ۱۶ هسته CPU کافی است. مقدار باید روی توانی از ۲ تنظیم شود.
olcLocalSSF: <SSF>: ضریب قدرت امنیتی (SSF) داده‌شده به نشست‌های LDAP محلی، مانند نشست‌های متصل به شنونده ldapi:// را مشخص می‌کند. برای تشریح مقادیر SSF به توضیحات گزینه minssf در olcSaslSecProps مراجعه کنید. پیش‌فرض 71 است.
olcLogFile: <filename>: فایلی را برای ثبت پیام‌های اشکال‌زدایی slapd مشخص می‌کند. این پیام‌ها ارتباطی با پیام‌های ارائه‌شده توسط پارامتر پیکربندی olcLogLevel ندارند. این تنظیم تنها بر دیمن slapd تأثیر می‌گذارد و هیچ تأثیری بر ابزارهای خط فرمان ندارد. به‌طور پیش‌فرض این پیام‌ها تنها به stderr ارسال می‌شوند و در هیچ جای دیگری ثبت نمی‌گردند. مشخص کردن یک فایل گزارش پیام‌ها را هم به stderr و هم به فایل لاگ کپی می‌کند.
olcLogFileFormat: debug|syslog-utc|syslog-localtime|rfc3339-utc: فرمت پیشوند پیام‌های نوشته‌شده در فایل لاگ را مشخص می‌کند. فرمت debug همان فرمت عادی مورد استفاده برای پیام‌های اشکال‌زدایی slapd است، با یک برچسب زمانی در مبنای شانزده، به همراه یک شناسه نخ. سایر گزینه‌ها استفاده از پیشوندهای به سبک syslog(3) با برچسب‌های زمانی در UTC یا در منطقه زمانی محلی هستند. پیش‌فرض فرمت debug است.
olcLogFileOnly: TRUE | FALSE: مشخص می‌کند که پیام‌های اشکال‌زدایی تنها باید به فایل لاگ پیکربندی‌شده بروند و به stderr نروند.
olcLogFileRotate: <max> <Mbytes> <hours>: چرخش خودکار را برای فایل لاگ پیکربندی‌شده به‌عنوان حداکثر تعداد فایل‌های لاگ قدیمی برای نگهداری، حداکثر اندازه بر حسب مگابایت برای رشد فایل لاگ قبل از چرخش، و حداکثر طول عمر بر حسب ساعت برای استفاده از فایل لاگ قبل از چرخش مشخص می‌کند. حداکثر تعداد باید در محدوده ۱ تا ۹۹ باشد. تنظیم Mbytes یا hours روی صفر به ترتیب بررسی اندازه یا طول عمر را غیرفعال می‌کند. حداقل یکی از مقادیر Mbytes یا hours باید غیرصفر باشد. به‌طور پیش‌فرض هیچ چرخش خودکاری انجام نخواهد شد.
olcLogLevel: <integer> [...]: سطحی را مشخص می‌کند که در آن دستورات اشکال‌زدایی و آمار عملیات باید از طریق syslog ثبت شوند (در حال حاضر در امکان LOG_LOCAL4 دیمن syslogd(8) ثبت می‌شود). آن‌ها باید به‌جای سطوح لاگ با جزئیات فزاینده، به‌عنوان زیرسیستم در نظر گرفته شوند. برخی از پیام‌ها با اولویت بالاتر، بدون توجه به loglevel پیکربندی‌شده، به محض پیکربندی هرگونه لاگ‌گیری ثبت می‌شوند. سطوح لاگ افزایشی هستند و سطوح موجود عبارتند از:

1: (0x1 trace) ردیابی فراخوانی‌های توابع
2: (0x2 packets) اشکال‌زدایی مدیریت بسته‌ها
4: (0x4 args) اشکال‌زدایی ردیابی سنگین (آرگومان‌های توابع)
8: (0x8 conns) مدیریت اتصالات
16: (0x10 BER) چاپ بسته‌های ارسالی و دریافتی
32: (0x20 filter) پردازش فیلتر جستجو
64: (0x40 config) پردازش فایل پیکربندی
128: (0x80 ACL) پردازش لیست کنترل دسترسی
256: (0x100 stats) اتصالات، عملیات LDAP، نتایج (توصیه‌شده)
512: (0x200 stats2) مدخل‌های لاگ stats2 ارسال‌شده
1024: (0x400 shell) چاپ ارتباطات با بک‌آندهای شل
2048: (0x800 parse) تجزیه مدخل‌ها
16384: (0x4000 sync) همگام‌سازی LDAPSync
32768: (0x8000 none) فقط پیام‌هایی که صرف‌نظر از سطح لاگ تنظیم‌شده ثبت می‌شوند

سطح لاگ مورد نظر را می‌توان به‌عنوان یک عدد صحیح منفرد که سطوح مورد نظر را ترکیب (OR) می‌کند، چه در نماد ده‌دهی و چه در مبنای شانزده، به‌عنوان فهرستی از اعداد صحیح (که به‌صورت داخلی OR می‌شوند)، یا به‌عنوان فهرستی از نام‌هایی که میان پرانتز نشان داده شده‌اند وارد کرد، به‌طوری که:

olcLogLevel: 129
olcLogLevel: 0x81
olcLogLevel: 128 1
olcLogLevel: 0x80 0x1
olcLogLevel: acl trace

معادل یکدیگر هستند. کلیدواژه any می‌تواند به‌عنوان یک میانبر برای فعال کردن لاگ‌گیری در تمام سطوح استفاده شود (معادل -1). کلیدواژه none، یا نمایش عدد صحیح معادل آن، باعث می‌شود پیام‌هایی که صرف‌نظر از olcLogLevel پیکربندی‌شده ثبت می‌شوند، به ثبت برسند. در واقع، اگر هیچ olcLogLevel تعریف نشود (یا سطح 0 باشد)، هیچ لاگ‌گیری انجام نمی‌شود، بنابراین حداقل سطح none برای ثبت پیام‌های با اولویت بالا مورد نیاز است.

توجه داشته باشید که سطوح packets، BER و parse تنها به‌عنوان خروجی اشکال‌زدایی در stderr در دسترس هستند و به syslog ارسال نمی‌شوند.

این تنظیم به‌طور پیش‌فرض روی stats است. این سطح معمولاً هنگام استفاده از سایر سطوح لاگ نیز باید گنجانده شود تا به تحلیل گزارش‌ها کمک کند.

olcMaxFilterDepth: <integer>: حداکثر عمق فیلترهای تو در تو در درخواست‌های جستجو را مشخص می‌کند. پیش‌فرض 1000 است.
olcPasswordCryptSaltFormat: <format>: فرمت نمک (salt) ارسال‌شده به crypt(3) را هنگام تولید گذرواژه‌های {CRYPT} (به olcPasswordHash مراجعه کنید) در حین پردازش عملیات‌های توسعه‌یافته اصلاح گذرواژه LDAP (RFC 3062) مشخص می‌کند.
این رشته باید در فرمت sprintf(3) باشد و می‌تواند شامل یک (و فقط یک) تبدیل %s باشد. این تبدیل با رشته‌ای از کاراکترهای تصادفی از [A-Za-z0-9./] جایگزین خواهد شد. به عنوان مثال، "%.2s" یک نمک دو کاراکتری را فراهم می‌کند و "$1$%.8s" به برخی از نسخه‌های crypt(3) می‌گوید که از الگوریتم MD5 استفاده کنند و ۸ کاراکتر تصادفی نمک ارائه می‌دهد. پیش‌فرض "%s" است که ۳۱ کاراکتر نمک ارائه می‌کند.
olcPidFile: <filename>: نام (مطلق) فایلی که شناسه فرآیند (PID) سرور slapd را در خود نگه می‌دارد (به getpid(2) مراجعه کنید).
olcPluginLogFile: <filename>: نام (مطلق) فایلی که حاوی پیام‌های لاگ از افزونه‌های SLAPI خواهد بود. برای جزئیات به slapd.plugin(5) مراجعه کنید.
olcReferral: <url>: ارجاعی را مشخص می‌کند که وقتی slapd(8) نمی‌تواند یک پایگاه‌داده محلی برای رسیدگی به یک درخواست پیدا کند، باید بازگردانده شود. اگر چندین مقدار مشخص شود، هر url ارائه می‌شود.
olcReverseLookup: TRUE | FALSE: فعال/غیرفعال کردن جستجوی معکوس تاییدنشده نام کلاینت (پیش‌فرض FALSE است اگر با --enable-rlookups کامپایل شده باشد).
olcRootDSE: <file>: نام یک فایل LDIF(5) حاوی مشخصه‌های تعریف‌شده توسط کاربر را برای DSE ریشه مشخص می‌کند. این مشخصه‌ها علاوه بر مشخصه‌هایی که معمولاً توسط slapd تولید می‌شوند بازگردانده می‌شوند.
مدخل DSE ریشه مدخلی است با اطلاعاتی درباره سرور و قابلیت‌های آن، در مشخصه‌های عملیاتی. این مدخل دارای DN خالی است و می‌توان آن را مثلاً با دستور زیر خواند: ldapsearch -x -b "" -s base "+"
برای جزئیات به بخش ۵.۱ از RFC 4512 مراجعه کنید.
olcSaslAuxprops: <plugin> [...]: مشخص می‌کند که از کدام افزونه‌های auxprop برای جستجوهای احراز هویت استفاده شود. مقدار پیش‌فرض خالی است که صرفاً از پشتیبانی داخلی slapd استفاده می‌کند. معمولاً به هیچ افزونه auxprop دیگری نیاز نیست.
olcSaslAuxpropsDontUseCopy: <attr> [...]: مشخص می‌کند که کدام مشخصه(ها) باید مشمول کنترل don't use copy باشند. این برای کارکرد برخی از مکانیزم‌های SASL مانند OTP در یک محیط همگام‌سازی‌شده (replicated) ضروری است. مشخصه "cmusaslsecretOTP" مقدار پیش‌فرض است.
olcSaslAuxpropsDontUseCopyIgnore TRUE | FALSE: برای غیرفعال کردن همگام‌سازی مشخصه(های) تعریف‌شده توسط olcSaslAuxpropsDontUseCopy و استفاده از یک مقدار محلی برای مشخصه در عوض استفاده می‌شود. این به مکانیزم SASL اجازه می‌دهد تا در صورت آفلاین بودن فراهم‌کننده به کار خود ادامه دهد. این امر می‌تواند باعث ناسازگاری همگام‌سازی شود. پیش‌فرض FALSE است.
olcSaslHost: <fqdn>: برای تعیین نام دامنه کاملاً واجد شرایط (FQDN) مورد استفاده برای پردازش SASL استفاده می‌شود.
olcSaslRealm: <realm>: قلمرو (realm) مربوط به SASL را مشخص می‌کند. پیش‌فرض خالی است.
olcSaslCbinding: none | tls-unique | tls-endpoint: نوع اتصال کانال (channel-binding) را مشخص می‌کند، همچنین به LDAP_OPT_X_SASL_CBINDING مراجعه کنید. پیش‌فرض none است.
olcSaslSecProps: <properties>: برای تعیین خصوصیات امنیتی Cyrus SASL استفاده می‌شود. فلگ none (بدون هیچ خصوصیت دیگری) باعث می‌شود که مقادیر پیش‌فرض خصوصیات یعنی "noanonymous,noplain" پاک شوند. فلگ noplain مکانیزم‌های آسیب‌پذیر در برابر حملات غیرفعال ساده را غیرفعال می‌کند. فلگ noactive مکانیزم‌های آسیب‌پذیر در برابر حملات فعال را غیرفعال می‌کند. فلگ nodict مکانیزم‌های آسیب‌پذیر در برابر حملات فرهنگ‌لغت غیرفعال را غیرفعال می‌کند. فلگ noanonymous مکانیزم‌هایی را که از ورود ناشناس پشتیبانی می‌کنند غیرفعال می‌کند. فلگ forwardsec رازداری پیشرو (forward secrecy) میان نشست‌ها را الزامی می‌کند. فلگ passcred مکانیزم‌هایی را که اعتبارنامه‌های کلاینت را منتقل می‌کنند الزامی می‌سازد (و به مکانیزم‌هایی که می‌توانند اعتبارنامه‌ها را عبور دهند اجازه این کار را می‌دهد). خصوصیت minssf=<factor> حداقل ضریب قدرت امنیتی (SSF) قابل قبول را به‌عنوان یک عدد صحیح تقریبی به طول کلید مؤثر مورد استفاده برای رمزگذاری مشخص می‌کند. مقدار 0 (صفر) به معنای عدم حفاظت است، 1 فقط به معنای حفاظت از یکپارچگی است، 128 به RC4، Blowfish و سایر رمزهای مشابه اجازه می‌دهد، و 256 به رمزهای مدرن نیاز دارد. پیش‌فرض 0 است. خصوصیت maxssf=<factor> حداکثر ضریب قدرت امنیتی قابل قبول را به‌عنوان یک عدد صحیح مشخص می‌کند (به توضیحات minssf مراجعه کنید). پیش‌فرض INT_MAX است. خصوصیت maxbufsize=<size> حداکثر اندازه بافر دریافت لایه امنیتی مجاز را مشخص می‌کند. مقدار 0 لایه‌های امنیتی را غیرفعال می‌کند. پیش‌فرض 65536 است.
olcServerID: <integer> [<URL>]: یک شناسه عددی از 0 تا 4095 را برای این سرور مشخص می‌کند. این شناسه همچنین می‌تواند با پیشوند "0x" به‌صورت هگزادسیمال مشخص شود. شناسه‌های غیرصفر هنگام استفاده از همگام‌سازی چندفراهم‌کننده‌ای (multi-provider) الزامی هستند و هر فراهم‌کننده باید یک شناسه غیرصفر منحصربه‌فرد داشته باشد. توجه داشته باشید که این الزام در مورد فراهم‌کننده‌های جداگانه‌ای که در مجموعه‌ای از پایگاه‌های داده پیوندخورده (glued) مشارکت دارند نیز اعمال می‌شود. اگر URL ارائه شود، این دستورالعمل می‌تواند چندین بار مشخص شود و فهرست کاملی از سرورهای مشارکت‌کننده و شناسه‌های آن‌ها را ارائه دهد. نام میزبان کاملاً واجد شرایط هر سرور باید در URLهای ارائه‌شده استفاده شود. شناسه‌ها در فیلد "شناسه رونوشت" (replica id) تمام CSNهای تولیدشده توسط سرور مشخص‌شده استفاده می‌شوند. مقدار پیش‌فرض صفر است که فقط برای همگام‌سازی تک‌فراهم‌کننده‌ای معتبر است. مثال:

olcServerID: 1 ldap://ldap1.example.com
olcServerID: 2 ldap://ldap2.example.com

olcSockbufMaxIncoming: <integer>: حداکثر اندازه PDU ورودی LDAP را برای نشست‌های ناشناس مشخص می‌کند. پیش‌فرض 262143 است.
olcSockbufMaxIncomingAuth: <integer>: حداکثر اندازه PDU ورودی LDAP را برای نشست‌های احرازشده مشخص می‌کند. پیش‌فرض 4194303 است.
olcTCPBuffer [listener=<URL>] [{read|write}=]<size>: اندازه بافر TCP را مشخص می‌کند. یک مقدار سراسری برای هر دو بافر TCP خواندن و نوشتن مربوط به هر شنونده تعریف می‌شود، مگر اینکه شنونده صریحاً مشخص شده باشد، یا از هر یک از توصیف‌کننده‌های خواندن یا نوشتن استفاده شود. برای جزئیات به tcp(7) مراجعه کنید. توجه داشته باشید که برخی از سیستم‌عامل‌ها تنظیم خودکار بافر TCP را پیاده‌سازی می‌کنند.
olcThreads: <integer>: حداکثر اندازه استخر نخ‌های اولیه (primary thread pool) را مشخص می‌کند. پیش‌فرض 16 است؛ حداقل مقدار 2 است.
olcThreadQueues: <integer>: تعداد صف‌های کاری را برای استخر نخ‌های اولیه مشخص می‌کند. پیش‌فرض 1 است و این معمولاً برای حداکثر ۸ هسته CPU کافی است. مقدار نباید از تعداد CPUهای موجود در سیستم بیشتر باشد.
olcToolThreads: <integer>: حداکثر تعداد نخ‌ها را برای استفاده در حالت ابزار (tool mode) مشخص می‌کند. این مقدار نباید بیشتر از تعداد CPUهای سیستم باشد. پیش‌فرض 1 است.
olcWriteTimeout: <integer>: تعداد ثانیه‌های انتظار قبل از بستن اجباری یک اتصال با نوشتن معلق را مشخص می‌کند. این امکان بازیابی از شرایط مختلف توقف (hang) شبکه را فراهم می‌کند. تنظیم 0 این قابلیت را غیرفعال می‌کند. پیش‌فرض 0 است.

گزینه‌های TLS (TLS OPTIONS)

اگر slapd با پشتیبانی از امنیت لایه انتقال (TLS) کامپایل شده باشد، گزینه‌های بیشتری وجود دارد که می‌توانید مشخص کنید.

olcTLSCipherSuite: <cipher-suite-spec>: امکان پیکربندی رمزهایی که پذیرفته می‌شوند و ترتیب اولویت آن‌ها را فراهم می‌کند. <cipher-suite-spec> باید یک مشخصه رمز برای کتابخانه TLS مورد استفاده (OpenSSL یا GnuTLS) باشد. مثال:

OpenSSL:: olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2
GnuTLS:: olcTLSCiphersuite: SECURE256:!AES-128-CBC

برای بررسی اینکه یک مشخصه معین در OpenSSL چه رمزهایی را انتخاب می‌کند، از دستور زیر استفاده کنید:

openssl ciphers -v <cipher-suite-spec>

در GnuTLS مشخصات موجود را می‌توان در صفحه راهنمای gnutls-cli(1) پیدا کرد (توضیحات گزینه --priority را ببینید).

در نسخه‌های قدیمی‌تر GnuTLS که gnutls-cli از گزینه --priority پشتیبانی نمی‌کند، می‌توانید با فراخوانی دستور زیر فهرست محدودتر رمزها را به دست آورید:

gnutls-cli -l

olcTLSCACertificateFile: <filename>

فایلی را مشخص می‌کند که حاوی گواهی‌های تمام مراجع صدور گواهی (CA) است که slapd آن‌ها را به رسمیت می‌شناسد. گواهی مرجع صدور گواهی که گواهی سرور را امضا کرده است باید در میان این گواهی‌ها گنجانده شود. اگر مرجع امضاکننده یک مرجع صدور گواهی سطح بالا (ریشه) نبود، باید گواهی‌های کل دنباله CAها از CA امضاکننده تا CA سطح بالا وجود داشته باشد. گواهی‌های متعدد صرفاً به فایل اضافه می‌شوند؛ ترتیب آن‌ها اهمیتی ندارد.

olcTLSCACertificatePath: <path>

مسیر پوشه‌هایی را مشخص می‌کند که حاوی گواهی‌های مرجع صدور گواهی در فایل‌های جداگانه منفرد هستند. معمولاً فقط یکی از این گزینه یا olcTLSCACertificateFile تعریف می‌شود. اگر هر دو مشخص شوند، از هر دو مکان استفاده خواهد شد. چندین پوشه را می‌توان با علامت نقطه‌ویرگول (semi-colon) از هم جدا کرد.

olcTLSCACertificate: <CA cert>

یک گواهی CA منفرد را که مورد اعتماد سرور است، در فرمت DER ذخیره می‌کند. اگر این گزینه تنظیم شود، گزینه‌های olcTLSCACertificateFile و olcTLSCACertificatePath نادیده گرفته می‌شوند. اگر به چندین گواهی CA نیاز باشد، باید به جای این گزینه از گزینه‌های olcTLSCACertificateFile یا olcTLSCACertificatePath استفاده شود.

olcTLSCertificateFile: <filename>

فایلی را مشخص می‌کند که حاوی گواهی سرور slapd است.

هنگام استفاده از OpenSSL آن فایل همچنین می‌تواند حاوی هر تعداد گواهی میانی پس از گواهی سرور باشد.

olcTLSCertificate: <cert>

یک گواهی منفرد را برای سرور، در فرمت DER ذخیره می‌کند. اگر از این گزینه استفاده شود، گزینه olcTLSCertificateFile نادیده گرفته می‌شود.

olcTLSCertificateKeyFile: <filename>

فایلی را مشخص می‌کند که حاوی کلید خصوصی سرور slapd منطبق با گواهی سرور مشخص‌شده است. اگر فایل کلید خصوصی با یک گذرواژه محافظت شده باشد، هنگام شروع slapd گذرواژه باید به صورت دستی تایپ شود. معمولاً کلید خصوصی با گذرواژه محافظت نمی‌شود تا slapd بدون دخالت دستی شروع به کار کند، بنابراین بسیار حیاتی است که فایل با دقت محافظت شود.

olcTLSCertificateKey <key>

کلید خصوصی منطبق با گواهی سرور را ذخیره می‌کند. اگر از این گزینه استفاده شود، گزینه olcTLSCertificateKeyFile نادیده گرفته می‌شود.

olcTLSDHParamFile: <filename>

این دستور فایلی را مشخص می‌کند که حاوی پارامترهایی برای تبادل کلید موقت دیفی-هلمن (Diffie-Hellman ephemeral) است. این برای استفاده از گواهی DSA روی سرور یا گواهی RSA که فاقد کاربرد کلید "key encipherment" است لازم می‌باشد. توجه داشته باشید که تنظیم این گزینه ممکن است تبادل کلید دیفی-هلمن ناشناس را نیز در برخی از مجموعه‌های رمز غیرپیش‌فرض فعال کند. به‌طور کلی باید از تبادل کلید ناشناس اجتناب شود زیرا هیچ احراز هویت واقعی کلاینت یا سرور را فراهم نمی‌کند و هیچ حفاظتی در برابر حملات مرد میانی (man-in-the-middle) ارائه نمی‌دهد. باید "!ADH" را به مجموعه‌های رمز خود اضافه کنید تا مطمئن شوید از این مجموعه‌ها استفاده نمی‌شود.

olcTLSECName: <name>

نام منحنی(هایی) را برای استفاده در تبادل کلید موقت دیفی-هلمن منحنی بیضوی (ECDHE) مشخص می‌کند. این گزینه فقط برای OpenSSL استفاده می‌شود. این گزینه با GnuTLS استفاده نمی‌شود؛ منحنی‌ها ممکن است در مشخصات ciphersuite مربوط به GnuTLS انتخاب شوند.

olcTLSProtocolMin: <major>[.<minor>]

حداقل نسخه پروتکل SSL/TLS را که مذاکره خواهد شد مشخص می‌کند. اگر سرور حداقل از آن نسخه پشتیبانی نکند، دست‌تکانی SSL شکست خواهد خورد. برای الزامی کردن TLS 1.x یا بالاتر، این گزینه را روی 3.(x+1) تنظیم کنید، مثلاً:

olcTLSProtocolMin: 3.2

به TLS 1.1 نیاز خواهد داشت. مشخص کردن حداقل نسخه‌ای بالاتر از آنچه توسط پیاده‌سازی OpenLDAP پشتیبانی می‌شود، باعث می‌شود که بالاترین سطحی که پشتیبانی می‌کند الزامی شود. این دستورالعمل در GnuTLS نادیده گرفته می‌شود.

olcTLSRandFile: <filename>

فایلی را برای به دست آوردن بیت‌های تصادفی در زمانی که /dev/[u]random در دسترس نیست مشخص می‌کند. معمولاً روی نام سوکت EGD/PRNGD تنظیم می‌شود. متغیر محیطی RANDFILE نیز می‌تواند برای تعیین نام فایل استفاده شود. این دستورالعمل در GnuTLS نادیده گرفته می‌شود.

olcTLSVerifyClient: <level>

مشخص می‌کند که چه بررسی‌هایی (در صورت وجود) باید روی گواهی‌های کلاینت در یک نشست ورودی TLS انجام شود. مقدار <level> می‌تواند به‌عنوان یکی از کلیدواژه‌های زیر مشخص شود:

never: این مقدار پیش‌فرض است. slapd از کلاینت درخواست گواهی نخواهد کرد.
allow: گواهی کلاینت درخواست می‌شود. اگر گواهی ارائه نشود، نشست به‌طور عادی ادامه می‌یابد. اگر یک گواهی نامعتبر ارائه شود، نادیده گرفته می‌شود و نشست به‌طور عادی ادامه می‌یابد.
try: گواهی کلاینت درخواست می‌شود. اگر گواهی ارائه نشود، نشست به‌طور عادی ادامه می‌یابد. اگر یک گواهی نامعتبر ارائه شود، نشست بلافاصله خاتمه می‌یابد.
demand | hard | true: این کلیدواژه‌ها به دلایل سازگاری همگی معادل هستند. گواهی کلاینت درخواست می‌شود. اگر هیچ گواهی ارائه نشود، یا یک گواهی نامعتبر ارائه شود، نشست بلافاصله خاتمه می‌یابد.
توجه داشته باشید که یک گواهی معتبر کلاینت برای استفاده از مکانیزم احراز هویت SASL EXTERNAL با یک نشست TLS مورد نیاز است. به این ترتیب، برای فعال کردن احراز هویت SASL EXTERNAL باید یک مقدار غیرپیش‌فرض برای olcTLSVerifyClient انتخاب شود.

olcTLSCRLCheck: <level>: مشخص می‌کند که آیا فهرست ابطال گواهی (CRL) مربوط به CA باید برای بررسی اینکه آیا گواهی‌های کلاینت باطل نشده‌اند استفاده شود یا خیر. این نیازمند تنظیم پارامتر olcTLSCACertificatePath است. این پارامتر در GnuTLS نادیده گرفته می‌شود. مقدار <level> می‌تواند به‌عنوان یکی از کلیدواژه‌های زیر مشخص شود:

none: هیچ بررسی CRL انجام نمی‌شود.
peer: فهرست CRL گواهی همتا را بررسی می‌کند.
all: فهرست CRL را برای کل زنجیره گواهی بررسی می‌کند.

olcTLSCRLFile: <filename>: فایلی حاوی فهرست ابطال گواهی را برای تأیید عدم ابطال گواهی‌ها مشخص می‌کند. این پارامتر فقط هنگام استفاده از GnuTLS معتبر است.

گزینه‌های ماژول پویا (DYNAMIC MODULE OPTIONS)

اگر slapd با گزینه --enable-modules کامپایل شده باشد، مدخل‌های مرتبط با ماژول در دسترس خواهند بود. این مدخل‌ها به نام cn=module{x},cn=config نام‌گذاری می‌شوند و باید کلاس شیء olcModuleList را داشته باشند. باید یک مدخل به ازای هر olcModulePath ایجاد شود. معمولاً موتور پیکربندی اندیس "{x}" را در RDN به‌طور خودکار تولید می‌کند، بنابراین هنگام بارگذاری اولیه این مدخل‌ها می‌توان آن را حذف کرد.

olcModuleLoad: <filename> [<arguments>...]: نام یک ماژول قابل بارگذاری پویا را برای بارگذاری و هرگونه آرگومان اضافی را در صورت پشتیبانی توسط ماژول مشخص می‌کند. نام فایل می‌تواند یک مسیر مطلق یا یک نام فایل ساده باشد. نام‌های غیرمطلق در پوشه‌های مشخص‌شده توسط گزینه olcModulePath جستجو می‌شوند.
olcModulePath: <pathspec>: فهرستی از پوشه‌ها را برای جستجوی ماژول‌های قابل بارگذاری مشخص می‌کند. معمولاً این مسیر با دونقطه (colon) جدا می‌شود اما این بستگی به سیستم‌عامل دارد. پیش‌فرض /usr/lib/ldap است، که مکانی است که نصب استاندارد OpenLDAP ماژول‌های خود را در آنجا قرار می‌دهد.

گزینه‌های اسکِما (SCHEMA OPTIONS)

تعاریف اسکِما به‌عنوان مدخل‌هایی در زیردرخت cn=schema,cn=config ایجاد می‌شوند. این مدخل‌ها باید کلاس شیء olcSchemaConfig را داشته باشند. همان‌طور که در بالا اشاره شد، مدخل واقعی cn=schema,cn=config از پیش تعریف شده است و هر مقداری که برای آن مشخص شود نادیده گرفته می‌شود.

olcAttributetypes: ( <oid> [NAME <name>] [DESC <description>] [OBSOLETE] [SUP <oid>] [EQUALITY <oid>] [ORDERING <oid>] [SUBSTR <oid>] [SYNTAX <oidlen>] [SINGLE-VALUE] [COLLECTIVE] [NO-USER-MODIFICATION] [USAGE <attributeUsage>] )

یک نوع مشخصه را با استفاده از نحو LDAPv3 تعریف‌شده در RFC 4512 مشخص می‌کند. تجزیه‌کننده slapd با اجازه دادن به استفاده از فرم‌های رشته‌ای و همچنین OIDهای عددی برای OID مشخصه و OID نحو مشخصه، تعریف RFC 4512 را گسترش می‌دهد (توضیحات olcObjectIdentifier را ببینید).

olcDitContentRules: ( <oid> [NAME <name>] [DESC <description>] [OBSOLETE] [AUX <oids>] [MUST <oids>] [MAY <oids>] [NOT <oids>] )

یک قانون محتوای DIT را با استفاده از نحو LDAPv3 تعریف‌شده در RFC 4512 مشخص می‌کند. تجزیه‌کننده slapd با اجازه دادن به فرم‌های رشته‌ای و همچنین OIDهای عددی برای OID مشخصه و OID نحو مشخصه، تعریف RFC 4512 را گسترش می‌دهد (توضیحات olcObjectIdentifier را ببینید).

olcLdapSyntaxes ( <oid> [DESC <description>] [X-SUBST <substitute-syntax>] )

یک نحو LDAP را با استفاده از نحو LDAPv3 تعریف‌شده در RFC 4512 مشخص می‌کند. تجزیه‌کننده slapd با اجازه دادن به فرم‌های رشته‌ای و همچنین OIDهای عددی برای OID نحو، تعریف RFC 4512 را گسترش می‌دهد (توضیحات objectidentifier را ببینید). تجزیه‌کننده slapd همچنین از پسوند X-SUBST (یک پسوند خاص OpenLDAP) پشتیبانی می‌کند، که به کاربر اجازه می‌دهد از مشخصه olcLdapSyntaxes برای تعریف یک نحو پیاده‌سازی‌نشده به همراه نحو دیگر (مقدار پسوند substitute-syntax) به‌عنوان جایگزین موقت آن استفاده کند. مقدار substitute-syntax باید تعریف شده باشد. این امکان تعریف انواع مشخصه‌ای را می‌دهد که از نحوهای پیاده‌سازی‌نشده با استفاده از OID نحو صحیح استفاده می‌کنند. مگر اینکه X-SUBST استفاده شود، این عبارت پیکربندی به یک خطا منجر می‌شود، زیرا هیچ گرداننده‌ای با ساختار نحو حاصل مرتبط نخواهد بود.

olcObjectClasses: ( <oid> [NAME <name>] [DESC <description>] [OBSOLETE] [SUP <oids>] [{ ABSTRACT | STRUCTURAL | AUXILIARY }] [MUST <oids>] [MAY <oids>] )

یک کلاس شیء را با استفاده از نحو LDAPv3 تعریف‌شده در RFC 4512 مشخص می‌کند. تجزیه‌کننده slapd با اجازه دادن به فرم‌های رشته‌ای و همچنین OIDهای عددی برای OID کلاس شیء، تعریف RFC 4512 را گسترش می‌دهد (توضیحات olcObjectIdentifier را ببینید). کلاس‌های شیء به‌طور پیش‌فرض "STRUCTURAL" هستند.

olcObjectIdentifier: <name> { <oid> | <name>[:<suffix>] }: یک نام رشته‌ای را تعریف می‌کند که با OID داده‌شده برابری می‌کند. این رشته می‌تواند به جای OID عددی در تعاریف کلاس شیء و مشخصه استفاده شود. این نام همچنین می‌تواند با پسوندی به شکل ":xx" استفاده شود که در این صورت از مقدار "oid.xx" استفاده خواهد شد.

گزینه‌های عمومی بک‌اند (GENERAL BACKEND OPTIONS)

گزینه‌ها در این مدخل‌ها تنها برای پیکربندی یک نوع منفرد از بک‌اند اعمال می‌شوند. همه بک‌اندها ممکن است از این دسته گزینه‌ها پشتیبانی کنند، اما در حال حاضر تنها back-mdb از آن پشتیبانی می‌کند. مدخل باید به نام olcBackend=<databasetype>,cn=config نام‌گذاری شود و باید دارای کلاس شیء olcBackendConfig باشد. <databasetype> باید یکی از موارد زیر باشد: asyncmeta، config، dnssrv، ldap، ldif، mdb، meta، monitor، null، passwd، perl، relay، sock، sql، یا wt. در حال حاضر، تنها back-mdb گزینه‌هایی از این نوع را پیاده‌سازی می‌کند، بنابراین این مدخل نباید برای هیچ بک‌اند دیگری استفاده شود.

گزینه‌های پایگاه‌داده (DATABASE OPTIONS)

گزینه‌های پایگاه‌داده در مدخل‌هایی به نام olcDatabase={x}<databasetype>,cn=config تنظیم می‌شوند و باید کلاس شیء olcDatabaseConfig را داشته باشند. معمولاً موتور پیکربندی اندیس "{x}" را در RDN به‌طور خودکار تولید می‌کند، بنابراین هنگام بارگذاری اولیه این مدخل‌ها می‌توان آن را حذف کرد.

پایگاه‌داده ویژه frontend همیشه شماره "{-1}" را دارد و پایگاه‌داده config همیشه شماره "{0}" را به خود اختصاص می‌دهد.

گزینه‌های سراسری پایگاه‌داده (GLOBAL DATABASE OPTIONS)

گزینه‌ها در این بخش ممکن است در پایگاه‌داده ویژه "frontend" تنظیم شوند و در تمام پایگاه‌های داده دیگر به ارث برده شوند. این گزینه‌ها ممکن است با تنظیمات بیشتر در هر پایگاه‌داده خاص تغییر یابند. مدخل frontend باید به نام olcDatabase=frontend,cn=config نام‌گذاری شود و باید دارای کلاس شیء olcFrontendConfig باشد.

olcAccess: to <what> [ by <who> <access> <control> ]+

اعطای دسترسی (مشخص‌شده با <access>) به مجموعه‌ای از مدخل‌ها و/یا مشخصه‌ها (مشخص‌شده با <what>) توسط یک یا چند درخواست‌کننده (مشخص‌شده با <who>). اگر هیچ کنترل دسترسی وجود نداشته باشد، خط‌مشی پیش‌فرض به هر کسی اجازه می‌دهد تا همه‌چیز را بخواند اما به‌روزرسانی‌ها را به rootdn محدود می‌کند (مثلاً: "olcAccess: to * by * read"). برای جزئیات به slapd.access(5) و "راهنمای مدیر OpenLDAP" مراجعه کنید.

کنترل‌های دسترسی تنظیم‌شده در frontend به هرگونه کنترل دسترسی تنظیم‌شده در پایگاه‌های داده خاص اضافه (ضمیمه) می‌شوند. rootdn یک پایگاه‌داده همیشه می‌تواند همه چیز را در آن پایگاه‌داده بخواند و بنویسد.

در مورد کنترل‌های دسترسی در پایگاه‌داده config باید مراقبت فوق‌العاده ویژه‌ای انجام شود. برخلاف سایر پایگاه‌های داده، خط‌مشی پیش‌فرض برای پایگاه‌داده config این است که فقط به rootdn اجازه دسترسی دهد. کاربران عادی نباید دسترسی خواندن داشته باشند و دسترسی نوشتن باید با دقت بسیار به مدیران ممتاز اعطا شود.

olcDefaultSearchBase: <dn>

یک پایه جستجوی پیش‌فرض را برای استفاده در زمانی که کلاینت یک درخواست جستجوی غیرپایه را با DN پایه خالی ارسال می‌کند، مشخص می‌کند. درخواست‌های جستجوی با دامنه پایه با DN پایه خالی تحت تأثیر قرار نمی‌گیرند. این تنظیم فقط در مدخل frontend مجاز است.

olcExtraAttrs: <attr>

مشخصه‌هایی را که باید به درخواست‌های جستجو اضافه شوند فهرست می‌کند. بک‌آندهای ذخیره‌سازی محلی کل مدخل را به frontend برمی‌گردانند. frontend مراقبت می‌کند که فقط مشخصه‌های درخواستی که توسط ACLها مجاز هستند بازگردانده شوند. با این حال، قابلیت‌هایی مانند بررسی دسترسی و غیره ممکن است به مشخصه‌های خاصی نیاز داشته باشند که به‌طور خودکار توسط بک‌آندهای ذخیره‌سازی از راه دور، مانند بک‌آندهای پروکسی و غیره بازگردانده نمی‌شوند. <attr> مشخصه‌ای است که برای اهداف داخلی مورد نیاز است و بنابراین همیشه باید جمع‌آوری شود، حتی زمانی که صریحاً توسط کلاینت‌ها درخواست نشده باشد. این مشخصه چندمقداری است.

olcPasswordHash: <hash> [<hash>...]

این گزینه یک یا چند هش را برای استفاده در تولید گذرواژه‌های کاربر ذخیره‌شده در مشخصه userPassword در حین پردازش عملیات‌های توسعه‌یافته اصلاح گذرواژه LDAP (RFC 3062) پیکربندی می‌کند. مقدار <hash> باید یکی از موارد {SSHA}، {SHA}، {SMD5}، {MD5}، {CRYPT} و {CLEARTEXT} باشد. پیش‌فرض {SSHA} است.

{SHA} و {SSHA} از الگوریتم SHA-1 (FIPS 160-1) استفاده می‌کنند که دومی همراه با نمک (seed) است.

{MD5} و {SMD5} از الگوریتم MD5 (RFC 1321) استفاده می‌کنند که دومی همراه با نمک است.

{CRYPT} از crypt(3) استفاده می‌کند.

{CLEARTEXT} نشان می‌دهد که گذرواژه جدید باید به‌عنوان متن واضح به userPassword اضافه شود.

توجه داشته باشید که این گزینه رفتار عادی برنامه‌های کاربردی با userPassword در طول عملیات‌های Add ،Modify یا سایر عملیات‌های LDAP را تغییر نمی‌دهد. این تنظیم فقط در مدخل frontend مجاز است.

olcReadOnly: TRUE | FALSE

این گزینه پایگاه‌داده را در حالت "فقط‌خواندنی" قرار می‌دهد. هرگونه تلاش برای تغییر پایگاه‌داده خطای "unwilling to perform" را برمی‌گرداند. به‌طور پیش‌فرض، olcReadOnly برابر با FALSE است. توجه داشته باشید که وقتی این گزینه در frontend روی TRUE تنظیم شود، بدون راه‌اندازی مجدد سرور نمی‌توان آن را بازنشانی کرد، زیرا نوشتن‌های بعدی در پایگاه‌داده config رد خواهند شد.

olcRequires: <conditions>

مجموعه‌ای از شرایط را برای الزامی بودن مشخص می‌کند (پیش‌فرض هیچ‌کدام است). این دستور می‌تواند به‌صورت سراسری و/یا به ازای هر پایگاه‌داده مشخص شود؛ پایگاه‌های داده شرایط سراسری را به ارث می‌برند، بنابراین مشخصات به ازای هر پایگاه‌داده افزایشی هستند. bind عملیات اتصال (bind) را قبل از عملیات فهرست راهنما الزامی می‌کند. LDAPv3 الزامی می‌کند که نشست از نسخه ۳ پروتکل LDAP استفاده کند. authc احراز هویت را قبل از عملیات دایرکتوری الزامی می‌کند. SASL احراز هویت SASL را قبل از عملیات دایرکتوری الزامی می‌کند. strong احراز هویت قوی را قبل از عملیات دایرکتوری الزامی می‌کند. کلیدواژه strong امکان احراز هویت "ساده" محافظت‌شده و همچنین احراز هویت SASL را فراهم می‌کند. none می‌تواند برای عدم الزام هیچ شرطی استفاده شود (برای پاک کردن شرایط تعیین‌شده سراسری در یک پایگاه‌داده خاص مفید است)؛ این مورد باید در ابتدا در فهرست شرایط ظاهر شود.

olcRestrict: <oplist>

فهرستی از عملیات‌های محدودشده را مشخص می‌کند. محدودیت‌ها روی یک پایگاه‌داده خاص هرگونه تنظیم frontend را بازنویسی می‌کنند. عملیات‌ها می‌توانند هر یک از موارد add، bind، compare، delete، extended[=<OID>]، modify، rename، search، یا شبه‌عملیات‌های ویژه read و write باشند که به ترتیب عملیات خواندن و نوشتن را خلاصه می‌کنند. استفاده از restrict write معادل olcReadOnly: TRUE است (در بالا ببینید). کلیدواژه extended به کاربر اجازه می‌دهد OID عملیات خاصی را که باید محدود شود نشان دهد.

olcSchemaDN: <dn>

نام متمایز (DN) را برای زیرمدخل subschema که مدخل‌های روی این سرور را کنترل می‌کند مشخص می‌کند. پیش‌فرض "cn=Subschema" است.

olcSecurity: <factors>

مجموعه‌ای از فاکتورهای قدرت امنیتی (جدا شده با فاصله) را برای الزامی بودن مشخص می‌کند (برای تشریح فاکتورهای قدرت امنیتی به گزینه minssf در olcSaslSecprops مراجعه کنید). این دستور می‌تواند به‌صورت سراسری و/یا به ازای هر پایگاه‌داده مشخص شود. ssf=<n> ضریب قدرت امنیتی کلی را مشخص می‌کند. transport=<n> ضریب قدرت امنیتی انتقال را مشخص می‌کند. tls=<n> ضریب قدرت امنیتی TLS را مشخص می‌کند. sasl=<n> ضریب قدرت امنیتی SASL را مشخص می‌کند. update_ssf=<n> ضریب قدرت امنیتی کلی مورد نیاز برای به‌روزرسانی‌های دایرکتوری را مشخص می‌کند. update_transport=<n> ضریب قدرت امنیتی انتقال مورد نیاز برای به‌روزرسانی‌های دایرکتوری را مشخص می‌کند. update_tls=<n> ضریب قدرت امنیتی TLS مورد نیاز برای به‌روزرسانی‌های دایرکتوری را مشخص می‌کند. update_sasl=<n> ضریب قدرت امنیتی SASL مورد نیاز برای به‌روزرسانی‌های دایرکتوری را مشخص می‌کند. simple_bind=<n> ضریب قدرت امنیتی مورد نیاز برای احراز هویت ساده نام‌کاربری/گذرواژه را مشخص می‌کند. توجه داشته باشید که فاکتور transport معیاری از امنیت ارائه‌شده توسط لایه انتقال زیرین است، مانند ldapi:// (و در نهایت IPSEC). این مورد معمولاً استفاده نمی‌شود.

olcSizeLimit: {<integer>|unlimited}

olcSizeLimit: size[.{soft|hard}]=<integer> [...]

حداکثر تعداد مدخل‌هایی را که باید از یک عملیات جستجو بازگردانده شوند مشخص می‌کند. محدودیت اندازه پیش‌فرض 500 است. از unlimited برای تعیین عدم وجود محدودیت استفاده کنید. فرمت دوم امکان تنظیم دقیق محدودیت‌های اندازه را فراهم می‌کند. اگر هیچ توصیف‌کننده خاصی مشخص نشده باشد، هر دو محدودیت نرم (soft) و سخت (hard) تنظیم می‌شوند. آرگومان‌های اضافی را می‌توان در همان مقدار اضافه کرد. توصیف‌کننده‌های اضافی در دسترس هستند؛ برای توضیح تمام فلگ‌های مختلف به olcLimits مراجعه کنید.

olcSortVals: <attr> [...]

فهرستی از مشخصه‌های چندمقداری را مشخص می‌کند که مقادیر آن‌ها همیشه به صورت مرتب‌شده نگهداری می‌شوند. استفاده از این گزینه باعث می‌شود که ارزیابی‌های Modify ،Compare و فیلتر روی این مشخصه‌ها با کارایی بیشتری انجام شود. ترتیب مرتب‌سازی حاصل به نحو و قوانین تطابق مشخصه بستگی دارد و ممکن است با ترتیب واژگانی یا هر ترتیب قابل تشخیص دیگری مطابقت نداشته باشد. این تنظیم فقط در مدخل frontend مجاز است.

olcTimeLimit: {<integer>|unlimited}

olcTimeLimit: time[.{soft|hard}]=<integer> [...]

حداکثر تعداد ثانیه‌هایی (در زمان واقعی) را که slapd برای پاسخ دادن به یک درخواست جستجو صرف می‌کند مشخص می‌کند. محدودیت زمانی پیش‌فرض 3600 است. از unlimited برای تعیین عدم وجود محدودیت استفاده کنید. فرمت دوم امکان تنظیم دقیق محدودیت‌های زمانی را فراهم می‌کند. آرگومان‌های اضافی را می‌توان در همان مقدار اضافه کرد. برای توضیح فلگ‌های مختلف به olcLimits مراجعه کنید.

گزینه‌های عمومی پایگاه‌داده (GENERAL DATABASE OPTIONS)

گزینه‌ها در این بخش تنها برای پایگاه‌داده خاصی که در آن تعریف شده‌اند اعمال می‌شوند. آن‌ها توسط هر نوع بک‌آندی پشتیبانی می‌شوند. تمام گزینه‌های سراسری پایگاه‌داده نیز ممکن است در اینجا استفاده شوند.

olcAddContentAcl: TRUE | FALSE: کنترل می‌کند که آیا عملیات Add بررسی‌های ACL را روی محتوای مدخل در حال اضافه شدن انجام دهد یا خیر. این بررسی به‌طور پیش‌فرض خاموش است. برای جزئیات بیشتر در مورد الزامات ACL برای عملیات Add به صفحه راهنمای slapd.access(5) مراجعه کنید.
olcHidden: TRUE | FALSE: کنترل می‌کند که آیا از پایگاه‌داده برای پاسخ به پرس‌وجوها استفاده شود یا خیر. پایگاه‌داده‌ای که مخفی باشد هرگز برای پاسخگویی به هیچ پرس‌وجویی انتخاب نخواهد شد، و هر پسوند (suffix) پیکربندی‌شده روی پایگاه‌داده در بررسی‌های تداخل با سایر پایگاه‌های داده نادیده گرفته می‌شود. به‌طور پیش‌فرض، olcHidden برابر با FALSE است.
olcLastMod: TRUE | FALSE: کنترل می‌کند که آیا slapd به‌طور خودکار مشخصه‌های modifiersName ،modifyTimestamp ،creatorsName و createTimestamp را برای مدخل‌ها نگهداری کند یا خیر. همچنین مشخصه‌های entryCSN و entryUUID را که توسط فراهم‌کننده syncrepl مورد نیاز است کنترل می‌کند. به‌طور پیش‌فرض، olcLastMod برابر با TRUE است.
olcLastBind: TRUE | FALSE: کنترل می‌کند که آیا slapd به‌طور خودکار مشخصه pwdLastSuccess را برای مدخل‌ها نگهداری کند یا خیر. به‌طور پیش‌فرض، olcLastBind برابر با FALSE است.
olcLastBindPrecision: <integer>: اگر olcLastBind فعال باشد، مشخص می‌کند که pwdLastSuccess هر چند وقت یک‌بار باید به‌روزرسانی شود. بیش از integer ثانیه باید از آخرین اتصال موفقیت‌آمیز گذشته باشد. در یک محیط همگام‌سازی‌شده با فعالیت مکرر bind ممکن است تنظیم این مورد روی یک مقدار بزرگ مفید باشد.
olcLimits: <selector> <limit> [<limit> [...]]: محدودیت‌های زمانی و اندازه را بر اساس آغازگر عملیات یا DN پایه مشخص می‌کند. آرگومان <selector> می‌تواند هر یک از موارد زیر باشد:

anonymous | users | [<dnspec>=]<pattern> | group[/oc[/at]]=<pattern>

به همراه:

<dnspec> ::= dn[.<type>][.<style>]
<type> ::= self | this
<style> ::= exact | base | onelevel | subtree | children | regex | anonymous

نوع DN مقدار self پیش‌فرض است و به معنای کاربر متصل‌شده می‌باشد، در حالی که this به معنای DN پایه عملیات است. اصطلاح anonymous با تمام کلاینت‌های احرازهویت‌نشده مطابقت دارد. اصطلاح users با تمام کلاینت‌های احرازهویت‌شده مطابقت دارد؛ در غیر این صورت یک الگوی dn از نوع exact فرض می‌شود مگر اینکه با توصیف رشته کلیدی (اختیاری) dn با exact یا base (که مترادف هستند)، برای الزام تطابق دقیق؛ با onelevel، برای الزام تطابق دقیقاً یک سطح عمق؛ با subtree، برای مجاز بودن هر سطح از عمق، شامل تطابق دقیق؛ با children، برای مجاز بودن هر سطح از عمق، بدون شامل شدن تطابق دقیق؛ مشخص شده باشد. regex صریحاً نیاز به تطابق بر اساس الگوی عبارت منظم (توسعه‌یافته) POSIX را الزامی می‌کند. در نهایت، anonymous با عملیات‌های متصل‌نشده مطابقت دارد؛ فیلد pattern نادیده گرفته می‌شود. رفتار مشابهی با استفاده از شکل anonymous در بند <selector> به دست می‌آید. اصطلاح group، با فیلدهای اختیاری کلاس شیء oc و نوع مشخصه at، به دنبال pattern، محدودیت‌ها را برای هر DN فهرست‌شده در مقادیر مشخصه at (پیش‌فرض member) از کلاس شیء گروه oc (پیش‌فرض groupOfNames) که DN آن دقیقاً با pattern مطابقت دارد تنظیم می‌کند.

محدودیت‌های پشتیبانی‌شده فعلی size و time هستند.

نحو محدودیت‌های زمانی time[.{soft|hard}]=<integer> است، که در آن integer تعداد ثانیه‌هایی است که slapd برای پاسخ به درخواست جستجو صرف می‌کند. اگر هیچ محدودیت زمانی صریحاً توسط کلاینت درخواست نشود، از محدودیت soft استفاده می‌شود؛ اگر محدودیت زمانی درخواستی از محدودیت hard فراتر رود، مقدار محدودیت سخت به جای آن استفاده می‌شود. اگر محدودیت hard روی کلیدواژه soft تنظیم شده باشد، در هر دو حالت از محدودیت نرم استفاده می‌شود؛ اگر روی کلیدواژه unlimited تنظیم شده باشد، هیچ محدودیت سختی اعمال نمی‌گردد. درخواست‌های صریح برای محدودیت‌های زمانی کوچکتری یا مساوی با محدودیت hard پذیرفته می‌شوند. اگر هیچ توصیف‌کننده محدودیتی تنظیم نشده باشد، مقدار به محدودیت soft اختصاص داده می‌شود و محدودیت hard روی soft تنظیم می‌شود تا رفتار اولیه حفظ شود.

نحو محدودیت‌های اندازه size[.{soft|hard|unchecked}]=<integer> است، که در آن integer حداکثر تعداد مدخل‌هایی است که slapd هنگام پاسخ به درخواست جستجو بازمی‌گرداند. اگر هیچ محدودیت اندازه‌ای صریحاً توسط کلاینت درخواست نشود، از محدودیت soft استفاده می‌شود؛ اگر محدودیت اندازه درخواستی از محدودیت hard فراتر رود، مقدار محدودیت سخت به جای آن استفاده می‌شود. اگر محدودیت hard روی کلیدواژه soft تنظیم شده باشد، در هر دو حالت از محدودیت نرم استفاده می‌شود؛ اگر روی کلیدواژه unlimited تنظیم شده باشد، هیچ محدودیت سختی اعمال نمی‌شود. درخواست‌های صریح برای محدودیت‌های اندازه کوچکتر یا مساوی با محدودیت hard پذیرفته می‌شوند. توصیف‌کننده unchecked محدودیتی را بر روی تعداد نامزدهایی که یک درخواست جستجو مجاز به بررسی آن‌ها است تنظیم می‌کند. منطق پشت آن این است که جستجوها برای مشخصه‌هایی که به‌درستی نمایه‌سازی نشده‌اند ممکن است به مجموعه‌های بزرگی از نامزدها منجر شود که باید توسط slapd(8) بررسی شوند تا مشخص گردد آیا با فیلتر جستجو مطابقت دارند یا خیر. محدودیت unchecked ابزاری برای لغو چنین عملیاتی قبل از شروع آن‌ها فراهم می‌کند. اگر نامزدهای انتخاب‌شده از محدودیت unchecked فراتر روند، جستجو با خطای Unwilling to perform لغو می‌شود. اگر روی کلیدواژه unlimited تنظیم شده باشد، هیچ محدودیتی اعمال نمی‌شود (پیش‌فرض). اگر روی disabled تنظیم شود، جستجو حتی انجام نمی‌شود؛ این می‌تواند برای غیرمجاز کردن جستجوها برای یک دسته خاص از کاربران استفاده شود. اگر هیچ توصیف‌کننده محدودیتی تنظیم نشده باشد، مقدار به محدودیت soft اختصاص می‌یابد و محدودیت hard روی soft تنظیم می‌شود تا رفتار اولیه حفظ گردد.

در صورت عدم تطابق، از محدودیت‌های سراسری استفاده می‌شود. مقادیر پیش‌فرض مشابه مقادیر olcSizeLimit و olcTimeLimit است؛ هیچ محدودیتی روی unchecked تنظیم نشده است.

اگر کنترل pagedResults درخواست شود، محدودیت اندازه hard به‌طور پیش‌فرض استفاده می‌شود، زیرا درخواست اندازه صفحه مشخص به‌عنوان یک درخواست صریح برای محدودیت در تعداد مدخل‌های بازگردانده‌شده در نظر گرفته می‌شود. با این حال، محدودیت اندازه بر تعداد کل مدخل‌های بازگردانده‌شده در جستجو اعمال می‌شود، نه بر یک صفحه منفرد. محدودیت‌های اندازه اضافی ممکن است اعمال شود؛ نحو آن size.pr={<integer>|noEstimate|unlimited} است، که در آن integer حداکثر اندازه صفحه است اگر هیچ محدودیت صریحی تنظیم نشده باشد؛ کلیدواژه noEstimate سرور را از برگرداندن تخمینی از تعداد کل مدخل‌هایی که ممکن است بازگردانده شوند بازمی‌دارد (توجه: پیاده‌سازی فعلی هیچ تخمینی را برنمی‌گرداند). کلیدواژه unlimited نشان می‌دهد که هیچ محدودیتی برای اندازه صفحه کنترل pagedResults اعمال نمی‌شود. نحو size.prtotal={<integer>|hard|unlimited|disabled} امکان تعیین محدودیت در تعداد کل مدخل‌هایی را که کنترل pagedResults برمی‌گرداند فراهم می‌کند. به‌طور پیش‌فرض روی محدودیت hard تنظیم شده است که از مقدار size.hard استفاده خواهد کرد. هنگام تنظیم، integer حداکثر تعداد مدخل‌هایی است که کل جستجو با کنترل pagedResults می‌تواند برگرداند. از unlimited برای مجاز ساختن بازگرداندن تعداد نامحدودی مدخل استفاده کنید، مثلاً برای استفاده از کنترل pagedResults به‌عنوان ابزاری برای دور زدن محدودیت‌های اندازه در جستجوهای عادی؛ کلیدواژه disabled کنترل را غیرفعال می‌کند، یعنی هیچ نتیجه صفحه‌بندی‌شده‌ای نمی‌تواند بازگردانده شود. توجه داشته باشید که تعداد کل مدخل‌های بازگردانده‌شده هنگام درخواست کنترل pagedResults نمی‌تواند از محدودیت اندازه hard جستجوهای عادی فراتر رود مگر اینکه با سوییچ prtotal گسترش یابد.

عبارت olcLimits معمولاً برای اجازه دادن به بازگرداندن تعداد نامحدودی مدخل توسط جستجوهای انجام‌شده با هویتی که توسط مصرف‌کننده برای اهداف همگام‌سازی از طریق پروتکل همگام‌سازی محتوای RFC 4533 LDAP استفاده می‌شود، به‌کار می‌رود (برای جزئیات به olcSyncrepl مراجعه کنید).

هنگام استفاده از پایگاه‌های داده زیرمجموعه (subordinate)، لازم است هر محدودیتی که قرار است در والد و زیرمجموعه‌های آن اعمال شود، هم در والد و هم در زیرمجموعه‌های آن تعریف شود. در غیر این صورت تنظیمات روی پایگاه‌های داده زیرمجموعه رعایت نمی‌شوند.

olcMaxDerefDepth: <depth>

حداکثر تعداد نام‌های مستعار (aliases) را برای ارجاع‌زدایی هنگام تلاش برای تفکیک یک مدخل مشخص می‌کند که برای جلوگیری از حلقه‌های نامتناهی نام مستعار استفاده می‌شود. پیش‌فرض 15 است.

olcMultiProvider: TRUE | FALSE

این گزینه پایگاه‌داده مصرف‌کننده را در حالت Multi-Provider قرار می‌دهد. عملیات به‌روزرسانی از هر کاربری پذیرفته می‌شود، نه فقط از updatedn. پایگاه‌داده باید از قبل به‌عنوان یک مصرف‌کننده syncrepl پیکربندی شده باشد تا بتوان این کلیدواژه را تنظیم کرد. این حالت همچنین نیازمند پیکربندی یک olcServerID (در بالا ببینید) است. به‌طور پیش‌فرض، این تنظیم FALSE است.

olcMonitoring: TRUE | FALSE

این گزینه نظارت خاص پایگاه‌داده را در مدخل مربوط به پایگاه‌داده فعلی در زیردرخت "cn=Databases,cn=Monitor" پایگاه‌داده مانیتور، در صورتی که پایگاه‌داده مانیتور فعال باشد، فعال می‌کند. در حال حاضر، تنها پایگاه‌داده MDB نظارت خاص پایگاه‌داده را ارائه می‌دهد. اگر نظارت توسط بک‌اند پشتیبانی شود، پیش‌فرض روی TRUE است، در غیر این صورت FALSE.

olcPlugin: <plugin_type> <lib_path> <init_function> [<arguments>]

یک افزونه SLAPI را پیکربندی می‌کند. برای جزئیات بیشتر به صفحه راهنمای slapd.plugin(5) مراجعه کنید.

olcRootDN: <dn>

نام متمایزی را مشخص می‌کند که مشمول محدودیت‌های کنترل دسترسی یا محدودیت‌های اداری برای عملیات روی این پایگاه‌داده نیست. این DN ممکن است با یک مدخل مرتبط باشد یا نباشد. یک DN ریشه خالی (پیش‌فرض) مشخص می‌کند که هیچ دسترسی ریشه‌ای اعطا نمی‌شود. توصیه می‌شود rootdn فقط در صورت نیاز مشخص شود (مانند زمان پر کردن اولیه یک پایگاه‌داده). اگر rootdn در یک namingContext (پسوند) پایگاه‌داده باشد، می‌توان با استفاده از دستور olcRootPW یک گذرواژه اتصال ساده نیز ارائه داد. بسیاری از قابلیت‌های اختیاری، از جمله syncrepl، نیازمند تعریف rootdn برای پایگاه‌داده هستند. مقدار olcRootDN مربوط به پایگاه‌داده cn=config به‌طور پیش‌فرض خود cn=config است.

olcRootPW: <password>

یک گذرواژه (یا هش گذرواژه) برای rootdn مشخص می‌کند. گذرواژه تنها در صورتی می‌تواند تنظیم شود که rootdn درون namingContext (پسوند) پایگاه‌داده باشد. این گزینه تمام فرمت‌های userPassword استاندارد RFC 2307 شناخته‌شده برای سرور (به توضیحات olcPasswordHash مراجعه کنید) و همچنین متن آشکار (cleartext) را می‌پذیرد. می‌توان از slappasswd(8) برای تولید هش گذرواژه استفاده کرد. گذرواژه‌های متن آشکار و {CRYPT} توصیه نمی‌شوند. اگر خالی باشد (پیش‌فرض)، احراز هویت DN ریشه با روش‌های دیگر (مثلاً SASL) انجام می‌شود. استفاده از SASL تشویق می‌شود.

olcSubordinate: [TRUE | FALSE | advertise]

مشخص می‌کند که پایگاه‌داده بک‌اند فعلی زیرمجموعه پایگاه‌داده بک‌اند دیگری است. یک پایگاه‌داده زیرمجموعه فقط می‌تواند یک پسوند داشته باشد. این گزینه می‌تواند برای پیوند دادن چندین پایگاه‌داده در یک namingContext واحد استفاده شود. اگر پسوند پایگاه‌داده فعلی درون namingContext یک پایگاه‌داده برتر باشد، جستجوها در برابر پایگاه‌داده برتر به پایگاه‌داده زیرمجموعه نیز منتقل می‌شوند. تمام پایگاه‌های داده مرتبط با یک namingContext واحد باید rootdn یکسان داشته باشند. رفتار سایر عملیات LDAP تحت تأثیر این تنظیم قرار نمی‌گیرد. به‌طور خاص، امکان استفاده از moddn برای انتقال یک مدخل از یک زیرمجموعه به زیرمجموعه دیگر در یک namingContext وجود ندارد.

اگر فلگ اختیاری advertise ارائه شود، بافت نام‌گذاری این پایگاه‌داده در DSE ریشه تبلیغ می‌شود. پیش‌فرض این است که این بافت پایگاه‌داده مخفی شود، به طوری که تنها بافت برتر قابل مشاهده باشد.

اگر از ابزارهای slap شامل slapcat(8)، slapadd(8)، slapmodify(8) یا slapindex(8) روی پایگاه‌داده برتر استفاده شود، هر زیرمجموعه پیوندخورده‌ای که از این ابزارها پشتیبانی می‌کند نیز باز می‌شود.

پایگاه‌های داده‌ای که به هم پیوند خورده‌اند معمولاً باید با همان نمایه‌ها پیکربندی شوند (با فرض اینکه از نمایه‌سازی پشتیبانی کنند)، حتی برای مشخصه‌هایی که فقط در برخی از این پایگاه‌های داده وجود دارند. به‌طور کلی، تمام پایگاه‌های داده پیوندخورده باید تا حد امکان به طور مشابه پیکربندی شوند، زیرا هدف ارائه ظاهر یک فهرست راهنمای واحد است.

توجه داشته باشید که عملکرد subordinate در داخل توسط اورلی glue پیاده‌سازی شده است و به همین دلیل رفتار آن با سایر اورلی‌های مورد استفاده تعامل خواهد داشت. به‌طور پیش‌فرض، اورلی glue به‌طور خودکار به‌عنوان آخرین اورلی در پایگاه‌داده برتر پیکربندی می‌شود. موقعیت آن در پایگاه‌داده را می‌توان با تنظیم دستور overlay glue در موقعیت مورد نظر صریحاً پیکربندی کرد. این پیکربندی صریح برای مثال هنگام استفاده از اورلی syncprov ضروری است، که باید بعد از glue قرار گیرد تا بر روی تمام پایگاه‌های داده پیوندخورده کار کند. به عنوان مثال:

dn: olcDatabase={1}mdb,cn=config
olcSuffix: dc=example,dc=com
...
dn: olcOverlay={0}glue,olcDatabase={1}mdb,cn=config
...
dn: olcOverlay={1}syncprov,olcDatabase={1}mdb,cn=config
...

برای جزئیات بیشتر به بخش اورلی‌ها در زیر مراجعه کنید.

olcSuffix: <dn suffix>: پسوند DN پرس‌وجوهایی را که به این پایگاه‌داده بک‌اند ارسال می‌شوند مشخص می‌کند. چندین خط پسوند را می‌توان ارائه داد و حداقل یکی از آن‌ها برای هر تعریف پایگاه‌داده الزامی است.
اگر پسوند یک پایگاه‌داده "درون" پایگاه‌داده دیگری باشد، پایگاه‌داده با پسوند داخلی باید ابتدا در فایل پیکربندی قرار گیرد. همچنین ممکن است بخواهید چنین پایگاه‌های داده‌ای را با مشخصه olcSubordinate به هم پیوند دهید.
olcSyncUseSubentry: TRUE | FALSE: ذخیره contextCSN مربوط به syncrepl در یک زیرمدخل (subentry) به جای مدخل بافت پایگاه‌داده. مقدار RDN زیرمدخل "cn=ldapsync" خواهد بود. پیش‌فرض FALSE است، به این معنی که contextCSN در مدخل بافت ذخیره می‌شود.

olcSyncrepl: rid=<replica ID> provider=ldap[s]://<hostname>[:port] searchbase=<base DN> [type=refreshOnly|refreshAndPersist] [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of retries>]+] [filter=<filter str>] [scope=sub|one|base|subord] [attrs=<attr list>] [exattrs=<attr list>] [attrsonly] [sizelimit=<limit>] [timelimit=<limit>] [schemachecking=on|off] [network-timeout=<seconds>] [timeout=<seconds>] [tcp-user-timeout=<milliseconds>] [bindmethod=simple|sasl] [binddn=<dn>] [saslmech=<mech>] [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>] [realm=<realm>] [secprops=<properties>] [keepalive=<idle>:<probes>:<interval>] [starttls=yes|critical] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_reqsan=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_ecname=<names>] [tls_crlcheck=none|peer|all] [tls_protocol_min=<major>[.<minor>]] [suffixmassage=<real DN>] [logbase=<base DN>] [logfilter=<filter str>] [syncdata=default|accesslog|changelog] [lazycommit]

پایگاه‌داده فعلی را به‌عنوان مصرف‌کننده‌ای مشخص می‌کند که با برقراری slapd(8) فعلی به‌عنوان یک سایت مصرف‌کننده همگام‌سازی که موتور همگام‌سازی syncrepl را اجرا می‌کند، با محتوای فراهم‌کننده به‌روز نگه داشته می‌شود. محتوای مصرف‌کننده با استفاده از پروتکل همگام‌سازی محتوای LDAP با محتوای فراهم‌کننده همگام نگه داشته می‌شود. برای اطلاعات دقیق در مورد راه‌اندازی یک سرویس دایرکتوری همگام‌سازی‌شده slapd با استفاده از موتور همگام‌سازی syncrepl به "راهنمای مدیر OpenLDAP" مراجعه کنید.

rid دستورالعمل فعلی syncrepl را در سایت مصرف‌کننده همگام‌سازی شناسایی می‌کند. این یک عدد صحیح غیرمنفی حداکثر تا 999 است (محدود به سه رقم ده‌دهی).

provider سایت فراهم‌کننده همگام‌سازی حاوی محتوای فراهم‌کننده را به‌عنوان یک URI در LDAP مشخص می‌کند. اگر <port> داده نشود، از شماره پورت استاندارد LDAP (389 یا 636) استفاده می‌شود.

محتوای مصرف‌کننده syncrepl با استفاده از مشخصات جستجو به‌عنوان مجموعه نتایج آن تعریف می‌شود. دیمن slapd مصرف‌کننده درخواست‌های جستجو را مطابق با مشخصات جستجو به slapd فراهم‌کننده ارسال می‌کند. مشخصات جستجو شامل پارامترهای searchbase، scope، filter، attrs، attrsonly، sizelimit و timelimit مشابه مشخصات جستجوی عادی است. گزینه exattrs همچنین می‌تواند برای تعیین مشخصه‌هایی که باید از مدخل‌های دریافتی حذف شوند استفاده شود. مقدار scope به‌طور پیش‌فرض sub، مقدار filter به‌طور پیش‌فرض (objectclass=*) است و هیچ پیش‌فرضی برای searchbase وجود ندارد. فهرست attrs به‌طور پیش‌فرض "*,+" است تا همه مشخصه‌های کاربر و عملیاتی را بازگرداند، و attrsonly و exattrs به‌طور پیش‌فرض تنظیم نشده‌اند. پارامترهای sizelimit و timelimit فقط "unlimited" و اعداد صحیح مثبت را می‌پذیرند، و هر دو به‌طور پیش‌فرض "unlimited" هستند. پارامترهای sizelimit و timelimit محدودیتی را تعریف می‌کنند که مصرف‌کننده برای تعداد مدخل‌های قابل بازگردانی توسط عملیات همگام‌سازی محتوای LDAP درخواست کرده است؛ این مقادیر باید از مقدار پیش‌فرض بدون تغییر باقی بمانند در غیر این صورت ممکن است همگام‌سازی هرگز موفق نشود. توجه داشته باشید که هرگونه محدودیت سمت فراهم‌کننده برای هویت همگام‌سازی توسط فراهم‌کننده بدون در نظر گرفتن محدودیت‌های درخواستی توسط عملیات همگام‌سازی محتوای LDAP اعمال خواهد شد، درست مانند هر عملیات جستجوی دیگر.

پروتکل همگام‌سازی محتوای LDAP دارای دو نوع عملیات است. در عملیات refreshOnly، عملیات جستجوی همگام‌سازی بعدی به‌طور دوره‌ای در یک بازه زمانی (مشخص‌شده با پارامتر interval؛ به‌طور پیش‌فرض ۱ روز) پس از اتمام هر عملیات همگام‌سازی دوباره زمان‌بندی می‌شود. در عملیات refreshAndPersist، یک جستجوی همگام‌سازی در slapd فراهم‌کننده پایدار می‌ماند. به‌روزرسانی‌های بعدی در فراهم‌کننده، پاسخ‌های جستجوی searchResultEntry را به عنوان پاسخ‌های جستجو به جستجوی همگام‌سازی پایدار به slapd مصرف‌کننده ارسال خواهند کرد. اگر جستجوی اولیه به دلیل خطا شکست بخورد، عملیات جستجوی همگام‌سازی بعدی به‌طور دوره‌ای در یک بازه زمانی (مشخص‌شده با پارامتر interval؛ پیش‌فرض ۱ روز) زمان‌بندی می‌شود.

اگر در حین همگام‌سازی خطایی رخ دهد، مصرف‌کننده طبق پارامتر retry که فهرستی از جفت‌های <retry interval> و <# of retries> است، اقدام به اتصال مجدد می‌کند. به عنوان مثال، retry="60 10 300 3" به مصرف‌کننده اجازه می‌دهد برای ۱۰ بار اول هر ۶۰ ثانیه یک‌بار دوباره تلاش کند و سپس برای ۳ بار بعدی هر ۳۰۰ ثانیه یک‌بار قبل از توقف تلاش مجدد کند. علامت '+' در <# of retries> به معنای تعداد نامحدود تلاش مجدد تا زمان موفقیت است. اگر هیچ retry مشخص نشده باشد، به‌طور پیش‌فرض syncrepl هر ساعت تا ابد تلاش مجدد می‌کند.

بررسی اسکِما را می‌توان در سایت مصرف‌کننده همگام‌سازی LDAP با روشن کردن پارامتر schemachecking الزامی کرد. پیش‌فرض off است. بررسی اسکِمای on به این معنی است که مدخل‌های همگام‌سازی‌شده باید دارای یک objectClass ساختاری باشند، باید از الزامات objectClass از نظر مشخصه‌های لازم/مجاز پیروی کنند، و مشخصه‌های نام‌گذاری و مقادیر متمایز باید وجود داشته باشند. در نتیجه، هنگامی که از همگام‌سازی جزئی (partial) استفاده می‌شود، بررسی اسکِما باید روی off باشد.

پارامتر network-timeout تعیین می‌کند که مصرف‌کننده چه مدت برای برقراری اتصال شبکه با فراهم‌کننده منتظر بماند. پس از برقراری اتصال، پارامتر timeout تعیین می‌کند که مصرف‌کننده چه مدت برای تکمیل درخواست Bind اولیه منتظر بماند. مقادیر پیش‌فرض برای این پارامترها از ldap.conf(5) می‌آیند. پارامتر tcp-user-timeout، در صورت غیرصفر بودن، با TCP_USER_TIMEOUT تنظیم‌شده روی اتصالات هدف مطابقت دارد و تنظیمات سیستم‌عامل را بازنویسی می‌کند. تنها برخی از سیستم‌ها از سفارشی‌سازی این پارامتر پشتیبانی می‌کنند، در غیر این صورت نادیده گرفته می‌شود و از تنظیمات سراسری سیستم استفاده خواهد شد.

یک bindmethod از نوع simple نیازمند گزینه‌های binddn و credentials است و تنها زمانی باید استفاده شود که سرویس‌های امنیتی مناسب (مانند TLS یا IPSEC) برقرار باشند. به یاد داشته باشید: اعتبارنامه‌های simple bind باید به صورت متن واضح (cleartext) باشند! یک bindmethod از نوع sasl نیازمند گزینه saslmech است. بسته به مکانیزم، هویت و/یا اعتبارنامه احراز هویت را می‌توان با استفاده از authcid و credentials مشخص کرد. پارامتر authzid ممکن است برای تعیین یک هویت اعطای مجوز استفاده شود. خصوصیات امنیتی خاص (همانند کلیدواژه sasl-secprops در بالا) برای یک bind مربوط به SASL را می‌توان با گزینه secprops تنظیم کرد. یک قلمرو غیرپیش‌فرض SASL را می‌توان با گزینه realm تنظیم نمود. هویت مورد استفاده برای همگام‌سازی توسط مصرف‌کننده باید مجاز به دریافت تعداد نامحدودی از مدخل‌ها در پاسخ به درخواست جستجو باشد. فراهم‌کننده، علاوه بر اجازه دادن به احراز هویت هویت syncrepl، باید امتیازات دسترسی مناسب به داده‌های در حال همگام‌سازی (دستور access) و محدودیت‌های زمانی و اندازه مناسب را به آن هویت اعطا کند. این کار را می‌توان یا با اجازه دادن به sizelimit و timelimit نامحدود، یا با تنظیم یک عبارت limits مناسب در پیکربندی مصرف‌کننده انجام داد (برای جزئیات به sizelimit و limits مراجعه کنید).

پارامتر keepalive مقادیر idle، probes و interval مورد استفاده برای بررسی زنده بودن سوکت را تنظیم می‌کند؛ idle تعداد ثانیه‌هایی است که یک اتصال باید بیکار بماند قبل از اینکه TCP شروع به ارسال پروب‌های keepalive کند؛ probes حداکثر تعداد پروب‌های keepalive است که TCP باید قبل از قطع اتصال ارسال کند؛ interval فاصله زمانی بر حسب ثانیه بین پروب‌های keepalive منفرد است. تنها برخی از سیستم‌ها از سفارشی‌سازی این مقادیر پشتیبانی می‌کنند؛ در غیر این صورت پارامتر keepalive نادیده گرفته می‌شود و از تنظیمات سراسری سیستم استفاده می‌گردد.

پارامتر starttls استفاده از عملیات توسعه‌یافته StartTLS را برای برقراری یک نشست TLS قبل از Binding به فراهم‌کننده مشخص می‌کند. اگر آرگومان critical ارائه شود، در صورت شکست درخواست StartTLS، نشست لغو خواهد شد. در غیر این صورت نشست syncrepl بدون TLS ادامه می‌یابد. تنظیم tls_reqcert به‌طور پیش‌فرض "demand"، تنظیم tls_reqsan به‌طور پیش‌فرض "allow" است و سایر تنظیمات TLS به‌طور پیش‌فرض مشابه تنظیمات اصلی TLS در slapd هستند.

پارامتر suffixmassage به مصرف‌کننده اجازه می‌دهد مدخل‌ها را از یک دایرکتوری راه دور که پسوند DN آن با دایرکتوری محلی متفاوت است واکشی کند. بخشی از DN مدخل‌های راه دور که با searchbase مطابقت دارد با DN مربوط به suffixmassage جایگزین خواهد شد.

به جای همگام‌سازی کل مدخل‌ها، مصرف‌کننده می‌تواند گزارش‌های تغییر داده‌ها را پرس‌وجو کند. این حالت عملیاتی به عنوان delta syncrepl نامیده می‌شود. علاوه بر پارامترهای فوق، پارامترهای logbase و logfilter باید به درستی برای گزارشی که استفاده خواهد شد تنظیم شوند. پارامتر syncdata باید روی "accesslog" تنظیم شود اگر لاگ با فرمت لاگ slapo-accesslog(5) مطابقت دارد، یا "changelog" اگر لاگ با فرمت منسوخ‌شده changelog مطابقت دارد. اگر پارامتر syncdata حذف شود یا روی "default" تنظیم شود، پارامترهای لاگ نادیده گرفته می‌شوند.

پارامتر lazycommit به پایگاه‌داده زیرین می‌گوید که می‌تواند تغییرات را بدون انجام تخلیه کامل (flush) پس از هر تغییر ذخیره کند. این ممکن است عملکرد مصرف‌کننده را بهبود بخشد، در حالی که ایمنی یا پایایی را فدا می‌کند.

olcUpdateDN: <dn>: این گزینه فقط در یک پایگاه‌داده رونوشت (replica) قابل اعمال است. این گزینه DN مجاز به به‌روزرسانی (مشروط به کنترل‌های دسترسی) رونوشت را مشخص می‌کند. این گزینه تنها در سناریوهای همگام‌سازی با حالت push مورد نیاز است. به‌طور کلی، این DN نباید همان rootdn مورد استفاده در فراهم‌کننده باشد.
olcUpdateRef: <url>: ارجاعی را برای بازگرداندن هنگامی که از slapd(8) خواسته می‌شود تا یک پایگاه‌داده محلی رونوشت‌شده را تغییر دهد مشخص می‌کند. اگر چندین مقدار مشخص شود، هر url ارائه می‌شود.

گزینه‌های خاص پایگاه‌داده (DATABASE-SPECIFIC OPTIONS)

هر پایگاه‌داده ممکن است گزینه‌های پیکربندی خاصی را مجاز بداند؛ آن‌ها به‌طور جداگانه در صفحات راهنمای بک‌آندها مستند شده‌اند. برای مروری بر بک‌آندهای موجود به صفحه راهنمای slapd.backends(5) مراجعه کنید.

اورلی‌ها (OVERLAYS)

یک اورلی (overlay) قطعه کدی است که عملیات پایگاه‌داده را برای گسترش یا تغییر آن‌ها رهگیری می‌کند. اورلی‌ها روی یک پشته بر فراز پایگاه‌داده قرار می‌گیرند، بنابراین به ترتیب معکوس ترتیبی که پیکربندی شده‌اند اجرا می‌شوند و خود پایگاه‌داده در آخرین مرحله کنترل را دریافت خواهد کرد.

اورلی‌ها باید به‌عنوان مدخل‌های فرزند یک پایگاه‌داده خاص پیکربندی شوند. مقدار RDN مدخل باید به شکل olcOverlay={x}<overlaytype> باشد و مدخل باید دارای کلاس شیء olcOverlayConfig باشد. معمولاً موتور پیکربندی اندیس "{x}" را در RDN به‌طور خودکار تولید می‌کند، بنابراین هنگام بارگذاری اولیه این مدخل‌ها می‌توان آن را حذف کرد.

برای مروری بر اورلی‌های موجود به صفحه راهنمای slapd.overlays(5) مراجعه کنید.

مثال‌ها (EXAMPLES)

در اینجا یک مثال کوتاه از پیکربندی در فرمت LDIF مناسب برای استفاده با slapadd(8) آمده است:

dn: cn=config
objectClass: olcGlobal
cn: config
olcPidFile: /var/run/slapd.pid
olcAttributeOptions: x-hidden lang-
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
include: file:///etc/ldap/schema/core.ldif
dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
# Subtypes of "name" (e.g. "cn" and "ou") with the
# option ";x-hidden" can be searched for/compared,
# but are not shown.  See slapd.access(5).
olcAccess: to attrs=name;x-hidden by * =cs
# Protect passwords.  See slapd.access(5).
olcAccess: to attrs=userPassword  by * auth
# Read access to other attributes and entries.
olcAccess: to * by * read
# set a rootpw for the config database so we can bind.
# deny access to everyone else.
dn: olcDatabase=config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
olcAccess: to * by * none
dn: olcDatabase=mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcSuffix: "dc=our-domain,dc=com"
# The database directory MUST exist prior to
# running slapd AND should only be accessible
# by the slapd/tools. Mode 0700 recommended.
olcDbDirectory: /var/lib/ldap
# Indices to maintain
olcDbIndex:     objectClass  eq
olcDbIndex:     cn,sn,mail   pres,eq,approx,sub
# We serve small clients that do not handle referrals,
# so handle remote lookups on their behalf.
dn: olcDatabase=ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLdapConfig
olcDatabase: ldap
olcSuffix: ""
olcDbUri: ldap://ldap.some-server.com/

با فرض اینکه داده‌های بالا در فایلی به نام "config.ldif" ذخیره شده و پوشه /etc/ldap/slapd.d ایجاد شده باشد، این دستور پیکربندی را مقداردهی اولیه می‌کند:

slapadd -F /etc/ldap/slapd.d -n 0 -l config.ldif

سند "OpenLDAP Administrator's Guide" حاوی مثال طولانی‌تر همراه با توضیحات از پیکربندی slapd است.

از طرف دیگر، یک فایل slapd.conf موجود را می‌توان با استفاده از slapd یا هر یک از ابزارهای slap به فرمت جدید تبدیل کرد:

slaptest -f /etc/ldap/slapd.conf -F /etc/ldap/slapd.d

فایل‌ها (FILES)

/etc/ldap/slapd.conf: فایل پیکربندی پیش‌فرض slapd
/etc/ldap/slapd.d: پوشه پیکربندی پیش‌فرض slapd

همچنین ببینید (SEE ALSO)

ldap(3)، ldif(5)، gnutls-cli(1)، slapd.access(5)، slapd.backends(5)， slapd.conf(5)، slapd.overlays(5)، slapd.plugin(5)， slapd(8)، slapacl(8)، slapadd(8)، slapauth(8)، slapcat(8)، slapdn(8)، slapindex(8)، slapmodify(8)، slappasswd(8)، slaptest(8).

"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin)

قدردانی‌ها (ACKNOWLEDGEMENTS)

نرم‌افزار OpenLDAP توسط پروژه OpenLDAP در http://www.openldap.org توسعه یافته و نگهداری می‌شود. نرم‌افزار OpenLDAP از انتشار LDAP 3.3 دانشگاه میشیگان برگرفته شده است.