table of contents
SSS-CERTMAP(5) | Формати файлів та правила | SSS-CERTMAP(5) |
NAME¶
sss-certmap - Правила встановлення відповідності і прив'язування сертифікатів SSSD
ОПИС¶
На цій сторінці підручника описано правила, якими можна скористатися у SSSD та інших компонентах для встановлення відповідності сертифікатів X.509 та прив'язування їх до облікових записів.
У кожного правила чотири компоненти — “пріоритетність”, “правило встановлення відповідності”, “правило прив'язки” і “список доменів”. Усі компоненти є необов'язковими. Якщо не вказано “пріоритетність”, буде додано правило із найнижчою пріоритетністю. Типове “правило встановлення відповідності” встановлює відповідність сертифікатів із використанням ключів digitalSignature і розширеним використанням ключів clientAuth. Якщо “правило прив'язки” є порожнім, сертифікати шукатимуться у атрибуті userCertificate у форматі закодованих двійкових даних DER. Якщо не буде вказано доменів, пошук відбуватиметься у локальному домені.
To allow extensions or completely different style of rule the “mapping” and “matching rules” can contain a prefix separated with a ':' from the main part of the rule. The prefix may only contain upper-case ASCII letters and numbers. If the prefix is omitted the default type will be used which is 'KRB5' for the matching rules and 'LDAP' for the mapping rules.
The 'sssctl' utility provides the 'cert-eval-rule' command to check if a given certificate matches a matching rules and how the output of a mapping rule would look like.
КОМПОНЕНТИ ПРАВИЛ¶
ПРІОРИТЕТНІСТЬ¶
Правила оброблятимуться за пріоритетністю, номер «0» (нуль) відповідає найвищому рівню пріоритетності. Чим більшим є значення, тим нижчою є пріоритетність. Якщо значення не вказано, пріоритетність вважається найнижчою. Обробку правил буде зупинено, якщо вдасться знайти відповідність правилу, подальші правила не оброблятимуться.
На внутрішньому рівні пріоритетність визначається 32-бітовим цілим числом без знаку. Використання значення пріоритетності, що перевищує 4294967295, призводитиме до виведення повідомлення про помилку.
Якщо однакову пріоритетність мають декілька правил, а застосовувати можна лише одне із пов'язаних відповідних правил, буде вибрано це правило. Якщо існує декілька відповідних правил із однаковою пріоритетністю, буде вибрано одне, але яке само не визначено. Щоб уникнути цієї невизначеної поведінки або використовуйте різні пріоритетності, або зробіть правила відповідності специфічнішими, наприклад, скориставшись явними взірцями <ISSUER>.
ПРАВИЛО ВІДПОВІДНОСТІ¶
Правило встановлення відповідності використовується для вибору сертифіката, до якого слід застосовувати правило прив'язки. У цьому використовується система, подібна до використаної у параметрі “pkinit_cert_match” Kerberos MIT. Правило складається з ключового слова між символами «<» і «>», яке визначає певну частину сертифіката, і взірцем, який має бути знайдено, для встановлення відповідності правила. Декілька пар ключове слово-взірець можна сполучати за допомогою логічних операторів «&&» (та) або «||» (або).
Given the similarity to MIT Kerberos the type prefix for this rule is 'KRB5'. But 'KRB5' will also be the default for “matching rules” so that "<SUBJECT>.*,DC=MY,DC=DOMAIN" and "KRB5:<SUBJECT>.*,DC=MY,DC=DOMAIN" are equivalent.
Доступні варіанти:
<SUBJECT>формальний-вираз
Для встановлення відповідності запис призначення, що зберігається у сертифікаті у форматі кодованого DER ASN.1, буде перетворено на текстовий рядок відповідно до 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>формальний-вираз
Приклад: <ISSUER>^CN=My-CA,DC=MY,DC=DOMAIN$
<KU>використання-ключа
Для спеціальних випадків можна також використати числове значення у діапазоні 32-бітових цілих чисел без знаку.
Приклад: <KU>digitalSignature,keyEncipherment
<EKU>розширене-використання-ключа
Розширені використання ключа, які не потрапили до вказаного вище списку, можна визначити за допомогою їхнього OID у точково-десятковому позначенні.
Приклад: <EKU>clientAuth,1.3.6.1.5.2.3.4
<SAN>формальний-вираз
Приклад: <SAN>.*@MY\.REALM
<SAN:Principal>формальний-вираз
Приклад: <SAN:Principal>.*@MY\.REALM
<SAN:ntPrincipalName>формальний-вираз
Приклад: <SAN:ntPrincipalName>.*@MY.AD.REALM
<SAN:pkinit>формальний-вираз
Приклад: <SAN:ntPrincipalName>.*@MY\.PKINIT\.REALM
<SAN:dotted-decimal-oid>формальний-вираз
Приклад: <SAN:1.2.3.4>test
<SAN:otherName>base64-string
Приклад: <SAN:otherName>MTIz
<SAN:rfc822Name>формальний-вираз
Приклад: <SAN:rfc822Name>.*@email\.domain
<SAN:dNSName>формальний-вираз
Приклад: <SAN:dNSName>.*\.my\.dns\.domain
<SAN:x400Address>рядок-base64
Приклад: <SAN:x400Address>MTIz
<SAN:directoryName>формальний-вираз
Приклад: <SAN:directoryName>.*,DC=com
<SAN:ediPartyName>рядок-base64
Приклад: <SAN:ediPartyName>MTIz
<SAN:uniformResourceIdentifier>формальний-вираз
Приклад: <SAN:uniformResourceIdentifier>URN:.*
<SAN:iPAddress>формальний-вираз
Приклад: <SAN:iPAddress>192\.168\..*
<SAN:registeredID>формальний-вираз
Приклад: <SAN:registeredID>1\.2\.3\..*
ПРАВИЛО ПРИВʼЯЗУВАННЯ¶
Правило прив'язки використовується для пов'язування сертифіката із одним або декількома обліковими записами. Далі, смарткарткою із сертифікатом та відповідним закритим ключем можна скористатися для розпізнавання за одним з цих облікових записів.
У поточній версії SSSD на базовому рівні підтримує пошук даних користувачів лише у LDAP (винятком є лише засіб надання проксі, який у цьому контексті є недоречним). Через це правило прив'язки засновано на синтаксисі фільтрування пошуку LDAP з шаблонами для додавання вмісту сертифікатів до фільтра. Очікується, що цей фільтр міститиме лише специфічні дані, потрібні для прив'язки, яку функція виклику вбудовуватиме до іншого фільтра для виконання справжнього пошуку. Через це рядок фільтрування має починатися із завершуватися «(» і «)», відповідно.
Загалом, рекомендується використовувати атрибути з сертифіката і додати їх до спеціальних атрибутів об'єкта користувача LDAP. Наприклад, можна скористатися атрибутом «altSecurityIdentities» у AD або атрибутом «ipaCertMapData» для IPA.
Бажаним шляхом є читання із сертифіката специфічних для користувача даних, наприклад адреси електронної пошти, і пошук цих даних на сервері LDAP. Причиною є те, що специфічні для користувача дані у LDAP можу бути з різних причин змінено, що розірве прив'язку. З іншого боку, якщо скористатися бажаним шляхом, розірвати прив'язку буде важко.
The default “mapping rule” type is 'LDAP' which can be added as a prefix to a rule like e.g. 'LDAP:(userCertificate;binary={cert!bin})'. There is an extension called 'LDAPU1' which offer more templates for more flexibility. To allow older versions of this library to ignore the extension the prefix 'LDAPU1' must be used when using the new templates in a “mapping rule” otherwise the old version of this library will fail with a parsing error. The new templates are described in section the section called “LDAPU1 extension”.
Шаблони для додавання даних сертифікатів до фільтра пошуку засновано на рядках форматування у стилі Python. Воли складаються з ключового слова у фігурних дужках із додатковим підкомпонентом-специфікатором, відокремленим «.», або додатковим параметром перетворення-форматування, відокремленим «!». Дозволені значення:
{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 extension
The following template are available when using the 'LDAPU1' extension:
{serial_number[!(dec|hex[_ucr])]}
With the formatting option '!dec' the number will be printed as decimal string. The hexadecimal output can be printed with upper-case letters ('!hex_u'), with a colon separating the hexadecimal bytes ('!hex_c') or with the hexadecimal bytes in reverse order ('!hex_r'). The postfix letters can be combined so that e.g. '!hex_uc' will produce a colon-separated hexadecimal string with upper-case letters.
Example: LDAPU1:(serial={serial_number})
{subject_key_id[!hex[_ucr]]}
The hexadecimal output can be printed with upper-case letters ('!hex_u'), with a colon separating the hexadecimal bytes ('!hex_c') or with the hexadecimal bytes in reverse order ('!hex_r'). The postfix letters can be combined so that e.g. '!hex_uc' will produce a colon-separated hexadecimal string with upper-case letters.
Example: LDAPU1:(ski={subject_key_id})
{cert[!DIGEST[_ucr]]}
The hexadecimal output can be printed with upper-case letters ('!sha512_u'), with a colon separating the hexadecimal bytes ('!sha512_c') or with the hexadecimal bytes in reverse order ('!sha512_r'). The postfix letters can be combined so that e.g. '!sha512_uc' will produce a colon-separated hexadecimal string with upper-case letters.
Example: LDAPU1:(dgst={cert!sha256})
{subject_dn_component[(.attr_name|[number]]}
A different component can it either selected by attribute name, e.g. {subject_dn_component.uid} or by position, e.g. {subject_dn_component.[2]} where positive numbers start counting from the most specific component and negative numbers start counting from the least specific component. Attribute name and the position can be combined as e.g. {subject_dn_component.uid[2]} which means that the name of the second component must be 'uid'.
Example: LDAPU1:(uid={subject_dn_component.uid})
{issuer_dn_component[(.attr_name|[number]]}
See 'subject_dn_component' for details about the attribute name and position specifiers.
Example: LDAPU1:(domain={issuer_dn_component.[-2]}.{issuer_dn_component.dc[-1]})
{sid[.rid]}
Example: LDAPU1:(objectsid={sid})
СПИСОК ДОМЕНІВ¶
Якщо список доменів не є порожнім, записи користувачів, прив'язані до заданого сертифіката, шукаються не лише у локальному домені, а і у доменах зі списку, якщо вони відомі SSSD. Домени, які не відомі SSSD, буде проігноровано.
AUTHORS¶
Основна гілка розробки SSSD — https://pagure.io/SSSD/sssd/
04/11/2023 | SSSD |