SUDOERS.LDAP(5) فایلهای پیکربندی SUDOERS.LDAP(5)

sudoers.ldap - پیکربندی دسترسیهای sudoers در سرویس LDAP

پرونده sudoers.ldap ساختار و نحوه واکشی و نگهداری قوانین و مجوزهای دسترسی دستور sudo را در دایرکتوری متمرکز LDAP شرح میدهد.

علاوه بر فایل استاندارد sudoers، دستور sudo می‌تواند از طریق LDAP نیز پیکربندی شود. این قابلیت به‌ویژه برای همگام‌سازی sudoers در یک محیط توزیع‌شده و بزرگ بسیار سودمند است.

استفاده از LDAP برای sudoers مزایای متعددی دارد:

•
دستور sudo دیگر نیازی به خواندن تمام و کمال فایل sudoers ندارد. هنگام استفاده از LDAP، در هر بار اجرای دستور تنها دو یا سه پرس‌وجوی LDAP انجام می‌شود. این امر اجرای آن را بسیار سریع کرده و استفاده از آن را در محیط‌های مبتنی بر LDAP بهینه می‌سازد.
•
امکان تعیین گزینه‌ها به ازای هر ورودی مشخص وجود دارد که گزینه‌های پیش‌فرض سراسری را بازنویسی (override) می‌کنند. فایل /etc/sudoers تنها از گزینه‌های پیش‌فرض و گزینه‌های محدودی در ارتباط با کاربران، میزبان‌ها، دستورات و نام‌های مستعار پشتیبانی می‌کند. سینتکس آن پیچیده است و درک آن برای کاربران دشوار است. قرار دادن گزینه‌ها مستقیماً درون خود ورودی بسیار طبیعی‌تر است.
•
دیگر نیازی به برنامه visudo نیست. برنامه visudo قفل‌گذاری و بررسی سینتکس فایل /etc/sudoers را فراهم می‌کند. از آنجا که به‌روزرسانی‌ها در LDAP به صورت اتمیک (تراکنشی) هستند، قفل‌گذاری دیگر لزومی ندارد. همچنین از آنجا که ساختار نحوی هنگام درج داده‌ها در LDAP بررسی می‌شود، نیازی به ابزار اختصاصی برای بررسی سینتکس نخواهد بود.

پیکربندی sudoers درون ظرف (کانتینر) LDAP با نام ‘ou=SUDOers’ نگهداری می‌شود.

دستور sudo ابتدا به دنبال ورودی ‘cn=defaults’ در کانتینر SUDOers می‌گردد. در صورت یافت شدن، صفت چندمقداره sudoOption دقیقاً مشابه با یک خط سراسری Defaults در فایل /etc/sudoers تجزیه و تحلیل می‌شود. در مثال زیر، متغیر محیطی SSH_AUTH_SOCK برای تمامی کاربران در محیط اجرا حفظ خواهد شد:

dn: cn=defaults,ou=SUDOers,dc=my-domain,dc=com
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here
sudoOption: env_keep+=SSH_AUTH_SOCK

معادل یک مدخل sudoer در LDAP، یک شیء sudoRole است. این شیء شامل صفت‌های زیر می‌باشد:

