.TH "SLAPD-LDAP" "5" "مه ۲۰۲۵" "OpenLDAP" "فایلهای پیکربندی"
.\" Copyright 1998-2024 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply.  See COPYRIGHT/LICENSE.
.\" $OpenLDAP$
.SH "نام (NAME)"
slapd-ldap \- بکاند پروکسی LDAP برای دیمن slapd
.SH "خلاصه (SYNOPSIS)"
/etc/ldap/slapd.conf
.SH "توضیحات (DESCRIPTION)"
بکاند \fBslapd-ldap\fR به عنوان پروکسی برای هدایت درخواستهای LDAP محلی به سرورهای LDAP راه دور عمل میکند.
در حین پردازش درخواست‌ها، این بکاند ارجاعات (referrals) را نیز دنبال می‌کند تا ارجاعات به طور کامل پردازش شوند و به کلاینت slapd برگردانده نشوند.
.PP
نشست‌هایی که صریحاً به پایگاه‌داده back-ldap متصل (Bind) می‌شوند، همیشه اتصال اختصاصی خود را به سرور LDAP راه دور ایجاد می‌کنند. نشست‌های ناشناس یک اتصال ناشناس مشترک را به سرور راه دور به اشتراک می‌گذارند. برای نشست‌هایی که از طریق سازوکارهای دیگر متصل می‌شوند، تمام نشست‌ها با یک DN یکسان، از همان اتصال مشترک استفاده می‌کنند. این راهبرد تجمیع اتصالات (connection pooling) می‌تواند با کاهش سربار ناشی از ایجاد و قطع مکرر اتصالات متعدد، کارایی پروکسی را بهبود بخشد.
.PP
پایگاه‌داده ldap همچنین می‌تواند به عنوان یک سرویس اطلاعاتی عمل کند؛ یعنی هویت کلاینت‌های احرازهویت‌شده محلی به سرور راه دور اثبات (assert) شود، احتمالاً در قالبی اصلاح‌شده.
برای این منظور، پروکسی با یک هویت مدیریتی به سرور راه دور متصل شده و در صورت نیاز، هویت اثبات‌شده را مجاز می‌کند.
قوانین
.IR idassert\- *
را در ادامه ببینید.
هویت مدیریتی پروکسی در سرور راه دور باید از طریق قوانین مناسب
.B authzTo
مجاز به صدور مجوز باشد؛ برای جزئیات به
.BR slapd.conf (5)
مراجعه کنید.
.PP
نمونه پروکسی
.BR slapd (8)
باید حاوی اطلاعات طرحواره (schema) برای ویژگی‌ها و کلاس‌های شیء (objectClasses) مورد استفاده در فیلترها، DNهای درخواست و به طور کلی داده‌های مرتبط با درخواست باشد.
همچنین باید شامل اطلاعات طرحواره برای داده‌های بازگردانده‌شده توسط سرور پروکسی‌شده باشد.
مسئولیت هماهنگ نگه‌داشتن طرحواره پروکسی با سرور پروکسی‌شده بر عهده مدیر پروکسی است.
.LP
نکته: هنگام ارجاع حلقه‌ای (looping back) به همان نمونه
.BR slapd (8) ،
هر اتصال به یک ریسه (thread) جدید نیاز دارد؛ در نتیجه، ممکن است پارامتر
.BR slapd (8)
\fBthreads\fP نیاز به تنظیم دقیق داشته باشد. در این موارد، می‌توان از
.BR slapd\-relay (5)
استفاده کرد که عملیات بازپخش‌شده را به صورت داخلی انجام داده و از این رو از همان اتصال مجدداً استفاده می‌کند.

.SH "پیکربندی (CONFIGURATION)"
این گزینه‌های
.B slapd.conf
برای پایگاه‌داده بکاند LDAP اعمال می‌شوند.
یعنی باید پس از خط "database ldap" و پیش از هر خط بعدی "backend" یا "database" قرار گیرند.
سایر گزینه‌های پایگاه‌داده در صفحه راهنمای
.BR slapd.conf (5)
شرح داده شده‌اند.
.LP
نکته: در نسخه‌های اولیه back-ldap توصیه می‌شد همیشه
.LP
.RS
.nf
lastmod  off
.fi
.RE
.LP
را برای پایگاه‌های داده
.B ldap
و
.B meta
تنظیم کنید.
این امر به این دلیل لازم بود که ویژگی‌های عملیاتی مربوط به ایجاد و تغییر مدخل نباید پروکسی می‌شدند، زیرا ممکن بود اشتباهاً روی سرور(های) مقصد نوشته شوند و خطایی ایجاد کنند.
پیاده‌سازی فعلی به طور خودکار lastmod را روی \fBoff\fP قرار می‌دهد، بنابراین استفاده از آن زاید است و باید حذف شود.

