SSSD-AD(5) File Formats and Conventions SSSD-AD(5)

sssd-ad - ارائه‌دهنده Active Directory برای SSSD

این صفحه راهنما، پیکربندی ارائه‌دهنده AD را برای sssd(8) شرح می‌دهد. برای مرجع دقیق ساختار، به بخش “FILE FORMAT” در صفحه راهنمای sssd.conf(5) مراجعه کنید.

ارائه‌دهنده AD یک بک‌اند است که برای اتصال به سرور Active Directory به کار می‌رود. این ارائه‌دهنده مستلزم پیوستن ماشین به دامین AD و در دسترس بودن یک keytab است. ارتباط بک‌اند روی یک کانال رمزنگاری‌شده با GSSAPI انجام می‌شود؛ گزینه‌های SSL/TLS نباید همراه با ارائه‌دهنده AD استفاده شوند و استفاده از Kerberos جایگزین آن‌ها خواهد شد.

ارائه‌دهنده AD از اتصال به Active Directory 2008 R2 یا نسخه‌های جدیدتر پشتیبانی می‌کند. نسخه‌های قدیمی‌تر ممکن است کار کنند، اما پشتیبانی نمی‌شوند.

ارائه‌دهنده AD می‌تواند برای دریافت اطلاعات کاربران و احراز هویت کاربران دامین‌های مورد اعتماد استفاده شود. در حال حاضر تنها دامین‌های مورد اعتماد در همان forest شناسایی می‌شوند. علاوه بر این، سرورهای دامین‌های مورد اعتماد همیشه به‌صورت خودکار شناسایی می‌شوند.

ارائه‌دهنده AD به SSSD امکان می‌دهد از ارائه‌دهنده هویت sssd-ldap(5) و ارائه‌دهنده احراز هویت sssd-krb5(5) همراه با بهینه‌سازی‌هایی برای محیط‌های Active Directory استفاده کند. ارائه‌دهنده AD با چند استثنا، همان گزینه‌های مورد استفاده در ارائه‌دهنده‌های sssd-ldap و sssd-krb5 را می‌پذیرد. با این حال، تنظیم این گزینه‌ها نه لازم است و نه توصیه می‌شود.

ارائه‌دهنده AD اساساً گزینه‌های پیش‌فرض ارائه‌دهنده‌های سنتی ldap و krb5 را با چند استثنا کپی می‌کند؛ تفاوت‌ها در بخش “MODIFIED DEFAULT OPTIONS” فهرست شده‌اند.

ارائه‌دهنده AD همچنین می‌تواند به عنوان ارائه‌دهنده access،‏ chpass،‏ sudo و autofs استفاده شود. هیچ پیکربندی خاصی برای ارائه‌دهنده دسترسی در سمت کلاینت لازم نیست.

اگر “auth_provider=ad” یا “access_provider=ad” در sssd.conf پیکربندی شده باشد، id_provider نیز باید روی “ad” تنظیم شود.

به‌طور پیش‌فرض، ارائه‌دهنده AD مقادیر UID و GID را از پارامتر objectSID در Active Directory نگاشت می‌کند. برای جزئیات در این باره، بخش “نگاشت شناسه (ID MAPPING)” را در زیر ببینید. اگر می‌خواهید نگاشت شناسه را غیرفعال کرده و در عوض به ویژگی‌های POSIX تعریف‌شده در Active Directory تکیه کنید، باید مقدار زیر را تنظیم کنید:

ldap_id_mapping = False

در صورت استفاده از ویژگی‌های POSIX، به دلایل کارایی توصیه می‌شود این ویژگی‌ها در Global Catalog نیز تکثیر (replicate) شوند. اگر ویژگی‌های POSIX تکثیر شده باشند، SSSD تلاش می‌کند تا دامین یک شناسه عددی درخواستی را به کمک Global Catalog مکان‌یابی کرده و تنها آن دامین را جستجو کند. در مقابل، اگر ویژگی‌های POSIX در Global Catalog تکثیر نشده باشند، SSSD باید تمام دامین‌های موجود در forest را به‌صورت متوالی جستجو کند. لطفاً توجه داشته باشید که گزینه “cache_first” نیز ممکن است در سرعت بخشیدن به جستجوهای بدون دامین مفید باشد. توجه داشته باشید که اگر تنها زیرمجموعه‌ای از ویژگی‌های POSIX در Global Catalog موجود باشد، ویژگی‌های تکثیرنشده در حال حاضر از پورت LDAP خوانده نمی‌شوند.

کاربران، گروه‌ها و سایر موجودیت‌های ارائه‌شده توسط SSSD، جهت سازگاری با پیاده‌سازی LDAP در Active Directory، در ارائه‌دهنده AD همواره بدون حساسیت به حروف کوچک و بزرگ در نظر گرفته می‌شوند.

‏SSSD تنها گروه‌های امنیتی (Security Groups) مربوط به Active Directory را حل‌وفصل می‌کند. برای اطلاعات بیشتر پیرامون انواع گروه‌های AD ببینید: Active Directory security groups[1]

‏SSSD گروه‌های Domain Local را از دامین‌های دوردست در forest متعلق به AD فیلتر می‌کند. به‌طور پیش‌فرض برای نمونه هنگام دنبال کردن سلسله‌مراتب گروه‌های تو‌در‌تو در دامین‌های دوردست، آن‌ها فیلتر می‌شوند زیرا در دامین محلی معتبر نیستند. این کار به منظور هم‌خوانی با تخصیص عضویت گروهی Active Directory انجام می‌شود که در PAC بلیت Kerberos صادرشده از سوی Active Directory برای کاربر قابل مشاهده است.

برای جزئیات مربوط به پیکربندی دامین SSSD، به بخش “DOMAIN SECTIONS” در صفحه راهنمای sssd.conf(5) مراجعه کنید.

ad_domain (string)

نام دامین Active Directory را مشخص می‌کند. این گزینه اختیاری است. در صورت ارائه نشدن، نام دامین پیکربندی استفاده می‌شود.

برای کارکرد درست، این گزینه باید به صورت نسخه تماماً حروف کوچک از نام کامل دامین Active Directory مشخص شود.

نام کوتاه دامین (شناخته‌شده به عنوان نام NetBIOS یا نام flat) به‌طور خودکار توسط SSSD شناسایی می‌شود.

ad_enabled_domains (string)

فهرستی از دامین‌های فعال‌شده Active Directory که با کاما از هم جدا شده‌اند. در صورت ارائه، SSSD دامین‌هایی را که در این گزینه ذکر نشده‌اند نادیده می‌گیرد. در صورت خالی بودن، همه دامین‌های کشف‌شده از AD forest در دسترس خواهند بود.

در طول شناسایی دامین‌ها، SSSD برخی دامین‌ها را که فلگ‌ها یا ویژگی‌هایشان نشان می‌دهد به forest محلی تعلق ندارند یا غیرقابل‌اعتماد هستند، فیلتر می‌کند. در صورت تنظیم ad_enabled_domains، ارائه‌دهنده SSSD تلاش می‌کند تمام دامین‌های ذکرشده را فعال کند.

برای کارکرد درست، این گزینه باید تماماً با حروف کوچک و به عنوان نام دامنه کاملاً واجد شرایط (FQDN) دامین Active Directory مشخص شود. برای نمونه:

ad_enabled_domains = sales.example.com, eng.example.com

نام کوتاه دامین (معروف به نام NetBIOS یا نام flat) به‌طور خودکار توسط SSSD شناسایی خواهد شد.

پیش‌فرض: تنظیم‌نشده

ad_server, ad_backup_server (string)

فهرست جداشده با کاما از نام‌های میزبان سرورهای AD که SSSD باید به ترتیب اولویت به آن‌ها متصل شود. برای اطلاعات بیشتر درباره جایگزینی هنگام خرابی و افزونگی سرور، به بخش “جایگزینی هنگام خرابی (FAILOVER)” مراجعه کنید.

در صورت فعال بودن شناسایی خودکار، این گزینه اختیاری است. برای اطلاعات بیشتر در خصوص شناسایی سرویس، به بخش “شناسایی سرویس (SERVICE DISCOVERY)” مراجعه کنید.

نکته: دامین‌های مورد اعتماد همواره سرورها را به‌طور خودکار شناسایی می‌کنند، حتی اگر سرور اصلی صراحتاً در گزینه ad_server تعریف شده باشد.

ad_hostname (string)

اختیاری. در ماشین‌هایی که hostname(5) بازتاب‌دهنده نام کاملاً واجد شرایط نیست، sssd تلاش می‌کند تا نام کوتاه را گسترش دهد. اگر این امر ممکن نیست یا باید واقعاً از نام کوتاه استفاده شود، این پارامتر را صراحتاً تنظیم کنید.

