SLAPO-RWM(5) File Formats Manual SLAPO-RWM(5)

slapo-rwm - بازنویسی/نگاشت بازپوشانی (Rewrite/Remap overlay) برای slapd

/etc/openldap/slapd.conf

روکش rwm برای slapd(8) عملیات پایه‌ای بازنویسی DN/داده و نگاشت objectClass/attributeType را انجام می‌دهد. کاربرد آن عمدتاً برای ارائه نماهای مجازی (virtual views) از داده‌های موجود است؛ چه به صورت از راه دور در ترکیب با بک‌اند پروکسی شرح داده شده در slapd-ldap(5)، یا به صورت محلی در ترکیب با بک‌اند رله شرح داده شده در slapd-relay(5).

این روکش آزمایشی (experimental) است.

یکی از قابلیت‌های مهم روکش rwm امکان نگاشت objectClassها و attributeTypeها از مجموعه محلی (یا زیرمجموعه‌ای از آن) به یک مجموعه خارجی و برعکس است. این کار از طریق دستورالعمل rwm-map انجام می‌پذیرد.

نگاشت attributeTypeها و objectClassها از سرور خارجی به مقادیر متفاوت در slapd محلی. دلیل آن این است که ممکن است برخی از ویژگی‌ها بخشی از طرح‌واره slapd محلی نباشند، برخی از نام‌های ویژگی‌ها متفاوت باشند اما همان هدف را برآورده کنند، و غیره. اگر نام محلی یا خارجی برابر `*' باشد، نام حفظ می‌شود. اگر نام محلی قید نشود، نام خارجی حذف می‌گردد. نام‌های نگاشت‌نشده در صورتی که هر دو نام محلی و خارجی برابر `*' باشند حفظ می‌شوند، و اگر نام محلی حذف شده و نام خارجی برابر `*' باشد، حذف خواهند شد.

مقادیر محلی objectClasses و attributeTypes باید در طرح‌واره محلی تعریف شده باشند؛ موارد خارجی نیازی به تعریف ندارند، اما به کاربران توصیه می‌شود که صراحتاً attributeTypeها و objectClassهای راه دور را که قصد نگاشت آن‌ها را دارند تعریف کنند. روی‌هم‌رفته، هنگام بازنگاشت یک سرور راه دور از طریق back-ldap (slapd-ldap(5)) یا back-meta (slapd-meta(5)) تعریف آن‌ها را می‌توان به سادگی با پرس‌وجو از subschemaSubentry سرور راه دور به دست آورد؛ این مشکل هنگام بازنگاشت یک پایگاه‌داده محلی نباید وجود داشته باشد. با این حال توجه داشته باشید که تصمیم‌گیری در مورد بازنویسی یا عدم بازنویسی attributeTypeهای دارای نحو distinguishedName، نیازمند آگاهی از نحو attributeType است. برای جزئیات بیشتر به بخش بازنویسی (REWRITING) مراجعه کنید.

توجه داشته باشید که هنگام نگاشت ویژگی‌های دارای مقدار DN از محلی به راه دور، ابتدا DN بازنویسی می‌شود و سپس attributeType نگاشت می‌گردد؛ در حالی که هنگام نگاشت از راه دور به محلی، ابتدا attributeType نگاشت می‌شود و سپس DN بازنویسی می‌گردد. از این رو، مهم است که attributeType محلی به درستی با استفاده از نحو distinguishedName تعریف شده باشد. همچنین توجه داشته باشید نحوهای مرتبط با DN وجود دارند (یعنی انواع ترکیبی با بخشی که دارای مقدار DN است)، مانند nameAndOptionalUID، که مقادیر آن‌ها در حال حاضر بازنویسی نمی‌شوند.

اگر نوع خارجی یک نگاشت ویژگی روی سرور محلی تعریف نشده باشد، ممکن است نرمال‌سازی مقادیر ویژگی پس از فرآیند نگاشت مطلوب باشد. عدم نرمال‌سازی مقادیر می‌تواند به نتایج نادرست منجر شود، به عنوان نمونه هنگامی که روکش rwm همراه با روکش‌هایی نظیر pcache به کار می‌رود. این نرمال‌سازی را می‌توان با استفاده از دستورالعمل rwm-normalize-mapped-attrs فعال کرد.

