Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Windows Server-operativsystem installeras med lokala standardkonton. Dessutom kan du skapa användarkonton för att uppfylla organisationens krav.
Den här referensartikeln beskriver de lokala Windows Server-standardkonton som lagras lokalt på domänkontrollanten och används i Active Directory. Den beskriver inte lokala standardanvändarkonton för en medlem, fristående server eller Windows-klient. Mer information finns i Lokala konton.
Förvalda lokala konton i Active Directory
Lokala standardkonton är inbyggda konton som skapas automatiskt när en Windows Server-domänkontrollant installeras och domänen skapas. Dessa lokala standardkonton har motsvarigheter i Active Directory. De har också domänomfattande åtkomst och är helt åtskilda från standard lokala användarkonton för en medlem eller fristående server.
Du kan tilldela rättigheter och behörigheter till lokala standardkonton på en viss domänkontrollant och endast på den domänkontrollanten. Dessa konton är lokala för domänen. När de lokala standardkontona har installerats lagras de i containern Användare i Active Directory Användare och datorer. Det är bästa praxis att behålla standard lokala konton i containern Användare och inte försöka flytta dessa konton till till exempel en annan organisationsenhet (OU).
Standard lokala konton i containern Användare är: Administratör, Gäst och KRBTGT. HelpAssistant-kontot installeras när en fjärrhjälpssession upprättas. I följande avsnitt beskrivs de lokala standardkontona och deras användning i Active Directory.
Lokala standardkonton utför följande åtgärder:
- Låt domänen representera, identifiera och autentisera identiteten för den användare som har tilldelats kontot med hjälp av unika autentiseringsuppgifter (användarnamn och lösenord). Det är bästa praxis att tilldela varje användare till ett enda konto för att säkerställa maximal säkerhet. Flera användare får inte dela ett konto. Med ett användarkonto kan en användare logga in på datorer, nätverk och domäner med en unik identifierare som kan autentiseras av datorn, nätverket eller domänen. 
- Auktorisera (bevilja eller neka) åtkomst till resurser. När en användares autentiseringsuppgifter har autentiserats har användaren behörighet att komma åt nätverks- och domänresurserna baserat på användarens uttryckligen tilldelade rättigheter för resursen. 
- Granska de åtgärder som utförs på användarkonton. 
I Active Directory använder administratörer lokala standardkonton för att hantera domän- och medlemsservrar direkt och från dedikerade administrativa arbetsstationer. Active Directory-konton ger åtkomst till nätverksresurser. Active Directory-användarkonton och datorkonton kan representera en fysisk entitet, till exempel en dator eller person, eller fungera som dedikerade tjänstkonton för vissa program.
Varje lokalt standardkonto tilldelas automatiskt till en säkerhetsgrupp som är förkonfigurerad med lämpliga rättigheter och behörigheter för att utföra specifika uppgifter. Active Directory-säkerhetsgrupper samlar in användarkonton, datorkonton och andra grupper i hanterbara enheter. Mer information finns i Active Directory-säkerhetsgrupper.
På en Active Directory-domänkontrollant kallas varje lokalt standardkonto för ett säkerhetsobjekt. Ett säkerhetsobjekt är ett katalogobjekt som används för att skydda och hantera Active Directory-tjänster som ger åtkomst till domänkontrollantresurser. Ett säkerhetsobjekt innehåller objekt som användarkonton, datorkonton, säkerhetsgrupper eller trådar eller processer som körs i säkerhetskontexten för ett användar- eller datorkonto. Mer information finns i Säkerhetsobjekt.
Ett säkerhetsobjekt representeras av en unik säkerhetsidentifierare (SID). De SID:er som är relaterade till vart och ett av de lokala standardkontona i Active Directory beskrivs i nästa avsnitt.
Vissa av de lokala standardkontona skyddas av en bakgrundsprocess som regelbundet kontrollerar och tillämpar en specifik säkerhetsbeskrivning. En säkerhetsbeskrivning är en datastruktur som innehåller säkerhetsinformation som är associerad med ett skyddat objekt. Den här processen säkerställer att alla lyckade obehöriga försök att ändra säkerhetsbeskrivningen på ett av de lokala standardkontona eller grupperna skrivs över med de skyddade inställningarna.
Den här säkerhetsbeskrivningen finns i adminSDHolder-objektet. Om du vill ändra behörigheterna för någon av tjänstadministratörsgrupperna eller på något av dess medlemskonton måste du ändra säkerhetsbeskrivningen för AdminSDHolder-objektet för att säkerställa att den tillämpas konsekvent. Var försiktig när du gör dessa ändringar, eftersom du också ändrar standardinställningarna som tillämpas på alla dina skyddade konton.
Administratörskonto
Ett administratörskonto är ett standardkonto som används i alla versioner av Windows-operativsystemet på varje dator och enhet. Administratörskontot används av systemadministratören för uppgifter som kräver administrativa autentiseringsuppgifter. Det går inte att ta bort eller låsa det här kontot, men kontot kan byta namn eller inaktiveras.
Administratörskontot ger användaren fullständig åtkomst (fullständig behörighet) till filer, kataloger, tjänster och andra resurser som finns på den lokala servern. Du kan använda administratörskontot för att skapa lokala användare och tilldela användarrättigheter och behörigheter för åtkomstkontroll. Du kan också använda kontot för att ta kontroll över lokala resurser när som helst genom att helt enkelt ändra användarrättigheter och behörigheter. Även om filer och kataloger kan skyddas från administratörskontot tillfälligt kan kontot ta kontroll över dessa resurser när som helst genom att ändra åtkomstbehörigheterna.
Medlemskap i kontogrupp
Administratörskontot har medlemskap i standardsäkerhetsgrupperna, enligt beskrivningen i tabellen Attribut för administratörskonto senare i den här artikeln.
Säkerhetsgrupperna ser till att du kan kontrollera administratörsrättigheterna utan att behöva ändra varje administratörskonto. I de flesta fall behöver du inte ändra de grundläggande inställningarna för det här kontot. Du kan dock behöva ändra dess avancerade inställningar, till exempel medlemskap i vissa grupper.
Säkerhetsfrågor
Efter installationen av serveroperativsystemet är din första uppgift att konfigurera egenskaperna för administratörskontot på ett säkert sätt. Detta omfattar att konfigurera ett särskilt långt, starkt lösenord och skydda profilinställningarna Fjärrstyrning och Fjärrskrivbordstjänster.
Administratörskontot kan också inaktiveras när det inte krävs. Om du byter namn på eller inaktiverar administratörskontot blir det svårare för skadliga användare att försöka få åtkomst till kontot. Men även när administratörskontot är inaktiverat kan det fortfarande användas för att få åtkomst till en domänkontrollant med hjälp av felsäkert läge.
På en domänkontrollant blir administratörskontot kontot för domänadministratör. Domänadministratörskontot används för att logga in på domänkontrollanten och det här kontot kräver ett starkt lösenord. Domänadministratörskontot ger dig åtkomst till domänresurser.
Note
När domänkontrollanten först installeras kan du logga in och använda Serverhanteraren för att konfigurera ett lokalt administratörskonto med de rättigheter och behörigheter som du vill tilldela. Du kan till exempel använda ett lokalt administratörskonto för att hantera operativsystemet när du först installerar det. Med den här metoden kan du konfigurera operativsystemet utan att bli utelåst. Vanligtvis behöver du inte använda kontot efter installationen. Du kan bara skapa lokala användarkonton på domänkontrollanten innan Active Directory Domain Services installeras och inte efteråt.
När Active Directory installeras på den första domänkontrollanten i domänen skapas administratörskontot för Active Directory. Administratörskontot är det mest kraftfulla kontot i domänen. Det ges domänomfattande åtkomst och administrativa rättigheter för att administrera datorn och domänen, och den har de mest omfattande rättigheterna och behörigheterna över domänen. Den person som installerar Active Directory Domain Services på datorn skapar lösenordet för det här kontot under installationen.
Administratörskontoattribut
| Attribute | Value | 
|---|---|
| Välkänd SID/RID | S-1-5- <domain>-500 | 
| Type | User | 
| Standardcontainer | CN=Users, DC= <domain>, DC= | 
| Standardmedlemmar | N/A | 
| Standardmedlem i | Administratörer, domänadministratörer, företagsadministratörer, domänanvändare (det primära grupp-ID:t för alla användarkonton är domänanvändare) Ägare av grupprincipskapare och schemaadministratörer i gruppen Active Directory-domänanvändare | 
| Skyddas av AdminSdHolder? | Yes | 
| Är det säkert att flytta ut från standardcontainern? | Yes | 
| Är det säkert att delegera hanteringen av den här gruppen till administratörer som inte är tjänstadministratörer? | No | 
Gästkonto
Gästkontot är ett lokalt standardkonto som har begränsad åtkomst till datorn och är inaktiverat som standard. Som standard lämnas lösenordet för gästkontot tomt. Med ett tomt lösenord kan gästkontot nås utan att användaren behöver ange ett lösenord.
Gästkontot gör det möjligt för tillfälliga eller engångsanvändare, som inte har ett enskilt konto på datorn, att logga in på den lokala servern eller domänen med begränsade rättigheter och behörigheter. Gästkontot kan aktiveras och lösenordet kan konfigureras om det behövs, men bara av en medlem i gruppen Administratör på domänen.
Medlemskap i gästkontogrupp
Gästkontot har medlemskap i standardsäkerhetsgrupperna som beskrivs i följande tabell med attribut för gästkonto. Som standard är gästkontot den enda medlemmen i standardgruppen Gäster, vilket gör att en användare kan logga in på en server och den globala gruppen Domängäster, som låter en användare logga in på en domän.
En medlem i gruppen Administratörer eller Gruppen Domänadministratörer kan konfigurera en användare med ett gästkonto på en eller flera datorer.
Säkerhetsöverväganden för gästkonto
Eftersom gästkontot kan ge anonym åtkomst är det en säkerhetsrisk. Det har också ett välkänt SID. Därför är det bästa praxis att lämna gästkontot inaktiverat, såvida inte dess användning krävs och sedan endast med begränsade rättigheter och behörigheter under en mycket begränsad tidsperiod.
När gästkontot krävs krävs en administratör på domänkontrollanten för att aktivera gästkontot. Gästkontot kan aktiveras utan att ett lösenord krävs, eller så kan det aktiveras med ett starkt lösenord. Administratören beviljar också begränsade rättigheter och behörigheter för gästkontot. Så här förhindrar du obehörig åtkomst:
- Bevilja inte gästkontot behörigheten Stäng av systemanvändaren . När en dator stängs av eller startas är det möjligt att en gästanvändare eller någon med lokal åtkomst, till exempel en obehörig användare, kan få obehörig åtkomst till datorn. 
- Ge inte gästkontot möjlighet att visa händelseloggarna. När gästkontot har aktiverats är det bästa praxis att övervaka det här kontot ofta för att se till att andra användare inte kan använda tjänster och andra resurser, till exempel resurser som oavsiktligt lämnades tillgängliga av en tidigare användare. 
- Använd inte gästkontot när servern har extern nätverksåtkomst eller åtkomst till andra datorer. 
Om du bestämmer dig för att aktivera gästkontot måste du begränsa dess användning och ändra lösenordet regelbundet. Precis som med administratörskontot kanske du vill byta namn på kontot som en extra säkerhetsåtgärd.
Dessutom ansvarar en administratör för att hantera gästkontot. Administratören övervakar gästkontot, inaktiverar gästkontot när det inte längre används och ändrar eller tar bort lösenordet efter behov.
Mer information om attributen för gästkontot finns i följande tabell:
Gästkontoattribut
| Attribute | Value | 
|---|---|
| Välkänd SID/RID | S-1-5- <domain>-501 | 
| Type | User | 
| Standardcontainer | CN=Users, DC= <domain>, DC= | 
| Standardmedlemmar | None | 
| Standardmedlem i | Gäster, Domängäster | 
| Skyddas av AdminSdHolder? | No | 
| Är det säkert att flytta ut från standardcontainern? | Kan flyttas ut, men vi rekommenderar det inte. | 
| Är det säkert att delegera hanteringen av den här gruppen till administratörer som inte är tjänstadministratörer? | No | 
HelpAssistant-konto (installerat med en fjärrhjälpssession)
HelpAssistant-kontot är ett lokalt standardkonto som är aktiverat när en fjärrhjälpssession körs. Det här kontot inaktiveras automatiskt när inga fjärrhjälpsbegäranden väntar.
HelpAssistant är det primära kontot som används för att upprätta en fjärrhjälpssession. Fjärrhjälpssessionen används för att ansluta till en annan dator som kör Windows-operativsystemet och initieras av inbjudan. För begärd fjärrhjälp skickar en användare en inbjudan från sin dator, via e-post eller som en fil, till en person som kan ge hjälp. När användarens inbjudan till en fjärrhjälpssession har godkänts skapas standardkontot HelpAssistant automatiskt för att ge den person som ger hjälp begränsad åtkomst till datorn. HelpAssistant-kontot hanteras av tjänsten Supportsessionshanteraren för fjärrskrivbord.
Säkerhetsöverväganden för HelpAssistant
De SID:ar som gäller för standardkontot HelpAssistant är:
- SID: S-1-5- - <domain>-13, visningsnamnet Terminal Server User. Den här gruppen innehåller alla användare som loggar in på en server med Fjärrskrivbordstjänster aktiverade. I Windows Server 2008 kallas Fjärrskrivbordstjänster terminaltjänster.
- SID: S-1-5- - <domain>-14, visningsnamn Fjärr interaktiv inloggning. Den här gruppen innehåller alla användare som ansluter till datorn med hjälp av en fjärrskrivbordsanslutning. Den här gruppen är en delmängd av den interaktiva gruppen. Åtkomsttokens som innehåller SID för fjärrinteraktiv inloggning innehåller även det interaktiva SID.
För Windows Server-operativsystemet är Fjärrhjälp en valfri komponent som inte är installerad som standard. Du måste installera Fjärrhjälp innan du kan använda den.
Mer information om kontoattributen HelpAssistant finns i följande tabell:
HelpAssistant-kontoattribut
| Attribute | Value | 
|---|---|
| Välkänd SID/RID | S-1-5- <domain>-13 (Terminal Server-användare), S-1-5-<domain>-14 (interaktiv fjärrinloggning) | 
| Type | User | 
| Standardcontainer | CN=Users, DC= <domain>, DC= | 
| Standardmedlemmar | None | 
| Standardmedlem i | Domängäster Guests | 
| Skyddas av AdminSdHolder? | No | 
| Är det säkert att flytta ut från standardcontainern? | Kan flyttas ut, men vi rekommenderar det inte. | 
| Är det säkert att delegera hanteringen av den här gruppen till administratörer som inte är tjänstadministratörer? | No | 
KRBTGT-konto
KRBTGT-kontot är ett lokalt standardkonto som fungerar som ett tjänstkonto för tjänsten Key Distribution Center (KDC). Det går inte att ta bort det här kontot och kontonamnet kan inte ändras. KRBTGT-kontot kan inte aktiveras i Active Directory.
KRBTGT är också det säkerhetshuvudnamn som används av KDC för en Windows Server-domän, enligt RFC 4120. KRBTGT-kontot är entiteten för KRBTGT-säkerhetsobjektet och skapas automatiskt när en ny domän skapas.
Windows Server Kerberos-autentisering uppnås med hjälp av en särskild Kerberos-biljettbeviljande biljett (TGT) som har en symmetrisk nyckel. Den här nyckeln härleds från lösenordet för den server eller tjänst som åtkomst begärs till. TGT-lösenordet för KRBTGT-kontot är endast känt av Kerberos-tjänsten. Om du vill begära en sessionsbiljett måste du presentera TGT för KDC. TGT utfärdas till Kerberos-klienten från KDC.
Överväganden för KRBTGT-kontounderhåll
Ett starkt lösenord tilldelas automatiskt till KRBTGT- och förtroendekontona. Du bör ändra dessa lösenord enligt ett regelbundet schema, precis som med alla privilegierade tjänstkonton. Lösenordet för KDC-kontot används för att härleda en hemlig nyckel för kryptering och dekryptering av de TGT-begäranden som utfärdas. Lösenordet för ett domänförtroendekonto används för att härleda en nyckel mellan domäner för kryptering av hänvisningsbiljetter.
För att återställa lösenordet måste du antingen vara medlem i gruppen Domänadministratörer eller ha tilldelats lämplig behörighet. Dessutom måste du vara medlem i den lokala gruppen Administratörer eller delegeras till lämplig auktoritet.
När du har återställt KRBTGT-lösenordet kontrollerar du att händelse-ID 9 i (Kerberos) Key-Distribution-Center händelsekälla skrivs till systemhändelseloggen.
Säkerhetsöverväganden för KRBTGT-konto
Det är också en bra idé att återställa KRBTGT-kontolösenordet för att säkerställa att en nyligen återställd domänkontrollant inte replikeras med en komprometterad domänkontrollant. I det här fallet kan du i en stor skogsåterställning som är utspridd på flera platser inte garantera att alla domänkontrollanter stängs av och, om de stängs av, att de inte kan startas om igen innan alla lämpliga återställningssteg utförs. När du har återställt KRBTGT-kontot kan en annan domänkontrollant inte replikera det här kontolösenordet med hjälp av ett gammalt lösenord.
En organisation som misstänker att domänen komprometterar KRBTGT-kontot bör överväga användningen av professionella incidenthanteringstjänster. Effekten för att återställa ägarskapet för kontot är domänomfattande, arbetsintensiv och bör utföras som en del av en större återställning.
KRBTGT-lösenordet är nyckeln som all förtroende i Kerberos bygger på. Att återställa KRBTGT-lösenordet liknar att förnya rotcertifikatutfärdarcertifikatet med en ny nyckel och omedelbart inte lita på den gamla nyckeln, vilket resulterar i att nästan alla efterföljande Kerberos-åtgärder påverkas.
För alla kontotyper (användare, datorer och tjänster):
- Alla TGT:er som redan har utfärdats och distribuerats kommer att vara ogiltiga eftersom DC:erna avvisar dem. Dessa biljetter är krypterade med KRBTGT så att vilken domänkontrollant som helst kan validera dem. När lösenordet ändras blir biljetterna ogiltiga. 
- Alla för närvarande autentiserade sessioner som inloggade användare har upprättat (baserat på deras tjänstbiljetter) till en resurs (till exempel en filresurs, SharePoint-webbplats eller Exchange-server) är bra tills tjänstbiljetten krävs för att autentisera igen. 
- NTLM-autentiserade anslutningar påverkas inte. 
Eftersom det är omöjligt att förutsäga de specifika fel som inträffar för en viss användare i en produktionsmiljö måste du anta att alla datorer och användare påverkas.
Important
Att starta om en dator är det enda tillförlitliga sättet att återställa funktioner, eftersom det gör att både datorkontot och användarkontona loggar in igen. När du loggar in igen begär du nya TGT:er som är giltiga med den nya KRBTGT:n, vilket korrigerar eventuella KRBTGT-relaterade driftproblem på denna dator.
Skrivskyddade domänkontrollanter och KRBTGT-kontot
RODC annonseras som Nyckeldistributionscenter (KDC) för avdelningskontoret. RODC använder ett annat KRBTGT-konto och lösenord än KDC på en skrivbar domänkontrollant när den signerar eller krypterar TGT-begäranden. När ett konto har autentiserats avgör RODC om en användares autentiseringsuppgifter eller en dators autentiseringsuppgifter kan replikeras från den skrivbara domänkontrollanten till RODC med hjälp av principen för lösenordsreplikering.
När autentiseringsuppgifterna har cachelagrats på RODC kan RODC acceptera användarens inloggningsbegäranden tills autentiseringsuppgifterna ändras. När en TGT är signerad med KRBTGT-kontot för RODC identifierar RODC att den har en cachelagrad kopia av autentiseringsuppgifterna. Om en annan domänkontrollant signerar TGT vidarebefordrar RODC begäranden till en skrivbar domänkontrollant.
KRBTGT-kontoattribut
Mer information om KRBTGT-kontoattributen finns i följande tabell:
| Attribute | Value | 
|---|---|
| Välkänd SID/RID | S-1-5- <domain>-502 | 
| Type | User | 
| Standardcontainer | CN=Users, DC= <domain>, DC= | 
| Standardmedlemmar | None | 
| Standardmedlem i | Domänanvändare-gruppen (Det primära grupp-ID:t för alla användarkonton är Domänanvändare.) | 
| Skyddas av AdminSdHolder? | Yes | 
| Är det säkert att flytta ut från standardcontainern? | Kan flyttas ut, men vi rekommenderar det inte. | 
| Är det säkert att delegera hanteringen av den här gruppen till administratörer som inte är tjänstadministratörer? | No | 
Inställningar för lokala standardkonton i Active Directory
Varje lokalt standardkonto i Active Directory har flera kontoinställningar som du kan använda för att konfigurera lösenordsinställningar och säkerhetsspecifik information enligt beskrivningen i följande tabell:
| Kontoinställning | Description | 
|---|---|
| Användaren måste ändra lösenordet vid nästa inloggning | Tvingar fram en lösenordsändring nästa gång användaren loggar in i nätverket. Använd det här alternativet när du vill se till att användaren är den enda person som känner till sitt lösenord. | 
| Användaren kan inte ändra lösenord | Förhindrar att användaren ändrar lösenordet. Använd det här alternativet när du vill behålla kontrollen över ett användarkonto, till exempel för ett gästkonto eller ett tillfälligt konto. | 
| Lösenordet löper aldrig ut | Förhindrar att ett användarlösenord upphör att gälla. Det är en bra idé att aktivera det här alternativet med tjänstkonton och använda starka lösenord. | 
| Lagra lösenord med reversibel kryptering | Ger stöd för program som använder protokoll som kräver kunskap om klartextformen för användarens lösenord i autentiseringssyfte. Det här alternativet krävs när du använder Chap (Challenge Handshake Authentication Protocol) i IAS (Internet Authentication Services) och när du använder sammanfattad autentisering i Internet Information Services (IIS). | 
| Kontot är inaktiverat | Förhindrar att användaren loggar in med det valda kontot. Som administratör kan du använda inaktiverade konton som mallar för vanliga användarkonton. | 
| Smartkort krävs för interaktiv inloggning | Kräver att en användare har ett smartkort för att logga in på nätverket interaktivt. Användaren måste också ha en smartkortsläsare ansluten till sin dator och ett giltigt personligt ID-nummer (PIN) för smartkortet. När det här attributet tillämpas på kontot blir effekten följande: | 
| Kontot är betrott för delegering | Låter en tjänst som körs under det här kontot utföra åtgärder för andra användarkonton i nätverket. En tjänst som körs under ett användarkonto (även kallat ett tjänstkonto) som är betrodd för delegering kan personifiera en klient för att få åtkomst till resurser, antingen på den dator där tjänsten körs eller på andra datorer. I en skog som är inställd på funktionsnivån Windows Server 2003 finns till exempel den här inställningen på fliken Delegering. Den är endast tillgänglig för konton som har tilldelats tjänstens huvudnamn (SPN), som anges med hjälp setspnav kommandot från Windows Support Tools. Den här inställningen är säkerhetskänslig och bör tilldelas försiktigt. | 
| Kontot är känsligt och kan inte delegeras | Ger kontroll över ett användarkonto, till exempel ett gästkonto eller ett tillfälligt konto. Det här alternativet kan användas om det här kontot inte kan tilldelas för delegering av ett annat konto. | 
| Använda DES-krypteringstyper för det här kontot | Tillhandahåller stöd för DATA Encryption Standard (DES). DES stöder flera krypteringsnivåer, inklusive Microsoft Point-to-Point Encryption (MPPE) Standard (40-bitars och 56-bitars), MPPE Standard (56-bitars), MPPE Strong (128-bitars), INTERNET Protocol Security (IPSec) DES (40-bitars), IPSec 56-bitars DES och IPSec Triple DES (3DES). | 
| Kräv inte Kerberos-förautentisering | Ger stöd för alternativa implementeringar av Kerberos-protokollet. Eftersom förautentisering ger ytterligare säkerhet bör du vara försiktig när du aktiverar det här alternativet. Domänkontrollanter som kör Windows 2000 eller Windows Server 2003 kan använda andra mekanismer för att synkronisera tid. | 
Note
DES är inte aktiverat som standard i Windows Server-operativsystem (från och med Windows Server 2008 R2) eller i Windows-klientoperativsystem (från och med Windows 7). För dessa operativsystem använder datorer som standard inte DES-CBC-MD5- eller DES-CBC-CRC chiffersviter. Om din miljö kräver DES kan den här inställningen påverka kompatibiliteten med klientdatorer eller tjänster och program i din miljö.
Mer information finns i Jakt efter DES för säker distribution av Kerberos.
Hantera lokala standardkonton i Active Directory
När de lokala standardkontona har installerats finns dessa konton i containern Användare i Active Directory Användare och datorer. Du kan skapa, inaktivera, återställa och ta bort lokala standardkonton med hjälp av Active Directory-användare och datorer i Microsoft Management Console (MMC) och med hjälp av kommandoradsverktyg.
Du kan använda Active Directory-användare och -datorer för att tilldela rättigheter och behörigheter på en angiven lokal domänkontrollant, och endast den domänkontrollanten, för att begränsa möjligheten för lokala användare och grupper att utföra vissa åtgärder. En rättighet ger en användare behörighet att utföra vissa åtgärder på en dator, till exempel att säkerhetskopiera filer och mappar eller stänga av en dator. Däremot är en åtkomstbehörighet en regel som är associerad med ett objekt, vanligtvis en fil, mapp eller skrivare, som reglerar vilka användare som kan ha åtkomst till objektet och på vilket sätt.
Mer information om hur du skapar och hanterar lokala användarkonton i Active Directory finns i Hantera lokala användare.
Du kan också använda Active Directory-användare och -datorer på en domänkontrollant för att rikta fjärrdatorer som inte är domänkontrollanter i nätverket.
Du kan få rekommendationer från Microsoft för domänkontrollantkonfigurationer som du kan distribuera med hjälp av SCM-verktyget (Security Compliance Manager). Mer information finns i Microsoft Security Compliance Manager.
Vissa av de lokala standardanvändarkontona skyddas av en bakgrundsprocess som regelbundet kontrollerar och tillämpar en specifik säkerhetsbeskrivning, vilket är en datastruktur som innehåller säkerhetsinformation som är associerad med ett skyddat objekt. Den här säkerhetsbeskrivningen finns i adminSDHolder-objektet.
Det innebär att när du vill ändra behörigheterna för en tjänstadministratörsgrupp eller på något av dess medlemskonton måste du också ändra säkerhetsbeskrivningen för objektet AdminSDHolder. Den här metoden säkerställer att behörigheterna tillämpas konsekvent. Var försiktig när du gör dessa ändringar, eftersom den här åtgärden också kan påverka standardinställningarna som tillämpas på alla dina skyddade administrativa konton.
Begränsa och skydda känsliga domänkonton
För att begränsa och skydda domänkonton i din domänmiljö måste du använda och implementera följande metodtips:
- Begränsa medlemskapet strikt till grupperna Administratörer, Domänadministratörer och Företagsadministratörer. 
- Kontrollera strikt var och hur domänkonton används. 
Medlemskonton i grupperna Administratörer, Domänadministratörer och Företagsadministratörer i en domän eller skog är värdefulla mål för skadliga användare. För att begränsa exponeringen är det bästa praxis att strikt begränsa medlemskapet till dessa administratörsgrupper till det minsta antalet konton. Om du begränsar medlemskapet i dessa grupper minskar risken för att en administratör oavsiktligt missbrukar dessa autentiseringsuppgifter, vilket skapar en säkerhetsrisk som skadliga användare kan utnyttja.
Dessutom är det bästa praxis att strikt kontrollera var och hur känsliga domänkonton används. Begränsa användningen av domänadministratörskonton och andra administratörskonton för att förhindra att de används för att logga in på hanteringssystem och arbetsstationer som skyddas på samma nivå som de hanterade systemen. När administratörskonton inte är begränsade på det här sättet ger varje arbetsstation som en domänadministratör loggar in från en annan plats som skadliga användare kan utnyttja.
Implementeringen av dessa metodtips är uppdelad i följande uppgifter:
- Separera administratörskonton från användarkonton
- Begränsa administratörsåtkomst till servrar och arbetsstationer
- Inaktivera behörigheten för kontodelegering för känsliga administratörskonton
För att tillhandahålla instanser där integreringsutmaningar med domänmiljön förväntas beskrivs varje uppgift enligt kraven för en minsta, bättre och idealisk implementering. Precis som med alla betydande ändringar i en produktionsmiljö ska du se till att du testar ändringarna noggrant innan du implementerar och distribuerar dem. Stega sedan utrullningen på ett sätt som möjliggör att återställa ändringen om tekniska problem uppstår.
Separera administratörskonton från användarkonton
Begränsa domänadministratörskonton och andra känsliga konton för att förhindra att de används för att logga in på servrar och arbetsstationer med lägre förtroende. Begränsa och skydda administratörskonton genom att skilja administratörskonton från standardanvändarkonton, genom att separera administrativa uppgifter från andra uppgifter och genom att begränsa användningen av dessa konton. Skapa dedikerade konton för administrativ personal som kräver administratörsautentiseringsuppgifter för att utföra specifika administrativa uppgifter och skapa sedan separata konton för andra standardanvändaruppgifter enligt följande riktlinjer:
- Privilegierat konto: Allokera administratörskonton för att endast utföra följande administrativa uppgifter: - Minimum: Skapa separata konton för domänadministratörer, företagsadministratörer eller motsvarande, med lämpliga administratörsrättigheter i domänen eller skogen. Använd konton som har beviljats känsliga administratörsrättigheter endast för att administrera domändata och domänkontrollanter. 
- Bättre: Skapa separata konton för administratörer som har begränsade administrativa rättigheter, till exempel konton för arbetsstationsadministratörer och konton med användarrättigheter över utsedda Active Directory-organisationsenheter (OUs). 
- Perfekt: Skapa flera separata konton för en administratör som har flera jobbansvar som kräver olika förtroendenivåer. Konfigurera varje administratörskonto med olika användarrättigheter, till exempel för administration av arbetsstationer, serveradministration och domänadministration, så att administratören kan logga in på angivna arbetsstationer, servrar och domänkontrollanter baserat på deras jobbansvar. 
 
