Dela via


Minska risken för angrepp på Active Directory

Det här avsnittet fokuserar på tekniska kontroller som ska implementeras för att minska attackytan för Active Directory-installationen. Avsnittet innehåller följande information:

  • Implementeringen av Least-Privilege administrativa modeller fokuserar på att identifiera den risk som användningen av konton med hög behörighet för den dagliga administrationen innebär, förutom att ge rekommendationer för att implementera för att minska risken för att privilegierade konton finns.

  • Implementering av säkra administrativa värdar beskriver principer för distribution av dedikerade, säkra administrativa system, utöver vissa exempelmetoder för en säker administrativ värddistribution.

  • När du skyddar domänkontrollanter mot angrepp diskuteras principer och inställningar som, även om de liknar rekommendationerna för implementering av säkra administrativa värdar, innehåller vissa domänkontrollantspecifika rekommendationer för att säkerställa att domänkontrollanterna och de system som används för att hantera dem är väl skyddade.

Privilegierade konton och grupper i Active Directory

Det här avsnittet innehåller bakgrundsinformation om privilegierade konton och grupper i Active Directory som är avsedda att förklara gemensamma uppgifter och skillnader mellan privilegierade konton och grupper i Active Directory. Genom att förstå dessa skillnader, oavsett om du implementerar rekommendationerna i Implementera Least-Privilege administrativa modeller ordagrant eller välja att anpassa dem för din organisation, har du de verktyg du behöver för att skydda varje grupp och konto på rätt sätt.

Inbyggda privilegierade konton och grupper

Active Directory underlättar delegering av administration och stöder principen om minsta behörighet vid tilldelning av rättigheter och behörigheter. "Vanliga" användare som har konton i en domän kan som standard läsa mycket av det som lagras i katalogen, men kan bara ändra en mycket begränsad uppsättning data i katalogen. Användare som behöver ytterligare behörighet kan beviljas medlemskap i olika "privilegierade" grupper som är inbyggda i katalogen så att de kan utföra specifika uppgifter som är relaterade till deras roller, men inte kan utföra uppgifter som inte är relevanta för deras uppgifter. Organisationer kan också skapa grupper som är skräddarsydda för specifika jobbansvar och beviljas detaljerade rättigheter och behörigheter som gör det möjligt för IT-personal att utföra dagliga administrativa funktioner utan att bevilja rättigheter och behörigheter som överskrider vad som krävs för dessa funktioner.

I Active Directory är tre inbyggda grupper de högsta behörighetsgrupperna i katalogen: Företagsadministratörer, Domänadministratörer och Administratörer. Standardkonfigurationen och funktionerna för var och en av dessa grupper beskrivs i följande avsnitt:

Högsta behörighetsgrupper i Active Directory

Företagsadministratörer

Företagsadministratörer (EA) är en grupp som bara finns i skogens rotdomän, och som standard är den medlem i gruppen Administratörer i alla domäner i skogen. Det inbyggda administratörskontot i skogens rotdomän är den enda standardmedlemmen i EA-gruppen. Certifikatutfärdare beviljas rättigheter och behörigheter som gör det möjligt för dem att implementera ändringar i hela skogen (dvs. ändringar som påverkar alla domäner i skogen), till exempel att lägga till eller ta bort domäner, upprätta skogsförtroenden eller höja skogens funktionsnivåer. I en korrekt utformad och implementerad delegeringsmodell krävs EA-medlemskap endast när du först skapar skogen eller när du gör vissa ändringar i hela skogen, till exempel att upprätta ett utgående skogsförtroende. De flesta rättigheter och behörigheter som beviljas ea-gruppen kan delegeras till mindre privilegierade användare och grupper.

Domänadministratörer

Varje domän i en skog har en egen domänadministratörsgrupp (DA), som är medlem i domänens administratörsgrupp och medlem i den lokala gruppen Administratörer på varje dator som är ansluten till domänen. Den enda standardmedlemmen i DA-gruppen för en domän är det inbyggda administratörskontot för domänen. Domänadministratörer är "allsmäktiga" inom sina domäner, medan företagsadministratörer har privilegier som omfattar hela skogen. I en korrekt utformad och implementerad delegeringsmodell bör domänadministratörsmedlemskap endast krävas i "break glass"-scenarier (till exempel situationer där ett konto med hög behörighetsnivå på varje dator i domänen behövs). Även om inbyggda Active Directory-delegeringsmekanismer tillåter delegering i den utsträckning som det är möjligt att endast använda DA-konton i nödsituationsscenarier, kan det vara tidskrävande att skapa en effektiv delegeringsmodell, och många organisationer använder verktyg från tredje part för att påskynda processen.