این فیلد برای تعیین host principal مورد استفاده در keytab و انجام به‌روزرسانی‌های پویای DNS به کار می‌رود. این مقدار باید با نام میزبانی که keytab برای آن صادر شده مطابقت داشته باشد.

ad_enable_dns_sites (boolean)

سایت‌های DNS را فعال می‌کند - شناسایی سرویس مبتنی بر موقعیت مکانی.

اگر مقدار true باشد و شناسایی سرویس (بند Service Discovery در انتهای صفحه راهنما را ببینید) فعال باشد، SSSD ابتدا تلاش می‌کند تا با استفاده از Active Directory Site Discovery، سرور Active Directory را برای اتصال شناسایی کند و در صورتی که هیچ سایت AD یافت نشد، به رکوردهای DNS SRV بازگردد. پیکربندی DNS SRV، شامل دامین شناسایی، در حین شناسایی سایت نیز مورد استفاده قرار می‌گیرد.

پیش‌فرض: true

ad_access_filter (string)

یک فیلتر کنترل دسترسی LDAP را مشخص می‌کند که کاربر برای به دست آوردن دسترسی باید با آن تطابق داشته باشد. برای اثرگذاری این گزینه، مقدار “access_provider” باید صراحتاً روی “ad” تنظیم شده باشد. اگر می‌خواهید از “ad_access_filter” به عنوان تنها شیوه کنترل دسترسی استفاده کنید، باید کنترل دسترسی مبتنی بر GPO را غیرفعال کنید (برای جزئیات، گزینه “ad_gpo_access_control” را ببینید).

این گزینه همچنین از تعیین فیلترهای متفاوت به ازای هر دامین یا forest پشتیبانی می‌کند. این فیلتر تعمیم‌یافته متشکل است از: “KEYWORD:NAME:FILTER”. کلمه کلیدی می‌تواند “DOM”،‏ “FOREST” یا خالی باشد.

اگر کلمه کلیدی برابر با “DOM” یا خالی باشد، “NAME” دامین یا زیردامینی را که فیلتر روی آن اعمال می‌شود تعیین می‌کند. اگر کلمه کلیدی برابر با “FOREST” باشد، فیلتر روی تمام دامین‌های متعلق به forest تعیین‌شده با “NAME” اعمال خواهد شد.

مشابه شیوه عملکرد پایه‌های جستجو (search bases)، فیلترهای چندگانه را می‌توان با نویسه “?” از یکدیگر جدا کرد.

عضویت در گروه‌های تو‌در‌تو باید با استفاده از یک OID ویژه “:1.2.840.113556.1.4.1941:” علاوه بر ساختار کامل DOM:domain.example.org: جستجو شود تا اطمینان حاصل گردد تجزیه‌کننده نویسه‌های دونقطه مربوط به OID را تفسیر نخواهد کرد. اگر از این OID استفاده نکنید، عضویت در گروه‌های تو‌در‌تو حل‌وفصل نخواهد شد. مثال کاربردی زیر را ببینید و برای اطلاعات بیشتر درباره این OID به اینجا مراجعه کنید: [MS-ADTS] section LDAP extensions[2]

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

مثال‌ها:

# اعمال فیلتر فقط روی دامین با نام dom1:
dom1:(memberOf=cn=admins,ou=groups,dc=dom1,dc=com)
# اعمال فیلتر فقط روی دامین با نام dom2:
DOM:dom2:(memberOf=cn=admins,ou=groups,dc=dom2,dc=com)
# اعمال فیلتر فقط روی forest با نام EXAMPLE.COM:
FOREST:EXAMPLE.COM:(memberOf=cn=admins,ou=groups,dc=example,dc=com)
# اعمال فیلتر برای عضوی از یک گروه تو‌در‌تو در dom1:
DOM:dom1:(memberOf:1.2.840.113556.1.4.1941:=cn=nestedgroup,ou=groups,dc=example,dc=com)

پیش‌فرض: تنظیم‌نشده

ad_site (string)

سایت AD را که کلاینت باید برای اتصال به آن تلاش کند مشخص می‌سازد. در صورت ارائه نشدن این گزینه، سایت AD به‌صورت خودکار شناسایی خواهد شد.

پیش‌فرض: تنظیم‌نشده

ad_enable_gc (boolean)

به‌طور پیش‌فرض، SSSD ابتدا به Global Catalog متصل می‌شود تا کاربران را از دامین‌های مورد اعتماد بازیابی کند و از پورت LDAP برای بازیابی عضویت‌های گروهی یا به عنوان پشتیبان استفاده می‌نماید. غیرفعال کردن این گزینه سبب می‌شود SSSD تنها به پورت LDAP سرور AD فعلی متصل گردد.

لطفاً توجه داشته باشید که غیرفعال کردن پشتیبانی از Global Catalog، بازیابی کاربران از دامین‌های مورد اعتماد را غیرفعال نمی‌سازد. در این حالت SSSD در عوض به پورت LDAP دامین‌های مورد اعتماد متصل خواهد شد. با این حال، به منظور حل‌وفصل عضویت‌های گروهی بین‌دامینی، استفاده از Global Catalog الزامی است.

پیش‌فرض: true

ad_gpo_access_control (string)

این گزینه حالت عملیاتی را برای قابلیت کنترل دسترسی مبتنی بر GPO تعیین می‌کند: اینکه در حالت غیرفعال، حالت اجباری (enforcing) یا حالت مجاز (permissive) عمل کند. لطفاً توجه داشته باشید که گزینه “access_provider” باید صراحتاً روی “ad” تنظیم شده باشد تا این گزینه اثرگذار شود.

قابلیت کنترل دسترسی مبتنی بر GPO از تنظیمات خط‌مشی GPO برای تعیین اینکه آیا یک کاربر مشخص مجاز به ورود به میزبان است یا خیر استفاده می‌کند. برای اطلاعات بیشتر پیرامون تنظیمات خط‌مشی‌های پشتیبانی‌شده لطفاً به گزینه‌های “ad_gpo_map” مراجعه کنید.

لطفاً توجه داشته باشید که نسخه فعلی SSSD از گروه‌های توکار (built-in) در Active Directory پشتیبانی نمی‌کند. گروه‌های توکار (مانند Administrators با SID S-1-5-32-544) در قوانین کنترل دسترسی GPO توسط SSSD نادیده گرفته می‌شوند. ردیاب مشکلات بالادستی را در https://github.com/SSSD/sssd/issues/5063 ببینید.

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

•Read: کاربر یا یکی از گروه‌های آن باید دسترسی خواندن به ویژگی‌های GPO را داشته باشد (RIGHT_DS_READ_PROPERTY)
•Apply Group Policy: کاربر یا دست‌کم یکی از گروه‌های آن باید مجاز به اعمال GPO باشد (RIGHT_DS_CONTROL_ACCESS).

به‌طور پیش‌فرض، گروه Authenticated Users روی یک GPO حضور دارد و این گروه دارای هر دو حق دسترسی Read و Apply Group Policy است. از آنجا که احراز هویت یک کاربر پیش از آغاز فیلترسازی امنیتی GPO و کنترل دسترسی باید با موفقیت انجام شده باشد، مجوزهای گروه Authenticated Users روی GPO همواره بر کاربر نیز اعمال می‌شود.

نکته: اگر حالت عملیاتی روی enforcing تنظیم شود، ممکن است کاربرانی که پیش‌تر اجازه ورود داشتند، اکنون از ورود منع شوند (همان‌طور که تنظیمات خط‌مشی GPO تعیین می‌کند). برای تسهیل انتقال روان برای مدیران سیستم، یک حالت permissive در دسترس است که قوانین کنترل دسترسی را اعمال نمی‌کند، اما آنها را ارزیابی کرده و در صورتی که دسترسی رد می‌شد یک پیام syslog صادر می‌کند. مدیران سیستم می‌توانند با بررسی لاگ‌ها، تغییرات لازم را پیش از تنظیم حالت روی enforcing انجام دهند. برای ثبت لاگ کنترل دسترسی مبتنی بر GPO، سطح اشکال‌زدایی 'trace functions' مورد نیاز است (صفحه راهنمای sssctl(8) را ببینید).

سه مقدار پشتیبانی‌شده برای این گزینه وجود دارد:

•disabled: قوانین کنترل دسترسی مبتنی بر GPO نه ارزیابی می‌شوند و نه اعمال.
•enforcing: قوانین کنترل دسترسی مبتنی بر GPO ارزیابی و اعمال می‌شوند.
•permissive: قوانین کنترل دسترسی مبتنی بر GPO ارزیابی می‌شوند، اما اعمال نمی‌شوند. در عوض، یک پیام syslog صادر خواهد شد که نشان می‌دهد اگر مقدار این گزینه روی enforcing تنظیم شده بود، دسترسی کاربر رد می‌شد.

پیش‌فرض: enforcing

ad_gpo_implicit_deny (boolean)

