SSS-CERTMAP(5) Formatos de Ficheiros e Conven SSS-CERTMAP(5)

sss-certmap - Correspondência de Certificados e Regras de Mapeamento do SSSD

Este manual descreve as regras que podem ser usadas pelo SSSD e outros componentes para corresponder a certificados X.509 e os mapear em contas.

Cada regra tem quatro componentes, um “priority”, um “matching rule”, um “mapping rule” e um “domain list”. Todos os componentes são opcionais. Um “priority” em falta irá adicionar a regra com a prioridade mais baixa. A “matching rule” predefinida irá corresponder a certificados com a utilização de chave digitalSignature e utilização de chave estendida clientAuth, Se a “mapping rule” estiver vazia os certificados serão procurados no atributo userCertificate como binário codificado em DER. Se nenhum domínio for dado apenas será procurado o domínio local.

Para permitir extensões ou estilo completamente diferente de regra o “mapping” e “matching rules” podem conter um prefixo separado por um ':' da principal parte de regra. O prefixo só pode conter letras maiúsculas ASCII e números. Se o prefixo for omitido será usado o tipo predefinido que é 'KRB5' para as regras de correspondência e "LDAP' para as regras de mapeamento.

O utilitário 'sssctl' fornece o comando 'cert-eval-rule' para verificar se um dado certificado corresponde a uma regra de correspondência e como o resultado de uma regra de mapeamento se iria parecer.

As regras são processadas pela prioridade e o número '0' (zero) indica a prioridade mais alta. Quanto mais alto o número mais baixa a prioridade. Um valor em falta indica a prioridade mais baixa. O processamento de regras é parado quando é encontrada uma regra correspondente e não são verificadas mais regras.

Internamente a prioridade é tratada como um inteiro de 32bit não assinado, usar um valor de prioridade maior que 4294967295 irá causar um erro.

Se várias regras tiverem a mesma prioridade e apenas uma das regras correspondentes relacionadas se aplica, essa regra será escolhida. Se existirem com a mesma prioridade que correspondem, é escolhida uma mas qual delas é não está definido. Para evitar este comportamento indefinido ou se usa diferentes prioridades ou torne as regras de correspondência mas específicas ex. ao usar padrões <ISSUER> distintos.

A regra correspondente é usada para selecionar o certificado ao qual a regra de mapeamento deve ser aplicada. Usa um sistema semelhante aquele usado pela opção “pkinit_cert_match” do MIT Kerberos. Consiste de uma palavra chave envolta por '<' e '>' o que identifica uma certa parte do certificado e um padrão que deve ser encontrado para que a regra corresponda. Múltiplos pares de padrões de palavra chave pode ser ou juntados com '&&' (e) ou '||' (ou).

Dada a semelhança com o MIT Kerberos o prefixo de tipo para esta regra é 'KRB5'. Mas 'KRB5' irá ser também a predefinição para “matching rules” para que "<SUBJECT>.*,DC=MY,DC=DOMAIN" e "KRB5:<SUBJECT>.*,DC=MY,DC=DOMAIN" sejam equivalentes.

As opções disponíveis são:

<SUBJECT>expressão-regular

Com isto uma parte ou o nome completo de sujeito do certificado pode ser correspondido. Para correspondência é usada sintaxe Extended Regular Expression do POSIX, veja regex(7) para detalhes.

Para corresponder o nome do sujeito guardado no certificado em ASN.1 codificado em DER é convertido numa string de acordo com RFC 4514. Isto significa que o componente nome mais especifico vem primeiro. Por favor note que nem todos os nomes de atributo possíveis são cobertos por by RFC 4514. Os nomes incluídos são 'CN', 'L', 'ST', 'O', 'OU', 'C', 'STREET', 'DC' e 'UID'. Outros nomes de atributos podem ser mostrados de maneira diferente em plataformas diferentes ou por diferentes ferramentas. Para evitar confusões é melhor não usar esses nomes de atributos ou cobri-los por uma expressão regular apropriada.

Exemplo: <SUBJECT>.*,DC=MY,DC=DOMAIN

Por favor note que os caracteres "^.[$()|*+?{\\" têm um significado especial em expressões regulares e têm de ser escapados com a ajuda do caractere '\' para que correspondam como caracteres normais.

Exemplo: <SUBJECT>^CN=.* \(Admin\),DC=MY,DC=DOMAIN$

<ISSUER>expressão-regular

Com isto uma parte do nome completo do emissor do certificado pode ser correspondida. Todos os comentários para <SUBJECT> também se aplicam aqui.

Exemplo: <ISSUER>^CN=My-CA,DC=MY,DC=DOMAIN$

<KU>key-usage

