SSS-CERTMAP(5)

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

ОПИС

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

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

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

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

The rules are processed by priority while the number '0' (zero) indicates the highest priority. The higher the number the lower is the priority. A missing value indicates the lowest priority.

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

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

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

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

<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

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

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

<KU>використання-ключа
    This option can be used to specify which key usage values the certificate should have. The following values can be used in a comma separated list:

        • 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\..*

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

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

Currently SSSD basically only supports LDAP to lookup user information (the exception is the proxy provider which is not of relevance here). Because of this the mapping rule is based on LDAP search filter syntax with templates to add certificate content to the filter. It is expected that the filter will only contain the specific data needed for the mapping and that the caller will embed it in another filter to do the actual search. Because of this the filter string should start and stop with '(' and ')' respectively.

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

This should be preferred to read user specific data from the certificate like e.g. an email address and search for it in the LDAP server. The reason is that the user specific data in LDAP might change for various reasons would break the mapping. On the other hand it would be hard to break the mapping on purpose for a specific user.

The templates to add certificate data to the search filter are based on Python-style formatting strings. They consist of a keyword in curly braces with an optional sub-component specifier separated by a '.' or an optional conversion/formatting option separated by a '!'. Allowed values are:

{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]}
    This template will add the Kerberos principal which is taken either from the SAN used by pkinit or the one used by AD. The 'short_name' component represents the first part of the principal before the '@' sign.

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

{subject_pkinit_principal[.short_name]}
    This template will add the Kerberos principal which is given by the SAN used by pkinit. The 'short_name' component represents the first part of the principal before the '@' sign.

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

{subject_nt_principal[.short_name]}
    This template will add the Kerberos principal which is given by the SAN used by AD. The 'short_name' component represent the first part of the principal before the '@' sign.

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

{subject_rfc822_name[.short_name]}
    This template will add the string which is stored in the rfc822Name component of the SAN, typically an email address. The 'short_name' component represents the first part of the address before the '@' sign.

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

{subject_dns_name[.short_name]}
    This template will add the string which is stored in the dNSName component of the SAN, typically a fully-qualified host name. The 'short_name' component represents the first part of the name before the first '.' sign.

    Приклад: (|(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})

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

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

AUTHORS

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