.lf 1 "-
.TH SLAPD.ACCESS 5 "2026/03/09" "OpenLDAP 2.6.13"
.\" Copyright 1998-2026 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply.  See COPYRIGHT/LICENSE.
.\" $OpenLDAP$
.SH "نام (NAME)"
slapd.access \- پیکربندی دسترسی برای slapd، دیمن مستقل LDAP
.SH "خلاصه دستور (SYNOPSIS)"
/etc/openldap/slapd.conf
.SH "توضیحات (DESCRIPTION)"
فایل 
.BR slapd.conf (5)
شامل اطلاعات پیکربندی برای دیمن
.BR slapd (8)
است. این فایل پیکربندی همچنین توسط ابزارهای SLAPD شامل
.BR slapacl (8)،
.BR slapadd (8)،
.BR slapauth (8)،
.BR slapcat (8)،
.BR slapdn (8)،
.BR slapindex (8)،
.BR slapmodify (8)
و
.BR slaptest (8)
استفاده می‌شود.
.LP
فایل
.B slapd.conf
شامل مجموعه‌ای از گزینه‌های پیکربندی سراسری است که بر
.B slapd
به‌طور کلی (شامل تمام بک‌اندها) اعمال می‌شود، و به دنبال آن صفر یا چند تعریف بک‌اند پایگاه‌داده می‌آید که شامل اطلاعات مختص به یک نمونه بک‌اند است.
.LP
قالب کلی
.B slapd.conf
به صورت زیر است:
.LP
.nf
    # 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
    ...
.fi
.LP
هم بخش پیکربندی سراسری و هم هر بخش مختص به بک‌اند می‌توانند شامل اطلاعات دسترسی باشند. دستورالعمل‌های کنترل دسترسیِ مختص به بک‌اند، با توجه به زمینه نام‌گذاری‌شان (naming context)، برای آن دسته از مدخل‌هایی استفاده می‌شوند که به آن بک‌اند تعلق دارند. در صورتی که هیچ دستورالعمل کنترل دسترسی برای یک بک‌اند تعریف نشده باشد یا موارد تعریف‌شده قابل اعمال نباشند، دستورالعمل‌های بخش پیکربندی سراسری به کار گرفته می‌شوند.
.LP
اگر هیچ کنترل دسترسی‌ای وجود نداشته باشد، خط‌مشی پیش‌فرض به همگان اجازه خواندن همه‌چیز را می‌دهد اما به‌روزرسانی‌ها را به rootdn محدود می‌سازد (مانند "access to * by * read").
.LP
هنگام کار با یک فهرست دسترسی، از آنجا که فهرست دسترسی سراسری عملاً به انتهای فهرست هر پایگاه‌داده ضمیمه می‌شود، در صورت خالی نبودن فهرست حاصل، فهرست دسترسی با یک دستورالعمل ضمنی
.B access to * by * none
پایان می‌یابد. اگر هیچ دستورالعمل دسترسی قابل اعمالی برای یک بک‌اند وجود نداشته باشد، خواندن پیش‌فرض (default read) اعمال می‌شود.
.LP
.B هشدار: rootdn همواره می‌تواند همه‌چیز را بخواند و بنویسد!
.LP
برای مدخل‌هایی که در هیچ بک‌اندی نگهداری نمی‌شوند (مانند یک root DSE)، دستورالعمل‌های سراسری استفاده می‌شوند.
.LP
آرگومان‌هایی که باید با متن واقعی جایگزین شوند درون براکت‌های <> نشان داده شده‌اند.
.SH "دستورالعمل دسترسی (THE ACCESS DIRECTIVE)"
ساختار دستورالعمل‌های کنترل دسترسی به صورت زیر است:
.TP
.B access to <what> "[ by <who> [ <access> ] [ <control> ] ]+"
اعطای دسترسی (مشخص‌شده با 
.BR <access> ) 
به مجموعه‌ای از مدخل‌ها و/یا صفت‌ها (مشخص‌شده با 
.BR <what> ) 
توسط یک یا چند درخواست‌کننده (مشخص‌شده با 
.BR <who> ).

.LP
فهرست‌های دستورالعمل‌های دسترسی به ترتیبی که در \fIslapd.conf\fP آمده‌اند ارزیابی می‌شوند.
هنگامی که یک بند
.B <what>
با داده‌ای که دسترسی به آن در حال ارزیابی است مطابقت کند، فهرست بندهای
.B <who>
آن بررسی می‌شود.
هنگامی که یک بند
.B <who>
با ویژگی‌های درخواست‌کننده دسترسی مطابقت کند، بندهای
.B <access>
و
.B <control>
آن ارزیابی می‌شوند.

.LP
بررسی کنترل دسترسی در اولین تطابق بندهای
.B <what>
و
.B <who>
متوقف می‌شود، مگر آنکه توسط بند
.B <control>
به‌گونه دیگری تعیین شده باشد.
هر فهرست بند
.B <who>
به‌طور ضمنی با یک بند
.LP
.nf
	by * none stop
.fi
.LP
.B <control>
خاتمه می‌یابد. این بند
.B <control>
ضمنی، ارزیابی دستورالعمل دسترسی را متوقف می‌کند و هیچ امتیاز دسترسی دیگری به فرد دیگری اعطا نمی‌شود.
برای اینکه ارزیابی دستورالعمل دسترسی تنها زمانی که هر دوی
.B <who>
و
.B <what>
تطابق یافتند متوقف شود، یک بند صریح
.LP
.nf
	by * break
.fi
.LP
را به انتهای فهرست بندهای
.B <who>
اضافه کنید.

.LP
هر فهرست بند
.B <what>
به‌طور ضمنی با بند
.LP
.nf
	access to *
		by * none