.TP
.B uri <ldapurl>
سرور LDAP مورد استفاده. چندین URI را می‌توان در یک شناسه
.B ldapurl
تعیین کرد، که باعث می‌شود کتابخانه زیرین به طور خودکار اولین سرور پاسخگو در لیست را فراخوانی کند، به عنوان مثال:

\fBuri "ldap://host/ ldap://backup\-host/"\fP

لیست URI با فاصله یا کاما از هم جدا می‌شود.
هرگاه سروری که پاسخ می‌دهد اولین سرور لیست نباشد، لیست بازآرایی شده و سرور پاسخگو به ابتدای لیست منتقل می‌شود تا دفعه بعدی که نیاز به ایجاد اتصال بود، اول با آن تماس گرفته شود.
.HP
.hy 0
.B acl\-bind
.B bindmethod=simple|sasl [binddn=<simple DN>] [credentials=<simple password>]
.B [saslmech=<SASL mech>] [secprops=<properties>] [realm=<realm>]
.B [authcId=<authentication ID>] [authzId=<authorization ID>]
.B [starttls=no|yes|critical]
.B [tls_cert=<file>]
.B [tls_key=<file>]
.B [tls_cacert=<file>]
.B [tls_cacertdir=<path>]
.B [tls_reqcert=never|allow|try|demand]
.B [tls_reqsan=never|allow|try|demand]
.B [tls_cipher_suite=<ciphers>]
.B [tls_ecname=<names>]
.B [tls_protocol_min=<major>[.<minor>]]
.B [tls_crlcheck=none|peer|all]
.RS
امکان تعریف پارامترهای روش احرازهویتی را فراهم می‌کند که به صورت داخلی توسط پروکسی برای جمع‌آوری اطلاعات مرتبط با کنترل دسترسی و هر زمان که عملیاتی با هویت rootdn پایگاه‌داده پروکسی LDAP رخ می‌دهد، استفاده می‌شود.
هویت تعریف‌شده توسط این دستورالعمل، با توجه به ویژگی‌های مرتبط با روش احرازهویت، فرض می‌شود که دسترسی خواندن به ویژگی‌های مورد استفاده در پروکسی برای بررسی ACL را در سرور مقصد دارد.

هیچ خطری در افشای چنین مقادیری وجود ندارد؛ آن‌ها فقط برای بررسی مجوزها استفاده می‌شوند.
پیش‌فرض استفاده از اتصال
.BR simple 
با \fIbinddn\fP و \fIcredentials\fP خالی است، به این معنی که عملیات مربوطه به صورت ناشناس انجام خواهد شد.
اگر تنظیم نشود، و \fBidassert\-bind\fP تعریف شده باشد، از هویت اخیر استفاده می‌شود. برای جزئیات به \fBidassert\-bind\fP مراجعه کنید.

اتصال بین پایگاه‌داده پروکسی و سرور راه دور مرتبط با این هویت بدون توجه به طول عمر اتصال کلاینت-پروکسی که ابتدا آن را برقرار کرده است، کش می‌شود.

.B این هویت به طور ضمنی توسط پروکسی استفاده نمی‌شود
.B هنگامی که کلاینت به صورت ناشناس متصل می‌شود.
در عوض، ویژگی
.B idassert\-bind
در برخی موارد می‌تواند برای پیاده‌سازی این رفتار تنظیم شود، که \fIذاتاً ناامن است و باید با احتیاط فراوان استفاده شود\fP.

تنظیمات TLS به طور پیش‌فرض همانند تنظیمات اصلی TLS در slapd است، به جز
.B tls_reqcert
که پیش‌فرض آن "demand" است، و
.B tls_reqsan
که پیش‌فرض آن "allow" است.
.RE

