Implementera administrativa modeller med lägsta behörighet

Följande utdrag är från The Administrator Accounts Security Planning Guide, som först publicerades den 1 april 1999:

"De flesta säkerhetsrelaterade utbildningar och dokumentation diskuterar implementeringen av en princip med minst behörighet, men organisationer följer den sällan. Principen är enkel, och effekten av att tillämpa den på rätt sätt ökar säkerheten avsevärt och minskar risken. Principen anger att alla användare ska logga in med ett användarkonto som har den absoluta lägsta behörighet som krävs för att slutföra den aktuella uppgiften och inget mer. Detta ger skydd mot skadlig kod, bland andra attacker. Den här principen gäller för datorer och användare av dessa datorer. " En anledning till att den här principen fungerar så bra är att den tvingar dig att göra lite intern forskning. Du måste till exempel fastställa vilka åtkomstbehörigheter som en dator eller användare verkligen behöver och sedan implementera dem. För många organisationer kan den här uppgiften till en början verka som en hel del arbete. Det är dock ett viktigt steg för att skydda din nätverksmiljö. "Du bör ge alla domänadministratörsanvändare sina domänbehörigheter enligt begreppet lägsta behörighet. Om en administratör till exempel loggar in med ett privilegierat konto och oavsiktligt kör ett virusprogram har viruset administrativ åtkomst till den lokala datorn och till hela domänen. Om administratören i stället hade loggat in med ett icke-privilegierat (icke-ministrativt) konto skulle virusets omfattning av skador bara vara den lokala datorn eftersom den körs som en lokal datoranvändare. "I ett annat exempel får konton som du beviljar administratörsrättigheter på domännivå inte ha utökade rättigheter i en annan skog, även om det finns en förtroenderelation mellan skogarna. Den här taktiken hjälper till att förhindra omfattande skador om en angripare lyckas kompromettera en hanterad skog. Organisationer bör regelbundet granska sitt nätverk för att skydda mot obehörig eskalering av privilegier."

Följande utdrag är från Microsoft Windows Security Resource Kit, som först publicerades 2005:

"Tänk alltid på säkerhet när det gäller att bevilja den minsta mängd privilegier som krävs för att utföra uppgiften. Om ett program som har för många behörigheter ska komprometteras kan angriparen kanske utöka attacken utöver vad det skulle göra om programmet hade haft minsta möjliga behörighet. Du kan till exempel undersöka konsekvenserna av att en nätverksadministratör oavsiktligt öppnar en bifogad e-postbilaga som startar ett virus. Om administratören är inloggad med domänadministratörskontot har viruset administratörsbehörighet på alla datorer i domänen och därmed obegränsad åtkomst till nästan alla data i nätverket. Om administratören är inloggad med ett lokalt administratörskonto har viruset administratörsbehörighet på den lokala datorn och kan därför komma åt data på datorn och installera skadlig programvara, till exempel loggningsprogram för nyckeldrag på datorn. Om administratören är inloggad med ett normalt användarkonto har viruset endast åtkomst till administratörens data och kommer inte att kunna installera skadlig programvara. Genom att använda de minsta behörigheter som krävs för att läsa e-post minskar kompromissens potentiella omfattning avsevärt i det här exemplet."

Behörighetsproblemet

Principerna som beskrivs i föregående utdrag har inte ändrats, men när vi utvärderar Active Directory-installationer hittar vi alltid ett överdrivet antal konton som har beviljats rättigheter och behörigheter långt utöver de som krävs för att utföra det dagliga arbetet. Miljöns storlek påverkar antalet alltför privilegierade konton, men inte proportionerna. Medelstora kataloger kan ha dussintals konton i de mest privilegierade grupperna, medan stora installationer kan ha hundratals eller till och med tusentals. Med få undantag, oavsett hur sofistikerad en angripares färdigheter och arsenal är, följer angripare vanligtvis vägen för minst motstånd. De ökar komplexiteten i sina verktyg och tillvägagångssätt endast om och när enklare mekanismer misslyckas eller omintetgörs av försvarare.

Tyvärr har vägen för minsta motstånd i många miljöer visat sig vara överanvändningen av konton med breda och djupa privilegier. Breda behörigheter är rättigheter och behörigheter som gör det möjligt för ett konto att utföra specifika aktiviteter i ett stort tvärsnitt i miljön, till exempel kan supportpersonal beviljas behörigheter som gör att de kan återställa lösenorden på många användarkonton.

Djupa privilegier är kraftfulla privilegier som tillämpas på ett smalt segment av populationen, till exempel att ge en tekniker administratörsbehörighet på en server så att de kan utföra reparationer. Varken breda privilegier eller djupa privilegier är nödvändigtvis farliga, men när många konton i domänen permanent beviljas breda och djupa privilegier, om bara ett av kontona komprometteras, kan det snabbt användas för att konfigurera om miljön till angriparens syften eller till och med för att förstöra stora delar av infrastrukturen.

Pass-the-hash-attacker, som är en typ av stöld av autentiseringsuppgifter, är allestädes närvarande eftersom verktygen för att utföra dem är fritt tillgängliga och lättanvända, och eftersom många miljöer är sårbara för attackerna. Pass-the-hash-attacker är dock inte det verkliga problemet. Problemets crux är dubbel:

1. Det är vanligtvis enkelt för en angripare att få djup behörighet på en enda dator och sedan sprida den behörigheten brett till andra datorer.
2. Det finns vanligtvis för många permanenta konton med hög behörighet i databehandlingslandskapet.

Även om pass-the-hash-attacker elimineras skulle angripare helt enkelt använda olika taktiker, inte en annan strategi. I stället för att plantera skadlig kod som innehåller verktyg för stöld av autentiseringsuppgifter kan de plantera skadlig kod som loggar tangenttryckningar eller utnyttja valfritt antal andra metoder för att samla in autentiseringsuppgifter som är kraftfulla i hela miljön. Oavsett taktik förblir målen desamma: konton med breda och djupa privilegier.

Det går inte bara att bevilja för hög behörighet i Active Directory i komprometterade miljöer. När en organisation har utvecklat vanan att bevilja mer behörighet än vad som krävs finns den vanligtvis i hela infrastrukturen enligt beskrivningen i följande avsnitt.

I Active Directory