- Standardanvändarkonto: Bevilja standardanvändarrättigheter för standardanvändaruppgifter, till exempel e-post, webbsurfning och användning av verksamhetsspecifika program (LOB). Dessa konton bör inte beviljas administratörsbehörighet. 
Important
Se till att känsliga administratörskonton inte kan komma åt e-post eller surfa på Internet, enligt beskrivningen i följande avsnitt.
Mer information om privilegierad åtkomst finns i Privilegierade åtkomstenheter.
Begränsa administratörsåtkomst till servrar och arbetsstationer
Det är bästa praxis att begränsa administratörer från att använda känsliga administratörskonton för att logga in på servrar och arbetsstationer med lägre förtroende. Den här begränsningen hindrar administratörer från att oavsiktligt öka risken för stöld av autentiseringsuppgifter genom att logga in på en dator med lägre förtroende.
Important
Kontrollera att du antingen har lokal åtkomst till domänkontrollanten eller att du har skapat minst en dedikerad administrativ arbetsstation.
Begränsa inloggningsåtkomsten till servrar och arbetsstationer med lägre förtroende med hjälp av följande riktlinjer:
- Minimum: Begränsa domänadministratörer från att ha inloggningsåtkomst till servrar och arbetsstationer. Innan du påbörjar den här proceduren bör du identifiera alla organisationsenheter i domänen som innehåller arbetsstationer och servrar. Alla datorer i organisationsenheter som inte identifieras begränsar inte administratörer med känsliga konton från att logga in på dem. 
- Bättre: Begränsa domänadministratörer från icke-domänkontrollantservrar och arbetsstationer. 
- Perfekt: Begränsa serveradministratörer från att logga in på arbetsstationer, förutom domänadministratörer. 
Note
För den här proceduren ska du inte länka konton till den organisationsenhet som innehåller arbetsstationer för administratörer som endast utför administrationsuppgifter och inte tillhandahåller internet- eller e-poståtkomst.
Begränsa åtkomsten för domänadministratörer på arbetsstationer (minimalt)
- Som domänadministratör öppnar du Grupprinciphanteringskonsolen (GPMC). 
- Öppna Grupprinciphantering, expandera <forest>\Domains\ - <domain>.
- Högerklicka på Grupprincipobjekt och välj sedan Nytt.   
- I fönstret Nytt grupprincipobjekt namnger du grupprincipobjektet som begränsar administratörer från att logga in på arbetsstationer och väljer sedan OK.   
- Högerklicka på Nytt grupprincipobjekt och välj sedan Redigera. 
- Konfigurera användarrättigheter för att neka inloggning lokalt för domänadministratörer. 
- Välj Datorkonfigurationsprinciper>>Windows-inställningar>Lokala principer, välj Tilldelning av användarrättigheter och gör sedan följande: - Dubbelklicka på Neka inloggning lokalt och välj sedan Definiera dessa principinställningar. 
- Välj Lägg till användare eller grupp, välj Bläddra, skriv Företagsadministratörer och välj sedan OK. 
- Välj Lägg till användare eller grupp, välj Bläddra, skriv Domänadministratörer och välj sedan OK. 
   - Tip - Du kan också lägga till grupper som innehåller serveradministratörer som du vill begränsa från att logga in på arbetsstationer. - Note - Om du slutför det här steget kan det orsaka problem med administratörsuppgifter som körs som schemalagda aktiviteter eller tjänster med konton i gruppen Domänadministratörer. Metoden att använda domänadministratörskonton för att köra tjänster och uppgifter på arbetsstationer skapar en betydande risk för stöld av autentiseringsuppgifter och bör därför ersättas med alternativa metoder för att köra schemalagda uppgifter eller tjänster. - d. Välj OK för att slutföra konfigurationen. 