.TP
.B cancel {ABANDON|ignore|exop[\-discover]}
نحوه مدیریت لغو عملیات را مشخص می‌کند.
به طور پیش‌فرض،
.B abandon
فراخوانی می‌شود، بنابراین عملیات فوراً رها می‌شود.
اگر روی
.BR ignore
تنظیم شود، هیچ اقدامی صورت نمی‌گیرد و هرگونه پاسخ بعدی نادیده گرفته می‌شود؛ این ممکن است منجر به صف‌بندی پیام‌های پاسخ بعدی برای آن اتصال شود، بنابراین توصیه می‌شود اتصالات طولانی‌مدت توسط
.I idle\-timeout
یا
.IR conn\-ttl
منقضی شوند تا منابع در نهایت آزاد شوند.
اگر روی
.BR exop
تنظیم شود، یک عملیات
.I cancel
(بر اساس RFC 3909) صادر می‌شود که منجر به لغو عملیات فعلی می‌گردد؛ عملیات
.I cancel
منتظر پاسخ سرور راه دور می‌ماند، بنابراین استفاده از آن ممکن است توصیه نشود.
اگر روی
.BR exop\-discover
تنظیم شود، پشتیبانی از عملیات توسعه‌یافته
.I cancel
با خواندن root DSE سرور راه دور شناسایی می‌شود.

.TP
.B chase\-referrals {YES|no}
فعال/غیرفعال کردن دنبال کردن خودکار ارجاعات، که به libldap زیرین واگذار می‌شود، و در صورت استفاده از دستورالعمل \fBrebind\-as\-user\fP در نهایت اتصال مجدد انجام می‌شود. پیش‌فرض دنبال کردن ارجاعات است.

.TP
.B conn\-pool\-max <int>
این دستورالعمل حداکثر اندازه استخر اتصالات ممتاز را مشخص می‌کند.

.TP
.B conn\-ttl <time>
این دستورالعمل باعث می‌شود یک اتصال کش‌شده پس از یک ttl معین قطع شود، صرف‌نظر از اینکه بیکار باشد یا خیر. اگر اتصال کلاینت بیشتر از اتصال راه دور عمر کند، کلاینت هنگام اجرای عملیات بعدی
.IR LDAP_UNAVAILABLE
دریافت خواهد کرد.

.TP
.B idassert\-authzFrom <authz-regexp>
در صورت تعریف، مشخص می‌کند کدام هویت‌های
.I محلی
مجاز به استفاده از ویژگی اثبات هویت هستند.
رشته
.B <authz-regexp>
بیشتر از قواعد تعریف‌شده برای ویژگی
.I authzFrom
پیروی می‌کند.
برای جزئیات درباره ساختار این فیلد، به
.BR slapd.conf (5)،
بخش مربوط به
.BR authz\-policy
مراجعه کنید. این پارامتر با رفتار مستند شده در رابطه با معنای * تفاوت دارد، که در اینجا به جای رد کردن، به اتصال ناشناس اجازه می‌دهد.

.HP
.hy 0
.B idassert\-bind
.B bindmethod=none|simple|sasl [binddn=<simple DN>] [credentials=<simple password>]
.B [saslmech=<SASL mech>] [secprops=<properties>] [realm=<realm>]
.B [authcId=<authentication ID>] [authzId=<authorization ID>]
.B [authz={native|proxyauthz}] [mode=<mode>] [flags=<flags>]
.B [starttls=no|yes|critical]
.B [tls_cert=<file>]
.B [tls_key=<file>]
.B [tls_cacert=<file>]
.B [tls_cacertdir=<path>]
.B [tls_reqcert=never|allow|try|demand]
.B [tls_reqsan=never|allow|try|demand]
.B [tls_cipher_suite=<ciphers>]
.B [tls_ecname=<names>]
.B [tls_protocol_min=<version>]
.B [tls_crlcheck=none|peer|all]
.RS
امکان تعریف پارامترهای روش احرازهویتی را فراهم می‌کند که به صورت داخلی توسط پروکسی برای صدور مجوز اتصالاتی که توسط پایگاه‌های داده دیگر احرازهویت شده‌اند، استفاده می‌شود.
اتصالات مستقیم همیشه بدون هیچ‌گونه پردازش idassert پروکسی می‌شوند.

