نام (NAME)

slapd.conf - فایل پیکربندی برای slapd، دیمن مستقل LDAP

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

/etc/openldap/slapd.conf

توضیحات (DESCRIPTION)

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

فایل slapd.conf شامل مجموعه‌ای از گزینه‌های پیکربندی سراسری است که برای slapd به‌طور کلی (از جمله تمام بک‌اندها) اعمال می‌شوند، و به دنبال آن صفر یا چند تعریف بک‌اند پایگاه‌داده که حاوی اطلاعات خاص یک نمونه بک‌اند هستند می‌آید. گزینه‌های پیکربندی به حروف بزرگ و کوچک حساس نیستند (case-insensitive)؛ اما مقدار آن‌ها، مورد به مورد، ممکن است به حروف بزرگ و کوچک حساس باشد.

قالب کلی slapd.conf به شرح زیر است:

# comment - these options apply to every database
<global configuration options>
# first database definition & configuration options
database <backend 1 type>
<configuration options specific to backend 1>
# subsequent database definitions & configuration options
...

می‌توان هر تعداد بخش خاص بک‌اند را که لازم است قرار داد. گزینه‌های سراسری را می‌توان در یک بک‌اند لغو کرد (برای گزینه‌هایی که بیش از یک بار ظاهر می‌شوند، آخرین باری که در فایل slapd.conf آمده‌اند استفاده می‌شود).

اگر خطی با نویسه فاصله آغاز شود، به عنوان ادامه خط قبلی در نظر گرفته می‌شود. هیچ خط فیزیکی نباید بیش از ۲۰۰۰ بایت طول داشته باشد.

خطوط خالی و خطوط توضیحات که با نویسه `#' آغاز می‌شوند نادیده گرفته می‌شوند. توجه: خطوط ادامه قبل از پردازش توضیحات باز می‌شوند (unwrap می‌شوند).

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

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

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

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

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

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

allow <features>

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

argsfile <filename>

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

attributeoptions [option-name]...

گزینه‌های مشخصه برچسب‌گذاری یا پیشوندهای برچسب/محدوده گزینه را تعریف می‌کند. گزینه‌ها نباید به `-' ختم شوند؛ پیشوندها باید به `-' ختم شوند. پیشوند `lang-' از پیش تعریف شده است. اگر از دستورالعمل attributeoptions استفاده کنید، `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' را به‌طور توکار دارد، اما این یک گزینه انتقال است، نه گزینه برچسب‌گذاری.

