| SSS-CERTMAP(5) | File Formats and Conventions | SSS-CERTMAP(5) |
نام (NAME)
sss-certmap - قواعد تطبیق و نگاشت گواهی‌نامه SSSD
توضیحات (DESCRIPTION)
این صفحه راهنما قواعدی را شرح می‌دهد که توسط SSSD و سایر مؤلفه‌ها برای تطبیق گواهی‌نامه‌های X.509 و نگاشت آن‌ها به حساب‌های کاربری استفاده می‌شوند.
هر قاعده شامل چهار جزء است: “اولویت (priority)”، “قاعده تطبیق (matching rule)”، “قاعده نگاشت (mapping rule)” و یک “فهرست دامنه (domain list)”. تمامی این اجزا اختیاری هستند. در صورت نبود “اولویت”، قاعده با کمترین اولویت ممکن اضافه خواهد شد. به صورت پیش‌فرض، “قاعده تطبیق” گواهی‌نامه‌های دارای کاربرد کلید digitalSignature و کاربرد گسترده کلید clientAuth را تطبیق می‌دهد. اگر “قاعده نگاشت” خالی باشد، گواهی‌نامه‌ها در مشخصه userCertificate به صورت باینری با کدگذاری DER جستجو خواهند شد. در صورتی که دامنه‌ای مشخص نشود، تنها دامنه محلی جستجو می‌شود.
برای پشتیبانی از افزونه‌ها یا سبک‌های کاملاً متفاوت قواعد، “قواعد نگاشت” و “قواعد تطبیق” می‌توانند حاوی یک پیشوند باشند که با نویسه ':' از بخش اصلی قاعده جدا می‌شود. این پیشوند تنها می‌تواند شامل حروف بزرگ اَسکی (ASCII) و اعداد باشد. در صورت حذف پیشوند، نوع پیش‌فرض استفاده خواهد شد که برای قواعد تطبیق برابر با 'KRB5' و برای قواعد نگاشت برابر با 'LDAP' است.
ابزار 'sssctl' دستور 'cert-eval-rule' را فراهم می‌کند تا بتوان بررسی کرد آیا یک گواهی‌نامه مشخص با قاعده تطبیق همخوانی دارد و خروجی قاعده نگاشت چگونه خواهد بود.
اجزای قاعده (RULE COMPONENTS)
اولویت (PRIORITY)
قواعد بر اساس اولویت پردازش می‌شوند، به طوری که عدد '0' (صفر) نشان‌دهنده بالاترین اولویت است. هرچه عدد بزرگ‌تر باشد، اولویت کمتر خواهد بود. عدم تعیین مقدار نشان‌دهنده کمترین اولویت است. پردازش قواعد به محض یافتن نخستین قاعده منطبق متوقف می‌شود و هیچ قاعده دیگری بررسی نخواهد شد.
در ساختار داخلی، اولویت به عنوان یک عدد صحیح ۳۲ بیتی بدون علامت پردازش می‌شود و استفاده از مقدار اولویت بزرگ‌تر از ۴۲۹۴۹۶۷۲۹۵ خطاساز خواهد بود.
اگر چندین قاعده اولویت یکسانی داشته باشند و تنها یکی از قواعد تطبیق مربوطه صدق کند، همان قاعده انتخاب خواهد شد. اگر چندین قاعده با اولویت یکسان تطبیق داده شوند، یکی از آن‌ها انتخاب می‌شود اما این انتخاب نامعین و غیرقابل پیش‌بینی است. برای جلوگیری از این رفتار نامعین، یا از اولویت‌های متفاوتی استفاده کنید یا قواعد تطبیق را مشخص‌تر و محدودتر کنید، برای نمونه با استفاده از الگوهای متمایز <ISSUER>.
قاعده تطبیق (MATCHING RULE)
قاعده تطبیق برای انتخاب گواهی‌نامه‌ای به کار می‌رود که قاعده نگاشت باید روی آن اعمال شود. این سازوکار از سیستمی مشابه با گزینه “pkinit_cert_match” در MIT Kerberos استفاده می‌کند. این قاعده شامل یک کلمه کلیدی احاطه‌شده میان '<' و '>' است که بخش مشخصی از گواهی‌نامه را تعیین می‌کند و یک الگو که برای برقراری انطباق باید پیدا شود. چندین جفت کلمه کلیدی-الگو می‌توانند با '&&' (و / AND) یا '||' (یا / OR) به یکدیگر متصل شوند.
با توجه به شباهت به MIT Kerberos، پیشوند نوع برای این قاعده 'KRB5' است. با این حال، 'KRB5' پیش‌فرض “قواعد تطبیق” نیز خواهد بود، بنابراین دو عبارت "<SUBJECT>.*,DC=MY,DC=DOMAIN" و "KRB5:<SUBJECT>.*,DC=MY,DC=DOMAIN" معادل یکدیگر هستند.
گزینه‌های موجود عبارتند از:
<SUBJECT>regular-expression
برای تطبیق، نام موضوع ذخیره‌شده در گواهی‌نامه با کدگذاری ASN.1 DER طبق RFC 4514 به یک رشته تبدیل می‌شود. این بدان معناست که خاص‌ترین مؤلفه نام در ابتدا قرار می‌گیرد. لطفاً توجه داشته باشید که تمام نام‌های ممکن برای مشخصه‌ها توسط RFC 4514 پوشش داده نشده‌اند. نام‌های گنجانده‌شده عبارتند از: 'CN'، 'L'، 'ST'، 'O'، 'OU'، 'C'، 'STREET'، 'DC' و 'UID'. سایر نام‌های مشخصه‌ها ممکن است در بسترها و ابزارهای مختلف به شکل‌های متفاوتی نمایش داده شوند. برای جلوگیری از سردرگمی، بهتر است از این نام‌ها استفاده نشود یا با یک عبارت باقاعده مناسب پوشش داده شوند.
مثال: <SUBJECT>.*,DC=MY,DC=DOMAIN
لطفاً توجه داشته باشید که نویسه‌های "^.[$()|*+?{\" در عبارت‌های باقاعده دارای معانی خاص هستند و باید به کمک نویسه '\' اسکیپ شوند تا به عنوان نویسه‌های معمولی تطبیق داده شوند.
مثال: <SUBJECT>^CN=.* \(Admin\),DC=MY,DC=DOMAIN$
<ISSUER>regular-expression
مثال: <ISSUER>^CN=My-CA,DC=MY,DC=DOMAIN$
<KU>key-usage
یک مقدار عددی در محدوده اعداد صحیح ۳۲ بیتی بدون علامت نیز می‌تواند برای پوشش موارد خاص استفاده شود.
مثال: <KU>digitalSignature,keyEncipherment
<EKU>extended-key-usage
کاربردهای گسترده کلیدی که در بالا فهرست نشده‌اند را می‌توان با OID آن‌ها در قالب نشانه‌گذاری ده‌دهی نقطه‌دار (dotted-decimal) مشخص کرد.
مثال: <EKU>clientAuth,1.3.6.1.5.2.3.4
<SAN>regular-expression
مثال: <SAN>.*@MY\.REALM
<SAN:Principal>regular-expression
مثال: <SAN:Principal>.*@MY\.REALM
<SAN:ntPrincipalName>regular-expression
مثال: <SAN:ntPrincipalName>.*@MY.AD.REALM
<SAN:pkinit>regular-expression
مثال: <SAN:ntPrincipalName>.*@MY\.PKINIT\.REALM
<SAN:dotted-decimal-oid>regular-expression
مثال: <SAN:1.2.3.4>test
<SAN:otherName>base64-string
مثال: <SAN:otherName>MTIz
<SAN:rfc822Name>regular-expression
مثال: <SAN:rfc822Name>.*@email\.domain
<SAN:dNSName>regular-expression
مثال: <SAN:dNSName>.*\.my\.dns\.domain
<SAN:x400Address>base64-string
مثال: <SAN:x400Address>MTIz
<SAN:directoryName>regular-expression
مثال: <SAN:directoryName>.*,DC=com
<SAN:ediPartyName>base64-string
مثال: <SAN:ediPartyName>MTIz
<SAN:uniformResourceIdentifier>regular-expression
مثال: <SAN:uniformResourceIdentifier>URN:.*
<SAN:iPAddress>regular-expression
مثال: <SAN:iPAddress>192\.168\..*
<SAN:registeredID>regular-expression
مثال: <SAN:registeredID>1\.2\.3\..*
قاعده نگاشت (MAPPING RULE)
قاعده نگاشت برای انتساب یک گواهی‌نامه به یک یا چند حساب کاربری استفاده می‌شود. سپس می‌توان از یک کارت هوشمند (Smartcard) حاوی گواهی‌نامه و کلید خصوصی متناظر با آن برای احراز هویت به عنوان یکی از آن حساب‌ها استفاده کرد.
در حال حاضر SSSD اساساً فقط از LDAP برای جستجوی اطلاعات کاربر پشتیبانی می‌کند (استثنا ارائه‌دهنده پراکسی است که در اینجا اهمیتی ندارد). به همین دلیل، قاعده نگاشت بر پایه نحو فیلتر جستجوی LDAP همراه با الگوهایی برای افزودن محتوای گواهی‌نامه به فیلتر طراحی شده است. انتظار می‌رود که فیلتر تنها حاوی داده‌های خاص مورد نیاز برای نگاشت باشد و فراخواننده آن را برای انجام جستجوی واقعی در فیلتر دیگری بگنجاند. به همین علت، رشته فیلتر باید به ترتیب با '(' و ')' شروع و پایان یابد.
به طور کلی توصیه می‌شود مشخصه‌های برگرفته از گواهی‌نامه را به مشخصه‌های ویژه‌ای در شیء کاربری LDAP اضافه کنید. برای نمونه، می‌توان از مشخصه 'altSecurityIdentities' در AD یا مشخصه 'ipaCertMapData' در IPA استفاده کرد.
این روش باید بر خواندن داده‌های خاص کاربر از گواهی‌نامه مانند آدرس ایمیل و جستجوی آن در کارساز LDAP ترجیح داده شود. دلیل آن این است که داده‌های خاص کاربر در LDAP ممکن است به دلایل گوناگون تغییر کرده و نگاشت را مختل کنند. از سوی دیگر، شکستن عمدی نگاشت برای یک کاربر خاص به این شیوه بسیار دشوار خواهد بود.
نوع پیش‌فرض “قاعده نگاشت” برابر با 'LDAP' است که می‌تواند به عنوان یک پیشوند به قاعده اضافه شود؛ مانند 'LDAP:(userCertificate;binary={cert!bin})'. افزونه‌ای به نام 'LDAPU1' نیز وجود دارد که الگوهای بیشتری را برای انعطاف‌پذیری بالاتر ارائه می‌دهد. برای آنکه نسخه‌های قدیمی‌تر این کتابخانه بتوانند افزونه را نادیده بگیرند، هنگام استفاده از الگوهای جدید در یک “قاعده نگاشت” باید حتماً از پیشوند 'LDAPU1' استفاده شود، در غیر این صورت نسخه‌های قدیمی کتابخانه با خطای تجزیه مواجه خواهند شد. الگوهای جدید در بخش “افزونه LDAPU1 (LDAPU1 extension)” توضیح داده شده‌اند.
الگوهای افزودن داده‌های گواهی‌نامه به فیلتر جستجو بر اساس رشته‌های قالب‌بندی سبک پایتون (Python-style) هستند. آن‌ها از یک کلمه کلیدی درون آکولادها همراه با یک تعیین‌کننده اختیاری زیرمؤلفه که با '.' جدا می‌شود، یا یک گزینه اختیاری تبدیل/قالب‌بندی که با '!' جدا می‌شود تشکیل شده‌اند. مقادیر مجاز عبارتند از:
{issuer_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}
گزینه‌های تبدیل که با 'ad_' شروع می‌شوند از نام مشخصه‌ها به صورتی که در AD کاربرد دارد استفاده خواهند کرد؛ برای نمونه 'S' به جای 'ST'.
گزینه‌های تبدیل که با 'nss_' شروع می‌شوند از نام مشخصه‌ها مطابق با کاربرد در NSS استفاده خواهند کرد.
گزینه تبدیل پیش‌فرض 'nss' است؛ یعنی نام مشخصه‌ها مطابق با NSS و با ترتیب LDAP/RFC 4514.
مثال: (ipacertmapdata=X509:<I>{issuer_dn!ad}<S>{subject_dn!ad})
{subject_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}
گزینه‌های تبدیل که با 'ad_' شروع می‌شوند از نام مشخصه‌ها به صورتی که در AD کاربرد دارد استفاده خواهند کرد؛ برای نمونه 'S' به جای 'ST'.
گزینه‌های تبدیل که با 'nss_' شروع می‌شوند از نام مشخصه‌ها مطابق با کاربرد در NSS استفاده خواهند کرد.
گزینه تبدیل پیش‌فرض 'nss' است؛ یعنی نام مشخصه‌ها مطابق با NSS و با ترتیب LDAP/RFC 4514.
مثال: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
{cert[!(bin|base64)]}
مثال: (userCertificate;binary={cert!bin})
{subject_principal[.short_name]}
مثال: (|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name}))
{subject_pkinit_principal[.short_name]}
مثال: (|(userPrincipal={subject_pkinit_principal})(uid={subject_pkinit_principal.short_name}))
{subject_nt_principal[.short_name]}
مثال: (|(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.short_name}))
{subject_rfc822_name[.short_name]}
مثال: (|(mail={subject_rfc822_name})(uid={subject_rfc822_name.short_name}))
{subject_dns_name[.short_name]}
مثال: (|(fqdn={subject_dns_name})(host={subject_dns_name.short_name}))
{subject_uri}
مثال: (uri={subject_uri})
{subject_ip_address}
مثال: (ip={subject_ip_address})
{subject_x400_address}
مثال: (attr:binary={subject_x400_address})
{subject_directory_name[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}
مثال: (orig_dn={subject_directory_name})
{subject_ediparty_name}
مثال: (attr:binary={subject_ediparty_name})
{subject_registered_id}
مثال: (oid={subject_registered_id})
افزونه LDAPU1 (LDAPU1
extension)
الگوهای زیر هنگام استفاده از افزونه 'LDAPU1' در دسترس هستند:
{serial_number[!(dec|hex[_ucr])]}
با گزینه قالب‌بندی '!dec'، عدد به صورت یک رشته ده‌دهی چاپ خواهد شد. خروجی هگزادسیمال را می‌توان با حروف بزرگ ('!hex_u')، با دو نقطه برای جداسازی بایت‌های هگزادسیمال ('!hex_c') یا با بایت‌های هگزادسیمال به ترتیب معکوس ('!hex_r') چاپ کرد. پسوندهای حرفی را می‌توان ترکیب کرد؛ به عنوان نمونه '!hex_uc' یک رشته هگزادسیمال با حروف بزرگ و جداشده با دو نقطه تولید می‌کند.
مثال: LDAPU1:(serial={serial_number})
{subject_key_id[!hex[_ucr]]}
خروجی هگزادسیمال را می‌توان با حروف بزرگ ('!hex_u')، با دو نقطه برای جداسازی بایت‌های هگزادسیمال ('!hex_c') یا با بایت‌های هگزادسیمال به ترتیب معکوس ('!hex_r') چاپ کرد. پسوندهای حرفی را می‌توان ترکیب کرد؛ به طوری که برای نمونه '!hex_uc' یک رشته هگزادسیمال با حروف بزرگ و جداشده با دو نقطه تولید می‌کند.
مثال: LDAPU1:(ski={subject_key_id})
{cert[!DIGEST[_ucr]]}
خروجی هگزادسیمال را می‌توان با حروف بزرگ ('!sha512_u')، با دو نقطه برای جداسازی بایت‌های هگزادسیمال ('!sha512_c') یا با بایت‌های هگزادسیمال به ترتیب معکوس ('!sha512_r') چاپ کرد. پسوندهای حرفی را می‌توان با یکدیگر ترکیب کرد؛ برای نمونه '!sha512_uc' یک رشته هگزادسیمال با حروف بزرگ و جداشده با دو نقطه تولید می‌کند.
مثال: LDAPU1:(dgst={cert!sha256})
{subject_dn_component[(.attr_name|[number]]}
یک مؤلفه متفاوت را می‌توان یا از طریق نام مشخصه، مانند {subject_dn_component.uid}، یا از روی جایگاه، مانند {subject_dn_component.[2]} انتخاب کرد؛ در اینجا اعداد مثبت شمارش را از خاص‌ترین مؤلفه و اعداد منفی از عمومی‌ترین مؤلفه آغاز می‌کنند. نام مشخصه و جایگاه را می‌توان با هم ترکیب کرد، برای نمونه {subject_dn_component.uid[2]} به این معنی است که نام مؤلفه دوم باید حتماً 'uid' باشد.
مثال: LDAPU1:(uid={subject_dn_component.uid})
{issuer_dn_component[(.attr_name|[number]]}
برای جزئیات بیشتر درباره تعیین‌کننده‌های نام مشخصه و جایگاه، 'subject_dn_component' را ببینید.
مثال: LDAPU1:(domain={issuer_dn_component.[-2]}.{issuer_dn_component.dc[-1]})
{sid[.rid]}
مثال: LDAPU1:(objectsid={sid})
فهرست دامنه‌ها (DOMAIN LIST)
اگر فهرست دامنه‌ها خالی نباشد، کاربران نگاشت‌شده به یک گواهی‌نامه خاص نه تنها در دامنه محلی، بلکه در دامنه‌های فهرست‌شده نیز تا زمانی که برای SSSD شناخته‌شده باشند جستجو خواهند شد. دامنه‌هایی که برای SSSD ناشناخته هستند نادیده گرفته می‌شوند.
نویسندگان (AUTHORS)
The SSSD upstream - https://github.com/SSSD/sssd
| 06/09/2026 | SSSD |