.fi
.LP
خاتمه می‌یابد که موجب عدم اعطای هرگونه امتیاز دسترسی به داده‌ای می‌شود که وضعیت آن مشخص نشده است.
.SH "فیلد <WHAT> (THE <WHAT> FIELD)"
فیلد
.BR <what>
موجودیتی را مشخص می‌کند که دستورالعمل کنترل دسترسی به آن اعمال می‌شود.
این فیلد می‌تواند قالب‌های زیر را داشته باشد:
.LP
.nf
	dn[.<dnstyle>]=<dnpattern>
	filter=<ldapfilter>
	attrs=<attrlist>[ val[/matchingRule][.<attrstyle>]=<attrval>]
.fi
.LP
همراه با
.LP
.nf
	<dnstyle>={{exact|base(object)}|regex
		|one(level)|sub(tree)|children}
	<attrlist>={<attr>|[{!|@}]<objectClass>}[,<attrlist>]
	<attrstyle>={{exact|base(object)}|regex
		|one(level)|sub(tree)|children}
.fi
.LP
عبارت
.B dn=<dnpattern>
مدخل‌ها را بر اساس زمینه نام‌گذاری‌شان (naming context) انتخاب می‌کند.
.B <dnpattern>
یک نمایش رشته‌ای از DN مدخل است.
نویسه عام
.B *
نشان‌دهنده تمام مدخل‌ها است و در صورتی که هیچ فرمی از
.B dn
داده نشده باشد، به صورت ضمنی در نظر گرفته می‌شود.
.LP
مشخصه 
.B <dnstyle> 
اختیاری است؛ با این حال، توصیه می‌شود برای جلوگیری از ابهام آن را مشخص کنید.
.B Base 
(مترادف
.BR baseObject )،
حالت پیش‌فرض،
یا
.B exact 
(نام مستعار 
.BR base )
نشان‌دهنده مدخلی است که DN آن برابر با
.BR <dnpattern>
باشد؛
.B one
(مترادف
.BR onelevel )
نشان‌دهنده تمام مدخل‌های بلافاصله در زیر
.BR <dnpattern>
است؛
.B sub
(مترادف
.BR subtree )
نشان‌دهنده تمام مدخل‌های موجود در زیردرخت در
.BR <dnpattern>
است؛
.B children
نشان‌دهنده تمام مدخل‌های زیر (تابعِ) 
.BR <dnpattern>
است.
.LP
اگر توصیف‌کننده
.B <dnstyle>
برابر با
.BR regex
باشد، آن‌گاه 
.B <dnpattern>
یک الگوی عبارت منظم POSIX (از نوع «extended») است، همان‌گونه که در
.BR regex (7)
و/یا
.BR re_format (7)
شرح داده شده است، که با یک نمایش رشته‌ای نرمال‌شده از DN مدخل تطابق می‌یابد.
قالب regex این الگو (هنوز) از UTF-8 پشتیبانی نمی‌کند.
.LP
عبارت
.B filter=<ldapfilter>
مدخل‌ها را بر اساس یک فیلتر معتبر LDAP، همان‌طور که در RFC 4515 توصیف شده است، انتخاب می‌کند.
اگر هیچ قالبی از
.B filter
داده نشده باشد، فیلتر
.B (objectClass=*)
به‌طور ضمنی در نظر گرفته می‌شود.
.LP
عبارت
.B attrs=<attrlist>
صفت‌هایی را انتخاب می‌کند که قاعده کنترل دسترسی به آن‌ها اعمال می‌شود.
این یک فهرست جداشده با کاما از انواع صفت‌ها به همراه نام‌های ویژه
.BR entry ،
نشان‌دهنده دسترسی به خود مدخل، و
.BR children ،
نشان‌دهنده دسترسی به فرزندان مدخل است. نام‌های ObjectClass نیز می‌توانند در این فهرست مشخص شوند که بر تمام صفت‌های الزامی و/یا مجاز توسط آن objectClass تأثیر می‌گذارند.
در واقع، نام‌های موجود در 
.B <attrlist>
که دارای پیشوند
.B @
هستند، مستقیماً به عنوان نام‌های objectClass در نظر گرفته می‌شوند. نامی که دارای پیشوند
.B !
باشد نیز به عنوان یک objectClass در نظر گرفته می‌شود، اما در این حالت قاعده دسترسی بر صفت‌هایی تأثیر می‌گذارد که توسط آن objectClass نه الزامی هستند و نه مجاز.
اگر هیچ فرمی از
.B attrs
داده نشود، 
.B attrs=@extensibleObject
به‌طور ضمنی در نظر گرفته می‌شود، یعنی تمام صفت‌ها را شامل می‌شود.
.LP
استفاده از قالب
.B attrs=<attr> val[/matchingRule][.<attrstyle>]=<attrval>
دسترسی به یک مقدار خاص از یک صفت منفرد را مشخص می‌کند.
در این حالت، تنها یک نوع صفت منفرد می‌تواند تعیین شود.
.B <attrstyle>
مقدار
.B exact
(پیش‌فرض) از قاعده تطابق برابری (equality matching rule) صفت برای مقایسه مقدار استفاده می‌کند، مگر آنکه یک قاعده تطابق متفاوت (و سازگار) مشخص شده باشد. اگر
.B <attrstyle>
برابر با
.BR regex
باشد، مقدار ارائه‌شده به عنوان یک الگوی عبارت منظم POSIX (از نوع «extended») استفاده می‌شود. اگر صفت دارای نحو DN باشد، 
.B <attrstyle>
می‌تواند هر یک از
.BR base ،
.BR onelevel ،
.B subtree
یا
.BR children
باشد که به ترتیب منجر به تطابق base، onelevel، subtree یا children می‌شود.
.LP
عبارت‌های dn، filter و attrs تجمیعی هستند؛ آن‌ها می‌توانند به صورت متوالی برای انتخاب موجودیت‌هایی که قاعده دسترسی به آن‌ها اعمال می‌شود، بر اساس زمینه نام‌گذاری، مقدار و نوع صفت به‌طور هم‌زمان استفاده شوند.
زیرتطابق‌های حاصل از تطابق
.B regex
می‌توانند در فیلد
.B <who>
با استفاده از نحو
.IR ${v<n>} ،
که در آن
.I <n>
شماره زیرتطابق است، مورد ارجاع قرار گیرند.
نحو پیش‌فرض،
.IR $<n> ،
در واقع یک نام مستعار برای
.IR ${d<n>}
است که متناظر با ارجاع به زیرتطابق‌های حاصل از بخش
.B dnpattern
در فیلد
.B <what>
می‌باشد.
.SH "بخش <WHO> (THE <WHO> FIELD)"
فیلد
.B <who>
مشخص می‌کند که قوانین دسترسی برای چه کسانی اعمال می‌شوند.
چندین عبارت
.B <who>
می‌توانند در یک دستور کنترل دسترسی قرار گیرند، که بیانگر امتیازات دسترسی متفاوت به یک منبع یکسان برای دسترسی‌گیرندگان مختلف است.
این فیلد می‌تواند به اشکال زیر باشد:
.LP
.nf
	*
	anonymous
	users
	self[.<selfstyle>]

	dn[.<dnstyle>[,<modifier>]]=<DN>
	dnattr=<attrname>

	realanonymous
	realusers
	realself[.<selfstyle>]

	realdn[.<dnstyle>[,<modifier>]]=<DN>
	realdnattr=<attrname>

	group[/<objectclass>[/<attrname>]]
		[.<groupstyle>]=<group>
	peername[.<peernamestyle>]=<peername>
	sockname[.<style>]=<sockname>
	domain[.<domainstyle>[,<modifier>]]=<domain>
	sockurl[.<style>]=<sockurl>
	set[.<setstyle>]=<pattern>

	ssf=<n>
	transport_ssf=<n>
	tls_ssf=<n>
	sasl_ssf=<n>

	dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]