attributetype ( <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 را گسترش می‌دهد. (به توضیحات objectidentifier مراجعه کنید.)

authid-rewrite<cmd> <args>: توسط چارچوب احراز هویت برای تبدیل نام‌های کاربری ساده به یک DN در LDAP برای اهداف مجوزدهی استفاده می‌شود. هدف آن مشابه هدف authz-regexp (در زیر ببینید) است. پیشوند authid- با مجموعه‌ای از قوانین مشابه موارد شرح‌داده‌شده در slapo-rwm(5) برای بازنویسی داده‌ها دنبال می‌شود (پیشوند rwm- را با authid- جایگزین کنید). قوانین authid-rewrite<cmd> و authz-regexp نباید با یکدیگر ترکیب شوند.
authz-policy <policy>: برای تعیین قوانینی که باید برای احراز هویت وکالتی (Proxy Authorization) استفاده شوند به‌کار می‌رود. احراز هویت وکالتی به کلاینت اجازه می‌دهد تا با استفاده از اطلاعات اعتبارسنجی یک کاربر با سرور احراز هویت کند، اما هویت متفاوتی را برای اهداف اعطای مجوز و کنترل دسترسی تعیین نماید. این سازوکار اساساً به کاربر A امکان می‌دهد تا با گذرواژه کاربر A به عنوان کاربر B وارد سیستم شود. فلگ 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 است. اصلاح‌کننده‌های اختیاری dnstyle شامل exact، onelevel، children و subtree تطابق‌های دقیق، یک‌سطحی، فرزندان و زیردرخت را ارائه می‌دهند که باعث می‌شوند <pattern> بر اساس قوانین عادی‌سازی DN نرمال شود. اصلاح‌کننده ویژه dnstyle به نام 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 می‌تواند بر امنیت تأثیر بگذارد، به کاربران اکیداً توصیه می‌شود که صریحاً نوع تعیین هویت مورد استفاده را مشخص کنند. زیرمجموعه‌ای از این قوانین می‌تواند به‌عنوان آرگومان سوم در دستورالعمل authz-regexp (در زیر ببینید) استفاده شود؛ به‌ویژه شکل‌های URI، به شرطی که دقیقاً به یک مدخل ختم شود، و شکل‌های dn.exact:<dn>.

authz-regexp <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" را در موضوع داشته باشد.

چندین گزینه authz-regexp می‌تواند در فایل پیکربندی برای امکان تطابق و جایگزینی چندگانه ارائه شود. الگوهای تطابق به ترتیبی که در فایل ظاهر می‌شوند بررسی می‌شوند و با رسیدن به اولین تطابق موفق متوقف می‌گردند.

concurrency <integer>: سطح همروندی مورد نظر را مشخص می‌کند. به‌عنوان یک راهنمایی (hint) به سیستم نخ‌های زیرین ارائه می‌شود. پیش‌فرض این است که هیچ راهنمایی ارائه نشود. این تنظیم تنها در برخی پلتفرم‌ها که در آن‌ها تناظر یک‌به‌یک بین نخ‌های کاربر و نخ‌های هسته وجود ندارد معنادار است.
conn_max_pending <integer>: حداکثر تعداد درخواست‌های معلق برای یک نشست ناشناس را مشخص می‌کند. اگر درخواست‌ها سریع‌تر از توانایی پردازش سرور ارسال شوند، تا این سقف در صف قرار می‌گیرند. اگر از این حد فراتر رود، نشست بسته می‌شود. پیش‌فرض 100 است.
conn_max_pending_auth <integer>: حداکثر تعداد درخواست‌های معلق برای یک نشست احرازهویت‌شده را مشخص می‌کند. پیش‌فرض 1000 است.
defaultsearchbase <dn>: یک پایه جستجوی پیش‌فرض را برای زمانی مشخص می‌کند که کلاینت درخواست جستجوی غیرپایه‌ای (non-base) را با یک DN پایه خالی ارسال می‌کند. درخواست‌های جستجو در دامنه پایه با DN پایه خالی تحت تأثیر قرار نمی‌گیرند.
disallow <features>: مجموعه‌ای از قابلیت‌ها را (که با فاصله از هم جدا شده‌اند) برای غیرمجاز کردن مشخص می‌کند (پیش‌فرض هیچ‌کدام است). bind_anon پذیرش درخواست‌های بایند ناشناس را غیرفعال می‌کند. توجه داشته باشید که این تنظیم مانع از دسترسی ناشناس به دایرکتوری نمی‌شود (به "require authc" مراجعه کنید). bind_simple احراز هویت ساده (بایند) را غیرفعال می‌کند. tls_2_anon اجبار نشست به وضعیت ناشناس در هنگام دریافت عملیات StartTLS را غیرفعال می‌کند (همچنین به tls_authc مراجعه کنید). tls_authc در صورت احراز هویت بودن، عملیات StartTLS را غیرمجاز می‌کند (همچنین به tls_2_anon مراجعه کنید). proxy_authz_non_critical پذیرش کنترل احراز هویت وکالتی (RFC4370) با وضعیت بحرانی (criticality) تنظیم‌شده روی FALSE را غیرفعال می‌کند. dontusecopy_non_critical پذیرش کنترل dontUseCopy (یک کار در حال توسعه) با وضعیت بحرانی تنظیم‌شده روی FALSE را غیرفعال می‌کند.

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

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

gentlehup { on | off }: سیگنال SIGHUP تنها باعث تلاش برای خاموش شدن «ملایم» می‌شود: Slapd گوش دادن به اتصالات جدید را متوقف می‌کند، اما اتصالات کلاینت‌های فعلی را نمی‌بندد. با این حال، عملیات نوشتن بعدی خطای unwilling-to-perform را برمی‌گردانند. Slapd زمانی خاتمه می‌یابد که همه کلاینت‌ها اتصالات خود را ببندند (اگر اصلاً ببندند)، یا - مانند قبل - اگر سیگنال SIGTERM دریافت کند. این می‌تواند زمانی مفید باشد که بخواهید سرور را خاتمه دهید و سرور slapd جدیدی را با پایگاه‌داده دیگری، بدون ایجاد اختلال برای کلاینت‌های فعال فعلی راه‌اندازی کنید. پیش‌فرض off است. ممکن است مایل باشید از idletimeout همراه با این گزینه استفاده کنید.
idletimeout <integer>: تعداد ثانیه‌های انتظار قبل از بستن اجباری یک اتصال کلاینت غیرفعال (idle) را مشخص می‌کند. تنظیم 0 این قابلیت را غیرفعال می‌کند. پیش‌فرض 0 است. ممکن است بخواهید گزینه writetimeout را نیز تنظیم کنید.
include <filename>: اطلاعات پیکربندی اضافی را قبل از ادامه با خط بعدی فایل فعلی، از فایل داده‌شده می‌خواند.
index_hash64 { on | off }: استفاده از هش ۶۴ بیتی برای نمایه‌سازی. پیش‌فرض استفاده از هش‌های ۳۲ بیتی است. این هش‌ها برای نمایه‌سازی برابری و زیررشته استفاده می‌شوند. نسخه ۶۴ بیتی ممکن است برای جلوگیری از برخورد نمایه زمانی که تعداد مقادیر نمایه‌شده از حدود ۶۴ میلیون فراتر می‌رود مورد نیاز باشد. (توجه داشته باشید که نمایه‌سازی زیررشته به ازای هر مقدار مشخصه واقعی، چندین مقدار نمایه تولید می‌کند.) نمایه‌های تولیدشده با هش‌های ۳۲ بیتی با نسخه ۶۴ بیتی ناسازگار هستند و برعکس. هنگام تغییر این تنظیم، هر پایگاه‌داده موجود باید به‌طور کامل دوباره بارگذاری شود. این دستورالعمل تنها بر روی پردازنده‌های ۶۴ بیتی پشتیبانی می‌شود.
index_intlen <integer>: طول کلید را برای نمایه‌های اعداد صحیح مرتب‌شده مشخص می‌کند. پرارزش‌ترین بایت‌های عدد صحیح باینری برای کلیدهای نمایه استفاده می‌شوند. مقدار پیش‌فرض 4 است که نمایه‌سازی دقیق را برای مقادیر ۳۱ بیتی فراهم می‌کند. برای نمایه‌سازی مقادیر بسیار بزرگ از یک نمایش ممیز شناور استفاده می‌شود.
index_substr_if_maxlen <integer>: حداکثر طول را برای نمایه‌های زیرآغازین و زیرپایانی (subinitial و subfinal) مشخص می‌کند. تنها این تعداد نویسه از یک مقدار مشخصه توسط توابع نمایه‌سازی پردازش می‌شوند؛ نویسه‌های اضافی نادیده گرفته می‌شوند. پیش‌فرض 4 است.
index_substr_if_minlen <integer>: حداقل طول را برای نمایه‌های زیرآغازین و زیرپایانی مشخص می‌کند. یک مقدار مشخصه باید حداقل این تعداد نویسه داشته باشد تا توسط توابع نمایه‌سازی پردازش شود. پیش‌فرض 2 است.
index_substr_any_len <integer>: طول استفاده‌شده برای نمایه‌های subany را مشخص می‌کند. یک مقدار مشخصه برای پردازش باید حداقل این تعداد نویسه داشته باشد. مقادیر مشخصه طولانی‌تر از این طول در بخش‌هایی به این طول پردازش می‌شوند. پیش‌فرض 4 است. نمایه subany همچنین در جستجوهای نمایه subinitial و subfinal زمانی که رشته فیلتر طولانی‌تر از مقدار index_substr_if_maxlen باشد استفاده خواهد شد.
index_substr_any_step <integer>: گام‌های استفاده‌شده در جستجوهای نمایه subany را مشخص می‌کند. این مقدار آفست را برای بخش‌هایی از رشته فیلتر که برای جستجوی نمایه subany پردازش می‌شوند تنظیم می‌کند. پیش‌فرض 2 است. به عنوان مثال، با مقادیر پیش‌فرض، جستجویی با استفاده از فیلتر "cn=*abcdefgh*" جستجوهای نمایه‌ای را برای "abcd"، "cdef" و "efgh" تولید می‌کند.

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

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

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

listener-threads <integer>: تعداد نخ‌هایی (threads) را که باید برای مدیر اتصال استفاده شود مشخص می‌کند. مقدار پیش‌فرض ۱ است و این مقدار معمولاً برای حداکثر ۱۶ هسته پردازنده مناسب و کافی است. این مقدار باید توانی از ۲ تنظیم شود.
localSSF <SSF>: فاکتور استحکام امنیتی (SSF) را برای نشست‌های محلی LDAP، مانند نشست‌های مربوط به شنونده ldapi://، مشخص می‌کند. برای شرح مقادیر SSF، توضیحات گزینه minssf در sasl-secprops را ببینید. مقدار پیش‌فرض ۷۱ است.
logfile <filename>: فایلی را برای ثبت پیام‌های اشکال‌زدایی slapd مشخص می‌کند. این پیام‌ها ارتباطی با پیام‌های مشخص‌شده توسط پارامتر پیکربندی loglevel ندارند. این تنظیم تنها دیمن slapd را تحت تأثیر قرار می‌دهد و هیچ اثری بر ابزارهای خط فرمان ندارد. به‌طور پیش‌فرض، این پیام‌ها تنها به stderr ارسال می‌شوند و در هیچ جای دیگری ثبت نمی‌شوند. مشخص کردن یک logfile پیام‌ها را هم به stderr و هم به فایل لاگ ارسال می‌کند.
logfile-format debug|syslog-utc|syslog-localtime|rfc3339-utc: قالب پیشوند پیام‌های نوشته‌شده در فایل لاگ را مشخص می‌کند. قالب debug همان قالب عادی مورد استفاده برای پیام‌های اشکال‌زدایی slapd است، با یک برچسب زمانی در مبنای شانزده، که پس از آن یک شناسه نخ (thread ID) می‌آید. گزینه‌های دیگر شامل استفاده از پیشوندهای سبک syslog(3) با برچسب‌های زمانی بر حسب UTC یا منطقه زمانی محلی هستند. مقدار پیش‌فرض قالب debug است.
logfile-only on | off: مشخص می‌کند که پیام‌های اشکال‌زدایی تنها به فایل لاگ پیکربندی‌شده ارسال شوند و به stderr نروند.
logfile-rotate <max> <Mbytes> <hours>: چرخش خودکار (rotation) را برای فایل لاگ پیکربندی‌شده مشخص می‌کند؛ به‌صورت حداکثر تعداد فایل‌های لاگ قدیمی برای نگهداری، حداکثر اندازه بر حسب مگابایت برای رشد فایل لاگ پیش از چرخش، و حداکثر عمر بر حسب ساعت برای استفاده از یک فایل لاگ پیش از چرخش. حداکثر تعداد باید در محدوده ۱ تا ۹۹ باشد. تنظیم Mbytes یا hours روی صفر، به ترتیب بررسی اندازه یا سن فایل را غیرفعال می‌کند. حداقل یکی از مقادیر Mbytes یا hours باید غیرصفر باشد. به‌طور پیش‌فرض هیچ چرخش خودکاری انجام نمی‌شود.
loglevel <integer> [...]: سطحی را مشخص می‌کند که در آن دستورهای اشکال‌زدایی و آمار عملیات باید از طریق syslog ثبت شوند (در حال حاضر در تسهیلات LOG_LOCAL4 مربوط به syslogd(8) ثبت می‌شود). این‌ها را باید بیشتر به عنوان زیرسیستم‌ها در نظر گرفت تا سطوح لاگ‌گیری که به تدریج پرحرف‌تر می‌شوند. برخی از پیام‌های با اولویت بالاتر، به محض اینکه هر گونه ثبت لاگی پیکربندی شود، بدون در نظر گرفتن loglevel پیکربندی‌شده ثبت می‌شوند. سطوح لاگ جمع‌پذیر (additive) هستند، و سطوح موجود عبارتند از:

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

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

loglevel 129
loglevel 0x81
loglevel 128 1
loglevel 0x80 0x1
loglevel acl trace

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

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

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

maxfilterdepth <integer>: حداکثر عمق فیلترهای تودرتو را در درخواست‌های جستجو مشخص می‌کند. مقدار پیش‌فرض ۱۰۰۰ است.
moduleload <filename> [<arguments>...]: نام یک ماژول قابل بارگذاری پویا را برای بارگذاری و هرگونه آرگومان اضافی در صورت پشتیبانی توسط ماژول مشخص می‌کند. نام فایل می‌تواند یک مسیر مطلق یا یک نام فایل ساده باشد. نام‌های غیرمطلق در دایرکتوری‌های مشخص‌شده توسط گزینه modulepath جستجو می‌شوند. این گزینه و گزینه modulepath تنها در صورتی قابل استفاده هستند که slapd با --enable-modules کامپایل شده باشد.
modulepath <pathspec>: فهرستی از دایرکتوری‌ها را برای جستجوی ماژول‌های قابل بارگذاری مشخص می‌کند. معمولاً مسیرها با دو نقطه (colon) از هم جدا می‌شوند، اما این به سیستم‌عامل بستگی دارد. مقدار پیش‌فرض /usr/lib/openldap است، که محل قرارگیری ماژول‌ها در نصب استاندارد OpenLDAP می‌باشد.

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

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

objectidentifier <name> { <oid> | <name>[:<suffix>] }

یک نام رشته‌ای تعریف می‌کند که معادل OID داده‌شده است. این رشته را می‌توان به جای OID عددی در تعاریف objectclass و ویژگی‌ها به کار برد. نام را می‌توان همچنین با یک پسوند به فرم ":xx" استفاده کرد که در این حالت مقدار "oid.xx" استفاده خواهد شد.

password-hash <hash> [<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) استفاده می‌کنند، که دومی همراه با یک seed است.

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

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

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

password-crypt-salt-format <format>

قالب سالت (salt) ارسال‌شده به crypt(3) را هنگام تولید گذرواژه‌های {CRYPT} (ببینید password-hash) در حین پردازش عملیات‌های گسترش‌یافته تغییر گذرواژه LDAP (مطابق RFC 3062) مشخص می‌کند.

این رشته باید در قالب sprintf(3) باشد و ممکن است شامل یک (و تنها یک) تبدیل %s باشد. این تبدیل با رشته‌ای از نویسه‌های تصادفی از [A-Za-z0-9./] جایگزین خواهد شد. به عنوان مثال، "%.2s" یک سالت دو نویسه‌ای ارائه می‌دهد و "$1$%.8s" به برخی از نسخه‌های crypt(3) اعلام می‌کند که از الگوریتم MD5 استفاده کنند و یک سالت با ۸ نویسه تصادفی فراهم می‌کند. مقدار پیش‌فرض "%s" است که یک سالت ۳۱ نویسه‌ای ارائه می‌دهد.

pidfile <filename>

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

pluginlog: <filename>

نام (مطلق) فایلی که شامل پیام‌های لاگ مربوط به افزونه‌های SLAPI خواهد بود. برای جزئیات slapd.plugin(5) را ببینید.

referral <url>

ارجاع (referral) برگشتی را در زمانی که slapd(8) نمی‌تواند یک پایگاه‌داده محلی برای پردازش درخواست پیدا کند، مشخص می‌کند. اگر چندین بار مشخص شود، هر نشانی اینترنتی (url) ارائه می‌شود.

require <conditions>

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

reverse-lookup on | off

فعال/غیرفعال کردن جستجوی معکوس تأییدنشده نام سرویس‌گیرنده (در صورت کامپایل با --enable-rlookups، پیش‌فرض off است).

rootDSE <file>

نام یک فایل LDIF(5) شامل ویژگی‌های تعریف‌شده توسط کاربر برای root DSE را مشخص می‌کند. این ویژگی‌ها علاوه بر ویژگی‌هایی که به‌طور معمول توسط slapd تولید می‌شوند، بازگردانده می‌شوند.

شناسه root DSE مدخلی است حاوی اطلاعاتی درباره سرور و قابلیت‌های آن، در ویژگی‌های عملیاتی. این مدخل دارای DN خالی است و می‌توان آن را به‌طور مثال با دستور زیر خواند: ldapsearch -x -b "" -s base "+"
برای جزئیات به بخش 5.1 از RFC 4512 مراجعه کنید.

sasl-auxprops <plugin> [...]

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

sasl-auxprops-dontusecopy <attr> [...]

مشخص می‌کند کدام ویژگی(ها) باید مشمول کنترل «don't use copy» باشند. این امر برای کارکرد برخی مکانیزم‌های SASL مانند OTP در یک محیط تکثیرشده (replicated) ضروری است. ویژگی "cmusaslsecretOTP" مقدار پیش‌فرض است.

sasl-auxprops-dontusecopy-ignore on | off

برای غیرفعال کردن تکثیر ویژگی(های) تعریف‌شده توسط sasl-auxprops-dontusecopy و استفاده از یک مقدار محلی برای آن ویژگی استفاده می‌شود. این به مکانیزم SASL اجازه می‌دهد در صورت آفلاین بودن تأمین‌کننده (provider) به کار خود ادامه دهد. این امر می‌تواند باعث ناسازگاری در تکثیر شود. مقدار پیش‌فرض off است.

sasl-host <fqdn>

برای مشخص کردن نام دامنه کاملاً واجد شرایط (FQDN) مورد استفاده برای پردازش SASL به کار می‌رود.

sasl-realm <realm>

قلمرو (realm) مربوط به SASL را مشخص می‌کند. پیش‌فرض خالی است.

sasl-cbinding none | tls-unique | tls-endpoint

نوع پیوند کانال (channel-binding) را مشخص می‌کند؛ همچنین LDAP_OPT_X_SASL_CBINDING را ببینید. پیش‌فرض none است.

sasl-secprops <properties>

برای تعیین ویژگی‌های امنیتی Cyrus SASL استفاده می‌شود. پرچم none (بدون هیچ ویژگی دیگر) باعث پاک شدن پیش‌فرض ویژگی‌های پرچم، یعنی "noanonymous,noplain" می‌شود. پرچم noplain مکانیزم‌های آسیب‌پذیر در برابر حملات غیرفعال ساده را غیرفعال می‌کند. پرچم noactive مکانیزم‌های آسیب‌پذیر در برابر حملات فعال را غیرفعال می‌کند. پرچم nodict مکانیزم‌های آسیب‌پذیر در برابر حملات واژه‌نامه‌ای غیرفعال را غیرفعال می‌کند. پرچم noanonymous مکانیزم‌هایی را که از ورود ناشناس پشتیبانی می‌کنند غیرفعال می‌کند. پرچم forwardsec رازداری پیشرو (forward secrecy) را بین نشست‌ها الزامی می‌کند. پرچم passcred مکانیزم‌هایی را الزامی می‌کند که اطلاعات اعتباری کلاینت را ارسال می‌کنند (و به مکانیزم‌هایی که می‌توانند اطلاعات اعتباری را ارسال کنند اجازه انجام این کار را می‌دهد). ویژگی minssf=<factor> حداقل فاکتور استحکام امنیتی قابل قبول را به عنوان یک عدد صحیح تقریبی به طول کلید مؤثر مورد استفاده برای رمزنگاری مشخص می‌کند. ۰ (صفر) به معنی عدم حفاظت است، ۱ فقط حفاظت از یکپارچگی را می‌رساند، ۱۲۸ به RC4، Blowfish و سایر رمزهای مشابه اجازه فعالیت می‌دهد، ۲۵۶ به رمزهای مدرن نیاز خواهد داشت. مقدار پیش‌فرض ۰ است. ویژگی maxssf=<factor> حداکثر فاکتور استحکام امنیتی قابل قبول را به عنوان یک عدد صحیح مشخص می‌کند (توضیحات minssf را ببینید). پیش‌فرض INT_MAX است. ویژگی maxbufsize=<size> حداکثر اندازه مجاز بافر دریافت لایه امنیتی را مشخص می‌کند. مقدار ۰ لایه‌های امنیتی را غیرفعال می‌کند. مقدار پیش‌فرض ۶۵۵۳۶ است.

schemadn <dn>

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

security <factors>

مجموعه‌ای از فاکتورهای استحکام امنیتی (جداشده با فاصله) را برای الزام مشخص می‌کند (برای شرح فاکتورهای استحکام امنیتی، گزینه minssf در sasl-secprops را ببینید). این دستورالعمل می‌تواند به‌صورت سراسری و/یا به ازای هر پایگاه‌داده مشخص شود. ssf=<n> فاکتور کلی استحکام امنیتی را مشخص می‌کند. transport=<n> فاکتور استحکام امنیتی انتقال (transport) را مشخص می‌کند. 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). این گزینه معمولاً استفاده نمی‌شود.

