'\" t
.\" Title: sss-certmap
.\" Author: Основна гілка розробки SSSD \(em https://pagure.io/SSSD/sssd/
.\" Generator: DocBook XSL Stylesheets vsnapshot
.\" Date: 05/17/2024
.\" Manual: Формати файлів та правила
.\" Source: SSSD
.\" Language: English
.\"
.TH "SSS\-CERTMAP" "5" "05/17/2024" "SSSD" "Формати файлів та правила"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "NAME"
sss-certmap \- Правила встановлення відповідності і прив\*(Aqязування сертифікатів SSSD
.SH "ОПИС"
.PP
На цій сторінці підручника описано правила, якими можна скористатися у SSSD та інших компонентах для встановлення відповідності сертифікатів X\&.509 та прив\*(Aqязування їх до облікових записів\&.
.PP
У кожного правила чотири компоненти \(em
\(lqпріоритетність\(rq,
\(lqправило встановлення відповідності\(rq,
\(lqправило прив\*(Aqязки\(rq
і
\(lqсписок доменів\(rq\&. Усі компоненти є необов\*(Aqязковими\&. Якщо не вказано
\(lqпріоритетність\(rq, буде додано правило із найнижчою пріоритетністю\&. Типове
\(lqправило встановлення відповідності\(rq
встановлює відповідність сертифікатів із використанням ключів digitalSignature і розширеним використанням ключів clientAuth\&. Якщо
\(lqправило прив\*(Aqязки\(rq
є порожнім, сертифікати шукатимуться у атрибуті userCertificate у форматі закодованих двійкових даних DER\&. Якщо не буде вказано доменів, пошук відбуватиметься у локальному домені\&.
.PP
Щоб дозволити розширення або зовсім інший стиль правила,
\(lqприв\*(Aqязки\(rq
та
\(lqправила відповідності\(rq
можуть містити префікс відокремлений символом \(Fo:\(Fc від основної частини правила\&. Префікс може містити лише літери верхнього регістру ASCII і цифри\&. Якщо префікс пропущено, буде використано стандартний тип, яким є \(FoKRB5\(Fc для правил відповідності і \(FoLDAP\(Fc для правил прив\*(Aqязки\&.
.PP
Допоміжна програма \(Fosssctl\(Fc надає доступ до команди \(Focert\-eval\-rule\(Fc, яку призначено для перевірки, чи відповідає вказаний сертифікат правилам відповідності, і визначає, як виглядатиме виведення правила прив\*(Aqязки\&.
.SH "КОМПОНЕНТИ ПРАВИЛ"
.SS "ПРІОРИТЕТНІСТЬ"
.PP
Правила оброблятимуться за пріоритетністю, номер \(Fo0\(Fc (нуль) відповідає найвищому рівню пріоритетності\&. Чим більшим є значення, тим нижчою є пріоритетність\&. Якщо значення не вказано, пріоритетність вважається найнижчою\&. Обробку правил буде зупинено, якщо вдасться знайти відповідність правилу, подальші правила не оброблятимуться\&.
.PP
На внутрішньому рівні пріоритетність визначається 32\-бітовим цілим числом без знаку\&. Використання значення пріоритетності, що перевищує 4294967295, призводитиме до виведення повідомлення про помилку\&.
.PP
Якщо однакову пріоритетність мають декілька правил, а застосовувати можна лише одне із пов\*(Aqязаних відповідних правил, буде вибрано це правило\&. Якщо існує декілька відповідних правил із однаковою пріоритетністю, буде вибрано одне, але яке само не визначено\&. Щоб уникнути цієї невизначеної поведінки або використовуйте різні пріоритетності, або зробіть правила відповідності специфічнішими, наприклад, скориставшись явними взірцями \&.
.SS "ПРАВИЛО ВІДПОВІДНОСТІ"
.PP
Правило встановлення відповідності використовується для вибору сертифіката, до якого слід застосовувати правило прив\*(Aqязки\&. У цьому використовується система, подібна до використаної у параметрі
\(lqpkinit_cert_match\(rq
Kerberos MIT\&. Правило складається з ключового слова між символами \(Fo<\(Fc і \(Fo>\(Fc, яке визначає певну частину сертифіката, і взірцем, який має бути знайдено, для встановлення відповідності правила\&. Декілька пар ключове слово\-взірець можна сполучати за допомогою логічних операторів \(Fo&&\(Fc (та) або \(Fo||\(Fc (або)\&.
.PP
Якщо задано подібність до MIT Kerberos, префіксом для цього правила є \(FoKRB5\(Fc\&. Втім, \(FoKRB5\(Fc також буде типовим для
\(lqправил відповідності\(rq, тому \(Fo\&.*,DC=MY,DC=DOMAIN\(Fc і \(FoKRB5:\&.*,DC=MY,DC=DOMAIN\(Fc є рівнозначними\&.
.PP
Доступні варіанти:
.PP
формальний\-вираз
.RS 4
За допомогою цього компонент можна встановлювати відповідність частини або усього запису призначення\&. Для встановлення відповідності використовується синтаксис розширених формальних виразів POSIX\&. Докладніший опис синтаксису можна знайти на сторінці підручника regex(7)\&.
.sp
Для встановлення відповідності запис призначення, що зберігається у сертифікаті у форматі кодованого DER ASN\&.1, буде перетворено на текстовий рядок відповідно до RFC 4514\&. Це означає, що першою у рядку буде найспецифічніша компонента\&. Будь ласка, зауважте, що у RFC 4514 описано не усі можливі назви атрибутів\&. Включеними вважаються такі назви: \(FoCN\(Fc, \(FoL\(Fc, \(FoST\(Fc, \(FoO\(Fc, \(FoOU\(Fc, \(FoC\(Fc, \(FoSTREET\(Fc, \(FoDC\(Fc і \(FoUID\(Fc\&. Назви інших атрибутів може бути показано у різний спосіб на різних платформах і у різних інструментах\&. Щоб уникнути двозначностей, не варто використовувати ці атрибути і вживати їх у відповідних формальних виразах\&.
.sp
Приклад: \&.*,DC=MY,DC=DOMAIN
.sp
Будь ласка, зауважте, що символи \(Fo^\&.[$()|*+?{\e\(Fc мають спеціальне значення у формальних виразах, тому їх має бути екрановано за допомогою символу \(Fo\e\(Fc, щоб програма сприймала їх як звичайні символи\&.
.sp
Приклад: ^CN=\&.* \e(Admin\e),DC=MY,DC=DOMAIN$
.RE
.PP
формальний\-вираз
.RS 4
За допомогою цього компонент можна встановлювати відповідність частини або усього запису видавця\&. Цього запису стосуються усі коментарі щодо \&.
.sp
Приклад: ^CN=My\-CA,DC=MY,DC=DOMAIN$
.RE
.PP
використання\-ключа
.RS 4
За допомогою цього параметра можна визначити значення використання ключа, які повинен містити сертифікат\&. У списку значень, відокремлених комами, можна використовувати такі значення:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
digitalSignature
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
nonRepudiation
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
keyEncipherment
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
dataEncipherment
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
keyAgreement
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
keyCertSign
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
cRLSign
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
encipherOnly
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
decipherOnly
.RE
.sp
Для спеціальних випадків можна також використати числове значення у діапазоні 32\-бітових цілих чисел без знаку\&.
.sp
Приклад: digitalSignature,keyEncipherment
.RE
.PP
розширене\-використання\-ключа
.RS 4
За допомогою цього параметра можна визначити значення розширеного використання ключа, які повинен містити сертифікат\&. У списку значень, відокремлених комами, можна використовувати такі значення:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
serverAuth
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
clientAuth
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
codeSigning
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
emailProtection
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
timeStamping
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
OCSPSigning
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
KPClientAuth
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
pkinit
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
msScLogin
.RE
.sp
Розширені використання ключа, які не потрапили до вказаного вище списку, можна визначити за допомогою їхнього OID у точково\-десятковому позначенні\&.
.sp
Приклад: clientAuth,1\&.3\&.6\&.1\&.5\&.2\&.3\&.4
.RE
.PP
формальний\-вираз
.RS 4
Для сумісності із використанням Kerberos MIT цей параметр встановлюватиме відповідність реєстраційних даних Kerberos у PKINIT або AD NT Principal SAN так, як це робить \&.
.sp
Приклад: \&.*@MY\e\&.REALM
.RE
.PP
формальний\-вираз
.RS 4
Встановити відповідність реєстраційних даних Kerberos у PKINIT або AD NT Principal SAN\&.
.sp
Приклад: \&.*@MY\e\&.REALM
.RE
.PP
формальний\-вираз
.RS 4
Встановити відповідність реєстраційних даних Kerberos з AD NT Principal SAN\&.
.sp
Приклад: \&.*@MY\&.AD\&.REALM
.RE
.PP
формальний\-вираз
.RS 4
Встановити відповідність реєстраційних даних Kerberos з SAN PKINIT\&.
.sp
Приклад: \&.*@MY\e\&.PKINIT\e\&.REALM
.RE
.PP
формальний\-вираз
.RS 4
Отримати значення компонента SAN otherName, яке задано OID у крапково\-десятковому позначенні, обробити його як рядок і спробувати встановити відповідність формальному виразу\&.
.sp
Приклад: test
.RE
.PP
base64\-string
.RS 4
Виконати спробу встановлення двійкової відповідності блоку у кодуванні base64 із усіма компонентами SAN otherName\&. За допомогою цього параметра можна встановлювати відповідність із нетиповими компонентами otherName із особливими кодуваннями, які не можна обробляти як рядки\&.
.sp
Приклад: MTIz
.RE
.PP
формальний\-вираз
.RS 4
Встановити відповідність значення SAN rfc822Name\&.
.sp
Приклад: \&.*@email\e\&.domain
.RE
.PP
формальний\-вираз
.RS 4
Встановити відповідність значення SAN dNSName\&.
.sp
Приклад: \&.*\e\&.my\e\&.dns\e\&.domain
.RE
.PP
рядок\-base64
.RS 4
Встановити двійкову відповідність значення SAN x400Address\&.
.sp
Приклад: MTIz
.RE
.PP
формальний\-вираз
.RS 4
Встановити відповідність значення SAN directoryName\&. Цього параметра стосуються ті самі коментарі, які було вказано для параметрів та \&.
.sp
Приклад: \&.*,DC=com
.RE
.PP
рядок\-base64
.RS 4
Встановити двійкову відповідність значення SAN ediPartyName\&.
.sp
Приклад: MTIz
.RE
.PP
формальний\-вираз
.RS 4
Встановити відповідність значення SAN uniformResourceIdentifier\&.
.sp
Приклад: URN:\&.*
.RE
.PP
формальний\-вираз
.RS 4
Встановити відповідність значення SAN iPAddress\&.
.sp
Приклад: 192\e\&.168\e\&.\&.*
.RE
.PP
формальний\-вираз
.RS 4
Встановити значення SAN registeredID у форматі точково\-десяткового рядка\&.
.sp
Приклад: 1\e\&.2\e\&.3\e\&.\&.*
.RE
.SS "ПРАВИЛО ПРИВʼЯЗУВАННЯ"
.PP
Правило прив\*(Aqязки використовується для пов\*(Aqязування сертифіката із одним або декількома обліковими записами\&. Далі, смарткарткою із сертифікатом та відповідним закритим ключем можна скористатися для розпізнавання за одним з цих облікових записів\&.
.PP
У поточній версії SSSD на базовому рівні підтримує пошук даних користувачів лише у LDAP (винятком є лише засіб надання проксі, який у цьому контексті є недоречним)\&. Через це правило прив\*(Aqязки засновано на синтаксисі фільтрування пошуку LDAP з шаблонами для додавання вмісту сертифікатів до фільтра\&. Очікується, що цей фільтр міститиме лише специфічні дані, потрібні для прив\*(Aqязки, яку функція виклику вбудовуватиме до іншого фільтра для виконання справжнього пошуку\&. Через це рядок фільтрування має починатися із завершуватися \(Fo(\(Fc і \(Fo)\(Fc, відповідно\&.
.PP
Загалом, рекомендується використовувати атрибути з сертифіката і додати їх до спеціальних атрибутів об\*(Aqєкта користувача LDAP\&. Наприклад, можна скористатися атрибутом \(FoaltSecurityIdentities\(Fc у AD або атрибутом \(FoipaCertMapData\(Fc для IPA\&.
.PP
Бажаним шляхом є читання із сертифіката специфічних для користувача даних, наприклад адреси електронної пошти, і пошук цих даних на сервері LDAP\&. Причиною є те, що специфічні для користувача дані у LDAP можу бути з різних причин змінено, що розірве прив\*(Aqязку\&. З іншого боку, якщо скористатися бажаним шляхом, розірвати прив\*(Aqязку буде важко\&.
.PP
Стандартним типом
\(lqправила прив\*(Aqязки\(rq
є \(FoLDAP\(Fc\&. Цей запис може бути додано як префікс до правила\&. Ось так, наприклад: \(FoLDAP:(userCertificate;binary={cert!bin})\(Fc\&. Передбачено розширення, яке має назву \(FoLDAPU1\(Fc, і яке надає додаткові шаблони для збільшення гнучкості\&. Щоб дозволити застарілим версіям цієї бібліотеки ігнорувати розширення, при використанні нових шаблонів у
\(lqправилі прив\*(Aqязки\(rq
має бути використано префікс \(FoLDAPU1\(Fc, інакше роботу застарілої версії цієї бібліотеки буде завершено із повідомленням про помилку при обробці вхідних даних\&. Нові шаблони описано у розділі
the section called \(lqРозширення LDAPU1\(rq\&.
.PP
Шаблони для додавання даних сертифікатів до фільтра пошуку засновано на рядках форматування у стилі Python\&. Воли складаються з ключового слова у фігурних дужках із додатковим підкомпонентом\-специфікатором, відокремленим \(Fo\&.\(Fc, або додатковим параметром перетворення\-форматування, відокремленим \(Fo!\(Fc\&. Дозволені значення:
.PP
{issuer_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}
.RS 4
Цей шаблон додасть повний DN видавця, перетворений на рядок відповідно до RFC 4514\&. Якщо використано упорядковування X\&.500 (найспецифічніший RDN стоїть останнім), буде використано параметр із префіксом \(Fo_x500\(Fc\&.
.sp
У варіантах перетворення, назви яких починаються з \(Foad_\(Fc, використовуватимуться назви атрибутів, які використовуються AD, наприклад \(FoS\(Fc, замість \(FoST\(Fc\&.
.sp
У варіантах перетворення, назви яких починаються з \(Fonss_\(Fc, використовуватимуться назви атрибутів, які використовуються NSS\&.
.sp
Типовим варіантом перетворення є \(Fonss\(Fc, тобто назви атрибутів відповідно до NSS і упорядковування за LDAP/RFC 4514\&.
.sp
Приклад: (ipacertmapdata=X509:{issuer_dn!ad}{subject_dn!ad})
.RE
.PP
{subject_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}
.RS 4
Цей шаблон додасть повний DN призначення, перетворений на рядок відповідно до RFC 4514\&. Якщо використано упорядковування X\&.500 (найспецифічніший RDN стоїть останнім), буде використано параметр із префіксом \(Fo_x500\(Fc\&.
.sp
У варіантах перетворення, назви яких починаються з \(Foad_\(Fc, використовуватимуться назви атрибутів, які використовуються AD, наприклад \(FoS\(Fc, замість \(FoST\(Fc\&.
.sp
У варіантах перетворення, назви яких починаються з \(Fonss_\(Fc, використовуватимуться назви атрибутів, які використовуються NSS\&.
.sp
Типовим варіантом перетворення є \(Fonss\(Fc, тобто назви атрибутів відповідно до NSS і упорядковування за LDAP/RFC 4514\&.
.sp
Приклад: (ipacertmapdata=X509:{issuer_dn!nss_x500}{subject_dn!nss_x500})
.RE
.PP
{cert[!(bin|base64)]}
.RS 4
Цей шаблон додасть увесь сертифікат у кодуванні DER як рядок до фільтра пошуку\&. Залежно від параметра перетворення, двійковий сертифікат або буде преетворено на екрановану послідовність шістнадцяткових чисел у форматі \(Fo\exx\(Fc, або на код base64\&. Типовим варіантом є екранована шістнадцяткова послідовність, її може бути, наприклад, використано з атрибутом LDAP \(FouserCertificate;binary\(Fc\&.
.sp
Приклад: (userCertificate;binary={cert!bin})
.RE
.PP
{subject_principal[\&.short_name]}
.RS 4
Цей шаблон додасть реєстраційні дані Kerberos, які буде взято або з SAN, який використовується pkinit, або з реєстраційних даних AD\&. Компонент \(Foshort_name\(Fc відповідає першій частині реєстраційного запису до символу \(Fo@\(Fc\&.
.sp
Приклад: (|(userPrincipal={subject_principal})(samAccountName={subject_principal\&.short_name}))
.RE
.PP
{subject_pkinit_principal[\&.short_name]}
.RS 4
Цей шаблон додасть реєстраційні дані Kerberos, які буде передано SAN, що використовується pkinit\&. Компонент \(Foshort_name\(Fc відповідає першій частині реєстраційного запису до символу \(Fo@\(Fc\&.
.sp
Приклад: (|(userPrincipal={subject_pkinit_principal})(uid={subject_pkinit_principal\&.short_name}))
.RE
.PP
{subject_nt_principal[\&.short_name]}
.RS 4
Цей шаблон додасть реєстраційні дані Kerberos, які буде передано SAN, що використовується AD\&. Компонент \(Foshort_name\(Fc відповідає першій частині реєстраційного запису до символу \(Fo@\(Fc\&.
.sp
Приклад: (|(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal\&.short_name}))
.RE
.PP
{subject_rfc822_name[\&.short_name]}
.RS 4
Цей шаблон додасть рядок, який зберігається у компоненті rfc822Name SAN, типово, адресу електронної пошти\&. Компонент \(Foshort_name\(Fc відповідає першій частині адреси до символу \(Fo@\(Fc\&.
.sp
Приклад: (|(mail={subject_rfc822_name})(uid={subject_rfc822_name\&.short_name}))
.RE
.PP
{subject_dns_name[\&.short_name]}
.RS 4
Цей шаблон додасть рядок, який зберігається у компоненті dNSName SAN, типово, повну назву вузла\&. Компонент \(Foshort_name\(Fc відповідає першій частині назви до першого символу \(Fo\&.\(Fc\&.
.sp
Приклад: (|(fqdn={subject_dns_name})(host={subject_dns_name\&.short_name}))
.RE
.PP
{subject_uri}
.RS 4
Цей шаблон додає рядок, який зберігається у компоненті uniformResourceIdentifier SAN\&.
.sp
Приклад: (uri={subject_uri})
.RE
.PP
{subject_ip_address}
.RS 4
Цей шаблон додає рядок, який зберігається у компоненті iPAddress SAN\&.
.sp
Приклад: (ip={subject_ip_address})
.RE
.PP
{subject_x400_address}
.RS 4
Цей шаблон додає значення, яке зберігається у компоненті x400Address SAN як послідовність екранованих шістнадцяткових чисел\&.
.sp
Приклад: (attr:binary={subject_x400_address})
.RE
.PP
{subject_directory_name[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}
.RS 4
Цей шаблон додасть рядок DN значення, яке зберігається у компоненті directoryName SAN\&.
.sp
Приклад: (orig_dn={subject_directory_name})
.RE
.PP
{subject_ediparty_name}
.RS 4
Цей шаблон додає значення, яке зберігається у компоненті ediPartyName SAN як послідовність екранованих шістнадцяткових чисел\&.
.sp
Приклад: (attr:binary={subject_ediparty_name})
.RE
.PP
{subject_registered_id}
.RS 4
Цей шаблон додає OID, який зберігається у компоненті registeredID SAN у форматі точково\-десяткового рядка\&.
.sp
Приклад: (oid={subject_registered_id})
.RE
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBРозширення LDAPU1\fR
.RS 4
.PP
При використанні розширення LDAPU1 можна скористатися такими шаблонами:
.PP
.PP
{serial_number[!(dec|hex[_ucr])]}
.RS 4
Цей шаблон додасть серійний номер сертифіката\&. Типово, його буде надруковано як шістнадцяткове число літерами нижнього регістру\&.
.sp
Якщо використано параметр форматування \(Fo!dec\(Fc, число буде виведено як десятковий рядок\&. Виведені шістнадцяткові дані може бути показано за допомогою літер верхнього регістру (\(Fo!hex_u\(Fc), із двокрапкою, що відокремлює шістнадцяткові байти (\(Fo!hex_c\(Fc), або із шістнадцятковими байтами у зворотному порядку (\(Fo!hex_r\(Fc)\&. Літер постфікса може бути поєднано, отже, наприклад, \(Fo!hex_uc\(Fc призведе до виведення відокремленого двокрапками шістнадцяткового рядка із літер верхнього регістру\&.
.sp
Приклад: LDAPU1:(serial={серійний_номер})
.RE
.PP
{subject_key_id[!hex[_ucr]]}
.RS 4
Цей шаблон додасть ідентифікатор ключа призначення сертифіката\&. Типово, його буде надруковано як шістнадцяткове число літерами нижнього регістру\&.
.sp
Виведені шістнадцяткові дані може бути показано за допомогою літер верхнього регістру (\(Fo!hex_u\(Fc), із двокрапкою, що відокремлює шістнадцяткові байти (\(Fo!hex_c\(Fc), або із шістнадцятковими байтами у зворотному порядку (\(Fo!hex_r\(Fc)\&. Літер постфікса може бути поєднано, отже, наприклад, \(Fo!hex_uc\(Fc призведе до виведення відокремленого двокрапками шістнадцяткового рядка із літер верхнього регістру\&.
.sp
Приклад: LDAPU1:(ski={ідентифікатор_ключа_призначення})
.RE
.PP
{cert[!DIGEST[_ucr]]}
.RS 4
Цей шаблон додає шістнадцяткову контрольну суму або хеш до сертифіката\&. Запис DIGEST має бути замінено назвою функції контрольної суми або хешу, підтримку яких передбачено у OpenSSL, наприклад \(Fosha512\(Fc\&.
.sp
Виведені шістнадцяткові дані може бути показано за допомогою літер верхнього регістру (\(Fo!sha512_u\(Fc), із двокрапкою, що відокремлює шістнадцяткові байти (\(Fo!sha512_c\(Fc), або із шістнадцятковими байтами у зворотному порядку (\(Fo!sha512_r\(Fc) Літер постфікса може бути поєднано, отже, наприклад, \(Fo!sha512_uc\(Fc призведе до виведення відокремленого двокрапками шістнадцяткового рядка із літер верхнього регістру\&.
.sp
Приклад: LDAPU1:(dgst={cert!sha256})
.RE
.PP
{subject_dn_component[(\&.назва_атрибуту|[число]]}
.RS 4
Цей шаблон додасть значення атрибуту компонента DN призначення\&. Типовим значенням є найспецифічніший компонент\&.
.sp
Можна вибрати інший компонент або за назвою атрибуту, наприклад, {subject_dn_component\&.uid}, або за позицією, наприклад, {subject_dn_component\&.[2]}, де додатні числа означають відлік від найбільш специфічного компонента, а від\*(Aqємні числа \(em відлік від найменш специфічного компонента\&. Назву атрибуту та позицію можна поєднувати\&. Приклад: {subject_dn_component\&.uid[2]}, тобто назвою другого компонента має бути \(Fouid\(Fc\&.
.sp
Приклад: LDAPU1:(uid={subject_dn_component\&.uid})
.RE
.PP
{issuer_dn_component[(\&.назва_атрибуту|[число]]}
.RS 4
Цей шаблон додасть значення атрибуту компонента DN видавця\&. Типовим значенням є найспецифічніший компонент\&.
.sp
Див\&. \(Fosubject_dn_component\(Fc, щоб дізнатися більше про назви атрибутів та специфікатори позиції\&.
.sp
Приклад: LDAPU1:(domain={issuer_dn_component\&.[\-2]}\&.{issuer_dn_component\&.dc[\-1]})
.RE
.PP
{sid[\&.rid]}
.RS 4
Цей шаблон додасть SID, якщо відповідне розширення впроваджено Microsoft із доступним OID 1\&.3\&.6\&.1\&.4\&.1\&.311\&.25\&.2\&. Якщо вказано \(Fo\&.rid\(Fc, буде додано лише останній компонент, тобто RID\&.
.sp
Приклад: LDAPU1:(objectsid={sid})
.RE
.RE
.SS "СПИСОК ДОМЕНІВ"
.PP
Якщо список доменів не є порожнім, записи користувачів, прив\*(Aqязані до заданого сертифіката, шукаються не лише у локальному домені, а і у доменах зі списку, якщо вони відомі SSSD\&. Домени, які не відомі SSSD, буде проігноровано\&.
.SH "AUTHORS"
.PP
\fBОсновна гілка розробки SSSD \(em
https://pagure\&.io/SSSD/sssd/\fR