I Active Directory är det vanligt att ea-, DA- och BA-grupperna innehåller för många konton. Oftast innehåller en organisations EA-grupp minst antal medlemmar, DA-grupper innehåller vanligtvis en multiplikator av antalet användare i EA-gruppen och administratörsgrupper innehåller vanligtvis fler medlemmar än populationerna i de andra grupperna tillsammans. Detta beror ofta på en tro att administratörer på något sätt är "mindre privilegierade" än delegerade administratörer (DAs) eller exekutiva assistenter (EAs). Även om de rättigheter och behörigheter som beviljas var och en av dessa grupper skiljer sig åt, bör de effektivt betraktas som lika mäktiga grupper eftersom en medlem i en kan göra sig själv till medlem i de andra två.

På medlemsservrar

När vi hämtar medlemskap i lokala administratörsgrupper på medlemsservrar i många miljöer hittar vi medlemskap som sträcker sig från en handfull lokala konton och domänkonton till dussintals kapslade grupper som, när de expanderas, avslöjar hundratals, till och med tusentals, konton med lokal administratörsbehörighet på servrarna. I många fall är domängrupper med stora medlemskap kapslade i medlemsservrarnas lokala administratörsgrupper, utan hänsyn till att alla användare som kan ändra medlemskap i dessa grupper i domänen kan få administrativ kontroll över alla system där gruppen har kapslats i en lokal administratörsgrupp.

På arbetsstationer

Även om arbetsstationer vanligtvis har betydligt färre medlemmar i sina lokala administratörsgrupper än medlemsservrar, beviljas användare i många miljöer medlemskap i den lokala gruppen Administratörer på sina personliga datorer. När detta inträffar, även om UAC är aktiverat, utgör dessa användare en förhöjd risk för integriteten för sina arbetsstationer.

Viktigt!

Du bör noga överväga om användarna behöver administrativa rättigheter på sina arbetsstationer, och om de gör det kan en bättre metod vara att skapa ett separat lokalt konto på datorn som är medlem i gruppen Administratörer. När användarna behöver utökade privilegier kan de visa autentiseringsuppgifterna för det lokala kontot för utökade privilegier, men eftersom kontot är lokalt kan det inte användas för att kompromettera andra datorer eller komma åt domänresurser. Precis som med alla lokala konton bör dock autentiseringsuppgifterna för det lokala privilegierade kontot vara unika. Om du skapar ett lokalt konto med samma autentiseringsuppgifter på flera arbetsstationer exponerar du datorerna för pass-the-hash-attacker.

Applikationer

I attacker där målet är en organisations immateriella egendom kan konton som har beviljats kraftfulla privilegier inom program riktas in för att tillåta exfiltrering av data. Även om konton som har åtkomst till känsliga data kanske inte har beviljats några utökade privilegier i domänen eller operativsystemet, innebär konton som kan ändra konfigurationen av ett program eller åtkomst till den information som programmet ger en risk.

I datalagringsplatser

Som med andra mål kan angripare som söker åtkomst till immateriella rättigheter i form av dokument och andra filer rikta in sig på konton som styr åtkomsten till filarkiven, konton som har direkt åtkomst till filerna eller till och med grupper eller roller som har åtkomst till filerna. Om en filserver till exempel används för att lagra kontraktdokument och åtkomst beviljas till dokumenten med hjälp av en Active Directory-grupp, kan en angripare som kan ändra medlemskapet i gruppen lägga till komprometterade konton i gruppen och komma åt kontraktsdokumenten. I fall där åtkomst till dokument tillhandahålls av program som SharePoint kan angripare rikta in sig på programmen enligt beskrivningen tidigare.

Minska privilegier

Ju större och mer komplex en miljö är, desto svårare är det att hantera och skydda. I små organisationer kan det vara relativt enkelt att granska och minska behörigheten, men varje ytterligare server, arbetsstation, användarkonto och program som används i en organisation lägger till ett annat objekt som måste skyddas. Eftersom det kan vara svårt eller till och med omöjligt att skydda alla aspekter av en organisations IT-infrastruktur korrekt bör du först fokusera arbetet på konton vars behörighet skapar den största risken, som vanligtvis är de inbyggda privilegierade kontona och grupperna i Active Directory, samt privilegierade lokala konton på arbetsstationer och medlemsservrar.

Skydda lokala administratörskonton på arbetsstationer och medlemsservrar

Även om det här dokumentet fokuserar på att skydda Active Directory, som tidigare har diskuterats, börjar de flesta attacker mot katalogen som attacker mot enskilda värdar. Det går inte att ge fullständiga riktlinjer för att skydda lokala grupper i medlemssystem, men följande rekommendationer kan användas för att skydda lokala administratörskonton på arbetsstationer och medlemsservrar.

Skydda lokala administratörskonton

På alla versioner av Windows som för närvarande har mainstream-stöd inaktiveras det lokala administratörskontot som standard, vilket gör kontot oanvändbart för pass-the-hash-attacker och andra stölder av autentiseringsuppgifter. Men i domäner som innehåller äldre operativsystem eller där lokala administratörskonton har aktiverats kan dessa konton användas enligt tidigare beskrivning för att sprida kompromisser mellan medlemsservrar och arbetsstationer. Därför rekommenderas följande kontroller för alla lokala administratörskonton i domänanslutna system.

Detaljerade instruktioner för att implementera dessa kontroller finns i bilaga H: Skydda lokala administratörskonton och grupper. Innan du implementerar de här inställningarna bör du dock se till att lokala administratörskonton för närvarande inte används i miljön för att köra tjänster på datorer eller utföra andra aktiviteter som dessa konton inte ska användas för. Testa inställningarna noggrant innan du implementerar dem i en produktionsmiljö.

Kontroller för lokala administratörskonton

Inbyggda administratörskonton bör aldrig användas som tjänstkonton på medlemsservrar och bör inte heller användas för att logga in på lokala datorer (utom i felsäkert läge, vilket är tillåtet även om kontot är inaktiverat). Målet med att implementera inställningarna som beskrivs här är att förhindra att varje dators lokala administratörskonto kan användas om inte skyddskontrollerna först ångras. Genom att implementera dessa kontroller och övervaka administratörskonton för ändringar kan du avsevärt minska sannolikheten för att ett angrepp som riktar sig mot lokala administratörskonton lyckas.

Konfigurera grupprincipobjekt för att begränsa administratörskonton i Domain-Joined system

I en eller flera GPO:er som du skapar och länkar till arbetsstations- och medlemsserverns OU:er i varje domän, lägg till Administratörskontot till följande användarrättigheter i Datorkonfiguration\Principer\Windows-inställningar\Säkerhetsinställningar\Lokala principer\Tilldelningar av användarrättigheter:

• Neka åtkomst till den här datorn från nätverket
• Neka inloggning som batchjobb
• Neka inloggning som en tjänst
• Neka inloggning via Fjärrskrivbordstjänster