Esta opção pode ser usada para especificar quais valores de utilização de chave o certificado deve ter. Os seguintes valores podem ser usados numa lista separados por vírgulas:
•digitalSignature
•nonRepudiation
•keyEncipherment
•dataEncipherment
•keyAgreement
•keyCertSign
•cRLSign
•encipherOnly
•decipherOnly

Um valor numérico no alcance de inteiro de 32bit não assinado pode ser usado também para cobrir casos de utilização especiais.

Exemplo: <KU>digitalSignature,keyEncipherment

<EKU>extended-key-usage

Esta opção pode ser usada para especificar qual utilização de chave estendida o certificado deve ter. Os seguintes valores podem ser usados numa lista separados por vírgulas:
•serverAuth
•clientAuth
•codeSigning
•emailProtection
•timeStamping
•OCSPSigning
•KPClientAuth
•pkinit
•msScLogin

Utilizações de chave estendida que não estejam listadas em cima podem ser especificadas com o seu OID em notação de pontuação-decimal.

Exemplo: <EKU>clientAuth,1.3.6.1.5.2.3.4

<SAN>expressão-regular

Para ser compatível com a utilização de MIT Kerberos esta opção irá corresponder aos principais de Kerberos no SAN Principal PKINIT ou AD NT como faz o <SAN:Principal>.

Exemplo: <SAN>.*@MY\.REALM

<SAN:Principal>expressão-regular

Corresponde aos principais de Kerberos no SAN Principal PKINIT ou AD NT.

Exemplo: <SAN:Principal>.*@MY\.REALM

<SAN:ntPrincipalName>expressão-regular

Corresponde aos principais de Kerberos no SAN Principal AD NT.

Exemplo: <SAN:ntPrincipalName>.*@MY.AD.REALM

<SAN:pkinit>expressão-regular

Corresponde aos principais de Kerberos no SAN PKINIT.

Exemplo: <SAN:ntPrincipalName>.*@MY\.PKINIT\.REALM

<SAN:dotted-decimal-oid>expressão-regular

Toma o valor do componente SAN otherName dado pelo OID em notação de pontuação-decimal, interpreta-o como uma string e tenta corresponde-lo com a expressão regular.

Exemplo: <SAN:1.2.3.4>test

<SAN:otherName>base64-string

Faz uma correspondência binária com o borrão codificado em base64 contra todos os componentes SAN otherName. Com esta opção é possível corresponder contra componentes otherName personalizados com codificações especiais que não podem ser tratados como strings.

Exemplo: <SAN:otherName>MTIz

<SAN:rfc822Name>expressão-regular

Corresponde ao valor de rfc822Name SAN.

Exemplo: <SAN:rfc822Name>.*@email\\.domain

<SAN:dNSName>expressão-regular

Corresponde ao valor de dNSName SAN.

Exemplo: <SAN:dNSName>.*\\.my\\.dns\\.domain

<SAN:x400Address>base64-string

Corresponde em binário ao valor de x400Address SAN.

Exemplo: <SAN:x400Address>MTIz

<SAN:directoryName>expressão-regular

Corresponde o valor do SAN directoryName. OS mesmos comentários que são dados para <ISSUER> e <SUBJECT> aplicam-se aqui também.

Exemplo: <SAN:directoryName>.*,DC=com

<SAN:ediPartyName>base64-string

Corresponde em binário ao valor de ediPartyName SAN.

Exemplo: <SAN:ediPartyName>MTIz

<SAN:uniformResourceIdentifier>expressão-regular

Corresponde ao valor de uniformResourceIdentifier SAN.

Exemplo: <SAN:uniformResourceIdentifier>URN:.*

<SAN:iPAddress>expressão-regular

Corresponde ao valor de iPAddress SAN.

Exemplo: <SAN:iPAddress>192\\.168\\..*

<SAN:registeredID>expressão-regular

Corresponde o valor de SAN registeredID como string de pontuação-decimal.

Exemplo: <SAN:registeredID>1\\.2\\.3\\..*

A regra de mapeamento é usada para associar um certificado com uma ou mais contas. Uma Smartcard com o certificado e a chave privada correspondente podem então ser usadas para autenticar como uma dessas contas.

Actualmente o SSSD basicamente apenas suporta o LDAP para procurar informação do utilizador (a excepção é o provedor proxy o qual não é relevante aqui). Devido a isto, a regra de mapeamento é baseada na sintaxe do filtro de busca do LDAP com modelos para adicionar o conteúdo de certificados ao filtro. É esperado que o filtro apenas contenha os dados específicos necessários para o mapeamento e que o chamador irá embebe-lo noutro filtro para fazer a própria procura. Devido a isto, a string do filtro deve começar e terminar com '(' e ')' respetivamente.

Em geral é recomendado usar atributos a partir do certificado e adiciona-los a atributos especiais ao objecto utilizador do LDAP. Ex. pode ser usado o atributo 'altSecurityIdentities' em AD ou o atributo 'ipaCertMapData' para IPA.