serverID <integer> [<URL>]

یک شناسه عددی صحیح از ۰ تا ۴۰۹۵ را برای این سرور مشخص می‌کند. این شناسه می‌تواند با افزودن پیشوند "0x" به مقدار، به صورت شانزده‌شانزدهی (هگزادسیمال) نیز مشخص شود. شناسه‌های غیرصفر هنگام استفاده از تکثیر چندتأمین‌کننده‌ای (multi-provider replication) الزامی هستند و هر تأمین‌کننده باید یک شناسه غیرصفر یکتا داشته باشد. توجه داشته باشید که این الزام برای تأمین‌کننده‌های مجزایی که در یک مجموعه پایگاه‌داده چسبانده‌شده (glued) مشارکت دارند نیز صدق می‌کند. اگر URL ارائه شود، این دستورالعمل را می‌توان چندین بار مشخص کرد که فهرستی کامل از سرورهای مشارکت‌کننده و شناسه‌های آن‌ها را فراهم می‌کند. نام کامل میزبان (FQDN) هر سرور باید در URLهای ارائه‌شده استفاده شود. این شناسه‌ها در فیلد "replica id" تمام CSNهای تولیدشده توسط سرور مشخص‌شده به کار می‌روند. مقدار پیش‌فرض صفر است که تنها برای تکثیر تک‌تأمین‌کننده‌ای معتبر است. مثال:

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

