SSS-CERTMAP(5) Формати файлів та правила SSS-CERTMAP(5)

sss-certmap - Правила встановлення відповідності і прив'язування сертифікатів SSSD

ОПИС

На цій сторінці підручника описано правила, якими можна скористатися у SSSD та інших компонентах для встановлення відповідності сертифікатів X.509 та прив'язування їх до облікових записів.

У кожного правила чотири компоненти — “пріоритетність”, “правило встановлення відповідності”, “правило прив'язки” і “список доменів”. Усі компоненти є необов'язковими. Якщо не вказано “пріоритетність”, буде додано правило із найнижчою пріоритетністю. Типове “правило встановлення відповідності” встановлює відповідність сертифікатів із використанням ключів digitalSignature і розширеним використанням ключів clientAuth. Якщо “правило прив'язки” є порожнім, сертифікати шукатимуться у атрибуті userCertificate у форматі закодованих двійкових даних DER. Якщо не буде вказано доменів, пошук відбуватиметься у локальному домені.

Щоб дозволити розширення або зовсім інший стиль правила, “прив'язки” та “правила відповідності” можуть містити префікс відокремлений символом «:» від основної частини правила. Префікс може містити лише літери верхнього регістру ASCII і цифри. Якщо префікс пропущено, буде використано стандартний тип, яким є «KRB5» для правил відповідності і «LDAP» для правил прив'язки.

Допоміжна програма «sssctl» надає доступ до команди «cert-eval-rule», яку призначено для перевірки, чи відповідає вказаний сертифікат правилам відповідності, і визначає, як виглядатиме виведення правила прив'язки.

КОМПОНЕНТИ ПРАВИЛ

ПРІОРИТЕТНІСТЬ

Правила оброблятимуться за пріоритетністю, номер «0» (нуль) відповідає найвищому рівню пріоритетності. Чим більшим є значення, тим нижчою є пріоритетність. Якщо значення не вказано, пріоритетність вважається найнижчою. Обробку правил буде зупинено, якщо вдасться знайти відповідність правилу, подальші правила не оброблятимуться.

На внутрішньому рівні пріоритетність визначається 32-бітовим цілим числом без знаку. Використання значення пріоритетності, що перевищує 4294967295, призводитиме до виведення повідомлення про помилку.

Якщо однакову пріоритетність мають декілька правил, а застосовувати можна лише одне із пов'язаних відповідних правил, буде вибрано це правило. Якщо існує декілька відповідних правил із однаковою пріоритетністю, буде вибрано одне, але яке само не визначено. Щоб уникнути цієї невизначеної поведінки або використовуйте різні пріоритетності, або зробіть правила відповідності специфічнішими, наприклад, скориставшись явними взірцями <ISSUER>.

ПРАВИЛО ВІДПОВІДНОСТІ

Правило встановлення відповідності використовується для вибору сертифіката, до якого слід застосовувати правило прив'язки. У цьому використовується система, подібна до використаної у параметрі “pkinit_cert_match” Kerberos MIT. Правило складається з ключового слова між символами «<» і «>», яке визначає певну частину сертифіката, і взірцем, який має бути знайдено, для встановлення відповідності правила. Декілька пар ключове слово-взірець можна сполучати за допомогою логічних операторів «&&» (та) або «||» (або).

Якщо задано подібність до MIT Kerberos, префіксом для цього правила є «KRB5». Втім, «KRB5» також буде типовим для “правил відповідності”, тому «<SUBJECT>.*,DC=MY,DC=DOMAIN» і «KRB5:<SUBJECT>.*,DC=MY,DC=DOMAIN» є рівнозначними.

Доступні варіанти:

<SUBJECT>формальний-вираз

За допомогою цього компонент можна встановлювати відповідність частини або усього запису призначення. Для встановлення відповідності використовується синтаксис розширених формальних виразів POSIX. Докладніший опис синтаксису можна знайти на сторінці підручника regex(7).

Для встановлення відповідності запис призначення, що зберігається у сертифікаті у форматі кодованого 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>формальний-вираз

За допомогою цього компонент можна встановлювати відповідність частини або усього запису видавця. Цього запису стосуються усі коментарі щодо <SUBJECT>.

Приклад: <ISSUER>^CN=My-CA,DC=MY,DC=DOMAIN$

<KU>використання-ключа

За допомогою цього параметра можна визначити значення використання ключа, які повинен містити сертифікат. У списку значень, відокремлених комами, можна використовувати такі значення:
•digitalSignature
•nonRepudiation
•keyEncipherment
•dataEncipherment
•keyAgreement
•keyCertSign
•cRLSign
•encipherOnly
•decipherOnly

Для спеціальних випадків можна також використати числове значення у діапазоні 32-бітових цілих чисел без знаку.