.fi
.LP
با مقادیر:
.LP
.nf
	<style>={exact|regex|expand}
	<selfstyle>={level{<n>}}
	<dnstyle>={{exact|base(object)}|regex
		|one(level)|sub(tree)|children|level{<n>}}
	<groupstyle>={exact|expand}
	<peernamestyle>={<style>|ip|ipv6|path}
	<domainstyle>={exact|regex|sub(tree)}
	<setstyle>={exact|expand}
	<modifier>={expand}
	<name>=aci		<pattern>=<attrname>]
.fi
.LP
این موارد ممکن است به‌صورت ترکیبی مشخص شوند.
.LP
.nf
.fi
.LP
نویسه عام (wildcard)
.B *
به همه اشاره دارد.
.LP
کلیدواژه‌های دارای پیشوند
.B real
مانند همتاهای بدون پیشوند خود عمل می‌کنند؛ با این تفاوت که بررسی به ترتیب با DN \fIاحراز هویت\fP و DN \fIمجوزدهی\fP انجام می‌گیرد.
.LP
کلیدواژه
.B anonymous
بدین معناست که دسترسی به کلاینت‌های احراز هویت‌نشده اعطا می‌شود؛ این کلیدواژه بیشتر برای محدود کردن دسترسی کلاینت‌های احراز هویت‌نشده به منابع احراز هویت (مانند مشخصه
.BR userPassword )
جهت اهداف احراز هویت به کار می‌رود.
.LP
کلیدواژه
.B users
بدین معناست که دسترسی به کلاینت‌های احراز هویت‌شده اعطا می‌شود.
.LP
کلیدواژه
.B self
بدین معناست که دسترسی به یک مدخل برای خود همان مدخل مجاز است (برای مثال، مدخلی که مورد دسترسی قرار می‌گیرد و مدخل درخواست‌کننده باید یکسان باشند).
این کلیدواژه امکان استفاده از شیوه
.B level{<n>}
را فراهم می‌کند، که در آن \fI<n>\fP مشخص می‌کند کدام نیا (ancestor) از DN باید در تطابق‌ها استفاده شود.
یک مقدار مثبت نشان می‌دهد که <n>-امین نیای DN کاربر باید در نظر گرفته شود؛ یک مقدار منفی نشان می‌دهد که <n>-امین نیای هدف باید در نظر گرفته شود.
برای مثال، یک عبارت "\fIby self.level{1} ...\fP" زمانی تطابق می‌یابد که شیء "\fIdc=example,dc=com\fP" توسط "\fIcn=User,dc=example,dc=com\fP" مورد دسترسی قرار گیرد.
یک عبارت "\fIby self.level{-1} ...\fP" زمانی تطابق می‌یابد که همان کاربر به شیء "\fIou=Address Book,cn=User,dc=example,dc=com\fP" دسترسی پیدا کند.
.LP
دستور
.B dn=<DN>
بدین معناست که دسترسی به DN منطبق اعطا می‌شود.
توصیف‌کننده اختیاری شیوه
.B dnstyle
همان گزینه‌های فرم dn در فیلد
.B <what>
را ارائه می‌دهد. علاوه بر این، شیوه
.B regex
می‌تواند از جایگزینی زیررشته حاصل از زیرتطابق‌ها در عبارت dn.regex مربوط به
.B <what>
با استفاده از فرم
.BR $<digit> ،
که در آن
.B digit
عددی در بازه 0 تا 9 است (که در آن 0 با کل رشته تطابق دارد)، یا فرم
.BR ${<digit>+} ،
برای زیرتطابق‌های بزرگ‌تر از 9 بهره ببرد.
جایگزینی زیررشته از مقدار مشخصه می‌تواند با استفاده از فرم
.BR ${v<digit>+}
انجام شود.
از آنجا که نویسه دلار برای نشان دادن جایگزینی زیررشته به کار می‌رود، نویسه دلاری که برای نشان دادن تطابق تا انتهای رشته استفاده می‌شود باید با یک نویسه دلار دوم گریز داده شود (escape شود)، مانند:
.LP
.nf
    access to dn.regex="^(.+,)?uid=([^,]+),dc=[^,]+,dc=com$"
        by dn.regex="^uid=$2,dc=[^,]+,dc=com$$" write