När du lägger till administratörskonton i dessa användarrättigheter anger du om du lägger till det lokala administratörskontot eller domänens administratörskonto på det sätt som du märker kontot. Om du till exempel vill lägga till NWTRADERS-domänens administratörskonto till dessa nekanderättigheter skriver du kontot som NWTRADERS\Administrator eller bläddrar till administratörskontot för NWTRADERS-domänen. Om du vill se till att du begränsar det lokala administratörskontot skriver du Administratör i dessa inställningar för användarrättigheter i redigeraren för grupprincipobjekt.

Anmärkning

Även om lokala administratörskonton byts namn gäller principerna fortfarande.

De här inställningarna säkerställer att en dators administratörskonto inte kan användas för att ansluta till de andra datorerna, även om det är oavsiktligt eller skadligt aktiverat. Lokala inloggningar med det lokala administratörskontot kan inte inaktiveras helt och bör inte heller försöka göra det, eftersom en dators lokala administratörskonto är utformat för att användas i haveriberedskapsscenarier.

Om en medlemsserver eller arbetsstation skulle skiljas från domänen utan andra lokala konton som beviljats administratörsbehörighet, kan datorn startas i felsäkert läge, administratörskontot kan aktiveras och kontot kan sedan användas för att utföra reparationer på datorn. När reparationerna har slutförts bör administratörskontot inaktiveras igen.

Skydda lokala privilegierade konton och grupper i Active Directory

Lag nummer sex: En dator är bara så säker som administratören är betrodd. - Tio oföränderliga säkerhetslagar (version 2.0)

Informationen här är avsedd att ge allmänna riktlinjer för att skydda inbyggda konton och grupper med högsta behörighet i Active Directory. Detaljerade stegvisa instruktioner finns också i bilaga D: Skydda Built-In administratörskonton i Active Directory, bilaga E: Skydda företagsadministratörsgrupper i Active Directory, bilaga F: Skydda domänadministratörsgrupper i Active Directory och i bilaga G: Skydda administratörsgrupper i Active Directory.

Innan du implementerar någon av de här inställningarna bör du också testa alla inställningar noggrant för att avgöra om de är lämpliga för din miljö. Alla organisationer kommer inte att kunna implementera de här inställningarna.

Skydda inbyggda administratörskonton i Active Directory

I varje domän i Active Directory skapas ett administratörskonto som en del av skapandet av domänen. Det här kontot är som standard medlem i domänadministratörs- och administratörsgrupperna i domänen, och om domänen är skogsrotdomänen är kontot också medlem i gruppen Företagsadministratörer. Användning av en domäns lokala administratörskonto bör endast reserveras för inledande byggaktiviteter och eventuellt haveriberedskapsscenarier. För att säkerställa att ett inbyggt administratörskonto kan användas för att utföra reparationer i händelse av att inga andra konton kan användas, bör du inte ändra standardmedlemskapet för administratörskontot i någon domän i skogen. I stället bör du följa riktlinjerna för att skydda administratörskontot i varje domän i skogen. Detaljerade instruktioner för att implementera dessa kontroller finns i bilaga D: Skydda Built-In administratörskonton i Active Directory.

Kontroller för inbyggda administratörskonton

Målet med att implementera inställningarna som beskrivs här är att förhindra att varje domäns administratörskonto (inte en grupp) kan användas om inte ett antal kontroller ångras. Genom att implementera dessa kontroller och övervaka administratörskontona för ändringar kan du avsevärt minska sannolikheten för en lyckad attack genom att utnyttja domänens administratörskonto. För administratörskontot i varje domän i skogen bör du konfigurera följande inställningar.

Aktivera flaggan "Kontot är känsligt och kan inte delegeras" för kontot

Som standard kan alla konton i Active Directory delegeras. Med delegering kan en dator eller tjänst presentera autentiseringsuppgifterna för ett konto som har autentiserats för datorn eller tjänsten till andra datorer för att hämta tjänster för kontots räkning. När du aktiverar kontot är känsligt och inte kan delegeras till ett domänbaserat konto kan kontots autentiseringsuppgifter inte visas för andra datorer eller tjänster i nätverket, vilket begränsar attacker som utnyttjar delegering för att använda kontots autentiseringsuppgifter på andra system.

Aktivera flaggan "Smartkort krävs för interaktiv inloggning" på kontot

När du aktiverar smartkortet krävs för interaktiv inloggningsattribut på ett konto återställer Windows kontots lösenord till ett slumpmässigt värde på 120 tecken. Genom att ange den här flaggan på inbyggda administratörskonton ser du till att lösenordet för kontot inte bara är långt och komplext, utan inte är känt för någon användare. Det är inte tekniskt nödvändigt att skapa smartkort för kontona innan du aktiverar det här attributet, men om möjligt bör smartkort skapas för varje administratörskonto innan du konfigurerar kontobegränsningarna och smartkorten ska lagras på säkra platser.

Även om inställningen av smartkortet krävs för interaktiv inloggningsflagga återställer kontots lösenord, hindrar det inte en användare med behörighet att återställa kontots lösenord från att ange kontot till ett känt värde och använda kontots namn och nya lösenord för att komma åt resurser i nätverket. Därför bör du implementera följande ytterligare kontroller för kontot.

Konfigurera gruppolicys för att begränsa domänadministratörkonton på Domain-Joined systemen

Även om inaktivering av administratörskontot i en domän gör kontot i praktiken oanvändbart bör du implementera ytterligare begränsningar för kontot om kontot är oavsiktligt eller skadligt aktiverat. Även om dessa kontroller i slutändan kan ångras av administratörskontot är målet att skapa kontroller som saktar ned en angripares förlopp och begränsar den skada som kontot kan orsaka.

I en eller flera grupprincipobjekt som du skapar och länkar till arbetsstations- och medlemsserverns organisationsenheter i varje domän lägger du till varje domäns administratörskonto till följande användarrättigheter i Datorkonfiguration\Principer\Windows-inställningar\Säkerhetsinställningar\Lokala principer\Tilldelningar av användarrättigheter:

• Neka åtkomst till den här datorn från nätverket
• Neka inloggning som batchjobb
• Neka inloggning som en tjänst
• Neka inloggning via Fjärrskrivbordstjänster

Anmärkning

När du lägger till lokala administratörskonton i den här inställningen måste du ange om du konfigurerar lokala administratörskonton eller domänadministratörskonton. Om du till exempel vill lägga till NWTRADERS-domänens lokala administratörskonto till dessa nekanderättigheter måste du antingen ange kontot som NWTRADERS\Administrator eller bläddra till det lokala administratörskontot för NWTRADERS-domänen. Om du skriver Administratör i inställningarna för användarrättigheter i redigeraren för grupprincipobjekt begränsar du det lokala administratörskontot på varje dator som grupprincipobjektet tillämpas på.