- Länka grupprincipobjektet till den första arbetsstationernas organisationsenhet. Gå till sökvägen <forest>\Domains\ - <domain>\OU och gör sedan följande:- a. Högerklicka på arbetsstationens organisationsenhet och välj sedan Länka ett befintligt gruppolicyobjekt.   - b. Välj det grupprincipobjekt som du nyss skapade och välj sedan OK.   
- Testa funktionerna i företagsprogram på arbetsstationer i den första organisationsenheten och lös eventuella problem som orsakas av den nya principen. 
- Länka alla andra organisationsenheter som innehåller arbetsstationer. - Skapa dock inte en länk till organisationsenheten för administrativa arbetsstationer om den skapas för administrativa arbetsstationer som endast är dedikerade till administrationsuppgifter och saknar internet- eller e-poståtkomst. - Important - Om du senare utökar den här lösningen ska du inte neka inloggningsrättigheter för gruppen Domänanvändare. Gruppen Domänanvändare innehåller alla användarkonton i domänen, inklusive Användare, Domänadministratörer och Företagsadministratörer. 
Inaktivera behörigheten för kontodelegering för känsliga administratörskonton
Även om användarkonton inte har markerats för delegering som standard kan konton i en Active Directory-domän vara betrodda för delegering. Det innebär att en tjänst eller en dator som är betrodd för delegering kan personifiera ett konto som autentiserar till den för att få åtkomst till andra resurser i nätverket.
För känsliga konton, till exempel de som tillhör medlemmar i grupperna Administratörer, Domänadministratörer eller Företagsadministratörer i Active Directory, kan delegering utgöra en betydande risk för rättighetseskalering. Om till exempel ett konto i gruppen Domänadministratörer används för att logga in på en komprometterad medlemsserver som är betrodd för delegering, kan servern begära åtkomst till resurser i kontexten för domänadministratörskontot och eskalera kompromissen för medlemsservern till en domänkompromiss.
Det är bästa praxis att konfigurera användarobjekten för alla känsliga konton i Active Directory genom att välja kryssrutan Konto är känsligt och kan inte delegeras under Kontoalternativ för att förhindra att konton delegeras. Mer information finns i Inställningar för lokala standardkonton i Active Directory.
Precis som med alla konfigurationsändringar testar du den här aktiverade inställningen helt för att säkerställa att den fungerar korrekt innan du implementerar den.
               
              
            