.fi
.LP
توصیف‌کننده شیوه امکان داشتن یک
.B modifier
اختیاری را فراهم می‌کند. در حال حاضر، تنها نوع مجاز
.BR expand
است، که باعث می‌شود جایگزینی زیررشته حاصل از زیرتطابق‌ها حتی زمانی که
.B dnstyle
از نوع
.B regex
نیست رخ دهد.
توجه داشته باشید که
.B dnstyle
از نوع
.B regex
در مثال بالا تنها در صورتی ممکن است مفید باشد که عبارت
.B <by>
نیاز داشته باشد یک regex باشد؛ در غیر این صورت، اگر مقدار بخش دوم (از سمت راست)
.B dc=
از DN در مثال بالا ثابت بود، فرم
.LP
.nf
    access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
        by dn.exact,expand="uid=$2,dc=example,dc=com" write
.fi
.LP
می‌توانست استفاده شود؛ و اگر لازم بود با مقدار موجود در عبارت
.B <what>
تطابق یابد، فرم
.LP
.nf
    access to dn.regex="^(.+,)?uid=([^,]+),dc=([^,]+),dc=com$"
        by dn.exact,expand="uid=$2,dc=$3,dc=com" write
.fi
.LP
می‌توانست به کار رود.
.LP
فرم‌های دیگری از عبارت
.B <what>
به‌جز regex نیز می‌توانند زیرتطابق‌ها را ارائه دهند. فرم‌های
.BR base(object) ،
.BR sub(tree) ،
.BR one(level)
و
.B children
مقدار
.B $0
را به‌عنوان تطابق کل رشته ارائه می‌دهند.
فرم‌های
.BR sub(tree) ،
.BR one(level)
و
.B children
همچنین
.B $1
را به‌عنوان تطابق راست‌ترین بخش DN همان‌طور که در عبارت
.B <what>
تعریف شده، ارائه می‌کنند.
این قابلیت ممکن است به‌عنوان مثال برای اعطای دسترسی به تمامی نیاکان یک کاربر با تعریف زیر مفید باشد:
.LP
.nf
    access to dn.subtree="dc=com"
        by dn.subtree,expand="$1" read
