SSSD-AD(5)

NAME
sssd-ad - SSSD Active Directory-leverantör

BESKRIVNING

Denna manualsida beskriver konfigurationen av leverantören AD till sssd(8). För en detaljerad referens om syntaxen, se avsnittet “FILFORMAT” i manualsidan sssd.conf(5).

Leverantören AD är en bakände som används för att ansluta till en Active Directory-server. Leverantören kräver att maskinen läggs in i AD-domänen och att en keytab är tillgänglig. Bakändekommunikationen sker över en GSSAPI-krypterad kanal, SSL/TLS-alternativ skall inte användas tillsammans med AD-leverantören och kommer ersättas av Kerberos-användning.

AD-leverantören stödjer anslutning till Active Directory 2008 R2 eller senare. Tidigare versioner kan fungera, men stödjs inte.

AD-leverantören kan användas för att få användarinformation och autentisera användare från betrodda domäner. För närvarande känns endast betrodda domäner i samma skog igen. Dessutom automatupptäcks alltid servrar från betrodda domäner.

AD-leverantören gör att SSSD kan använda identitetsleverantören sssd-ldap(5) och autentiseringsleverantören sssd-krb5(5) med optimeringar för Active Directory-miljöer. AD-leverantören tar samma alternativ som används av leverantörerna sssd-ldap och sssd-krb5 med några undantag. Dock är det varken nödvändigt eller lämpligt att sätta dessa alternativ.

AD-leverantören kopierar i huvudsak standardalternativen för de traditionella leverantörerna ldap och krb5 med några undantag. Skillnaderna listas i avsnittet “ÄNDRADE STANDARDINSTÄLLNINGAR”.

AD-leverantören kan även användas som en åtkomst-, chpass-, sudo- och autofs-leverantör. Ingen konfiguration av åtkomstleverantören behövs på klientsidan.

Om “auth_provider=ad” eller “access_provider=ad” konfigureras i sssd.conf måste id-leverantören också sättas till “ad”.

Som standard kommer AD-leverantören översätta AID- och GID-värden från parametern objectSID i Active Directory. För detaljer om detta se avsnittet “ID-ÖVERSÄTTNING” nedan. Om du vill avaktivera ID-översättning och istället lita på POSIX-attribut definierade i Active Directory skall du sätta

    ldap_id_mapping = False

. Om POSIX-attribut skall användas rekommenderas det av prestandaskäl att attributen även replikeras till den globala katalogen. Om POSIX-attribut replikeras kommer SSSD försöka att hitta domänen för den begärda numeriska ID:n med hjälp av den globala katalogen och endast söka i den domänen. Om POSIX-attribut däremot inte replikeras till den globala katalogen måste SSSD söka i alla domänerna i skogen sekventiellt. Observera att alternativet “cache_first” också kan vara till hjälp för att snabba upp domänlösa sökningar. Observera att om endast en delmängd av POSIX-attributen finns i den globala katalogen läses för närvarande inte de attribut som inte replikeras från LDAP-porten.

Användare, grupper och andra enheter som servas av SSSD behandlas alltid som skiftlägesokänsliga i AD-leverantören för kompatibilitet med Active Directorys LDAP-implementation.

SSSD slår endast up Active Directory Security Groups. För mer information om AD-grupptyper se: Active Directory security grouips[1]

SSSD filtrerar ut domänlokala grupper från fjärrdomäner i AD-skogen. Som standard filtreras de ut t.ex. när man följer en nästad grupphierarki i fjärrdomäner för att de inte är giltiga i den lokala domänen. Detta görs för att stämma med Active Directorys gruppmedlemskapstilldelning vilken kan ses i Kerberosbiljettens PAC för en användare utgiven av Active Directory.

KONFIGURATIONSALTERNATIV

Se “DOMÄNSEKTIONER” i manualsidan sssd.conf(5) för detaljer om konfigurationen av en SSSD-domän.

ad_domain (sträng)
    Anger namnet på Active Directory-domänen. Detta är frivilligt. Om det inte anges används namnet på den konfigurerade domänen.

    För att fungera ordentligt skall detta alternativ anges som den gemena versionen av den långa versionen av Active Directorys domän.

    Det korta domännamnet (även känt som NetBIOS-namnet eller det platta namnet) detekteras automatiskt av SSSD.

ad_enabled_domains (sträng)
    En kommaseparerad lista av aktiverade Active Directory-domäner. Om det tillhandahålls kommer SSSD ignorera eventuella domäner som inte räknas upp i detta alternativ. Om det lämnas osatt kommer alla upptäckta domäner från AD-skogen vara tillgängliga.

    När den letar efter domänerna kommer SSSD filtrera ut några domäner vars flaggor eller attribut indikerar att de inte tillhör den lokala skogen eller inte är betrodda. Om ad_enabled_domains är satt kommer SSSD försöka aktivera alla listade domäner.

    För att fungera ordentligt bör detta alternativ anges helt i gemener och som det fullständigt kvalificerade namnet på Active Directory-domänen. Till exempel:

        ad_enabled_domains = marknad.exempel.se, tekn.exempel.se

    Det korta domännamnet (även känt som NetBIOS-namnet eller det platta namnet) kommer detekteras automatiskt av SSSD.

    Standard: inte satt

ad_server, ad_backup_server (sträng)
    Den kommaseparerade listan av värdnamn till AD-servrar till vilka SSSD skall ansluta i prioritetsordning. För mer information om reserver och serverredundans se avsnittet “RESERVER”.

    Detta är frivilligt om automatupptäckt är aktiverat. För mer information om tjänsteupptäckt se avsnittet “TJÄNSTEUPPTÄCKT”.

    Observera: betrodda domäner kommer alltid automatiskt upptäcka servrar även om den primära servern definieras uttryckligen i alternativet ad_server.

ad_hostname (sträng)
    Valfri. På maskiner där hostname(5) inte avspeglar det fullständigt kvalificerade namnet kommer sssd försöka expandera det korta namnet. Om det inte är möjligt eller det korta namnet verkligen skall användas istället, sätt då denna parameter uttryckligen.

    Detta fält används för att avgöra värd-huvudmannen som används i keytab:en och utföra dynamiska DNS-uppdateringar. Det måste stämma med värdnamnet som keytab:en gavs ut för.

ad_enable_dns_sites (boolean)
    Aktiverar DNS-sajter – platsbaserat tjänsteupptäckt.

    Om sant och tjänsteupptäckt (se stycket Tjänsteupptäckt i slutet av manualsidan) är aktiverat kommer SSSD först att försöka hitta en Active Directory-server att ansluta till med Active Directory Site Discovery och sedan falla tillbaka på traditionell SRV-upptäckt om ingen AD-sajt hittas. Konfigurationen av DNS SRV, inklusive upptäcktsdomänen, används också under sajtupptäckten.

    Standard: true