Vi rekommenderar att du begränsar lokala administratörskonton på medlemsservrar och arbetsstationer på samma sätt som domänbaserade administratörskonton. Därför bör du vanligtvis lägga till administratörskontot för varje domän i skogen och administratörskontot för de lokala datorerna i dessa inställningar för användarrättigheter.

Konfigurera GPO:er för att begränsa administratörskonton på domänkontrollanter

I varje domän i skogen bör standarddomänkontrollantspolicyn eller en policy som är kopplad till domänkontrollanter OU ändras för att lägga till varje domäns administratörskonto till följande användarrättigheter i Datorkonfiguration\Policies\Windows-inställningar\Säkerhetsinställningar\Lokala policies\Användarrättighetstilldelningar:

• Neka åtkomst till den här datorn från nätverket
• Neka inloggning som batchjobb
• Neka inloggning som en tjänst
• Neka inloggning via Fjärrskrivbordstjänster

Anmärkning

De här inställningarna säkerställer att det lokala administratörskontot inte kan användas för att ansluta till en domänkontrollant, även om kontot, om det är aktiverat, kan logga in lokalt på domänkontrollanter. Eftersom det här kontot bara ska aktiveras och användas i haveriberedskapsscenarier förväntas fysisk åtkomst till minst en domänkontrollant vara tillgänglig, eller att andra konton med behörighet att komma åt domänkontrollanter via fjärranslutning kan användas.

Konfigurera granskning av inbyggda administratörskonton

När du har skyddat varje domäns administratörskonto och inaktiverat det bör du konfigurera granskning för att övervaka ändringar i kontot. Om kontot är aktiverat, lösenordet återställs eller om andra ändringar görs i kontot, bör aviseringar skickas till de användare eller team som ansvarar för administrationen av AD DS, förutom incidenthanteringsteam i din organisation.

Skydda administratörer, domänadministratörer och företagsadministratörsgrupper

Skydda företagsadministratörsgrupper

Gruppen Företagsadministratörer, som finns i skogsrotdomänen, bör inte innehålla några användare regelbundet, med möjligt undantag för domänens lokala administratörskonto, förutsatt att det skyddas enligt beskrivningen tidigare och i Bilaga D: Skydda Built-In administratörskonton i Active Directory.

När EA-åtkomst krävs bör de användare vars konton kräver EA-rättigheter och -behörigheter tillfälligt placeras i gruppen Företagsadministratörer. Även om användarna använder konton med hög behörighet bör deras aktiviteter granskas och helst utföras med en användare som utför ändringarna och en annan användare observerar ändringarna för att minimera sannolikheten för oavsiktlig missbruk eller felkonfiguration. När aktiviteterna har slutförts bör kontona tas bort från EA-gruppen. Detta kan uppnås via manuella procedurer och dokumenterade processer, programvara för privilegierad identitets-/åtkomsthantering från tredje part (PIM/PAM) eller en kombination av båda. Riktlinjer för att skapa konton som kan användas för att styra medlemskap i privilegierade grupper i Active Directory finns i Attraktiva konton för stöld av autentiseringsuppgifter och detaljerade instruktioner finns i bilaga I: Skapa hanteringskonton för skyddade konton och grupper i Active Directory.

Företagsadministratörer är som standard medlemmar i den inbyggda gruppen Administratörer i varje domän i skogen. Att ta bort gruppen Företagsadministratörer från administratörsgrupperna i varje domän är en olämplig ändring eftersom EA-rättigheter sannolikt kommer att krävas i händelse av ett haveriberedskapsscenario för skogen. Om gruppen Företagsadministratörer har tagits bort från administratörsgrupper i en skog bör den läggas till i gruppen Administratörer i varje domän och följande ytterligare kontroller bör implementeras:

• Som tidigare beskrivits bör gruppen Företagsadministratörer inte innehålla några användare dagligen, med möjligt undantag för skogsrotsdomänens administratörskonto, som bör skyddas enligt beskrivningen i bilaga D: Skydda Built-In administratörskonton i Active Directory.
• I grupprincipobjekt som är länkade till organisationsenheter som innehåller medlemsservrar och arbetsstationer i varje domän bör EA-gruppen läggas till i följande användarrättigheter:
  • Neka åtkomst till den här datorn från nätverket
  • Neka inloggning som batchjobb
  • Neka inloggning som en tjänst
  • Neka inloggning lokalt
  • Neka inloggning via Fjärrskrivbordstjänster.

Detta förhindrar att medlemmar i EA-gruppen loggar in på medlemsservrar och arbetsstationer. Om jump-servrar används för att administrera domänkontrollanter och Active Directory kontrollerar du att jump-servrarna finns i en organisationsenhet som de restriktiva grupprincipobjekten inte är länkade till.

• Granskning bör konfigureras för att skicka aviseringar om några ändringar görs i egenskaperna eller medlemskapet i EA-gruppen. Dessa aviseringar bör minst skickas till användare eller team som ansvarar för Active Directory-administration och incidenthantering. Du bör också definiera processer och procedurer för att tillfälligt bemanna EA-gruppen, inklusive meddelandeprocedurer när den legitima bemanningen av gruppen utförs.

Skydda domänadministratörsgrupper

Som med gruppen Företagsadministratörer bör medlemskap i domänadministratörsgrupper endast krävas i scenarier med bygg- eller haveriberedskap. Det bör inte finnas några dagliga användarkonton i DA-gruppen, med undantag för det lokala administratörskontot för domänen, om det har skyddats enligt beskrivningen i bilaga D: Skydda Built-In administratörskonton i Active Directory.

När DA-åtkomst krävs bör konton som behöver den här åtkomstnivån tillfälligt placeras i DA-gruppen för den aktuella domänen. Även om användarna använder konton med hög behörighet bör aktiviteter granskas och helst utföras med en användare som utför ändringarna och en annan användare observerar ändringarna för att minimera sannolikheten för oavsiktlig missbruk eller felkonfiguration. När aktiviteterna har slutförts bör kontona tas bort från gruppen Domänadministratörer. Detta kan uppnås via manuella procedurer och dokumenterade processer via programvara för privilegierad identitets-/åtkomsthantering (PIM/PAM) från tredje part, eller en kombination av båda. Riktlinjer för att skapa konton som kan användas för att styra medlemskap i privilegierade grupper i Active Directory finns i bilaga I: Skapa hanteringskonton för skyddade konton och grupper i Active Directory.