اگر روکش rwm باید سعی کند مقادیر ویژگی‌هایی را که از یک نوع ویژگی ناشناخته برای سرور محلی نگاشت شده‌اند نرمال‌سازی کند، این تنظیم را روی "yes" قرار دهید. مقدار پیش‌فرض این تنظیم "no" است.
اگر روکش rwm باید ویژگی‌هایی را که صریحاً توسط یک عملیات جستجو درخواست نشده‌اند حذف کند، این گزینه را روی "yes" قرار دهید. هنگامی که این گزینه روی "no" تنظیم شده باشد، روکش rwm تمام ویژگی‌ها را در جای خود باقی می‌گذارد تا ماژول‌های بعدی بتوانند آن‌ها را بیشتر دستکاری کنند. در هر صورت، ویژگی‌های درخواست‌نشده هنگام کدگذاری بسته پاسخ مدخل جستجو توسط فرانت‌اند، از نتایج جستجو حذف خواهند شد. مقدار پیش‌فرض این تنظیم "yes" است.

یک قابلیت پایه‌ای روکش rwm امکان انجام ماساژ/تغییر پسوند (suffix massaging) بین یک بافت نام‌گذاری مجازی و یک بافت نام‌گذاری واقعی از طریق دستورالعمل rwm-suffixmassage است. این ویژگی در ترکیب با بک‌اندهای پروکسی، slapd-ldap(5) و slapd-meta(5)، یا با بک‌اند رله، slapd-relay(5)، امکان ایجاد نماهای مجازی از پایگاه‌های داده را فراهم می‌سازد. یک ویژگی متمایزکننده این روکش این است که اگر پیش از هر پایگاه‌داده‌ای نمونه‌سازی شود، می‌تواند DN درخواست‌ها را پیش از انتخاب پایگاه‌داده تغییر دهد. به همین دلیل، قواعدی که DN خالی ("") یا DN مربوط به subschemaSubentry (معمولاً "cn=subschema") را بازنویسی می‌کنند، مانع از خواندن DSE ریشه یا طرح‌واره DSA توسط کلاینت‌ها خواهند شد.

میانبری برای پیاده‌سازی بازنویسی بافت نام‌گذاری؛ بخش پایانی DN از بافت نام‌گذاری مجازی به واقعی در زمینه‌های بازنویسی bindDN، searchDN، searchFilterAttrDN، compareDN، compareAttrDN، addDN، addAttrDN، modifyDN، modifyAttrDN، modrDN، newSuperiorDN، deleteDN، exopPasswdDN، و از بافت نام‌گذاری واقعی به مجازی در searchEntryDN، searchAttrDN و matchedDN بازنویسی می‌شود. به طور پیش‌فرض هیچ بازنویسی برای searchFilter و برای زمینه‌های بازنویسی referralAttrDN و referralDN رخ نمی‌دهد. اگر هیچ <virtual naming context> مشخص نشود، از اولین پسوند پایگاه‌داده استفاده می‌شود؛ این امر مستلزم آن است که دستورالعمل rwm-suffixmassage پس از دستورالعمل suffix پایگاه‌داده تعریف شود. دستورالعمل rwm-suffixmassage به طور خودکار rwm-rewriteEngine را روی ON تنظیم می‌کند.

برای جزئیات به بخش بازنویسی (REWRITING) مراجعه کنید.

یک رشته بر اساس مجموعه‌ای از قوانین به نام «زمینه بازنویسی» (rewrite context) بازنویسی می‌شود. این قوانین بر پایه عبارت‌های منظم POSIX (از نوع «گسترش‌یافته» یا extended) همراه با تطبیق زیررشته‌ها استوار هستند؛ جایگزینی متغیرهای پایه‌ای و تفکیک نگاشت (map resolution) زیررشته‌ها توسط سازوکارهای مشخصی که در ادامه شرح داده شده‌اند امکان‌پذیر است. رفتار تطبیق الگو/جایگزینی می‌تواند توسط مجموعه‌ای از فلگ‌ها تغییر یابد.

<rewrite context> ::= <rewrite rule> [...]
<rewrite rule> ::= <pattern> <action> [<flags>]