ad_access_filter (sträng)
    Anger et filter för LDAP-åtkomstkontroll som en användare måste matcha för att få åtkomst. Alternativet “access_provider” måste vara uttryckligen satt till “ad” för att detta alternativ skall ha någon verkan. Om man vill använda “ad_access_filter” som det enda åtkomstkontrollschemat måste man avaktivera GPO-baserad åtkomstkontroll (se alternativet “ad_gpo_access_control” för detaljer).

    Alternativet stödjer också att ange olika filter per domän eller skog. Detta utökade filter skulle bestå av: “NYCKELORD:NAMN:FILTER”. Nyckelordet kan vara antingen “DOM”, “FOREST” eller utelämnas.

    Om nyckelordet är lika med “DOM” eller saknas anger “NAMN” domänen eller underdomänen filtret gäller för. Om nyckelordet är lika med “FOREST” är filtret lika för alla domäner från skogen som anges av “NAMN”.

    Flera filter kan avgränsas med tecknet “?”, i likhet med hur sökbaser fungerar.

    Nästade gruppmedlemskap måste sökas efter med en speciell OID “:1.2.840.113556.1.4.1941:” utöver den fullständiga syntaxen DOM:domän.exempel.se: för att säkerställa att tolken inte försöker tolka kolontecknen som hör till OID:n. Om man inte använder denna OID kommer nästade gruppmedlemskap inte slås upp. Se användningsexempel nedan och se här för ytterligare information om OID:n: [MS-ADTS] avsnittet LDAP-utökningar[2]

    Den mest specifika matchningen används alltid. Till exempel, om alternativet angav filter för en domän användaren är medlem i och ett globalt filter skulle det domänspecifika filtret tillämpas. Om det finns fler matchningar med samma specifikation används den första.

    Exempel:

        # tillämpa endast filtret på en domän som heter dom1:
        dom1:(memberOf=cn=admins,ou=groups,dc=dom1,dc=com)
        # tillämpa endast filtret på en domän som heter dom2:
        DOM:dom2:(memberOf=cn=admins,ou=groups,dc=dom2,dc=com)
        # tillämpa endast filtret på en skog som heter EXEMPEL.COM:
        FOREST:EXEMPEL.COM:(memberOf=cn=admins,ou=groups,dc=example,dc=com)
        # tillämpa filtret på en medlem av en nästad grupp i dom1:
        DOM:dom1:(memberOf:1.2.840.113556.1.4.1941:=cn=nestedgroup,ou=groups,dc=example,dc=com)

    Standard: inte satt

ad_site (sträng)
    Ange en AD-sajt som klienten skall försöka ansluta till. Om detta alternativ inte anges kommer AD-sajten att automatupptäckas.

    Standard: inte satt

ad_enable_gc (boolean)
    Som standard ansluter SSSD till den globala katalogen först för att hämta användare från betrodda domäner och använder LDAP-porten för att hämta gruppmedlemskap som en reserv. Att avaktivera detta alternativ gör att SSSD endast ansluter till LDAP-porten på den aktuella AD-servern.

    Observera att att avaktivera stöd för den globala katalogen inte avaktiverar att hämta användare från betrodda domäner. SSSD skulle ansluta till LDAP-porten på den betrodda domänen istället. Dock måste den globala katalogen användas för att slå upp gruppmedlemskap över domäner.

    Standard: true

ad_gpo_access_control (sträng)
    Detta alternativ anger arbetsläget för GPO-baserad åtkomstkontrollsfunktionalitet: huruvida det arbetar i avaktiverat läge, tvingande läge eller tillåtande läge. Observera att alternativet “access_provider” måste vara uttryckligen satt till “ad” för att detta alternativ skall ha någon effekt.

    Funktionalitet för GPO-baserad åtkomststyrning använder GPO-policyinställningar för att avgöra huruvida en viss användare tillåts logga in på värden eller inte. För mer information om de stödda policyinställningarna se flaggan “ad_gpo_map”.

    Observera att den aktuella versionen av SSSD inte stöjder Active Directorys inbyggda grupper. Inbyggda grupper (såsom administratörer med SID S-1-5-32-544) i GPO-åtkomststyrningsregler kommer ignoreras av SSSD. Se uppströms ärendehanterare https://github.com/SSSD/sssd/issues/5063 .

    Före åtkomstkontroll utförs tillämpar SSSD säkerhetsfiltrering enligt gruppolicy på GPO:erna. För varje enskild användares inloggning kontrolleras tillämpligheten av GPO:erna som är länkade till värden. För att en GPO skall vara tillämplig på en användare måste användaren eller åtminstone en av de grupper den tillhör ha följande rättigheter på GPO:n:

        • Läs: användaren eller en av dess grupper måste ha läsrättigheter till egenskaperna hos GPO:n (RIGHT_DS_READ_PROPERTY)

        • Verkställ gruppolicy: användaren eller åtminstone en av dess grupper måste ha tillåtelse att verkställa GPO:n (RIGHT_DS_CONTROL_ACCESS).

    Som standard fins en autentiserad användares grupp på en GPO och denna grupp har både Läs- och Verkställ gruppolicy-åtkomsträttigheter. Eftersom autentisering av en användare måste ha fullgjorts framgångsrikt före GPO-säkerhetsfiltrering och åtkomstkontroll börjar gäller alltid även den autentiserade användarens grupprättigheter på GPO:n för användaren.

    OBS: Om åtgärdsläget är satt till tvingande är det möjligt att användarna som tidigare var tillåtna inloggningsåtkomst nu kommer nekast inloggningsåtkomst (som det dikteras av GPO-policyinställningar). För att möjliggöra en smidig övergång för administratörer finns ett tillåtande läge tillgängligt som inte kommer genomdriva åtkomststyrningsreglerna, utan kommer beräkna deom och skriva ut ett syslog-meddelande om åtkomst skulle ha nekats. Genom att granska loggarna kan administratörer sedan göra de nödvändiga ändringarna före läget ställs in som tvingande. För att logga felsökningsnivå av GPO-baserad åtkomstkontroll krävs ”trace functions” (se manualsidan sssctl(8)).

    Det finns tre stödda värden för detta alternativ:

        • disabled: GPO-baserade åtkomstkontrollsregler varken evalueras eller påtvingas.

        • enforcing: GPO-baserade åtkomstkontrollregler evalueras och påtvingas.

        • permissive: GPO-baserade åtkomstkontrollregler evalueras men påtvingas inte. Istället skickas ett syslog-meddelande ut som indikerar att användaren skulle ha nekats åtkomst om detta alternativs värde vore satt till enforcing.

    Standard: enforcing