Isto deve ser preferido a ler dados específicos do utilizador a partir do certificado tal como, ex. um endereço de email e procurar por ele no servidor LDAP. A razão é que os dados específicos do utilizador podem mudar por várias razões e iria quebrar o mapeamento. Do outro modo, seria difícil quebrar o mapeamento de propósito a um utilizador específico.

O tipo predefinido de “mapping rule” é 'LDAP' que pode ser adicionado como prefixo a uma regra como ex. 'LDAP:(userCertificate;binary={cert!bin})'. Existe uma extensão chamada 'LDAPU1' que oferece mais modelos para mais flexibilidade. Para permitir a versões mais antigas desta biblioteca ignorar a extensão, o prefixo 'LDAPU1' tem de ser usado quando se usa os novos modelos numa “mapping rule” caso contrário a versão antiga desta biblioteca irá falhar com um erro de análise. Os novos modelos estão descritos na secção the section called “Extensão LDAPU1”.

Os modelos para adicionar dados de certificados aos filtros de busca são baseados em strings de formatação de estilo-Python. Consistem duma palavra chave entre chavetas com um especificador de sub-componente opcional separado por um '.' ou uma opção de conversão/formatação opcional separada por um '!'. Os valores permitidos são:

{issuer_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}

Este modelo irá adicionar o emissor total DN convertido numa string conforme RFC 4514. Se encomendar X.500 (RDN mais específico chega em último) deve ser usado uma opção com o prefixo '_x500'.

As opções de conversão que começam com 'ad_' irão usar nomes de atributo como usado pelo AD, ex. 'S' em vez de 'ST'.

As opções de conversão que começam com 'nss_' irão usar nomes de atributo como usado pelo NSS.

A opção de conversão predefinida é 'nss', isto é, nomes de atributos de acordo para pedidos NSS e LDAP/RFC 4514.

Exemplo: (ipacertmapdata=X509:<I>{issuer_dn!ad}<S>{subject_dn!ad})

{subject_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}

Este modelo irá adicionar o sujeito total DN convertido numa string conforme RFC 4514. Se encomendar X.500 (RDN mais específico chega em último) deve ser usado uma opção com o prefixo '_x500'.

As opções de conversão que começam com 'ad_' irão usar nomes de atributo como usado pelo AD, ex. 'S' em vez de 'ST'.

As opções de conversão que começam com 'nss_' irão usar nomes de atributo como usado pelo NSS.

A opção de conversão predefinida é 'nss', isto é, nomes de atributos de acordo para pedidos NSS e LDAP/RFC 4514.

Exemplo: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})

{cert[!(bin|base64)]}

Este modelo irá adicionar o certificado completo codificado em DER como uma string ao filtro de busca. Dependendo da opção de conversão o certificado binário é ou convertido para uma sequência hexadecimal escapada \\xx' ou base64. A sequência hexadecimal escapada é a predefinição e pode, por exemplo, ser usada com o atributo do LDAP 'userCertificate;binary'.

Exemplo: (userCertificate;binary={cert!bin})

{subject_principal[.short_name]}

Este modelo irá adicionar o principal Kerberos o qual é tomado ou a partir do SAN usado pelo pkinit ou daquele usado pelo AD. O componente 'short_name' representa a primeira parte do principal antes do sinal '@'.

Exemplo: (|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name}))

{subject_pkinit_principal[.short_name]}

Este modelo irá adicionar o principal Kerberos o qual é dado pelo SAN usado pelo pkinit. O componente 'short_name' representa a primeira parte do principal antes do sinal '@'.

Exemplo: (|(userPrincipal={subject_pkinit_principal})(uid={subject_pkinit_principal.short_name}))

{subject_nt_principal[.short_name]}

Este modelo irá adicionar o principal Kerberos o qual é dado pelo SAN usado pelo AD. O componente 'short_name' representa a primeira parte do principal antes do sinal '@'.

Exemplo: (|(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.short_name}))

{subject_rfc822_name[.short_name]}

Este modelo irá adicionar a string que está guardada no componente rfc822Name do SAN, tipicamente um endereço de email. O componente 'short_name' representa a primeira parte do endereço antes do sinal '@'.

Exemplo: (|(mail={subject_rfc822_name})(uid={subject_rfc822_name.short_name}))

{subject_dns_name[.short_name]}

Este modelo irá adicionar a string que está guardada no componente dNSName do SAN, tipicamente um nome de máquina totalmente qualificado. O componente 'short_name' representa a primeira parte do nome antes do primeiro sinal '.'.

Exemplo: (|(fqdn={subject_dns_name})(host={subject_dns_name.short_name}))

{subject_uri}