ایده بنیادین، ساخت یک ماژول بازنویسی سبک‌وزن برای سرور slapd است (که در ابتدا به بک‌اند LDAP اختصاص داشت):

رشته ورودی با مجموعه‌ای از rewriteRules تطبیق داده می‌شود. قوانین از یک الگوی تطبیق عبارت منظم، یک الگوی جایگزینی و مجموعه‌ای از عملیات تشکیل شده‌اند که توسط مجموعه‌ای از فلگ‌های اختیاری شرح داده می‌شوند. در صورت تطبیق، بازنویسی رشته مطابق با الگوی جایگزینی انجام می‌گیرد که امکان ارجاع به زیررشته‌های تطبیق‌یافته در رشته ورودی را فراهم می‌سازد. سپس عملیات (در صورت وجود) اجرا می‌شوند. هر قانون به صورت بازگشتی اجرا می‌شود مگر اینکه توسط فلگ‌های عملیاتی خاص تغییر یابد؛ برای جزئیات به "فلگ‌های عملیات" مراجعه کنید. یک حد پیش‌فرض برای سطح بازگشت تنظیم شده است که می‌تواند با دستورالعمل rwm-rewriteMaxPasses تغییر کند، همان‌گونه که در بخش "نحو پیکربندی تکمیلی" شرح داده شده است. الگوی جایگزینی امکان تفکیک نگاشت زیررشته‌ها را فراهم می‌کند. یک نگاشت (map) یک شیء عمومی است که یک الگوی جایگزینی را به یک مقدار نگاشت می‌کند. فلگ‌ها به "فلگ‌های تطبیق الگو" و "فلگ‌های عملیات" تقسیم می‌شوند؛ دسته اول رفتار الگوی تطبیق عبارت منظم را تغییر می‌دهند، در حالی که دسته دوم عملیاتی را که پس از جایگزینی انجام می‌شوند تغییر می‌دهند.

`C'
رعایت بزرگی و کوچکی حروف در تطبیق (پیش‌فرض حساس نبودن به بزرگی و کوچکی حروف است)
`R'
استفاده از عبارت‌های منظم «پایه‌ای» POSIX (پیش‌فرض «گسترش‌یافته» است)
`M{n}'
اجازه ندادن به بیش از n گذر بازگشتی برای یک قانون خاص؛ این گزینه شمارش کل حداکثر گذرها را تغییر نمی‌دهد، بنابراین فقط می‌تواند محدودیت سخت‌گیرانه‌تری را برای یک قانون خاص اعمال کند.

`:'
اعمال قانون تنها برای یک بار (پیش‌فرض بازگشتی است)
`@'
توقف اعمال قوانین در صورت تطبیق؛ قانون جاری همچنان به صورت بازگشتی اعمال می‌شود؛ جهت اعمال قانون جاری تنها برای یک بار و سپس توقف، با `:' ترکیب کنید.
`#'
توقف عملیات جاری در صورت تطبیق قانون، و صدور خطای `unwilling to perform' (عدم تمایل به انجام).
`G{n}'
پرش به میزان n قانون به جلو یا عقب (مراقب حلقه‌ها باشید!). توجه داشته باشید که `G{1}' به طور ضمنی در هر قانونی وجود دارد.
`I'
نادیده گرفتن خطاها در قانون؛ به این معنی که در صورت بروز خطا، مثلاً صادرشده توسط یک نگاشت، خطا به عنوان عدم تطبیق در نظر گرفته می‌شود. خطای `unwilling to perform' لغو نمی‌شود.
`U{n}'
استفاده از n به عنوان کد بازگشتی در صورت تطبیق قانون؛ این فلگ رفتار بازگشتی قانون را تغییر نمی‌دهد، بنابراین برای اجرای آن تنها برای یک بار، باید در ترکیب با `:' استفاده شود، به عنوان مثال `:U{32}' پس از دقیقاً یک بار اجرای قانون در صورت تطبیق الگو، مقدار `32' (نشان‌دهنده noSuchObject) را برمی‌گرداند. در نتیجه، رفتار آن معادل `@' است که کد بازگشتی آن روی n تنظیم شده باشد؛ یا به عبارت دیگر، `@' معادل `U{0}' است. کدهای خطای مثبت مجاز هستند که کدهای خطای مربوطه LDAP را همان‌گونه که در RFC4511 مشخص شده است نشان می‌دهند.

ترتیب قرارگیری فلگ‌ها می‌تواند حائز اهمیت باشد. به عنوان مثال: `IG{2}' یعنی خطاها را نادیده بگیر و چه در صورت تطبیق و چه در صورت خطا، دو خط به جلو بپر؛ در حالی که `G{2}I' یعنی خطاها را نادیده بگیر، اما تنها در صورت تطبیق دو خط به جلو بپر.

