SLAPD-LDAP(5) فایلهای پیکربندی SLAPD-LDAP(5)

slapd-ldap - بکاند پروکسی LDAP برای دیمن slapd

/etc/ldap/slapd.conf

بکاند slapd-ldap به عنوان پروکسی برای هدایت درخواستهای LDAP محلی به سرورهای LDAP راه دور عمل میکند. در حین پردازش درخواست‌ها، این بکاند ارجاعات (referrals) را نیز دنبال می‌کند تا ارجاعات به طور کامل پردازش شوند و به کلاینت slapd برگردانده نشوند.

نشست‌هایی که صریحاً به پایگاه‌داده back-ldap متصل (Bind) می‌شوند، همیشه اتصال اختصاصی خود را به سرور LDAP راه دور ایجاد می‌کنند. نشست‌های ناشناس یک اتصال ناشناس مشترک را به سرور راه دور به اشتراک می‌گذارند. برای نشست‌هایی که از طریق سازوکارهای دیگر متصل می‌شوند، تمام نشست‌ها با یک DN یکسان، از همان اتصال مشترک استفاده می‌کنند. این راهبرد تجمیع اتصالات (connection pooling) می‌تواند با کاهش سربار ناشی از ایجاد و قطع مکرر اتصالات متعدد، کارایی پروکسی را بهبود بخشد.

پایگاه‌داده ldap همچنین می‌تواند به عنوان یک سرویس اطلاعاتی عمل کند؛ یعنی هویت کلاینت‌های احرازهویت‌شده محلی به سرور راه دور اثبات (assert) شود، احتمالاً در قالبی اصلاح‌شده. برای این منظور، پروکسی با یک هویت مدیریتی به سرور راه دور متصل شده و در صورت نیاز، هویت اثبات‌شده را مجاز می‌کند. قوانین idassert-* را در ادامه ببینید. هویت مدیریتی پروکسی در سرور راه دور باید از طریق قوانین مناسب authzTo مجاز به صدور مجوز باشد؛ برای جزئیات به slapd.conf(5) مراجعه کنید.

نمونه پروکسی slapd(8) باید حاوی اطلاعات طرحواره (schema) برای ویژگی‌ها و کلاس‌های شیء (objectClasses) مورد استفاده در فیلترها، DNهای درخواست و به طور کلی داده‌های مرتبط با درخواست باشد. همچنین باید شامل اطلاعات طرحواره برای داده‌های بازگردانده‌شده توسط سرور پروکسی‌شده باشد. مسئولیت هماهنگ نگه‌داشتن طرحواره پروکسی با سرور پروکسی‌شده بر عهده مدیر پروکسی است.

نکته: هنگام ارجاع حلقه‌ای (looping back) به همان نمونه slapd(8)، هر اتصال به یک ریسه (thread) جدید نیاز دارد؛ در نتیجه، ممکن است پارامتر slapd(8) threads نیاز به تنظیم دقیق داشته باشد. در این موارد، می‌توان از slapd-relay(5) استفاده کرد که عملیات بازپخش‌شده را به صورت داخلی انجام داده و از این رو از همان اتصال مجدداً استفاده می‌کند.

این گزینه‌های slapd.conf برای پایگاه‌داده بکاند LDAP اعمال می‌شوند. یعنی باید پس از خط "database ldap" و پیش از هر خط بعدی "backend" یا "database" قرار گیرند. سایر گزینه‌های پایگاه‌داده در صفحه راهنمای slapd.conf(5) شرح داده شده‌اند.

نکته: در نسخه‌های اولیه back-ldap توصیه می‌شد همیشه

lastmod  off

را برای پایگاه‌های داده ldap و meta تنظیم کنید. این امر به این دلیل لازم بود که ویژگی‌های عملیاتی مربوط به ایجاد و تغییر مدخل نباید پروکسی می‌شدند، زیرا ممکن بود اشتباهاً روی سرور(های) مقصد نوشته شوند و خطایی ایجاد کنند. پیاده‌سازی فعلی به طور خودکار lastmod را روی off قرار می‌دهد، بنابراین استفاده از آن زاید است و باید حذف شود.

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

uri "ldap://host/ ldap://backup-host/"

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

