sss-certmap 5 Formatos de archivo y convenciones sss-certmap Reglas de Correspondencia y Asignación de Certificados SSSD 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. 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. 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 Con esto una parte o todo el nombre de sujeto del certificado pueden coincidir. Para la coincidencia se usa la sintaxis Expresión Regular Extendida POSIX, vea detalles en regex(7). 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 Con esto, se puede hacer coincidir una parte o el nombre completo del emisor del certificado. Todos los comentarios para <SUBJECT> se le aplican también. Ejemplo: <ISSUER>^CN=My-CA,DC=MY,DC=DOMAIN$ <KU>key-usage Esta opción se puede usar para especificar que valores de uso clave debe tener el certificado. Se pueden usar los siguientes valores en una lista separados por comas: digitalSignature nonRepudiation keyEncipherment dataEncipherment keyAgreement keyCertSign cRLSign encipherOnly decipherOnly 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 Esta opción se puede usar para especificar que uso de clave extendida puede tener el certificado. El siguiente valor se puede usar en una lista separada por comas: serverAuth clientAuth codeSigning emailProtection timeStamping OCSPSigning KPClientAuth pkinit msScLogin 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 Para ser compatible con la utilización de MIT Kerberos esta opción coincidirá con los principios de Kerberos en PKINIT o AD NT Principal SAN como hace <SAN:Principal>. Ejemplo: <SAN>.*@MY\.REALM <SAN:Principal>regular-expression Haga coincidir los principios principales de Kerberos en la SAN principal de PKINIT o AD NT. Example: <SAN:Principal>.*@MY\.REALM <SAN:ntPrincipalName>regular-expression Haga coincidir los principales de Kerberos de la SAN principal de AD NT. Example: <SAN:ntPrincipalName>.*@MY.AD.REALM <SAN:pkinit>regular-expression Haga coincidir los principales de Kerberos con los PKINIT SAN. Example: <SAN:ntPrincipalName>.*@MY\.PKINIT\.REALM <SAN:dotted-decimal-oid>regular-expression Toma el valor del componente SAN otherName dado por el de OID en anotación decimal con puntos, lo interpreta como una cadena e intenta hacerlo coincidir con la expresión regular. Example: <SAN:1.2.3.4>test <SAN:otherName>base64-string Haga una coincidencia binaria con el blob codificado en base64 con todos los demás componentes SAN otheName. Con esta opción es posible la coincidencia con los componentes otherName personales con codificación especial que podrían no ser tratados como cadenas. Example: <SAN:otherName>MTIz <SAN:rfc822Name>regular-expression Haga coincidir el valor del rfc822Name SAN. Example: <SAN:rfc822Name>.*@email\.domain <SAN:dNSName>regular-expression Haga coincidir el valor del dNSName SAN. Example: <SAN:dNSName>.*\.my\.dns\.domain <SAN:x400Address>base64-string Binario coincide con el valor del x400Address SAN. Example: <SAN:x400Address>MTIz <SAN:directoryName>regular-expression Haga coincidir el valor del directoryName SAN. Los mismos comentarios dados para <ISSUER> and <SUBJECT> se aplican aquí también. Example: <SAN:directoryName>.*,DC=com <SAN:ediPartyName>base64-string Hacer coincidir binario el valor del ediPartyName SAN. Ejemplo: <SAN:ediPartyName>MTIz <SAN:uniformResourceIdentifier>regular-expression Hacer coincidir el valor del uniformResourceIdentifier SAN. Ejemplo: <SAN:uniformResourceIdentifier>URN:.* <SAN:iPAddress>regular-expression Haga coincidir el valor del iPAddress SAN. Ejemplo: <SAN:iPAddress>192\.168\..* <SAN:registeredID>regular-expression Haga coincidir el valor de registeredID SAN como cadena decimal con puntos. Ejemplo: <SAN:registeredID>1\.2\.3\..* 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 . 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))]} Esta plantilla agregará el DN del emisor completo convertido en una plantilla de acuerdo con el RFC 4514. Si se ordena X.500 (más especifico RDN viene el último) se debería usar un opción con el prefijo '_x500'. 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))]} Esta plantilla añadirá el sujeto completo DN convertido en una cadena de acuerdo a RFC 4514. Si la ordenación X.500 (más específico RDN viene el último) se usaría una opción con el prefijo '_x500'. 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)]} Esta plantilla añadirá el certificado completo codificado DER como una cadena al filtro de búsqueda. Dependiendo de la opción de conversión el certificado binario se convierte en una secuencia hexadecimal escapada '\xx' o base64. La secuencia hexadecimal escapada es la predeterminada y puede, por ejemplo, ser usada con el atributo LDAP 'userCertificate;binary'. Ejemplo: (userCertificate;binary={cert!bin}) {subject_principal[.short_name]} Esta plantilla añadirá el principal Kerberos bien desde el SAN usado por pkinit o del usado por AD. El componente 'short_name' representa la primera parte del principal antes del signo '@'. Ejemplo: (|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name})) {subject_pkinit_principal[.short_name]} Esta plantilla añadirá el principal Kerberos que es dado por el SAN usado por pkinit. El componente 'short_name' representa la primera parte del principal antes del signo '@'. Ejemplo: (|(userPrincipal={subject_pkinit_principal})(uid={subject_pkinit_principal.short_name})) {subject_nt_principal[.short_name]} Esta plantilla añadirá el principal Kerberos que es dado por el SAN usado por AD. El componente 'short_name' represebta la primera parte del principal antes del signo '@'. Example: (|(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.short_name})) {subject_rfc822_name[.short_name]} Esta plantilla añadirá la cadena que está almacenada en el componente rfc822Name del SAN, normalmente una dirección de correo electrónico. El componente 'short_name' representa la primera parte de la dirección antes del signo '@'. Ejemplo: (|(mail={subject_rfc822_name})(uid={subject_rfc822_name.short_name})) {subject_dns_name[.short_name]} Esta plantilla añadirá la cadena que está almacenada en el componente dNSName del SAN, normalmente un nombre de host totalmente cualificado. El componente 'short_name' representa la primera parte del nombre antes del primer signo '.'. Ejemplo: (|(fqdn={subject_dns_name})(host={subject_dns_name.short_name})) {subject_uri} Esta plantilla añadirá la cadena que está almacenada en el componente uniformResourceIdentifier del SAN. Ejemplo: (uri={subject_uri}) {subject_ip_address} Esta plantilla añadirá la cadena que está almacenada en el componente iPAddress del SAN. Ejemplo: (ip={subject_ip_address}) {subject_x400_address} Esta plantilla añadirá el valor que está almacenado en el componente x400Address del SAN como secuencia hexadecimal escapada. Ejemplo: (attr:binary={subject_x400_address}) {subject_directory_name[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]} Esta plantilla añadirá la cadena DN del valor que está almacenado en el componente directoryName del SAN. Ejemplo: (orig_dn={subject_directory_name}) {subject_ediparty_name} Esta plantilla añadirá el valor que está almacenado en el componente ediPartyName del SAN como secuencia hexadecimal escapada. Ejemplo: (attr:binary={subject_ediparty_name}) {subject_registered_id} Esta plantilla añadirá la OID que está almacenada en el componente registeredID del SAN como una cadena decimal con puntos.. Ejemplo: (oid={subject_registered_id}) The following template are available when using the 'LDAPU1' extension: {serial_number[!(dec|hex[_ucr])]} This template will add the serial number of the certificate. By default it will be printed as a hexadecimal number with lower-case letters. 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]]} This template will add the subject key id of the certificate. By default it will be printed as a hexadecimal number with lower-case letters. 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]]} This template will add the hexadecimal digest/hash of the certificate where DIGEST must be replaced with the name of a digest/hash function supported by OpenSSL, e.g. 'sha512'. 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]]} This template will add an attribute value of a component of the subject DN, by default the value of the most specific component. 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]]} This template will add an attribute value of a component of the issuer DN, by default the value of the most specific component. 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]} This template will add the SID if the corresponding extension introduced by Microsoft with the OID 1.3.6.1.4.1.311.25.2 is available. With the '.rid' selector only the last component, i.e. the RID, will be added. Example: LDAPU1:(objectsid={sid}) 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.