ad_gpo_implicit_deny (boolean)
    Normalt när inga tillämpliga GPO:er finns tillåts användarna åtkomst. När detta alternativ är satt till True kommer användare att tillåtas åtkomst endast när det uttryckligen tillåts av en GPO-regel. Annars kommer användare nekas åtkomst. Detta kan användas för att stärka säkerheten men var försiktig när detta alternativ används för det kan neka åtkomst även till användare i den inbyggda administratörsgruppen om inga GPO-regler är tillämpliga på dem.

    Standard: False

    Följande 2 tabeller bör illustrera när en användare tillåts eller nekas baserat på de tillåtande eller nekande inloggningsrättigheterna definierade på serversidan och inställningen av ad_gpo_implicit_deny.
    ad_gpo_implicit_deny = False (standard)
    tillåtelseregler | nekanderegler | resultat
    saknas | saknas | alla användare tillåts
    saknas | finns | endast användare som inte finns i nekanderegler tillåts
    finns | saknas | endast användare i tillåtelseregler tillåts
    finns | finns | endast användare i tillåtelse och inte i nekanderegler tillåts

    ad_gpo_implicit_deny = True
    tillåtelseregler | nekanderegler | resultat
    saknas | saknas | inga användare tillåts
    saknas | finns | inga användare tillåts
    finns | saknas | endast användare i tillåtelseregler tillåts
    finns | finns | endast användare i tillåtelse och inte i nekanderegler tillåts

ad_gpo_ignore_unreadable (boolean)
    Normalt när några gruppolicybehållare (AD-objekt) av några tillämpliga gruppolicyobjekt inte är läsbara av SSSD så nekas användare åtkomst. Detta alternativ tillåter att man ignorerar gruppolicybehållare och med dem tillhörande policyer om deras attribut i gruppolicybehållare inte är läsbara för SSSD.

    Standard: False

ad_gpo_cache_timeout (heltal)
    Tiden mellan uppslagningar av GPO-policyfiler mot AD-servern. Detta kommer reducera tidsfördröjningen och lasten på AD-servern om det görs många begäranden om åtkomstkontroll under en kort tid.

    Standard: 5 (sekunder)

ad_gpo_map_interactive (sträng)
    En kommaseparerad lista av PAM-tjänstenamn för vilka GPO-baserad åtkomstkontroll beräknas baserat på policyinställningarna InteractiveLogonRight och DenyInteractiveLogonRight. Endast de GPO:er beräknas för vilka användaren har Läs- eller Verkställ gruppolicy-rättigheter (se flaggan “ad_gpo_access_control”). Om en beräknad GPO innehåller inställningen neka interaktiv inloggning för användaren eller en av dess grupper nekas användaren lokal åtkomst. Om ingen av de evaluerade GPO:erna har en interaktiv inloggningsrättighet definierad ges användaren lokal åtkomst. Om åtminstone en beräknad GPO innehåller inställningen interaktiv inloggningsrättighet ges användaren lokal åtkomst endast om denne eller åtminstone en av dess grupper är del av den policyinställningen.

    Obs: när man använder gruppolicyhanteringsredigeraren kallas detta värde ”Tillåt inloggning lokalt” och ”Neka inloggning lokalt”.

    Det är möjligt att lägga till ett annat PAM-tjänstenamn till standarduppsättningen genom att använda “+tjänstenamn” eller att uttryckligen ta bort ett PAM-tjänstenamn från standarduppsättningen genom att använda “-tjänstenamn”. Till exempel, för att byta ut ett standard-PAM-tjänstenamn för denna inloggningsrätt (t.ex. “login”) mot ett anpassat PAM-tjänstenamn (t.ex. “min_pam-tjänst”) skulle man använda följande konfiguration:

        ad_gpo_map_interactive = +min_pam-tjänst, -login

    Standard: standarduppsättningen av PAM-tjänstenamn innefattar:

        • login

        • su

        • su-l

        • gdm-fingerprint

        • gdm-password

        • gdm-smartcard

        • kdm

        • lightdm

        • lxdm

        • plasmalogin

        • sddm

        • unity

        • xdm

ad_gpo_map_remote_interactive (sträng)
    En kommaseparerad lista av PAM-tjänstenamn för vilka GPO-baserad åtkomstkontroll beräknas baserat på policyinställningarna RemoteInteractiveLogonRight och DenyRemoteInteractiveLogonRight. Endast de GPO:er beräknas för vilka användaren har Läs- eller Verkställ gruppolicy-rättigheter (se flaggan “ad_gpo_access_control”). Om en beräknad GPO innehåller inställningen neka fjärrinloggning för användaren eller en av dess grupper nekas användaren interaktiv fjärråtkomst. Om ingen av de evaluerade GPO:erna har en interaktiv inloggningsrättighet definierad ges användaren interaktiv fjärråtkomst. Om åtminstone en beräknad GPO innehåller inställningen interaktiv fjärrinloggningsrättighet ges användaren fjärråtkomst endast om denne eller åtminstone en av dess grupper är del av den policyinställningen.

    Obs: när man använder gruppolicyhanteringsredigeraren kallas detta värde ”Tillåt inloggning via fjärrskrivbordstjänster” och ”Neka inloggning via fjärrinloggningstjänster”.

    Det är möjligt att lägga till ett annat PAM-tjänstenamn till standarduppsättningen genom att använda “+tjänstenamn” eller att uttryckligen ta bort ett PAM-tjänstenamn från standarduppsättningen genom att använda “-tjänstenamn”. Till exempel, för att byta ut ett standard-PAM-tjänstenamn för denna inloggningsrätt (t.ex. “sshd”) mot ett anpassat PAM-tjänstenamn (t.ex. “min_pam-tjänst”) skulle man använda följande konfiguration:

        ad_gpo_map_remote_interactive = +min_pam-tjänst, -sshd

    Standard: standarduppsättningen av PAM-tjänstenamn innefattar:

        • sshd

        • cockpit

ad_gpo_map_network (sträng)
    En kommaseparerad lista av PAM-tjänstenamn för vilka GPO-baserad åtkomstkontroll beräknas baserat på policyinställningarna NetworkLogonRight och DenyNetworkLogonRight. Endast de GPO:er beräknas för vilka användaren har Läs- eller Verkställ gruppolicy-rättigheter (se flaggan “ad_gpo_access_control”). Om en beräknad GPO innehåller inställningen neka nätverksinloggning för användaren eller en av dess grupper nekas användaren nätverksåtkomst. Om ingen av de evaluerade GPO:erna har en nätverksinloggningsrättighet definierad ges användaren inloggningsåtkomst. Om åtminstone en beräknad GPO innehåller inställningen nätverksinloggningsrättighet ges användaren inloggningsåtkomst endast om denne eller åtminstone en av dess grupper är del av den policyinställningen.

    Obs: när man använder gruppolicyhanteringsredigeraren kallas detta värde ”Kom åt denna dator från nätverket” och ”Neka åtkomst till denna dator från nätverket”.

    Det är möjligt att lägga till ett annat PAM-tjänstenamn till standarduppsättningen genom att använda “+tjänstenamn” eller att uttryckligen ta bort ett PAM-tjänstenamn från standarduppsättningen genom att använda “-tjänstenamn”. Till exempel, för att byta ut ett standard-PAM-tjänstenamn för denna inloggningsrätt (t.ex. “ftp”) mot ett anpassat PAM-tjänstenamn (t.ex. “min_pam-tjänst”) skulle man använda följande konfiguration:

        ad_gpo_map_network = +min_pam-tjänst, -ftp

    Standard: standarduppsättningen av PAM-tjänstenamn innefattar:

        • ftp

        • samba