acl-bind bindmethod=simple|sasl [binddn=<simple DN>] [credentials=<simple password>] [saslmech=<SASL mech>] [secprops=<properties>] [realm=<realm>] [authcId=<authentication ID>] [authzId=<authorization ID>] [starttls=no|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_protocol_min=<major>[.<minor>]] [tls_crlcheck=none|peer|all]

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

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

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

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

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

نحوه مدیریت لغو عملیات را مشخص می‌کند. به طور پیش‌فرض، abandon فراخوانی می‌شود، بنابراین عملیات فوراً رها می‌شود. اگر روی ignore تنظیم شود، هیچ اقدامی صورت نمی‌گیرد و هرگونه پاسخ بعدی نادیده گرفته می‌شود؛ این ممکن است منجر به صف‌بندی پیام‌های پاسخ بعدی برای آن اتصال شود، بنابراین توصیه می‌شود اتصالات طولانی‌مدت توسط idle-timeout یا conn-ttl منقضی شوند تا منابع در نهایت آزاد شوند. اگر روی exop تنظیم شود، یک عملیات cancel (بر اساس RFC 3909) صادر می‌شود که منجر به لغو عملیات فعلی می‌گردد؛ عملیات cancel منتظر پاسخ سرور راه دور می‌ماند، بنابراین استفاده از آن ممکن است توصیه نشود. اگر روی exop-discover تنظیم شود، پشتیبانی از عملیات توسعه‌یافته cancel با خواندن root DSE سرور راه دور شناسایی می‌شود.
فعال/غیرفعال کردن دنبال کردن خودکار ارجاعات، که به libldap زیرین واگذار می‌شود، و در صورت استفاده از دستورالعمل rebind-as-user در نهایت اتصال مجدد انجام می‌شود. پیش‌فرض دنبال کردن ارجاعات است.
این دستورالعمل حداکثر اندازه استخر اتصالات ممتاز را مشخص می‌کند.
این دستورالعمل باعث می‌شود یک اتصال کش‌شده پس از یک ttl معین قطع شود، صرف‌نظر از اینکه بیکار باشد یا خیر. اگر اتصال کلاینت بیشتر از اتصال راه دور عمر کند، کلاینت هنگام اجرای عملیات بعدی LDAP_UNAVAILABLE دریافت خواهد کرد.
در صورت تعریف، مشخص می‌کند کدام هویت‌های محلی مجاز به استفاده از ویژگی اثبات هویت هستند. رشته <authz-regexp> بیشتر از قواعد تعریف‌شده برای ویژگی authzFrom پیروی می‌کند. برای جزئیات درباره ساختار این فیلد، به slapd.conf(5)، بخش مربوط به authz-policy مراجعه کنید. این پارامتر با رفتار مستند شده در رابطه با معنای * تفاوت دارد، که در اینجا به جای رد کردن، به اتصال ناشناس اجازه می‌دهد.

idassert-bind bindmethod=none|simple|sasl [binddn=<simple DN>] [credentials=<simple password>] [saslmech=<SASL mech>] [secprops=<properties>] [realm=<realm>] [authcId=<authentication ID>] [authzId=<authorization ID>] [authz={native|proxyauthz}] [mode=<mode>] [flags=<flags>] [starttls=no|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_protocol_min=<version>] [tls_crlcheck=none|peer|all]

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

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

none|simple|sasl

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

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

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

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

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

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

u:<user>

[dn:]<DN>

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

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

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

override,[non-]prescriptive,proxy-authz-[non-]critical,dn-{authzid|whoami}

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

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

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

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

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

هویت مرتبط با این دستورالعمل همچنین برای عملیات ممتاز هر زمان که idassert-bind تعریف شده باشد و acl-bind تعریف نشده باشد استفاده می‌شود. برای جزئیات به acl-bind مراجعه کنید.