sizelimit {<integer>|unlimited}
sizelimit size[.{soft|hard}]=<integer> [...]: حداکثر تعداد مدخل‌هایی را که از یک عملیات جستجو بازگردانده می‌شوند، مشخص می‌کند. محدودیت اندازه پیش‌فرض ۵۰۰ است. از unlimited برای تعیین عدم وجود محدودیت استفاده کنید. قالب دوم امکان تنظیم دقیق‌تر محدودیت‌های اندازه را فراهم می‌کند. اگر هیچ توصیف‌کننده خاصی مشخص نشود، هر دو محدودیت نرم (soft) و سخت (hard) تنظیم می‌شوند. آرگومان‌های اضافی را می‌توان در همان خط اضافه کرد. توصیف‌کننده‌های دیگری نیز موجود است؛ برای شرح تمام پرچم‌های مختلف، limits را ببینید.
sockbuf_max_incoming <integer>: حداکثر اندازه PDU ورودی LDAP را برای نشست‌های ناشناس مشخص می‌کند. مقدار پیش‌فرض ۲۶۲۱۴۳ است.
sockbuf_max_incoming_auth <integer>: حداکثر اندازه PDU ورودی LDAP را برای نشست‌های احراز هویت‌شده مشخص می‌کند. مقدار پیش‌فرض ۴۱۹۴۳۰۳ است.
sortvals <attr> [...]: فهرستی از ویژگی‌های چندمقداری را مشخص می‌کند که مقادیر آن‌ها همیشه به ترتیب مرتب‌شده نگهداری می‌شوند. استفاده از این گزینه باعث می‌شود ارزیابی‌های Modify، Compare و فیلترها روی این ویژگی‌ها به شکل کارآمدتری انجام شود. ترتیب مرتب‌سازی حاصل به نحو و قواعد تطابق ویژگی‌ها بستگی دارد و ممکن است با ترتیب واژگانی یا هر ترتیب قابل تشخیص دیگری مطابقت نداشته باشد.
tcp-buffer [listener=<URL>] [{read|write}=]<size>: اندازه بافر TCP را مشخص می‌کند. یک مقدار سراسری برای هر دو بافر خواندن و نوشتن TCP مربوط به هر شنونده تعریف می‌شود، مگر اینکه شنونده به‌صراحت مشخص شده باشد یا از توصیف‌کننده‌های read یا write استفاده شود. برای جزئیات tcp(7) را ببینید. توجه داشته باشید که برخی سیستم‌های عامل تنظیم خودکار بافر TCP را پیاده‌سازی کرده‌اند.
threads <integer>: حداکثر اندازه استخر نخ (thread pool) اصلی را مشخص می‌کند. مقدار پیش‌فرض ۱۶ است؛ حداقل مقدار ۲ است.
threadqueues <integer>: تعداد صف‌های کاری را برای استفاده در استخر نخ اصلی مشخص می‌کند. مقدار پیش‌فرض ۱ است و این مقدار معمولاً برای حداکثر ۸ هسته پردازنده کافی است. این مقدار نباید از تعداد CPUهای سیستم تجاوز کند.
timelimit {<integer>|unlimited}
timelimit time[.{soft|hard}]=<integer> [...]: حداکثر تعداد ثانیه‌ها (به وقت واقعی) را مشخص می‌کند که slapd صرف پاسخ دادن به یک درخواست جستجو خواهد کرد. محدودیت زمانی پیش‌فرض ۳۶۰۰ است. از unlimited برای تعیین عدم وجود محدودیت استفاده کنید. قالب دوم امکان تنظیم دقیق‌تر محدودیت‌های زمانی را فراهم می‌کند. آرگومان‌های اضافی را می‌توان در همان خط اضافه کرد. برای شرح پرچم‌های مختلف، limits را ببینید.
tool-threads <integer>: حداکثر تعداد نخ‌ها برای استفاده در حالت ابزار را مشخص می‌کند. این مقدار نباید از تعداد پردازنده‌های سیستم بیشتر باشد. مقدار پیش‌فرض ۱ است.
writetimeout <integer>: تعداد ثانیه‌ها برای انتظار پیش از بستن اجباری یک اتصال با عملیات نوشتن معلق را مشخص می‌کند. این امر امکان بازیابی از شرایط مختلف هنگ کردن شبکه را فراهم می‌کند. مقدار writetimeout برابر ۰ این ویژگی را غیرفعال می‌کند. مقدار پیش‌فرض ۰ است.

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

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

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