Este modelo irá adicionar a string que está guardada no componente uniformResourceIdentifier do SAN.

Exemplo: (uri={subject_uri})

{subject_ip_address}

Este modelo irá adicionar a string que está guardada no componente iPAddress do SAN.

Exemplo: (ip={subject_ip_address})

{subject_x400_address}

Este modelo irá adicionar o valor que está guardado no componente x400Address do SAN como sequência hexadecimal escapada.

Exemplo: (attr:binary={subject_x400_address})

{subject_directory_name[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}

Este modelo irá adicionar a string DN do valor que está guardado no componente directoryName do SAN.

Exemplo: (orig_dn={subject_directory_name})

{subject_ediparty_name}

Este modelo irá adicionar o valor que está guardado no componente ediPartyName do SAN como sequência hexadecimal escapada.

Exemplo: (attr:binary={subject_ediparty_name})

{subject_registered_id}

Este modelo irá adicionar o OID que está guardado no componente registeredID do SAN como uma string decimal-pontuada.

Exemplo: (oid={subject_registered_id})

Extensão LDAPU1

The following templates are available when using the 'LDAPU1' extension:

{serial_number[!(dec|hex[_ucr])]}

Este modelo irá adicionar o número de série do certificado. Por predefinição será escrito como um número hexadecimal com letras minúsculas.

Com a opção de formatação '!dec' o número será escrito em string decimal. O resultado hexadecimal pode ser escrito com letras maiúsculas ('!hex_u'), com dois-pontos a separar os bytes hexadecimais ('!hex_c') ou com os bytes hexadecimais em ordem reversa ('!hex_r'). As letras posteriores podem ser combinadas para que ex. '!hex_uc' produza uma string hexadecimal separada por dois-pontos com letras maiúsculas.

Exemplo: LDAPU1:(serial={serial_number})

{subject_key_id[!hex[_ucr]]}

Este modelo irá adicionar o id de chave de objeto do certificado. Por predefinição será escrito como um número hexadecimal com letras minúsculas.

O resultado em hexadecimal pode ser escrito com letras maiúsculas ('!hex_u'), com dois-pontos a separar os bytes hexadecimais ('!hex_c') ou com os bytes hexadecimais em ordem reversa ('!hex_r'). As letras posteriores podem ser combinadas para que ex. '!hex_uc' produza uma string hexadecimal com dois-pontos a separar e letras maiúsculas.

Exemplo: LDAPU1:(ski={subject_key_id})

{cert[!DIGEST[_ucr]]}

Este modelo irá adicionar a digestão/cinza hexadecimal do certificado onde DIGEST tem de ser substituído pelo nome da função digest/hash suportada pelo OpenSSL, ex. 'sha512'.

O resultado em hexadecimal pode ser escrito com letras maiúsculas ('!sha512_u'), com dois-pontos a separar os bytes hexadecimais ('!sha512_c') ou com os bytes hexadecimais em ordem reversa ('!sha512_r'). As letras posteriores podem ser combinadas para que ex. '!sha512_uc' produza uma string hexadecimal com dois-pontos a separar e letras maiúsculas.

Exemplo: LDAPU1:(dgst={cert!sha256})

{subject_dn_component[(.attr_name|[number]]}

Este modelo irá adicionar um valor de atributo de um componente do objeto DN, por predefinição o valor do componente mais específico.

A different component can be selected by either attribute name, e.g. {subject_dn_component.uid} or by position, e.g. {subject_dn_component.[2]} where positive numbers start counting from the most specific component and negative numbers start counting from the least specific component. Attribute name and the position can be combined as e.g. {subject_dn_component.uid[2]} which means that the name of the second component must be 'uid'.

Exemplo: LDAPU1:(uid={subject_dn_component.uid})

{issuer_dn_component[(.attr_name|[number]]}

Este modelo irá adicionar um valor de atributo de um componente do publicador DN, por predefinição o valor é o componente mais específico.

Veja 'subject_dn_component' para detalhes acerca de nome de atributo e especificadores de posição.

Exemplo: LDAPU1:(domain={issuer_dn_component.[-2]}.{issuer_dn_component.dc[-1]})

{sid[.rid]}

Este modelo irá adicionar o SID se a extensão correspondente introduzida pela Microsoft com o OID 1.3.6.1.4.1.311.25.2 estiver disponível. Com o seletor '.rid' apenas o último componente, isto é, o RID, será adicionado.

Exemplo: LDAPU1:(objectsid={sid})

Se a lista de domínios não estiver vazia, os utilizadores mapeados a um dado certificado não são apenas procurados no domínio local mas também nos domínios listados desde que sejam conhecidos pelo SSSD. Os domínios não conhecidos do SSSD serão ignorados.

O autor do SSSD - https://github.com/SSSD/sssd/

01/18/2026 SSSD