هویت تعریف‌شده توسط این دستورالعمل، با توجه به ویژگی‌های مرتبط با روش احرازهویت، فرض می‌شود که دسترسی auth به ویژگی‌های مورد استفاده در پروکسی برای احرازهویت و صدور مجوز در سرور مقصد دارد و مجاز به صدور مجوز برای کاربران است.
این امر مستلزم داشتن امتیازات
.B proxyAuthz
بر روی مجموعه گسترده‌ای از DNها است، مانند
.BR authzTo=dn.subtree:"" ،
و اینکه در سرور راه دور
.B authz\-policy
روی
.B to
یا
.BR both
تنظیم شده باشد.
برای جزئیات درباره این عبارات و ملاحظات و معایب استفاده از آن‌ها به
.BR slapd.conf (5)
مراجعه کنید.
روش‌های bind پشتیبانی‌شده عبارتند از:

\fBnone|simple|sasl\fP

که در آن
.B none
پیش‌فرض است، یعنی هیچ \fIاثبات هویتی\fP انجام نمی‌شود.

پارامتر
.B authz
برای هدایت SASL bind به بهره‌برداری از مجوزدهی
.B native 
در SASL، در صورت موجود بودن، استفاده می‌شود؛ از آنجا که اتصالات کش می‌شوند، این مورد فقط باید هنگام صدور مجوز با یک هویت ثابت استفاده شود (به عنوان مثال با استفاده از پارامترهای
.B authzDN
یا
.BR authzID ).
در غیر این صورت، از مقدار پیش‌فرض
.B proxyauthz
استفاده می‌شود، یعنی کنترل proxyAuthz (مجوزدهی پروکسی‌شده، RFC 4370) به تمام عملیات اضافه می‌شود.

حالت‌های پشتیبانی‌شده عبارتند از:

\fB<mode> := {legacy|anonymous|none|self}\fP

اگر 
.B <mode>
حاضر نباشد و 
.B authzId
داده شده باشد، پروکسی همیشه آن هویت را مجاز می‌کند.

.B <authorization ID>
می‌تواند یکی از موارد زیر باشد:

\fBu:<user>\fP

\fB[dn:]<DN>\fP

مورد اول فرض می‌شود که بر اساس قوانین authz توسط سرور راه دور بسط داده شود؛ برای جزئیات به
.BR slapd.conf (5)
مراجعه کنید.
در مورد دوم، صرف‌نظر از وجود یا عدم وجود پیشوند
.B dn: ،
رشته باید اعتبارسنجی و نرمال‌سازی DN را با موفقیت بگذراند.

حالت پیش‌فرض
.BR legacy
است، که به این معنی است که پروکسی یا یک bind ساده به عنوان
.I authcDN
یا یک SASL bind به عنوان
.I authcID
انجام می‌دهد و هویت کلاینت را در صورتی که ناشناس نباشد اثبات می‌کند.
سایر حالت‌ها به این معنی هستند که پروکسی همیشه یا یک bind ساده به عنوان
.IR authcDN
یا یک SASL bind به عنوان
.IR authcID
انجام می‌دهد، مگر اینکه توسط قوانین
.BR idassert\-authzFrom
(در ادامه ببینید) محدود شده باشد، که در این صورت عملیات با شکست مواجه می‌شود؛
در نهایت، هویت دیگری را مطابق با
.BR <mode>
اثبات خواهد کرد.
سایر حالت‌های اثبات هویت عبارتند از
.BR anonymous
و
.BR self ،
که به ترتیب به این معنی هستند که هویت
.I خالی
یا هویت
.IR کلاینت
اثبات خواهد شد؛
.BR none ،
که یعنی هیچ کنترل proxyAuthz استفاده نخواهد شد، بنابراین هویت
.I authcDN
یا
.I authcID
اثبات خواهد شد.
برای تمام حالت‌هایی که نیاز به استفاده از کنترل
.I proxyAuthz 
دارند، هویت پروکسی در سرور راه دور باید مجوزهای مناسب
.I authzTo
را داشته باشد، یا هویت‌های اثبات‌شده باید مجوزهای مناسب
.I authzFrom 
را داشته باشند. توجه داشته باشید که ویژگی اثبات هویت بیشتر زمانی مفید است که هویت‌های اثبات‌شده در سرور راه دور وجود نداشته باشند.

فلگ‌ها می‌توانند موارد زیر باشند:

\fBoverride,[non\-]prescriptive,proxy\-authz\-[non\-]critical,dn\-{authzid|whoami}\fP