فلگ‌های بیشتر (عمدتاً فلگ‌های عملیات) بر حسب نیاز افزوده خواهند شد.

به regex(7) و/یا re_format(7) مراجعه کنید.

هر عبارتی که با `$' آغاز شود نیازمند جایگزینی است؛

تنها استثنای بدیهی `$$' است که به یک `$' منفرد تبدیل می‌شود؛

جایگزینی پایه به صورت `$<d>' است که در آن `<d>' یک رقم است؛ 0 نشان‌دهنده کل رشته است، در حالی که 1-9 یک زیرتطبیق است، همان‌گونه که در regex(7) و/یا re_format(7) شرح داده شده است.

علامت `$' که پس از آن `{' بیاید، یک جایگزینی پیشرفته را فراخوانی می‌کند. الگو به صورت زیر است:

`$' `{' [ <operator> ] <name> `(' <substitution> `)' `}'

که در آن <name> باید یک نام مجاز برای نگاشت باشد، یعنی:

<name> ::= [a-z][a-z0-9]* (غیرحساس به بزرگی و کوچکی حروف)
<operator> ::= `>' `|' `&' `&&' `*' `**' `$'

و <substitution> باید یک الگوی جایگزینی مجاز باشد، بدون هیچ محدودیتی در سطح تودرتویی.

عملگرها عبارتند از:

>
فراخوانی زیرزمینه؛ <name> باید یک نام زمینه بازنویسی مجاز و از پیش تعریف‌شده باشد
|
فراخوانی دستور خارجی؛ <name> باید به یک نام دستور مجاز و از پیش تعریف‌شده اشاره کند (هنوز پیاده‌سازی نشده است)
&
انتساب متغیر؛ <name> متغیری را در ساختار عملیات در حال اجرا تعریف می‌کند که بعداً می‌تواند ارجاع‌زدایی شود؛ عملگر & متغیری را در حوزه زمینه بازنویسی منتسب می‌کند؛ عملگر && متغیری را منتسب می‌کند که کل نشست را در بر می‌گیرد، به عنوان مثال مقدار آن می‌تواند بعداً توسط سایر زمینه‌های بازنویسی ارجاع‌زدایی شود
*
ارجاع‌زدایی متغیر؛ <name> باید به متغیری اشاره کند که برای عملیات جاری تعریف و منتسب شده است؛ عملگر * متغیری را در حوزه زمینه بازنویسی ارجاع‌زدایی می‌کند؛ عملگر ** متغیری را در حوزه کل نشست ارجاع‌زدایی می‌کند، به این معنی که مقدار آن در طول زمینه‌های بازنویسی منتقل می‌شود
$
ارجاع‌زدایی پارامتر؛ <name> باید به یک پارامتر موجود اشاره کند؛ ایده این است که برخی پارامترهای زمان اجرا که توسط سیستم تعیین شده‌اند در دسترس موتور بازنویسی قرار گیرند، مانند نام میزبان کلاینت، bind DN در صورت وجود، پارامترهای ثابتی که در زمان پیکربندی مقداردهی شده‌اند، و غیره؛ در حال حاضر هیچ پارامتری توسط back-ldap یا back-meta تنظیم نمی‌شود، اما پارامترهای ثابت را می‌توان در فایل پیکربندی با استفاده از دستورالعمل rewriteParam تعریف کرد.

اسکیپ کردن جایگزینی به نماد `$' واگذار شده است، که به جای `\' در الگوهای جایگزینی رشته استفاده می‌شود زیرا `\' از قبل توسط روتین‌های تجزیه سطح پایین slapd اسکیپ شده است؛ در نتیجه، اسکیپ کردن عبارت منظم به دو نماد `\' نیاز دارد، به عنوان مثال `.*\.foo\.bar' باید به صورت `.*\\.foo\\.bar' نوشته شود.

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

هر عملیات پایه‌ای سرور با یک زمینه بازنویسی مرتبط است؛ آن‌ها به دو گروه اصلی تقسیم می‌شوند: بازنویسی client -> server (کلاینت به سرور) و server -> client (سرور به کلاینت).

کلاینت به سرور (client -> server):

(default)            در صورت تعریف و عدم وجود زمینه خاص دیگر
bindDN               اتصال (bind)
searchDN             جستجو (search)
searchFilter         جستجو (search)
searchFilterAttrDN   جستجو (search)
compareDN            مقایسه (compare)
compareAttrDN        مقایسه مقادیر AVA
addDN                افزودن (add)
addAttrDN            افزودن AVA (به استثنای بخش DN از "ref")
modifyDN             تغییر (modify)
modifyAttrDN         تغییر AVA (به استثنای بخش DN از "ref")
referralAttrDN       افزودن/تغییر بخش DN ارجاعات
                     (پیش‌فرض بر روی none)
renameDN             دستور modrdn (شناسه DN قدیمی)
newSuperiorDN        دستور modrdn (شناسه DN والد جدید، در صورت وجود)
newRDN               دستور modrdn (شناسه RDN نسبی جدید)
deleteDN             حذف (delete)
exopPasswdDN         شناسه DN عملیات گسترش‌یافته تغییر گذرواژه

سرور به کلاینت (server -> client):

searchEntryDN        جستجو (فقط در صورت تعریف؛ بدون پیش‌فرض؛
                     روی DN مدخل‌های جستجو اعمال می‌شود)
searchAttrDN         جستجوی AVA (فقط در صورت تعریف؛ پیش‌فرض به
                     searchEntryDN؛ روی ویژگی‌های با نحو DN در
                     نتایج جستجو اعمال می‌شود)
matchedDN            تمام عملیات (فقط در صورت کاربرد؛ پیش‌فرض به
                     searchEntryDN)
referralDN           تمام عملیات (فقط در صورت کاربرد؛ پیش‌فرض به
                     none)

تمامی دستورالعمل‌های بازنویسی/نگاشت با پیشوند rwm- آغاز می‌شوند.

اگر `on' باشد، بازنویسی درخواستی انجام می‌شود؛ اگر `off' باشد، هیچ بازنویسی صورت نمی‌گیرد (روشی ساده برای متوقف کردن بازنویسی بدون تغییر بیش از حد فایل پیکربندی).
شناسه <Context name> نامی است که زمینه را مشخص می‌کند، یعنی نامی که توسط برنامه برای ارجاع به مجموعه قوانین موجود در آن استفاده می‌شود. همچنین برای ارجاع به زیرزمینه‌ها در بازنویسی رشته به کار می‌رود. یک زمینه می‌تواند نام مستعار زمینه دیگری باشد. در این حالت، زمینه دارای نام مستعار شامل هیچ قانونی نیست، و هر ارجاعی به آن به دسترسی به زمینه اصلی منجر خواهد شد.
مشخص می‌کند در صورت تطبیق الگو، رشته چگونه بازنویسی شود. مثال‌ها در ادامه آورده شده‌اند.

امکان تعریف نگاشتی را فراهم می‌کند که بازنویسی زیررشته را به چیزی دیگر تبدیل می‌نماید. این نگاشت درون الگوی جایگزینی یک قانون ارجاع داده می‌شود.
مقداری با حوزه سراسری تنظیم می‌کند که می‌تواند توسط دستور `${$paramName}' ارجاع‌زدایی شود.
حداکثر تعداد کل گذرهای بازنویسی را که می‌توان در یک عملیات بازنویسی انجام داد تنظیم می‌کند (برای جلوگیری از حلقه‌ها). یک مقدار پیش‌فرض ایمن روی 100 تنظیم شده است؛ توجه داشته باشید که رسیدن به این حد همچنان به عنوان موفقیت تلقی می‌شود؛ فراخوانی بازگشتی قوانین صرفاً متوقف می‌گردد. این شمارش برای کل عملیات بازنویسی اعمال می‌شود و نه برای یک قانون منفرد؛ یک محدودیت اختیاری به ازای هر قانون نیز می‌تواند تعیین شود. این حد با تنظیم محدودیت‌های خاص به ازای هر قانون از طریق فلگ `M{n}' لغو (override) می‌شود.

در حال حاضر، نگاشت‌های اندکی به صورت توکار (builtin) هستند اما انواع نگاشت بیشتری ممکن است در زمان اجرا ثبت شوند.

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

نگاشت LDAP با انجام یک جستجوی ساده LDAP، یک مقدار را گسترش می‌دهد. پیکربندی آن بر اساس یک URI الزامی است که بخش attrs آن باید دقیقاً شامل یک ویژگی باشد (برای دریافت DN یک مدخل از entryDN استفاده کنید). اگر از یک ویژگی چندمقداری استفاده شود، تنها اولین مقدار در نظر گرفته می‌شود.

پارامتر bindwhen تعیین می‌کند که چه زمانی اتصال برقرار شود. این پارامتر می‌تواند مقادیر now، later و everytime را بپذیرد که به ترتیب نشان‌دهنده آن است که اتصال باید در هنگام راه‌اندازی، در زمان نیاز، یا هر بار که استفاده می‌شود ایجاد گردد. در دو حالت اول، اتصال در حافظه موقت (cache) نگهداری می‌شود، در حالی که در حالت آخر هر بار از یک اتصال تازه استفاده می‌شود. این گزینه پیش‌فرض است.

پارامترهای binddn و credentials نشان‌دهنده DN و گذرواژه‌ای هستند که برای انجام یک اتصال ساده (simple bind) احرازهویت‌شده پیش از اجرای عملیات جستجو استفاده می‌شوند؛ در صورت عدم ارائه، از یک اتصال ناشناس (anonymous) استفاده می‌شود.

پارامتر version می‌تواند 2 یا 3 باشد تا نسخه پروتکل مورد استفاده را مشخص کند. پیش‌فرض 3 است.

نگاشت slapd با انجام یک جستجوی داخلی LDAP، یک مقدار را گسترش می‌دهد. پیکربندی آن بر اساس یک URI الزامی است که باید با ldap:/// شروع شود (یعنی باید یک URI از نوع LDAP باشد و نباید میزبانی در آن مشخص شده باشد). همانند نگاشت LDAP، بخش attrs باید دقیقاً شامل یک ویژگی باشد، و اگر از یک ویژگی چندمقداری استفاده شود، تنها مقدار اول در نظر گرفته می‌شود.
نگاشت escape امکان استفاده از DNها یا بخش‌هایی از آن‌ها را در رشته‌های فیلتر و برعکس فراهم می‌سازد. این نگاشت یک مقدار را بر اساس عملیات‌های فهرست‌شده به ترتیب پردازش می‌کند. عملیات‌های پشتیبانی‌شده شامل موارد زیر هستند:
رشته‌ای را دریافت کرده و آن را اسکیپ می‌کند تا بتوان آن را با امنیت در یک DN قرار داد
رشته‌ای را دریافت کرده و آن را اسکیپ می‌کند تا بتوان آن را با امنیت در یک فیلتر قرار داد
رشته‌ای را دریافت کرده و اسکیپ‌گذاری DN را خنثی می‌کند
رشته‌ای را دریافت کرده و اسکیپ‌گذاری فیلتر را خنثی می‌کند
توصیه می‌شود که هر نگاشت escape با یک عملیات escape به پایان برسد زیرا این تنها راه ایمن برای مدیریت رشته‌های دلخواه است.

# تنظیم روی `off' برای غیرفعال کردن بازنویسی
rwm-rewriteEngine on
# قواعدی که دستورالعمل "suffixmassage" اعمال می‌کند
rwm-rewriteEngine on
# تمام جریان داده از کلاینت به سرور با ارجاع به DNها
rwm-rewriteContext default
rwm-rewriteRule "(.+,)?<virtualnamingcontext>$" "$1<realnamingcontext>" ":"
# قانون فیلتر خالی
rwm-rewriteContext searchFilter
# تمام جریان داده از سرور به کلاینت
rwm-rewriteContext searchEntryDN
rwm-rewriteRule "(.+,)?<realnamingcontext>$" "$1<virtualnamingcontext>" ":"
rwm-rewriteContext searchAttrDN alias searchEntryDN
rwm-rewriteContext matchedDN alias searchEntryDN
# قواعد متفرقه خالی
rwm-rewriteContext referralAttrDN
rwm-rewriteContext referralDN
# هر آنچه اینجا تعریف شود به زمینه `default' می‌رود.
# این قانون بافت نام‌گذاری هر چیزی را که به `dc=home,dc=net' فرستاده شود
# به `dc=OpenLDAP, dc=org' تغییر می‌دهد
rwm-rewriteRule "(.+,)?dc=home,[ ]?dc=net$"
            "$1dc=OpenLDAP, dc=org"  ":"
# از آنجا که یک DN تمیز/نرمال‌شده شامل فاصله پس از
# جداکننده‌های rdn (مانند `,') نیست، این قانون کفایت می‌کند:
rwm-rewriteRule "(.+,)?dc=home,dc=net$"
            "$1dc=OpenLDAP,dc=org"  ":"
# شروع یک زمینه جدید (ورودی زمینه قبلی پایان می‌یابد).
# این قانون در صورت نبود فاصله بین بخش‌های DN، فاصله اضافه می‌کند.
rwm-rewriteContext  addBlanks
rwm-rewriteRule     "(.*),([^ ].*)" "$1, $2"
# این قانون فاصله‌ها را حذف می‌کند
rwm-rewriteContext  eatBlanks
rwm-rewriteRule     "(.*), (.*)" "$1,$2"
# اینجا کنترل به زمینه بازنویسی پیش‌فرض برمی‌گردد؛
# قوانین به موارد موجود ضمیمه می‌شوند.
# هر چیزی که به اینجا برسد به قانون `addBlanks' هدایت می‌شود
rwm-rewriteContext  default
rwm-rewriteRule     ".*" "${>addBlanks($0)}" ":"
# بازنویسی مبنای جستجو مطابق با قوانین `default'.
rwm-rewriteContext  searchDN alias default
# نتایج جستجو با DN اوپن‌ال‌دپ مجدداً با بافت نام‌گذاری
# `dc=home,dc=net' و با حذف فاصله‌ها بازنویسی می‌شوند.
rwm-rewriteContext  searchEntryDN
rwm-rewriteRule     "(.*[^ ],)?[ ]?dc=OpenLDAP,[ ]?dc=org$"
                "${>eatBlanks($1)}dc=home,dc=net"    ":"
# تبدیل مقدار DN به گونه‌ای که بتواند در یک فیلتر استفاده شود
rwm-rewriteMap escape dn2filter unescapedn escape2filter
# اتصال با ایمیل به جای DN کامل: ما ابتدا به یک نگاشت ldap نیاز داریم
# که ویژگی‌ها را به یک DN تبدیل کند (آرگومان مورد استفاده هنگام فراخوانی
# نگاشت به URI ضمیمه شده و به عنوان بخش فیلتر عمل می‌کند)
rwm-rewriteMap ldap attr2dn "ldap://host/dc=my,dc=org?dn?sub"
# سپس باید DN تشکیل‌شده از یک ایمیل واحد را شناسایی کنیم،
# مثلاً `mail=someone@example.com'؛ توجه داشته باشید که این قانون
# در صورت تطبیق، بازنویسی را متوقف می‌کند؛ در صورت بروز خطا،
# خطا نادیده گرفته می‌شود. در صورتی که بافت‌های نام‌گذاری مجازی را
# به واقعی نگاشت می‌کنیم، همچنین باید DNهای معمولی را بازنویسی کنیم،
# زیرا تعریف یک زمینه بازنویسی bindDN بر تعریف پیش‌فرض اولویت دارد.
#
# در حالی که آدرس‌های ایمیل واقعی معمولاً حاوی کاراکترهای ویژه فیلتر
# نیستند، Bind DN ارائه‌شده چنین محدودیتی ندارد.
rwm-rewriteContext bindDN
rwm-rewriteRule "^(mail=)([^,]+@[^,]+)$"
                "${attr2dn($1${dn2filter($2)})}" ":@I"
# این یک مثال نسبتاً پیشرفته است. این مثال فیلتر جستجو را در صورتی که
# انجام‌دهنده جستجو دارای امتیازات مدیریتی باشد، تغییر می‌دهد. ابتدا باید
# bind DN درخواست ورودی را ردیابی کنیم که در متغیری به نام `binddn'
# با حوزه نشست ذخیره می‌شود، و در جای خود باقی می‌ماند تا اتصال عادی امکان‌پذیر باشد:
rwm-rewriteContext  bindDN
rwm-rewriteRule     ".+" "${&&binddn($0)}$0" ":"
# فیلتر جستجوی حاوی `uid=' تنها در صورتی بازنویسی می‌شود
# که یک DN مناسب متصل (bind) شده باشد.
# برای انجام این کار، در اولین قانون، DN متصل‌شده ارجاع‌زدایی می‌شود،
# در حالی که فیلتر به یک پیشوند، مقدار AVA مربوط به `uid=<arg>'،
# و یک پسوند تجزیه می‌گردد. یک برچسب `<>' به DN افزوده می‌شود.
# اگر DN به مدخلی در زیردرخت `ou=admin' اشاره کند، فیلتر با اعمال OR بین
# `uid=<arg>' و `cn=<arg>' بازنویسی می‌شود؛ در غیر این صورت دست‌نخورده باقی می‌ماند.
# این می‌تواند برای مثال مفید باشد تا به ماژول auth_ldap-1.4 آپاچی امکان دهد
# کاربران را با هر دو `uid' و `cn' احراز هویت کند، اما تنها در صورتی که درخواست
# از جانب یک کاربر احتمالی `cn=Web auth,ou=admin,dc=home,dc=net' آمده باشد.
rwm-rewriteContext searchFilter
rwm-rewriteRule "(.*\\()uid=([a-z0-9_]+)(\\).*)"
  "${**binddn}<>${&prefix($1)}${&arg($2)}${&suffix($3)}"
  ":I"
rwm-rewriteRule "^[^,]+,ou=admin,dc=home,dc=net$"
  "${*prefix}|(uid=${*arg})(cn=${*arg})${*suffix}" ":@I"
rwm-rewriteRule ".*<>$" "${*prefix}uid=${*arg}${*suffix}" ":"
# این مثال نشان می‌دهد چگونه مقادیر ناخواسته ویژگی‌های با مقدار DN را
# از یک نتیجه جستجو حذف کنیم؛ قانون اول مقادیر DN زیر
# "ou=People,dc=example,dc=com" را مطابقت می‌دهد؛
# در صورت تطبیق، بازنویسی با موفقیت به پایان می‌رسد.
# قانون دوم هر چیز دیگری را تطبیق می‌دهد و باعث می‌شود مقدار رد شود.
rwm-rewriteContext searchEntryDN
rwm-rewriteRule ".+,ou=People,dc=example,dc=com$" "$0" ":@"
rwm-rewriteRule ".*" "" "#"

دستورالعمل‌های زیر کلاس شیء `groupOfNames' را به کلاس شیء `groupOfUniqueNames' و نوع ویژگی `member' را به نوع ویژگی `uniqueMember' نگاشت می‌کنند:

map objectclass groupOfNames groupOfUniqueNames
map attribute uniqueMember member

این مورد یک مجموعه ویژگی محدود از سرور خارجی را ارائه می‌دهد:

map attribute cn *
map attribute sn *
map attribute manager *
map attribute description *
map attribute *

این خطوط cn، sn، manager و description را به خودشان نگاشت می‌کنند، و هر ویژگی دیگری قبل از ارسال به کلاینت (یا ارسال به سرور LDAP) از شیء "حذف" می‌شود. این مسلماً یک مثال ساده است، اما مقصود را بیان می‌کند.

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

slapd.conf(5)، slapd-config(5)، slapd-ldap(5)، slapd-meta(5)، slapd-relay(5)، slapd(8)، regex(7)، re_format(7).

Pierangelo Masarati؛ بر اساس قابلیت‌های بازنویسی/نگاشت back-ldap توسط Howard Chu و Pierangelo Masarati.

2026/03/09 OpenLDAP 2.6.13