| SUDOERS.LDAP(5) | فایلهای پیکربندی | SUDOERS.LDAP(5) |
نام (NAME)
sudoers.ldap - پیکربندی دسترسیهای sudoers در سرویس LDAP
توضیحات (DESCRIPTION)
پرونده sudoers.ldap ساختار و نحوه واکشی و نگهداری قوانین و مجوزهای دسترسی دستور sudo را در دایرکتوری متمرکز LDAP شرح میدهد.
علاوه بر فایل استاندارد sudoers، دستور sudo میتواند از طریق LDAP نیز پیکربندی شود. این قابلیت بهویژه برای همگامسازی sudoers در یک محیط توزیعشده و بزرگ بسیار سودمند است.
استفاده از LDAP برای sudoers مزایای متعددی دارد:
- •
- دستور sudo دیگر نیازی به خواندن تمام و کمال فایل sudoers ندارد. هنگام استفاده از LDAP، در هر بار اجرای دستور تنها دو یا سه پرسوجوی LDAP انجام میشود. این امر اجرای آن را بسیار سریع کرده و استفاده از آن را در محیطهای مبتنی بر LDAP بهینه میسازد.
- •
- امکان تعیین گزینهها به ازای هر ورودی مشخص وجود دارد که گزینههای پیشفرض سراسری را بازنویسی (override) میکنند. فایل /etc/sudoers تنها از گزینههای پیشفرض و گزینههای محدودی در ارتباط با کاربران، میزبانها، دستورات و نامهای مستعار پشتیبانی میکند. سینتکس آن پیچیده است و درک آن برای کاربران دشوار است. قرار دادن گزینهها مستقیماً درون خود ورودی بسیار طبیعیتر است.
- •
- دیگر نیازی به برنامه visudo نیست. برنامه visudo قفلگذاری و بررسی سینتکس فایل /etc/sudoers را فراهم میکند. از آنجا که بهروزرسانیها در LDAP به صورت اتمیک (تراکنشی) هستند، قفلگذاری دیگر لزومی ندارد. همچنین از آنجا که ساختار نحوی هنگام درج دادهها در LDAP بررسی میشود، نیازی به ابزار اختصاصی برای بررسی سینتکس نخواهد بود.
ظرف LDAP قوانین SUDOers (SUDOers LDAP container)
پیکربندی 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 است. این شیء شامل صفتهای زیر میباشد:
- sudoUser
- یک نام کاربری، شناسه کاربری (با پیشوند ‘#’)، نام یا شناسه گروه یونیکس (به ترتیب با پیشوند ‘%’ یا ‘%#’)، نتگروپ کاربر (با پیشوند ‘+’)، یا نام یا شناسه گروه غیر یونیکسی (به ترتیب با پیشوند ‘%:’ یا ‘%:#’). تطبیق نتگروپهای کاربر تنها با استفاده از اعضای کاربر و دامنه صورت میگیرد؛ عضو میزبان هنگام تطبیق استفاده نمیشود. پشتیبانی از گروههای غیر یونیکسی تنها زمانی در دسترس است که یک group_plugin مناسب در شیء سراسری defaults در sudoRole تعریف شده باشد. اگر یک ورودی sudoUser با علامت تعجب (‘!’) شروع شود و آن ورودی تطبیق یابد، کل sudoRole مربوطه نادیده گرفته خواهد شد. ورودیهای نفیشده sudoUser تنها در نسخه ۱.۹.۹ یا بالاتر پشتیبانی میشوند.
- sudoHost
- یک نام میزبان، آدرس IP، شبکه IP، یا نتگروپ میزبان (با پیشوند ‘+’). مقدار ویژه ALL با هر میزبانی تطبیق پیدا میکند. نتگروپهای میزبان تنها با استفاده از اعضای میزبان (هم با نام کامل و هم بدون دامنه) و دامنه مطابقت داده میشوند؛ عضو کاربر در هنگام تطبیق به کار نمیرود. اگر یک ورودی sudoHost با علامت تعجب (‘!’) شروع شود و تطبیق یابد، آن sudoRole نادیده گرفته میشود. ورودیهای نفیشده sudoHost تنها از نسخه ۱.۸.۱۸ یا بالاتر پشتیبانی میشوند.
- sudoCommand
- یک نام
دستور
یونیکسی با
مسیر کامل
به همراه
آرگومانهای
اختیاری خط
فرمان،
احتمالاً
شامل
نویسههای
الگو
(وایلدکارتها).
اگر نام
دستور با
علامت تعجب
(‘!’) شروع
شود، کاربر
از اجرای آن
دستور منع
خواهد شد.
دستور توکار “sudoedit” برای اجازه دادن به کاربر جهت اجرای sudo با گزینه -e (یا به عنوان sudoedit) به کار میرود. این دستور مانند یک دستور معمولی میتواند آرگومانهای خط فرمان بپذیرد. برخلاف سایر دستورات، “sudoedit” درون خود sudo تعبیه شده است و باید بدون مسیر ابتدایی مشخص شود.
مقدار ویژه ALL با هر دستوری تطبیق مییابد.
اگر نام یک دستور با یک چکیده رمزنقاری SHA-2 پیشوند شده باشد، اجرای دستور تنها در صورتی مجاز خواهد بود که چکیده هش آن مطابقت داشته باشد. این ویژگی ممکن است در شرایطی مفید باشد که کاربری که sudo را اجرا میکند به خود دستور یا دایرکتوری والد آن دسترسی نوشتن داشته باشد. قالبهای چکیده زیر پشتیبانی میشوند: sha224، sha256، sha384 و sha512. نام چکیده باید به دنبال یک دونقطه (‘:’) و سپس خود چکیده به صورت هگزادسیمال یا base64 بیاید. برای نمونه با مقدار زیر برای sudoCommand:
sha224:0GomF8mNN3wlDt1HD9XldjJ3SNgpFdbjO1+NsQ /bin/ls
کاربر تنها در صورتی میتواند /bin/ls را اجرا کند که چکیده sha224 آن با مقدار مشخصشده یکسان باشد. چکیدههای دستور تنها از نسخه ۱.۸.۷ به بعد پشتیبانی میشوند.
- sudoOption
- از نظر عملکردی مشابه با گزینههای سراسری توصیفشده در بالا است، اما مختص به همان sudoRole میباشد که در آن تعریف شده است.
- sudoRunAsUser
- یک نام
کاربری یا
شناسه
کاربری (با
پیشوند ‘#’)
که دستورات
میتوانند
در قالب آن
اجرا شوند،
یا یک گروه
یونیکس (با
پیشوند ‘%’)
یا نتگروپ
کاربر (با
پیشوند ‘+’)
شامل
فهرستی از
کاربرانی
که دستورات
میتوانند
در قالب
آنها اجرا
گردند.
مقدار ویژه
ALL با هر
کاربری
تطبیق
مییابد.
اگر یک
ورودی sudoRunAsUser
با علامت
تعجب (‘!’)
آغاز شود و
تطبیق پیدا
کند، آن sudoRole
نادیده
گرفته
خواهد شد.
اگر sudoRunAsUser
مشخص شده
ولی خالی
باشد، با
کاربر
فراخواننده
تطبیق داده
میشود. اگر
هیچکدام
از sudoRunAsUser و sudoRunAsGroup
وجود
نداشته
باشند،
مقدار sudoOption
با نام runas_default
استفاده
میشود
(پیشفرض root
است).
صفت sudoRunAsUser تنها در نسخه ۱.۷.۰ و بالاتر sudo در دسترس است. نسخههای قدیمیتر sudo به جای آن از صفت sudoRunAs استفاده میکردند. ورودیهای نفیشده sudoRunAsUser تنها در نسخه ۱.۸.۲۶ یا بالاتر پشتیبانی میشوند.
- sudoRunAsGroup
- یک گروه
یونیکس یا
شناسه گروه
(با پیشوند
‘#’) که
دستورات
میتوانند
تحت آن گروه
اجرا شوند.
مقدار ویژه
ALL با هر
گروهی
تطبیق پیدا
میکند. اگر
یک ورودی
sudoRunAsGroup با
علامت تعجب
(‘!’) آغاز
شده و تطبیق
یابد، آن sudoRole
نادیده
گرفته
خواهد شد.
صفت sudoRunAsGroup تنها در نسخه ۱.۷.۰ و بالاتر sudo در دسترس است. ورودیهای نفیشده sudoRunAsGroup تنها در نسخه ۱.۸.۲۶ یا بالاتر پشتیبانی میشوند.
- sudoNotBefore
- یک برچسب
زمانی به
قالب ‘yyyymmddHHMMSSZ’
که
میتواند
برای تعیین
زمان و
تاریخ آغاز
معتبر شدن
sudoRole به کار
رود. اگر
چند ورودی
sudoNotBefore وجود
داشته
باشد،
زودترین
آنها
استفاده
میشود.
برچسبهای
زمانی باید
در قالب
ساعت
هماهنگ
جهانی (UTC)
باشند و نه
منطقه
زمانی محلی.
بخشهای
دقیقه و
ثانیه
اختیاری
هستند، اما
برخی
کارگزارهای
LDAP بر خلاف RFC
الزام
دارند که
حتماً قید
شوند.
صفت sudoNotBefore تنها در نسخه ۱.۷.۵ و بالاتر sudo در دسترس است و باید صراحتاً از طریق گزینه SUDOERS_TIMED در فایل /etc/openldap/ldap.conf فعال شده باشد.
- sudoNotAfter
- یک برچسب
زمانی به
قالب ‘yyyymmddHHMMSSZ’
که
تاریخ/زمان
انقضا را
مشخص
میکند، و
پس از آن
تاریخ sudoRole
دیگر معتبر
نخواهد بود.
اگر چند
ورودی sudoNotAfter
وجود داشته
باشد،
آخرین مورد
استفاده
خواهد شد.
برچسبهای
زمانی باید
در قالب
ساعت
هماهنگ
جهانی (UTC)
باشند و نه
زمان محلی.
بخشهای
دقیقه و
ثانیه
اختیاری
هستند، اما
برخی
سرورهای LDAP
حضور آنها
را الزامی
میدانند.
صفت sudoNotAfter تنها در نسخه ۱.۷.۵ و بالاتر sudo در دسترس است و باید صراحتاً از طریق گزینه SUDOERS_TIMED در /etc/openldap/ldap.conf فعال گردد.
- sudoOrder
- ورودیهای
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
کالبدشناسی و ساختار جستجوی sudoers در LDAP (Anatomy of LDAP sudoers lookup)
هنگام جستجوی یک 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 پشتیبانی نماید.
تفاوتهای میان sudoers مبتنی بر LDAP و فایل معمولی (Differences between LDAP and non-LDAP sudoers)
یکی از تفاوتهای عمده میان 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
تبدیل میان sudoers مبتنی بر فایل و LDAP (Converting between file-based and LDAP sudoers)
ابزار 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’ هستند.
طرحواره Sudoers (Sudoers schema)
به منظور استفاده از پشتیبانی LDAP در sudo، طرحواره (اسکیما) sudo باید روی سرور LDAP شما نصب شود. علاوه بر این، حتماً اطمینان حاصل کنید که صفت sudoUser ایندکسگذاری شده باشد.
توزیع sudo شامل نسخههایی از طرحواره sudoers برای سرورهای مختلف LDAP است:
- schema.ActiveDirectory
- مایکروسافت اکتیو دایرکتوری (Microsoft Active Directory)
- schema.IBM_LDAP
- سرور دایرکتوری آیبیام (IBM Directory Server)، همچنین شناختهشده با نامهای IBM Tivoli Directory Server، IBM Security Directory Server، و IBM Security Verify Directory
- schema.iPlanet
- سرورهای مشتقشده از نتاسکیپ مانند سرورهای دایرکتوری iPlanet، Oracle و 389 Directory Server
- schema.olcSudo
- سرور OpenLDAP slapd نسخه ۲.۳ و بالاتر زمانی که پیکربندی برخط (on-line) فعال است
- schema.OpenLDAP
- سرور OpenLDAP slapd و OpenBSD ldapd
طرحواره در قالب OpenLDAP در بخش مثالها (EXAMPLES) نیز آورده شده است.
پیکربندی ldap.conf (Configuring ldap.conf)
دستور 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 seconds
- پارامتر BIND_TIMELIMIT مدت زمان (به ثانیه) انتظار در حین تلاش برای اتصال به یک سرور LDAP را مشخص میکند. اگر چندین URI یا HOST تعیین شده باشد، این زمان مدت انتظاری است که قبل از رفتن به سرور بعدی در فهرست اعمال میشود.
- BINDDN DN
- پارامتر BINDDN هویت مورد نظر برای انجام عملیات LDAP را در قالب یک نام متمایز (DN) تعیین میکند. اگر مشخص نشود، عملیات LDAP با هویت ناشناس (anonymous) انجام میشود. به طور پیشفرض، اکثر سرورهای LDAP دسترسی ناشناس را مجاز میدانند.
- BINDPW secret
- پارامتر BINDPW گذرواژه مورد استفاده هنگام انجام عملیات LDAP را تعیین میکند. این گزینه معمولاً همراه با پارامتر BINDDN به کار میرود. مقدار secret میتواند یک گذرواژه متنی ساده یا یک رشته کدگذاریشده با Base64 دارای پیشوند “base64:” باشد. برای مثال:
BINDPW base64:dGVzdA==
اگر از گذرواژه متنی ساده استفاده شود، باید یک رشته ساده بدون کوتیشن باشد. گذرواژههای متنی ساده نباید شامل نویسه کامنت (‘#’) باشند و اسکیپ کردن نویسههای خاص با بکاسلش (‘\’) پشتیبانی نمیشود.
- DEREF never/searching/finding/always
- نحوه ارجاعزدایی نامهای مستعار (alias dereferencing) در هنگام جستجو را مشخص میکند. توضیح کامل این گزینه را در راهنمای ldap.conf(5) ببینید.
- HOST name[:port] ...
- اگر هیچ URI مشخص نشده باشد (به پایین مراجعه کنید)، پارامتر HOST فهرستی از سرورهای LDAP که با فاصله از هم جدا شدهاند را برای اتصال مشخص میسازد. هر میزبان میتواند شامل یک پورت اختیاری باشد که با دونقطه (‘:’) جدا میشود. پارامتر HOST منسوخ شده و تعیین URI توصیه میشود و تنها برای سازگاری با نسخههای پیشین حفظ شده است.
- KRB5_CCNAME file name
- مسیر حافظه
پنهان
گواهی
کربروس ۵ (Kerberos 5
credential cache) جهت
استفاده
هنگام
احراز هویت
با سرور راه
دور.
این گزینه تنها هنگام استفاده از احراز هویت SASL کاربرد دارد (به پایین مراجعه کنید).
- LDAP_VERSION number
- نسخه پروتکل LDAP برای اتصال به سرور. مقدار پیشفرض، پروتکل نسخه ۳ است.
- NETGROUP_BASE base
- پایه 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 زیر باشد:
- NETGROUP_QUERY on/true/yes/off/false/no
- پارامتر
NETGROUP_QUERY مشخص
میکند که
آیا سرور LDAP
از
پرسوجوی
اشیاء nisNetgroup
بر اساس صفت
nisNetgroupTriple
پشتیبانی
میکند یا
خیر. به طور
پیشفرض،
sudoers هنگامی
که NETGROUP_BASE
تنظیم شده
باشد
انتظار
دارد که
بتواند
پرسوجوهایی
منطبق بر
صفتهای
nisNetgroupTriple انجام
دهد، اما
تمام
سرورهای LDAP
از این
قابلیت
پشتیبانی
نمیکنند.
اگر NETGROUP_QUERY غیرفعال شود، sudoers تلاشی برای تعیین فهرست نتگروپهایی که کاربر به آنها تعلق دارد نخواهد کرد، اما همچنان هنگام تطبیق نتگروپها مستقیماً از NETGROUP_BASE استفاده میکند. این مورد میتواند برای پشتیبانی از نتگروپها در سیستمهایی که فاقد تابع کتابخانهای innetgr() هستند استفاده شود. برای اطلاعات بیشتر به توضیحات پارامتر NETGROUP_BASE مراجعه نمایید.
- NETGROUP_SEARCH_FILTER ldap_filter
- یک فیلتر LDAP
که برای
محدود کردن
مجموعه
رکوردهای
بازگرداندهشده
در هنگام
اجرای
پرسوجوی
نتگروپ LDAP
به کار
میرود.
معمولاً
این فیلتر
به شکل ‘attribute=value’
یا
‘(&(attribute=value)(attribute2=value2))’
میباشد.
فیلتر
جستجوی
پیشفرض
عبارت است
از: ‘objectClass=nisNetgroup’.
اگر ldap_filter حذف
شود، هیچ
فیلتر
جستجویی
استفاده
نخواهد شد.
این گزینه تنها زمانی استفاده میشود که نتگروپها مستقیماً از طریق LDAP پرسوجو شوند.
- NETWORK_TIMEOUT seconds
- یک نام مستعار برای BIND_TIMELIMIT جهت سازگاری با OpenLDAP.
- PORT port_number
- اگر هیچ URI مشخص نشده باشد، پارامتر PORT پورت پیشفرض برای اتصال به سرور LDAP را تعیین میکند در صورتی که پارامتر HOST پورت را مشخص نکرده باشد. اگر پارامتر PORT تعیین نشود، مقدار پیشفرض ۳۸۹ برای LDAP و ۶۳۶ برای LDAP بر روی TLS (SSL) است. پارامتر PORT منسوخ شده و تعیین URI توصیه میشود و تنها برای سازگاری به عقب حفظ گردیده است.
- ROOTBINDDN DN
- پارامتر ROOTBINDDN هویت را در قالب یک نام متمایز (DN) برای انجام عملیات دارای مجوز ارشد LDAP مانند پرسوجوهای sudoers مشخص میکند. گذرواژه مربوط به این هویت باید در فایلی نگهداری شود که مسیر آن توسط آرگومان افزونه ldap_secret در sudo.conf(5) تعیین میشود، و پیشفرض آن /etc/ldap.secret است. اگر ROOTBINDDN مشخص نشود، هویت BINDDN (در صورت وجود) به کار میرود.
- ROOTUSE_SASL on/true/yes/off/false/no
- مقدار ROOTUSE_SASL را فعال کنید تا احراز هویت SASL هنگام اتصال به سرور LDAP از یک فرایند ارشد، مانند sudo فعال شود.
- SASL_AUTH_ID identity
- نام کاربری
SASL جهت اتصال
به سرور LDAP. به
طور
پیشفرض،
sudo از اتصال
ناشناس
استفاده
میکند.
این گزینه تنها هنگام استفاده از احراز هویت SASL کاربرد دارد.
- SASL_MECH mechanisms
- فهرستی جداشده با فاصله از سازوکارهای احراز هویت SASL برای استفاده. به طور پیشفرض، sudo از احراز هویت GSSAPI استفاده میکند.
- SASL_SECPROPS none/properties
- ویژگیهای
امنیتی SASL یا
none برای عدم
استفاده از
ویژگیها.
برای
جزئیات
راهنمای
برنامهنویس
SASL را مشاهده
کنید.
این گزینه تنها هنگام استفاده از احراز هویت SASL کاربرد دارد.
- SSL on/true/yes/off/false/no
- اگر پارامتر SSL روی on، true یا yes تنظیم شود، رمزنگاری TLS (SSL) همیشه هنگام برقراری ارتباط با سرور LDAP به کار میرود. معمولاً این امر شامل اتصال به سرور روی پورت ۶۳۶ (ldaps) است.
- SSL start_tls
- اگر پارامتر SSL روی start_tls تنظیم شود، اتصال سرور LDAP به صورت عادی آغاز شده و رمزنگاری TLS پیش از ارسال اعتبارنامههای bind آغاز میگردد. این حالت این مزیت را دارد که نیازی به یک پورت اختصاصی برای ارتباطات رمزنگاریشده ندارد. این پارامتر تنها توسط سرورهای LDAP پشتیبانی میشود که از افزونه start_tls پشتیبانی میکنند، مانند سرورهای دایرکتوری OpenLDAP و IBM Tivoli.
- SUDOERS_BASE base
- پایه DN برای استفاده هنگام انجام پرسوجوهای sudo در LDAP. معمولاً برای دامنه my-domain.com به صورت ‘ou=SUDOers,dc=my-domain,dc=com’ است. میتوان چندین خط SUDOERS_BASE تعیین کرد، که در این صورت با ترتیبی که نوشته شدهاند پرسوجو میشوند.
- SUDOERS_DEBUG debug_level
- سطح
اشکالزدایی
(دیباگ) را
برای
پرسوجوهای
sudo در LDAP تنظیم
میکند.
اطلاعات
اشکالزدایی
در خروجی
خطای
استاندارد
چاپ میشود.
مقدار ۱
منجر به حجم
متوسطی از
اطلاعات
دیباگ
میشود.
مقدار ۲
نتایج خود
تطبیقها
را نشان
میدهد. این
پارامتر
نباید در یک
محیط
عملیاتی
تنظیم شود
زیرا
اطلاعات
اضافی به
احتمال
زیاد باعث
سردرگمی
کاربران
میگردد.
پارامتر SUDOERS_DEBUG منسوخ شده و در نسخههای آینده حذف خواهد شد. همین اطلاعات اکنون از طریق چارچوب اشکالزدایی sudo با استفاده از زیرسیستم “ldap” در اولویتهای diag و info به ترتیب برای مقادیر ۱ و ۲ debug_level ثبت میشوند. برای جزئیات بیشتر در مورد نحوه پیکربندی اشکالزدایی sudo به راهنمای sudo.conf(5) مراجعه کنید.
- SUDOERS_SEARCH_FILTER ldap_filter
- یک فیلتر LDAP که برای محدود کردن مجموعه رکوردهای بازگرداندهشده در هنگام انجام یک پرسوجوی sudo در LDAP به کار میرود. معمولاً به فرمت ‘attribute=value’ یا ‘(&(attribute=value)(attribute2=value2))’ میباشد. فیلتر جستجوی پیشفرض برابر است با: ‘objectClass=sudoRole’. اگر ldap_filter حذف شود، هیچ فیلتر جستجویی استفاده نخواهد شد.
- SUDOERS_TIMED on/true/yes/off/false/no
- مشخص میکند که آیا صفتهای sudoNotBefore و sudoNotAfter که ورودیهای زماندار sudoers را پیادهسازی میکنند ارزیابی شوند یا خیر.
- TIMELIMIT seconds
- پارامتر TIMELIMIT میزان زمان انتظار (به ثانیه) برای دریافت پاسخ پرسوجوی LDAP را مشخص میکند.
- TIMEOUT seconds
- پارامتر TIMEOUT مدت زمان انتظار (به ثانیه) برای دریافت پاسخ از APIهای مختلف LDAP را مشخص میکند.
- TLS_CACERT file name
- نام مستعار برای TLS_CACERTFILE جهت سازگاری با OpenLDAP.
- TLS_CACERTFILE file name
- مسیر به یک
بسته مراجع
صدور گواهی
(CA bundle) که شامل
گواهیهای
تمام مراجع
صدور گواهی
معتبر
شناختهشده
توسط
کلاینت
است، برای
مثال /etc/ssl/ca-bundle.pem.
این گزینه تنها توسط کتابخانههای OpenLDAP پشتیبانی میشود. کتابخانههای LDAP مشتق از Netscape از همان پایگاه داده گواهی برای گواهیهای CA و کلاینت استفاده میکنند (گزینه TLS_CERT را ببینید).
- TLS_CACERTDIR directory
- مشابه با
TLS_CACERTFILE اما به
جای فایل،
پوشهای
شامل
گواهیهای
مجزای
مراجع صدور
گواهی است،
برای مثال
/etc/ssl/certs.
دایرکتوری
مشخصشده
توسط TLS_CACERTDIR پس
از TLS_CACERTFILE
بررسی
میشود.
این گزینه تنها توسط کتابخانههای OpenLDAP پشتیبانی میشود.
- TLS_CERT file name
- مسیر یک فایل حاوی گواهی کلاینت که میتواند برای احراز هویت کلاینت نزد سرور LDAP استفاده شود. نوع گواهی به کتابخانههای LDAP مورد استفاده بستگی دارد.
- OpenLDAP:
- ‘tls_cert /etc/ssl/client_cert.pem’
- مشتق از Netscape:
- ‘tls_cert /var/ldap/cert7.db’
- IBM LDAP:
- استفاده نمیشود؛ پایگاهداده کلید مشخصشده با TLS_KEY شامل هر دو کلیدها و گواهیها است.
هنگام استفاده از کتابخانههای مشتق از Netscape، این فایل ممکن است شامل گواهیهای مرجع صدور گواهی (CA) نیز باشد.
- TLS_CHECKPEER on/true/yes/off/false/no
- اگر فعال
باشد، TLS_CHECKPEER
باعث
اعتبارسنجی
گواهی TLS
سرور LDAP
میشود. اگر
گواهی TLS
سرور تایید
نشود
(معمولاً به
این دلیل که
توسط یک
مرجع صدور
گواهی
ناشناخته
امضا شده
است)، sudo
قادر به
اتصال به آن
نخواهد بود.
اگر TLS_CHECKPEER
غیرفعال
باشد، هیچ
بررسی
انجام
نمیشود.
غیرفعال
کردن این
بررسی
فرصتی برای
حملات مرد
میانی (man-in-the-middle)
ایجاد
میکند
زیرا هویت
سرور احراز
نمیشود. در
صورت
امکان،
گواهی CA
باید به
صورت محلی
نصب شود تا
قابل
اعتبارسنجی
باشد.
این گزینه توسط کتابخانههای IBM LDAP پشتیبانی نمیشود.
- TLS_KEY file name
- مسیر یک فایل حاوی کلید خصوصی که با گواهی مشخصشده توسط TLS_CERT تطابق دارد. کلید خصوصی نباید با گذرواژه محافظت شده باشد. نوع کلید به کتابخانههای LDAP مورد استفاده بستگی دارد.
- OpenLDAP:
- ‘tls_key /etc/ssl/client_key.pem’
- مشتق از Netscape:
- ‘tls_key /var/ldap/key3.db’
- IBM LDAP:
- ‘tls_key /usr/ldap/ldapkey.kdb’
هنگام استفاده از کتابخانههای IBM LDAP، این فایل همچنین ممکن است شامل گواهیهای مرجع صدور گواهی و کلاینت باشد و ممکن است رمزنگاری شده باشد.
- TLS_CIPHERS cipher list
- پارامتر
TLS_CIPHERS به مدیر
سیستم
اجازه
میدهد
الگوریتمهای
رمزنگاری
مجاز برای
اتصالات TLS (SSL)
را محدود
کند. برای
فهرستی از
سایفرهای
معتبر به
راهنمای OpenLDAP
یا IBM Tivoli Directory Server
مراجعه
کنید.
این گزینه توسط کتابخانههای مشتق از Netscape پشتیبانی نمیشود.
- TLS_KEYPW secret
- شامل گذرواژه مورد استفاده برای رمزگشایی پایگاهداده کلید در کلاینتهایی است که از کتابخانه 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 level
- پارامتر TLS_REQCERT نحوه اعتبارسنجی گواهی TLS سرور LDAP را کنترل میکند (در صورت انجام بررسی). اگر گواهی TLS سرور تایید نشود (معمولاً به دلیل اینکه توسط یک مرجع صدور گواهی ناشناخته امضا شده است)، sudo قادر به اتصال به آن نخواهد بود. مقادیر زیر برای level پشتیبانی میشوند:
- never
-
گواهی سرور درخواست یا بررسی نمیشود. - allow
-
گواهی سرور درخواست میشود. گواهی نامعتبر یا گمشده نادیده گرفته شده و خطا تلقی نمیشود. - try
- گواهی سرور درخواست میشود. گواهی ناموجود نادیده گرفته میشود اما گواهی نامعتبر منجر به خطای اتصال خواهد شد.
- demand | hard
- گواهی سرور درخواست خواهد شد. نبود گواهی یا نامعتبر بودن آن منجر به خطای اتصال میشود. این رفتار پیشفرض است.
این گزینه تنها توسط کتابخانههای OpenLDAP پشتیبانی میشود. سایر کتابخانههای LDAP تنها از پارامتر TLS_CHECKPEER پشتیبانی میکنند.
- TLS_RANDFILE file name
- پارامتر
TLS_RANDFILE مسیر
منبع
آنتروپی را
برای
سیستمهایی
که فاقد
دستگاه
اعداد
تصادفی
هستند مشخص
میکند.
عموماً
همراه با prngd
یا egd به کار
میرود.
این گزینه تنها توسط کتابخانههای OpenLDAP پشتیبانی میشود.
- URI ldap[s]://[hostname[:port]] ...
- فهرستی از یک یا چند URI جداشده با فاصله را که سرور(های) LDAP مورد اتصال را توصیف میکنند مشخص میسازد. پروتکل protocol میتواند ldap یا ldaps باشد، که دومی برای سرورهایی است که از رمزنگاری TLS (SSL) پشتیبانی میکنند. اگر هیچ پورتی مشخص نشده باشد، پورت پیشفرض ۳۸۹ برای ‘ldap://’ یا ۶۳۶ برای ‘ldaps://’ است. اگر هیچ نام میزبانی مشخص نشود، sudo به localhost متصل خواهد شد. خطوط متعدد URI دقیقاً مشابه با یک خط URI حاوی چندین ورودی رفتار میکنند. تنها سیستمهایی که از کتابخانههای OpenSSL استفاده میکنند از ترکیب URIهای ‘ldap://’ و ‘ldaps://’ پشتیبانی مینمایند. هر دو کتابخانه مشتق از Netscape و IBM LDAP که در بیشتر نسخههای تجاری یونیکس استفاده میشوند تنها قادر به پشتیبانی از یکی از آنها هستند.
- USE_SASL on/true/yes/off/false/no
- گزینه USE_SASL را برای سرورهای LDAP که از احراز هویت SASL پشتیبانی میکنند فعال کنید.
- ROOTSASL_AUTH_ID identity
- نام کاربری SASL برای استفاده هنگامی که ROOTUSE_SASL فعال باشد.
مدخل ldap.conf در بخش مثالها (EXAMPLES) را ببینید.
پیکربندی nsswitch.conf (Configuring nsswitch.conf)
مگر در مواردی که در زمان ساخت برنامه غیرفعال شده باشد، sudo فایل Name Service Switch یعنی /etc/nsswitch.conf را برای تعیین ترتیب جستجوی sudoers بررسی میکند. دستور sudo به دنبال خطی میگردد که با sudoers: آغاز شود و از آن برای تعیین ترتیب جستجو استفاده میکند. به طور پیشفرض، sudo پس از اولین تطبیق جستجو را متوقف نمیکند و تطبیقهای بعدی بر تطبیقهای قبلی ارجحیت دارند (مگر اینکه از ‘[SUCCESS=return]’ استفاده شود، به پایین مراجعه کنید). منابع زیر شناسایی میشوند:
علاوه بر این، زیرمجموعهای از دستورات عملیاتی به سبک 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 (به پایین مراجعه کنید).
پیکربندی netsvc.conf (Configuring netsvc.conf)
در سیستمهای 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
یکپارچهسازی با sssd (Integration with sssd)
در سیستمهایی که دارای دیمن خدمات امنیتی سیستم 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) مراجعه نمایید.
فایلها (FILES)
- /etc/openldap/ldap.conf
- فایل پیکربندی LDAP
- /etc/nsswitch.conf
- تعیینترتیب منابع sudoers
- /etc/netsvc.conf
- تعیینترتیب منابع sudoers در AIX
مثالها (EXAMPLES)
نمونه ldap.conf (Example ldap.conf)
# 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
طرحواره Sudoers برای OpenLDAP (Sudoers schema for OpenLDAP)
طرحواره زیر، در قالب 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 )
)
همچنین ببینید (SEE ALSO)
cvtsudoers(1), ldap.conf(5), sssd-sudo(5), sudo.conf(5), sudoers(5)
نویسندگان (AUTHORS)
افراد بسیاری در طول سالها روی sudo کار کردهاند؛ این نسخه از کدهایی تشکیل شده که اصولاً توسط شخص زیر نوشته شده است:
برای مشاهده فهرست کامل افرادی که در پروژه sudo مشارکت داشتهاند، فایل CONTRIBUTORS.md را در توزیع sudo (https://www.sudo.ws/about/contributors) ببینید.
هشدارها (CAVEATS)
تفاوتهایی در نحوه تجزیه sudoers مبتنی بر LDAP در مقایسه با sudoers مبتنی بر فایل وجود دارد. برای اطلاعات بیشتر بخش تفاوتهای میان sudoers مبتنی بر LDAP و فایل معمولی را مشاهده نمایید.
گزارش اشکالات (BUGS)
اگر فکر میکنید اشکالی در 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 رمزنگاری کنید.
پشتیبانی (SUPPORT)
پشتیبانی رایگان و محدود از طریق فهرست پستی sudo-users در دسترس است؛ برای عضویت یا جستجو در آرشیوها نشانی https://www.sudo.ws/mailman/listinfo/sudo-users را مشاهده نمایید.
سلب مسئولیت (DISCLAIMER)
برنامه sudo «همانگونه که هست» (AS IS) ارائه میشود و هرگونه ضمانت صریح یا ضمنی، از جمله، اما نه محدود به، ضمانتهای ضمنی قابلیت خرید و فروش و تناسب برای یک هدف خاص سلب میگردد. برای جزئیات کامل، فایل LICENSE.md توزیعشده با sudo یا نشانی https://www.sudo.ws/about/license را ببینید.
| مه ۲۰۲۵ | sudo |