هنگامی که فلگ
.B override
استفاده می‌شود، اثبات هویت حتی زمانی که پایگاه‌داده برای هویت کلاینت مجوز می‌دهد رخ می‌دهد، یعنی پس از bind با هویت ارائه‌شده، و بنابراین احرازهویت آن، پروکسی اثبات هویت را با استفاده از هویت و روش احرازهویت پیکربندی‌شده انجام می‌دهد.

هنگامی که فلگ
.B prescriptive
استفاده می‌شود (پیش‌فرض)، عملیات برای آن هویت‌هایی که اثبات آن‌ها توسط الگوهای
.B idassert\-authzFrom
مجاز نیست با
\fIinappropriateAuthentication\fP
شکست می‌خورد.
اگر فلگ
.B non\-prescriptive
استفاده شود، عملیات برای آن هویت‌هایی که اثبات آن‌ها توسط الگوهای
.B idassert\-authzFrom
مجاز نیست به صورت ناشناس انجام می‌شود.

هنگامی که فلگ
.B proxy\-authz\-non\-critical
استفاده می‌شود (پیش‌فرض)، کنترل proxyAuthz بر خلاف RFC 4370 به عنوان بحرانی (critical) علامت‌گذاری نمی‌شود. استفاده از
.B proxy\-authz\-critical
توصیه می‌شود.

هنگامی که فلگ
.B dn\-authzid
استفاده می‌شود، از RFC 3829 (کنترل‌های هویت مجوزدهی LDAP) برای بازیابی هویت مرتبط با هویت SASL استفاده می‌شود؛
هنگامی که فلگ
.B dn\-whoami
استفاده می‌شود، عملیات RFC 4532 (عملیات Who am I در LDAP) پس از bind برای همان هدف انجام می‌شود.

تنظیمات TLS به طور پیش‌فرض همانند تنظیمات اصلی TLS در slapd است، به جز
.B tls_reqcert
که پیش‌فرض آن "demand" است، و
.B tls_reqsan
که پیش‌فرض آن "allow" است.

هویت مرتبط با این دستورالعمل همچنین برای عملیات ممتاز هر زمان که \fBidassert\-bind\fP تعریف شده باشد و \fBacl\-bind\fP تعریف نشده باشد استفاده می‌شود. برای جزئیات به \fBacl\-bind\fP مراجعه کنید.
.RE

.TP
.B idassert-passthru <authz-regexp>
در صورت تعریف، مشخص می‌کند کدام هویت‌های
.I محلی
ویژگی اثبات هویت را دور می‌زنند.
آن هویت‌ها باید برای میزبان راه دور شناخته‌شده باشند.
رشته
.B <authz-regexp>
از قوانین تعریف‌شده برای ویژگی
.I authzFrom
پیروی می‌کند.
برای جزئیات درباره ساختار این فیلد به
.BR slapd.conf (5)،
بخش مربوط به
.BR authz\-policy
مراجعه کنید.

.TP
.B idle\-timeout <time>
این دستورالعمل باعث می‌شود یک اتصال کش‌شده پس از بیکار ماندن به مدت زمان مشخص‌شده قطع شود. اگر اتصال کلاینت بیشتر از اتصال راه دور عمر کند، کلاینت هنگام اجرای عملیات بعدی
.IR LDAP_UNAVAILABLE
دریافت خواهد کرد.

.TP
.B keepalive  <idle>:<probes>:<interval>
پارامتر
.B keepalive
مقادیر \fIidle\fP، \fIprobes\fP و \fIinterval\fP را تنظیم می‌کند که برای بررسی زنده بودن سوکت استفاده می‌شوند؛
.I idle
تعداد ثانیه‌هایی است که اتصال باید بیکار بماند تا TCP ارسال کاوش‌های keepalive را آغاز کند؛
.I probes
حداکثر تعداد کاوش‌های keepalive است که TCP باید قبل از قطع اتصال ارسال کند؛
.I interval
فاصله زمانی بر حسب ثانیه بین کاوش‌های انفرادی keepalive است.
تنها برخی از سیستم‌ها از سفارشی‌سازی این مقادیر پشتیبانی می‌کنند؛ در غیر این صورت پارامتر
.B keepalive
نادیده گرفته شده و از تنظیمات سراسری سیستم استفاده می‌شود.