Domänadministratörer är som standard medlemmar i de lokala administratörsgrupperna på alla medlemsservrar och arbetsstationer i sina respektive domäner. Den här standardkapslingen bör inte ändras eftersom den påverkar supportalternativen och katastrofberedskapsalternativen. Om "Domain Admins"-grupper har tagits bort från de lokala administratörsgrupperna på medlemsservrarna bör de läggas till i administratörsgruppen på varje medlemsserver och arbetsstation i domänen genom att använda restriktionsinställningar för grupper i länkade grupprincipobjekt. Följande allmänna kontroller, som beskrivs ingående i bilaga F: Skydda domänadministratörsgrupper i Active Directory bör också implementeras.

För gruppen Domänadministratörer i varje domän i skogen:

1. Ta bort alla medlemmar från DA-gruppen, med möjligt undantag för det inbyggda administratörskontot för domänen, förutsatt att det har skyddats enligt beskrivningen i bilaga D: Skydda Built-In administratörskonton i Active Directory.

2. I grupprincipobjekt som är länkade till organisationsenheter som innehåller medlemsservrar och arbetsstationer i varje domän bör DA-gruppen läggas till i följande användarrättigheter:

   • Neka åtkomst till den här datorn från nätverket
   • Neka inloggning som batchjobb
   • Neka inloggning som en tjänst
   • Neka inloggning lokalt
   • Neka inloggning via Fjärrskrivbordstjänster

   Detta förhindrar att medlemmar i DA-gruppen loggar in på medlemsservrar och arbetsstationer. Om jump-servrar används för att administrera domänkontrollanter och Active Directory kontrollerar du att jump-servrarna finns i en organisationsenhet som de restriktiva grupprincipobjekten inte är länkade till.

3. Granskning bör konfigureras för att skicka aviseringar om några ändringar görs i egenskaperna eller medlemskapet i DA-gruppen. Dessa aviseringar bör minst skickas till användare eller team som ansvarar för AD DS-administration och incidenthantering. Du bör också definiera processer och procedurer för att tillfälligt bemanna DA-gruppen, inklusive notifieringsprocedurer när den legitima bemanningen av gruppen sker.

Skydda administratörsgrupper i Active Directory

Som med EA- och DA-grupperna bör medlemskap i gruppen Administratörer (BA) endast krävas i bygg- eller haveriberedskapsscenarier. Det bör inte finnas några dagliga användarkonton i gruppen Administratörer med undantag för det lokala administratörskontot för domänen, om det har skyddats enligt beskrivningen i bilaga D: Skydda Built-In administratörskonton i Active Directory.

När administratörsåtkomst krävs bör konton som behöver den här åtkomstnivån tillfälligt placeras i gruppen Administratörer för den aktuella domänen. Även om användarna använder konton med hög behörighet bör aktiviteter granskas och helst utföras med en användare som utför ändringarna och en annan användare observerar ändringarna för att minimera sannolikheten för oavsiktlig missbruk eller felkonfiguration. När aktiviteterna har slutförts bör kontona omedelbart tas bort från gruppen Administratörer. Detta kan uppnås via manuella procedurer och dokumenterade processer via programvara för privilegierad identitets-/åtkomsthantering (PIM/PAM) från tredje part, eller en kombination av båda.

Administratörer är som standard ägare till de flesta AD DS-objekt i sina respektive domäner. Medlemskap i den här gruppen kan krävas i bygg- och haveriberedskapsscenarier där ägarskap eller möjlighet att ta ägarskap för objekt krävs. Dessutom ärver DA:er och EA:er ett antal av sina rättigheter och behörigheter på grund av deras standardmedlemskap i gruppen Administratörer. Standardgruppkapsling för privilegierade grupper i Active Directory bör inte ändras och varje domäns administratörsgrupp bör skyddas enligt beskrivningen i bilaga G: Skydda administratörsgrupper i Active Directory och i de allmänna anvisningarna nedan.

1. Ta bort alla medlemmar från gruppen Administratörer, med möjligt undantag för det lokala administratörskontot för domänen, förutsatt att det har skyddats enligt beskrivningen i bilaga D: Skydda Built-In administratörskonton i Active Directory.

2. Medlemmar i domänens administratörsgrupp bör aldrig behöva logga in på medlemsservrar eller arbetsstationer. I en eller flera GPO:n som är länkade till arbetsstations- och medlemsserver-organisationsenheter i varje domän bör gruppen Administratörer läggas till för följande användarrättigheter.

   • Neka åtkomst till den här datorn från nätverket
   • Neka inloggning som ett batchjobb,
   • Neka inloggning som en tjänst
   • Detta förhindrar att medlemmar i gruppen Administratörer används för att logga in eller ansluta till medlemsservrar eller arbetsstationer (om inte flera kontroller först överträds), där deras autentiseringsuppgifter kan cachelagras och därmed komprometteras. Ett privilegierat konto bör aldrig användas för att logga in på ett system med mindre privilegier, och om du tillämpar dessa kontroller får du skydd mot ett antal attacker.

3. På domänkontrollanternas organisationsenhet i varje domän i skogen bör gruppen Administratörer beviljas följande användarrättigheter (om de inte redan har dessa rättigheter), vilket gör att medlemmarna i gruppen Administratörer kan utföra de funktioner som krävs för ett skogsomfattande haveriberedskapsscenario:

   • Få åtkomst till den här datorn från nätverket
   • Tillåt lokal inloggning
   • Tillåt inloggning genom Fjärrskrivbordstjänster

4. Granskning bör konfigureras för att skicka aviseringar om några ändringar görs i egenskaperna eller medlemskapet i gruppen Administratörer. Dessa aviseringar bör minst skickas till medlemmar i teamet som ansvarar för AD DS-administration. Aviseringar bör också skickas till medlemmar i säkerhetsteamet och procedurer bör definieras för att ändra medlemskapet i gruppen Administratörer. Specifikt bör dessa processer innehålla en procedur genom vilken säkerhetsteamet kommer att meddelas när gruppen Administratörer ska ändras så att när aviseringar skickas är de förväntade och ett larm inte utlöses. Dessutom bör processer för att meddela säkerhetsteamet när användningen av gruppen Administratörer har slutförts och de konton som används har tagits bort från gruppen implementeras.

Anmärkning

