'\" 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