SSS-CERTMAP(5) Filformat och konventioner SSS-CERTMAP(5) NAME sss-certmap - SSSD:s certifikatmatchnings- och -mappningsregler BESKRIVNING Manualsidan beskriver reglerna som kan anvandas av SSSD och andra komponenter for att matcha X.509-certifikat och koppla dem till konton. Varje regel har fyra komponenter, en "prioritet", en "matchningsregel", en "mappningsregel" och en "domanlista". Alla komponenter ar frivilliga. En saknad "prioritet" kommer lagga till regeln med den lagsta prioriteten. Standard-"matchningsregeln" kommer matcha certifikat med digitalSignature-nyckelanvandning och clientAuth-utokadnyckelanvandning. Om "mappningsregeln" ar tom kommer certifikaten sokas efter i attributet userCertificate som DER-kodade binarer. Om inga domaner anges kommer endast den lokala domanen sokas. For att tillata utokningar eller helt annorluda regelstil kan "mapping" och "matching rules" innehalla ett prefix separerat med ett ":" fran huvuddelen av regeln. Prefixet far bara innehalla versala ASCII-bokstaver och siffror. Om prefixet utelamnas kommer standardtypen anvandas vilken ar "KRB5" for matchningsregler och "LDAP" for avbildningsregler. Verktyget "sssctl" tillhandahaller kommandot "cert-eval-rule" for att kontrollera om ett givet certifikat stammer med en matchningsregel och hur utdata fran en avbildningsregel skulle se ut. REGELKOMPONENTER PRIORITET Reglerna bearbetas i prioritetsordning dar "0" (noll) indikerar den hogsta prioriteten. Ju hogre talet ar desto lagre ar prioriteten. Ett saknat varde indikerar den lagsta prioriteten. Regelbearbetningen stoppas nar en regel som matchar hittas och inga ytterligare regler kontrolleras. Internt behandlas prioriteten som teckenlosa 32-bitars heltal, att anvanda ett prioritetsvarde storre an 4294967295 kommer orsaka ett fel. Om flera regler har samma prioritet och bara en av de relaterade matchningsreglerna galler kommer denna regel att valjas. Om det finns flera regler med samma prioritet som matchar valjs en men vilken av den ar odefinierat. For att undvika detta beteende, anvand antingen olika prioriteter eller gor matchningsregeln mer specifik, t.ex. genom att anvanda olika -monster. MATCHNINGSREGEL Matchningsregeln anvands for att valja ett certifikat som oversattningsregeln skall tillampas pa. Det anvander ett system liknande det som anvands av alternativet "pkinit_cert_match" i MIT Kerberos. Det bestar av ett nyckelord omgivet av "<" och ">" som identifierar en specifik del av certifikatet och ett monster som skall finnas for att regeln skall matcha. Flera nyckelord/monster-par kan antingen sammanfogas med "&&" (och) eller "||" (eller). Givet likheten med MIT Kerberos ar typprefixet for denna regel "KRB5". Men "KRB5" kommer aven vara standardvardet for "matching rules" sa att ".*,DC=MIN,DC=DOMAN" och "KRB5:.*,DC=MIN,DC=DOMAN" ar likvardiga. De tillgangliga alternativen ar: reguljart-uttryck Med denna kan en del eller hela certifikatets subject-namn matchas. For matchningen anvands POSIX syntax for utokade reguljara uttryck, se regex(7) for detaljer. For matchningen konverteras subject-namnet lagrat i certifikatet i DER-kodad ASN.1 till en strang i enlighet med RFC 4514. Detta betyder att den mest specifika namnkomponenten kommer forst. Observera att inte alla mojliga attributnamn tacks av RFC 4514. De inkluderade namnen ar "CN", "L", "ST", "O", "OU", "C", "STREET", "DC" och "UID". Andra attributnamn kan visas olika pa olika plattformar och av olika verktyg. For att undvika forvirring ar det bast att dessa attributnamn inte anvands eller tacks av ett lampligt reguljart uttryck. Exempel: .*,DC=MIN,DC=DOMAN Observera att tecknen "^.[$()|*+?{\" har en sarskild betydelse i reguljara uttryck och maste skyddas med hjalp av tecknet "\" sa att de kan matchas som vanliga tecken. Exempel: ^CN=.* \(Admin\),DC=MIN,DC=DOMAN$ reguljart-uttryck Med denna kan en del eller hela certifikatets issuer-namn matchas. Alla kommentarer for ar tillampliga har ocksa. Exempel: ^CN=Min-CA,DC=MIN,DC=DOMAN$ nyckelanvandning Detta alternativ kan anvandas for att specificera vilka nyckelanvandningsvarden certifikatet skall ha. Foljande varden kan anvandas i en kommaseparerad lista: o digitalSignature o nonRepudiation o keyEncipherment o dataEncipherment o keyAgreement o keyCertSign o cRLSign o encipherOnly o decipherOnly Ett numeriskt varde i intervallet hos ett 32-bitars teckenlost heltal kan anvandas ocksa for att tacka speciella anvandningsfall. Exempel: digitalSignature,keyEncipherment utokad-nyckel-anvandning Detta alternativ kan anvandas for att specificera vilka utokade-nyckel-anvandningsvarden certifikatet skall ha. Foljande varden kan anvandas i en kommaseparerad lista: o serverAuth o clientAuth o codeSigning o emailProtection o timeStamping o OCSPSigning o KPClientAuth o pkinit o msScLogin Anvandningar av utokade nycklar som inte listas ovanfor kan specificeras med sina OID:er i punktad decimal notation. Exempel: clientAuth,1.3.6.1.5.2.3.4 reguljart-uttryck For att vara kompatibel med anvandningen av MIT Kerberos kommer detta alternativ matcha Kerberos-huvudman i PKINIT eller AD NT-Principal SAN som gor. Exempel: .*@MITT\.RIKE reguljart-uttryck Matcha Kerberos-huvudmannen i PKINIT eller AD NT Principal SAN. Exempel: .*@MITT\.RIKE reguljart-uttryck Matcha Kerberos-huvudman fran AD NT Principal SAN. Exempel: .*@MITT.AD.RIKE reguljart-uttryck Matcha Kerberos-huvudman fran PKINIT SAN. Exempel: .*@MITT\.PKINIT\.RIKE reguljart-uttryck Ta vardet fran otherName SAN-komponenten som anges av OID:n i punktad decimal notation, tolka den som en strang och forsok att matcha den mot det reguljara uttrycket. Exempel: test base64-strang Gor en binar matchning med den base64-kodade klicken mot alla otherName SAN-komponenter. Med detta alternativ ar det mojligt att matcha mot anpassade otherName-komponenter med speciella kodningar som inte kan hanteras som strangar. Exempel: MTIz reguljart-uttryck Matcha vardet pa rfc822Name SAN. Exempel: .*@epost\.doman reguljart-uttryck Matcha vardet pa dNSName SAN. Exempel: .*\.min\.dns\.doman base64-strang Matcha binart vardet pa x400Address SAN. Exempel: MTIz reguljart-uttryck Matcha vardet pa directoryName SAN. Samma kommentarer som gavs for och galler har ocksa. Exempel: .*,DC=com base64-strang Matcha binart vardet pa ediPartyName SAN. Exempel: MTIz reguljart-uttryck Matcha vardet pa uniformResourceIdentifier SAN. Exempel: URN:.* reguljart-uttryck Matcha vardet pa iPAddress SAN. Exempel: 192\.168\..* reguljart-uttryck Matcha vardet pa registeredID SAN som punktad decimal strang. Exempel: 1\.2\.3\..* MAPPNINGSREGEL Mappningsregeln anvands for att koppla ett certifikat med ett eller flera konton. Ett smartkort med certifikat och den matchande privata nyckeln kan da anvandas for autentisering som ett av dessa konton. For narvarande stodjer SSSD egentligen bara LDAP for att sla upp anvandarinformation (undantaget ar proxy-leverantoren som inte ar relevant har. Pa grund av detta ar mappningsregeln baserad pa syntaxen for LDAP-sokfilter med mallar for att lagga till certifikatinnehall till filtret. Det antas att filtret endast kommer innehalla de specifika data som behovs for mappningen och att anroparen kommer badda in dem i ett annat filter for att gora den egentliga sokningen. Darfor skall filterstrangen borja och sluta med "(" respektive ")". I allmanhet rekommenderas det att anvanda attribut fran certifikatet och lagga till dem till speciella attribut till LDAP-anvandarobjektet. T.ex. kan attributet "altSecurityIdentities" i AD eller attributet "ipaCertMapData" i IPA anvandas. Detta bor hellre anvandas an att lasa anvandarspecifik data fran certifikatet som t.ex. en e-postadress och soka efter den i LDAP-servern. Anledningen ar att anvandarspecifika data i LDAP kan andras av olika anledningar vilket skulle gora sonder mappningen. A andra sidan skulle det vara svart att bryta mappningen avsiktligt for en specifik anvandare. Standardtypen for "mapping rule" ar "LDAP" vilket kan laggas till som ett prefix till en regel som t.ex. "LDAP:(userCertificate;binary={cert!bin})". Det finns en utokning som heter "LDAPU1" som erbjuder fler mallar for mer flexibilitet. For att tillata aldre versioner av detta bibliotek att ignorera utokningen maste prefixet "LDAPU1" anvandas nar de nya mallarna i en "mapping rule" anvands annars kommer den gamla versionen av biblioteket misslyckas med ett tolkningsfel. Den nya mallarna beskrivs i avsnittet the section called "LDAPU1-utvidgningen". Mallarna for att lagga till certifikatdata till sokfiltret baseras pa formateringsstrangar i Python-stil. De bestar av ett nyckelord i krullparenteser med en valfri underkomponentspecificerare separerad av en "." eller ett valfritt konverterings-/formateringsalternativ separerat av ett "!". Tillatna varden ar: {issuer_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]} Mallen kommer lagga till den fullstandiga utgivar-DN:en konverterad till en strang enligt RFC 4514. Om X.500-ordning (mest specifik RDN kommer sist) skall ett alternativ med prefixet "_x500" anvandas. Konverteringsalternativen som borjar med "ad_" kommer anvanda attribut som de anvands av AD, t.ex. "S" istallet for "ST". Konverteringsalternativen som borjar med "nss_" kommer anvanda attributnamn som de anvands av NSS. Standard for konverteringsalternativ ar "nss", d.v.s. attributnamn enligt NSS och LDAP/RFC 4514-ordning. Exempel: (ipacertmapdata=X509:{issuer_dn!ad}{subject_dn!ad}) {subject_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]} Mallen kommer lagga till den fullstandiga subjekt-DN:en konverterad till en strang enligt RFC 4514. Om X.500-ordning (mest specifik RDN kommer sist) skall ett alternativ med prefixet "_x500" anvandas. Konverteringsalternativen som borjar med "ad_" kommer anvanda attribut som de anvands av AD, t.ex. "S" istallet for "ST". Konverteringsalternativen som borjar med "nss_" kommer anvanda attributnamn som de anvands av NSS. Standard for konverteringsalternativ ar "nss", d.v.s. attributnamn enligt NSS och LDAP/RFC 4514-ordning. Exempel: (ipacertmapdata=X509:{issuer_dn!nss_x500}{subject_dn!nss_x500}) {cert[!(bin|base64)]} Denna mall kommer lagga till hela det DER-kodade certifikatet som an strang till sokfiltret. Beroende pa konverteringsalternativen konverteras antingen certifikatet till en hex-sekvens med styrtecken "\xx" eller till base64. Hex-strangen med styrtecken ar standard och kan t.ex. anvandas med LDAP-attributet "userCertificate;binary". Exempel: (userCertificate;binary={cert!bin}) {subject_principal[.short_name]} Denna mall kommer lagga till Kerberos-huvudmannen som hamtas antingen fran den SAN som anvands av pkinit eller den som anvands av AD. Komponenten "short_name" representerar forsta delen av huvudmannen fore tecknet "@". Exempel: (|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name})) {subject_pkinit_principal[.short_name]} Denna mall kommer lagga till Kerberos-huvudmannen som hamtas fran den SAN som anvands av pkinit. Komponenten "short_name" representerar forsta delen av huvudmannen fore tecknet "@". Exempel: (|(userPrincipal={subject_pkinit_principal})(uid={subject_pkinit_principal.short_name})) {subject_nt_principal[.short_name]} Denna mall kommer lagga till Kerberos-huvudmannen som hamtas fran den SAN som anvands av AD. Komponenten "short_name" representerar forsta delen av huvudmannen fore tecknet "@". Exempel: (|(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.short_name})) {subject_rfc822_name[.short_name]} Denna mall kommer lagga till strangen som lagras i komponenten rfc822Name i SAN:en, normalt en e-postadress. Komponenten "short_name" representerar forsta delen av huvudmannen fore tecknet "@". Exempel: (|(mail={subject_rfc822_name})(uid={subject_rfc822_name.short_name})) {subject_dns_name[.short_name]} Denna mall kommer lagga till strangen som lagras i komponenten dNSName i SAN:en, normalt ett fullstandigt kvalificerat vardnamn. Komponenten "short_name" representerar forsta delen av huvudmannen fore det forsta "."-tecknet. Exempel: (|(fqdn={subject_dns_name})(host={subject_dns_name.short_name})) {subject_uri} Denna mall kommer lagga till strangen som lagras i komponenten uniformResourceIdentifier i SAN:en. Exempel: (uri={subject_uri}) {subject_ip_address} Denna mall kommer lagga till strangen som lagras i komponenten iPAddress i SAN:en. Exempel: (ip={subject_ip_address}) {subject_x400_address} Denna mall kommer lagga till vardet som lagras i komponenten x400Address i SAN:en som en hex-sekvens med styrtecken. Exempel: (attr:binary={subject_x400_address}) {subject_directory_name[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]} Denna mall kommer lagga till DN-strangen for vardet som lagras i komponenten directoryName i SAN:en. Exempel: (orig_dn={subject_directory_name}) {subject_ediparty_name} Denna mall kommer lagga till vardet som lagras i komponenten ediPartyName i SAN:en som en hex-sekvens med styrtecken. Exempel: (attr:binary={subject_ediparty_name}) {subject_registered_id} Denna mall kommer lagga till OID:n som lagras i komponenten registeredID i SAN:en som en punktad decimal strang. Exempel: (oid={subject_registered_id}) LDAPU1-utvidgningen Foljande mall ar tillganglig nar utokningen "LDAPU1" anvands: {serial_number[!(dec|hex[_ucr])]} Denna mall kommer lagga till certifikatets serienummer. Som standard kommer det skrivas som ett hexadecimalt tal med gemena bokstaver. Med formateringsalternativet "!dec" kommer numret skrivas som en decimal strang. Den exadecimala utdatan kan skrivas med versala bokstaver ("!hex_u"), med ett kolon som separator mellan hexadecimala byte ("!hex_c") eller med de hexadecimala byten i omvand ordning ("!hex_r"). Postfixbokstaverna kan kombineras sa att t.ex. "!hex_uc" kommer producera en kolonseparerad hexadecimal strang med versaler. Exempel: LDAPU1:(serial={serial_number}) {subject_key_id[!hex[_ucr]]} Denna mall kommer lagga till certifikatets subjektnyckel-id. Som standard kommer det skrivas som ett hexadecimalt tal med gemena bokstaver. Den hexadecimala utdatan kan skrivas med versala bokstaver ("!hex_u"), med ett kolon som separator mellan hexadecimala byte ("!hex_c") eller med de hexadecimala byten i omvand ordning ("!hex_r"). Postfixbokstaverna kan kombineras sa att t.ex. "!hex_uc" kommer producera en kolonseparerad hexadecimal strang med versaler. Exempel: LDAPU1:(ski={subject_key_id}) {cert[!KONTROLLSUMMA[_ucr]]} Denna mall kommer laga till certifikatets hexadecimala kontrollsumma/hash dar KONTROLLSUMMA maste ersattas med namnet pa en kontrollsumme-/hash-funktion som stodjs av OpenSSL, t.ex. "sha512". Den hexadecimala utdatan kan skrivas med versala bokstaver ("!sha512_u"), med ett kolon som separator mellan hexadecimala byte ("!sha512_c") eller med de hexadecimala byten i omvand ordning ("!sha512_r"). Postfixbokstaverna kan kombineras sa att t.ex. "!sha512_uc" kommer producera en kolonseparerad hexadecimal strang med versaler. Exempel: LDAPU1:(dgst={cert!sha256}) {subject_dn_component[(.attr_name|[number]]} Denna mall kommer lagga till ett av komponentens attributvarden fran subjekt-DN, som standard vardet pa den mest specifika komponenten. En annan komponent kan antingen valjas via attributnamnet, t.ex. {subject_dn_component.uid} eller via position, t.ex. {subject_dn_component.[2]} dar positiva tal borjar raknas fran den mest specifika komponenten och negativa tal borjar rakna fran den minst specifika komponenten Attributnamn och positionen kan kombineras, t.ex. {subject_dn_component.uid[2]} vilket betyder att namnet pa den andra komponenten maste vara "uid". Exempel: LDAPU1:(uid={subject_dn_component.uid}) {issuer_dn_component[(.attr_namn|[tal]]} Denna mall kommer lagga till ett av komponentens attributvarden fran utgivar-DN, som standard vardet pa den mest specifika komponenten. Se "subject_dn_component" for detaljer om attributnamn och positionsangivelser. Exempel: LDAPU1:(domain={issuer_dn_component.[-2]}.{issuer_dn_component.dc[-1]}) {sid[.rid]} Denna mall kommer lagga till SID:n om den motsvarande utokningen introducerad av Microsoft med OID 1.3.6.1.4.1.311.25.2 ar tillganglig. Med selektorn ".rid" kommer endast den sista komponenten, d.v.s RID:n, att laggas till. Exempel: LDAPU1:(objectsid={sid}) DOMANLISTA Om domanlistan inte ar tom soks anvandare mappade till ett givet certifikat inte bara i den lokala domanen utan i de listade domanerna ocksa forutsatt att de ar kanda av SSSD. Domaner som SSSD inte kanner till kommer ignoreras. AUTHORS SSSD uppstroms - https://github.com/SSSD/sssd/ SSSD 05/17/2024 SSS-CERTMAP(5)