From 74aa0bc6779af38018a03fd2cf4419fe85917904 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Fri, 19 Apr 2024 07:31:45 +0200 Subject: Adding upstream version 2.9.4. Signed-off-by: Daniel Baumann --- src/man/ru/sss-certmap.5.xml | 771 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 771 insertions(+) create mode 100644 src/man/ru/sss-certmap.5.xml (limited to 'src/man/ru/sss-certmap.5.xml') diff --git a/src/man/ru/sss-certmap.5.xml b/src/man/ru/sss-certmap.5.xml new file mode 100644 index 0000000..93e68a4 --- /dev/null +++ b/src/man/ru/sss-certmap.5.xml @@ -0,0 +1,771 @@ + + + +Справка по SSSD + + + + + 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 MIT Kerberos. Правило состоит из ключевого +слова, расположенного между «<» и «>», которое идентифицирует +определённую часть сертификата, и шаблона, который должен быть найден для +установления соответствия правила. Несколько пар «ключевое слово — шаблон» +можно соединить с помощью логического оператора «&&» (и) или +«||» (или). + + + Учитывая сходство с 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>регулярное_выражение + + + Для обеспечения совместимости с использованием MIT Kerberos этот параметр +будет устанавливать соответствие участников Kerberos в SAN PKINIT или SAN AD +NT Principal так, как это делает <SAN:Principal>. + + + Пример: <SAN>.*@MY\.REALM + + + + + <SAN:Principal>регулярное_выражение + + + Установить соответствие участников Kerberos в SAN PKINIT или SAN AD NT +Principal. + + + Пример: <SAN:Principal>.*@MY\.REALM + + + + + <SAN:ntPrincipalName>регулярное_выражение + + + Установить соответствие участников Kerberos в SAN AD NT Principal. + + + Пример: <SAN:ntPrincipalName>.*@MY.AD.REALM + + + + + <SAN:pkinit>регулярное_выражение + + + Установить соответствие участников Kerberos в SAN PKINIT. + + + Пример: <SAN:ntPrincipalName>.*@MY\.PKINIT\.REALM + + + + + <SAN:dotted-decimal-oid>регулярное_выражение + + + Взять значение компонента otherName SAN, указанное с помощью OID в +десятичном формате, интерпретировать его как строку и попытаться установить +его соответствие регулярному выражению. + + + Пример: <SAN:1.2.3.4>test + + + + + <SAN:otherName>строка_base64 + + + Выполнить установление двоичного соответствия blob-объекта в кодировке +base64 всем компонентам otherName SAN. С помощью этого параметра возможно +устанавливать соответствие пользовательским компонентам 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», иначе работа устаревшей версии этой +библиотеки будет завершена с сообщением об ошибке при обработке входных +данных. Новые шаблоны описаны в разделе . + + + Шаблоны для добавления данных сертификата в фильтр поиска основаны на +строках форматирования в стиле 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, либо из SAN, используемого 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={subject_key_id}) + + + + + + {cert[!DIGEST[_ucr]]} + + + Этот шаблон добавит шестнадцатеричную контрольную сумму или хэш к +сертификату. Запись DIGEST должна быть заменена названием функции +контрольной суммы или хэша, поддержка которых предусмотрена в OpenSSL, +например. «sha512». + + + Шестнадцатеричный вывод может быть показан буквами в верхнем регистре +(«!sha512_u»), с двоеточием, разделяющим шестнадцатеричные байты +(«!sha512_c»), или с шестнадцатеричными байтами в обратном порядке +(«!sha512_r»). Буквы постфикса можно комбинировать, например, «!sha512_uc» +приведет к выводу шестнадцатеричной строки, разделенной двоеточием, с +буквами в верхнем регистре. + + + Пример: LDAPU1:(dgst={cert!sha256}) + + + + + + {subject_dn_component[(.attr_name|[number]]} + + + Этот шаблон добавит значение атрибуту компонента DN субъекта, по умолчанию +значением является самый специфический компонент. + + + Другой компонент может быть выбран по имени атрибута, например, +{subject_dn_component.uid} или по позиции, например, +{subject_dn_component.[2]}, где положительные числа означают отсчет от +наиболее специфичного компонента, а отрицательные числа — от наименее +специфичного компонента. Название атрибута и позиция могут быть объединены, +например, {subject_dn_component.uid[2]} означает, что имя второго компонента +должно быть «uid». + + + Пример: LDAPU1:(uid={subject_dn_component.uid}) + + + + + + {issuer_dn_component[(.attr_name|[number]]} + + + Этот шаблон добавит значение атрибуту компонента 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, будут игнорироваться. + + + + + -- cgit v1.2.3