یک نام کاربری، شناسه کاربری (با پیشوند ‘#’)، نام یا شناسه گروه یونیکس (به ترتیب با پیشوند ‘%’ یا ‘%#’)، نت‌گروپ کاربر (با پیشوند ‘+’)، یا نام یا شناسه گروه غیر یونیکسی (به ترتیب با پیشوند ‘%:’ یا ‘%:#’). تطبیق نت‌گروپ‌های کاربر تنها با استفاده از اعضای کاربر و دامنه صورت می‌گیرد؛ عضو میزبان هنگام تطبیق استفاده نمی‌شود. پشتیبانی از گروه‌های غیر یونیکسی تنها زمانی در دسترس است که یک group_plugin مناسب در شیء سراسری defaults در sudoRole تعریف شده باشد. اگر یک ورودی sudoUser با علامت تعجب (‘!’) شروع شود و آن ورودی تطبیق یابد، کل sudoRole مربوطه نادیده گرفته خواهد شد. ورودی‌های نفی‌شده sudoUser تنها در نسخه ۱.۹.۹ یا بالاتر پشتیبانی می‌شوند.
یک نام میزبان، آدرس IP، شبکه IP، یا نت‌گروپ میزبان (با پیشوند ‘+’). مقدار ویژه ALL با هر میزبانی تطبیق پیدا می‌کند. نت‌گروپ‌های میزبان تنها با استفاده از اعضای میزبان (هم با نام کامل و هم بدون دامنه) و دامنه مطابقت داده می‌شوند؛ عضو کاربر در هنگام تطبیق به کار نمی‌رود. اگر یک ورودی sudoHost با علامت تعجب (‘!’) شروع شود و تطبیق یابد، آن sudoRole نادیده گرفته می‌شود. ورودی‌های نفی‌شده sudoHost تنها از نسخه ۱.۸.۱۸ یا بالاتر پشتیبانی می‌شوند.
یک نام دستور یونیکسی با مسیر کامل به همراه آرگومان‌های اختیاری خط فرمان، احتمالاً شامل نویسه‌های الگو (وایلدکارت‌ها). اگر نام دستور با علامت تعجب (‘!’) شروع شود، کاربر از اجرای آن دستور منع خواهد شد.

دستور توکار “sudoedit” برای اجازه دادن به کاربر جهت اجرای sudo با گزینه -e (یا به عنوان sudoedit) به کار می‌رود. این دستور مانند یک دستور معمولی می‌تواند آرگومان‌های خط فرمان بپذیرد. برخلاف سایر دستورات، “sudoedit” درون خود sudo تعبیه شده است و باید بدون مسیر ابتدایی مشخص شود.

مقدار ویژه ALL با هر دستوری تطبیق می‌یابد.

اگر نام یک دستور با یک چکیده رمزنقاری SHA-2 پیشوند شده باشد، اجرای دستور تنها در صورتی مجاز خواهد بود که چکیده هش آن مطابقت داشته باشد. این ویژگی ممکن است در شرایطی مفید باشد که کاربری که sudo را اجرا می‌کند به خود دستور یا دایرکتوری والد آن دسترسی نوشتن داشته باشد. قالب‌های چکیده زیر پشتیبانی می‌شوند: sha224، sha256، sha384 و sha512. نام چکیده باید به دنبال یک دونقطه (‘:’) و سپس خود چکیده به صورت هگزادسیمال یا base64 بیاید. برای نمونه با مقدار زیر برای sudoCommand:

sha224:0GomF8mNN3wlDt1HD9XldjJ3SNgpFdbjO1+NsQ /bin/ls

کاربر تنها در صورتی می‌تواند /bin/ls را اجرا کند که چکیده sha224 آن با مقدار مشخص‌شده یکسان باشد. چکیده‌های دستور تنها از نسخه ۱.۸.۷ به بعد پشتیبانی می‌شوند.

از نظر عملکردی مشابه با گزینه‌های سراسری توصیف‌شده در بالا است، اما مختص به همان sudoRole می‌باشد که در آن تعریف شده است.
یک نام کاربری یا شناسه کاربری (با پیشوند ‘#’) که دستورات می‌توانند در قالب آن اجرا شوند، یا یک گروه یونیکس (با پیشوند ‘%’) یا نت‌گروپ کاربر (با پیشوند ‘+’) شامل فهرستی از کاربرانی که دستورات می‌توانند در قالب آن‌ها اجرا گردند. مقدار ویژه ALL با هر کاربری تطبیق می‌یابد. اگر یک ورودی sudoRunAsUser با علامت تعجب (‘!’) آغاز شود و تطبیق پیدا کند، آن sudoRole نادیده گرفته خواهد شد. اگر sudoRunAsUser مشخص شده ولی خالی باشد، با کاربر فراخواننده تطبیق داده می‌شود. اگر هیچ‌کدام از sudoRunAsUser و sudoRunAsGroup وجود نداشته باشند، مقدار sudoOption با نام runas_default استفاده می‌شود (پیش‌فرض root است).

صفت sudoRunAsUser تنها در نسخه ۱.۷.۰ و بالاتر sudo در دسترس است. نسخه‌های قدیمی‌تر sudo به جای آن از صفت sudoRunAs استفاده می‌کردند. ورودی‌های نفی‌شده sudoRunAsUser تنها در نسخه ۱.۸.۲۶ یا بالاتر پشتیبانی می‌شوند.

یک گروه یونیکس یا شناسه گروه (با پیشوند ‘#’) که دستورات می‌توانند تحت آن گروه اجرا شوند. مقدار ویژه ALL با هر گروهی تطبیق پیدا می‌کند. اگر یک ورودی sudoRunAsGroup با علامت تعجب (‘!’) آغاز شده و تطبیق یابد، آن sudoRole نادیده گرفته خواهد شد.

صفت sudoRunAsGroup تنها در نسخه ۱.۷.۰ و بالاتر sudo در دسترس است. ورودی‌های نفی‌شده sudoRunAsGroup تنها در نسخه ۱.۸.۲۶ یا بالاتر پشتیبانی می‌شوند.

یک برچسب زمانی به قالب ‘yyyymmddHHMMSSZ’ که می‌تواند برای تعیین زمان و تاریخ آغاز معتبر شدن sudoRole به کار رود. اگر چند ورودی sudoNotBefore وجود داشته باشد، زودترین آن‌ها استفاده می‌شود. برچسب‌های زمانی باید در قالب ساعت هماهنگ جهانی (UTC) باشند و نه منطقه زمانی محلی. بخش‌های دقیقه و ثانیه اختیاری هستند، اما برخی کارگزارهای LDAP بر خلاف RFC الزام دارند که حتماً قید شوند.

صفت sudoNotBefore تنها در نسخه ۱.۷.۵ و بالاتر sudo در دسترس است و باید صراحتاً از طریق گزینه SUDOERS_TIMED در فایل /etc/openldap/ldap.conf فعال شده باشد.

یک برچسب زمانی به قالب ‘yyyymmddHHMMSSZ’ که تاریخ/زمان انقضا را مشخص می‌کند، و پس از آن تاریخ sudoRole دیگر معتبر نخواهد بود. اگر چند ورودی sudoNotAfter وجود داشته باشد، آخرین مورد استفاده خواهد شد. برچسب‌های زمانی باید در قالب ساعت هماهنگ جهانی (UTC) باشند و نه زمان محلی. بخش‌های دقیقه و ثانیه اختیاری هستند، اما برخی سرورهای LDAP حضور آن‌ها را الزامی می‌دانند.

صفت sudoNotAfter تنها در نسخه ۱.۷.۵ و بالاتر sudo در دسترس است و باید صراحتاً از طریق گزینه SUDOERS_TIMED در /etc/openldap/ldap.conf فعال گردد.

ورودی‌های sudoRole دریافت‌شده از دایرکتوری LDAP هیچ ترتیب ذاتی و پیش‌فرضی ندارند. صفت sudoOrder یک عدد صحیح (یا در سرورهایی که پشتیبانی می‌کنند عدد اعشاری) است که برای مرتب‌سازی ورودی‌های منطبق استفاده می‌شود. این صفت به ورودی‌های sudoers مبتنی بر LDAP اجازه می‌دهد رفتار فایل sudoers را با دقت بیشتری تقلید کنند، جایی که ترتیب خطوط بر نتیجه تاثیر می‌گذارد. اگر چندین ورودی تطبیق پیدا کنند، ورودی با بالاترین صفت sudoOrder انتخاب می‌شود. این متناظر با رفتار «آخرین تطبیق» (last match) در فایل sudoers است. اگر صفت sudoOrder وجود نداشته باشد، مقدار ۰ در نظر گرفته می‌شود.

صفت sudoOrder تنها در نسخه‌های ۱.۷.۵ و بالاتر sudo موجود است.

هر صفت ذکرشده در بالا باید شامل یک مقدار واحد باشد، اما ممکن است چندین نمونه از هر نوع صفت در یک شیء وجود داشته باشد. یک sudoRole باید حداقل شامل یکی از هر صفت‌های sudoUser، sudoHost و sudoCommand باشد.

مثال زیر به کاربران گروه wheel اجازه می‌دهد هر دستوری را بر روی هر میزبانی از طریق sudo اجرا کنند:

dn: cn=%wheel,ou=SUDOers,dc=my-domain,dc=com
objectClass: top
objectClass: sudoRole
cn: %wheel
sudoUser: %wheel
sudoHost: ALL
sudoCommand: ALL

هنگام جستجوی یک sudoer با استفاده از LDAP، در هر فراخوانی تنها دو یا سه پرس‌وجوی LDAP انجام می‌شود. پرس‌وجوی اول برای تجزیه گزینه‌های سراسری است. پرس‌وجوی دوم برای تطبیق دادن با نام کاربر و گروه‌هایی است که کاربر به آن‌ها تعلق دارد. (تگ ویژه ALL نیز در همین پرس‌وجو بررسی می‌شود.) اگر هیچ تطبیقی برای نام کاربر و گروه‌هایش یافت نشد، پرس‌وجوی سوم تمام ورودی‌های حاوی نت‌گروپ‌های کاربر و سایر گروه‌های غیر یونیکسی را برمی‌گرداند و بررسی می‌کند که آیا کاربر عضو هیچ‌یک از آن‌ها است یا خیر.

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

اگر پارامتر NETGROUP_BASE حضور داشته باشد و NETGROUP_QUERY غیرفعال نشده باشد (بخش پیکربندی ldap.conf در ادامه را ببینید)، پرس‌وجوهایی برای تعیین فهرست نت‌گروپ‌هایی که کاربر قبل از پرس‌وجوی sudoers به آن‌ها تعلق دارد اجرا می‌شود. این امر باعث می‌شود بتوان نت‌گروپ‌ها را نیز همانند گروه‌های یونیکس در رشته پرس‌وجوی اصلی sudoers گنجاند. پرس‌وجوی سوم ذکرشده در بالا انجام نمی‌شود مگر اینکه یک افزونه تامین‌کننده گروه نیز پیکربندی شده باشد. پرس‌وجوهای واقعی LDAP که توسط sudo انجام می‌شوند به شرح زیر هستند:

1.
تطبیق تمامی رکوردهای nisNetgroup با یک nisNetgroupTriple حاوی کاربر، میزبان و دامنه NIS. پرس‌وجو رکوردهای nisNetgroupTriple را با نام میزبان کوتاه، نام کامل، یا بدون مشخص بودن نام میزبان در تاپل مطابقت می‌دهد. اگر دامنه NIS تعیین شده باشد، پرس‌وجو تنها رکوردهایی را مطابقت می‌دهد که شامل دامنه باشند یا هیچ دامنه‌ای در آن‌ها وجود نداشته باشد. اگر دامنه NIS تنظیم نشده باشد، یک نویسه عمومی (wildcard) برای تطبیق با هر نام دامنه‌ای استفاده می‌شود، اما توجه داشته باشید که طرحواره NIS در برخی سرورهای LDAP ممکن است از وایلدکارت‌ها برای nisNetgroupTriple پشتیبانی نکند.
2.
پرس‌وجوهای مکرر برای یافتن رکوردهای تودرتوی nisNetgroup با ورودی memberNisNetgroup که به رکوردی اشاره دارند که قبلاً تطبیق یافته است، اجرا می‌شوند.

برای سازمان‌هایی با تعداد زیادی نت‌گروپ، استفاده از NETGROUP_BASE می‌تواند زمان اجرای sudo را به طور چشمگیری کاهش دهد، مشروط بر اینکه سرور LDAP از پرس‌وجوی شیء nisNetgroup بر اساس صفت nisNetgroupTriple پشتیبانی نماید.

یکی از تفاوت‌های عمده میان LDAP و فایل sudoers معمولی این است که در LDAP، نام‌های مستعار (Aliases) اختصاصی sudo پشتیبانی نمی‌شوند.

در بیشتر موارد، نیاز چندانی به نام‌های مستعار اختصاصی sudo وجود ندارد. گروه‌های یونیکس، گروه‌های غیر یونیکسی (از طریق group_plugin)، یا نت‌گروپ‌های کاربری می‌توانند به جای User_Aliases و Runas_Aliases استفاده شوند. نت‌گروپ‌های میزبان می‌توانند به جای Host_Aliases استفاده گردند. از آنجا که گروه‌ها و نت‌گروپ‌ها نیز می‌توانند در LDAP ذخیره شوند، نیاز واقعی به نام‌های مستعار ویژه sudo وجود ندارد.

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

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

یک مثال در زیر آمده است:

# /etc/sudoers:
# Allow all commands except shell
johnny  ALL=(root) ALL,!/bin/sh
# Always allows all commands because ALL is matched last
puddles ALL=(root) !/bin/sh,ALL
# LDAP equivalent of johnny
# Allows all commands except shell
dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
objectClass: sudoRole
objectClass: top
cn: role1
sudoUser: johnny
sudoHost: ALL
sudoCommand: ALL
sudoCommand: !/bin/sh
# LDAP equivalent of puddles
# Notice that even though ALL comes last, it still behaves like
# role1 since the LDAP code assumes the more paranoid configuration
dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
objectClass: sudoRole
objectClass: top
cn: role2
sudoUser: puddles
sudoHost: ALL
sudoCommand: !/bin/sh
sudoCommand: ALL

ابزار cvtsudoers(1) می‌تواند برای تبدیل میان sudoers مبتنی بر فایل و مبتنی بر LDAP استفاده شود. با این حال، ویژگی‌هایی در sudoers مبتنی بر فایل وجود دارد که هیچ معادلی در sudoers مبتنی بر LDAP ندارند (و برعکس). این ویژگی‌ها را نمی‌توان به صورت خودکار تبدیل نمود.

برای نمونه، یک Cmnd_Alias در فایل sudoers ممکن است به یک sudoRole تبدیل شود که شامل چندین دستور است. کاربران و/یا گروه‌های متعددی می‌توانند به آن sudoRole اختصاص داده شوند.

همچنین، مقادیر Defaults مبتنی بر میزبان، کاربر، runas و دستور پشتیبانی نمی‌شوند. با این وجود، یک sudoRole می‌تواند شامل یک یا چند صفت sudoOption باشد که معمولاً می‌توانند همان هدف را محقق کنند.

خطوط زیر از sudoers را در نظر بگیرید:

Cmnd_Alias PAGERS = /usr/bin/more, /usr/bin/pg, /usr/bin/less
Defaults!PAGERS noexec
alice, bob ALL = ALL

در این مثال، alice و bob مجاز به اجرای تمامی دستورات هستند، اما دستورات فهرست‌شده در PAGERS دارای فلگ noexec خواهند بود تا از گریز به شل (shell escape) جلوگیری شود.

هنگام تبدیل این پیکربندی به LDAP، می‌توان از دو شیء sudoRole استفاده کرد:

dn: cn=PAGERS,ou=SUDOers,dc=my-domain,dc=com
objectClass: top
objectClass: sudoRole
cn: PAGERS
sudoUser: alice
sudoUser: bob
sudoHost: ALL
sudoCommand: /usr/bin/more
sudoCommand: /usr/bin/pg
sudoCommand: /usr/bin/less
sudoOption: noexec
sudoOrder: 900
dn: cn=ADMINS,ou=SUDOers,dc=my-domain,dc=com
objectClass: top
objectClass: sudoRole
cn: ADMINS
sudoUser: alice
sudoUser: bob
sudoHost: ALL
sudoCommand: ALL
sudoOrder: 100

در نسخه LDAP، از صفت sudoOrder استفاده شده تا اطمینان حاصل شود که sudoRole مربوط به PAGERS با گزینه noexec اولویت دارد. برخلاف نسخه sudoers، نسخه LDAP مستلزم آن است که تمامی کاربرانی که محدودیت باید روی آن‌ها اعمال شود، صراحتاً به sudoRole با نام PAGERS منتسب شوند. استفاده از یک گروه یونیکس یا نت‌گروپ در PAGERS به جای فهرست کردن تک‌تک کاربران، نگهداری آن را آسان‌تر می‌کند.

مدخل‌های Defaults به ازای هر کاربر را می‌توان با استفاده از یک یا چند صفت sudoOption در یک sudoRole شبیه‌سازی کرد. خطوط زیر در sudoers را در نظر بگیرید:

User_Alias ADMINS = john, sally
Defaults:ADMINS !authenticate
ADMINS ALL = (ALL:ALL) ALL

در این مثال، john و sally مجاز به اجرای هر دستوری در قالب هر کاربر یا گروهی هستند.

هنگام تبدیل به LDAP، می‌توانیم به جای User_Alias از یک گروه یونیکس استفاده کنیم:

dn: cn=admins,ou=SUDOers,dc=my-domain,dc=com
objectClass: top
objectClass: sudoRole
cn: admins
sudoUser: %admin
sudoHost: ALL
sudoRunAsUser: ALL
sudoRunAsGroup: ALL
sudoCommand: ALL
sudoOption: !authenticate

این پیکربندی فرض می‌کند که کاربران john و sally عضو گروه یونیکسی “admins’ هستند.

به منظور استفاده از پشتیبانی LDAP در sudo، طرحواره (اسکیما) sudo باید روی سرور LDAP شما نصب شود. علاوه بر این، حتماً اطمینان حاصل کنید که صفت sudoUser ایندکس‌گذاری شده باشد.

توزیع sudo شامل نسخه‌هایی از طرحواره sudoers برای سرورهای مختلف LDAP است:

مایکروسافت اکتیو دایرکتوری (Microsoft Active Directory)
سرور دایرکتوری آی‌بی‌ام (IBM Directory Server)، همچنین شناخته‌شده با نام‌های IBM Tivoli Directory Server، IBM Security Directory Server، و IBM Security Verify Directory
سرورهای مشتق‌شده از نت‌اسکیپ مانند سرورهای دایرکتوری iPlanet، Oracle و 389 Directory Server
سرور OpenLDAP slapd نسخه ۲.۳ و بالاتر زمانی که پیکربندی برخط (on-line) فعال است
سرور OpenLDAP slapd و OpenBSD ldapd

طرحواره در قالب OpenLDAP در بخش مثال‌ها (EXAMPLES) نیز آورده شده است.

دستور sudo فایل /etc/openldap/ldap.conf را برای پیکربندی‌های اختصاصی LDAP می‌خواند. معمولاً این فایل بین کلاینت‌های مختلف سازگار با LDAP به اشتراک گذاشته می‌شود. به این ترتیب، بیشتر تنظیمات اختصاصی sudo نیستند. فایل /etc/openldap/ldap.conf مستقیماً توسط خود sudo تجزیه می‌شود و ممکن است از گزینه‌هایی پشتیبانی کند که با گزینه‌های شرح داده‌شده در راهنمای سیستم ldap.conf(5) متفاوت باشد. مسیر ldap.conf می‌تواند از طریق آرگومان افزونه ldap_conf در فایل sudo.conf(5) بازنویسی شود.

در سیستم‌هایی که از کتابخانه‌های OpenLDAP استفاده می‌کنند، مقادیر پیش‌فرض مشخص‌شده در /etc/openldap/ldap.conf یا فایل‌های .ldaprc کاربر استفاده نمی‌شوند.

دستور sudo از پیاده‌سازی‌های مختلف کتابخانه LDAP پشتیبانی می‌کند، از جمله OpenLDAP، کتابخانه‌های مشتق از Netscape (که در Solaris و HP-UX نیز استفاده می‌شوند)، و IBM LDAP (معروف به Tivoli). برخی گزینه‌ها مختص پیاده‌سازی‌های خاصی از LDAP هستند یا رفتار وابسته به پیاده‌سازی دارند. این تفاوت‌ها در ادامه در بخش‌های مربوطه ذکر شده‌اند.

تنها گزینه‌هایی که صراحتاً در /etc/openldap/ldap.conf به عنوان موارد پشتیبانی‌شده توسط sudo فهرست شده‌اند مورد استفاده قرار می‌گیرند. گزینه‌های پیکربندی در ادامه با حروف بزرگ آمده‌اند اما به صورت غیرحساس به بزرگی و کوچکی حروف تجزیه می‌شوند.

خطوطی که با علامت هش (‘#’) آغاز می‌شوند نادیده گرفته خواهند شد. فاصله‌های خالی ابتدای خطوط حذف می‌شوند.

پارامتر BIND_TIMELIMIT مدت زمان (به ثانیه) انتظار در حین تلاش برای اتصال به یک سرور LDAP را مشخص می‌کند. اگر چندین URI یا HOST تعیین شده باشد، این زمان مدت انتظاری است که قبل از رفتن به سرور بعدی در فهرست اعمال می‌شود.
پارامتر BINDDN هویت مورد نظر برای انجام عملیات LDAP را در قالب یک نام متمایز (DN) تعیین می‌کند. اگر مشخص نشود، عملیات LDAP با هویت ناشناس (anonymous) انجام می‌شود. به طور پیش‌فرض، اکثر سرورهای LDAP دسترسی ناشناس را مجاز می‌دانند.
پارامتر BINDPW گذرواژه مورد استفاده هنگام انجام عملیات LDAP را تعیین می‌کند. این گزینه معمولاً همراه با پارامتر BINDDN به کار می‌رود. مقدار secret می‌تواند یک گذرواژه متنی ساده یا یک رشته کدگذاری‌شده با Base64 دارای پیشوند “base64:” باشد. برای مثال:
BINDPW base64:dGVzdA==

اگر از گذرواژه متنی ساده استفاده شود، باید یک رشته ساده بدون کوتیشن باشد. گذرواژه‌های متنی ساده نباید شامل نویسه کامنت (‘#’) باشند و اسکیپ کردن نویسه‌های خاص با بک‌اسلش (‘\’) پشتیبانی نمی‌شود.

نحوه ارجاع‌زدایی نام‌های مستعار (alias dereferencing) در هنگام جستجو را مشخص می‌کند. توضیح کامل این گزینه را در راهنمای ldap.conf(5) ببینید.
اگر هیچ URI مشخص نشده باشد (به پایین مراجعه کنید)، پارامتر HOST فهرستی از سرورهای LDAP که با فاصله از هم جدا شده‌اند را برای اتصال مشخص می‌سازد. هر میزبان می‌تواند شامل یک پورت اختیاری باشد که با دونقطه (‘:’) جدا می‌شود. پارامتر HOST منسوخ شده و تعیین URI توصیه می‌شود و تنها برای سازگاری با نسخه‌های پیشین حفظ شده است.
مسیر حافظه پنهان گواهی کربروس ۵ (Kerberos 5 credential cache) جهت استفاده هنگام احراز هویت با سرور راه دور.

این گزینه تنها هنگام استفاده از احراز هویت SASL کاربرد دارد (به پایین مراجعه کنید).

نسخه پروتکل LDAP برای اتصال به سرور. مقدار پیش‌فرض، پروتکل نسخه ۳ است.
پایه DN برای انجام پرس‌وجوهای نت‌گروپ LDAP. معمولاً برای دامنه my-domain.com به صورت ‘ou=netgroup,dc=my-domain,dc=com’ است. می‌توان چندین خط NETGROUP_BASE تعیین کرد، که در این صورت با همان ترتیبی که مشخص شده‌اند پرس‌وجو می‌شوند.

هنگامی که این گزینه فعال باشد، sudo به هنگام تطبیق نت‌گروپ‌های موجود در یک sudoRole به جای اتکا به تابع innetgr() در کتابخانه C، مستقیماً از سرور LDAP پرس‌وجو می‌کند.

علاوه بر این، اگر پارامتر NETGROUP_QUERY (که به طور پیش‌فرض فعال است) غیرفعال نشده باشد، نت‌گروپ‌های کاربر مستقیماً از طریق LDAP برای استفاده در پرس‌وجوی اصلی sudoers استعلام می‌شوند. این روش معمولاً بسیار سریع‌تر از دریافت تک‌تک اشیاء sudoRole شامل sudoUser با پیشوند ‘+’ و سپس بررسی عضویت کاربر در هر کدام از آن‌ها است. طرحواره NIS مورد استفاده در برخی سرورهای LDAP نیاز به اصلاحی دارد تا از پرس‌وجوی شیء nisNetgroup بر اساس صفت nisNetgroupTriple پشتیبانی کند. برای مثال، slapd در OpenLDAP نیازمند تغییر زیر در صفت nisNetgroupTriple می‌باشد:

attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple'
   DESC 'Netgroup triple'
   EQUALITY caseIgnoreIA5Match
   SUBSTR caseIgnoreIA5SubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

پیش از فعال‌سازی NETGROUP_BASE، باید بررسی کنید که سرور LDAP شما از تطبیق nisNetgroupTriple پشتیبانی می‌کند. برای مثال با استفاده از ldapsearch:

$ ldapsearch -b $NETGROUP_BASE \
  '(&(objectClass=nisNetgroup)(nisNetgroupTriple=\28*,USER,\29))'

جایی که داده‌های nisNetgroup شما شامل شیئی با nisNetgroupTriple زیر باشد:

nisNetgroupTriple: (,USER,)
پارامتر NETGROUP_QUERY مشخص می‌کند که آیا سرور LDAP از پرس‌وجوی اشیاء nisNetgroup بر اساس صفت nisNetgroupTriple پشتیبانی می‌کند یا خیر. به طور پیش‌فرض، sudoers هنگامی که NETGROUP_BASE تنظیم شده باشد انتظار دارد که بتواند پرس‌وجوهایی منطبق بر صفت‌های nisNetgroupTriple انجام دهد، اما تمام سرورهای LDAP از این قابلیت پشتیبانی نمی‌کنند.

اگر NETGROUP_QUERY غیرفعال شود، sudoers تلاشی برای تعیین فهرست نت‌گروپ‌هایی که کاربر به آن‌ها تعلق دارد نخواهد کرد، اما همچنان هنگام تطبیق نت‌گروپ‌ها مستقیماً از NETGROUP_BASE استفاده می‌کند. این مورد می‌تواند برای پشتیبانی از نت‌گروپ‌ها در سیستم‌هایی که فاقد تابع کتابخانه‌ای innetgr() هستند استفاده شود. برای اطلاعات بیشتر به توضیحات پارامتر NETGROUP_BASE مراجعه نمایید.

یک فیلتر LDAP که برای محدود کردن مجموعه رکوردهای بازگردانده‌شده در هنگام اجرای پرس‌وجوی نت‌گروپ LDAP به کار می‌رود. معمولاً این فیلتر به شکل ‘attribute=value’ یا ‘(&(attribute=value)(attribute2=value2))’ می‌باشد. فیلتر جستجوی پیش‌فرض عبارت است از: ‘objectClass=nisNetgroup’. اگر ldap_filter حذف شود، هیچ فیلتر جستجویی استفاده نخواهد شد.

این گزینه تنها زمانی استفاده می‌شود که نت‌گروپ‌ها مستقیماً از طریق LDAP پرس‌وجو شوند.

یک نام مستعار برای BIND_TIMELIMIT جهت سازگاری با OpenLDAP.
اگر هیچ URI مشخص نشده باشد، پارامتر PORT پورت پیش‌فرض برای اتصال به سرور LDAP را تعیین می‌کند در صورتی که پارامتر HOST پورت را مشخص نکرده باشد. اگر پارامتر PORT تعیین نشود، مقدار پیش‌فرض ۳۸۹ برای LDAP و ۶۳۶ برای LDAP بر روی TLS (SSL) است. پارامتر PORT منسوخ شده و تعیین URI توصیه می‌شود و تنها برای سازگاری به عقب حفظ گردیده است.
پارامتر ROOTBINDDN هویت را در قالب یک نام متمایز (DN) برای انجام عملیات دارای مجوز ارشد LDAP مانند پرس‌وجوهای sudoers مشخص می‌کند. گذرواژه مربوط به این هویت باید در فایلی نگهداری شود که مسیر آن توسط آرگومان افزونه ldap_secret در sudo.conf(5) تعیین می‌شود، و پیش‌فرض آن /etc/ldap.secret است. اگر ROOTBINDDN مشخص نشود، هویت BINDDN (در صورت وجود) به کار می‌رود.
مقدار ROOTUSE_SASL را فعال کنید تا احراز هویت SASL هنگام اتصال به سرور LDAP از یک فرایند ارشد، مانند sudo فعال شود.
نام کاربری SASL جهت اتصال به سرور LDAP. به طور پیش‌فرض، sudo از اتصال ناشناس استفاده می‌کند.

این گزینه تنها هنگام استفاده از احراز هویت SASL کاربرد دارد.

فهرستی جداشده با فاصله از سازوکارهای احراز هویت SASL برای استفاده. به طور پیش‌فرض، sudo از احراز هویت GSSAPI استفاده می‌کند.
ویژگی‌های امنیتی SASL یا none برای عدم استفاده از ویژگی‌ها. برای جزئیات راهنمای برنامه‌نویس SASL را مشاهده کنید.

این گزینه تنها هنگام استفاده از احراز هویت SASL کاربرد دارد.

اگر پارامتر SSL روی on، true یا yes تنظیم شود، رمزنگاری TLS (SSL) همیشه هنگام برقراری ارتباط با سرور LDAP به کار می‌رود. معمولاً این امر شامل اتصال به سرور روی پورت ۶۳۶ (ldaps) است.
اگر پارامتر SSL روی start_tls تنظیم شود، اتصال سرور LDAP به صورت عادی آغاز شده و رمزنگاری TLS پیش از ارسال اعتبارنامه‌های bind آغاز می‌گردد. این حالت این مزیت را دارد که نیازی به یک پورت اختصاصی برای ارتباطات رمزنگاری‌شده ندارد. این پارامتر تنها توسط سرورهای LDAP پشتیبانی می‌شود که از افزونه start_tls پشتیبانی می‌کنند، مانند سرورهای دایرکتوری OpenLDAP و IBM Tivoli.
پایه DN برای استفاده هنگام انجام پرس‌وجوهای sudo در LDAP. معمولاً برای دامنه my-domain.com به صورت ‘ou=SUDOers,dc=my-domain,dc=com’ است. می‌توان چندین خط SUDOERS_BASE تعیین کرد، که در این صورت با ترتیبی که نوشته شده‌اند پرس‌وجو می‌شوند.
سطح اشکال‌زدایی (دیباگ) را برای پرس‌وجوهای sudo در LDAP تنظیم می‌کند. اطلاعات اشکال‌زدایی در خروجی خطای استاندارد چاپ می‌شود. مقدار ۱ منجر به حجم متوسطی از اطلاعات دیباگ می‌شود. مقدار ۲ نتایج خود تطبیق‌ها را نشان می‌دهد. این پارامتر نباید در یک محیط عملیاتی تنظیم شود زیرا اطلاعات اضافی به احتمال زیاد باعث سردرگمی کاربران می‌گردد.

پارامتر SUDOERS_DEBUG منسوخ شده و در نسخه‌های آینده حذف خواهد شد. همین اطلاعات اکنون از طریق چارچوب اشکال‌زدایی sudo با استفاده از زیرسیستم “ldap” در اولویت‌های diag و info به ترتیب برای مقادیر ۱ و ۲ debug_level ثبت می‌شوند. برای جزئیات بیشتر در مورد نحوه پیکربندی اشکال‌زدایی sudo به راهنمای sudo.conf(5) مراجعه کنید.

یک فیلتر LDAP که برای محدود کردن مجموعه رکوردهای بازگردانده‌شده در هنگام انجام یک پرس‌وجوی sudo در LDAP به کار می‌رود. معمولاً به فرمت ‘attribute=value’ یا ‘(&(attribute=value)(attribute2=value2))’ می‌باشد. فیلتر جستجوی پیش‌فرض برابر است با: ‘objectClass=sudoRole’. اگر ldap_filter حذف شود، هیچ فیلتر جستجویی استفاده نخواهد شد.
مشخص می‌کند که آیا صفت‌های sudoNotBefore و sudoNotAfter که ورودی‌های زمان‌دار sudoers را پیاده‌سازی می‌کنند ارزیابی شوند یا خیر.
پارامتر TIMELIMIT میزان زمان انتظار (به ثانیه) برای دریافت پاسخ پرس‌وجوی LDAP را مشخص می‌کند.
پارامتر TIMEOUT مدت زمان انتظار (به ثانیه) برای دریافت پاسخ از APIهای مختلف LDAP را مشخص می‌کند.
نام مستعار برای TLS_CACERTFILE جهت سازگاری با OpenLDAP.
مسیر به یک بسته مراجع صدور گواهی (CA bundle) که شامل گواهی‌های تمام مراجع صدور گواهی معتبر شناخته‌شده توسط کلاینت است، برای مثال /etc/ssl/ca-bundle.pem.

این گزینه تنها توسط کتابخانه‌های OpenLDAP پشتیبانی می‌شود. کتابخانه‌های LDAP مشتق از Netscape از همان پایگاه داده گواهی برای گواهی‌های CA و کلاینت استفاده می‌کنند (گزینه TLS_CERT را ببینید).

مشابه با TLS_CACERTFILE اما به جای فایل، پوشه‌ای شامل گواهی‌های مجزای مراجع صدور گواهی است، برای مثال /etc/ssl/certs. دایرکتوری مشخص‌شده توسط TLS_CACERTDIR پس از TLS_CACERTFILE بررسی می‌شود.

این گزینه تنها توسط کتابخانه‌های OpenLDAP پشتیبانی می‌شود.

مسیر یک فایل حاوی گواهی کلاینت که می‌تواند برای احراز هویت کلاینت نزد سرور LDAP استفاده شود. نوع گواهی به کتابخانه‌های LDAP مورد استفاده بستگی دارد.
‘tls_cert /etc/ssl/client_cert.pem’
مشتق از Netscape:
‘tls_cert /var/ldap/cert7.db’
استفاده نمی‌شود؛ پایگاه‌داده کلید مشخص‌شده با TLS_KEY شامل هر دو کلیدها و گواهی‌ها است.

هنگام استفاده از کتابخانه‌های مشتق از Netscape، این فایل ممکن است شامل گواهی‌های مرجع صدور گواهی (CA) نیز باشد.

اگر فعال باشد، TLS_CHECKPEER باعث اعتبارسنجی گواهی TLS سرور LDAP می‌شود. اگر گواهی TLS سرور تایید نشود (معمولاً به این دلیل که توسط یک مرجع صدور گواهی ناشناخته امضا شده است)، sudo قادر به اتصال به آن نخواهد بود. اگر TLS_CHECKPEER غیرفعال باشد، هیچ بررسی انجام نمی‌شود. غیرفعال کردن این بررسی فرصتی برای حملات مرد میانی (man-in-the-middle) ایجاد می‌کند زیرا هویت سرور احراز نمی‌شود. در صورت امکان، گواهی CA باید به صورت محلی نصب شود تا قابل اعتبارسنجی باشد.

این گزینه توسط کتابخانه‌های IBM LDAP پشتیبانی نمی‌شود.

مسیر یک فایل حاوی کلید خصوصی که با گواهی مشخص‌شده توسط TLS_CERT تطابق دارد. کلید خصوصی نباید با گذرواژه محافظت شده باشد. نوع کلید به کتابخانه‌های LDAP مورد استفاده بستگی دارد.
‘tls_key /etc/ssl/client_key.pem’
مشتق از Netscape:
‘tls_key /var/ldap/key3.db’
‘tls_key /usr/ldap/ldapkey.kdb’

هنگام استفاده از کتابخانه‌های IBM LDAP، این فایل همچنین ممکن است شامل گواهی‌های مرجع صدور گواهی و کلاینت باشد و ممکن است رمزنگاری شده باشد.

پارامتر TLS_CIPHERS به مدیر سیستم اجازه می‌دهد الگوریتم‌های رمزنگاری مجاز برای اتصالات TLS (SSL) را محدود کند. برای فهرستی از سایفرهای معتبر به راهنمای OpenLDAP یا IBM Tivoli Directory Server مراجعه کنید.

این گزینه توسط کتابخانه‌های مشتق از Netscape پشتیبانی نمی‌شود.

شامل گذرواژه مورد استفاده برای رمزگشایی پایگاه‌داده کلید در کلاینت‌هایی است که از کتابخانه IBM LDAP استفاده می‌کنند. مقدار secret می‌تواند یک گذرواژه متنی ساده یا یک رشته کدگذاری‌شده با Base64 دارای پیشوند “base64:” باشد. برای مثال:
TLS_KEYPW base64:dGVzdA==

اگر گذرواژه متنی ساده استفاده شود، باید یک رشته ساده بدون کوتیشن باشد. گذرواژه‌های متنی ساده نباید حاوی نویسه کامنت (‘#’) باشند و اسکیپ کردن کاراکترهای خاص با بک‌اسلش (‘\’) پشتیبانی نمی‌شود. اگر از این گزینه استفاده شود، فایل /etc/openldap/ldap.conf برای جلوگیری از افشای گذرواژه نباید توسط همه کاربران قابل خواندن باشد. همچنین، می‌توان از یک stash file برای ذخیره گذرواژه در قالب رمزنگاری‌شده استفاده کرد (به پایین مراجعه کنید).

اگر هیچ TLS_KEYPW مشخص نشده باشد، در صورت وجود از یک stash file استفاده خواهد شد. فایل stash file باید همان مسیر فایل مشخص‌شده با TLS_KEY را داشته باشد اما از پسوند ‘.sth’ به جای ‘.kdb’ استفاده کند، برای مثال ‘ldapkey.sth’. فایل پیش‌فرض ‘ldapkey.kdb’ که همراه با IBM Tivoli Directory Server عرضه می‌شود با گذرواژه ‘ssl_password’ رمزنگاری شده است. ابزار gsk8capicmd می‌تواند برای مدیریت پایگاه‌داده کلید و ایجاد stash file استفاده شود.

این گزینه تنها توسط کتابخانه‌های IBM LDAP پشتیبانی می‌شود.

پارامتر TLS_REQCERT نحوه اعتبارسنجی گواهی TLS سرور LDAP را کنترل می‌کند (در صورت انجام بررسی). اگر گواهی TLS سرور تایید نشود (معمولاً به دلیل اینکه توسط یک مرجع صدور گواهی ناشناخته امضا شده است)، sudo قادر به اتصال به آن نخواهد بود. مقادیر زیر برای level پشتیبانی می‌شوند:

گواهی سرور درخواست یا بررسی نمی‌شود.

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

این گزینه تنها توسط کتابخانه‌های OpenLDAP پشتیبانی می‌شود. سایر کتابخانه‌های LDAP تنها از پارامتر TLS_CHECKPEER پشتیبانی می‌کنند.

پارامتر TLS_RANDFILE مسیر منبع آنتروپی را برای سیستم‌هایی که فاقد دستگاه اعداد تصادفی هستند مشخص می‌کند. عموماً همراه با prngd یا egd به کار می‌رود.

این گزینه تنها توسط کتابخانه‌های OpenLDAP پشتیبانی می‌شود.

فهرستی از یک یا چند URI جداشده با فاصله را که سرور(های) LDAP مورد اتصال را توصیف می‌کنند مشخص می‌سازد. پروتکل protocol می‌تواند ldap یا ldaps باشد، که دومی برای سرورهایی است که از رمزنگاری TLS (SSL) پشتیبانی می‌کنند. اگر هیچ پورتی مشخص نشده باشد، پورت پیش‌فرض ۳۸۹ برای ‘ldap://’ یا ۶۳۶ برای ‘ldaps://’ است. اگر هیچ نام میزبانی مشخص نشود، sudo به localhost متصل خواهد شد. خطوط متعدد URI دقیقاً مشابه با یک خط URI حاوی چندین ورودی رفتار می‌کنند. تنها سیستم‌هایی که از کتابخانه‌های OpenSSL استفاده می‌کنند از ترکیب URIهای ‘ldap://’ و ‘ldaps://’ پشتیبانی می‌نمایند. هر دو کتابخانه مشتق از Netscape و IBM LDAP که در بیشتر نسخه‌های تجاری یونیکس استفاده می‌شوند تنها قادر به پشتیبانی از یکی از آن‌ها هستند.
گزینه USE_SASL را برای سرورهای LDAP که از احراز هویت SASL پشتیبانی می‌کنند فعال کنید.
نام کاربری SASL برای استفاده هنگامی که ROOTUSE_SASL فعال باشد.

مدخل ldap.conf در بخش مثال‌ها (EXAMPLES) را ببینید.

مگر در مواردی که در زمان ساخت برنامه غیرفعال شده باشد، sudo فایل Name Service Switch یعنی /etc/nsswitch.conf را برای تعیین ترتیب جستجوی sudoers بررسی می‌کند. دستور sudo به دنبال خطی می‌گردد که با sudoers: آغاز شود و از آن برای تعیین ترتیب جستجو استفاده می‌کند. به طور پیش‌فرض، sudo پس از اولین تطبیق جستجو را متوقف نمی‌کند و تطبیق‌های بعدی بر تطبیق‌های قبلی ارجحیت دارند (مگر اینکه از ‘[SUCCESS=return]’ استفاده شود، به پایین مراجعه کنید). منابع زیر شناسایی می‌شوند:

خواندن قوانین sudoers از /etc/sudoers
خواندن قوانین sudoers از LDAP

علاوه بر این، زیرمجموعه‌ای از دستورات عملیاتی به سبک nsswitch.conf پشتیبانی می‌شوند، به ویژه ‘[SUCCESS=return]’ و ‘[NOTFOUND=return]’. این عبارات جستجو را بدون قید و شرط پایان می‌دهند اگر کاربر در منبع بلافاصله قبلی یا پیدا شده باشد (‘[SUCCESS=return]’) یا پیدا نشده باشد (‘[NOTFOUND=return]’). سایر عبارات عملیاتی پشتیبانی نمی‌شوند، و نفی آزمون با علامت ‘!’ نیز پشتیبانی نمی‌شود.

برای بررسی ابتدا LDAP و سپس فایل sudoers محلی (در صورت وجود)، استفاده کنید از:

sudoers: ldap files

برای بررسی LDAP تنها در صورتی که هیچ تطبیقی در فایل sudoers محلی یافت نشد (در صورت وجود)، استفاده کنید از:

sudoers: files [SUCCESS=return] ldap

فایل محلی sudoers می‌تواند با استفاده از خط زیر کاملاً نادیده گرفته شود:

sudoers: ldap

اگر فایل /etc/nsswitch.conf وجود نداشته باشد یا خط sudoers در آن نباشد، پیش‌فرض زیر در نظر گرفته می‌شود:

sudoers: files

فایل /etc/nsswitch.conf حتی در زمانی که سیستم‌عامل زیرین از آن پشتیبانی نمی‌کند نیز توسط sudo پشتیبانی می‌شود، به جز در AIX (به پایین مراجعه کنید).

در سیستم‌های AIX، فایل /etc/netsvc.conf به جای /etc/nsswitch.conf بررسی می‌شود. دستور sudo صرفاً با netsvc.conf به عنوان گونه‌ای از nsswitch.conf رفتار می‌کند؛ اطلاعات بخش قبلی که نامرتبط با فرمت خود فایل است همچنان اعمال می‌شود.

برای بررسی ابتدا LDAP و سپس فایل sudoers محلی (در صورت وجود)، استفاده کنید از:

sudoers = ldap, files

فایل محلی sudoers می‌تواند با استفاده از خط زیر کاملاً نادیده گرفته شود:

sudoers = ldap

برای اینکه LDAP مرجع قطعی در نظر گرفته شود و فایل sudoers محلی تنها در صورت عدم حضور کاربر در LDAP استفاده شود، استفاده کنید از:

sudoers = ldap = auth, files

در مثال فوق، قید auth تنها بر جستجوی کاربران تأثیر می‌گذارد؛ هم LDAP و هم sudoers برای ورودی‌های Defaults استعلام خواهند شد.

اگر فایل /etc/netsvc.conf وجود نداشته باشد یا خط sudoers وجود نداشته باشد، پیش‌فرض زیر در نظر گرفته می‌شود:

sudoers = files

در سیستم‌هایی که دارای دیمن خدمات امنیتی سیستم System Security Services Daemon (SSSD) هستند و sudo با پشتیبانی از SSSD ساخته شده است، می‌توان از SSSD برای کش کردن قوانین LDAP sudoers استفاده کرد. برای استفاده از SSSD به عنوان منبع sudoers، باید از sss به جای ldap برای ورودی sudoers در /etc/nsswitch.conf استفاده کنید. فایل /etc/openldap/ldap.conf توسط بک‌اند SSSD در sudo استفاده نمی‌شود. برای اطلاعات بیشتر در مورد پیکربندی sudo جهت کار با SSSD به sssd-sudo(5) مراجعه نمایید.

/etc/openldap/ldap.conf
فایل پیکربندی LDAP
/etc/nsswitch.conf
تعیین‌ترتیب منابع sudoers
/etc/netsvc.conf
تعیین‌ترتیب منابع sudoers در AIX

# Either specify one or more URIs or one or more host:port pairs.
# If neither is specified sudo will default to localhost, port 389.
#
#host          ldapserver
#host          ldapserver1 ldapserver2:390
#
# Default port if host is specified without one, defaults to 389.
#port          389
#
# URI will override the host and port settings.
uri            ldap://ldapserver
#uri            ldaps://secureldapserver
#uri            ldaps://secureldapserver ldap://ldapserver
#
# The amount of time, in seconds, to wait while trying to connect to
# an LDAP server.
bind_timelimit 30
#
# The amount of time, in seconds, to wait while performing an LDAP query.
timelimit 30
#
# Must be set or sudo will ignore LDAP; may be specified multiple times.
sudoers_base   ou=SUDOers,dc=my-domain,dc=com
#
# verbose sudoers matching from ldap
#sudoers_debug 2
#
# Enable support for time-based entries in sudoers.
#sudoers_timed yes
#
# optional proxy credentials
#binddn        <who to search as>
#bindpw        <password>
#rootbinddn    <who to search as, uses /etc/ldap.secret for bindpw>
#
# LDAP protocol version, defaults to 3
#ldap_version 3
#
# Define if you want to use an encrypted LDAP connection.
# Typically, you must also set the port to 636 (ldaps).
#ssl on
#
# Define if you want to use port 389 and switch to
# encryption before the bind credentials are sent.
# Only supported by LDAP servers that support the start_tls
# extension such as OpenLDAP.
#ssl start_tls
#
# Additional TLS options follow that allow tweaking of the
# SSL/TLS connection.
#
#tls_checkpeer yes # verify server SSL certificate
#tls_checkpeer no  # ignore server SSL certificate
#
# If you enable tls_checkpeer, specify either tls_cacertfile
# or tls_cacertdir.  Only supported when using OpenLDAP.
#
#tls_cacertfile /etc/certs/trusted_signers.pem
#tls_cacertdir  /etc/certs
#
# For systems that don't have /dev/random
# use this along with PRNGD or EGD.pl to seed the
# random number pool to generate cryptographic session keys.
# Only supported when using OpenLDAP.
#
#tls_randfile /etc/egd-pool
#
# You may restrict which ciphers are used.  Consult your SSL
# documentation for which options go here.
# Only supported when using OpenLDAP.
#
#tls_ciphers <cipher-list>
#
# Sudo can provide a client certificate when communicating to
# the LDAP server.
# Tips:
#   * Enable both lines at the same time.
#   * Do not password protect the key file.
#   * Ensure the keyfile is only readable by root.
#
# For OpenLDAP:
#tls_cert /etc/certs/client_cert.pem
#tls_key  /etc/certs/client_key.pem
#
# For Netscape-derived LDAP, tls_cert and tls_key may specify either
# a directory, in which case the files in the directory must have the
# default names (e.g., cert8.db and key4.db), or the path to the cert
# and key files themselves.  However, a bug in version 5.0 of the LDAP
# SDK will prevent specific file names from working.  For this reason
# it is suggested that tls_cert and tls_key be set to a directory,
# not a file name.
#
# The certificate database specified by tls_cert may contain CA certs
# and/or the client's cert.  If the client's cert is included, tls_key
# should be specified as well.
# For backward compatibility, "sslpath" may be used in place of tls_cert.
#tls_cert /var/ldap
#tls_key /var/ldap
#
# If using SASL authentication for LDAP (OpenSSL)
# use_sasl yes
# sasl_auth_id <SASL user name>
# rootuse_sasl yes
# rootsasl_auth_id <SASL user name for root access>
# sasl_secprops none
# krb5_ccname /etc/.ldapcache

طرحواره زیر، در قالب OpenLDAP، در توزیع‌های سورس و باینری sudo تحت عنوان schema.OpenLDAP گنجانده شده است. کافی است آن را در دایرکتوری طرحواره‌ها (مانند /etc/openldap/schema) کپی کرده، خط include مناسب را در slapd.conf اضافه نموده و slapd را مجدداً راه‌اندازی کنید. سایت‌هایی که از پیکربندی برخط اختیاری پشتیبانی‌شده توسط OpenLDAP نسخه ۲.۳ و بالاتر استفاده می‌کنند باید به جای آن از فایل schema.olcSudo استفاده کنند.

attributetype ( 1.3.6.1.4.1.15953.9.1.1
   NAME 'sudoUser'
   DESC 'User(s) who may  run sudo'
   EQUALITY caseExactMatch
   SUBSTR caseExactSubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 1.3.6.1.4.1.15953.9.1.2
   NAME 'sudoHost'
   DESC 'Host(s) who may run sudo'
   EQUALITY caseExactIA5Match
   SUBSTR caseExactIA5SubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.15953.9.1.3
   NAME 'sudoCommand'
   DESC 'Command(s) to be executed by sudo'
   EQUALITY caseExactIA5Match
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.15953.9.1.4
   NAME 'sudoRunAs'
   DESC 'User(s) impersonated by sudo'
   EQUALITY caseExactIA5Match
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.15953.9.1.5
   NAME 'sudoOption'
   DESC 'Options(s) followed by sudo'
   EQUALITY caseExactIA5Match
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.15953.9.1.6
   NAME 'sudoRunAsUser'
   DESC 'User(s) impersonated by sudo'
   EQUALITY caseExactMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 1.3.6.1.4.1.15953.9.1.7
   NAME 'sudoRunAsGroup'
   DESC 'Group(s) impersonated by sudo'
   EQUALITY caseExactMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 1.3.6.1.4.1.15953.9.1.8
   NAME 'sudoNotBefore'
   DESC 'Start of time interval for which the entry is valid'
   EQUALITY generalizedTimeMatch
   ORDERING generalizedTimeOrderingMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
attributetype ( 1.3.6.1.4.1.15953.9.1.9
   NAME 'sudoNotAfter'
   DESC 'End of time interval for which the entry is valid'
   EQUALITY generalizedTimeMatch
   ORDERING generalizedTimeOrderingMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
attributetype ( 1.3.6.1.4.1.15953.9.1.10
   NAME 'sudoOrder'
   DESC 'an integer to order the sudoRole entries'
   EQUALITY integerMatch
   ORDERING integerOrderingMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
   DESC 'Sudoer Entries'
   MUST ( cn )
   MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $
         sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $
         sudoOrder $ description )
   )

cvtsudoers(1), ldap.conf(5), sssd-sudo(5), sudo.conf(5), sudoers(5)

افراد بسیاری در طول سال‌ها روی sudo کار کرده‌اند؛ این نسخه از کدهایی تشکیل شده که اصولاً توسط شخص زیر نوشته شده است:

Todd C. Miller

برای مشاهده فهرست کامل افرادی که در پروژه sudo مشارکت داشته‌اند، فایل CONTRIBUTORS.md را در توزیع sudo (https://www.sudo.ws/about/contributors) ببینید.

تفاوت‌هایی در نحوه تجزیه sudoers مبتنی بر LDAP در مقایسه با sudoers مبتنی بر فایل وجود دارد. برای اطلاعات بیشتر بخش تفاوت‌های میان sudoers مبتنی بر LDAP و فایل معمولی را مشاهده نمایید.

اگر فکر می‌کنید اشکالی در sudoers.ldap پیدا کرده‌اید، می‌توانید یک گزارش اشکال در پایگاه داده باگ‌های sudo به نشانی https://bugzilla.sudo.ws ثبت کنید، یا یک issue در https://github.com/sudo-project/sudo/issues باز نمایید. اگر ترجیح می‌دهید از ایمیل استفاده کنید، پیام‌ها می‌توانند به فهرست پستی sudo-workers به نشانی https://www.sudo.ws/mailman/listinfo/sudo-workers (عمومی) یا <sudo@sudo.ws> (خصوصی) ارسال شوند.

لطفاً آسیب‌پذیری‌های امنیتی را از طریق issueهای عمومی گیت‌هاب، Bugzilla یا فهرست‌های پستی گزارش نکنید. در عوض، آن‌ها را از طریق ایمیل به <Todd.Miller@sudo.ws> ارسال نمایید. در صورت تمایل می‌توانید پیام خود را با استفاده از کلید موجود در https://www.sudo.ws/dist/PGPKEYS با PGP رمزنگاری کنید.

پشتیبانی رایگان و محدود از طریق فهرست پستی sudo-users در دسترس است؛ برای عضویت یا جستجو در آرشیوها نشانی https://www.sudo.ws/mailman/listinfo/sudo-users را مشاهده نمایید.

برنامه sudo «همان‌گونه که هست» (AS IS) ارائه می‌شود و هرگونه ضمانت صریح یا ضمنی، از جمله، اما نه محدود به، ضمانت‌های ضمنی قابلیت خرید و فروش و تناسب برای یک هدف خاص سلب می‌گردد. برای جزئیات کامل، فایل LICENSE.md توزیع‌شده با sudo یا نشانی https://www.sudo.ws/about/license را ببینید.

مه ۲۰۲۵ sudo