.fi
.LP
که بدین معناست تنها دسترسی به مدخل‌هایی که در DN عبارت
.B <by>
ظاهر می‌شوند مجاز است.
.LP
فرم
.B level{<n>}
یک توسعه و تعمیم از فرم
.B onelevel
است که با تمام DNهایی که <n>-امین نیاکان آن‌ها الگو است تطابق می‌یابد.
بنابراین، \fIlevel{1}\fP معادل با \fIonelevel\fP و \fIlevel{0}\fP معادل با \fIbase\fP است.
.LP
اعطای هرگونه امتیاز دسترسی به DNای که دقیقاً با
.B rootdn
پایگاه‌داده‌ای که ACLها برای آن اعمال می‌شوند تطابق دارد کاملاً بی‌فایده است، زیرا این DN به‌طور ضمنی دارای امتیاز نوشتن برای کل درخت آن پایگاه‌داده است.
در واقع، کنترل دسترسی برای
.B rootdn
دور زده می‌شود (bypassed) تا مسئله ذاتی «مرغ و تخم‌مرغ» حل شود.
.LP
دستور
.B dnattr=<attrname>
بدین معناست که دسترسی به درخواست‌هایی اعطا می‌شود که DN آن‌ها در مشخصه
.B <attrname>
از مدخلی که به آن دسترسی پیدا می‌شود فهرست شده باشد.
.LP
دستور
.B group=<group>
بدین معناست که دسترسی به درخواست‌هایی اعطا می‌شود که DN آن‌ها در مدخل گروهی که DN آن توسط
.B <group>
مشخص شده است، فهرست شده باشد.
پارامترهای اختیاری
.B <objectclass>
و
.B <attrname>
کلاس شیء (objectClass) و نوع مشخصه (attributeType) عضو مربوط به مدخل گروه را تعیین می‌کنند. مقادیر پیش‌فرض به ترتیب
.B groupOfNames
و
.B member
هستند.
توصیف‌کننده اختیاری شیوه
.B <style>
می‌تواند
.B expand
باشد، به این معنی که
.B <group>
به‌عنوان یک رشته جایگزین (اما نه به‌عنوان یک عبارت باقاعده) طبق
.BR regex (7)
و/یا
.BR re_format (7)
بسط می‌یابد، و
.BR exact ،
به این معنی که تطابق دقیق استفاده خواهد شد.
اگر شیوه بخش DN در عبارت
.B <what>
از نوع regex باشد، زیرتطابق‌ها طبق
.BR regex (7)
و/یا
.BR re_format (7)
در دسترس قرار می‌گیرند؛ سایر شیوه‌ها زیرتطابق‌های محدودی را مطابق آنچه در بالا درباره فرم DN از عبارت
.B <by>
بحث شد ارائه می‌دهند.
.LP
برای گروه‌های ایستا (static groups)، نوع مشخصه تعیین‌شده باید دارای نحو
.B DistinguishedName
یا
.B NameAndOptionalUID
باشد. برای گروه‌های پویا (dynamic groups) نوع مشخصه باید یک زیرنوع از نوع مشخصه
.B labeledURI
باشد. تنها URIهای LDAP به فرم
.B ldap:///<base>??<scope>?<filter>
تنها از طریق جستجو در سرور محلی، در یک گروه پویا ارزیابی خواهند شد.
.LP
دستورات
.BR peername=<peername> ،
.BR sockname=<sockname> ،
.BR domain=<domain>
و
.B sockurl=<sockurl>
بدین معنا هستند که IP میزبان متصل‌شونده (به فرم
.B "IP=<ip>:<port>"
برای IPv4، یا
.B "IP=[<ipv6>]:<port>"
برای IPv6)
یا نام فایل لوله نام‌گذاری‌شده (named pipe) میزبان متصل‌شونده (به فرم
.B "PATH=<path>"
در صورت اتصال از طریق یک لوله نام‌گذاری‌شده) برای
.BR peername ،
نام فایل لوله نام‌گذاری‌شده برای
.BR sockname ،
نام میزبان متصل‌شونده برای
.BR domain
و URL متصل‌شونده برای
.B sockurl
جهت تعیین دسترسی با
.B pattern
مقایسه می‌شوند.
همان قوانین
.B style
برای تطابق الگو که برای حالت
.B group
شرح داده شد اعمال می‌شوند، به‌علاوه شیوه
.B regex
که به معنای
.B expand
زیرتطابق و تطابق regex پارامترهای اتصال مربوطه است.
شیوه
.B exact
در عبارت
.B <peername>
(حالت پیش‌فرض) مستلزم تطابق دقیق با حساسیت به بزرگی و کوچکی حروف روی
.B IP
کلاینت، شامل پیشوند
.B "IP="
و
.B ":<port>"
پایانی، یا
.B path
کلاینت، شامل پیشوند
.B "PATH="
در صورت اتصال از طریق لوله نام‌گذاری‌شده است.
شیوه ویژه
.B ip
الگو را به‌صورت
.B <peername>=<ip>[%<mask>][{<n>}]
تفسیر می‌کند، که در آن
.B <ip>
و
.B <mask>
نمایش رقمی نقطه‌دار از IP و ماسک هستند، در حالی که
.BR <n> ،
محصور در پرانتزهای شکسته، یک درگاه اختیاری است.
همین موضوع برای آدرس‌های IPv6 در هنگام استفاده از شیوه ویژه
.B ipv6
نیز صدق می‌کند.
هنگام بررسی امتیازات دسترسی، بخش IP از
.B peername
استخراج شده، پیشوند
.B "IP="
و بخش
.B ":<port>"
حذف می‌گردند، و پس از اعمال ماسک با
.BR <mask> ،
با بخش
.B <ip>
از الگو مقایسه می‌شود:
\fI((peername & <mask>) == <ip>)\fP.
به‌عنوان مثال،
.B peername.ip=127.0.0.1
و
.B peername.ipv6=::1
تنها اتصالات از localhost را مجاز می‌دانند،
.B peername.ip=192.168.1.0%255.255.255.0
اتصالات از هر IP در دامنه کلاس C با نشانی 192.168.1 را مجاز می‌کند، و
.B peername.ip=192.168.1.16%255.255.255.240{9009}
تنها در صورتی که درگاه 9009 استفاده شود، اتصالات از هر IP در محدوده 192.168.1.[16-31] از همان دامنه را مجاز می‌سازد.
شیوه ویژه
.B path
هنگام اتصال از طریق یک لوله نام‌گذاری‌شده، پیشوند
.B "PATH="
را از
.B peername
حذف کرده و یک تطابق دقیق روی الگوی داده‌شده انجام می‌دهد.
عبارت
.B <domain>
همچنین شیوه
.B subtree
را مجاز می‌داند، که زمانی موفق می‌شود که یک نام کاملاً واجد شرایط (FQDN) دقیقاً با الگوی
.B domain
تطابق یابد، یا بخش انتهایی آن، پس از یک
.BR نقطه ،
دقیقاً با الگوی
.B domain
مطابقت داشته باشد.
شیوه
.B expand
مجاز است، که متضمن تطابق
.B exact
همراه با بسط زیرتطابق است؛ استفاده از
.B expand
به‌عنوان یک اصلاح‌کننده شیوه مناسب‌تر در نظر گرفته می‌شود.
به‌عنوان مثال،
.B domain.subtree=example.com
با www.example.com تطابق می‌یابد، اما با www.anotherexample.com تطابق نخواهد یافت.
مقدار
.B domain
میزبان متصل‌شونده با انجام جستجوی معکوس DNS تعیین می‌شود.
از آنجا که این جستجو به‌راحتی می‌تواند جعل (spoof) شود، استفاده از دستور
.B domain
اکیداً منع می‌شود. به‌طور پیش‌فرض، جستجوهای معکوس غیرفعال هستند.
توصیف‌کننده اختیاری
.B domainstyle
در عبارت
.B <domain>
گزینه
.B modifier
را مجاز می‌داند؛ تنها مقداری که در حال حاضر پشتیبانی می‌شود
.B expand
است که باعث می‌شود جایگزینی زیررشته حاصل از زیرتطابق‌ها حتی زمانی که
.B domainstyle
از نوع
.B regex
نیست صورت گیرد، بسیار شبیه به کاربرد متناظر در عبارت
.BR <dn> .
.LP
دستور
.B set=<pattern>
هنوز مستندسازی نشده است.
.LP
دستور
.B dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]
بدین معناست که بررسی دسترسی به روش تعریف‌شده توسط مدیر که توسط
.B <name>
مشخص شده واگذار می‌شود، که می‌تواند در زمان اجرا با استفاده از دستور
.B moduleload
ثبت گردد.
فیلدهای
.BR <options> ،
.B <dynstyle>
و
.B <pattern>
اختیاری هستند و مستقیماً به روال تجزیه ثبت‌شده ارسال می‌شوند.
قابلیت Dynacl آزمایشی است؛ و باید در زمان کامپایل فعال شود.
.LP
دستور
.B dynacl/aci[=<attrname>]
بدین معناست که کنترل دسترسی توسط مقادیر موجود در
.B attrname
از خود مدخل تعیین می‌شود.
مقدار اختیاری
.B <attrname>
مشخص می‌کند کدام نوع مشخصه (attributeType) اطلاعات ACI را در مدخل نگهداری می‌کند.
به‌طور پیش‌فرض، مشخصه عملیاتی
.B OpenLDAPaci
استفاده می‌شود.
قابلیت ACIها آزمایشی است؛ و باید در زمان کامپایل فعال شود.
.LP
دستورات
.BR ssf=<n> ،
.BR transport_ssf=<n> ،
.BR tls_ssf=<n>
و
.B sasl_ssf=<n>
حداقل ضریب استحکام امنیتی (Security Strength Factor یا ssf) مورد نیاز برای اعطای دسترسی را تعیین می‌کنند. این مقدار باید یک عدد صحیح مثبت باشد.
.SH "بخش <ACCESS> (THE <ACCESS> FIELD)"
فیلد اختیاری
.B <access> ::= [[real]self]{<level>|<priv>}
سطح دسترسی یا امتیازات دسترسی خاصی را تعیین می‌کند که فیلد
.B who 
خواهد داشت.
اجزای آن به صورت زیر تعریف می‌شوند:
.LP
.nf
	<level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage
	<priv> ::= {=|+|\-}{0|d|x|c|s|r|{w|a|z}|m}+