در صورت تعریف، مشخص می‌کند کدام هویت‌های محلی ویژگی اثبات هویت را دور می‌زنند. آن هویت‌ها باید برای میزبان راه دور شناخته‌شده باشند. رشته <authz-regexp> از قوانین تعریف‌شده برای ویژگی authzFrom پیروی می‌کند. برای جزئیات درباره ساختار این فیلد به slapd.conf(5)، بخش مربوط به authz-policy مراجعه کنید.
این دستورالعمل باعث می‌شود یک اتصال کش‌شده پس از بیکار ماندن به مدت زمان مشخص‌شده قطع شود. اگر اتصال کلاینت بیشتر از اتصال راه دور عمر کند، کلاینت هنگام اجرای عملیات بعدی LDAP_UNAVAILABLE دریافت خواهد کرد.
پارامتر keepalive مقادیر idle، probes و interval را تنظیم می‌کند که برای بررسی زنده بودن سوکت استفاده می‌شوند؛ idle تعداد ثانیه‌هایی است که اتصال باید بیکار بماند تا TCP ارسال کاوش‌های keepalive را آغاز کند؛ probes حداکثر تعداد کاوش‌های keepalive است که TCP باید قبل از قطع اتصال ارسال کند؛ interval فاصله زمانی بر حسب ثانیه بین کاوش‌های انفرادی keepalive است. تنها برخی از سیستم‌ها از سفارشی‌سازی این مقادیر پشتیبانی می‌کنند؛ در غیر این صورت پارامتر keepalive نادیده گرفته شده و از تنظیمات سراسری سیستم استفاده می‌شود.
اگر غیر صفر باشد، متناظر با TCP_USER_TIMEOUT تنظیم‌شده بر روی اتصالات مقصد است، که تنظیمات سیستم‌عامل را بازنویسی می‌کند. تنها برخی از سیستم‌ها از سفارشی‌سازی این پارامتر پشتیبانی می‌کنند؛ در غیر این صورت نادیده گرفته شده و از تنظیمات سراسری سیستم استفاده می‌شود.
مقدار مهلت زمانی شبکه را تعیین می‌کند که پس از آن poll(2)/select(2) متعاقب یک connect(2) در صورت عدم فعالیت بازمی‌گردد. مقدار بر حسب ثانیه است و می‌تواند همانند idle-timeout مشخص شود.
اگر yes باشد، پاسخ‌های ارجاع جستجو بازگردانده نمی‌شوند. به طور پیش‌فرض، آن‌ها بازگردانده می‌شوند مگر اینکه درخواست LDAPv2 باشد.
اگر yes باشد، objectClassها یا ویژگی‌هایی که برای سرور محلی شناخته‌شده نیستند بازگردانده نمی‌شوند. پیش‌فرض بازگرداندن تمام عناصر طرحواره است.
اگر yes باشد، در صورتی که یک فیلتر تعریف‌نشده باشد یا شامل بخش‌های تعریف‌نشده باشد، به جای جستجو، وضعیت موفقیت‌آمیز را برمی‌گرداند. به طور پیش‌فرض، جستجو پس از جایگزینی بخش‌های تعریف‌نشده با (!(objectClass=*))، که متناظر با مجموعه نتایج خالی است، منتشر می‌شود.
این دستورالعمل امکان انتخاب رفتار در صورت بازگرداندن خطا توسط سرور راه دور در حین جستجو را فراهم می‌کند. حالت پیش‌فرض، continue، شامل بازگرداندن موفقیت است. اگر مقدار روی stop تنظیم شود، خطا به کلاینت بازگردانده می‌شود.
این دستورالعمل مشخص می‌کند که چه نسخه پروتکلی باید برای تماس با سرور راه دور استفاده شود. اگر روی 0 (پیش‌فرض) تنظیم شود، پروکسی از همان نسخه پروتکل استفاده‌شده توسط کلاینت استفاده می‌کند، در غیر این صورت از پروتکل درخواستی استفاده می‌شود. اگر عملیاتی انجام شود که با پروتکل درخواستی ناسازگار باشد، پروکسی unwillingToPerform را برمی‌گرداند.
پروکسی کردن عملیات توسعه‌یافته WhoAmI را فعال می‌کند. اگر این گزینه داده شود، back-ldap روال اصلی WhoAmI در slapd را با روال خود جایگزین می‌کند. در نشست‌های slapd که توسط back-ldap احرازهویت شده‌اند، درخواست WhoAmI به سرور LDAP راه دور هدایت می‌شود. سایر نشست‌ها مانند قبل توسط slapd محلی رسیدگی می‌شوند. این گزینه عمدتاً همراه با Proxy Authorization مفید است.
قرنطینه کردن URIهایی که LDAP_UNAVAILABLE را بازگردانده‌اند فعال می‌کند، به طوری که تلاش برای اتصال مجدد فقط در فواصل زمانی مشخص رخ می‌دهد نه هر بار که یک کلاینت درخواستی را صادر می‌کند. الگو عبارت است از: تلاش مجدد فقط پس از گذشت حداقل interval ثانیه از آخرین تلاش، دقیقاً به تعداد num بار؛ سپس استفاده از الگوی بعدی. اگر num برای آخرین الگو "+" باشد، برای همیشه تلاش مجدد می‌کند؛ در غیر این صورت، تلاش مجدد دیگری رخ نمی‌دهد. این فرآیند می‌تواند با بازنشانی ویژگی olcDbQuarantine در مدخل پایگاه‌داده در بکاند پیکربندی مجدداً راه‌اندازی شود.
اگر این گزینه داده شود، اطلاعات احرازهویت bind کلاینت برای اتصال‌های مجدد، هنگام تلاش برای برقراری مجدد یک اتصال قطع‌شده، یا هنگام دنبال کردن ارجاع به خاطر سپرده می‌شود در صورتی که chase-referrals روی yes تنظیم شده باشد. توجه داشته باشید که اتصال پس از قطع شدن به دلیل idle-timeout یا conn-ttl به طور خودکار مجدداً برقرار نمی‌شود.
کنترل ردیابی نشست را برای تمام درخواست‌ها اضافه می‌کند. آدرس IP و نام میزبان کلاینت، و هویت مرتبط با هر درخواست (در صورت مشخص بودن) برای اهداف اطلاعاتی به سرور راه دور ارسال می‌شوند. این دستورالعمل با تنظیم protocol-version روی 2 ناسازگار است.
هنگامی که کلاینت مجدداً متصل می‌شود (rebind)، اتصال کش‌شده فعلی را کنار می‌گذارد.
اگر سرور راه دور از فیلترهای مطلق پشتیبانی می‌کند آن را فعال کنید (برای جزئیات به RFC 4526 مراجعه کنید). اگر روی discover تنظیم شود، پشتیبانی با خواندن root DSE سرور راه دور شناسایی می‌شود.
این دستورالعمل امکان تعیین مهلت‌های زمانی برای هر عملیات را فراهم می‌کند. عملیات می‌توانند موارد زیر باشند:

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