به‌طور معمول وقتی هیچ GPO قابل اعمالی یافت نشود، به کاربران اجازه دسترسی داده می‌شود. هنگامی که این گزینه روی True تنظیم شود، به کاربران تنها در صورتی اجازه دسترسی داده خواهد شد که صراحتاً توسط یک قانون GPO مجاز شده باشند. در غیر این صورت دسترسی کاربران رد خواهد شد. از این گزینه می‌توان برای سخت‌سازی امنیت استفاده کرد، اما در استفاده از آن احتیاط کنید زیرا اگر هیچ قانونی از GPO بر کاربران گروه توکار Administrators اعمال نشود، می‌تواند حتی دسترسی آنان را نیز رد کند.

پیش‌فرض: False

۲ جدول زیر نشان می‌دهند که چه زمانی یک کاربر بر اساس حقوق ورود allow و deny تعریف‌شده در سمت سرور و تنظیم ad_gpo_implicit_deny مجاز شناخته شده یا رد می‌شود.

ad_gpo_implicit_deny = False (پیش‌فرض)
قوانین allow قوانین deny نتایج
ناموجود ناموجود همه کاربران مجاز هستند
ناموجود موجود تنها کاربرانی که در قوانین deny نیستند مجاز هستند
موجود ناموجود تنها کاربرانی که در قوانین allow هستند مجاز هستند
موجود موجود تنها کاربرانی که در قوانین allow هستند و در قوانین deny نیستند مجاز هستند
ad_gpo_implicit_deny = True
قوانین allow قوانین deny نتایج
ناموجود ناموجود هیچ کاربری مجاز نیست
ناموجود موجود هیچ کاربری مجاز نیست
موجود ناموجود تنها کاربرانی که در قوانین allow هستند مجاز هستند
موجود موجود تنها کاربرانی که در قوانین allow هستند و در قوانین deny نیستند مجاز هستند

ad_gpo_ignore_unreadable (boolean)

به‌طور معمول وقتی برخی کانتینرهای خط‌مشی گروه (شیء AD) مربوط به اشیاء خط‌مشی گروهِ قابل‌اعمال برای SSSD قابل خواندن نباشند، دسترسی کاربران رد می‌شود. این گزینه اجازه می‌دهد تا کانتینرهای خط‌مشی گروه و خط‌مشی‌های مرتبط با آنها، در صورتی که مشخصه‌های آنها در کانتینرهای خط‌مشی گروه برای SSSD قابل خواندن نباشد، نادیده گرفته شوند.

پیش‌فرض: False

ad_gpo_cache_timeout (integer)

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

پیش‌فرض: 5 (ثانیه)

ad_gpo_map_interactive (string)

فهرستی جداشده با کاما از نام‌های سرویس PAM که کنترل دسترسی مبتنی بر GPO برای آنها بر اساس تنظیمات خط‌مشی InteractiveLogonRight و DenyInteractiveLogonRight ارزیابی می‌شود. تنها آن دسته از GPOهایی ارزیابی می‌شوند که کاربر مجوز Read و Apply Group Policy را برای آنها دارد (گزینه “ad_gpo_access_control” را ببینید). اگر یک GPO ارزیابی‌شده شامل تنظیم deny interactive logon برای کاربر یا یکی از گروه‌های آن باشد، دسترسی محلی کاربر رد می‌شود. اگر در هیچ‌یک از GPOهای ارزیابی‌شده حق ورود تعاملی تعریف نشده باشد، به کاربر دسترسی محلی داده می‌شود. اگر دست‌کم یک GPO ارزیابی‌شده شامل تنظیمات حق ورود تعاملی باشد، دسترسی محلی به کاربر تنها در صورتی داده می‌شود که خودش یا دست‌کم یکی از گروه‌هایش بخشی از تنظیمات خط‌مشی باشند.

نکته: در Group Policy Management Editor این مقدار “Allow log on locally” و “Deny log on locally” نامیده می‌شود.

امکان افزودن نام یک سرویس PAM دیگر به مجموعه پیش‌فرض با استفاده از “+service_name” یا حذف صریح یک نام سرویس PAM از مجموعه پیش‌فرض با استفاده از “-service_name” وجود دارد. برای نمونه، جهت جایگزینی یک نام پیش‌فرض سرویس PAM برای این حق ورود (مانند “login”) با یک نام سرویس PAM سفارشی (مانند “my_pam_service”)، می‌توان از پیکربندی زیر استفاده کرد:

ad_gpo_map_interactive = +my_pam_service, -login

پیش‌فرض: مجموعه پیش‌فرض نام‌های سرویس PAM شامل موارد زیر است:

•login
•su
•su-l
•gdm-fingerprint
•gdm-password
•gdm-smartcard
•kdm
•lightdm
•lxdm
•plasmalogin
•sddm
•unity
•xdm

ad_gpo_map_remote_interactive (رشته)

فهرستی از نام‌های سرویس PAM جداشده با کاما که کنترل دسترسی مبتنی بر GPO برای آن‌ها بر اساس تنظیمات خط‌مشی RemoteInteractiveLogonRight و DenyRemoteInteractiveLogonRight ارزیابی می‌شود. تنها GPOهایی ارزیابی می‌شوند که کاربر برای آن‌ها مجوز Read و Apply Group Policy داشته باشد (گزینه “ad_gpo_access_control” را ببینید). اگر یک GPO ارزیابی‌شده حاوی تنظیم منع ورود از راه دور برای کاربر یا یکی از گروه‌های آن باشد، دسترسی تعاملی از راه دور به کاربر داده نخواهد شد. اگر در هیچ‌یک از GPOهای ارزیابی‌شده مجوزی برای ورود تعاملی از راه دور تعریف نشده باشد، به کاربر دسترسی از راه دور داده می‌شود. اگر حداقل یک GPO ارزیابی‌شده حاوی تنظیمات حق ورود تعاملی از راه دور باشد، دسترسی از راه دور تنها در صورتی به کاربر داده می‌شود که خود کاربر یا حداقل یکی از گروه‌های آن بخشی از تنظیمات خط‌مشی باشند.

نکته: در Group Policy Management Editor، این مقدار تحت عناوین "Allow log on through Remote Desktop Services" و "Deny log on through Remote Desktop Services" نامیده می‌شود.

می‌توان با استفاده از “+service_name” یک نام سرویس PAM دیگر به مجموعه پیش‌فرض افزود یا با استفاده از “-service_name” یک نام سرویس PAM را صراحتاً از مجموعه پیش‌فرض حذف کرد. برای مثال، به‌منظور جایگزینی یک نام سرویس PAM پیش‌فرض برای این حق ورود (مانند “sshd”) با یک نام سرویس PAM سفارشی (مانند “my_pam_service”)، می‌توان از پیکربندی زیر استفاده کرد:

ad_gpo_map_remote_interactive = +my_pam_service, -sshd

پیش‌فرض: مجموعه پیش‌فرض نام‌های سرویس PAM شامل موارد زیر است:

•sshd
•cockpit

ad_gpo_map_network (رشته)

فهرستی از نام‌های سرویس PAM جداشده با کاما که کنترل دسترسی مبتنی بر GPO برای آن‌ها بر اساس تنظیمات خط‌مشی NetworkLogonRight و DenyNetworkLogonRight ارزیابی می‌شود. تنها GPOهایی ارزیابی می‌شوند که کاربر برای آن‌ها مجوز Read و Apply Group Policy داشته باشد (گزینه “ad_gpo_access_control” را ببینید). اگر یک GPO ارزیابی‌شده حاوی تنظیم منع ورود از طریق شبکه برای کاربر یا یکی از گروه‌های آن باشد، دسترسی ورود از طریق شبکه به کاربر داده نخواهد شد. اگر در هیچ‌یک از GPOهای ارزیابی‌شده مجوزی برای ورود از طریق شبکه تعریف نشده باشد، به کاربر دسترسی ورود داده می‌شود. اگر حداقل یک GPO ارزیابی‌شده حاوی تنظیمات حق ورود از طریق شبکه باشد، دسترسی ورود تنها در صورتی به کاربر داده می‌شود که خود کاربر یا حداقل یکی از گروه‌های آن بخشی از تنظیمات خط‌مشی باشند.

نکته: در Group Policy Management Editor، این مقدار تحت عناوین "Access this computer from the network" و "Deny access to this computer from the network" نامیده می‌شود.

می‌توان با استفاده از “+service_name” یک نام سرویس PAM دیگر به مجموعه پیش‌فرض افزود یا با استفاده از “-service_name” یک نام سرویس PAM را صراحتاً از مجموعه پیش‌فرض حذف کرد. برای مثال، به‌منظور جایگزینی یک نام سرویس PAM پیش‌فرض برای این حق ورود (مانند “ftp”) با یک نام سرویس PAM سفارشی (مانند “my_pam_service”)، می‌توان از پیکربندی زیر استفاده کرد:

