Scroll to navigation

SSSD-AD(5) Filformat och konventioner 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)

A comma-separated list of enabled Active Directory domains. If provided, SSSD will ignore any domains not listed in this option. If left unset, all discovered domains from the AD forest will be available.

During the discovery of the domains SSSD will filter out some domains where flags or attributes indicate that they do not belong to the local forest or are not trusted. If ad_enabled_domains is set, SSSD will try to enable all listed domains.

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.example.com, tekn.example.com

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)

Detta alternativ anger LDAP:s åtkomstkontrollfilter som användaren måste matcha för att tillåtas åtkomst. Observera att alternativet “access_provider” måste vara uttryckligen satt till “ad” för att detta alternativ skall ha någon effekt.

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.example.com: 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 EXAMPLE.COM:
FOREST:EXAMPLE.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

•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)

Detta alternativ skall endast användas för att testa maskinkontoförnyelsefunktionen. Alternativet förväntar sig 2 heltal separerade av ett kolon (”:”). Det första heltalet anger intervallet i sekunder hur ofta funktionen körs. Det andra anger den initiala tidsgränsen i sekunder före funktionen körs för första gången efter uppstart.

Standard: 86400:750 (24h och 15m)

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

ad_allow_remote_domain_local_groups (boolean)

Om detta alternativ är satt till “sant” kommer SSSD inte att filtrera 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. För att vara kompatibel med andra lösningar som gör AD-användare och -grupper tillgängliga i Linuxklienter lades detta alternativ till.

Observera att sätta detta alternativ till “sant” kommer strida mot avsikten med domänlokala grupper i Active Directory och SKALL ENDAST ANVÄNDAS FÖR ATT MÖJLIGGÖRA MIGRERING FRÅN ANDRA LÖSNINGAR. Även om grruppen finns och användaren kan vara medlem av gruppen är avsikten att gruppen endast skall användas i domänen den är definierad och inte i några andra. Eftersom det endast finns en typ av POSIX-grupper är det enda sättet att uppnå detta på Linuxsidan att ignorera dessa grupper. Detta görs också av Active Directory som kan ses i PAC:en i Kerberosbiljetten för en lokal tjänst sller i tokenGroups-begäranden där också de domänlokala fjärrgrupperna saknas.

Givet ovanstående kommentarer, om detta alternativ är satt till “sant” måste tokenGroups-begäranden avaktiveras genom att sätta “ldap_use_tokengroups” till “falskt” för att få konsistenta gruppmedlemskap för en användare. Dessutom skall uppslagningar i Global Catalog också hoppas över genom att sätta “ad_enable_gc” till “falskt”. Slutligen kan det vara nödvändigt att ändra “ldap_group_nesting_level” om de domänlokala fjärrgurpperna endast finns med en djupare nästningsnivå.

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)

Valfri. Endast tillämpligt när dyndns_update är sann. Välj gränssnittet eller en lista av gränssnitt vars IP-adresser skall användas för dynamiska DNS-uppdateringar. Specialvärdet “*” betyder att IP:n från alla gränssnitt skall användas.

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

Exempel: dyndns_iface = em1, vnet1, vnet2

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.

Note that dyndns_update_per_family parameter does not apply for PTR record updates. Those updates are always sent separately.

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.

Att sätta detta alternativ är meningsfullt i miljöer där DNS-servern är skild från identitetsservern.

Observera att detta alternativ bara kommer användas i försök att falla tillbaka på när tidigare försök som använder automatiskt upptäckta inställningar misslyckas.

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

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

Den ursprungliga hemkatalogen som hämtades från identitetsleverantören.

%h

Den ursprungliga hemkatalogen som hämtades från identitetsleverantören, men i gemener.

%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-översättningsalgoritmen tar ett intervall av tillgängliga AID:er och delar upp det i lika stora komponentavsnitt – kallade ”skivor” (”slices”) –. Varje skiva representerar utrymmet 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 den senaste tillagda Active Directory-användaren har objectSid=S-1-5-21-2153326666-2176343378-3404031434-1107, måste “ldap_idmap_range_size” vara åtminstone 1108 eftersom intervallstorleken är lika med maximal SID minus minimal SID 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.

When this option is configured, domains will be allocated starting with slice zero and increasing monotonically with each additional domain.

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 example.com ä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.example.com
ad_hostname = client.example.com
ad_domain = example.com

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-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(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

AUTHORS

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

NOTES

1.
Active Directory security grouips
2.
[MS-ADTS] avsnittet LDAP-utökningar
10/01/2024 SSSD