Guidesidan Ange lösenordsreplikeringsprincip i installationsguiden för Active Directory Domain Services visas när du skapar ett konto för en skrivskyddad domänkontrollant, men bara om du har markerat kryssrutan Använd installation i avancerat läge på sidan Välkommen till guiden Installera Active Directory Domain Services i guiden.
Så här fungerar principen för lösenordsreplikering
Principen för lösenordsreplikering avgör hur autentiseringsuppgifter cachelagras på en skrivskyddad domänkontrollant. Cachelagring av autentiseringsuppgifter innebär lagring av autentiseringsuppgifter för användare och datorer.
När användare eller datorer försöker bli autentiserade i domänen på en plats där det finns en skrivskyddad domänkontrollant kan den skrivskyddade domänkontrollanten inte verifiera autentiseringsuppgifterna som standard. Den skrivskyddade domänkontrollanten vidarebefordrar då autentiseringsbegäran till en skrivbar domänkontrollant. Det kan emellertid finnas en uppsättning säkerhetsobjekt som eventuellt kan utföra autentiseringen på en plats där det finns en skrivskyddad domänkontrollant även om de inte är anslutna till några skrivbara domänkontrollanter.
Du skulle till exempel kunna ha ett antal användare och datorer på en filial som du vill ska kunna autentiseras även om en anslutning saknas mellan filialen och de platser som har skrivbara domänkontrollanter. Du kan lösa det här problemet genom att konfigurera principen för lösenordsreplikering för den skrivskyddade domänkontrollanten så att lösenorden för dessa användare får cachelagras på den skrivskyddade domänkontrollanten. Om kontolösenorden cachelagras på den skrivskyddade domänkontrollanten kan den autentisera dessa konton när det inte finns någon anslutning till skrivbara domänkontrollanter.
Principen för lösenordsreplikering fungerar som en åtkomstkontrollista (ACL). Den avgör om en skrivskyddad domänkontrollant får cachelagra autentiseringsuppgifter om ett konto. När den skrivskyddade domänkontrollanten tar emot en inloggningsbegäran från en användare eller dator försöker den replikera autentiseringsuppgifterna för kontot från en skrivbar domänkontrollant som kör Windows Server 2008 eller Windows Server 2008 R2. Den skrivbara domänkontrollanten undersöker principen för lösenordsreplikering i ett försök att bedöma om kontots autentiseringsuppgifter bör cachelagras. Om principen för lösenordsreplikering tillåter att kontot cachelagras replikerar den skrivbara domänkontrollanten kontots autentiseringsuppgifter till den skrivskyddade domänkontrollanten, som cachelagrar dem. När någon därefter försöker logga in på kontot kan den skrivskyddade domänkontrollanten autentisera kontot genom att jämföra med autentiseringsuppgifterna som har cachelagrats. Den skrivskyddade domänkontrollanten behöver inte ha kontakt med den skrivbara domänkontrollanten.
Principen för lösenordsreplikering i aktion
Principen för lösenordsrepliktering definieras av två flervärda Active Directory-attribut som innehåller säkerhetsobjekt (användare, datorer och grupper). Varje datorkonto på en skrivskyddad domänkontrollant har dessa två attribut:
-
msDS-Reveal-OnDemandGroup, kallas också listan Tillåtna
-
msDS-NeverRevealGroup, kallas också listan Nekade
Som hjälp vid hanteringen av principen för lösenordsreplikering sparas uppgifter om två andra attribut som är tätt sammanbundna med principen för lösenordsreplikering för varje skrivskyddad domänkontrollant:
-
msDS-RevealedUsers, kallas också listan Visa
-
msDS-AuthenticatedToAccountList, kallas också listan Autentiserade till
Attributet msDS-Reveal-OnDemandGroup anger vilka säkerhetsobjekts lösenord som kan cachelagras på en skrivskyddad domänkontrollant. Som standard har detta attribut ett värde, nämligen Tillåten lösenordsreplikering för RODC. Eftersom den här domänlokala gruppen saknar medlemmar som standard kan inga kontolösenord normalt lagras av den skrivskyddade domänkontrollanten.
I det här avsnittet beskrivs hur listattributen Tillåtna, Nekade, Visa och Autentiserade till används.
När en skrivskyddad domänkontrollant skickar en begäran om att replikera en användares lösenord kan begäran tillåtas eller nekas på den skrivbara domänkontrollant med Windows Server 2008 som den skrivskyddade kontrollanten kontaktar. För att avgöra om begäran ska tillåtas eller nekas undersöker den skrivbara domänkontrollanten värdena i listan Tillåtna och listan Nekade för den skrivskyddade domänkontrollant som skickar begäran.
Om det konto vars lösenord begärs av den skrivskyddade domänkontrollanten finns i listan Tillåtna (och inte i listan Nekade) för kontrollanten tillåts begäran.
Följande illustration visar hur denna åtgärd genomförs.
Listan Nekade har företräde framför listan Tillåtna.
Exempel: En organisation har säkerhetsgruppen Administratörer för administratörer. Organisationen har en plats med namnet P1 och en säkerhetsgrupp med namnet Anst_P1 som innehåller de anställda på den platsen. Organisationen har en annan plats med namnet P2 och en säkerhetsgrupp med namnet Anst_P2 som innehåller de anställda på den platsen.
Platsen P2 innehåller bara en RODC. Bob är administratör och arbetar på platsen P2. Därför tillhör han både gruppen Anst_P2 och gruppen Administratörer. När den skrivskyddade domänkontrollanten på P2 installeras läggs de säkerhetsgrupper som visas i nedanstående tabell till i principen för lösenordsreplikering.
| Säkerhetsgrupp | Inställning för lösenordsreplikeringsprincip |
|---|---|
|
Administratörer |
Nekade |
|
Anst_P2 |
Tillåtna |
Den angivna principen innebär att det bara är autentiseringsuppgifterna för de medlemmar av gruppen Anst_P2 som inte är medlemmar av gruppen Administratörer som kan cachelagras på den skrivskyddade domänkontrollanten på platsen P2. Autentiseringsuppgifterna för användare som är medlemmar av grupperna Anst_P1 och Administratörer cachelagras inte på den skrivskyddade domänkontrollanten. Autentiseringsuppgifterna för användare som är medlemmar av gruppen Anst_P2 kan cachelagras på den skrivskyddade domänkontrollanten. Bobs autentiseringsuppgifter cachelagras inte på den skrivskyddade domänkontrollanten.
Standardinställningar för lösenordsreplikeringsprinciper
Varje skrivskyddad domänkontrollant har en lösenordsreplikeringsprincip som bestämmer vilka konton som kan få sina lösenord replikerade till den skrivskyddade domänkontrollanten, och vilka konton som inte kan få det. Standardprincipen anger grupper och inställningar enligt följande tabell.
| Gruppnamn | Inställning för lösenordsreplikeringsprincip |
|---|---|
|
Administratörer |
Neka |
|
Serveransvariga |
Neka |
|
Ansvariga för säkerhetskopiering |
Neka |
|
Kontoansvariga |
Neka |
|
Gruppen Nekad lösenordsreplikering för RODC |
Neka |
|
Gruppen Tillåten lösenordsreplikering för RODC |
Tillåt |
Gruppen Nekad lösenordsreplikering för RODC innehåller som standard följande domänkontomedlemmar:
-
Certifikatpublicerare
-
Domänadministratörer
-
Företagsadministratörer
-
Företagets domänkontrollanter
-
Företagets skrivskyddade domänkontrollanter
-
Skapare och ägare av grupprincip
-
krbtgt
-
Schemaadministratörer
Gruppen Tillåten lösenordsreplikering för RODC har inga medlemmar som standard.
Standardprincipen för lösenordsreplikering förbättrar säkerheten för en installerad skrivskyddad domänkontrollant genom att inga kontolösenord lagras som standard samt att lösenorden för konton som är känsliga ur säkerhetssynpunkt (t.ex. medlemmar av gruppen Domänadministratörer) uttryckligen aldrig kan lagras på den skrivskyddade domänkontrollanten.
Ändra standardprincipen för lösenordsreplikering
Du kan ändra standardprincipen för lösenordsreplikering när du skapar ett konto för den skrivskyddade domänkontrollanten eller efter att kontot har skapats. Om du vill ändra standardprincipen efter att RODC-kontot har skapats högerklickar du på kontot i organisationsenheten Domänkontrollanter i snapin-modulen Active Directory - användare och datorer. Välj Egenskaper och klicka på fliken Lösenordsreplikeringsprincip. (Öppna snapin-modulen Active Directory - användare och datorer genom att klicka på Start, peka på Administrationsverktyg och klicka på Active Directory - användare och datorer.)
Om du vill lägga till konton i standardprincipen för lösenordsreplikering när du skapar RODC-kontot klickar du på Lägg till på guidesidan Ange lösenordsreplikeringsprincip och anger sedan om du vill tillåta eller neka att lösenord för kontot lagras på den skrivskyddade domänkontrollanten. Därefter kan du ange vilka konton som ska läggas till i dialogrutan Välj användare, datorer eller grupper.
Du måste inkludera rätt användar-, dator- och tjänstkonton i principen för lösenordsreplikering om autentiserings- och tjänstbiljettbegäranden ska kunna hanteras lokalt på den skrivskyddade domänkontrollanten. Om du inte inkluderar de datorkonton som filialkontorets användare kommer att använda för att logga in på nätverket i listan Tillåten kan tjänstbiljettbegäranden inte hanteras lokalt på den skrivskyddade domänkontrollanten. Om sådana begäranden ska kunna hanteras krävs åtkomst till en skrivbar domänkontrollant. Om WAN (wide area network) är offline kan tjänstproblem uppstå.
Inställningen Neka har företräde framför inställningen Tillåt. Om båda inställningarna anges för en användare (antingen direkt eller indirekt genom att användaren är medlem i en säkerhetsgrupp som har angetts, eller som är inkapslad i en angiven säkerhetsgrupp) kan användarens lösenord inte lagras på den skrivskyddade domänkontrollanten. Observera dock att en användare vars lösenord inte lagras på en RODC ändå kan använda den för att logga in om en WAN-anslutning till en skrivbar domänkontrollant är tillgänglig. Användarens lösenord replikeras inte till den skrivskyddade domänkontrollanten, men inloggningen kan autentiseras av den skrivbara domänkontrollanten via WAN-anslutningen.
I nedanstående tabell beskrivs för- och nackdelar med tre olika exempelkonfigurationer av en princip för lösenordsreplikering.
| Exempel | Fördelar | Nackdelar |
|---|---|---|
|
Inga konton cachelagras (standard). |
Säkrast – användarna autentiseras av en skrivbar domänkontrollant och de erhåller en grupprincip från den skrivskyddade domänkontrollanten för snabb principhantering. |
Ingen åtkomst offline för någon – ett WAN krävs för inloggning. |
|
De flesta konton cachelagras. |
Enkel lösenordshantering – det här alternativet är avsett för organisationer som har störst glädje av att förbättra hanteringen av den skrivskyddade domänkontrollanten, inte säkerheten. |
Fler lösenord kan tänkas överföras till en skrivskyddad domänkontrollant. |
|
Få konton cachelagras. |
Detta möjliggör åtkomst offline till de användare som behöver ha det men erbjuder högre säkerhet än att cachelagra de flesta konton. |
Den här metoden kräver mer administrativa åtgärder. Du kan behöva mappa användare och datorer till varje filial som har en skrivskyddad domänkontrollant. Du kan även använda verktyg, t.ex. repadmin /prp, för att flytta konton som har autentiserats på en skrivskyddad domänkontrollant till en grupp i listan Tillåten. Du kan även behöva använda ILM (Identity Lifecycle Manager) för att automatisera processen. |
I följande avsnitt förklaras varje exempel mer detaljerat.
Inga konton cachelagras
Det här exemplet är det säkraste alternativet. Inga lösenord replikeras till den skrivskyddade domänkontrollanten förutom dess datorkonto och det speciella kontot krbtgt. Om användare och datorer ska kunna autentiseras krävs emellertid ett WAN. Det här exemplet har den fördelen att det krävs lite eller ingen ytterligare administrativ konfiguration utöver standardinställningarna.
Om du vill kan du välja att lägga till egna känsliga användargrupper i listan Nekade. Även om inga konton cachelagras som standard kan du skydda dina egna känsliga användargrupper mot att bli tillagda i listan Tillåtna – vilket gör att deras lösenord sedermera cachelagras av den skrivskyddade domänkontrollanten – av misstag.
Observera att den delegerade administratören av den skrivskyddade domänkontrollanten inte automatiskt läggs till i listan Tillåtna. Du bör lägga till den delagerade administratören av den skrivskyddade domänkontrollanten i listan Tillåtna för att se till att denne alltid kan logga in på den skrivskyddade domänkontrollanten, oavsett om det finns en WAN-anslutning till en skrivbar domänkontrollant eller inte.
De flesta konton cachelagras
Det här exemplet är det enklaste administrationsläget och undanröjer behovet av en WAN-anslutning för autentisering av användare och datorer. I det här exemplet fyller du listan Tillåtna för alla skrivskyddade domäner med grupper som representerar en stor del av användar- och datorpopulationen. Listan Nekade tillåter inte att känsliga användargrupper, t.ex. domänadministratörer, får sina lösenord cachelagrade. De flesta användares lösenord kan emellertid cachelagras på begäran. Om du vill kan du välja att lägga till egna känsliga användargrupper i listan Nekade.
Den här konfigurationen är lämpligast i miljöer där den fysiska säkerheten för den skrivskyddade domänkontrollanten inte hotas. Du skulle till exempel kunna konfigurera principen för lösenordsreplikering på det här viset för en skrivskyddad domänkontrollant som du har ställt på en säker plats huvudsakligen för att dra nytta av dess begränsade krav på replikering och administration.
 | Viktigt! |