ad_gpo_map_network = +my_pam_service, -ftp

پیش‌فرض: مجموعه پیش‌فرض نام‌های سرویس PAM شامل موارد زیر است:

•ftp
•samba

ad_gpo_map_batch (string)

فهرستی از نام‌های سرویس PAM جداشده با کاما که کنترل دسترسی مبتنی بر GPO برای آن‌ها بر اساس تنظیمات خط‌مشی BatchLogonRight و DenyBatchLogonRight ارزیابی می‌شود. تنها آن دسته از GPOهایی ارزیابی می‌شوند که کاربر مجوز Read و Apply Group Policy را برای آن‌ها داشته باشد (گزینه “ad_gpo_access_control” را ببینید). اگر یک GPO ارزیابی‌شده حاوی تنظیم رد ورود دسته‌ای (deny batch logon) برای کاربر یا یکی از گروه‌هایش باشد، دسترسی ورود دسته‌ای کاربر رد می‌شود. اگر هیچ‌یک از GPOهای ارزیابی‌شده دارای حق ورود دسته‌ای تعریف‌شده نباشد، به کاربر دسترسی ورود داده می‌شود. اگر دست‌کم یک GPO ارزیابی‌شده شامل تنظیمات حق ورود دسته‌ای باشد، کاربر تنها در صورتی مجاز به ورود است که خود یا حداقل یکی از گروه‌هایش بخشی از تنظیمات این خط‌مشی باشند.

نکته: در Group Policy Management Editor این مقدار “Allow log on as a batch job” و “Deny log on as a batch job” نامیده می‌شود.

می‌توان با استفاده از “+service_name” یک نام سرویس PAM دیگر را به مجموعه پیش‌فرض افزود یا با استفاده از “-service_name” صریحاً یک نام سرویس PAM را از مجموعه پیش‌فرض حذف کرد. برای نمونه، جهت جایگزین کردن یک نام سرویس پیش‌فرض PAM برای این حق ورود (مانند “crond”) با یک نام سرویس pam سفارشی (مانند “my_pam_service”)، از پیکربندی زیر استفاده می‌شود:

ad_gpo_map_batch = +my_pam_service, -crond

نکته: نام سرویس Cron ممکن است بسته به توزیع لینوکس مورد استفاده متفاوت باشد.

پیش‌فرض: مجموعه پیش‌فرض نام‌های سرویس PAM شامل موارد زیر است:

•crond

ad_gpo_map_service (string)

فهرستی از نام‌های سرویس PAM جداشده با کاما که کنترل دسترسی مبتنی بر GPO برای آن‌ها بر اساس تنظیمات خط‌مشی ServiceLogonRight و DenyServiceLogonRight ارزیابی می‌شود. تنها آن دسته از GPOهایی ارزیابی می‌شوند که کاربر مجوز Read و Apply Group Policy را برای آن‌ها داشته باشد (گزینه “ad_gpo_access_control” را ببینید). اگر یک GPO ارزیابی‌شده حاوی تنظیم رد ورود سرویس (deny service logon) برای کاربر یا یکی از گروه‌هایش باشد، دسترسی ورود سرویس کاربر رد می‌شود. اگر هیچ‌یک از GPOهای ارزیابی‌شده دارای حق ورود سرویس تعریف‌شده نباشد، به کاربر دسترسی ورود داده می‌شود. اگر دست‌کم یک GPO ارزیابی‌شده شامل تنظیمات حق ورود سرویس باشد، کاربر تنها در صورتی مجاز به ورود است که خود یا حداقل یکی از گروه‌هایش بخشی از تنظیمات این خط‌مشی باشند.

نکته: در Group Policy Management Editor این مقدار “Allow log on as a service” و “Deny log on as a service” نامیده می‌شود.

می‌توان با استفاده از “+service_name” یک نام سرویس PAM را به مجموعه پیش‌فرض افزود. از آن‌جا که مجموعه پیش‌فرض خالی است، حذف نام سرویس PAM از مجموعه پیش‌فرض امکان‌پذیر نیست. برای نمونه، جهت افزودن یک نام سرویس pam سفارشی (مانند “my_pam_service”)، از پیکربندی زیر استفاده می‌شود:

ad_gpo_map_service = +my_pam_service

پیش‌فرض: تنظیم نشده است

ad_gpo_map_permit (string)

فهرستی از نام‌های سرویس PAM جداشده با کاما که دسترسی مبتنی بر GPO برای آن‌ها همیشه مجاز دانسته می‌شود، صرف‌نظر از هرگونه GPO Logon Rights.

می‌توان با استفاده از “+service_name” یک نام سرویس PAM دیگر را به مجموعه پیش‌فرض افزود یا با استفاده از “-service_name” صریحاً یک نام سرویس PAM را از مجموعه پیش‌فرض حذف کرد. برای نمونه، جهت جایگزین کردن یک نام سرویس پیش‌فرض PAM برای دسترسی بدون قید و شرط مجاز (مانند “sudo”) با یک نام سرویس pam سفارشی (مانند “my_pam_service”)، از پیکربندی زیر استفاده می‌شود:

ad_gpo_map_permit = +my_pam_service, -sudo

پیش‌فرض: مجموعه پیش‌فرض نام‌های سرویس PAM شامل موارد زیر است:

•polkit-1
•sudo
•sudo-i
•systemd-user

ad_gpo_map_deny (string)

فهرستی از نام‌های سرویس PAM جداشده با کاما که دسترسی مبتنی بر GPO برای آن‌ها همیشه رد می‌شود، صرف‌نظر از هرگونه GPO Logon Rights.

می‌توان با استفاده از “+service_name” یک نام سرویس PAM را به مجموعه پیش‌فرض افزود. از آن‌جا که مجموعه پیش‌فرض خالی است، حذف نام سرویس PAM از مجموعه پیش‌فرض امکان‌پذیر نیست. برای نمونه، جهت افزودن یک نام سرویس pam سفارشی (مانند “my_pam_service”)، از پیکربندی زیر استفاده می‌شود:

ad_gpo_map_deny = +my_pam_service

پیش‌فرض: تنظیم نشده است

ad_gpo_default_right (string)

این گزینه نحوه ارزیابی کنترل دسترسی را برای نام‌های سرویس PAM که صریحاً در یکی از گزینه‌های ad_gpo_map_* فهرست نشده‌اند، مشخص می‌کند. این گزینه را می‌توان به دو روش مختلف تنظیم کرد. نخست، این گزینه می‌تواند برای استفاده از یک حق ورود پیش‌فرض تنظیم شود. برای نمونه، اگر این گزینه روی 'interactive' تنظیم شود، به این معنی است که نام‌های سرویس PAM نگاشت‌نشده بر اساس تنظیمات خط‌مشی InteractiveLogonRight و DenyInteractiveLogonRight پردازش خواهند شد. در حالت دیگر، می‌توان این گزینه را طوری تنظیم کرد که همواره دسترسی برای نام‌های سرویس PAM نگاشت‌نشده را مجاز دانسته یا همیشه رد کند.

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

•interactive
•remote_interactive
•network
•batch
•service
•permit
•deny

پیش‌فرض: deny

ad_maximum_machine_account_password_age (عدد صحیح)

‏SSSD روزی یک بار بررسی می‌کند که آیا سن گذرواژهٔ حساب ماشین از مقدار ارائه‌شده بر حسب روز بیشتر است یا خیر، و برای تمدید آن تلاش می‌کند. مقدار 0 تلاش برای تمدید را غیرفعال می‌کند.

پیش‌فرض: ۳۰ روز

ad_machine_account_password_renewal_opts (رشته)

این گزینه تنها باید برای آزمودن وظیفهٔ تمدید حساب ماشین استفاده شود. این گزینه ۳ عدد صحیح و یک رشته را که با دو نقطه (':') جدا شده‌اند می‌پذیرد. عدد صحیح نخست، فاصلهٔ زمانی به ثانیه را برای چگونگی اجرای متناوب این وظیفه تعیین می‌کند. عدد دوم، مهلت زمانی اولیه را بر حسب ثانیه پیش از نخستین اجرای وظیفه پس از راه‌اندازی مشخص می‌کند. مقدار سوم اختیاری، بیشینهٔ آفست تصادفی را نسبت به دو مقدار پیشین تعیین می‌کند تا از به‌روزرسانی هم‌زمان چندین میزبان جلوگیری شود (مسئلهٔ “thundering herd”). اگر این مقدار در رشتهٔ مقدار موجود نباشد یا خالی باشد، '0' استفاده خواهد شد.