När du implementerar begränsningar för Administratörsgruppen i grupprincipobjekt (GPO) tillämpar Windows inställningarna på medlemmarna i en dators lokala administratörsgrupp samt på administratörsgruppen för domänen. Därför bör du vara försiktig när du implementerar begränsningar för gruppen Administratörer. Även om förbud mot nätverks-, batch- och tjänstinloggningar för medlemmar i gruppen Administratörer rekommenderas oavsett var det är möjligt att implementera, begränsa inte lokala inloggningar eller inloggningar via Fjärrskrivbordstjänster. Att blockera dessa inloggningstyper kan blockera legitim administration av en dator av medlemmar i den lokala gruppen Administratörer. Följande skärmbild visar konfigurationsinställningar som blockerar missbruk av inbyggda lokala konton och domänadministratörskonton, förutom missbruk av inbyggda lokala grupper eller domänadministratörsgrupper. Observera att neka-inloggning via fjärrskrivbordstjänster inte innehåller gruppen Administratörer, eftersom det även skulle blockera inloggningarna för konton som är medlemmar i den lokala datorns administratörsgrupp om du inkluderar den i den här inställningen. Om tjänster på datorer är konfigurerade att köras i kontexten för någon av de privilegierade grupper som beskrivs i det här avsnittet kan implementeringen av dessa inställningar leda till att tjänster och program misslyckas. Som med alla rekommendationer i det här avsnittet bör du därför noggrant testa inställningarna för tillämplighet i din miljö.

Role-Based Åtkomstkontroller (RBAC) för Active Directory

I allmänhet är rollbaserade åtkomstkontroller (RBAC) en mekanism för att gruppera användare och ge åtkomst till resurser baserat på affärsregler. När det gäller Active Directory är implementeringen av RBAC för AD DS processen att skapa roller till vilka rättigheter och behörigheter delegeras så att medlemmar i rollen kan utföra dagliga administrativa uppgifter utan att ge dem för hög behörighet. RBAC för Active Directory kan utformas och implementeras via inbyggda verktyg och gränssnitt genom att använda programvara som du kanske redan äger, genom att köpa produkter från tredje part eller någon kombination av dessa metoder. Det här avsnittet innehåller inte stegvisa instruktioner för att implementera RBAC för Active Directory, utan beskriver i stället faktorer som du bör överväga när du väljer en metod för att implementera RBAC i dina AD DS-installationer.

Inhemska metoder för RBAC för Active Directory

I den enklaste RBAC-implementeringen kan du implementera roller som AD DS-grupper och delegera rättigheter och behörigheter till de grupper som gör det möjligt för dem att utföra daglig administration inom rollens avsedda omfång.

I vissa fall kan befintliga säkerhetsgrupper i Active Directory användas för att bevilja rättigheter och behörigheter som är lämpliga för en jobbfunktion. Om vissa anställda i IT-organisationen till exempel ansvarar för hantering och underhåll av DNS-zoner och -poster kan det vara så enkelt att delegera dessa ansvarsområden som att skapa ett konto för varje DNS-administratör och lägga till det i gruppen DNS-administratörer i Active Directory. GRUPPEN DNS-administratörer har, till skillnad från mer privilegierade grupper, få kraftfulla rättigheter i Active Directory, även om medlemmar i den här gruppen har delegerats behörigheter som gör att de kan administrera DNS och fortfarande utsätts för intrång och missbruk kan leda till utökade privilegier.

I andra fall kan du behöva skapa säkerhetsgrupper och delegera rättigheter och behörigheter till Active Directory-objekt, filsystemobjekt och registerobjekt så att medlemmar i grupperna kan utföra avsedda administrativa uppgifter. Om supportansvariga till exempel ansvarar för att återställa bortglömda lösenord, hjälpa användare med anslutningsproblem och felsöka programinställningar kan du behöva kombinera delegeringsinställningar för användarobjekt i Active Directory med behörigheter som gör att supportavdelningens användare kan fjärransluta till användarnas datorer för att visa eller ändra användarnas konfigurationsinställningar. För varje roll som du definierar bör du identifiera:

1. Vilka uppgifter som medlemmar i rollen utför dagligen och vilka uppgifter som utförs mindre ofta.
2. På vilka system och i vilka program medlemmar i en roll ska beviljas rättigheter och behörigheter.
3. Vilka användare som ska beviljas medlemskap i en roll.
4. Hur hantering av rollmedlemskap ska utföras.

I många miljöer kan det vara svårt att manuellt skapa rollbaserade åtkomstkontroller för administration av en Active Directory-miljö. Om du har tydligt definierade roller och ansvarsområden för administration av IT-infrastrukturen kanske du vill använda ytterligare verktyg för att hjälpa dig att skapa en hanterbar intern RBAC-distribution. Om Till exempel Forefront Identity Manager (FIM) används i din miljö kan du använda FIM för att automatisera skapandet och populationen av administrativa roller, vilket kan underlätta pågående administration. Om du använder Microsoft Endpoint Configuration Manager och System Center Operations Manager (SCOM) kan du använda programspecifika roller för att delegera hanterings- och övervakningsfunktioner och även framtvinga konsekvent konfiguration och granskning mellan system i domänen. Om du har implementerat en offentlig nyckelinfrastruktur (PKI) kan du utfärda och kräva smartkort för IT-personal som ansvarar för att administrera miljön. Med FIM Credential Management (FIM CM) kan du till och med kombinera hantering av roller och autentiseringsuppgifter för din administrativa personal.

I andra fall kan det vara bättre för en organisation att överväga att distribuera RBAC-programvara från tredje part som tillhandahåller "färdiga" funktioner. Ett antal leverantörer erbjuder kommersiella färdiga lösningar (off-the-shelf) för RBAC för Active Directory, Windows och andra kataloger och operativsystem än Windows. När du väljer mellan interna lösningar och produkter från tredje part bör du överväga följande faktorer:

1. Budget: Genom att investera i utveckling av RBAC med hjälp av programvara och verktyg som du redan äger kan du minska de programvarukostnader som ingår i distributionen av en lösning. Men om du inte har personal som har erfarenhet av att skapa och distribuera interna RBAC-lösningar kan du behöva engagera konsultresurser för att utveckla din lösning. Du bör noggrant väga de förväntade kostnaderna för en anpassad utvecklad lösning med kostnaderna för att distribuera en "out-of-box"-lösning, särskilt om din budget är begränsad.
2. It-miljöns sammansättning: Om din miljö främst består av Windows-system, eller om du redan använder Active Directory för hantering av icke-Windows-system och konton, kan anpassade interna lösningar ge den optimala lösningen för dina behov. Om din infrastruktur innehåller många system som inte kör Windows och inte hanteras av Active Directory kan du behöva överväga alternativ för hantering av icke-Windows-system separat från Active Directory-miljön.
3. Privilegiemodell i lösningen: Om en produkt förlitar sig på placeringen av sina tjänstkonton i mycket privilegierade grupper i Active Directory och inte erbjuder alternativ utan att det krävs att alltför hög behörighet beviljas RBAC-programvaran, har du inte riktigt minskat din Active Directory-attackyta, du har bara ändrat sammansättningen av de mest privilegierade grupperna i katalogen. Om inte en programleverantör kan tillhandahålla kontroller för tjänstkonton som minimerar sannolikheten för att kontona komprometteras och används på ett skadligt sätt, kanske du vill överväga andra alternativ.