.fi
.LP
تعدیل‌کننده
.B self
عملیات خاصی مانند داشتن یک سطح دسترسی یا امتیاز خاص را فقط در صورتی مجاز می‌سازد که عملیات شامل نام کاربری باشد که درخواست دسترسی داده است.
این امر دلالت بر مجاز بودن (authorized) کاربری دارد که درخواست دسترسی می‌کند.
تعدیل‌کننده
.B realself
به DN احراز هویت‌شده (authenticated DN) در مقابل DN مجازِ (authorized DN) تعدیل‌کننده
.B self
اشاره دارد.
یک مثال، دسترسی
.B selfwrite
به ویژگی member در یک گروه است، که به فرد اجازه می‌دهد DN خود را به فهرست اعضای یک گروه اضافه یا از آن حذف کند، در حالی که مجاز به تأثیرگذاری روی سایر اعضا نیست.
.LP
مدل دسترسی
.B level 
بر تفسیر افزایشی امتیازات دسترسی تکیه دارد.
سطوح ممکن عبارتند از:
.BR none ،
.BR disclose ،
.BR auth ،
.BR compare ،
.BR search ،
.BR read ،
.BR write ،
و
.BR manage .
هر سطح دسترسی شامل تمام سطوح ماقبل خود نیز می‌شود؛ بنابراین 
.B manage
تمام دسترسی‌ها از جمله دسترسی مدیریتی را اعطا می‌کند. این دسترسی
برخی تغییرات را مجاز می‌کند که در غیر این صورت توسط مدل داده LDAP یا طرح‌واره (schema) دایرکتوری ممنوع می‌بود، به عنوان مثال تغییر
objectclass ساختاری یک مدخل، یا تغییر یک ویژگی عملیاتی
که به صورت غیرقابل تغییر توسط کاربر تعریف شده است.
دسترسی 
.BR write
در واقع ترکیبی از
.BR add
و
.BR delete
است، که به ترتیب امتیاز نوشتن را به افزودن یا حذف
.BR <what>
مشخص‌شده محدود می‌کنند.

.LP
سطح دسترسی
.B none 
هرگونه دسترسی، از جمله افشا در صورت بروز خطا (disclosure on error) را غیرمجاز می‌کند.
.LP
سطح دسترسی
.B disclose
اجازه افشای اطلاعات در هنگام بروز خطا را می‌دهد.
.LP
سطح دسترسی
.B auth
بدین معنی است که فرد صرفاً برای انجام عملیات احراز هویت/مجوزدهی (مانند
.BR bind )
مجاز به دسترسی به یک ویژگی است، بدون هیچ دسترسی دیگری.
این مورد برای اعطای کمترین سطح دسترسی ممکن به کلاینت‌های احراز هویت‌نشده به منابع حیاتی، مانند گذرواژه‌ها، مفید است.
.LP
مدل دسترسی
.B priv
بر تنظیم صریح امتیازات دسترسی برای هر بند تکیه دارد.
علامت
.B =
دسترسی‌های از پیش تعریف‌شده را بازنشانی می‌کند؛ در نتیجه، امتیازات دسترسی نهایی تنها مواردی خواهد بود که توسط این بند تعیین شده است.
علامت‌های
.B +
و
.B \-
امتیازات دسترسی را به موارد موجود اضافه کرده یا از آن‌ها کم می‌کنند.
امتیازات عبارتند از:
.B m
برای manage،
.B w
برای write،
.B a
برای add،
.B z
برای delete،
.B r
برای read،
.B s 
برای search،
.B c 
برای compare،
.B x
برای authentication، و
.B d
برای disclose.
بیش از یکی از امتیازات فوق را می‌توان در یک عبارت اضافه کرد.
.B 0
نشان‌دهنده عدم وجود هیچ امتیازی است و فقط به تنهایی استفاده می‌شود (مثلاً +0).
توجه داشته باشید که
.B +az
معادل
.BR +w
است.
.LP
اگر هیچ دسترسی داده نشود، به طور پیش‌فرض
.BR +0
خواهد بود.
.SH "بخش <CONTROL> (THE <CONTROL> FIELD)"
فیلد اختیاری
.B <control>
جریان اعمال قواعد دسترسی را کنترل می‌کند.
می‌تواند دارای یکی از اشکال زیر باشد:
.LP
.nf
	stop
	continue
	break
.fi
.LP
که در آن
.BR stop ،
حالت پیش‌فرض، به این معنی است که در صورت تطابق، بررسی دسترسی متوقف می‌شود.
دو شکل دیگر برای ادامه پردازش بندهای دسترسی استفاده می‌شوند.
به طور دقیق‌تر، شکل
.B continue
امکان بررسی سایر بندهای
.B <who>
را در همان بند
.B <access>
فراهم می‌سازد، به طوری که ممکن است به تغییر تدریجی امتیازات منجر شوند، در حالی که شکل
.B break
امکان پردازش سایر بندهای
.B <access>
که با همان هدف تطابق دارند را می‌دهد.
این مثال (ساده‌لوحانه) را در نظر بگیرید:
.LP
.nf
	access to dn.subtree="dc=example,dc=com" attrs=cn
		by * =cs break

	access to dn.subtree="ou=People,dc=example,dc=com"
		by * +r
