SSS-CERTMAP(5) Formatos de Ficheiros e Conven SSS-CERTMAP(5) NAME sss-certmap - Correspondencia de Certificados e Regras de Mapeamento do SSSD DESCRICAO 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 sao opcionais. Um "priority" em falta ira adicionar a regra com a prioridade mais baixa. A "matching rule" predefinida ira corresponder a certificados com a utilizacao de chave digitalSignature e utilizacao de chave estendida clientAuth, Se a "mapping rule" estiver vazia os certificados serao procurados no atributo userCertificate como binario codificado em DER. Se nenhum dominio for dado apenas sera procurado o dominio local. Para permitir extensoes 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 so pode conter letras maiusculas ASCII e numeros. Se o prefixo for omitido sera usado o tipo predefinido que e 'KRB5' para as regras de correspondencia e "LDAP' para as regras de mapeamento. O utilitario 'sssctl' fornece o comando 'cert-eval-rule' para verificar se um dado certificado corresponde a uma regra de correspondencia e como o resultado de uma regra de mapeamento se iria parecer. COMPONENTES DE REGRA PRIORIDADE As regras sao processadas pela prioridade e o numero '0' (zero) indica a prioridade mais alta. Quanto mais alto o numero mais baixa a prioridade. Um valor em falta indica a prioridade mais baixa. O processamento de regras e parado quando e encontrada uma regra correspondente e nao sao verificadas mais regras. Internamente a prioridade e tratada como um inteiro de 32bit nao assinado, usar um valor de prioridade maior que 4294967295 ira causar um erro. Se varias regras tiverem a mesma prioridade e apenas uma das regras correspondentes relacionadas se aplica, essa regra sera escolhida. Se existirem com a mesma prioridade que correspondem, e escolhida uma mas qual delas e nao esta definido. Para evitar este comportamento indefinido ou se usa diferentes prioridades ou torne as regras de correspondencia mas especificas ex. ao usar padroes distintos. REGRA DE CORRESPONDENCIA A regra correspondente e usada para selecionar o certificado ao qual a regra de mapeamento deve ser aplicada. Usa um sistema semelhante aquele usado pela opcao "pkinit_cert_match" do MIT Kerberos. Consiste de uma palavra chave envolta por '<' e '>' o que identifica uma certa parte do certificado e um padrao que deve ser encontrado para que a regra corresponda. Multiplos pares de padroes de palavra chave pode ser ou juntados com '&&' (e) ou '||' (ou). Dada a semelhanca com o MIT Kerberos o prefixo de tipo para esta regra e 'KRB5'. Mas 'KRB5' ira ser tambem a predefinicao para "matching rules" para que ".*,DC=MY,DC=DOMAIN" e "KRB5:.*,DC=MY,DC=DOMAIN" sejam equivalentes. As opcoes disponiveis sao: expressao-regular Com isto uma parte ou o nome completo de sujeito do certificado pode ser correspondido. Para correspondencia e 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 e 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 possiveis sao cobertos por by RFC 4514. Os nomes incluidos sao '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 confusoes e melhor nao usar esses nomes de atributos ou cobri-los por uma expressao regular apropriada. Exemplo: .*,DC=MY,DC=DOMAIN Por favor note que os caracteres "^.[$()|*+?{\\" tem um significado especial em expressoes regulares e tem de ser escapados com a ajuda do caractere '\' para que correspondam como caracteres normais. Exemplo: ^CN=.* \(Admin\),DC=MY,DC=DOMAIN$ expressao-regular Com isto uma parte do nome completo do emissor do certificado pode ser correspondida. Todos os comentarios para tambem se aplicam aqui. Exemplo: ^CN=My-CA,DC=MY,DC=DOMAIN$ key-usage Esta opcao pode ser usada para especificar quais valores de utilizacao de chave o certificado deve ter. Os seguintes valores podem ser usados numa lista separados por virgulas: o digitalSignature o nonRepudiation o keyEncipherment o dataEncipherment o keyAgreement o keyCertSign o cRLSign o encipherOnly o decipherOnly Um valor numerico no alcance de inteiro de 32bit nao assinado pode ser usado tambem para cobrir casos de utilizacao especiais. Exemplo: digitalSignature,keyEncipherment extended-key-usage Esta opcao pode ser usada para especificar qual utilizacao de chave estendida o certificado deve ter. Os seguintes valores podem ser usados numa lista separados por virgulas: o serverAuth o clientAuth o codeSigning o emailProtection o timeStamping o OCSPSigning o KPClientAuth o pkinit o msScLogin Utilizacoes de chave estendida que nao estejam listadas em cima podem ser especificadas com o seu OID em notacao de pontuacao-decimal. Exemplo: clientAuth,1.3.6.1.5.2.3.4 expressao-regular Para ser compativel com a utilizacao de MIT Kerberos esta opcao ira corresponder aos principais de Kerberos no SAN Principal PKINIT ou AD NT como faz o . Exemplo: .*@MY\.REALM expressao-regular Corresponde aos principais de Kerberos no SAN Principal PKINIT ou AD NT. Exemplo: .*@MY\.REALM expressao-regular Corresponde aos principais de Kerberos no SAN Principal AD NT. Exemplo: .*@MY.AD.REALM expressao-regular Corresponde aos principais de Kerberos no SAN PKINIT. Exemplo: .*@MY\.PKINIT\.REALM expressao-regular Toma o valor do componente SAN otherName dado pelo OID em notacao de pontuacao-decimal, interpreta-o como uma string e tenta corresponde-lo com a expressao regular. Exemplo: test base64-string Faz uma correspondencia binaria com o borrao codificado em base64 contra todos os componentes SAN otherName. Com esta opcao e possivel corresponder contra componentes otherName personalizados com codificacoes especiais que nao podem ser tratados como strings. Exemplo: MTIz expressao-regular Corresponde ao valor de rfc822Name SAN. Exemplo: .*@email\\.domain expressao-regular Corresponde ao valor de dNSName SAN. Exemplo: .*\\.my\\.dns\\.domain base64-string Corresponde em binario ao valor de x400Address SAN. Exemplo: MTIz expressao-regular Corresponde o valor do SAN directoryName. OS mesmos comentarios que sao dados para e aplicam-se aqui tambem. Exemplo: .*,DC=com base64-string Corresponde em binario ao valor de ediPartyName SAN. Exemplo: MTIz expressao-regular Corresponde ao valor de uniformResourceIdentifier SAN. Exemplo: URN:.* expressao-regular Corresponde ao valor de iPAddress SAN. Exemplo: 192\\.168\\..* expressao-regular Corresponde o valor de SAN registeredID como string de pontuacao-decimal. Exemplo: 1\\.2\\.3\\..* REGRA DE MAPEAMENTO A regra de mapeamento e usada para associar um certificado com uma ou mais contas. Uma Smartcard com o certificado e a chave privada correspondente podem entao ser usadas para autenticar como uma dessas contas. Actualmente o SSSD basicamente apenas suporta o LDAP para procurar informacao do utilizador (a excepcao e o provedor proxy o qual nao e relevante aqui). Devido a isto, a regra de mapeamento e baseada na sintaxe do filtro de busca do LDAP com modelos para adicionar o conteudo de certificados ao filtro. E esperado que o filtro apenas contenha os dados especificos necessarios para o mapeamento e que o chamador ira embebe-lo noutro filtro para fazer a propria procura. Devido a isto, a string do filtro deve comecar e terminar com '(' e ')' respetivamente. Em geral e 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 especificos do utilizador a partir do certificado tal como, ex. um endereco de email e procurar por ele no servidor LDAP. A razao e que os dados especificos do utilizador podem mudar por varias razoes e iria quebrar o mapeamento. Do outro modo, seria dificil quebrar o mapeamento de proposito a um utilizador especifico. O tipo predefinido de "mapping rule" e 'LDAP' que pode ser adicionado como prefixo a uma regra como ex. 'LDAP:(userCertificate;binary={cert!bin})'. Existe uma extensao chamada 'LDAPU1' que oferece mais modelos para mais flexibilidade. Para permitir a versoes mais antigas desta biblioteca ignorar a extensao, o prefixo 'LDAPU1' tem de ser usado quando se usa os novos modelos numa "mapping rule" caso contrario a versao antiga desta biblioteca ira falhar com um erro de analise. Os novos modelos estao descritos na seccao the section called "Extensao LDAPU1". Os modelos para adicionar dados de certificados aos filtros de busca sao baseados em strings de formatacao de estilo-Python. Consistem duma palavra chave entre chavetas com um especificador de sub-componente opcional separado por um '.' ou uma opcao de conversao/formatacao opcional separada por um '!'. Os valores permitidos sao: {issuer_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]} Este modelo ira adicionar o emissor total DN convertido numa string conforme RFC 4514. Se encomendar X.500 (RDN mais especifico chega em ultimo) deve ser usado uma opcao com o prefixo '_x500'. As opcoes de conversao que comecam com 'ad_' irao usar nomes de atributo como usado pelo AD, ex. 'S' em vez de 'ST'. As opcoes de conversao que comecam com 'nss_' irao usar nomes de atributo como usado pelo NSS. A opcao de conversao predefinida e 'nss', isto e, nomes de atributos de acordo para pedidos NSS e LDAP/RFC 4514. Exemplo: (ipacertmapdata=X509:{issuer_dn!ad}{subject_dn!ad}) {subject_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]} Este modelo ira adicionar o sujeito total DN convertido numa string conforme RFC 4514. Se encomendar X.500 (RDN mais especifico chega em ultimo) deve ser usado uma opcao com o prefixo '_x500'. As opcoes de conversao que comecam com 'ad_' irao usar nomes de atributo como usado pelo AD, ex. 'S' em vez de 'ST'. As opcoes de conversao que comecam com 'nss_' irao usar nomes de atributo como usado pelo NSS. A opcao de conversao predefinida e 'nss', isto e, nomes de atributos de acordo para pedidos NSS e LDAP/RFC 4514. Exemplo: (ipacertmapdata=X509:{issuer_dn!nss_x500}{subject_dn!nss_x500}) {cert[!(bin|base64)]} Este modelo ira adicionar o certificado completo codificado em DER como uma string ao filtro de busca. Dependendo da opcao de conversao o certificado binario e ou convertido para uma sequencia hexadecimal escapada \\xx' ou base64. A sequencia hexadecimal escapada e a predefinicao e pode, por exemplo, ser usada com o atributo do LDAP 'userCertificate;binary'. Exemplo: (userCertificate;binary={cert!bin}) {subject_principal[.short_name]} Este modelo ira adicionar o principal Kerberos o qual e 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 ira adicionar o principal Kerberos o qual e 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 ira adicionar o principal Kerberos o qual e 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 ira adicionar a string que esta guardada no componente rfc822Name do SAN, tipicamente um endereco de email. O componente 'short_name' representa a primeira parte do endereco antes do sinal '@'. Exemplo: (|(mail={subject_rfc822_name})(uid={subject_rfc822_name.short_name})) {subject_dns_name[.short_name]} Este modelo ira adicionar a string que esta guardada no componente dNSName do SAN, tipicamente um nome de maquina 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 ira adicionar a string que esta guardada no componente uniformResourceIdentifier do SAN. Exemplo: (uri={subject_uri}) {subject_ip_address} Este modelo ira adicionar a string que esta guardada no componente iPAddress do SAN. Exemplo: (ip={subject_ip_address}) {subject_x400_address} Este modelo ira adicionar o valor que esta guardado no componente x400Address do SAN como sequencia hexadecimal escapada. Exemplo: (attr:binary={subject_x400_address}) {subject_directory_name[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]} Este modelo ira adicionar a string DN do valor que esta guardado no componente directoryName do SAN. Exemplo: (orig_dn={subject_directory_name}) {subject_ediparty_name} Este modelo ira adicionar o valor que esta guardado no componente ediPartyName do SAN como sequencia hexadecimal escapada. Exemplo: (attr:binary={subject_ediparty_name}) {subject_registered_id} Este modelo ira adicionar o OID que esta guardado no componente registeredID do SAN como uma string decimal-pontuada. Exemplo: (oid={subject_registered_id}) Extensao LDAPU1 The following templates are available when using the 'LDAPU1' extension: {serial_number[!(dec|hex[_ucr])]} Este modelo ira adicionar o numero de serie do certificado. Por predefinicao sera escrito como um numero hexadecimal com letras minusculas. Com a opcao de formatacao '!dec' o numero sera escrito em string decimal. O resultado hexadecimal pode ser escrito com letras maiusculas ('!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 maiusculas. Exemplo: LDAPU1:(serial={serial_number}) {subject_key_id[!hex[_ucr]]} Este modelo ira adicionar o id de chave de objeto do certificado. Por predefinicao sera escrito como um numero hexadecimal com letras minusculas. O resultado em hexadecimal pode ser escrito com letras maiusculas ('!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 maiusculas. Exemplo: LDAPU1:(ski={subject_key_id}) {cert[!DIGEST[_ucr]]} Este modelo ira adicionar a digestao/cinza hexadecimal do certificado onde DIGEST tem de ser substituido pelo nome da funcao digest/hash suportada pelo OpenSSL, ex. 'sha512'. O resultado em hexadecimal pode ser escrito com letras maiusculas ('!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 maiusculas. Exemplo: LDAPU1:(dgst={cert!sha256}) {subject_dn_component[(.attr_name|[number]]} Este modelo ira adicionar um valor de atributo de um componente do objeto DN, por predefinicao o valor do componente mais especifico. 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 ira adicionar um valor de atributo de um componente do publicador DN, por predefinicao o valor e o componente mais especifico. Veja 'subject_dn_component' para detalhes acerca de nome de atributo e especificadores de posicao. Exemplo: LDAPU1:(domain={issuer_dn_component.[-2]}.{issuer_dn_component.dc[-1]}) {sid[.rid]} Este modelo ira adicionar o SID se a extensao correspondente introduzida pela Microsoft com o OID 1.3.6.1.4.1.311.25.2 estiver disponivel. Com o seletor '.rid' apenas o ultimo componente, isto e, o RID, sera adicionado. Exemplo: LDAPU1:(objectsid={sid}) LISTA DE DOMINIOS Se a lista de dominios nao estiver vazia, os utilizadores mapeados a um dado certificado nao sao apenas procurados no dominio local mas tambem nos dominios listados desde que sejam conhecidos pelo SSSD. Os dominios nao conhecidos do SSSD serao ignorados. AUTHORS O autor do SSSD - https://github.com/SSSD/sssd/ SSSD 01/18/2026 SSS-CERTMAP(5)