ad_gpo_map_batch (sträng)
    En kommaseparerad lista av PAM-tjänstenamn för vilka GPO-baserad åtkomstkontroll beräknas baserat på policyinställningarna BatchLogonRight och DenyBatchLogonRight. Endast de GPO:er beräknas för vilka användaren har Läs- eller Verkställ gruppolicy-rättigheter (se flaggan “ad_gpo_access_control”). Om en beräknad GPO innehåller inställningen neka satsvis inloggning för användaren eller en av dess grupper nekas användaren satsvis inloggningsåtkomst. Om ingen av de evaluerade GPO:erna har en satsvis inloggningsrättighet definierad ges användaren inloggningsåtkomst. Om åtminstone en beräknad GPO innehåller inställningen satsvis inloggningsrättighet ges användaren inloggningsåtkomst endast om denne eller åtminstone en av dess grupper är del av den policyinställningen.

    Obs: när man använder gruppolicyhanteringsredigeraren kallas detta värde ”Tillåt inloggning som ett batch-jobb” och ”Neka inloggning som ett batch-jobb”.

    Det är möjligt att lägga till ett annat PAM-tjänstenamn till standarduppsättningen genom att använda “+tjänstenamn” eller att uttryckligen ta bort ett PAM-tjänstenamn från standarduppsättningen genom att använda “-tjänstenamn”. Till exempel, för att byta ut ett standard-PAM-tjänstenamn för denna inloggningsrätt (t.ex. “crond”) mot ett anpassat PAM-tjänstenamn (t.ex. “min_pam-tjänst”) skulle man använda följande konfiguration:

        ad_gpo_map_batch = +min_pam-tjänst, -crond

    Obs: cron-tjänstenamn kan skilja beroende på vilken Linuxdistribution som används.

    Standard: standarduppsättningen av PAM-tjänstenamn innefattar:

        • crond

ad_gpo_map_service (sträng)
    En kommaseparerad lista av PAM-tjänstenamn för vilka GPO-baserad åtkomstkontroll beräknas baserat på policyinställningarna ServiceLogonRight och DenyServiceLogonRight. Endast de GPO:er beräknas för vilka användaren har Läs- eller Verkställ gruppolicy-rättigheter (se flaggan “ad_gpo_access_control”). Om en beräknad GPO innehåller inställningen neka tjänsteinloggning för användaren eller en av dess grupper nekas användaren tjänsteinloggningsåtkomst. Om ingen av de evaluerade GPO:erna har en tjänsteinloggningsrättighet definierad ges användaren inloggningsåtkomst. Om åtminstone en beräknad GPO innehåller inställningen tjänsteinloggningsrättighet ges användaren inloggningsåtkomst endast om denne eller åtminstone en av dess grupper är del av den policyinställningen.

    Obs: när man använder gruppolicyhanteringsredigeraren kallas detta värde ”Tillåt inloggning som en tjänst” och ”Neka inloggning som en tjänst”.

    Det är möjligt att lägga till ett PAM-tjänstenamn till standarduppsättningen genom att använda “+tjänstenamn”. Eftersom standarduppsättningen är tom är det inte möjligt att ta bort ett PAM-tjänstenamn från standarduppsättningen. Till exempel, för att lägga till ett anpassat PAM-tjänstenamn (t.ex. “min_pam-tjänst”) skulle man använda följande konfiguration:

        ad_gpo_map_service = +min_pam-tjänst

    Standard: inte satt

ad_gpo_map_permit (sträng)
    En kommaseparerad lista av PAM-tjänstenamn för vilka GPO-baserad åtkomst alltid tillåts, oavsett några andra GPO-inloggningsrättigheter.

    Det är möjligt att lägga till ett annat PAM-tjänstenamn till standarduppsättningen genom att använda “+tjänstenamn” eller att uttryckligen ta bort ett PAM-tjänstenamn från standarduppsättningen genom att använda “-tjänstenamn”. Till exempel, för att byta ut ett standard-PAM-tjänstenamn för ovillkorligt tillåten åtkomst (t.ex. “sudo”) mot ett anpassat PAM-tjänstenamn (t.ex. “min_pam-tjänst”) skulle man använda följande konfiguration:

        ad_gpo_map_permit = +min_pam-tjänst, -sudo

    Standard: standarduppsättningen av PAM-tjänstenamn innefattar:

        • polkit-1

        • sudo

        • sudo-i

        • systemd-user

ad_gpo_map_deny (sträng)
    En kommaseparerad lista av PAM-tjänstenamn för vilka GPO-baserad åtkomst alltid nekas, oavsett några andra GPO-inloggningsrättigheter.

    Det är möjligt att lägga till ett PAM-tjänstenamn till standarduppsättningen genom att använda “+tjänstenamn”. Eftersom standarduppsättningen är tom är det inte möjligt att ta bort ett PAM-tjänstenamn från standarduppsättningen. Till exempel, för att lägga till ett anpassat PAM-tjänstenamn (t.ex. “min_pam-tjänst”) skulle man använda följande konfiguration:

        ad_gpo_map_deny = +min_pam-tjänst

    Standard: inte satt

ad_gpo_default_right (sträng)
    Detta alternativ definierar hur åtkomstkontroll beräknas för PAM-tjänstenamn som inte är uttryckligen listade i en av alternativen ad_gpo_map_*. Detta alternativ kan anges på två olika sätt. Antingen kan detta alternativ sättas till att ange standardinloggningsrättigheter. Till exempel, om detta alternativ är satt till ”interactive” betyder det att omappade PAM-tjänstenamn kommer bearbetas baserat på policyinställningarna InteractiveLogonRight och DenyInteractiveLogonRight. Alternativt kan detta alternativ sättas till att antingen alltid tillåta eller alltid neka åtkomst för omappade PAM-tjänstenamn.

    Värden som stödjs för detta alternativ inkluderar:

        • interactive

        • remote_interactive

        • network

        • batch

        • service

        • permit

        • deny

    Standard: deny

ad_maximum_machine_account_password_age (heltal)
    SSSD kommer en gång om dagen kontrollera om maskinkontolösenordet är äldre än den givna åldern i dagar och försöka förnya det. Ett värde på 0 kommer förhindra förnyelseförsöket.

    Standard: 30 dagar