.TP
.B tcp\-user\-timeout  <milliseconds>
اگر غیر صفر باشد، متناظر با
.B TCP_USER_TIMEOUT
تنظیم‌شده بر روی اتصالات مقصد است، که تنظیمات سیستم‌عامل را بازنویسی می‌کند.
تنها برخی از سیستم‌ها از سفارشی‌سازی این پارامتر پشتیبانی می‌کنند؛ در غیر این صورت نادیده گرفته شده و از تنظیمات سراسری سیستم استفاده می‌شود.

.TP
.B network\-timeout <time>
مقدار مهلت زمانی شبکه را تعیین می‌کند که پس از آن
.BR poll (2)/ select (2) 
متعاقب یک
.BR connect (2) 
در صورت عدم فعالیت بازمی‌گردد.
مقدار بر حسب ثانیه است و می‌تواند همانند
.BR idle\-timeout
مشخص شود.

.TP
.B norefs <NO|yes>
اگر
.BR yes
باشد، پاسخ‌های ارجاع جستجو بازگردانده نمی‌شوند.
به طور پیش‌فرض، آن‌ها بازگردانده می‌شوند مگر اینکه درخواست LDAPv2 باشد.

.TP
.B omit-unknown-schema <NO|yes>
اگر
.BR yes
باشد، objectClassها یا ویژگی‌هایی که برای سرور محلی شناخته‌شده نیستند بازگردانده نمی‌شوند.
پیش‌فرض بازگرداندن تمام عناصر طرحواره است.

.TP
.B noundeffilter <NO|yes>
اگر
.BR yes
باشد، در صورتی که یک فیلتر تعریف‌نشده باشد یا شامل بخش‌های تعریف‌نشده باشد، به جای جستجو، وضعیت موفقیت‌آمیز را برمی‌گرداند.
به طور پیش‌فرض، جستجو پس از جایگزینی بخش‌های تعریف‌نشده با
.BR (!(objectClass=*)) ،
که متناظر با مجموعه نتایج خالی است، منتشر می‌شود.

.TP
.B onerr {CONTINUE|stop}
این دستورالعمل امکان انتخاب رفتار در صورت بازگرداندن خطا توسط سرور راه دور در حین جستجو را فراهم می‌کند.
حالت پیش‌فرض، \fBcontinue\fP، شامل بازگرداندن موفقیت است.
اگر مقدار روی \fBstop\fP تنظیم شود، خطا به کلاینت بازگردانده می‌شود.

.TP
.B protocol\-version {0,2,3}
این دستورالعمل مشخص می‌کند که چه نسخه پروتکلی باید برای تماس با سرور راه دور استفاده شود.
اگر روی 0 (پیش‌فرض) تنظیم شود، پروکسی از همان نسخه پروتکل استفاده‌شده توسط کلاینت استفاده می‌کند، در غیر این صورت از پروتکل درخواستی استفاده می‌شود.
اگر عملیاتی انجام شود که با پروتکل درخواستی ناسازگار باشد، پروکسی \fIunwillingToPerform\fP را برمی‌گرداند.

.TP
.B proxy\-whoami {NO|yes}
پروکسی کردن عملیات توسعه‌یافته WhoAmI را فعال می‌کند. اگر این گزینه داده شود، back-ldap روال اصلی WhoAmI در slapd را با روال خود جایگزین می‌کند. در نشست‌های slapd که توسط back-ldap احرازهویت شده‌اند، درخواست WhoAmI به سرور LDAP راه دور هدایت می‌شود. سایر نشست‌ها مانند قبل توسط slapd محلی رسیدگی می‌شوند. این گزینه عمدتاً همراه با Proxy Authorization مفید است.

.TP
.B quarantine <interval>,<num>[;<interval>,<num>[...]]
قرنطینه کردن URIهایی که
.IR LDAP_UNAVAILABLE
را بازگردانده‌اند فعال می‌کند، به طوری که تلاش برای اتصال مجدد فقط در فواصل زمانی مشخص رخ می‌دهد نه هر بار که یک کلاینت درخواستی را صادر می‌کند.
الگو عبارت است از: تلاش مجدد فقط پس از گذشت حداقل
.I interval
ثانیه از آخرین تلاش، دقیقاً به تعداد
.I num
بار؛ سپس استفاده از الگوی بعدی.
اگر
.I num
برای آخرین الگو "\fB+\fP" باشد، برای همیشه تلاش مجدد می‌کند؛ در غیر این صورت، تلاش مجدد دیگری رخ نمی‌دهد.
این فرآیند می‌تواند با بازنشانی ویژگی \fIolcDbQuarantine\fP در مدخل پایگاه‌داده در بکاند پیکربندی مجدداً راه‌اندازی شود.

