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» доступны следующие шаблоны: {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, будут игнорироваться.