ad_machine_account_password_renewal_opts (sträng)
    Det här alternativet ska endast användas för att testa uppgiften för förnyelse av maskinkonto. Alternativet förväntar sig tre heltal och en sträng separerade med kolon (':'). Det första heltalet definierar intervallet i sekunder för hur ofta uppgiften ska köras. Det andra anger den initiala tidsgränsen i sekunder innan uppgiften körs för första gången efter start. Det valfria tredje värdet anger en maximal slumpmässig förskjutning från de två föregående värdena för att undvika uppdateringar av många värdar samtidigt ("thundering herd-problemet"). Om detta värde saknas eller är tomt i värdesträngen används '0'.

    Det valfria fjärde strängvärdet identifierar hjälpprogrammet som ska användas för förnyelsen. För närvarande stöds adcli och realm. Om detta värde saknas eller är tomt i värdesträngen kommer realm att användas. Eftersom hjälpprogrammet startas som den användare som SSSD körs som kan det hända att förnyelsen misslyckas om denna användare inte har behörighet att ändra keytab-filen där maskinens kontouppgifter lagras. Detta är vanligtvis fallet för adcli.

    realm uppdaterar inte keytab direkt utan anropar realmd-processen, som körs som root-användare, för denna uppgift. realmd kan tillåta åtkomst för icke-privilegierade användare med hjälp av PolicyKit och som standard tillhandahåller SSSD lämpliga regler för den användare som SSSD körs som.

    Standard: 86400:750:300:realm (24h, 12m30s och 5m)

ad_update_samba_machine_account_password (boolean)
    Om aktiverat kommer lösenordet i Sambas databas också uppdateras när SSSD förnyar maskinkontolösenordet. Detta förhindrar Sambas exemplar av maskinkontolösenordet från att bli inaktuellt när det är uppsatt att använda AD för autentisering.

    Standard: false

ad_use_ldaps (bool)
    Som standard använder SSSD den enkla LDAP-porten 389 porten 3628 för den globala katalogen. Om denna flagga är satt till sant kommer SSSD använda LDAPS-porten 636 och porten 3629 för den globala katalogen med LDAPS-skydd. Eftersom AD inte tillåter att ha flera krypteringsnivåer på en ensam förbindelse och vi fortfarande vill använda SASL/GSSAPI eller SASL/GSS-SPNEGO till autentisering är SASL-säkerhetsegenskapen maxssf satt till 0 (noll) för dessa förbindelser.

    Standard: False

dyndns_update (boolean)
    Valfritt. Detta alternativ säger till SSSD att automatiskt uppdatera DNS-servern i Active Directory med IP-adressen för denna klient. Uppdateringen säkras med GSS-TSIG. Som en konsekvens av det behöver Active Directory-administratören bara tillåta säkra uppdateringar för DNS-zonen. IP-adressen för AD-LDAP-förbindelsen används för uppdateringar, om det inte specificeras på annat sätt med alternativet “dyndns_iface”.

    OBS: på äldre system (såsom RHEL 5) måste standardriket för Kerberos sättas i /etc/krb5.conf för att detta beteende skall fungera pålitligt

    Standard: true

dyndns_ttl (heltal)
    TTL:en att använda för klientens DNS-post vid uppdatering. Om dyndns_update är falsk har detta ingen effekt. Detta kommer åsidosätta TTL på serversidan om det är satt av en administratör.

    Standard: 3600 (sekunder)

dyndns_iface (sträng)
    Valfritt. Gäller endast när dyndns_update är sant. Välj gränssnittet eller en lista över gränssnitt vars IP-adresser ska användas för dynamiska DNS-uppdateringar. Namnet på gränssnittet kan vara ett jokerteckenmönster med prefixet ! för gränssnitt som ska exkluderas. Första träffen avbryter utvärderingen. Till exempel list !eth1, * instruerar SSSD att använda alla gränssnitt utom eth1. Se man 7 glob för mer information om mönster.

    OBS: även om det fortfarande är möjligt att använda det gamla alternativet ipa_dyndns_iface bör användare migrera till att använda dyndns_iface i sin konfigurationsfil.

    Standard: använd IP-adresser för gränssnittet som används för AD LDAP-förbindelsen

    Exempel: dyndns_iface = em[12], !vnet1, vnet*

dyndns_address (sträng)
    Valfritt. Gäller endast när dyndns_update är sant. En lista över IP-adresser eller IP-nätverk som ska användas för dynamiska DNS-uppdateringar. Nätverksadresser måste vara i CIDR-format. En post kan prefixeras med ! för att ange undantag. Den bästa matchningen används för att avgöra om en adress ska inkluderas eller exkluderas (dvs. ett längre prefix har företräde).

    Standard: Ingen filtrering av IP-adresser.

    Exempel: dyndns_address = 10.0.0.0/16, !10.0.1.0/24

dyndns_refresh_interval (heltal)
    Hur ofta bakänden skall utföra periodiska DNS-uppdateringar utöver den automatiska uppdateringen som utförs när bakänden kopplar upp. Detta alternativ är valfritt och tillämpligt endast när dyndns_update är sann. Observera att det lägsta möjliga värdet är 60 sekunder, ifall ett värde mindre än 60 ges kommer parametern endast anta det lägsta värdet.

    Standard: 86400 (24 timmar)

dyndns_update_ptr (bool)
    Huruvida PTR-posten också skall uppdateras explicit när klientens DNS-post uppdateras. Tillämpligt endast när dyndns_update är sann.

    Observera att parametern dyndns_update_per_family inte gäller för uppdateringar av PTR-poster. Dessa uppdateringar skickas alltid separat.

    Standard: True

dyndns_force_tcp (bool)
    Huruvida nsupdate-verktyget som standard skall använda TCP för kommunikation med DNS-servern.

    Standard: False (låt nsupdate välja protokollet)

dyndns_auth (sträng)
    Huruvida verktyget nsupdate skall använda GSS-TSIG-autentisering för säkra uppdateringar av DNS-servern, osäkra uppdateringar kan skickas genom att sätta detta alternativ till ”none”.

    Standard: GSS-TSIG

dyndns_auth_ptr (sträng)
    Huruvida verktyget nsupdate skall använda GSS-TSIG-autentisering för säkra PTR-uppdateringar av DNS-servern, osäkra uppdateringar kan skickas genom att sätta detta alternativ till ”none”.

    Standard: samma som dyndns_auth

dyndns_server (sträng)
    DNS-servern som skall användas när en uppdatering av DNS utförs. I de flesta uppsättningar rekommenderas det att låta detta alternativ vara osatt.

    Det är lämpligt att ställa in detta alternativ i miljöer där DNS-servern skiljer sig från identitetsservern eller när vi använder krypterad DNS.

    Parametern kan vara en enkel sträng som innehåller DNS-namn eller IP-adress. Den kan också vara en URI. URI kan se ut som dns://servernamn/ eller dns+tls://1.2.3.4:853#servernamn/..

    Det andra exemplet aktiverar DNS-over-TLS-protokollet för DNS-uppdateringar. Verktyget nsupdate måste stödja DoT – kontrollera man nsupdate innan du aktiverar det i SSSD.

    Observera att detta alternativ endast kommer att användas som reservlösning när tidigare försök med automatiskt identifierade inställningar misslyckats eller när DNS-over-TLS är aktiverat.

    Standard: Ingen (låt nsupdate välja servern)

dyndns_update_per_family (boolean)
    DNS-uppdateringar utförs som standard i två steg – IPv4-uppdatering och sedan IPv6-uppdatering. I några fall kan det vara önskvärt att utföra IPv4- och IPv6-uppdateringar i ett enda steg.

    Standard: true