.fi
.LP
که به همه افراد زیر درخت "dc=example,dc=com" امتیازات search و compare را می‌دهد، در حالی که قاعده دوم دسترسی read را نیز در زیردرخت "ou=People" مجاز می‌کند،
یا این مثال (حتی ساده‌لوحانه‌تر):
.LP
.nf
	access to dn.subtree="dc=example,dc=com" attrs=cn
		by * =cs continue
		by users +r
.fi
.LP
که به همه امتیازات search و compare را اعطا کرده و امتیازات read را به کلاینت‌های احراز هویت‌شده اضافه می‌کند.
.LP
یک کاربرد مفید، اعطای آسان امتیازات write به یک
.B updatedn
است که با
.BR rootdn
تفاوت دارد.
در این حالت، از آنجا که
.B updatedn
به (تقریباً) همه داده‌ها دسترسی write نیاز دارد، می‌توان از
.LP
.nf
	access to *
		by dn.exact="cn=The Update DN,dc=example,dc=com" write
		by * break
.fi
.LP
به عنوان اولین قاعده دسترسی استفاده کرد.
در نتیجه، مگر اینکه عملیات با هویت
.B updatedn
انجام شود، کنترل مستقیماً به قواعد بعدی واگذار می‌شود.

.SH "نیازمندی‌های عملیات (OPERATION REQUIREMENTS)"
عملیات‌ها به امتیازات متفاوتی بر روی بخش‌های مختلف مدخل‌ها نیاز دارند.
خلاصه زیر برای بک‌اند اصلی پایگاه داده MDB صدق می‌کند. نیازمندی‌ها
برای سایر بک‌اندها ممکن است (و اغلب اوقات) تفاوت داشته باشد.

.LP
عملیات
.B add
نیازمند امتیازات
.B add (=a)
بر روی شبه‌ویژگی 
.B entry
از مدخلی است که اضافه می‌شود، و امتیازات
.B add (=a)
بر روی شبه‌ویژگی
.B children
از والد مدخل.
هنگام اضافه کردن مدخل پسوند (suffix entry) یک پایگاه داده،
دسترسی
.B add
به
.B children
از DN خالی ("") مورد نیاز است. همچنین اگر
بررسی ACL محتوای Add روی پایگاه داده پیکربندی شده باشد (صفحه راهنمای
.BR slapd.conf (5)
یا
.BR slapd\-config (5)
را ببینید)،
.B add (=a)
بر روی تمامی ویژگی‌هایی که اضافه می‌شوند مورد نیاز خواهد بود.

.LP
عملیات 
.B bind
هنگامی که اعتبارنامه‌ها در دایرکتوری ذخیره شده‌اند، نیازمند امتیازات 
.B auth (=x)
بر روی ویژگی که اعتبارنامه‌ها در آن ذخیره شده‌اند (معمولاً
.BR userPassword )
است.

.LP
عملیات
.B compare
به امتیازات 
.B compare (=c)
بر روی ویژگی مورد مقایسه نیاز دارد.

.LP
عملیات
.B delete
نیازمند امتیازات
.B delete (=z)
بر روی شبه‌ویژگی
.B entry 
از مدخل در حال حذف، و امتیازات
.B delete (=d)
بر روی شبه‌ویژگی
.B children
از والد مدخل است.

.LP
عملیات
.B modify
نیازمند امتیازات 
.B write (=w)
بر روی ویژگی‌های در حال تغییر است.
به طور مشخص، 
.B add (=a)
برای افزودن مقادیر جدید،
.B delete (=z)
برای حذف مقادیر موجود،
و هر دو مورد
.B delete
و
.BR "add (=az)" ،
یا
.BR "write (=w)" ،
برای جایگزینی مقادیر موجود مورد نیاز هستند.

.LP
عملیات
.B modrdn
نیازمند امتیازات
.B write (=w)
بر روی شبه‌ویژگی
.B entry
از مدخلی است که DN نسبی آن در حال تغییر است،
امتیازات
.B delete (=z)
بر روی شبه‌ویژگی
.B children
از والدین مدخل قدیمی،
امتیازات
.B add (=a)
بر روی شبه‌ویژگی
.B children
از والدین مدخل جدید، و
امتیازات
.B add (=a)
بر روی ویژگی‌هایی که در DN نسبی جدید وجود دارند.
همچنین در صورتی که
.B deleteoldrdn
بر روی 1 تنظیم شده باشد، امتیازات
.B Delete (=z)
بر روی ویژگی‌های موجود در DN نسبی قدیمی مورد نیاز خواهد بود.

.LP
عملیات
.B search
نیازمند امتیازات 
.B search (=s)
بر روی شبه‌ویژگی 
.B entry
از searchBase است
(نکته: این مورد با OpenLDAP 2.4 معرفی شد).
سپس، برای هر مدخل، به امتیازات
.B search (=s)
بر روی ویژگی‌هایی که در فیلتر تعریف شده‌اند نیاز دارد.
مدخل‌های حاصل در نهایت برای امتیازات 
.B read (=r)
بر روی شبه‌ویژگی
.B entry
(برای دسترسی خواندن به خود مدخل)
و برای دسترسی
.B read (=r)
بر روی هر مقدار از هر ویژگی که درخواست شده است، بررسی می‌شوند.
همچنین، برای هر شیء
.B referral
که در ایجاد ارجاعات ادامه‌دار (continuation references) استفاده می‌شود، عملیات نیازمند دسترسی
.B read (=r)
بر روی شبه‌ویژگی
.B entry
(برای دسترسی خواندن به خود شیء referral)،
و همچنین دسترسی
.B read (=r)
به ویژگی نگهدارنده اطلاعات ارجاع
(معمولاً ویژگی
.BR ref )
است.