.TP
.B rebind\-as\-user {NO|yes}
اگر این گزینه داده شود، اطلاعات احرازهویت bind کلاینت برای اتصال‌های مجدد، هنگام تلاش برای برقراری مجدد یک اتصال قطع‌شده، یا هنگام دنبال کردن ارجاع به خاطر سپرده می‌شود در صورتی که
.B chase\-referrals
روی
.IR yes
تنظیم شده باشد.
توجه داشته باشید که اتصال پس از قطع شدن به دلیل
.B idle\-timeout
یا
.B conn\-ttl
به طور خودکار مجدداً برقرار نمی‌شود.

.TP
.B session\-tracking\-request {NO|yes}
کنترل ردیابی نشست را برای تمام درخواست‌ها اضافه می‌کند.
آدرس IP و نام میزبان کلاینت، و هویت مرتبط با هر درخواست (در صورت مشخص بودن) برای اهداف اطلاعاتی به سرور راه دور ارسال می‌شوند.
این دستورالعمل با تنظیم \fIprotocol\-version\fP روی 2 ناسازگار است.

.TP
.B single\-conn {NO|yes}
هنگامی که کلاینت مجدداً متصل می‌شود (rebind)، اتصال کش‌شده فعلی را کنار می‌گذارد.

.TP
.B t\-f\-support {NO|yes|discover}
اگر سرور راه دور از فیلترهای مطلق پشتیبانی می‌کند آن را فعال کنید (برای جزئیات به \fIRFC 4526\fP مراجعه کنید).
اگر روی
.BR discover
تنظیم شود، پشتیبانی با خواندن root DSE سرور راه دور شناسایی می‌شود.

.TP
.B timeout [<op>=]<val> [...]
این دستورالعمل امکان تعیین مهلت‌های زمانی برای هر عملیات را فراهم می‌کند.
عملیات می‌توانند موارد زیر باشند:

\fB<op> ::= bind, add, delete, modrdn, modify, compare, search\fP

مدت زمان کلی عملیات \fBsearch\fP یا توسط پارامتر \fBtimelimit\fP یا توسط محدودیت‌های زمانی اعمال‌شده توسط سرور کنترل می‌شود (برای جزئیات به \fBtimelimit\fP و \fBlimits\fP در
.BR slapd.conf (5)
مراجعه کنید).
این پارامتر \fBtimeout\fP کنترل می‌کند که مقصد چه مدت می‌تواند قبل از سقط عملیات بدون پاسخ بماند.
تعیین مهلت زمانی برای سایر عملیات، یعنی \fBunbind\fP و \fBabandon\fP که مستلزم هیچ پاسخی نیستند، بی‌معنی است، در حالی که در عملیات \fBextended\fP که در حال حاضر پشتیبانی می‌شوند هنوز پیاده‌سازی نشده است.
اگر هیچ عملیاتی مشخص نشود، مهلت زمانی \fBval\fP بر تمام عملیات پشتیبانی‌شده تأثیر می‌گذارد.

نکته: اگر محدودیت زمانی فراتر رود، عملیات لغو می‌شود (بر اساس دستورالعمل \fBcancel\fP)؛ پروتکل هیچ روشی برای بازگردانی عملیات ارائه نمی‌دهد، بنابراین کلاینت از نتیجه عملیات که در نهایت ممکن است موفق شده باشد یا نه، مطلع نخواهد شد. در صورتی که در حین عملیات bind مهلت زمانی به پایان برسد، مطابق با RFC4511 اتصال از بین می‌رود.

نکته: در برخی موارد، این بکاند ممکن است قبل از سایر عملیات اقدام به bind کند (مثلاً برای bind ناشناس یا با هویتی مشخص طبق دستورالعمل \fBidassert\-bind\fP). در این حالت، مهلت زمانی عملیاتی که منجر به bind شده است استفاده می‌شود.

.HP
.hy 0
.B tls {none|[try\-]start|[try\-]propagate|ldaps}
.B [starttls=no]
.B [tls_cert=<file>]
.B [tls_key=<file>]
.B [tls_cacert=<file>]
.B [tls_cacertdir=<path>]
.B [tls_reqcert=never|allow|try|demand]
.B [tls_reqsan=never|allow|try|demand]
.B [tls_cipher_suite=<ciphers>]
.B [tls_ecname=<names>]
.B [tls_crlcheck=none|peer|all]
.RS
تنظیمات TLS را برای اتصالات عادی مشخص می‌کند.