dyndns_dot_cacert (sträng)
    Det här alternativet anger filen med certifikatutfärdarnas certifikat (i PEM-format) för att verifiera fjärrserverns TLS-certifikat när DoT används.

    Standard: Ingen (använd globalt certifikatlager)

dyndns_dot_cert (sträng)
    Det här alternativet ställer in certifikatfilen eller certifikatfilerna för autentisering för DoT-transporten till fjärrservern. Certifikatkedjefilen förväntas vara i PEM-format.

    Alternativen dyndns_dot_cert och dyndns_dot_key måste båda vara inställda för att ömsesidig TLS-autentisering ska fungera.

    Standard: Ingen (Använd inte TLS-autentisering)

dyndns_dot_key (sträng)
    Det här alternativet ställer in nyckelfilen för autentiserad kryptering för DoT-transporten till fjärrservern. Den privata nyckelfilen förväntas vara i PEM-format.

    Standard: Ingen (Använd inte TLS-autentisering)

override_homedir (sträng)
    Åsidosätt användarens hemkatalog. Du kan antingen ge ett absolut värde eller en mall. I mallen ersätts följande sekvenser:

    %u
        inloggningsnamn

    %U
        AID-nummer

    %d
        domännamn

    %f
        fullständigt kvalificerat användarnamn (användare@domän)

    %l
        Första bokstaven i inloggningsnamnet.

    %P
        UPN – Användarens Huvudmansnamn (namn@RIKE)

    %o
        Värdet för homedir som definieras i identitetsleverantörens katalog.

        Denna ersättning är avsedd att användas i ett IPA-AD-förtroendescenario. Om denna ersättning används för alternativet subdomain_homedir, sprider den värdet för hemkatalogen från AD-domänen till IPA-klienterna. I detta scenario måste alternativet ställas in i SSSD-konfigurationen på IPA-servern där SSSD körs i serverläge.

    %h
        Den sökväg som definierats för attributet homedir för identitetsleverantören, men med små bokstäver. För mer information om användningen, se %o.

    %H
        Värdet på konfigurationsalternativet homedir_substring.

    %%
        ett bokstavligt ”%”

    Detta alternativ kan även sättas per domän.

    exempel:

        override_homedir = /home/%u

    Standard: Inte satt (SSSD kommer använda värdet som hämtas från LDAP)

    Observera att hemkatalog från ett specifikt åsidosättande för användaren, antingen lokalt (se sss_override(8)) eller centralt hanterat IPA-id-åsidosättande, har en högre precedens och kommer användas istället för värdet gom ges av override_homedir.

homedir_substring (sträng)
    Värdet på detta alternativ kommer användas i expansionen av alternativet override_homedir om mallen innehåller formatsträngen %H. En LDAP-katalogpost kan innehålla denna mall direkt så att detta alternativ kan användas för att expandera sökvägen till hemkatalogen för varje klientmaskin (eller operativsystem). Den kan sättas per domän eller globalt i avsnittet [nss]. Ett värde som anges i ett domänavsnitt kommer åsidosätta ett som är satt i avsnittet [nss].

    Standard: /home

krb5_confd_path (sträng)
    Absolut sökväg till en katalog där SSSD skall placera konfigurationsstycken för Kerberos.

    För att förhindra att konfigurationsstycken skapas, sätt parametern till ”none”.

    Standard: inte satt (underkatalogen krb5.include.d till SSSD:s pubconf-katalog)

ÄNDRADE STANDARDALTERNATIV

Vissa alternativs standardvärde stämmer inte med deras respektive bakändars standardvärden, dessa alternativnamn och AD-leverantörspecifika standardvärden är uppräknade nedan:

  KRB5-leverantör

    • krb5_validate = true

    • krb5_use_enterprise_principal = true

  LDAP-leverantör

    • ldap_schema = ad

    • ldap_force_upper_case_realm = true

    • ldap_id_mapping = true

    • ldap_sasl_mech = GSS-SPNEGO

    • ldap_referrals = false

    • ldap_account_expire_policy = ad

    • ldap_use_tokengroups = true

    • ldap_sasl_authid = sAMAccountName@RIKE (typiskt KORTNAMN$@RIKE)

    AD-leverantören letar efter en annan huvudman än LDAP-leverantören som standard, eftersom huvudmännen i en Active Directory-miljö är uppdelade i två grupper – användarhuvudmän och tjänstehuvudmän. Endast användarhuvudmannen kan användas för att hämta en TGT och som standard är datorobjekts huvudman konstruerade från dess sAMAccountName och AD-riket. Den välkända huvudmannen för värd/värdnamn@RIKE är en tjänstehuvudman och kan därmed inte användas för att hämta en TGT.

  NSS-konfiguration

    • fallback_homedir = /home/%d/%u

    AD-leverantören sätter automatiskt ”fallback_homedir = /home/%d/%u” för att tillhandahålla personliga hemkataloger för användare utan attributet homeDirectory. Om ens AD-domän är vederbörligen populerad med Posix-attribut, och man vill undvika att falla tillbaka på detta beteende, kan man uttryckligen sätta ”fallback_homedir = %o”.

    Observera att systemet typiskt förväntar sig en hemkatalog i mappen /home/%u. Om man bestämmer sig för att använda en annan katalogstruktur kan några andra delar av ens system behöva justeras.

    Till exempel kräver automatiserat skapande av hemkataloger i kombination med selinux anpassningar av selinux, annars kommer hemkatalogen skapas med fel selinux-kontext.

RESERVER

Reservfunktionen gör att bakändar automatiskt kan byta till en annan server om den nuvarande servern slutar fungera.

  Reservsyntax

Listan av servrar ges som en kommaseparerad lista; godtyckligt antal mellanslag tillåts runt kommatecknet. Servrarna listas i preferensordning. Listan kan innehålla obegränsat antal servrar.

För varje reservaktiverat konfigurationsalternativ finns det två varianter: primary och backup. Tanken är att servrar i den primära listan föredras och backup-servrar bara provas om inga primära servrar kan nås. Om en backup-server väljs sätts en tidsgräns på 31 sekunder. Efter denna tidsgräns kommer SSSD periodiskt att försöka återansluta till en av de primära servrarna. Om det lyckas kommer den ersätta den nu aktiva (backup-)servern.

  Reservmekanismen

Reservmekanismen gör skillnad mellan en maskin och en tjänst. Bakänden försöker först att slå upp värdnamnet för en given maskin; om denna uppslagning misslyckas antas maskinen vara bortkopplad. Inga ytterligare försök görs att ansluta till denna maskin för någon annan tjänst. Om uppslagningsförsöket lyckas försöker bakänden ansluta till en tjänst på denna maskin. Om tjänsteanslutningen misslyckas anses bara just denna tjänst frånkopplad och bakänden byter automatiskt till nästa tjänst. Maskinen betraktas fortfarande som uppkopplad och kan användas vid försök att nå en annan tjänst.