.LP
برخی عملیات داخلی و برخی
.B controls
نیازمند امتیازات دسترسی خاصی هستند.

.LP
نگاشت SASL
.B authzID
و کنترل LDAP
.B proxyAuthz
نیازمند امتیازات
.B auth (=x)
بر روی تمامی ویژگی‌هایی هستند که در فیلتر جستجوی نگاشت‌های regexp در URI (سمت راست دستورهای
.BR authz-regexp )
وجود دارند.
همچنین امتیازات
.B Auth (=x)
بر روی ویژگی
.B authzTo
از هویت اجازه‌دهنده (authorizing identity) و/یا بر روی ویژگی
.B authzFrom
از هویت مجازشده (authorized identity) مورد نیاز است.
در هر دو حالت، این هویت اجازه‌دهنده است که نیازمند امتیازات است
(یعنی هویتی که احراز هویت شده و اکنون سعی دارد با استفاده از مجوزهای موجودیتی دیگر عملیاتی انجام دهد).

.LP
به طور کلی، هنگامی که یک جستجوی داخلی برای مقاصد احراز هویت یا مجوزدهی انجام می‌شود، امتیازات مختص جستجو (نیازمندی‌های دسترسی برای عملیات جستجو که در بالا شرح داده شد را ببینید) به
.BR auth
تخفیف می‌یابند.

.LP
کنترل دسترسی برای جستجوی مدخل‌ها توسط frontend بررسی می‌شود،
بنابراین توسط تمامی بک‌اندها به طور کامل رعایت می‌گردد؛ برای تمامی عملیات دیگر
و برای مرحله کشف در عملیات جستجو،
معناشناسی کامل ACL تنها توسط بک‌اندهای اصلی، یعنی
.BR slapd\-mdb (5)
پشتیبانی می‌شود.

برخی بک‌اندهای دیگر، مانند
.BR slapd\-sql (5)،
ممکن است به طور کامل از آن‌ها پشتیبانی کنند؛ سایر بک‌اندها ممکن است تنها بخشی از معناشناسی توصیف‌شده را پشتیبانی کنند، یا حتی در برخی جنبه‌ها تفاوت داشته باشند.
جزئیات مرتبط در صفحات راهنمای اختصاصی هر بک‌اند شرح داده شده است.

.SH "هشدارها (CAVEATS)"
اکیداً توصیه می‌شود که مناسب‌ترین
.B <dnstyle>
را به طور صریح در بندهای
.B <what>
و
.B <who>
به کار ببرید، تا از مشخص‌سازی‌های احتمالاً نادرست قوانین دسترسی و همچنین به دلایل کارایی (اجتناب از تطبیق غیرضروری regex در صورتی که یک تطابق دقیق کفایت می‌کند) جلوگیری شود.
.LP
یک مدیر ممکن است قاعده‌ای به این شکل ایجاد کند:
.LP
.nf
	access to dn.regex="dc=example,dc=com"
		by ...
.fi
.LP
با این انتظار که با تمام مدخل‌ها در زیردرخت "dc=example,dc=com" تطابق یابد.
اما این قاعده در واقع با هر DN که در هر جای خود شامل زیررشته "dc=example,dc=com" باشد تطبیق می‌یابد. به این معنی که قاعده با هر دو مورد
"uid=joe,dc=example,dc=com" و "dc=example,dc=com,uid=joe" مطابقت دارد.
.LP
برای تطبیق زیردرخت مورد نظر، قاعده باید با دقت بیشتری نوشته شود:
.LP
.nf
	access to dn.regex="^(.+,)?dc=example,dc=com$"
		by ...
.fi
.LP
به دلایل کارایی، بهتر است از سبک subtree استفاده شود.
.LP
.nf
	access to dn.subtree="dc=example,dc=com"
		by ...
.fi
.LP
هنگام نوشتن قواعد زیرتطابق (submatch)، ممکن است اجتناب از استفاده غیرضروری از
.B <dnstyle>
نوع
.B regex
مفید باشد؛ برای نمونه، جهت اعطای دسترسی به زیردرخت کاربری که با بند
.B <what>
تطابق دارد، می‌توان از مورد زیر استفاده کرد:
.LP
.nf
	access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
		by dn.regex="^uid=$2,dc=example,dc=com$$" write
		by ...
.fi
.LP
با این حال، از آنجا که تمام آنچه در بند
.B <by>
مورد نیاز است انبساط زیررشته است، یک راه‌حل کارآمدتر عبارت است از:
.LP
.nf
	access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
		by dn.exact,expand="uid=$2,dc=example,dc=com" write
		by ...
.fi
.LP
در واقع، در حالی که مقدار
.B regex
برای
.B <dnstyle>
به معنای انبساط زیررشته است،
.BR exact ،
و همچنین تمام مقادیر دیگر
.B <dnstyle>
مختص DN چنین نیستند، بنابراین باید صراحتاً درخواست شود.
.LP
.SH "فایل‌ها (FILES)"
.TP
/etc/openldap/slapd.conf
فایل پیکربندی پیش‌فرض slapd
.SH "همچنین ببینید (SEE ALSO)"
.BR slapd (8),
.BR slapd\-* (5),
.BR slapacl (8),
.BR regex (7),
.BR re_format (7)
.LP
"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin)
.SH "قدردانی‌ها (ACKNOWLEDGEMENTS)"
.lf 1 "./../Project
.\" Shared Project Acknowledgement Text
.B "نرم‌افزار OpenLDAP"
توسط پروژه OpenLDAP در <http://www.openldap.org> توسعه یافته و نگهداری می‌شود.
.B "نرم‌افزار OpenLDAP"
از انتشار LDAP 3.3 دانشگاه میشیگان برگرفته شده است.
.lf 1213 "-