OpenSSL:: TLSCipherSuite HIGH:MEDIUM:+SSLv2
GnuTLS:: TLSCiphersuite SECURE256:!AES-128-CBC

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

openssl ciphers -v <cipher-suite-spec>

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

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

gnutls-cli -l

TLSCACertificateFile <filename>

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

TLSCACertificatePath <path>

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

TLSCertificateFile <filename>

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

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

TLSCertificateKeyFile <filename>

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

TLSDHParamFile <filename>

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

TLSECName <name>

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

TLSProtocolMin <major>[.<minor>]

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

TLSProtocolMin 3.2

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

TLSRandFile <filename>

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

TLSVerifyClient <level>

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

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

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

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

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

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

گزینه‌ها در این بخش فقط برای بخش فایل پیکربندی تمام نمونه‌های بک‌اند مشخص‌شده اعمال می‌شوند. همه بک‌اندها ممکن است از این دسته گزینه‌ها پشتیبانی کنند، اما در حال حاضر فقط back-mdb از آن پشتیبانی می‌کند.

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

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

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

database <databasetype>: شروع تعریف یک نمونه جدید از پایگاه‌داده را مشخص می‌کند. <databasetype> بسته به اینکه کدام بک‌اند به پایگاه‌داده سرویس می‌دهد، باید یکی از موارد asyncmeta، config، dnssrv، ldap، ldif، mdb، meta، monitor، null، passwd، perl، relay، sock، sql یا wt باشد.
عملیات‌های LDAP، حتی جستجوهای زیردرخت (subtree)، به‌طور معمول فقط به یک پایگاه‌داده دسترسی دارند. این رفتار را می‌توان با پیوند زدن پایگاه‌های داده به یکدیگر با استفاده از کلیدواژه subordinate تغییر داد. کنترل‌های دسترسی و برخی از اورلی‌ها (overlays) نیز می‌توانند چندین پایگاه‌داده را درگیر کنند.
add_content_acl on | off: کنترل می‌کند که آیا عملیات‌های افزودن (Add) بررسی‌های ACL را روی محتوای مدخلی که در حال افزوده شدن است انجام دهند یا خیر. این بررسی به‌طور پیش‌فرض off است. برای جزئیات بیشتر درباره الزامات ACL برای عملیات‌های Add، صفحه راهنمای slapd.access(5) را ببینید.
extra_attrs <attrlist>: ویژگی‌هایی را فهرست می‌کند که باید به درخواست‌های جستجو افزوده شوند. بک‌اندهای ذخیره‌سازی محلی کل مدخل را به بخش فرانت‌اند بازمی‌گردانند. فرانت‌اند وظیفه دارد فقط ویژگی‌های درخواست‌شده‌ای را که توسط ACLها مجاز هستند، برگرداند. با این حال، قابلیت‌هایی مانند بررسی دسترسی و غیره ممکن است به ویژگی‌های خاصی نیاز داشته باشند که توسط بک‌اندهای ذخیره‌سازی راه‌دور (مانند بک‌اندهای پراکسی و غیره) به‌طور خودکار بازگردانده نمی‌شوند. <attrlist> فهرستی از ویژگی‌ها است که برای اهداف داخلی مورد نیازند و بنابراین همیشه باید جمع‌آوری شوند، حتی زمانی که صراحتاً توسط کلاینت‌ها درخواست نشده باشند.
hidden on | off: کنترل می‌کند که آیا از این پایگاه‌داده برای پاسخ دادن به پرس‌وجوها استفاده شود یا خیر. پایگاه‌داده‌ای که پنهان (hidden) باشد هرگز برای پاسخ به هیچ پرس‌وجویی انتخاب نخواهد شد، و هر پسوند (suffix) پیکربندی‌شده روی این پایگاه‌داده در بررسی‌های تداخل با سایر پایگاه‌های داده نادیده گرفته می‌شود. به‌طور پیش‌فرض، hidden برابر با off است.
lastmod on | off: کنترل می‌کند که آیا slapd ویژگی‌های modifiersName، modifyTimestamp، creatorsName و createTimestamp را به‌طور خودکار برای مدخل‌ها نگه‌داری کند یا خیر. همچنین ویژگی‌های entryCSN و entryUUID را که مورد نیاز فراهم‌کننده syncrepl هستند کنترل می‌کند. به‌طور پیش‌فرض، lastmod برابر با on است.
lastbind on | off: کنترل می‌کند که آیا slapd ویژگی pwdLastSuccess را به‌طور خودکار برای مدخل‌ها نگه‌داری کند یا خیر. به‌طور پیش‌فرض، lastbind برابر با off است. در یک مصرف‌کننده رونوشت (replication consumer)، با فرض اینکه تنظیمات updateref و اورلی chain به‌درستی پیکربندی شده باشند، ویژگی pwdLastSuccess به ارائه‌دهنده (provider) بازفرستاده (forward) خواهد شد.
lastbind-precision <integer>: اگر lastbind فعال باشد، مشخص می‌کند که pwdLastSuccess هر چند وقت یک‌بار باید به‌روزرسانی شود. باید بیش از integer ثانیه از آخرین اتصال (bind) موفق گذشته باشد. در یک محیط تکثیرشده با فعالیت اتصال مکرر، ممکن است مفید باشد که این مقدار روی عددی بزرگ تنظیم شود.
limits <selector> <limit> [<limit> [...]]: محدودیت‌های زمانی و اندازه را بر اساس آغازگر عملیات یا DN پایه (base 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 پیش‌فرض است و به معنای کاربری است که متصل (bound) شده است، در حالی که this به معنای DN پایه عملیات است. عبارت anonymous با تمام کلاینت‌های احرازهویت‌نشده مطابقت دارد. عبارت users با تمام کلاینت‌های احرازهویت‌شده مطابقت دارد؛ در غیر این صورت، یک الگوی dn از نوع exact فرض می‌شود، مگر اینکه با توصیف رشته کلیدی (اختیاری) dn با exact یا base (که مترادف هستند)، برای الزام تطابق دقیق مشخص شده باشد؛ با onelevel، برای الزام تطابق در دقیقاً یک سطح عمق؛ با subtree، برای اجازه تطابق در هر سطحی از عمق، شامل تطابق دقیق؛ با children، برای اجازه تطابق در هر سطحی از عمق، بدون شامل شدن تطابق دقیق؛ regex به‌صراحت تطابق (پیش‌فرض) را بر اساس الگوی عبارت منظم POSIX (از نوع «extended») الزامی می‌کند. در نهایت، anonymous با عملیات‌های متصل‌نشده (unbound) مطابقت دارد؛ فیلد 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 تنظیم شود، در هر دو حالت محدودیت نرم (soft) استفاده خواهد شد؛ اگر روی کلیدواژه unlimited تنظیم شود، هیچ محدودیت سختی (hard) اعمال نمی‌گردد. درخواست‌های صریح برای محدودیت‌های زمانی کوچک‌تر یا مساوی با محدودیت hard پذیرفته و رعایت می‌شوند. اگر هیچ تعیین‌کننده محدودیتی (specifier) مشخص نشده باشد، مقدار به محدودیت 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 تنظیم می‌شود.

در صورت عدم تطابق، از محدودیت‌های سراسری استفاده می‌شود. مقادیر پیش‌فرض مشابه مقادیر sizelimit و timelimit هستند؛ هیچ محدودیتی برای 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 گسترش یافته باشد.

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

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

maxderefdepth <depth>

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

multiprovider on | off

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

monitoring on | off

اگر پایگاه‌داده monitor فعال باشد، این گزینه نظارت ویژهٔ پایگاه‌داده را در مدخل مربوط به پایگاه‌داده فعلی در زیردرخت "cn=Databases,cn=Monitor" پایگاه‌داده monitor فعال می‌کند. در حال حاضر، فقط پایگاه‌داده MDB نظارت ویژهٔ پایگاه‌داده را فراهم می‌کند. اگر نظارت توسط بک‌اند پشتیبانی شود، پیش‌فرض آن on است، در غیر این صورت off است.

overlay <overlay-name>

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

readonly on | off

این گزینه پایگاه‌داده را در حالت «فقط‌خواندنی» (read-only) قرار می‌دهد. هرگونه تلاش برای تغییر پایگاه‌داده، خطای «unwilling to perform» را برمی‌گرداند. به‌طور پیش‌فرض، readonly برابر با off است.

restrict <oplist>

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

rootdn <dn>

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

rootpw <password>

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

suffix <dn suffix>

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

اگر پسوند یک پایگاه‌داده «درون» پایگاه‌داده دیگری باشد، پایگاه‌داده دارای پسوند داخلی باید ابتدا در فایل پیکربندی قرار گیرد. همچنین ممکن است بخواهید چنین پایگاه‌های داده‌ای را با کلیدواژه subordinate به یکدیگر پیوند دهید.

subordinate [advertise]

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

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

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

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

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

database mdb
suffix dc=example,dc=com
...
overlay glue
overlay syncprov

sync_use_subentry: ذخیره contextCSN مربوط به syncrepl در یک زیرمدخل (subentry) به جای مدخل بافت پایگاه‌داده. مقدار RDN زیرمدخل "cn=ldapsync" خواهد بود. به‌طور پیش‌فرض، contextCSN در مدخل بافت ذخیره می‌شود.

syncrepl 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" تنظیم شود، پارامترهای لاگ نادیده گرفته می‌شوند. اگر از multiprovider استفاده می‌شود، پایگاه‌داده یکسان برای logbase باید روی تمام فراهم‌کننده‌ها پیکربندی شود.

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

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

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

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

مثال‌ها (EXAMPLES)

در اینجا نمونه کوتاهی از یک فایل پیکربندی آورده شده است:

include   /etc/openldap/schema/core.schema
pidfile   /var/lib/openldap/run/slapd.pid
# 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).
attributeoptions x-hidden lang-
access to attrs=name;x-hidden by * =cs
# Protect passwords.  See slapd.access(5).
access    to attrs=userPassword  by * auth
# Read access to other attributes and entries.
access    to *  by * read
database  mdb
suffix    "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.
directory /var/lib/openldap/openldap-data
# Indices to maintain
index     objectClass  eq
index     cn,sn,mail   pres,eq,approx,sub
# We serve small clients that do not handle referrals,
# so handle remote lookups on their behalf.
database  ldap
suffix    ""
uri       ldap://ldap.some-server.com/
lastmod   off

راهنمای «OpenLDAP Administrator's Guide» شامل یک نمونه طولانی‌تر و همراه با یادداشت‌های توضیحی از یک فایل پیکربندی است. فایل اصلی /etc/openldap/slapd.conf نمونه دیگری است.

فایل‌ها (FILES)

/etc/openldap/slapd.conf: فایل پیکربندی پیش‌فرض slapd

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

ldap(3)، gnutls-cli(1)، slapd-config(5)، slapd.access(5)، slapd.backends(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 دانشگاه میشیگان برگرفته شده است.