Skydda och hantera domänkontrollanter
Det är bästa praxis att strikt tillämpa begränsningar för domänkontrollanterna i din miljö. Detta säkerställer att domänkontrollanterna:
- Kör endast nödvändig programvara.
- Kräv att programvaran uppdateras regelbundet.
- Konfigureras med lämpliga säkerhetsinställningar.
En aspekt av att skydda och hantera domänkontrollanter är att se till att de lokala standardanvändarkontona är helt skyddade. Det är av största vikt att begränsa och skydda alla känsliga domänkonton enligt beskrivningen i föregående avsnitt.
Eftersom domänkontrollanter lagrar hashar för autentiseringsuppgifter för alla konton i domänen är de värdefulla mål för skadliga användare. När domänkontrollanter inte hanteras väl och skyddas med hjälp av begränsningar som tillämpas strikt kan de komprometteras av skadliga användare. En obehörig användare kan till exempel stjäla autentiseringsuppgifter för känslig domänadministratör från en domänkontrollant och sedan använda dessa autentiseringsuppgifter för att attackera domänen och skogen.
Dessutom kan installerade program och hanteringsagenter på domänkontrollanter ge en sökväg för eskalerande rättigheter som skadliga användare kan använda för att kompromettera hanteringstjänsten eller administratörerna för den tjänsten. De hanteringsverktyg och tjänster som din organisation använder för att hantera domänkontrollanter och deras administratörer är lika viktiga för säkerheten för domänkontrollanterna och domänadministratörskontona. Se till att dessa tjänster och administratörer är helt skyddade med samma ansträngning.
Relaterat innehåll
- Säkerhetsobjekt
- översikt över åtkomstkontroll