چهارمین مقدار اختیاری رشته، فایل باینری کمکی را که باید برای تمدید استفاده شود تعیین می‌کند. در حال حاضر adcli و realm پشتیبانی می‌شوند. اگر این مقدار در رشتهٔ مقدار موجود نباشد یا خالی باشد، realm استفاده خواهد شد. از آنجا که برنامهٔ کمکی تحت همان کاربری که SSSD با آن اجرا می‌شود اجرا می‌گردد، این احتمال وجود دارد که اگر این کاربر دسترسی‌های لازم برای تغییر فایل keytab محل ذخیرهٔ اعتبارنامه‌های حساب ماشین را نداشته باشد، تمدید با شکست مواجه شود. این وضعیت معمولاً برای adcli رخ می‌دهد.

ابزار realm فایل keytab را مستقیماً به‌روزرسانی نمی‌کند، بلکه فرایند realmd را که تحت کاربر root اجرا می‌شود برای این وظیفه فراخوانی می‌کند. realmd می‌تواند با کمک PolicyKit به کاربران غیرممتاز اجازهٔ دسترسی دهد و SSSD به‌طور پیش‌فرض قواعد مناسبی را برای کاربری که SSSD تحت آن اجرا می‌شود فراهم می‌کند.

پیش‌فرض: 86400:750:300:realm (۲۴ ساعت، ۱۲ دقیقه و ۳۰ ثانیه، و ۵ دقیقه)

ad_update_samba_machine_account_password (بولی)

در صورت فعال بودن، هنگامی که SSSD گذرواژهٔ حساب ماشین را تمدید می‌کند، در پایگاه دادهٔ Samba نیز به‌روزرسانی می‌شود. این کار از منقضی شدن نسخهٔ گذرواژهٔ حساب ماشین در Samba هنگامی که برای احراز هویت با AD پیکربندی شده است جلوگیری می‌کند.

پیش‌فرض: false

ad_use_ldaps (بولی)

به‌طور پیش‌فرض SSSD از درگاه متنی سادهٔ LDAP یعنی 389 و درگاه Global Catalog یعنی 3628 استفاده می‌کند. اگر این گزینه روی True تنظیم شود، SSSD از درگاه LDAPS یعنی 636 و درگاه Global Catalog یعنی 3629 به همراه حفاظت LDAPS استفاده خواهد کرد. از آنجا که AD اجازهٔ داشتن چندین لایهٔ رمزنگاری را روی یک اتصال نمی‌دهد و ما همچنان می‌خواهیم از SASL/GSSAPI یا SASL/GSS-SPNEGO برای احراز هویت استفاده کنیم، ویژگی امنیتی SASL یعنی maxssf برای این اتصال‌ها روی 0 (صفر) تنظیم می‌شود.

پیش‌فرض: False

dyndns_update (بولی)

اختیاری. این گزینه به SSSD اعلام می‌کند که کارگزار DNS در Active Directory را به‌طور خودکار با آدرس IP این کلاینت به‌روزرسانی کند. این به‌روزرسانی با استفاده از GSS-TSIG ایمن می‌شود. در نتیجه، مدیر Active Directory تنها باید به‌روزرسانی‌های امن را برای ناحیهٔ (zone) مربوط به DNS مجاز کند. در صورتی که با استفاده از گزینهٔ “dyndns_iface” طور دیگری تعیین نشده باشد، از آدرس IP مربوط به اتصال AD LDAP برای به‌روزرسانی‌ها استفاده می‌شود.

نکته: در سیستم‌های قدیمی‌تر (مانند RHEL 5)، برای عملکرد مطمئن این سازوکار، realm پیش‌فرض Kerberos باید به درستی در /etc/krb5.conf تنظیم شده باشد.

پیش‌فرض: true

dyndns_ttl (عدد صحیح)

مقدار TTL جهت اعمال روی رکورد DNS کلاینت هنگام به‌روزرسانی آن. اگر dyndns_update برابر false باشد این گزینه تأثیری ندارد. این مقدار، در صورت تعیین شدن توسط مدیر در سمت سرور، TTL را رونویسی خواهد کرد.

پیش‌فرض: 3600 (ثانیه)

dyndns_iface (رشته)

اختیاری. تنها زمانی کاربرد دارد که dyndns_update برابر true باشد. رابط شبکه یا فهرستی از رابط‌ها را انتخاب کنید که آدرس‌های IP آن‌ها باید برای به‌روزرسانی‌های پویای DNS استفاده شوند. نام رابط می‌تواند یک الگوی عام (wildcard) باشد که برای مستثنی کردن رابط، پیشوند ! می‌گیرد. اولین تطابق، ارزیابی را متوقف می‌کند. برای نمونه فهرست !eth1, * به SSSD دستور می‌دهد از تمامی رابط‌ها به جز eth1 استفاده کند. برای جزئیات مربوط به الگوها به man 7 glob مراجعه کنید.

نکته: در حالی که هنوز استفاده از گزینهٔ قدیمی ipa_dyndns_iface امکان‌پذیر است، کاربران باید در فایل پیکربندی خود به استفاده از dyndns_iface مهاجرت کنند.

پیش‌فرض: استفاده از آدرس‌های IP رابطی که برای اتصال AD LDAP استفاده می‌شود

مثال: dyndns_iface = em[12], !vnet1, vnet*

dyndns_address (رشته)

اختیاری. تنها زمانی کاربرد دارد که dyndns_update برابر true باشد. فهرستی از آدرس‌های IP یا شبکه‌های IP که باید برای به‌روزرسانی‌های پویای DNS استفاده شوند. آدرس‌های شبکه باید در قالب CIDR باشند. برای مشخص کردن موارد مستثنی، می‌توان به یک مدخل پیشوند ! اضافه کرد. برای تعیین اینکه آیا یک آدرس شامل یا مستثنی شود، از بهترین تطابق استفاده می‌شود (یعنی پیشوند طولانی‌تر اولویت دارد).

پیش‌فرض: بدون فیلتر کردن آدرس‌های IP.

مثال: dyndns_address = 10.0.0.0/16, !10.0.1.0/24

dyndns_refresh_interval (عدد صحیح)

بک‌اند علاوه بر به‌روزرسانی خودکاری که هنگام برخط شدن انجام می‌دهد، هر چند وقت یک‌بار باید به‌روزرسانی دوره‌ای DNS را اجرا کند. این گزینه اختیاری است و تنها زمانی کاربرد دارد که dyndns_update برابر true باشد. توجه داشته باشید که کمترین مقدار ممکن ۶۰ ثانیه است؛ در صورتی که مقداری کمتر از ۶۰ وارد شود، پارامتر تنها کمترین مقدار را در نظر خواهد گرفت.

پیش‌فرض: 86400 (۲۴ ساعت)

dyndns_update_ptr (بولی)

مشخص می‌کند که آیا هنگام به‌روزرسانی رکوردهای DNS کلاینت، رکورد PTR نیز باید به‌صراحت به‌روزرسانی شود یا خیر. تنها زمانی کاربرد دارد که dyndns_update برابر true باشد.

توجه داشته باشید که پارامتر dyndns_update_per_family برای به‌روزرسانی‌های رکورد PTR اعمال نمی‌شود. این به‌روزرسانی‌ها همواره جداگانه ارسال می‌شوند.

پیش‌فرض: True

dyndns_force_tcp (بولی)

مشخص می‌کند که آیا ابزار nsupdate برای برقراری ارتباط با کارگزار DNS به‌طور پیش‌فرض از TCP استفاده کند یا خیر.

پیش‌فرض: False (اجازه به nsupdate برای انتخاب پروتکل)

dyndns_auth (رشته)

مشخص می‌کند که آیا ابزار nsupdate باید از احراز هویت GSS-TSIG برای به‌روزرسانی‌های امن در ارتباط با کارگزار DNS استفاده کند یا خیر؛ به‌روزرسانی‌های ناامن را می‌توان با تنظیم این گزینه روی 'none' ارسال کرد.

پیش‌فرض: GSS-TSIG

dyndns_auth_ptr (رشته)

مشخص می‌کند که آیا ابزار nsupdate باید از احراز هویت GSS-TSIG برای به‌روزرسانی‌های امن PTR در ارتباط با کارگزار DNS استفاده کند یا خیر؛ به‌روزرسانی‌های ناامن را می‌توان با تنظیم این گزینه روی 'none' ارسال کرد.

پیش‌فرض: همانند dyndns_auth

dyndns_server (رشته)

کارگزار DNS مورد استفاده هنگام انجام به‌روزرسانی DNS. در بیشتر ساختارها، توصیه می‌شود این گزینه بدون مقدار رها شود.

تنظیم این گزینه برای محیط‌هایی مناسب است که کارگزار DNS با کارگزار هویت تفاوت دارد، یا زمانی که از DNS رمزگذاری‌شده استفاده می‌کنیم.

این پارامتر می‌تواند یک رشتهٔ ساده شامل نام DNS یا آدرس IP باشد. همچنین می‌تواند یک URI باشد. این URI می‌تواند شبیه dns://servername/ یا dns+tls://1.2.3.4:853#servername/ باشد.

