table of contents
SSS-CERTMAP(5) | Formatos de archivo y convenci | SSS-CERTMAP(5) |
NAME¶
sss-certmap - Reglas de Correspondencia y Asignación de Certificados SSSD
DESCRIPCION¶
La página de manual describe las reglas que pueden ser usadas por SSSD y otros componentes para corresponder con los certificados X.509 y asignarlos a cuentas.
Cada regla tiene cuatro componentes, una “priority”, una “matching rule”, una “mapping rule” y una “domain list”. Todos los componentes son opcionales. Si no hay “priority” se añadirá la regla con el nivel de prioridad más bajo. La “matching rule” predeterminada hará coincidir los certificados con la clave de utilización digitalSignature y la clave de utilización extendida clientAuth. Si “mapping rule” está vacía los certificados serán buscados en el atributo userCertificate como DER codificado en binario. Si no se dan dominios solo se buscará en el dominio local.
To allow extensions or completely different style of rule the “mapping” and “matching rules” can contain a prefix separated with a ':' from the main part of the rule. The prefix may only contain upper-case ASCII letters and numbers. If the prefix is omitted the default type will be used which is 'KRB5' for the matching rules and 'LDAP' for the mapping rules.
The 'sssctl' utility provides the 'cert-eval-rule' command to check if a given certificate matches a matching rules and how the output of a mapping rule would look like.
COMPONENTES DE LA REGLA¶
PRIORIDAD¶
Las reglas son procesados por prioridad sabiendo que el número '0' (cero) indica la prioridad más alta. Más alto en número más baja la prioridad. Un valor desaparecido indica la prioridad más baja. Las reglas de procesamiento se para cuando una regla coincidente y no se comprueban más reglas.
Internamente la prioridad se trata como un entero no firmado de 32 bitr, la utilización de in valor de prioridad superior a 4294967295 causará un error.
If multiple rules have the same priority and only one of the related matching rules applies, this rule will be chosen. If there are multiple rules with the same priority which matches, one is chosen but which one is undefined. To avoid this undefined behavior either use different priorities or make the matching rules more specific e.g. by using distinct <ISSUER> patterns.
REGLA DE COINCIDENCIA¶
La regla de coincidencia se usa para seleccionar un certificado al que sería aplicado la regla de asignación. Usa un sistema similar al usado por la opción “pkinit_cert_match” de MIT Kerberos. Consiste en una clave encerrada entre '<' y '>' ue identifica una cierta parte del certificado y un patrón para que la regla coincida. Se pueden unir varios pares de palabras claves con '&&' (y) o '||' (o).
Given the similarity to MIT Kerberos the type prefix for this rule is 'KRB5'. But 'KRB5' will also be the default for “matching rules” so that "<SUBJECT>.*,DC=MY,DC=DOMAIN" and "KRB5:<SUBJECT>.*,DC=MY,DC=DOMAIN" are equivalent.
Las opciones disponibles son:
<SUBJECT>regular-expression
Para coincidir el nombre sujeto almacenado en el certificado en codificación DER ASN.1 se convierte en una cadena de acuerdo a RFC 4514. Esto significa que el componente de nombre más específico es el primero. Por favor advierta que no todos los posibles nombres de atributo están cubiertos por RFC 4514. Los nombres incluidos son 'CN', 'L', 'ST', 'O', 'OU', 'C', 'STREET', 'DC' y 'UID'. Otros nombres de atributo pueden ser mostrados de forma diferente sobre plataformas distintas y por herramientas diferentes. Para evitar la confusión es mejor que no se usen estos nombres de atributos o se cubran por una expresión regular a medida.
Ejemplo: <SUBJECT>.*,DC=MY,DC=DOMAIN
Please note that the characters "^.[$()|*+?{\" have a special meaning in regular expressions and must be escaped with the help of the '\' character so that they are matched as ordinary characters.
Example: <SUBJECT>^CN=.* \(Admin\),DC=MY,DC=DOMAIN$
<ISSUER>regular-expression
Ejemplo: <ISSUER>^CN=My-CA,DC=MY,DC=DOMAIN$
<KU>key-usage
Un valor numérico en el rango de un entero sin signo de 32 bit se puede usar también para cubrir casos de uso especiales.
Ejemplo: <KU>digitalSignature,keyEncipherment
<EKU>extended-key-usage
La utilización de claves extendidas que no están listadas arriba pueden ser especificadas con sus OID en anotación decimal con puntos.
Ejemplo: <EKU>clientAuth,1.3.6.1.5.2.3.4
<SAN>regular-expression
Ejemplo: <SAN>.*@MY\.REALM
<SAN:Principal>regular-expression
Example: <SAN:Principal>.*@MY\.REALM
<SAN:ntPrincipalName>regular-expression
Example: <SAN:ntPrincipalName>.*@MY.AD.REALM
<SAN:pkinit>regular-expression
Example: <SAN:ntPrincipalName>.*@MY\.PKINIT\.REALM
<SAN:dotted-decimal-oid>regular-expression
Example: <SAN:1.2.3.4>test
<SAN:otherName>base64-string
Example: <SAN:otherName>MTIz
<SAN:rfc822Name>regular-expression
Example: <SAN:rfc822Name>.*@email\.domain
<SAN:dNSName>regular-expression
Example: <SAN:dNSName>.*\.my\.dns\.domain
<SAN:x400Address>base64-string
Example: <SAN:x400Address>MTIz
<SAN:directoryName>regular-expression
Example: <SAN:directoryName>.*,DC=com
<SAN:ediPartyName>base64-string
Ejemplo: <SAN:ediPartyName>MTIz
<SAN:uniformResourceIdentifier>regular-expression
Ejemplo: <SAN:uniformResourceIdentifier>URN:.*
<SAN:iPAddress>regular-expression
Ejemplo: <SAN:iPAddress>192\.168\..*
<SAN:registeredID>regular-expression
Ejemplo: <SAN:registeredID>1\.2\.3\..*
REGLA DE MAPEO¶
La regla de mapeo se usa para asociar un certificado con una o mas cuentas. Una Smartcard con el certificado y la clave privada correspondiente puede ser usada entonces para autenticar una de estas cuentas.
Actualmente SSSD básicamente solo soporta LDAP para buscar información de usuario (la excepción es el proveedor proxy que no tiene relevancia aqui). Por esto la regla de mapeo se basa en una búsqueda por filtro de sintaxis LDAP con plantillas para añadir el contenido del certificado al filtro. Se espra que ese filtro solo contendrá los datos específicos para el mapeo y que la persona que llama lo incrustará en otro filtro para hacer la búsqueda real. Debido a esto la cadena de filtro de empezar y terminar con '('and')' respectivamente.
En general se recomienda usar atributos del certificado y añadirlos a atributos especiales al objeto usuario LDAP. E.g. el atributo 'altSecurityIdentities' en AD o el atributo 'ipaCertMapData' para IPA se pueden usar.
Debería preferible leer datos específicos del usuario del certificado, e.g. una dirección de correo electrónico y buscarla en el servidor LDAP. La razón es que los datos específicos del usuario en el LDAP podrían cambiar por diversas razones y romper el mapeo. Por otro lado, sería difícil romper el mapeo a propósito para un usuario específico.
The default “mapping rule” type is 'LDAP' which can be added as a prefix to a rule like e.g. 'LDAP:(userCertificate;binary={cert!bin})'. There is an extension called 'LDAPU1' which offer more templates for more flexibility. To allow older versions of this library to ignore the extension the prefix 'LDAPU1' must be used when using the new templates in a “mapping rule” otherwise the old version of this library will fail with a parsing error. The new templates are described in section the section called “LDAPU1 extension”.
La plantilla para añadir datos de certificado al filtro de búsqueda están basados sobre cadenas formateadas en estilo Python. Consiste en una palabra clave entre llaves con un subcomponente especificador opcional separado por un '.' o una opción opcional de conversión/formateo separada por un '!'. Los valores permitidos son:
{issuer_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}
Las opciones de conversión que empiezan con 'ad_' usarán nombres de atributos como los usados por AD, p. ej. 'S' en lugar de 'ST'.
Las opciones de conversión que empiezan por 'nss_' usarán nombres de atributos como los usados por NSS.
La opción de conversión predeterminada es 'nss', i.e. los nombres de atributo de acuerdo con la ordenación NSS y LDAP/RFC 4514.
Ejemplo: (ipacertmapdata=X509:<I>{issuer_dn!ad}<S>{subject_dn!ad})
{subject_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}
Las opciones de conversión que empiezan con 'ad_' usarán nombres de atributos como los usados por AD, p. ej. 'S' en lugar de 'ST'.
Las opciones de conversión que empiezan por 'nss_' usarán nombres de atributos como los usados por NSS.
La opción de conversión predeterminada es 'nss', i.e. los nombres de atributo de acuerdo con la ordenación NSS y LDAP/RFC 4514.
Ejemplo: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
{cert[!(bin|base64)]}
Ejemplo: (userCertificate;binary={cert!bin})
{subject_principal[.short_name]}
Ejemplo: (|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name}))
{subject_pkinit_principal[.short_name]}
Ejemplo: (|(userPrincipal={subject_pkinit_principal})(uid={subject_pkinit_principal.short_name}))
{subject_nt_principal[.short_name]}
Example: (|(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.short_name}))
{subject_rfc822_name[.short_name]}
Ejemplo: (|(mail={subject_rfc822_name})(uid={subject_rfc822_name.short_name}))
{subject_dns_name[.short_name]}
Ejemplo: (|(fqdn={subject_dns_name})(host={subject_dns_name.short_name}))
{subject_uri}
Ejemplo: (uri={subject_uri})
{subject_ip_address}
Ejemplo: (ip={subject_ip_address})
{subject_x400_address}
Ejemplo: (attr:binary={subject_x400_address})
{subject_directory_name[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}
Ejemplo: (orig_dn={subject_directory_name})
{subject_ediparty_name}
Ejemplo: (attr:binary={subject_ediparty_name})
{subject_registered_id}
Ejemplo: (oid={subject_registered_id})
LDAPU1 extension
The following template are available when using the 'LDAPU1' extension:
{serial_number[!(dec|hex[_ucr])]}
With the formatting option '!dec' the number will be printed as decimal string. The hexadecimal output can be printed with upper-case letters ('!hex_u'), with a colon separating the hexadecimal bytes ('!hex_c') or with the hexadecimal bytes in reverse order ('!hex_r'). The postfix letters can be combined so that e.g. '!hex_uc' will produce a colon-separated hexadecimal string with upper-case letters.
Example: LDAPU1:(serial={serial_number})
{subject_key_id[!hex[_ucr]]}
The hexadecimal output can be printed with upper-case letters ('!hex_u'), with a colon separating the hexadecimal bytes ('!hex_c') or with the hexadecimal bytes in reverse order ('!hex_r'). The postfix letters can be combined so that e.g. '!hex_uc' will produce a colon-separated hexadecimal string with upper-case letters.
Example: LDAPU1:(ski={subject_key_id})
{cert[!DIGEST[_ucr]]}
The hexadecimal output can be printed with upper-case letters ('!sha512_u'), with a colon separating the hexadecimal bytes ('!sha512_c') or with the hexadecimal bytes in reverse order ('!sha512_r'). The postfix letters can be combined so that e.g. '!sha512_uc' will produce a colon-separated hexadecimal string with upper-case letters.
Example: LDAPU1:(dgst={cert!sha256})
{subject_dn_component[(.attr_name|[number]]}
A different component can it either selected by 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'.
Example: LDAPU1:(uid={subject_dn_component.uid})
{issuer_dn_component[(.attr_name|[number]]}
See 'subject_dn_component' for details about the attribute name and position specifiers.
Example: LDAPU1:(domain={issuer_dn_component.[-2]}.{issuer_dn_component.dc[-1]})
{sid[.rid]}
Example: LDAPU1:(objectsid={sid})
LISTA DE DOMINIO¶
Si la lista de dominio no está vacía los usuarios mapeados a un certificado dado no serán buscados solo en el dominio local sino también en los dominios listados siempre que sean conocidos por SSSD. Los dominios no conocidos por SSSD serán ignorados.
AUTHORS¶
The SSSD upstream - https://github.com/SSSD/sssd/
04/18/2024 | SSSD |