Приклад: <KU>digitalSignature,keyEncipherment

<EKU>розширене-використання-ключа

За допомогою цього параметра можна визначити значення розширеного використання ключа, які повинен містити сертифікат. У списку значень, відокремлених комами, можна використовувати такі значення:
•serverAuth
•clientAuth
•codeSigning
•emailProtection
•timeStamping
•OCSPSigning
•KPClientAuth
•pkinit
•msScLogin

Розширені використання ключа, які не потрапили до вказаного вище списку, можна визначити за допомогою їхнього OID у точково-десятковому позначенні.

Приклад: <EKU>clientAuth,1.3.6.1.5.2.3.4

<SAN>формальний-вираз

Для сумісності із використанням Kerberos MIT цей параметр встановлюватиме відповідність реєстраційних даних Kerberos у PKINIT або AD NT Principal SAN так, як це робить <SAN:Principal>.

Приклад: <SAN>.*@MY\.REALM

<SAN:Principal>формальний-вираз

Встановити відповідність реєстраційних даних Kerberos у PKINIT або AD NT Principal SAN.

Приклад: <SAN:Principal>.*@MY\.REALM

<SAN:ntPrincipalName>формальний-вираз

Встановити відповідність реєстраційних даних Kerberos з AD NT Principal SAN.

Приклад: <SAN:ntPrincipalName>.*@MY.AD.REALM

<SAN:pkinit>формальний-вираз

Встановити відповідність реєстраційних даних Kerberos з SAN PKINIT.

Приклад: <SAN:ntPrincipalName>.*@MY\.PKINIT\.REALM

<SAN:dotted-decimal-oid>формальний-вираз

Отримати значення компонента SAN otherName, яке задано OID у крапково-десятковому позначенні, обробити його як рядок і спробувати встановити відповідність формальному виразу.

Приклад: <SAN:1.2.3.4>test

<SAN:otherName>base64-string

Виконати спробу встановлення двійкової відповідності блоку у кодуванні base64 із усіма компонентами SAN otherName. За допомогою цього параметра можна встановлювати відповідність із нетиповими компонентами otherName із особливими кодуваннями, які не можна обробляти як рядки.

Приклад: <SAN:otherName>MTIz

<SAN:rfc822Name>формальний-вираз

Встановити відповідність значення SAN rfc822Name.

Приклад: <SAN:rfc822Name>.*@email\.domain

<SAN:dNSName>формальний-вираз

Встановити відповідність значення SAN dNSName.

Приклад: <SAN:dNSName>.*\.my\.dns\.domain

<SAN:x400Address>рядок-base64

Встановити двійкову відповідність значення SAN x400Address.

Приклад: <SAN:x400Address>MTIz

<SAN:directoryName>формальний-вираз

Встановити відповідність значення SAN directoryName. Цього параметра стосуються ті самі коментарі, які було вказано для параметрів <ISSUER> та <SUBJECT>.

Приклад: <SAN:directoryName>.*,DC=com

<SAN:ediPartyName>рядок-base64

Встановити двійкову відповідність значення SAN ediPartyName.

Приклад: <SAN:ediPartyName>MTIz

<SAN:uniformResourceIdentifier>формальний-вираз

Встановити відповідність значення SAN uniformResourceIdentifier.

Приклад: <SAN:uniformResourceIdentifier>URN:.*

<SAN:iPAddress>формальний-вираз

Встановити відповідність значення SAN iPAddress.

Приклад: <SAN:iPAddress>192\.168\..*

<SAN:registeredID>формальний-вираз

Встановити значення SAN registeredID у форматі точково-десяткового рядка.

Приклад: <SAN:registeredID>1\.2\.3\..*

ПРАВИЛО ПРИВʼЯЗУВАННЯ

Правило прив'язки використовується для пов'язування сертифіката із одним або декількома обліковими записами. Далі, смарткарткою із сертифікатом та відповідним закритим ключем можна скористатися для розпізнавання за одним з цих облікових записів.

У поточній версії SSSD на базовому рівні підтримує пошук даних користувачів лише у LDAP (винятком є лише засіб надання проксі, який у цьому контексті є недоречним). Через це правило прив'язки засновано на синтаксисі фільтрування пошуку LDAP з шаблонами для додавання вмісту сертифікатів до фільтра. Очікується, що цей фільтр міститиме лише специфічні дані, потрібні для прив'язки, яку функція виклику вбудовуватиме до іншого фільтра для виконання справжнього пошуку. Через це рядок фільтрування має починатися із завершуватися «(» і «)», відповідно.