مثال دوم پروتکل DNS-over-TLS را برای به‌روزرسانی‌های DNS فعال می‌کند. ابزار nsupdate باید از DoT پشتیبانی کند - پیش از فعال‌سازی آن در SSSD، man nsupdate را بررسی کنید.

لطفاً توجه داشته باشید که این گزینه تنها در تلاش جایگزین (fallback) هنگامی که تلاش پیشین با استفاده از تنظیمات به‌طور خودکار شناسایی‌شده شکست بخورد، یا زمانی که DNS-over-TLS فعال باشد استفاده خواهد شد.

پیش‌فرض: None (اجازه به nsupdate برای انتخاب کارگزار)

dyndns_update_per_family (بولی)

به‌روزرسانی DNS به‌طور پیش‌فرض در دو مرحله انجام می‌شود - به‌روزرسانی IPv4 و سپس به‌روزرسانی IPv6. در برخی موارد ممکن است انجام به‌روزرسانی IPv4 و IPv6 در یک مرحله مطلوب باشد.

پیش‌فرض: true

dyndns_dot_cacert (رشته)

این گزینه فایل مربوط به گواهی‌های مراجع صدور گواهی (در قالب PEM) را جهت تأیید اعتبار گواهی TLS کارگزار راه دور هنگام استفاده از DoT مشخص می‌کند.

پیش‌فرض: None (استفاده از مخزن سراسری گواهی‌ها)

dyndns_dot_cert (رشته)

این گزینه فایل گواهی(ها) را برای احراز هویت در بستر انتقال DoT به کارگزار راه دور تعیین می‌کند. فایل زنجیرهٔ گواهی باید در قالب PEM باشد.

گزینه‌های dyndns_dot_cert و dyndns_dot_key هر دو باید تعیین شوند تا احراز هویت دوطرفهٔ TLS حاصل شود.

پیش‌فرض: None (عدم استفاده از احراز هویت TLS)

dyndns_dot_key (رشته)

این گزینه فایل کلید را برای رمزنگاری احراز هویت‌شده در بستر انتقال DoT به کارگزار راه دور تعیین می‌کند. فایل کلید خصوصی باید در قالب PEM باشد.

پیش‌فرض: None (عدم استفاده از احراز هویت TLS)

override_homedir (رشته)

دایرکتوری خانگی کاربر را جایگزین می‌کند. می‌توانید یک مقدار مطلق یا یک الگو ارائه دهید. در الگو، دنباله‌های زیر جایگزین می‌شوند:

%u

نام ورود

%U

شماره UID

%d

نام دامنه

%f

نام کامل و واجد شرایط کاربر (user@domain)

%l

حرف نخست نام ورود.

%P

شناسهٔ UPN - User Principal Name (name@REALM)

%o

مقدار homedir که در دایرکتوری ارائه‌دهندهٔ هویت تعریف شده است.

این جایگزینی برای استفاده در سناریوی اعتمادسازی IPA-AD طراحی شده است. اگر این جایگزینی برای گزینهٔ subdomain_homedir استفاده شود، مقدار دایرکتوری خانگی را از دامنهٔ AD به کلاینت‌های IPA انتشار می‌دهد. در این سناریو، این گزینه باید در پیکربندی SSSD روی سرور IPA که SSSD در آن در حالت کارگزار (server mode) اجرا می‌شود تنظیم گردد.

%h

مسیر تعریف‌شده برای مشخصهٔ دایرکتوری homedir در ارائه‌دهندهٔ هویت، اما با حروف کوچک. برای جزئیات کاربرد، به %o مراجعه کنید.

%H

مقدار گزینهٔ پیکربندی homedir_substring.

%%

نویسهٔ تحت‌اللفظی '%'

این گزینه همچنین می‌تواند به ازای هر دامنه تنظیم شود.

مثال:

override_homedir = /home/%u

پیش‌فرض: تنظیم‌نشده (SSSD از مقدار دریافت‌شده از LDAP استفاده خواهد کرد)

لطفاً توجه داشته باشید، دایرکتوری خانگی برگرفته از یک جایگزینی مشخص برای کاربر، خواه به‌صورت محلی (نگاه کنید به sss_override(8)) یا id-overrideهای IPA مدیریت‌شده به‌طور متمرکز، اولویت بالاتری دارد و به‌جای مقدار ارائه‌شده توسط override_homedir استفاده خواهد شد.

homedir_substring (رشته)

مقدار این گزینه در بسط گزینهٔ override_homedir استفاده خواهد شد اگر الگو حاوی رشتهٔ قالب‌بندی %H باشد. یک مدخل دایرکتوری LDAP می‌تواند مستقیماً حاوی این الگو باشد تا بتوان از این گزینه برای بسط مسیر دایرکتوری خانگی برای هر ماشین کلاینت (یا سیستم‌عامل) استفاده کرد. این گزینه می‌تواند به ازای هر دامنه یا به‌صورت سراسری در بخش [nss] تنظیم شود. مقدار مشخص‌شده در یک بخش دامنه، مقدار تنظیم‌شده در بخش [nss] را بازنویسی خواهد کرد.

پیش‌فرض: /home

krb5_confd_path (رشته)

مسیر مطلق دایرکتوری‌ای که SSSD باید قطعه‌های پیکربندی Kerberos را در آن قرار دهد.

برای غیرفعال کردن ایجاد قطعه‌های پیکربندی، پارامتر را روی 'none' تنظیم کنید.

پیش‌فرض: تنظیم‌نشده (زیردایرکتوری krb5.include.d از دایرکتوری pubconf مربوط به SSSD)

پیش‌فرض برخی از گزینه‌ها با مقادیر پیش‌فرض ارائه‌دهندهٔ بک‌اند مربوطه‌شان مطابقت ندارد؛ این نام‌های گزینه‌ها و مقادیر پیش‌فرض ویژهٔ ارائه‌دهندهٔ AD در زیر فهرست شده‌اند:

•krb5_validate = true
•krb5_use_enterprise_principal = true

•ldap_schema = ad
•ldap_force_upper_case_realm = true
•ldap_id_mapping = true
•ldap_sasl_mech = GSS-SPNEGO
•ldap_referrals = false
•ldap_account_expire_policy = ad
•ldap_use_tokengroups = true
•ldap_sasl_authid = sAMAccountName@REALM (معمولاً SHORTNAME$@REALM)

ارائه‌دهندهٔ AD به‌طور پیش‌فرض به دنبال پرینسیپالی متفاوت از ارائه‌دهندهٔ LDAP می‌گردد، زیرا در یک محیط Active Directory پرینسیپال‌ها به دو گروه تقسیم می‌شوند - پرینسیپال‌های کاربر (User Principals) و پرینسیپال‌های سرویس (Service Principals). تنها پرینسیپال کاربر می‌تواند برای دریافت TGT استفاده شود و به‌طور پیش‌فرض، پرینسیپال شیء رایانه از sAMAccountName آن و realm مربوط به AD ساخته می‌شود. پرینسیپال شناخته‌شدهٔ host/hostname@REALM یک پرینسیپال سرویس است و بنابراین نمی‌توان از آن برای دریافت TGT استفاده کرد.

•fallback_homedir = /home/%d/%u

ارائه‌دهندهٔ AD به‌طور خودکار "fallback_homedir = /home/%d/%u" را تنظیم می‌کند تا دایرکتوری‌های خانگی شخصی را برای کاربرانی که فاقد مشخصهٔ homeDirectory هستند فراهم کند. اگر دامنهٔ AD شما به‌درستی با مشخصه‌های Posix مقداردهی شده باشد، و می‌خواهید از این رفتار جایگزین (fallback) جلوگیری کنید، می‌توانید صراحتاً "fallback_homedir = %o" را تنظیم کنید.

توجه داشته باشید که سیستم معمولاً انتظار دارد دایرکتوری خانگی در پوشهٔ /home/%u باشد. اگر تصمیم بگیرید از ساختار دایرکتوری متفاوتی استفاده کنید، ممکن است برخی دیگر از بخش‌های سیستم شما نیاز به تنظیم داشته باشند.

برای مثال ایجاد خودکار دایرکتوری‌های خانگی در ترکیب با selinux نیازمند تنظیمات selinux است، در غیر این صورت دایرکتوری خانگی با کانتکست (context) نادرست selinux ایجاد خواهد شد.

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

فهرست سرورها به‌صورت فهرستی جداشده با کاما مشخص می‌شود؛ قرار دادن هر تعداد فاصله اطراف کاما مجاز است. سرورها به ترتیب اولویت فهرست می‌شوند. فهرست می‌تواند شامل هر تعداد سرور باشد.

