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.
Se "DOMÄNSEKTIONER" i manualsidan sssd.conf(5) för detaljer om konfigurationen av en SSSD-domän.
ad_domain (sträng)
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)
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)
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)
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)
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)
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: m[blue][MS-ADTS] avsnittet LDAP-utökningarm[][1]
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)
Standard: inte satt
ad_enable_gc (boolean)
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)
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:
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:
Standard: enforcing
ad_gpo_implicit_deny (boolean)
Standard: False
The following 2 tables should illustrate when a user is allowed or rejected based on the allow and deny login rights defined on the server-side and the setting of ad_gpo_implicit_deny.
|
ad_gpo_implicit_deny = False (default)
| ||
| allow-rules | deny-rules |
results
|
| missing | missing |
all users are allowed
|
| missing | present |
only users not in deny-rules are allowed
|
| present | missing |
only users in allow-rules are allowed
|
| present | present |
only users in allow-rules and not in deny-rules are allowed
|
|
ad_gpo_implicit_deny = True
| ||
| allow-rules | deny-rules |
results
|
| missing | missing |
no users are allowed
|
| missing | present |
no users are allowed
|
| present | missing |
only users in allow-rules are allowed
|
| present | present |
only users in allow-rules and not in deny-rules are allowed
|
ad_gpo_ignore_unreadable (boolean)
Standard: False
ad_gpo_cache_timeout (heltal)
Standard: 5 (sekunder)
ad_gpo_map_interactive (sträng)
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:
ad_gpo_map_remote_interactive (sträng)
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:
ad_gpo_map_network (sträng)
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:
ad_gpo_map_batch (sträng)
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:
ad_gpo_map_service (sträng)
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)
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:
ad_gpo_map_deny (sträng)
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)
Värden som stödjs för detta alternativ inkluderar:
Standard: deny
ad_maximum_machine_account_password_age (heltal)
Standard: 30 dagar
ad_machine_account_password_renewal_opts (sträng)
Standard: 86400:750 (24h och 15m)
ad_update_samba_machine_account_password (boolean)
Standard: false
ad_use_ldaps (bool)
Standard: False
ad_allow_remote_domain_local_groups (boolean)
Please note that setting this option to "true" will be against the intention of Domain Local group in Active Directory and SHOULD ONLY BE USED TO FACILITATE MIGRATION FROM OTHER SOLUTIONS. Although the group exists and user can be member of the group the intention is that the group should be only used in the domain it is defined and in no others. Since there is only one type of POSIX groups the only way to achieve this on the Linux side is to ignore those groups. This is also done by Active Directory as can be seen in the PAC of the Kerberos ticket for a local service or in tokenGroups requests where remote Domain Local groups are missing as well.
Given the comments above, if this option is set to "true" the tokenGroups request must be disabled by setting "ldap_use_tokengroups" to "false" to get consistent group-memberships of a users. Additionally the Global Catalog lookup should be skipped as well by setting "ad_enable_gc" to "false". Finally it might be necessary to modify "ldap_group_nesting_level" if the remote Domain Local groups can only be found with a deeper nesting level.
Standard: False
dyndns_update (boolean)
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)
Standard: 3600 (sekunder)
dyndns_iface (sträng)
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)
Standard: 86400 (24 timmar)
dyndns_update_ptr (bool)
Standard: True
dyndns_force_tcp (bool)
Standard: False (låt nsupdate välja protokollet)
dyndns_auth (sträng)
Standard: GSS-TSIG
dyndns_auth_ptr (string)
Default: Same as dyndns_auth
dyndns_server (sträng)
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)
Standard: true
override_homedir (sträng)
%u
%U
%d
%f
%l
%P
%o
%H
%%
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)
homedir_substring (sträng)
Standard: /home
krb5_confd_path (sträng)
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)
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:
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.
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".
Note that the system typically expects a home directory in /home/%u folder. If you decide to use a different directory structure, some other parts of your system may need adjustments.
For example automated creation of home directories in combination with selinux requires selinux adjustment, otherwise the home directory will be created with wrong selinux context.
Reservfunktionen gör att bakändar automatiskt kan byta till en annan server om den nuvarande servern slutar fungera.
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 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.
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
Standard: 1000
dns_resolver_op_timeout
Standard: 3
dns_resolver_timeout
Standard: 6
For LDAP-based providers, the resolve operation is performed as part of an LDAP connection operation. Therefore, also the "ldap_opt_timeout" timeout should be set to a larger value than "dns_resolver_timeout" which in turn should be set to a larger value than "dns_resolver_op_timeout" which should be larger than "dns_resolver_server_timeout".
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.
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.
Se parametern "dns_discovery_domain" i manualsidan sssd.conf(5) för fler detaljer.
Frågorna anger vanligen _tcp som protokoll. Undantag är dokumenterade i respektive alternativs beskrivning.
För mer information om tjänsteupptäcktsmekanismen, se RFC 2782.
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:
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.
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.
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.
ldap_idmap_range_min (heltal)
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)
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)
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)
Standard: inte satt
ldap_idmap_default_domain (sträng)
Standard: inte satt
ldap_idmap_autorid_compat (boolean)
När detta alternativ konfigureras kommer domäner allokeras med början med skiva noll och ökar monatomärt 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)
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
Avancerad konfiguration
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
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", "NT AUTHORITY" och "BUILTIN" inte användas som domännamn i sssd.conf.
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
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.
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-files(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) sssd-systemtap(5)
SSSD uppströms - https://github.com/SSSD/sssd/