SSSD-IPA(5) قالب‌های پرونده و قراردادها SSSD-IPA(5)

sssd-ipa - ارائه‌دهنده IPA در SSSD

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

ارائه‌دهنده IPA یک بک‌اند (back end) است که برای اتصال به کارساز IPA استفاده می‌شود. (برای اطلاعات در مورد سرورهای IPA به وب‌سایت freeipa.org مراجعه کنید.) این ارائه‌دهنده مستلزم آن است که دستگاه به دامنه IPA پیوسته باشد؛ پیکربندی تقریباً به‌طور کامل خودکار شناسایی شده و مستقیماً از کارساز دریافت می‌شود.

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

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

ارائه‌دهنده IPA به عنوان یک ارائه‌دهنده دسترسی، دارای حداقل پیکربندی است (به “ipa_access_order” مراجعه کنید) زیرا عمدتاً از قواعد HBAC (کنترل دسترسی مبتنی بر میزبان) بهره می‌برد. لطفاً برای اطلاعات بیشتر درباره HBAC به freeipa.org مراجعه کنید.

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

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

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

ipa_domain (string)

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

ipa_server, ipa_backup_server (string)

فهرستی از نشانی‌های IP یا نام‌های میزبان کارسازهای IPA که با کاما از هم جدا شده‌اند و SSSD باید به ترتیب اولویت به آن‌ها متصل شود. برای اطلاعات بیشتر درباره تغییر مسیر هنگام خرابی و افزونگی کارساز، بخش “FAILOVER” را ببینید. در صورت فعال بودن کشف خودکار، این گزینه اختیاری است. برای اطلاعات بیشتر درباره کشف سرویس، به بخش “SERVICE DISCOVERY” مراجعه کنید.

ipa_hostname (string)

اختیاری. می‌تواند روی دستگاه‌هایی تنظیم شود که در آن‌ها hostname(5) بیانگر نام کاملاً منطبق (FQDN) به کار رفته در دامنه IPA برای شناسایی این میزبان نباشد. نام میزبان باید کاملاً منطبق (fully qualified) باشد.

dyndns_update (boolean)

اختیاری. این گزینه به SSSD می‌گوید که کارساز DNS تعبیه‌شده در FreeIPA را به‌طور خودکار با نشانی IP این کلاینت به‌روزرسانی کند. این به‌روزرسانی با استفاده از GSS-TSIG ایمن می‌شود. برای به‌روزرسانی‌ها از نشانی IP اتصال LDAP مربوط به IPA استفاده می‌شود، مگر اینکه توسط گزینه “dyndns_iface” به‌گونه دیگری مشخص شده باشد.

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

پیش‌فرض: false

dyndns_ttl (integer)

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

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

dyndns_iface (string)

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

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

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

dyndns_address (string)

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

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

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

dyndns_auth (string)

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

پیش‌فرض: GSS-TSIG

dyndns_auth_ptr (string)

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

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

dyndns_refresh_interval (integer)

علاوه بر به‌روزرسانی خودکاری که هنگام برخط شدن بک‌اند انجام می‌شود، هر چند وقت یک‌بار بک‌اند باید به‌روزرسانی دوره‌ای DNS را انجام دهد. این گزینه اختیاری بوده و تنها زمانی کاربرد دارد که dyndns_update برابر true باشد.

پیش‌فرض: 0 (غیرفعال)

dyndns_update_ptr (bool)

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

این گزینه در اکثر استقرارهای IPA باید False باشد زیرا کارساز IPA هنگام تغییر رکوردهای مستقیم (forward)، رکوردهای PTR را به‌طور خودکار تولید می‌کند.

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

پیش‌فرض: False (غیرفعال)

dyndns_force_tcp (bool)

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

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

dyndns_server (string)

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

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