به ازای هر گزینهٔ پیکربندی دارای قابلیت جایگزینی هنگام خرابی، دو نوع وجود دارد: primary و backup. ایده این است که سرورهای موجود در فهرست اصلی (primary) اولویت دارند و سرورهای پشتیبان (backup) تنها در صورتی جستجو می‌شوند که هیچ سرور اصلی در دسترس نباشد. اگر یک سرور پشتیبان انتخاب شود، مهلت زمانی ۳۱ ثانیه‌ای تعیین می‌شود. پس از این مهلت زمانی، SSSD به‌صورت دوره‌ای تلاش می‌کند تا دوباره به یکی از سرورهای اصلی متصل شود. در صورت موفقیت، سرور اصلی جایگزین سرور فعال فعلی (پشتیبان) خواهد شد.

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

تلاش‌های بعدی برای اتصال به ماشین‌ها یا سرویس‌هایی که آفلاین علامت‌گذاری شده‌اند پس از گذشت یک بازهٔ زمانی مشخص انجام می‌شود؛ این بازه در حال حاضر به‌صورت ثابت روی ۳۰ ثانیه تنظیم شده است.

اگر ماشین دیگری برای امتحان وجود نداشته باشد، کل بک‌اند به حالت آفلاین می‌رود و سپس هر ۳۰ ثانیه برای برقراری مجدد اتصال تلاش می‌کند.

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

این بخش پارامترهای قابل تنظیم را فهرست می‌کند. لطفاً به توضیحات آنها در صفحهٔ راهنمای sssd.conf(5) مراجعه کنید.

dns_resolver_server_timeout

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

پیش‌فرض: 1000

dns_resolver_op_timeout

زمان بر حسب ثانیه که تعیین می‌کند SSSD چه مدت برای تحلیل یک پرس‌وجوی DNS منفرد (مانند تحلیل یک نام میزبان یا یک رکورد SRV) پیش از رفتن به سراغ نام میزبان بعدی یا دامنهٔ شناسایی، تلاش کند.

پیش‌فرض: 3

dns_resolver_timeout

مدت‌زمانی که SSSD برای تحلیل یک سرویس جایگزینی هنگام خرابی تلاش می‌کند. این تحلیل سرویس در درون خود ممکن است شامل چندین مرحله مانند تحلیل پرس‌وجوهای DNS SRV یا پیدا کردن سایت باشد.

پیش‌فرض: 6

برای ارائه‌دهندگان مبتنی بر LDAP، عملیات تحلیل نام به عنوان بخشی از عملیات اتصال LDAP انجام می‌شود. بنابراین، مهلت زمانی “ldap_opt_timeout” نیز باید روی مقداری بزرگتر از “dns_resolver_timeout” تنظیم شود که آن نیز به نوبهٔ خود باید بزرگتر از “dns_resolver_op_timeout” باشد و آن هم باید از “dns_resolver_server_timeout” بزرگتر تعیین شود.

ویژگی شناسایی سرویس به بک‌اندها امکان می‌دهد با استفاده از یک پرس‌وجوی DNS ویژه، سرورهای مناسب را برای اتصال به‌طور خودکار پیدا کنند. این ویژگی برای سرورهای پشتیبان (backup) پشتیبانی نمی‌شود.

اگر هیچ سروری مشخص نشده باشد، بک‌اند به‌طور خودکار از شناسایی سرویس برای یافتن سرور استفاده می‌کند. به‌صورت اختیاری، کاربر می‌تواند با قرار دادن کلمهٔ کلیدی ویژهٔ “_srv_” در فهرست سرورها، هم‌زمان از آدرس‌های ثابت سرور و شناسایی سرویس بهره ببرد. ترتیب اولویت حفظ می‌شود. این ویژگی برای نمونه زمانی کاربرد دارد که کاربر ترجیح می‌دهد در صورت امکان از شناسایی سرویس استفاده کند و اگر هیچ سروری از طریق DNS پیدا نشد، به یک سرور مشخص بازگردد.

لطفاً برای جزئیات بیشتر به پارامتر “dns_discovery_domain” در صفحهٔ راهنمای sssd.conf(5) مراجعه کنید.

پرس‌وجوها معمولاً _tcp را به عنوان پروتکل تعیین می‌کنند. موارد استثنا در توضیحات گزینه مربوطه مستند شده است.

برای اطلاعات بیشتر در مورد سازوکار شناسایی سرویس، به RFC 2782 مراجعه کنید.

ویژگی ID-mapping به SSSD امکان می‌دهد به عنوان کلاینت Active Directory عمل کند، بدون نیاز به اینکه مدیران سیستم ویژگی‌های کاربر را برای پشتیبانی از مشخصه‌های POSIX جهت شناسه‌های کاربر و گروه توسعه دهند.

نکته: هنگامی که ID-mapping فعال است، مشخصه‌های uidNumber و gidNumber نادیده گرفته می‌شوند. این کار برای جلوگیری از احتمال تداخل میان مقادیر تخصیص‌یافته به‌صورت خودکار و دستی است. اگر نیاز به استفاده از مقادیر دستی دارید، همهٔ مقادیر باید به‌صورت دستی تخصیص داده شوند.

لطفاً توجه داشته باشید که تغییر گزینه‌های پیکربندی مربوط به نگاشت شناسه باعث تغییر شناسه‌های کاربر و گروه خواهد شد. در حال حاضر SSSD از تغییر شناسه‌ها پشتیبانی نمی‌کند، بنابراین پایگاه دادهٔ SSSD باید حذف شود. از آنجا که گذرواژه‌های ذخیره‌شده در حافظهٔ پنهان نیز در پایگاه داده نگهداری می‌شوند، حذف پایگاه داده تنها زمانی باید انجام شود که سرورهای احراز هویت در دسترس باشند، در غیر این صورت ممکن است دسترسی کاربران قطع شود. برای ذخیرهٔ گذرواژه در حافظهٔ پنهان، باید احراز هویت صورت گیرد. استفاده از sss_cache(8) برای حذف پایگاه داده کافی نیست، بلکه فرایند شامل مراحل زیر است:

•اطمینان از در دسترس بودن سرورهای دوردست
•متوقف کردن سرویس SSSD
•حذف پایگاه داده
•راه‌اندازی سرویس SSSD

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

سامانهٔ Active Directory برای هر شیء کاربر و گروه در دایرکتوری، یک objectSID ارائه می‌دهد. این objectSID می‌تواند به مؤلفه‌هایی تجزیه شود که نمایانگر هویت دامنهٔ Active Directory و شناسهٔ نسبی (RID) شیء کاربر یا گروه هستند.

الگوریتم ID-mapping در SSSD بازه‌ای از UIDهای در دسترس را گرفته و آن را به بخش‌های مؤلفه‌ای هم‌اندازه به نام "برش‌ها" (slices) تقسیم می‌کند. هر برش نشان‌دهندهٔ فضای در دسترس برای یک دامنهٔ Active Directory است.

هنگامی که مدخل یک کاربر یا گروه برای دامنه‌ای خاص برای نخستین بار پردازش می‌شود، SSSD یکی از برش‌های در دسترس را به آن دامنه اختصاص می‌دهد. به منظور تکرارپذیر بودن این تخصیص برش در ماشین‌های کلاینت مختلف، انتخاب برش بر اساس الگوریتم زیر انجام می‌گیرد:

رشتهٔ SID به الگوریتم murmurhash3 فرستاده می‌شود تا به یک مقدار درهم‌سازی‌شدهٔ ۳۲ بیتی تبدیل شود. سپس باقی‌ماندهٔ تقسیم این مقدار بر تعداد کل برش‌های در دسترس محاسبه می‌شود تا برش مورد نظر انتخاب گردد.

نکته: امکان رخداد تداخل در هش و محاسبهٔ باقی‌ماندهٔ پس از آن وجود دارد. در این شرایط، برش در دسترس بعدی انتخاب خواهد شد، اما بازتولید دقیق همان مجموعه برش‌ها روی سایر ماشین‌ها ممکن نخواهد بود (چرا که ترتیبی که ماشین‌ها با آنها روبرو می‌شوند برش آنها را تعیین می‌کند). در این وضعیت، توصیه می‌شود یا به استفاده از ویژگی‌های صریح POSIX در Active Directory روی آورید (غیرفعال کردن ID-mapping) یا یک دامنهٔ پیش‌فرض را پیکربندی کنید تا تضمین شود دست‌کم یکی از آنها همیشه یکنواخت است. برای جزئیات به “پیکربندی” مراجعه کنید.

حداقل پیکربندی (در بخش “[domain/DOMAINNAME]”):

ldap_id_mapping = True
ldap_schema = ad

پیکربندی پیش‌فرض منجر به تنظیم 10,000 برش می‌شود که هر کدام گنجایش حداکثر 200,000 شناسه را دارند؛ این بازه از 200,000 آغاز شده و تا 2,000,200,000 ادامه می‌یابد. این مقدار برای بیشتر پیاده‌سازی‌ها کافی خواهد بود.