Загалом, рекомендується використовувати атрибути з сертифіката і додати їх до спеціальних атрибутів об'єкта користувача LDAP. Наприклад, можна скористатися атрибутом «altSecurityIdentities» у AD або атрибутом «ipaCertMapData» для IPA.

Бажаним шляхом є читання із сертифіката специфічних для користувача даних, наприклад адреси електронної пошти, і пошук цих даних на сервері LDAP. Причиною є те, що специфічні для користувача дані у LDAP можу бути з різних причин змінено, що розірве прив'язку. З іншого боку, якщо скористатися бажаним шляхом, розірвати прив'язку буде важко.

Стандартним типом “правила прив'язки” є «LDAP». Цей запис може бути додано як префікс до правила. Ось так, наприклад: «LDAP:(userCertificate;binary={cert!bin})». Передбачено розширення, яке має назву «LDAPU1», і яке надає додаткові шаблони для збільшення гнучкості. Щоб дозволити застарілим версіям цієї бібліотеки ігнорувати розширення, при використанні нових шаблонів у “правилі прив'язки” має бути використано префікс «LDAPU1», інакше роботу застарілої версії цієї бібліотеки буде завершено із повідомленням про помилку при обробці вхідних даних. Нові шаблони описано у розділі the section called “Розширення LDAPU1”.

Шаблони для додавання даних сертифікатів до фільтра пошуку засновано на рядках форматування у стилі Python. Воли складаються з ключового слова у фігурних дужках із додатковим підкомпонентом-специфікатором, відокремленим «.», або додатковим параметром перетворення-форматування, відокремленим «!». Дозволені значення:

{issuer_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}

Цей шаблон додасть повний DN видавця, перетворений на рядок відповідно до RFC 4514. Якщо використано упорядковування X.500 (найспецифічніший RDN стоїть останнім), буде використано параметр із префіксом «_x500».

У варіантах перетворення, назви яких починаються з «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))]}

Цей шаблон додасть повний DN призначення, перетворений на рядок відповідно до RFC 4514. Якщо використано упорядковування X.500 (найспецифічніший RDN стоїть останнім), буде використано параметр із префіксом «_x500».

У варіантах перетворення, назви яких починаються з «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)]}

Цей шаблон додасть увесь сертифікат у кодуванні DER як рядок до фільтра пошуку. Залежно від параметра перетворення, двійковий сертифікат або буде преетворено на екрановану послідовність шістнадцяткових чисел у форматі «\xx», або на код base64. Типовим варіантом є екранована шістнадцяткова послідовність, її може бути, наприклад, використано з атрибутом LDAP «userCertificate;binary».

Приклад: (userCertificate;binary={cert!bin})

{subject_principal[.short_name]}

Цей шаблон додасть реєстраційні дані Kerberos, які буде взято або з SAN, який використовується pkinit, або з реєстраційних даних AD. Компонент «short_name» відповідає першій частині реєстраційного запису до символу «@».

Приклад: (|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name}))

{subject_pkinit_principal[.short_name]}

Цей шаблон додасть реєстраційні дані Kerberos, які буде передано SAN, що використовується pkinit. Компонент «short_name» відповідає першій частині реєстраційного запису до символу «@».

Приклад: (|(userPrincipal={subject_pkinit_principal})(uid={subject_pkinit_principal.short_name}))

{subject_nt_principal[.short_name]}

Цей шаблон додасть реєстраційні дані Kerberos, які буде передано SAN, що використовується AD. Компонент «short_name» відповідає першій частині реєстраційного запису до символу «@».

Приклад: (|(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.short_name}))

{subject_rfc822_name[.short_name]}

Цей шаблон додасть рядок, який зберігається у компоненті rfc822Name SAN, типово, адресу електронної пошти. Компонент «short_name» відповідає першій частині адреси до символу «@».

Приклад: (|(mail={subject_rfc822_name})(uid={subject_rfc822_name.short_name}))

{subject_dns_name[.short_name]}

Цей шаблон додасть рядок, який зберігається у компоненті dNSName SAN, типово, повну назву вузла. Компонент «short_name» відповідає першій частині назви до першого символу «.».

Приклад: (|(fqdn={subject_dns_name})(host={subject_dns_name.short_name}))

{subject_uri}

Цей шаблон додає рядок, який зберігається у компоненті uniformResourceIdentifier SAN.

Приклад: (uri={subject_uri})

{subject_ip_address}

Цей шаблон додає рядок, який зберігається у компоненті iPAddress SAN.

Приклад: (ip={subject_ip_address})

{subject_x400_address}

Цей шаблон додає значення, яке зберігається у компоненті x400Address SAN як послідовність екранованих шістнадцяткових чисел.

Приклад: (attr:binary={subject_x400_address})