Hantering av privilegierad identitet

Privileged Identity Management (PIM), som ibland kallas privileged account management (PAM) eller privileged credential management (PCM) är design, konstruktion och implementering av metoder för att hantera privilegierade konton i infrastrukturen. I allmänhet tillhandahåller PIM mekanismer med vilka konton beviljas tillfälliga rättigheter och behörigheter som krävs för att utföra kritiska reparationsfunktioner, i stället för att lämna behörigheter permanent kopplade till konton. Om PIM-funktioner skapas manuellt eller implementeras via distribution av programvara från tredje part kan en eller flera av följande funktioner vara tillgängliga:

• "valv för autentiseringsuppgifter", där lösenord för privilegierade konton "checkas ut" och tilldelas ett första lösenord, och sedan "checkas in" när aktiviteter har slutförts, då lösenord återställs igen på kontona.
• Tidsbundna begränsningar för användningen av privilegierade autentiseringsuppgifter
• Autentiseringsuppgifter för engångsanvändning
• Arbetsflödesgenererad behörighetsbeviljande med övervakning och rapportering av aktiviteter som utförts och automatisk borttagning av privilegier när aktiviteter har slutförts eller tilldelad tid har upphört att gälla
• Ersättning av hårdkodade autentiseringsuppgifter som användarnamn och lösenord i skript med API:er (Application Programming Interfaces) som tillåter att autentiseringsuppgifter hämtas från valv efter behov
• Automatisk hantering av autentiseringsuppgifter för tjänstkonto

Skapa konton utan privilegier för att hantera privilegierade konton

En av utmaningarna med att hantera privilegierade konton är att konton som kan hantera privilegierade och skyddade konton och grupper som standard är privilegierade och skyddade konton. Om du implementerar lämpliga RBAC- och PIM-lösningar för active directory-installationen kan lösningarna innehålla metoder som gör att du effektivt kan avbefolka medlemskapet för de mest privilegierade grupperna i katalogen och fylla i grupperna endast tillfälligt och när det behövs.

Om du implementerar inbyggd RBAC och PIM bör du dock överväga att skapa konton som inte har någon behörighet och med den enda funktionen för att fylla och depopulera privilegierade grupper i Active Directory när det behövs. Bilaga I: Skapa hanteringskonton för skyddade konton och grupper i Active Directory innehåller stegvisa instruktioner som du kan använda för att skapa konton för detta ändamål.

Implementera robusta autentiseringskontroller

Lag nummer sex: Det finns verkligen någon där ute som försöker gissa dina lösenord. - 10 Oföränderliga lagar för säkerhetsadministration

Pass-the-hash- och andra stöldattacker för autentiseringsuppgifter är inte specifika för Windows-operativsystem och är inte heller nya. Den första pass-the-hash-attacken skapades 1997. Historiskt krävde dock dessa attacker anpassade verktyg, var osäkra i sin framgång och krävde att angripare hade en relativt hög grad av skicklighet. Introduktionen av fritt tillgängliga, lätthanterade verktyg som internt extraherar autentiseringsuppgifter har resulterat i en exponentiell ökning av antalet och framgångarna med stöld av autentiseringsuppgifter under de senaste åren. Stöld av autentiseringsuppgifter är dock inte på något sätt de enda mekanismer som autentiseringsuppgifterna är riktade till och komprometteras med.

Även om du bör implementera kontroller för att skydda dig mot stöld av autentiseringsuppgifter, bör du även identifiera de konton i din miljö som är mest sannolika att vara mål för angripare och implementera robusta autentiseringskontroller för dessa konton. Om dina mest privilegierade konton använder enfaktorautentisering, till exempel användarnamn och lösenord (båda är "något du vet", vilket är en autentiseringsfaktor), är dessa konton svagt skyddade. Allt en angripare behöver är kunskap om användarnamnet och lösenordet som är kopplat till kontot. Pass-the-hash-attacker är inte nödvändiga eftersom angriparen kan autentisera sig som användare till alla system som accepterar autentiseringsuppgifter med enkel faktor.

Även om implementering av multifaktorautentisering inte skyddar dig mot pass-the-hash-attacker kan implementering av multifaktorautentisering i kombination med skyddade system. Mer information om hur du implementerar skyddade system finns i Implementera säkra administrativa värdar, och autentiseringsalternativen beskrivs i följande avsnitt.

Allmänna autentiseringskontroller

Om du inte redan har implementerat multifaktorautentisering, till exempel smartkort, bör du överväga att göra det. Smartkort implementerar maskinvarubaserat skydd av privata nycklar i ett offentligt-privat nyckelpar, vilket förhindrar att en användares privata nyckel nås eller används om inte användaren presenterar rätt PIN-kod, lösenord eller biometrisk identifierare för smartkortet. Även om en användares PIN-kod eller lösenord fångas upp av en tangenttryckningsloggare på en komprometterad dator, måste kortet också finnas fysiskt för att en angripare ska kunna återanvända PIN-koden eller lösenordet.

I fall där långa, komplexa lösenord har visat sig vara svåra att implementera på grund av användarmotstånd, ger smartkort en mekanism genom vilken användare kan implementera relativt enkla PIN-koder eller lösenord utan att autentiseringsuppgifterna är mottagliga för råstyrke- eller regnbågstabellattacker. PIN-koder för smartkort lagras inte i Active Directory eller i lokala SAM-databaser, även om hashvärden för autentiseringsuppgifter fortfarande kan lagras i LSASS-skyddat minne på datorer där smartkort har använts för autentisering.

Ytterligare kontroller för VIP-konton

En annan fördel med att implementera smartkort eller andra certifikatbaserade autentiseringsmekanismer är möjligheten att använda Authentication Mechanism Assurance för att skydda känsliga data som är tillgängliga för VIP-användare. Authentication Mechanism Assurance är tillgängligt i domäner där funktionsnivån är inställd på Windows Server 2012 eller Windows Server 2008 R2. När den är aktiverad lägger Authentication Mechanism Assurance till ett globalt gruppmedlemskap som har utsetts av administratör till en användares Kerberos-token när användarens autentiseringsuppgifter autentiseras under inloggningen med hjälp av en certifikatbaserad inloggningsmetod.