Administrators

Den tredje grupp är den inbyggda domänlokal administratörsgruppen (BA) i vilken DAs och EAs är kapslade. Den här gruppen beviljas många av de direkta rättigheterna och behörigheterna i katalogen och på domänkontrollanter. Gruppen Administratörer för en domän har dock inga behörigheter på medlemsservrar eller på arbetsstationer. Det är via medlemskap i datorns lokala administratörsgrupp som lokal behörighet beviljas.

Note

Även om det här är standardkonfigurationerna för dessa privilegierade grupper kan en medlem i någon av de tre grupperna ändra katalogen för att få medlemskap i någon av de andra grupperna. I vissa fall är det trivialt att få medlemskap i de andra grupperna, medan det i andra är svårare, men ur ett potentiellt privilegiumsperspektiv bör alla tre grupperna betraktas som effektivt likvärdiga.

Schemaadministratörer

En fjärde privilegierad grupp, Schemaadministratörer (SA), finns bara i skogens rotdomän och har bara domänens inbyggda administratörskonto som standardmedlem, ungefär som gruppen Företagsadministratörer. Gruppen Schemaadministratörer är endast avsedd att fyllas i tillfälligt och ibland (när ändringar av AD DS-schemat krävs).

Även om SA-gruppen är den enda grupp som kan ändra Active Directory-schemat (dvs. katalogens underliggande datastrukturer, till exempel objekt och attribut), är omfattningen för SA-gruppens rättigheter och behörigheter mer begränsad än de tidigare beskrivna grupperna. Det är också vanligt att se att organisationer har utvecklat lämpliga metoder för hantering av medlemskap i SA-gruppen eftersom medlemskap i gruppen vanligtvis sällan behövs och endast under korta tidsperioder. Detta gäller tekniskt sett även för EA-, DA- och BA-grupperna i Active Directory, men det är mycket mindre vanligt att organisationer har implementerat liknande metoder för dessa grupper som för SA-gruppen.

Skyddade konton och grupper i Active Directory

I Active Directory skyddas en standarduppsättning med privilegierade konton och grupper som kallas "skyddade" konton och grupper på ett annat sätt än andra objekt i katalogen. Alla konton som har direkt eller transitivt medlemskap i en skyddad grupp (oavsett om medlemskapet härleds från säkerhets- eller distributionsgrupper) ärver denna begränsade säkerhet.

Om en användare till exempel är medlem i en distributionsgrupp som i sin tur är medlem i en skyddad grupp i Active Directory, flaggas användarobjektet som ett skyddat konto. När ett konto flaggas som ett skyddat konto anges värdet för attributet adminCount för objektet till 1.

Note

Även om transitivt medlemskap i en skyddad grupp innehåller kapslad distribution och kapslade säkerhetsgrupper, kommer konton som är medlemmar i kapslade distributionsgrupper inte att ta emot den skyddade gruppens SID i sina åtkomsttoken. Distributionsgrupper kan dock konverteras till säkerhetsgrupper i Active Directory, vilket är anledningen till att distributionsgrupper ingår i den skyddade gruppmedlemsuppräkningen. Om en skyddad kapslad distributionsgrupp någonsin konverteras till en säkerhetsgrupp får kontona som är medlemmar i den tidigare distributionsgruppen därefter den överordnade skyddade gruppens SID i sina åtkomsttoken vid nästa inloggning.

I följande tabell visas standardskyddade konton och grupper i Active Directory efter operativsystemversion och Service Pack-nivå.

Standardskyddade konton och grupper i Active Directory efter operativsystem och Service Pack -version (SP)

Windows 2000 <SP4 Windows 2000 SP4 -Windows Server 2003 Windows Server 2003 SP1+ Windows Server 2008 -Windows Server 2012
Administrators Kontooperatorer Kontooperatorer Kontooperatorer
Administrator Administrator Administrator
Administrators Administrators Administrators
Domänadministratörer Säkerhetskopieringsoperatorer Säkerhetskopieringsoperatorer Säkerhetskopieringsoperatorer
Cert Publishers
Domänadministratörer Domänadministratörer Domänadministratörer
Företagsadministratörer Domänkontrollanter Domänkontrollanter Domänkontrollanter
Företagsadministratörer Företagsadministratörer Företagsadministratörer
Krbtgt Krbtgt Krbtgt
Utskriftsoperatorer Utskriftsoperatorer Utskriftsoperatorer
Skrivskyddade domänkontrollanter
Replicator Replicator Replicator
Schemaadministratörer Schemaadministratörer Schemaadministratörer
AdminSDHolder och SDProp