Ytterligare försök att ansluta görs till maskiner eller tjänster som markerats som frånkopplade efter en viss tidsperiod, detta är för närvarande hårdkodat till 30 sekunder.

Om det inte finns några fler maskiner att prova byter bakänden i sin helhet till frånkopplat läge, och försöker sedan återansluta var 30:e sekund.

  Tidsgränser och trimning av reservfunktioner

Att slå upp en server att ansluta till kan vara så enkelt som att göra en enstaka DNS-fråga eller kan innebära flera steg, såsom att hitta den rätta sajten eller försöka med flera värdnamn ifall några av de konfigurerade servrarna inte kan nås. De mer komplexa scenariona kan ta en stund och SSSD behöver balansera mellan att tillhandahålla tillräckligt med tid för att färdigställa upplösningsprocessen men å andra sidan inte försöka för länge före den faller tillbaka på frånkopplat läge. Om SSSD:s felsökningsloggar visar att serverns upplösning överskrider tidsgränsen före en aktiv server nås kan du överväga att ändra tidsgränserna.

Detta avsnitt listar tillgängliga trimningsvariabler. Se deras beskrivning i manualsidan sssd.conf(5).

dns_resolver_server_timeout
    Tid i millisekunder som anger hur länge SSSD skall tala med en viss DNS-server före den provar nästa.

    Standard: 1000

dns_resolver_op_timeout
    Tid i sekunder hur länge SSSD skall försöka slå upp en viss DNS-fråga (t.ex. uppslagning av ett värdnamn eller en SRV-post) före den provar nästa värdnamn eller upptäcktsdomän.

    Standard: 3

dns_resolver_timeout
    Hur länge skall SSSD försöka slå upp en reservtjänst. Denna tjänsteuppslagning kan internt bestå av flera steg, såsom att slå upp DNS SRV-frågor och lokalisera sajten.

    Standard: 6

För LDAP-baserade leverantörer utförs uppslagningsoperationen som en del av LDAP-anslutningsoperationen. Därför skall även tidsgränsen “ldap_opt_timeout” sättas till ett större värde än “dns_resolver_timeout” som i sin tur skall sättas till ett större värde än “dns_resolver_op_timeout” som skall vara större än “dns_resolver_server_timeout”.

TJÄNSTEUPPTÄCKT

Tjänsteupptäcktsfunktionen gör att bakändar automatiskt kan hitta en lämplig server att ansluta till med en speciell DNS-fråga. Denna funktion stödjs inte för backup-servrar.

  Konfiguration

Om inga servrar anges använder bakänden automatiskt tjänsteupptäckt för att försöka hitta en server. Användaren kan om så önskas välja att använda både en bestämd serveradress och tjänsteupptäckt genom att infoga ett speciellt nyckelord, “_srv_”, i listan av servrar. Preferensordningen bibehålls. Denna funktion är användbar om, till exempel, användaren föredrar att använda tjänsteupptäckt närhelst det är möjligt, och falla tillbaka på en specifik server när inga servrar kan upptäckas med DNS.

  Domännamnet

Se parametern “dns_discovery_domain” i manualsidan sssd.conf(5) för fler detaljer.

  Protokollet

Frågorna anger vanligen _tcp som protokoll. Undantag är dokumenterade i respektive alternativs beskrivning.

  Se även

För mer information om tjänsteupptäcktsmekanismen, se RFC 2782.

ID-MAPPNING

ID-mappningsfunktionen låter SSSD fungera som en klient till Active Directory utan att kräva att administratörer utökar användarattribut till att stödja POSIX-attribut för användar- och gruppidentifierare.

OBSERVERA: När ID-mappning aktiveras ignoreras attributen uidNumber och gidNumber. Detta är för att undvika möjligheten av konflikt mellan automatiskt tilldelade och manuellt tilldelade värden. Om du behöver använda manuellt tilldelade värden måste ALLA värden tilldelas manuellt.

Observera att byte av ID-mappnings relaterade konfigurationsalternativ kommer få användar- och grupp-ID:n att ändras. För närvarande stödjer inte SSSD byte av ID:n, så SSSD-databasen måste tas bort. Eftersom cachade lösenord också lagras i databasen skall databasen bara tas bort när autentiseringsservrarna kan nås, annars kan användare låsas ute. För att cacha lösenordet måste en autentisering göras. Det är inte tillräckligt att använda sss_cache(8) för att ta bort databasen, istället består processen av:

    • Se till att fjärrservrarna är nåbara

    • Stoppa tjänsten SSSD

    • Ta bort databasen

    • Starta tjänsten SSSD

Dessutom, eftersom ändringen av ID:n kan göra det nödvändigt att justera andra systemegenskaper såsom ägare av filer och kataloger, är det lämpligt att planera i förväg och testa konfigurationen av ID-översättningar noggrant.

  Översättningsalgoritm

Active Directory tillhandahåller ett objectSID för varje användar- och gruppobjekt i katalogen. Detta objectSID kan delas upp i komponenter som representerar Active Directorys domänidentitet och den relativa identifieraren (RID) till användar- eller gruppobjektet.

SSSD ID-mappningsalgoritmen tar ett intervall av tillgängliga UID:er och delar upp det i lika stora komponenter, så kallade "slices". Varje slice representerar det utrymme som är tillgängligt för en Active Directory-domän.

När en användar- eller gruppost för en viss domän påträffas för första gången allokerar SSSD en av de tillgängliga skivorna för den domänen. För att göra denna skivtilldelning upprepbar på olika klientmaskiner väljer vi skivan baserat på följande algoritm:

SID-strängen skickas genom algoritmen murmurhash3 för att konvertera den till ett 32-bitars hash-värde. Vi tar sedan modulo på detta värde med det totala antalet tillgängliga skivor och väljer den skivan.

OBSERVERA: Det är möjligt att träffa på kollisioner i hash:en och den påföljande moduloberäkningen. I dessa situationer kommer vi välja nästa tillgängliga skiva, men det är kanske inte möjligt att reproducera exakt samma uppsättning av skivor på andra maskiner (eftersom ordningen som de påträffas kommer avgöra deras skiva). I den här situationen rekommenderas det att antingen byta till att använda explicita POSIX-attribut i Active Directory (avaktivera ID-mappningen) eller konfigurera en standarddomän för att garantera att åtminstone en alltid är konsistent. Se “Konfiguration” för detaljer.

  Konfiguration

Minimikonfiguration (i avsnittet “[domain/DOMÄNNAMN]”):

    ldap_id_mapping = True
    ldap_schema = ad

Standardkonfigurationen resulterar i konfiguration av 10 000 skivor, som var och en kan innehålla upp till 200 000 ID:n, med början på 200 000 och upp till 2 000 200 000. Detta bör vara tillräckligt för de flesta installationer.