Detta gör det möjligt för resursadministratörer att styra åtkomsten till resurser, till exempel filer, mappar och skrivare, baserat på om användaren loggar in med hjälp av en certifikatbaserad inloggningsmetod, utöver den typ av certifikat som används. När en användare till exempel loggar in med ett smartkort kan användarens åtkomst till resurser i nätverket anges som en annan än vad åtkomsten är när användaren inte använder ett smartkort (det vill säga när användaren loggar in genom att ange ett användarnamn och lösenord). Mer information om Authentication Mechanism Assurance finns i stegvis guide för autentiseringsmekanismssäkring för AD DS i Windows Server 2008 R2.

Konfigurera privilegierad kontoautentisering

I Active Directory för alla administrativa konton aktiverar du attributet Kräv smartkort för interaktiv inloggning och granskar för ändringar i (minst), något av attributen på fliken Konto för kontot (till exempel cn, name, sAMAccountName, userPrincipalName och userAccountControl) administrativa användarobjekt.

Även om inställningen Kräv smartkort för interaktiv inloggning på konton återställer kontots lösenord till ett slumpmässigt värde på 120 tecken och kräver smartkort för interaktiva inloggningar, kan attributet fortfarande skrivas över av användare med behörigheter som gör att de kan ändra lösenord på kontona, och kontona kan sedan användas för att upprätta icke-interaktiva inloggningar med endast användarnamn och lösenord.

I andra fall kan, beroende på konfigurationen av konton i Active Directory och certifikatinställningar i Active Directory Certificate Services (AD CS) eller en tredjeparts-PKI, kan UPN-attribut (User Principal Name) för administrativa konton eller VIP-konton riktas mot en viss typ av angrepp, enligt beskrivningen här.

UPN-kapning för förfalskning av certifikat

Även om en grundlig diskussion om attacker mot offentliga nyckelinfrastrukturer (PKIs) ligger utanför omfånget för det här dokumentet, har attacker mot offentliga och privata PKIs ökat exponentiellt sedan 2008. Överträdelser av offentliga PKIs har i stort sett publicerats, men attacker mot en organisations interna PKI är kanske ännu mer produktiva. En sådan attack utnyttjar Active Directory och certifikat så att en angripare kan förfalska autentiseringsuppgifterna för andra konton på ett sätt som kan vara svårt att identifiera.

När ett certifikat visas för autentisering till ett domänanslutet system används innehållet i attributet Ämne eller Alternativt ämnesnamn (SAN) i certifikatet för att mappa certifikatet till ett användarobjekt i Active Directory. Beroende på typen av certifikat och hur det konstrueras innehåller attributet Ämne i ett certifikat vanligtvis en användares eget namn (CN), enligt följande skärmbild.

Som standard skapar Active Directory en användares CN genom att sammanfoga kontots förnamn + " "+ efternamn. CN-komponenter i användarobjekt i Active Directory krävs dock inte eller garanteras vara unika, och om du flyttar ett användarkonto till en annan plats i katalogen ändras kontots unika namn (DN), som är den fullständiga sökvägen till objektet i katalogen, som visas i den nedre rutan i föregående skärmbild.

Eftersom certifikatmottagarens namn inte garanteras vara statiska eller unika används innehållet i det alternativa namnet på certifikatmottagaren ofta för att hitta användarobjektet i Active Directory. SAN-attributet för certifikat som utfärdas till användare från företagscertifikatutfärdare (Active Directory-integrerade certifikatutfärdare) innehåller vanligtvis användarens UPN eller e-postadress. Eftersom UPN:er garanterat är unika i en AD DS-skog utförs ofta lokalisering av ett användarobjekt av UPN som en del av autentiseringen, med eller utan certifikat som ingår i autentiseringsprocessen.

Användningen av UPN i SAN-attribut i autentiseringscertifikat kan användas av angripare för att få bedrägliga certifikat. Om en angripare har komprometterat ett konto som har möjlighet att läsa och skriva UPN på användarobjekt implementeras attacken på följande sätt:

UPN-attributet för ett användarobjekt (till exempel en VIP-användare) ändras tillfälligt till ett annat värde. SAM-kontonamnattributet och CN kan också ändras just nu, även om detta vanligtvis inte är nödvändigt av de skäl som beskrevs tidigare.

När UPN-attributet för målkontot har ändrats ändras ett inaktuellt, aktiverat användarkonto eller ett nyligen skapat användarkontos UPN-attribut till det värde som ursprungligen tilldelades målkontot. Överflödiga, aktiverade användarkonton är konton som inte har loggat in under lång tid utan att ha blivit inaktiverade. De är mål för angripare som tänker "gömma sig i klarsynthet" av följande skäl:

1. Eftersom kontot är aktiverat, men inte har använts nyligen, är det osannolikt att användning av kontot utlöser aviseringar på det sätt som aktivering av ett inaktiverat användarkonto kan göra.
2. Användning av ett befintligt konto kräver inte att ett nytt användarkonto skapas som kan märkas av administrativ personal.
3. Inaktuella användarkonton som fortfarande är aktiverade är vanligtvis medlemmar i olika säkerhetsgrupper och beviljas åtkomst till resurser i nätverket, vilket förenklar åtkomsten och smälter in i den befintliga användarpopulationen.

Det användarkonto där UPN nu har konfigurerats används för att begära ett eller flera certifikat från Active Directory Certificate Services.

När certifikat har hämtats för angriparens konto returneras UPN:erna på det "nya" kontot och målkontot till sina ursprungliga värden.

Angriparen har nu ett eller flera certifikat som kan visas för autentisering för resurser och program som om användaren är den VIP-användare vars konto tillfälligt ändrades. Även om en fullständig diskussion om alla sätt på vilka certifikat och PKI kan riktas mot angripare ligger utanför omfånget för det här dokumentet, tillhandahålls den här attackmekanismen för att illustrera varför du bör övervaka privilegierade och VIP-konton i AD DS för ändringar, särskilt för ändringar av något av attributen på fliken Konto för kontot (till exempel cn, name, sAMAccountName, userPrincipalName och userAccountControl). Förutom att övervaka kontona bör du begränsa vem som kan ändra kontona till en så liten uppsättning administrativa användare som möjligt. På samma sätt bör administrativa användares konton skyddas och övervakas för obehöriga ändringar.