این پارامتر می‌تواند یک رشته ساده حاوی نام DNS یا نشانی IP باشد. همچنین می‌تواند یک نشانی وب (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 (boolean)

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

پیش‌فرض: true

dyndns_dot_cacert (string)

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

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

dyndns_dot_cert (string)

این گزینه پرونده گواهی(ها) را برای اصالت‌سنجی در انتقال DoT به کارساز دوردست تنظیم می‌کند. پرونده زنجیره گواهی باید در قالب PEM باشد.

گزینه‌های dyndns_dot_cert و dyndns_dot_key هر دو باید تنظیم شوند تا اصالت‌سنجی متقابل TLS (mTLS) برقرار گردد.

پیش‌فرض: None (عدم استفاده از اصالت‌سنجی TLS)

dyndns_dot_key (string)

این گزینه پرونده کلید را برای رمزگذاریِ اصالت‌سنجی‌شده در انتقال DoT به کارساز دوردست تنظیم می‌کند. پرونده کلید خصوصی باید در قالب PEM باشد.

پیش‌فرض: None (عدم استفاده از اصالت‌سنجی TLS)

ipa_access_order (string)

فهرستی از گزینه‌های کنترل دسترسی که با کاما از هم جدا شده‌اند. مقادیر مجاز عبارتند از:

expire: استفاده از شیوه‌نامه انقضای حساب کاربری در IPA.

pwd_expire_policy_reject, pwd_expire_policy_warn, pwd_expire_policy_renew: این گزینه‌ها زمانی مفید هستند که کاربران تمایل دارند پیش از انقضای گذرواژه به آن‌ها هشدار داده شود و اصالت‌سنجی بر پایه روشی غیر از گذرواژه استوار باشد - برای نمونه کلیدهای SSH.

تفاوت بین این گزینه‌ها در اقدامی است که در صورت منقضی شدن گذرواژه کاربر صورت می‌گیرد:

•pwd_expire_policy_reject - ورود کاربر رد می‌شود،
•pwd_expire_policy_warn - کاربر همچنان قادر به ورود است،
•pwd_expire_policy_renew - از کاربر خواسته می‌شود فوراً گذرواژه خود را تغییر دهد.

لطفاً توجه داشته باشید که برای کارکرد این قابلیت باید 'access_provider = ipa' تنظیم شده باشد.

ipa_deskprofile_search_base (string)

اختیاری. استفاده از رشته داده‌شده به عنوان پایه جستجو (search base) برای اشیاء مرتبط با نمایه میزکار (Desktop Profile).

پیش‌فرض: استفاده از DN پایه

ipa_subid_ranges_search_base (string)

منسوخ شده. به جای آن از ldap_subid_ranges_search_base استفاده کنید.

ipa_hbac_search_base (string)

اختیاری. استفاده از رشته داده‌شده به عنوان پایه جستجو برای اشیاء مرتبط با HBAC.

پیش‌فرض: استفاده از DN پایه

ipa_host_search_base (string)

منسوخ شده. به جای آن از ldap_host_search_base استفاده کنید.

ipa_selinux_search_base (string)

اختیاری. استفاده از رشته داده‌شده به عنوان پایه جستجو برای نگاشت‌های کاربری SELinux.

برای اطلاعات درباره پیکربندی چندین پایه جستجو، “ldap_search_base” را ببینید.

پیش‌فرض: مقدار ldap_search_base

ipa_subdomains_search_base (string)

اختیاری. استفاده از رشته داده‌شده به عنوان پایه جستجو برای دامنه‌های مورد اعتماد.

برای اطلاعات درباره پیکربندی چندین پایه جستجو، “ldap_search_base” را ببینید.

پیش‌فرض: مقدار cn=trusts,%basedn

ipa_master_domain_search_base (string)

اختیاری. استفاده از رشته داده‌شده به عنوان پایه جستجو برای شیء دامنه اصلی (master domain).

برای اطلاعات درباره پیکربندی چندین پایه جستجو، “ldap_search_base” را ببینید.

پیش‌فرض: مقدار cn=ad,cn=etc,%basedn

ipa_views_search_base (string)

اختیاری. استفاده از رشته داده‌شده به عنوان پایه جستجو برای ظروف نماها (views containers).

برای اطلاعات درباره پیکربندی چندین پایه جستجو، “ldap_search_base” را ببینید.

پیش‌فرض: مقدار cn=views,cn=accounts,%basedn

krb5_realm (string)

نام قلمروی کربروس. این گزینه اختیاری است و پیش‌فرض آن به مقدار “ipa_domain” برمی‌گردد.

نام قلمروی کربروس معنای ویژه‌ای در IPA دارد - این نام به DN پایه تبدیل می‌شود تا برای انجام عملیات LDAP به کار رود.

krb5_confd_path (string)

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

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

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

ipa_deskprofile_refresh (integer)

مدت زمان بین جستجوهای قواعد نمایه میزکار (Desktop Profile) از سرور IPA. این امر تأخیر و بار روی سرور IPA را در صورتی که درخواست‌های زیادی برای نمایه‌های میزکار در بازه زمانی کوتاه انجام شود، کاهش می‌دهد.

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

ipa_deskprofile_request_interval (integer)

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

پیش‌فرض: 60 (دقیقه)

ipa_hbac_refresh (integer)

مدت زمان بین جستجوهای قواعد HBAC از کارساز IPA. این امر تأخیر و بار روی کارساز IPA را در صورتی که درخواست‌های کنترل دسترسی زیادی در مدت کوتاهی انجام شود، کاهش می‌دهد.

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

ipa_hbac_selinux (integer)

مدت زمان بین جستجوهای نگاشت‌های SELinux از کارساز IPA. این امر تأخیر و بار روی کارساز IPA را در صورتی که درخواست‌های ورود کاربر زیادی در مدت کوتاهی انجام شود، کاهش می‌دهد.

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

ipa_server_mode (boolean)

این گزینه توسط نصاب IPA به نام (ipa-server-install) به‌طور خودکار تنظیم می‌شود و نشان می‌دهد که آیا SSSD روی یک سرور IPA اجرا می‌شود یا خیر.

روی یک سرور IPA، برنامه SSSD کاربران و گروه‌ها را مستقیماً از دامنه‌های مورد اعتماد جستجو می‌کند، در حالی که روی یک کلاینت از سرور IPA درخواست خواهد کرد.

نکته: در حال حاضر فرضیاتی وجود دارد که هنگام اجرای SSSD روی یک سرور IPA باید برآورده شوند.

•گزینه “ipa_server” باید به گونه‌ای پیکربندی شود که به خود کارساز IPA اشاره کند. این مقدار پیش‌فرضی است که توسط نصاب IPA تنظیم می‌شود، بنابراین نیازی به تغییر دستی نیست.
•گزینه “full_name_format” نباید به گونه‌ای دستکاری شود که فقط نام‌های کوتاه را برای کاربران دامنه‌های مورد اعتماد چاپ کند.

پیش‌فرض: false

ipa_automount_location (string)

مکان سوارکننده خودکار (automounter) که این کلاینت IPA استفاده خواهد کرد

پیش‌فرض: مکان با نام "default"

لطفاً توجه داشته باشید که automounter نقشه اصلی را فقط هنگام راه‌اندازی می‌خواند، بنابراین اگر هرگونه تغییر مربوط به autofs در sssd.conf ایجاد شود، معمولاً باید پس از راه‌اندازی مجدد SSSD، دیمن automounter را نیز راه‌اندازی مجدد کنید.

ابزار SSSD می‌تواند نماها و بازنویسی‌هایی را مدیریت کند که توسط FreeIPA 4.1 و نسخه‌های جدیدتر ارائه می‌شوند. از آنجا که تمام مسیرها و رده‌های شیء (objectclasses) در سمت سرور ثابت هستند، اساساً نیازی به پیکربندی چیزی نیست. جهت کامل بودن، گزینه‌های مرتبط همراه با مقادیر پیش‌فرض آن‌ها در اینجا فهرست شده‌اند.

ipa_view_class (string)

رده شیء (objectclass) ظرفِ نما (view container).

پیش‌فرض: nsContainer

ipa_view_name (string)

نام مشخصه‌ای که نام نما را در خود نگه می‌دارد.

پیش‌فرض: cn

ipa_override_object_class (string)

رده شیء (objectclass) اشیاء بازنویسی (override objects).

پیش‌فرض: ipaOverrideAnchor

ipa_anchor_uuid (string)

نام مشخصه‌ای که حاوی ارجاع به شیء اصلی در یک دامنه دوردست است.

پیش‌فرض: ipaAnchorUUID

ipa_user_override_object_class (string)

نام رده شیء برای بازنویسی‌های کاربر. این گزینه برای تعیین اینکه آیا شیء بازنویسیِ یافت‌شده مربوط به یک کاربر است یا یک گروه به کار می‌رود.

بازنویسی‌های کاربر می‌توانند شامل مشخصه‌های ارائه‌شده توسط موارد زیر باشند

•ldap_user_name
•ldap_user_uid_number
•ldap_user_gid_number
•ldap_user_gecos
•ldap_user_home_directory
•ldap_user_shell
•ldap_user_ssh_public_key

پیش‌فرض: ipaUserOverride

ipa_group_override_object_class (string)

نام رده شیء برای بازنویسی‌های گروه. این گزینه برای تعیین اینکه آیا شیء بازنویسیِ یافت‌شده مربوط به یک کاربر است یا یک گروه به کار می‌رود.

بازنویسی‌های گروه می‌توانند شامل مشخصه‌های ارائه‌شده توسط موارد زیر باشند

•ldap_group_name
•ldap_group_gid_number

پیش‌فرض: ipaGroupOverride

پیش‌فرض‌های برخی گزینه‌ها با پیش‌فرض‌های ارائه‌دهنده بک‌اند متناظر آن‌ها مطابقت ندارند، نام این گزینه‌ها و مقادیر پیش‌فرض ویژه ارائه‌دهنده IPA در زیر آمده است:

•krb5_validate = true
•krb5_use_fast = try
•krb5_canonicalize = true

•ldap_schema = ipa_v1
•ldap_force_upper_case_realm = true
•ldap_sasl_mech = GSSAPI
•ldap_sasl_minssf = 56
•ldap_account_expire_policy = ipa
•ldap_use_tokengroups = true

•ldap_user_member_of = memberOf
•ldap_user_uuid = ipaUniqueID
•ldap_user_ssh_public_key = ipaSshPubKey
•ldap_user_auth_type = ipaUserAuthType

•ldap_group_object_class = ipaUserGroup
•ldap_group_object_class_alt = posixGroup
•ldap_group_member = member
•ldap_group_uuid = ipaUniqueID
•ldap_group_objectsid = ipaNTSecurityIdentifier
•ldap_group_external_member = ipaExternalMember

ارائه‌دهنده زیردامنه‌های IPA بسته به اینکه به‌طور صریح یا ضمنی پیکربندی شده باشد، رفتاری اندکی متفاوت دارد.

اگر گزینه 'subdomains_provider = ipa' در بخش دامنه در sssd.conf یافت شود، ارائه‌دهنده زیردامنه‌های IPA به‌طور صریح پیکربندی شده است و در صورت نیاز تمام درخواست‌های زیردامنه به کارساز IPA ارسال می‌شوند.

اگر گزینه 'subdomains_provider' در بخش دامنه در sssd.conf تنظیم نشده باشد اما گزینه 'id_provider = ipa' وجود داشته باشد، ارائه‌دهنده زیردامنه‌های IPA به‌طور ضمنی پیکربندی می‌شود. در این حالت، اگر درخواست زیردامنه با شکست مواجه شود و نشان دهد که سرور از زیردامنه‌ها پشتیبانی نمی‌کند، یعنی برای اعتمادها پیکربندی نشده است، ارائه‌دهنده زیردامنه‌های IPA غیرفعال می‌شود. پس از یک ساعت یا پس از اینکه ارائه‌دهنده IPA برخط شود، ارائه‌دهنده زیردامنه‌ها مجدداً فعال خواهد شد.

برخی از گزینه‌های پیکربندی را می‌توان برای یک دامنه مورد اعتماد نیز تنظیم کرد. پیکربندی یک دامنه مورد اعتماد می‌تواند با استفاده از زیربخش دامنه مورد اعتماد همانند مثال زیر تنظیم شود. روش دیگر، استفاده از گزینه “subdomain_inherit” در دامنه والد است.

[domain/ipa.domain.com/ad.domain.com]
ad_server = dc.ad.domain.com

برای جزئیات بیشتر، صفحه راهنمای sssd.conf(5) را ببینید.

بسته به اینکه SSSD را روی یک سرور IPA یا یک کلاینت IPA پیکربندی می‌کنید، گزینه‌های پیکربندی متفاوتی برای یک دامنه مورد اعتماد قابل تنظیم هستند.

گزینه‌های زیر را می‌توان در یک بخش زیردامنه روی کارساز اصلی IPA تنظیم کرد:

•ad_server
•ad_backup_server
•ad_site
•ipa_server
•ipa_backup_server
•ldap_search_base
•ldap_user_search_base
•ldap_group_search_base
•use_fully_qualified_names

گزینه‌هایی با پیشوند 'ad_' یا 'ipa_' تنها برای نوع زیردامنه مربوط به خود اعمال می‌شوند.

گزینه‌های زیر را می‌توان در یک بخش زیردامنه AD روی کلاینت IPA تنظیم کرد:

•ad_server
•ad_site

توجه داشته باشید که در صورت تنظیم هر دو گزینه، فقط “ad_server” ارزیابی می‌شود.

از آنجا که هرگونه درخواست برای هویت کاربر یا گروه از یک دامنه مورد اعتماد که از کلاینت IPA آغاز شده باشد توسط کارساز IPA برطرف می‌شود، گزینه‌های “ad_server” و “ad_site” تنها بر این موضوع اثر می‌گذارند که اصالت‌سنجی در برابر کدام AD DC انجام خواهد شد. به‌ویژه، نشانی‌های برطرف‌شده از این فهرست‌ها در پرونده‌های “kdcinfo” نوشته می‌شوند که توسط افزونه مکان‌یاب کربروس (Kerberos locator plugin) خوانده می‌شوند. لطفاً برای جزئیات بیشتر درباره افزونه مکان‌یاب کربروس، به صفحه راهنمای sssd_krb5_locator_plugin(8) مراجعه کنید.

قابلیت تغییر مسیر هنگام خرابی (failover) به بک‌اندها اجازه می‌دهد در صورت خرابی سرور فعلی، به‌طور خودکار به سرور دیگری سوئیچ کنند.

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

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

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

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

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

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

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

dns_resolver_server_timeout

مدت زمان به میلی‌ثانیه که تعیین می‌کند SSSD پیش از رفتن به سراغ سرور بعدی، تا چه مدت با یک سرور تکی DNS گفتگو کند.

پیش‌فرض: 1000

dns_resolver_op_timeout

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

پیش‌فرض: 3

dns_resolver_timeout

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

پیش‌فرض: 6

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

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

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

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

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

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

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

[domain/example.com]
id_provider = ipa
ipa_server = ipaserver.example.com
ipa_hostname = myhost.example.com

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)

The SSSD upstream - https://github.com/SSSD/sssd/

06/09/2026 SSSD