I systemcontainern för varje Active Directory-domän skapas automatiskt ett objekt som heter AdminSDHolder. Syftet med objektet AdminSDHolder är att säkerställa att behörigheterna för skyddade konton och grupper tillämpas konsekvent, oavsett var de skyddade grupperna och kontona finns i domänen.

Var 60:e minut (som standard) körs en process som kallas SDProp (Security Descriptor Propagator) på domänkontrollanten som innehåller domänens PDC-emulatorroll. SDProp jämför behörigheterna för domänens AdminSDHolder-objekt med behörigheterna för de skyddade kontona och grupperna i domänen. Om behörigheterna för något av de skyddade kontona och grupperna inte matchar behörigheterna för AdminSDHolder-objektet återställs behörigheterna för de skyddade kontona och grupperna så att de matchar behörigheterna för domänens AdminSDHolder-objekt.

Arv av behörigheter är inaktiverat för skyddade grupper och konton, vilket innebär att även om kontona eller grupperna flyttas till olika platser i katalogen ärver de inte behörigheter från sina nya överordnade objekt. Arv är också inaktiverat för AdminSDHolder-objektet så att behörighetsändringar i de överordnade objekten inte ändrar behörigheterna för AdminSDHolder.

Note

När ett konto tas bort från en skyddad grupp betraktas det inte längre som ett skyddat konto, men attributet adminCount är fortfarande inställt på 1 om det inte ändras manuellt. Resultatet av den här konfigurationen är att objektets ACL:er inte längre uppdateras av SDProp, men objektet ärver fortfarande inte behörigheter från det överordnade objektet. Därför kan objektet finnas i en organisationsenhet (OU) som behörigheter har delegerats till, men det tidigare skyddade objektet ärver inte dessa delegerade behörigheter. Ett skript för att hitta och återställa tidigare skyddade objekt i domänen finns i microsoft supportartikeln 817433.

Administratörsägarägarskap

De flesta objekt i Active Directory ägs av domänens BA-grupp. AdminSDHolder-objektet ägs dock som standard av domänens DA-grupp. (Det här är en situation där domänadministratörer inte härleder sina rättigheter och behörigheter via medlemskap i domänens administratörsgrupp.)

I versioner av Windows tidigare än Windows Server 2008 kan ägare av ett objekt ändra behörigheter för objektet, inklusive att ge sig själva behörigheter som de inte ursprungligen hade. Därför hindrar standardbehörigheterna för en domäns AdminSDHolder-objekt användare som är medlemmar i BA- eller EA-grupper från att ändra behörigheterna för en domäns AdminSDHolder-objekt. Medlemmar i gruppen Administratörer för domänen kan dock ta ansvar för objektet och ge sig själva ytterligare behörigheter, vilket innebär att det här skyddet är rudimentärt och endast skyddar objektet mot oavsiktlig ändring av användare som inte är medlemmar i DA-gruppen i domänen. Dessutom har grupperna BA och EA (i förekommande fall) behörighet att ändra attributen för AdminSDHolder-objektet i den lokala domänen (rotdomän för EA).

Note

Ett attribut för AdminSDHolder-objektet, dSHeuristics, tillåter begränsad anpassning (borttagning) av grupper som anses vara skyddade grupper och som påverkas av AdminSDHolder och SDProp. Den här anpassningen bör övervägas noggrant om den implementeras, även om det finns giltiga omständigheter där ändring av dSHeuristics på AdminSDHolder är användbar. Mer information om ändring av attributet dSHeuristics för ett AdminSDHolder-objekt finns i Microsoft Support-artiklarna 817433 och i bilaga C: Skyddade konton och grupper i Active Directory.

Även om de mest privilegierade grupperna i Active Directory beskrivs här finns det ett antal andra grupper som har beviljats förhöjda behörighetsnivåer. Mer information om alla standardgrupper och inbyggda grupper i Active Directory och de användarrättigheter som tilldelats var och en finns i Bilaga B: Privilegierade konton och grupper i Active Directory.