|
Du måste även lägga till användarnas datorkonton i listan Tillåtna så att dessa användare kan logga in på filialkontoret när WAN-anslutningen inte fungerar. |
Få konton cachelagras
I det här exempelt begränsas vilka konton som kan cachelagras. Detta är något som normalt anges särskilt för varje skrivskyddad domänkontrollant: varje sådan har olika användar- och datorkonton som får cachelagras. Det här exemplet gäller vanligtvis ett antal användare som arbetar på en särskild plats.
Fördelen med det här exemplet är att ett antal användare kan logga in på nätverket och autentiseras av den skrivskyddade domänkontrollanten på filialkontoret även om WAN-anslutningen inte fungerar. Samtidigt begränsas risken för att många lösenord avslöjas eftersom det endast är ett fåtal användares lösenord som cachelagras.
Det krävs en del administration för att fylla listan Tillåtna och Nekade i det här exemplet. Det finns ingen automatisk standardmetod för att läsa konton från den kända listan med säkerhetsobjekt som har autentiserats gentemot en given skrivskyddad domänkontrollant och det finns heller ingen standardmetod för att fylla listan Tillåtna med dessa konton. Du kan flytta dessa konton till en grupp i listan Tillåtna med hjälp av kommandot repadmin /prp move eller så kan du använda skript eller program såsom ILM för att bygga upp en process.
Även om du kan lägga till användar- och datorkonton direkt i listan Tillåtna bör du hellre skapa en säkerhetsgrupp för varje skrivskyddad domänkontrollant, lägga till den i listan Tillåtna och sedan lägga till användar- och datorkonton i säkerhetsgruppen. På det här viset kan du använda standardverktyg för grupphantering såsom snapin-modulen Active Directory – användare och datorer eller kommandotolkverktygen Dsadd eller Dsmod för att bestämma vilka konton som får cachelagras på den skrivskyddade domänkontrollanten.
Kommandot repadmin /prp move kräver att en säkerhetsgrupp anges. Om den säkerhetsgrupp du anger inte finns skapas den och läggs till i listan Tillåtna.
Som i det föregående exemplet måste du även lägga till lämpliga datorkonton i listan Tillåtna.