پیکربندی پیشرفته

ldap_idmap_range_min (عدد صحیح)

حد پایین (شامل خود مقدار) از بازهٔ شناسه‌های POSIX را برای نگاشت SIDهای کاربر و گروه Active Directory تعیین می‌کند. این مقدار اولین شناسهٔ POSIX است که می‌تواند برای نگاشت استفاده شود.

نکته: این گزینه با “min_id” متفاوت است؛ “min_id” خروجی درخواست‌ها به این دامنه را فیلتر می‌کند، در حالی که این گزینه بازهٔ تخصیص شناسه را کنترل می‌نماید. این تفاوتی ظریف است، اما توصیهٔ کلی مناسب این است که مقدار “min_id” کوچکتر یا مساوی با “ldap_idmap_range_min” باشد.

پیش‌فرض: 200000

ldap_idmap_range_max (عدد صحیح)

حد بالای (بدون احتساب خود مقدار) از بازهٔ شناسه‌های POSIX را برای نگاشت SIDهای کاربر و گروه Active Directory تعیین می‌کند. این اولین شناسهٔ POSIX است که دیگر نمی‌تواند برای نگاشت استفاده شود، یعنی یک واحد بزرگتر از آخرین شناسه‌ای است که می‌تواند در نگاشت به کار رود.

نکته: این گزینه با “max_id” تفاوت دارد؛ “max_id” خروجی درخواست‌ها به این دامنه را فیلتر می‌کند، در حالی که این گزینه بازهٔ تخصیص شناسه را کنترل می‌نماید. این تفاوتی ظریف است، اما توصیهٔ کلی مناسب این است که مقدار “max_id” بزرگتر یا مساوی با “ldap_idmap_range_max” باشد.

پیش‌فرض: 2000200000

ldap_idmap_range_size (عدد صحیح)

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

نکته: مقدار این گزینه باید حداقل به اندازهٔ بالاترین RID کاربری باشد که برای استفاده در سرور Active Directory برنامه‌ریزی شده است. جستجوی اطلاعات کاربری و ورود برای هر کاربری که RID او از این مقدار بیشتر باشد با شکست روبرو خواهد شد.

به عنوان مثال، اگر آخرین کاربر اضافه‌شده در Active Directory دارای مشخصهٔ objectSid=S-1-5-21-2153326666-2176343378-3404031434-1107 باشد، مقدار “ldap_idmap_range_size” باید دست‌کم 1108 تعیین شود، چرا که اندازهٔ بازه برابر است با بیشینهٔ RID منهای کمینهٔ RID به اضافهٔ یک (مثلاً 1108 = 1107 - 0 + 1).

برنامه‌ریزی از پیش برای توسعهٔ آینده بسیار مهم است، زیرا تغییر این مقدار باعث تغییر تمام نگاشت‌های شناسه روی سیستم شده و منجر به تغییر شناسه‌های محلی پیشین کاربران می‌شود.

پیش‌فرض: 200000

ldap_idmap_default_domain_sid (رشته)

شناسهٔ SID دامنه را برای دامنهٔ پیش‌فرض مشخص می‌کند. این تضمین می‌کند که این دامنه همواره به برش صفر در جدول نگاشت شناسه اختصاص یابد و الگوریتم murmurhash توضیح داده شده در بالا نادیده گرفته شود.

پیش‌فرض: تنظیم نشده

ldap_idmap_default_domain (رشته)

نام دامنهٔ پیش‌فرض را تعیین می‌کند.

پیش‌فرض: تنظیم نشده

ldap_idmap_autorid_compat (بولی)

رفتار الگوریتم ID-mapping را تغییر می‌دهد تا عملکردی شبیه‌تر به الگوریتم “idmap_autorid” در winbind پیدا کند.

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

نکته: این الگوریتم غیرقطعی (non-deterministic) است (به ترتیبی وابسته است که کاربران و گروه‌ها درخواست می‌شوند). اگر این حالت برای سازگاری با ماشین‌های اجراکنندهٔ winbind الزامی است، توصیه می‌شود از گزینهٔ “ldap_idmap_default_domain_sid” نیز استفاده کنید تا اطمینان یابید حداقل یک دامنه همیشه به برش صفر تعلق می‌گیرد.

پیش‌فرض: False

ldap_idmap_helper_table_size (عدد صحیح)

حداکثر تعداد برش‌های ثانویه‌ای را مشخص می‌کند که هنگام انجام نگاشت از شناسهٔ UNIX به SID مورد بررسی قرار می‌گیرند.

نکته: زمانی که SID به شناسهٔ UNIX نگاشت می‌شود و بخش RID مربوط به SID فراتر از بازهٔ برش‌های ثانویهٔ تاکنون تولیدشده باشد، ممکن است برش‌های ثانویهٔ جدید ایجاد شوند. اگر مقدار ldap_idmap_helper_table_size برابر 0 باشد، هیچ برش ثانویهٔ اضافی تولید نخواهد شد.

پیش‌فرض: 10

سرویس SSSD از جستجوی نام‌های SIDهای شناخته‌شده (Well-Known SIDs)، یعنی SIDهایی با معانی خاص و ثابت (hardcoded)، پشتیبانی می‌کند. از آنجا که کاربران و گروه‌های عمومی مرتبط با این Well-Known SIDها هیچ معادلی در محیط Linux/UNIX ندارند، هیچ شناسهٔ POSIXی برای این اشیاء در دسترس نیست.

فضای نام SID در مراجع (authorities) سازمان‌دهی شده است که می‌توان آن‌ها را مانند دامنه‌های مختلف در نظر گرفت. مراجع مربوط به Well-Known SIDها عبارتند از:

•Null Authority
•World Authority
•Local Authority
•Creator Authority
•Mandatory Label Authority
•Authentication Authority
•NT Authority
•Built-in

نسخه با حروف بزرگ این نام‌ها هنگام بازگرداندن نام کاملاً مشخص (fully qualified name) یک Well-Known SID به عنوان نام دامنه استفاده می‌شود.

از آنجا که برخی ابزارها امکان تغییر اطلاعات کنترل دسترسی مبتنی بر SID را با استفاده از نام به جای خودِ SID فراهم می‌کنند، SSSD از جستجوی SID بر اساس نام نیز پشتیبانی می‌کند. برای جلوگیری از تداخل، فقط از نام‌های کاملاً مشخص می‌توان برای جستجوی Well-Known SIDها استفاده کرد. در نتیجه، نام‌های دامنهٔ “NULL AUTHORITY”، “WORLD AUTHORITY”، “LOCAL AUTHORITY”، “CREATOR AUTHORITY”، “MANDATORY LABEL AUTHORITY”، “AUTHENTICATION AUTHORITY”، “NT AUTHORITY” و “BUILTIN” نباید به عنوان نام دامنه در sssd.conf استفاده شوند.

مثال زیر فرض می‌کند که SSSD به‌درستی پیکربندی شده و example.com یکی از دامنه‌ها در بخش [sssd] است. این مثال فقط گزینه‌های اختصاصی ارائه‌دهندهٔ AD را نشان می‌دهد.

[domain/EXAMPLE]
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
ad_server = dc1.example.com
ad_hostname = client.example.com
ad_domain = example.com

ارائه‌دهندهٔ کنترل دسترسی AD بررسی می‌کند که آیا حساب کاربری منقضی شده است یا خیر. این عملکرد تأثیری مشابه پیکربندی زیر در ارائه‌دهندهٔ LDAP دارد:

access_provider = ldap
ldap_access_order = expire
ldap_account_expire_policy = ad

با این حال، مگر اینکه ارائه‌دهندهٔ کنترل دسترسی “ad” به‌صورت صریح پیکربندی شده باشد، ارائه‌دهندهٔ دسترسی پیش‌فرض “permit” است. لطفاً توجه داشته باشید اگر ارائه‌دهندهٔ کنترلی به‌جز “ad” را پیکربندی کنید، باید تمام پارامترهای اتصال (مانند URIهای LDAP و جزئیات رمزنگاری) را دستی تنظیم کنید.

هنگامی که ارائه‌دهندهٔ autofs روی “ad” تنظیم شده باشد، نگاشت ویژگی شِمای RFC2307 (از جمله nisMap، nisObject و غیره) استفاده می‌شود، زیرا این ویژگی‌ها در شِمای پیش‌فرض Active Directory گنجانده شده‌اند.

sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-idp(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(1), sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

توسعه‌دهندگان بالادستی SSSD - https://github.com/SSSD/sssd

1.
گروه‌های امنیتی Active Directory
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups
2.
بخش افزونه‌های LDAP در [MS-ADTS]
https://msdn.microsoft.com/en-us/library/cc223367.aspx
06/09/2026 SSSD