اگر پارامتر اول "none" نباشد، این دستور تنظیمات TLS مورد استفاده برای اتصالات عادی را پیکربندی می‌کند.
عملیات توسعه‌یافته StartTLS هنگام برقراری اتصال استفاده خواهد شد مگر اینکه طرح پروتکل در دستورالعمل URI برابر با \fBldaps://\fP باشد.
در آن حالت این کلیدواژه فقط می‌تواند روی "ldaps" تنظیم شود و عملیات StartTLS استفاده نخواهد شد.

با \fBpropagate\fP، پروکسی تنها در صورتی عملیات StartTLS را صادر می‌کند که اتصال اصلی دارای یک لایه TLS برقرار شده باشد.
پیشوند \fBtry\-\fP به پروکسی دستور می‌دهد در صورت شکست عملیات StartTLS به عملیات ادامه دهد؛ استفاده از آن توصیه \fBنمی‌شود\fP.

تنظیمات TLS به طور پیش‌فرض همانند تنظیمات اصلی TLS در slapd است، به جز
.B tls_reqcert
که پیش‌فرض آن "demand" است،
.B tls_reqsan
که پیش‌فرض آن "allow" است، و
.B starttls
که تحت‌الشعاع کلمه کلیدی اول قرار گرفته و بنابراین نادیده گرفته می‌شود.
.RE

.TP
.B use\-temporary\-conn {NO|yes}
هنگامی که روی 
.BR yes
تنظیم شود، هر زمان که با سایر ریسه‌ها برای یک اتصال مشترک رقابت می‌کند، یک اتصال موقت ایجاد می‌کند؛ در غیر این صورت، صبر می‌کند تا اتصال مشترک در دسترس قرار گیرد.

.SH "کنترل دسترسی (ACCESS CONTROL)"
بکاند
.B ldap
از تمام قواعد معنایی ACL همانطور که در
.BR slapd.access (5)
توصیف شده است، پیروی نمی‌کند.
به طور کلی، بررسی دسترسی به سرور(های) راه دور واگذار می‌شود.
تنها دسترسی
.B خواندن (=r)
به شبه‌ویژگی
.B entry
و به سایر مقادیر ویژگی‌های مدخل‌های بازگردانده‌شده توسط عملیات
.B search
رعایت می‌شود که توسط فرانت‌اند انجام می‌پذیرد.

.SH "اورلی‌ها (OVERLAYS)"
بکاند LDAP قابلیت‌های پایه‌ای پروکسی را برای بسیاری از اورلی‌ها فراهم می‌کند.
اورلی
.B chain
که در
.BR slapo\-chain (5)
توصیف شده، و اورلی
.B translucent
که در
.BR slapo\-translucent (5)
توصیف شده است، شایسته اشاره ویژه هستند.
.PP
برعکس، اورلی‌های متعددی وجود دارند که بهتر است همراه با بکاند LDAP استفاده شوند.
اورلی
.B proxycache 
امکان کش کردن درخواست‌های جستجوی LDAP (پرس‌وجوها) را در یک پایگاه‌داده محلی فراهم می‌کند.
برای جزئیات به
.BR slapo\-pcache (5)
مراجعه کنید.
اورلی
.B rwm
قابلیت‌های بازنویسی DN و نگاشت ویژگی/objectClass را برای پایگاه‌داده زیرین فراهم می‌کند.
برای جزئیات به
.BR slapo\-rwm (5)
مراجعه کنید.

.SH "فایل‌ها (FILES)"
.TP
/etc/ldap/slapd.conf
فایل پیکربندی پیش‌فرض slapd
.SH "همچنین ببینید (SEE ALSO)"
.BR slapd.conf (5),
.BR slapd\-config (5),
.BR slapd\-meta (5),
.BR slapo\-chain (5),
.BR slapo\-pcache (5),
.BR slapo\-rwm (5),
.BR slapo\-translucent (5),
.BR slapd (8),
.BR ldap (3).
.SH "نویسنده (AUTHOR)"
Howard Chu، با بهبودهایی از Pierangelo Masarati