{subject_directory_name[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}

Цей шаблон додасть рядок DN значення, яке зберігається у компоненті directoryName SAN.

Приклад: (orig_dn={subject_directory_name})

{subject_ediparty_name}

Цей шаблон додає значення, яке зберігається у компоненті ediPartyName SAN як послідовність екранованих шістнадцяткових чисел.

Приклад: (attr:binary={subject_ediparty_name})

{subject_registered_id}

Цей шаблон додає OID, який зберігається у компоненті registeredID SAN у форматі точково-десяткового рядка.

Приклад: (oid={subject_registered_id})

Розширення LDAPU1

При використанні розширення LDAPU1 можна скористатися такими шаблонами:

{serial_number[!(dec|hex[_ucr])]}

Цей шаблон додасть серійний номер сертифіката. Типово, його буде надруковано як шістнадцяткове число літерами нижнього регістру.

Якщо використано параметр форматування «!dec», число буде виведено як десятковий рядок. Виведені шістнадцяткові дані може бути показано за допомогою літер верхнього регістру («!hex_u»), із двокрапкою, що відокремлює шістнадцяткові байти («!hex_c»), або із шістнадцятковими байтами у зворотному порядку («!hex_r»). Літер постфікса може бути поєднано, отже, наприклад, «!hex_uc» призведе до виведення відокремленого двокрапками шістнадцяткового рядка із літер верхнього регістру.

Приклад: LDAPU1:(serial={серійний_номер})

{subject_key_id[!hex[_ucr]]}

Цей шаблон додасть ідентифікатор ключа призначення сертифіката. Типово, його буде надруковано як шістнадцяткове число літерами нижнього регістру.

Виведені шістнадцяткові дані може бути показано за допомогою літер верхнього регістру («!hex_u»), із двокрапкою, що відокремлює шістнадцяткові байти («!hex_c»), або із шістнадцятковими байтами у зворотному порядку («!hex_r»). Літер постфікса може бути поєднано, отже, наприклад, «!hex_uc» призведе до виведення відокремленого двокрапками шістнадцяткового рядка із літер верхнього регістру.

Приклад: LDAPU1:(ski={ідентифікатор_ключа_призначення})

{cert[!DIGEST[_ucr]]}

Цей шаблон додає шістнадцяткову контрольну суму або хеш до сертифіката. Запис DIGEST має бути замінено назвою функції контрольної суми або хешу, підтримку яких передбачено у OpenSSL, наприклад «sha512».

Виведені шістнадцяткові дані може бути показано за допомогою літер верхнього регістру («!sha512_u»), із двокрапкою, що відокремлює шістнадцяткові байти («!sha512_c»), або із шістнадцятковими байтами у зворотному порядку («!sha512_r») Літер постфікса може бути поєднано, отже, наприклад, «!sha512_uc» призведе до виведення відокремленого двокрапками шістнадцяткового рядка із літер верхнього регістру.

Приклад: LDAPU1:(dgst={cert!sha256})

{subject_dn_component[(.назва_атрибуту|[число]]}

Цей шаблон додасть значення атрибуту компонента DN призначення. Типовим значенням є найспецифічніший компонент.

Можна вибрати інший компонент або за назвою атрибуту, наприклад, {subject_dn_component.uid}, або за позицією, наприклад, {subject_dn_component.[2]}, де додатні числа означають відлік від найбільш специфічного компонента, а від'ємні числа — відлік від найменш специфічного компонента. Назву атрибуту та позицію можна поєднувати. Приклад: {subject_dn_component.uid[2]}, тобто назвою другого компонента має бути «uid».

Приклад: LDAPU1:(uid={subject_dn_component.uid})

{issuer_dn_component[(.назва_атрибуту|[число]]}

Цей шаблон додасть значення атрибуту компонента DN видавця. Типовим значенням є найспецифічніший компонент.

Див. «subject_dn_component», щоб дізнатися більше про назви атрибутів та специфікатори позиції.

Приклад: LDAPU1:(domain={issuer_dn_component.[-2]}.{issuer_dn_component.dc[-1]})

{sid[.rid]}

Цей шаблон додасть SID, якщо відповідне розширення впроваджено Microsoft із доступним OID 1.3.6.1.4.1.311.25.2. Якщо вказано «.rid», буде додано лише останній компонент, тобто RID.

Приклад: LDAPU1:(objectsid={sid})

СПИСОК ДОМЕНІВ

Якщо список доменів не є порожнім, записи користувачів, прив'язані до заданого сертифіката, шукаються не лише у локальному домені, а і у доменах зі списку, якщо вони відомі SSSD. Домени, які не відомі SSSD, буде проігноровано.

Основна гілка розробки SSSD — https://pagure.io/SSSD/sssd/

03/22/2024 SSSD