table of contents
SSS-CERTMAP(5) | Filformat och konventioner | SSS-CERTMAP(5) |
NAME¶
sss-certmap - SSSD:s certifikatmatchnings- och -mappningsregler
BESKRIVNING¶
Manualsidan beskriver reglerna som kan användas av SSSD och andra komponenter för att matcha X.509-certifikat och koppla dem till konton.
Varje regel har fyra komponenter, en “prioritet”, en “matchningsregel”, en “mappningsregel” och en “domänlista”. Alla komponenter är frivilliga. En saknad “prioritet” kommer lägga till regel med den lägsta prioriteten. Standard-“matchningsregeln” kommer matcha certifikat med digitalSignature-nyckelanvändning och clientAuth-utökadnyckelanvändning. Om “mappningsregeln” är tom kommer certifikaten sökas efter i attrubutet userCertificate som DER-kodade binärer. Om inga domäner anges kommer endast den lokala domänen sökas.
REGELKOMPONENTER¶
PRIORITET¶
Reglerna bearbetas i prioritetsordning där ”0” (noll) indikerar den högsta prioriteten. Ju högre talet är desto lägre är prioriteten. Ett saknat värde indikerar den lägsta prioriteten. Regelbearbetningen stoppas när en regel som matchar hittas och inga ytterligare regler kontrolleras.
Internt behandlas prioriteten som teckenlösa 32-bitars heltal, att använda ett prioritetsvärde större än 4294967295 kommer orsaka ett fel.
MATCHNINGSREGEL¶
Matchningsregeln används för att välja ett certifikat som översättningsregeln skall tillämpas på. Det använder ett system liknande det som används av alternativet “pkinit_cert_match” i MIT Kerberos. Det består av ett nyckelord omgivet av ”<” och ”>” som identifierar en specifik del av certifikatet och ett mönster som skall finnas för att regeln skall matcha. Flera nyckelord/mönster-par kan antingen sammanfogas med ”&&” (och) eller ”||” (eller).
De tillgängliga alternativen är:
<SUBJECT>reguljärt-uttryck
För matchningen konverteras subject-namnet lagrat i certifikatet i DER-kodad ASN.1 till en sträng i enlighet med RFC 4514. Detta betyder att den mest specifika namnkomponenten kommer först. Observera att inte alla möjliga attributnamn täcks av RFC 4514. De inkluderade namnen är ”CN”, ”L”, ”ST”, ”O”, ”OU”, ”C”, ”STREET”, ”DC” och ”UID”.
Exempel: <SUBJECT>.*,DC=MIN,DC=DOMÄN
<ISSUER>reguljärt-uttryck
Exempel: <ISSUER>^CN=Min-CA,DC=MIN,DC=DOMÄN$
<KU>nyckelanvändning
Ett numeriskt värde i intervallet hos ett 32-bitars teckenlöst heltal kan användas också för att täcka speciella användningsfall.
Exempel: <KU>digitalSignature,keyEncipherment
<EKU>utökad-nyckel-användning
Användningar av utökade nycklar som inte listas ovanför kan specificeras med sina OID:er i punktad decimal notation.
Exempel: <EKU>clientAuth,1.3.6.1.5.2.3.4
<SAN>reguljärt-uttryck
Exempel: <SAN>.*@MITT\.RIKE
<SAN:Principal>reguljärt-uttryck
Exempel: <SAN:Principal>.*@MITT\.RIKE
<SAN:ntPrincipalName>reguljärt-uttryck
Exempel: <SAN:ntPrincipalName>.*@MITT.AD.RIKE
<SAN:pkinit>reguljärt-uttryck
Exempel: <SAN:ntPrincipalName>.*@MITT\.PKINIT\.RIKE
<SAN:dotted-decimal-oid>reguljärt-uttryck
Exempel: <SAN:1.2.3.4>test
<SAN:otherName>base64-sträng
Exempel: <SAN:otherName>MTIz
<SAN:rfc822Name>reguljärt-uttryck
Exempel: <SAN:rfc822Name>.*@epost\.domän
<SAN:dNSName>reguljärt-uttryck
Exempel: <SAN:dNSName>.*\.min\.dns\.domän
<SAN:x400Address>base64-sträng
Exempel: <SAN:x400Address>MTIz
<SAN:directoryName>reguljärt-uttryck
Exempel: <SAN:directoryName>.*,DC=com
<SAN:ediPartyName>base64-sträng
Exempel: <SAN:ediPartyName>MTIz
<SAN:uniformResourceIdentifier>reguljärt-uttryck
Exempel: <SAN:uniformResourceIdentifier>URN:.*
<SAN:iPAddress>reguljärt-uttryck
Exempel: <SAN:iPAddress>192\.168\..*
<SAN:registeredID>reguljärt-uttryck
Exempel: <SAN:registeredID>1\.2\.3\..*
MAPPNINGSREGEL¶
Mappningsregeln används för att koppla ett certifikat med ett eller flera konton. Ett smartkort med certifik och den matchande privata nyckeln kan då användas för autentisering som ett av dessa konton.
För närvarande stödjer SSSD egentligen bara LDAP för att slå upp användarinformation (undantaget är proxy-leverantören som inte är relevant här. På grund av detta är mappningsregeln baserad på syntaxen för LDAP-sökfilter med mallar för att lägga till certifikatinnehåll till filtret. Det antas att filtret endast kommer innehålla de specifika data som behövs för mappningen och att anroparen kommer bädda in dem i ett annat filter för att göra den egentliga sökningen. Därför skall filtersträngen börja och sluta med ”(” respektive ”)”.
I allmänhet rekommenderas det att använda attribut från certifikatet och lägga till dem till speciella attribut till LDAP-användarobjektet. T.ex. kan attributet ”altSecurityIdentities” i AD eller attributet ”ipaCertMapData” i IPA användas.
Detta bör hellre användas än att läsa användarspecifik data från certifikatet som t.ex. en e-postadress och söka efter den i LDAP-servern. Anledningen är att användarspecifika data i LDAP kan ändras av olika anledningar vilket skulle göra sönder mappningen. Å andra sidan skulle det vara svårt att bryta mappningen avsiktligt för en specifik användare.
Mallarna för att lägga till certifikatdata till sökfiltret baseras på formateringssträngar i Python-stil. De består av ett nyckelord i krullparenteser med en valfri underkomponentspecificerare separerad av en ”.” eller ett valfri konverterings-/formateringsalternativ separerat av ett ”!”. Tillåtna värden är:
{issuer_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}
Konverteringsalternativen som börjar med ”ad_” kommer använda attribut som de används av AD, t.ex. ”S” istället för ”ST”.
Konverteringsalternativen som börjar med ”nss_” kommer använda attributnamn som de används av NSS.
Standard för konverteringsalternativ är ”nss”, d.v.s. attributnamn enligt NSS och LDAP/RFC 4514-ordning.
Exempel: (ipacertmapdata=X509:<I>{issuer_dn!ad}<S>{subject_dn!ad})
{subject_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}
Konverteringsalternativen som börjar med ”ad_” kommer använda attribut som de används av AD, t.ex. ”S” istället för ”ST”.
Konverteringsalternativen som börjar med ”nss_” kommer använda attributnamn som de används av NSS.
Standard för konverteringsalternativ är ”nss”, d.v.s. attributnamn enligt NSS och LDAP/RFC 4514-ordning.
Exempel: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
{cert[!(bin|base64)]}
Exempel: (userCertificate;binary={cert!bin})
{subject_principal[.short_name]}
Exempel: (|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name}))
{subject_pkinit_principal[.short_name]}
Exempel: (|(userPrincipal={subject_pkinit_principal})(uid={subject_pkinit_principal.short_name}))
{subject_nt_principal[.short_name]}
Exempel: (|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name}))
{subject_rfc822_name[.short_name]}
Exempel: (|(mail={subject_rfc822_name})(uid={subject_rfc822_name.short_name}))
{subject_dns_name[.short_name]}
Exempel: (|(fqdn={subject_dns_name})(host={subject_dns_name.short_name}))
{subject_uri}
Exempel: (uri={subject_uri})
{subject_ip_address}
Exempel: (ip={subject_ip_address})
{subject_x400_address}
Exempel: (attr:binary={subject_x400_address})
{subject_directory_name[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}
Exempel: (orig_dn={subject_directory_name})
{subject_ediparty_name}
Exempel: (attr:binary={subject_ediparty_name})
{subject_registered_id}
Exempel: (oid={subject_registered_id})
DOMÄNLISTA¶
Om domänlistan inte är tom söks inte användare mappade till ett givet certifikat bara i den lokala domänen utan i de listade domänerna också förutsatt att de är kända av SSSD. Domäner som SSSD inte känner till kommer ignoreras.
AUTHORS¶
SSSD uppströms – https://pagure.io/SSSD/sssd/
01/23/2024 | SSSD |