مدت زمان کلی عملیات search یا توسط پارامتر timelimit یا توسط محدودیت‌های زمانی اعمال‌شده توسط سرور کنترل می‌شود (برای جزئیات به timelimit و limits در slapd.conf(5) مراجعه کنید). این پارامتر timeout کنترل می‌کند که مقصد چه مدت می‌تواند قبل از سقط عملیات بدون پاسخ بماند. تعیین مهلت زمانی برای سایر عملیات، یعنی unbind و abandon که مستلزم هیچ پاسخی نیستند، بی‌معنی است، در حالی که در عملیات extended که در حال حاضر پشتیبانی می‌شوند هنوز پیاده‌سازی نشده است. اگر هیچ عملیاتی مشخص نشود، مهلت زمانی val بر تمام عملیات پشتیبانی‌شده تأثیر می‌گذارد.

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

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

tls {none|[try-]start|[try-]propagate|ldaps} [starttls=no] [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 را برای اتصالات عادی مشخص می‌کند.

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

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

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

هنگامی که روی yes تنظیم شود، هر زمان که با سایر ریسه‌ها برای یک اتصال مشترک رقابت می‌کند، یک اتصال موقت ایجاد می‌کند؛ در غیر این صورت، صبر می‌کند تا اتصال مشترک در دسترس قرار گیرد.

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

بکاند LDAP قابلیت‌های پایه‌ای پروکسی را برای بسیاری از اورلی‌ها فراهم می‌کند. اورلی chain که در slapo-chain(5) توصیف شده، و اورلی translucent که در slapo-translucent(5) توصیف شده است، شایسته اشاره ویژه هستند.

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

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

slapd.conf(5), slapd-config(5), slapd-meta(5), slapo-chain(5), slapo-pcache(5), slapo-rwm(5), slapo-translucent(5), slapd(8), ldap(3).

Howard Chu، با بهبودهایی از Pierangelo Masarati

مه ۲۰۲۵ OpenLDAP