Avancerad konfiguration

    ldap_idmap_range_min (heltal)
        Anger den lägre (inklusiva) gränsen för intervallet av POSIX ID:n att använda för översättning av användar- och grupp-SID:n från Active Directory. Det är det första POSIX-ID:t som kan användas för översättning.

        OBSERVERA: Detta alternativ är inte detsamma som “min_id” eftersom “min_id” fungerar som ett filter av utmatade begäranden till denna domän, medan detta alternativ styr intervallet av ID-tilldelningen. Detta är en subtil distinktion, men det allmänna goda rådet skulle vara att ha “min_id” mindre än eller lika med “ldap_idmap_range_min”

        Standard: 200000

    ldap_idmap_range_max (heltal)
        Anger den övre (exklusiva) gränsen för intervallet av POSIX ID:n att använda för översättning av användar- och grupp-SID:n från Active Directory. Det är det första POSIX-ID:t som inte kan användas för översättning längre, d.v.s. ett mer än det sista som kan användas för översättningen.

        OBSERVERA: Detta alternativ är inte detsamma som “max_id” eftersom “max_id” fungerar som ett filter av utmatade begäranden till denna domän, medan detta alternativ styr intervallet av ID-tilldelningen. Detta är en subtil distinktion, men det allmänna goda rådet skulle vara att ha “max_id” större än eller lika med “ldap_idmap_range_max”

        Standard: 2000200000

    ldap_idmap_range_size (heltal)
        Anger antalet ID:n som är tillgängliga för varje skiva. Om storleken på intervallet inte delas jämnt mellan min- och maxvärdena kommer den skapa så många fullständiga skivor den kan.

        OBSERVERA: Värdet på detta alternativ måste vara åtminstone så stort som den högsta RID som planeras användas i Active Directory-servern. Användaruppslagningar och inloggningar kommer misslyckas för eventuella användare vars RID är större än detta värde.

        Till exempel, om din senast tillagda Active Directory-användare har objectSid=S-1-5-21-2153326666-2176343378-3404031434-1107, måste “ldap_idmap_range_size” vara minst 1108, eftersom intervallstorleken är lika med maximalt RID minus minimalt RID plus ett (t.ex. 1108 = 1107 - 0 + 1).

        Det är viktigt att planera i förväg för framtida expansioner, eftersom ändring av detta värde skulle resultera i att ändra alla ID-översättningar på systemet, vilket skulle leda till användare med andra lokala ID:n än de tidigare hade.

        Standard: 200000

    ldap_idmap_default_domain_sid (sträng)
        Ange domän-SID:n för standarddomänen. Detta kommer garantera att denna domän alltid kommer tilldelas till skiva noll i ID-översättningen, och undviker murmurhash-algoritmen som beskrivs ovan.

        Standard: inte satt

    ldap_idmap_default_domain (sträng)
        Ange namnet på standarddomänen.

        Standard: inte satt

    ldap_idmap_autorid_compat (boolean)
        Ändrar beteendet på ID-översättningsalgoritmen till att bete sig mer likt winbind:s “idmap_autorid”-algoritm.

        När detta alternativ konfigureras kommer domäner allokeras med början med skiva noll och ökar monotont med varje ytterligare domän.

        OBSERVERA: Denna algoritm är inte deterministisk (den beror på ordningen som användare och grupper efterfrågas). Om detta läge krävs för kompatibilitet med maskiner som kör winbind rekommenderas det att även använda alternativet “ldap_idmap_default_domain_sid” för att garantera att åtminstone en domän är konsekvent allokerat till skiva noll.

        Standard: False

    ldap_idmap_helper_table_size (heltal)
        Maximalt antal sekundära skivor som provas när mappningen från UNIX id till SID utförs.

        Observera: ytterligare sekundära skivor kan genereras när en SID översätts till UNIX-id och RID-delen av SID:n är utanför intervallet för sekundära skivor som genererats hittills. Om värdet på ldap_idmap_helper_table_size är lika med 0 genereras inga ytterligare sekundära skivor.

        Standard: 10

  Välkända SID:er

SSSD stödjer uppslagning av namnen på välkända SID:er, d.v.s. SID:er med en speciell hårdkodad betydelse. Eftersom de allmänna användarna och grupperna relaterade till dessa välkända SID:er inte har någon motsvarighet i en Linux-/UNIX-miljö är inga POSIX-ID:n tillgängliga för dessa objekt.

SID-namnrymden är organiserad i auktoriteter som kan ses som olika domäner. Auktoriteterna för välkända SID:er är

    • Null-auktoritet

    • Världsauktoritet

    • Lokal auktoritet

    • Skaparauktoritet

    • Tvingande etikettsauktoritet

    • Autentiseringsauktoritet

    • NT-auktoritet

    • Inbyggd

Den versala versionen av dessa namn används som domännamn när det fullständigt kvalificerade namnet på en välkänd SID returneras.

Eftersom några verktyg tillåter att man ändrar SID-baserad åtkomststyrningsinformation med hjälp av ett namn istället för att använda SID:en direkt stödjer SSSD uppslagning av SID:en med detta namn också. För att undvika kollisioner kan bara de fullständigt kvalificerade namnen användas för att slå upp välkända SID:er. Som ett resultat skall domännamnen “NULL AUTHORITY”, “WORLD AUTHORITY”, “LOCAL AUTHORITY”, “CREATOR AUTHORITY”, “MANDATORY LABEL AUTHORITY”, “AUTHENTICATION AUTHORITY”, “NT AUTHORITY” och “BUILTIN” inte användas som domännamn i sssd.conf.

EXEMPEL

Följande exempel antar att SSSD är korrekt konfigurerat och att exempel.se är en av domänerna i avsnittet [sssd]. Detta exempel visar endast alternativ som är specifika för leverantören AD.

    [domain/EXEMPEL]
    id_provider = ad
    auth_provider = ad
    access_provider = ad
    chpass_provider = ad
    ad_server = dc1.exempel.se
    ad_hostname = client.exempel.se
    ad_domain = exempel.se

NOTER

Leverantören AD av åtkomstkontroll kontrollerar om kontot har gått ut. Det har samma effekt som följande konfiguration av LDAP-leverantören:

    access_provider = ldap
    ldap_access_order = expire
    ldap_account_expire_policy = ad

Dock, om inte åtkomstleverantören “ad” är konfigurerad explicit är standardåtkomstleverantören “permit”. Observera att om man konfigurerar en annan åtkomstleverantör än “ad” behöver man sätta alla anslutningsparametrarna (såsom LDAP URI:er och krypteringsdetaljer) manuellt.

När autofs-leverantören är satt till “ad” används översättningen av schemaattribut enligt RFC2307 (nisMap, nisObject, ...), för att dessa attribut inkluderas i standardschemat för Active Directory.

SE ÄVEN

sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-idp(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(1), sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

AUTHORS

SSSD uppströms – https://github.com/SSSD/sssd/

NOTES

1.  Active Directory security grouips
    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups

2.  [MS-ADTS] avsnittet LDAP-utökningar
    https://msdn.microsoft.com/en-us/library/cc223367.aspx