Hantera RID-utfärdande

Den här artikeln förklarar ändringen av RID-huvudrollen för FSMO, inklusive de nya funktionerna för utfärdande och övervakning i RID-huvudservern och hur du analyserar och felsöker RID-utfärdande.

• Hantera RID-utfärdande

• Felsöka RID-utfärdande

Mer information finns på AskDS-bloggen.

Hantera RID-utfärdande

Som standard har en domän kapacitet för ungefär en miljard säkerhetsobjekt, till exempel användare, grupper och datorer. Naturligtvis finns det inga domäner med så många aktivt använda objekt. Microsofts kundsupport har dock hittat fall där:

• Etablering av programvara eller administrativa skript skapade användare, grupper och datorer av misstag.

• Många oanvända säkerhets- och distributionsgrupper skapades av delegerade användare

• Många domänkontrollanter degraderades, återställdes eller metadata rensades

• Skogens återställningar utfördes

• Åtgärden InvalidateRidPool utfördes ofta

• REGISTERvärdet för RID-blockstorlek ökades felaktigt

Alla dessa situationer använder RID i onödan, ofta av misstag. Under många år tog några miljöer slut på RID:er och detta tvingade dem att migrera till en ny domän eller utföra återställningar av skogar.

Windows Server 2012 löser problem med RID-allokering som bara har blivit problematiska med åldern och allestädes närvarande Active Directory. Dessa inkluderar bättre händelseloggning, lämpligare gränser och möjligheten att i en nödsituation fördubbla den totala storleken på det globala RID-utrymmet för en domän.

Varningar om periodisk förbrukning

Windows Server 2012 lägger till global spårning av RID-rymdhändelser som ger tidig varning när viktiga milstolpar korsas. Modellen beräknar det tio (10) procent använda märket i den globala poolen och loggar en händelse när den nås. Sedan beräknas nästa tio procent av det återstående beloppet som används, och händelsecykeln fortsätter. När det globala RID-utrymmet är uttömt accelereras händelserna när tio procent når snabbare i en minskande pool (men dämpning av händelseloggar förhindrar mer än en inmatning per timme). Systemhändelseloggen på varje domänkontroller skriver Directory -Services-SAM varningshändelse 16658.

Om vi antar ett standard 30-bitars globalt RID-utrymme loggar den första händelsen när poolen som innehåller 107 374 182^nd RID allokeras. Händelsefrekvensen accelererar naturligt fram till den sista kontrollpunkten på 100 000, med totalt 110 händelser genererade. Beteendet liknar ett olåst 31-bitars globalt RID-utrymme: från 214 748 365 och slutför i 117 händelser.

Ogiltighetshändelser för RID-pool

Det finns nya händelseaviseringar om att en lokal DC RID-pool har ignorerats. Dessa är informationsbaserade och kan förväntas, särskilt på grund av den nya VDC-funktionen. Mer information om händelsen finns i händelselistan nedan.

Storleksgräns för RID-block

Normalt begär en domänkontrollant RID-allokeringar i block med 500 RID:er samtidigt. Du kan åsidosätta den här standardinställningen med hjälp av följande register REG_DWORD värde på en domänkontrollant:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\RID Values
RID Block Size

Före Windows Server 2012 fanns det inget högsta värde som tillämpades i registernyckeln, förutom det implicita DWORD-maxvärdet (som har värdet 0xffffffff eller 4294967295). Det här värdet är betydligt större än det totala globala RID-utrymmet. Administratörer har ibland felaktigt eller av misstag konfigurerat RID-blockstorlek med värden som uttömde det globala RID i en massiv takt.

I Windows Server 2012 kan du inte ange det här registervärdet som är högre än 15 000 decimaler (0x3A98 hexadecimalt). Detta förhindrar massiv oavsiktlig RID-allokering.

Om du anger värdet högre än 15 000 behandlas värdet som 15 000 och domänkontrollanten loggar händelse 16653 i Directory Services-händelseloggen vid varje omstart tills värdet har korrigerats.

Upplåsning av global RID-utrymmesstorlek

Före Windows Server 2012 var det globala RID-utrymmet begränsat till 2³⁰ (eller 1 073 741 823) totala RID:er. När den har nåtts tillät endast en domänmigrering eller skogsåterställning till en äldre tidsram att nya SID:er skapades – haveriberedskap, oavsett mått. Från och med Windows Server 2012 kan 2³¹-bitarsgränsen upplåsas för att öka den globala poolen till 2 147 483 648 RID:er.

AD DS lagrar den här inställningen i ett särskilt dolt attribut med namnet SidCompatibilityVersion i RootDSE-kontexten för alla domänkontrollanter. Det här attributet kan inte läsas med ADSIEdit, LDP eller andra verktyg. Om du vill se en ökning av det globala RID-utrymmet går du till systemhändelseloggen efter varningshändelse 16655 från Directory–Services-SAM eller använder följande Dcdiag-kommando:

Dcdiag.exe /TEST:RidManager /v | find /i "Available RID Pool for the Domain"

Om du ökar den globala RID-poolen ändras den tillgängliga poolen till 2 147 483 647 i stället för standardvärdet 1 073 741 823. Till exempel:

Viktiga varningar

Windows Server 2003 och Windows Server 2008-domänkontrollanter kan inte utfärda RID när den globala RID-poolen 31^st bit är upplåst. Windows Server 2008 R2-domänkontrollanter kan använda 31:a bitars RIDs men bara om de har snabbkorrigering KB 2642658 installerad. Domänkontrollanter som inte stöds och som inte stöds behandlar den globala RID-poolen som uttömd när den låses upp.

Den här funktionen tillämpas inte av någon domänfunktionsnivå. Var noga med att endast Windows Server 2012 eller uppdaterade Windows Server 2008 R2-domänkontrollanter finns i domänen.

Implementera olåst globalt RID-utrymme

Utför följande steg för att frigöra RID-poolen till och med den 31^:a biten efter att ha fått RID-taksgränsvarningen (se nedan):

1. Kontrollera att RID-huvudrollen körs på en Windows Server 2012-domänkontrollant. Annars överför du den till en Windows Server 2012-domänkontrollant.

2. Kör LDP.exe

3. Välj menyn Anslutning och välj Anslut för Windows Server 2012 RID Master på port 389 och välj sedan Bind som domänadministratör.

4. Välj menyn Bläddra och välj Ändra.

5. Kontrollera att DN är tomt.

6. I Redigera postattribut skriver du:

   SidCompatibilityVersion
   

7. I Värden skriver du:

   1
   

8. Kontrollera att Lägg till är markerat i Åtgärd och välj Retur. Då uppdateras postlistan.

9. Välj alternativen Synkron och Utökad och välj sedan Kör.

   

10. Om det lyckas visar LDP-utdatafönstret:

    ***Call Modify...
     ldap_modify_ext_s(Id, '(null)',[1] attrs, SvrCtrls, ClntCtrls);
    modified "".
    
    

    

11. Bekräfta att den globala RID-poolen har ökat genom att undersöka systemhändelseloggen på domänkontrollanten för Katalog-Services-SAM Informationshändelse 16655.

RID-gräns efterlevnad

För att ge ett mått på skydd och öka den administrativa medvetenheten introducerar Windows Server 2012 ett artificiellt tak för det globala RID-intervallet på tio (10) procent återstående RID i det globala utrymmet. När de befinner sig inom en (1) procent av det artificiella taket, skriver domänkontrollanter som begär RID-pooler katalog-Services-SAM varning händelse-16656 till deras systemets händelseloggar. När du når tio procents taket på RID Master FSMO, skriver den Directory-Services-SAM händelse 16657 till sin systemlogg och allokerar inte ytterligare RID-pooler förrän det överstiger taket. Detta tvingar dig att utvärdera tillståndet för RID-mastern i domänen och ta itu med potentiell okontrollerad RID-tilldelning. Det skyddar också domäner från att förbruka hela RID-utrymmet.

Det här taket är hårdkodat så att tio procent av det tillgängliga RID-utrymmet återstår. Det innebär att taket aktiveras när RID-mastern allokerar en pool som innehåller RID som motsvarar nittio (90) procent av det globala RID-utrymmet.

• För standarddomäner är den första utlösarpunkten 2³⁰-1 * 0,90 = 966 367 640 (eller 107 374 183 RID som återstår).

• För domäner med upplåst 31-bitars RID-utrymme är utlösarpunkten 2³¹–1 * 0,90 = 1 932 735 282 RID :er (eller 214 748 365 RID:er kvar).

När den aktiveras ställer RID-mästaren in attributet msDS-RIDPoolAllocationEnabled i Active Directory (vanligt namn ms-DS-RID-Pool-Allocation-Enabled) till FALSE på objektet:

CN=RID-chef$,CN=System,DC=<domän>

Detta skriver 16657-händelsen och förhindrar ytterligare RID-blockutfärdning till alla domänkontrollanter. Domänkontrollanter fortsätter att använda alla utestående RID-pooler som redan har utfärdats till dem.

Om du vill ta bort blocket och tillåta att RID-poolallokeringen fortsätter anger du värdet till TRUE. Vid nästa RID-allokering som utförs av RID-huvudservern återgår attributet till standardvärdet NOT SET. Därefter finns det inga ytterligare tak och så småningom tar det globala RID-utrymmet slut, vilket kräver skogsåterställning eller domänmigrering.

Ta bort takblocket

Utför följande steg för att ta bort blocket när det når det artificiella taket:

1. Kontrollera att RID-huvudrollen körs på en Windows Server 2012-domänkontrollant. Annars överför du den till en Windows Server 2012-domänkontrollant.

2. Kör LDP.exe.

3. Välj menyn Anslutning och välj Anslut för Windows Server 2012 RID Master på port 389 och välj sedan Bind som domänadministratör.

4. Välj menyn Visa och därefter Träd, välj sedan Bas-DN och RID-masterns egen domännamngivningskontext. Välj Ok.

5. I navigeringsfönstret ökar du detaljnivån i CN=System-containern och väljer objektet CN=RID Manager$ . Högerklicka på den och välj Ändra.

6. I Redigera postattribut skriver du:

   MsDS-RidPoolAllocationEnabled
   

7. I Värden skriver du (i versaler):

   TRUE
   

8. Välj Ersätt i Åtgärd och välj Retur. Då uppdateras postlistan.

9. Aktivera alternativen Synkron och Utökad och välj sedan Kör:

   

10. Om det lyckas visar LDP-utdatafönstret:

    ***Call Modify...
    ldap_modify_ext_s(ld, 'CN=RID Manager$,CN=System,DC=<domain>',[1] attrs, SvrCtrls, ClntCtrls);
    Modified "CN=RID Manager$,CN=System,DC=<domain>".
    
    

    

Andra RID-korrigeringar

Tidigare Windows Server-operativsystem hade en RID-poolläcka när attributet rIDSetReferences saknades. Lös problemet på domänkontrollanter som kör Windows Server 2008 R2 genom att installera snabbkorrigeringen från KB-2618669.

Ofixerade RID-problem

Det har historiskt varit en RID-läcka vid fel vid kontoskapande, eftersom ett RID fortfarande används när du försöker skapa ett konto och det misslyckas. Det vanliga exemplet är att skapa en användare med ett lösenord som inte uppfyller komplexiteten.

RID-korrigeringar för tidigare versioner av Windows Server

Alla korrigeringar och ändringar ovan har Windows Server 2008 R2-snabbkorrigeringar släppta. Det finns för närvarande inga planerade eller pågående Snabbkorrigeringar för Windows Server 2008.

Felsökning av RID-utfärdande

Introduktion till felsökning

Felsökning av RID-utfärdande kräver en logisk och linjär metod. Såvida du inte övervakar dina händelseloggar noggrant för RID-utlösta varningar och fel, kommer dina första indikationer på ett problem sannolikt att vara misslyckade kontoskapanden. Nyckeln till att felsöka RID-utfärdande är att förstå när symptomet förväntas eller inte. många RID-utfärdandeproblem kan bara påverka en domänkontrollant och har inget att göra med komponentförbättringar. Det här enkla diagrammet nedan hjälper dig att göra dessa beslut tydligare:

Felsökningsalternativ

Loggningsalternativ

All loggning i RID-utfärdande sker i systemhändelseloggen under källan Directory-Services-SAM. Loggning är aktiverat och konfigurerat för maximal verbositet som standard. Om inga poster loggas för de nya komponentändringarna i Windows Server 2012, behandlar du problemet som ett klassiskt RID-utfärdandeproblem (även kallat äldre, före Windows Server 2012) som förekommer i Windows 2008 R2 eller äldre operativsystem.

Verktyg och kommandon för felsökning

Om du vill felsöka problem som inte förklaras av ovan nämnda loggar – särskilt äldre RID-utfärdandeproblem – använder du följande lista med verktyg som utgångspunkt:

• Dcdiag.exe

• Repadmin.exe

• Nätverksövervakare 3.4

Allmän metod för felsökning av konfiguration av domänkontrollant

1. Orsakas felet av ett problem med enkel behörighet eller domänkontrollanttillgänglighet?

   1. Försöker du skapa en säkerhetsprincip utan nödvändiga behörigheter? Granska utdata för åtkomstnekade fel.

   2. Är en domänkontrollant tillgänglig? Granska det returnerade felet eller LDAP- eller domänkontrollantens tillgänglighetsmeddelanden.

2. Nämner felet som returnerades specifikt RID:erna och är tillräckligt specifikt för att användas som vägledning? I så fall följer du riktlinjerna.

3. Nämner det returnerade felet specifikt RID:erna, men är annars icke specifikt? Till exempel "Windows kan inte skapa objektet eftersom katalogtjänsten inte kunde allokera en relativ identifierare.".

   1. Granska systemhändelseloggen på domänkontrollanten efter "äldre" (före Windows Server 2012) RID-händelser som beskrivs i RID-poolbegäran (16642, 16643, 16644, 16645, 16656).

   2. Undersök systemhändelsen på domänkontrollanten och RID-hanteraren för nya blockindikeringshändelser som beskrivs nedan i den här artikeln (16655, 16656, 16657).

   3. Verifiera Active Directory-replikeringshälsa med Repadmin.exe och RID Master-tillgänglighet med Dcdiag.exe /test:ridmanager /v. Aktivera dubbelsidiga nätverksinsamlingar mellan domänkontrollanten och RID-mastern om dessa tester är ofullständiga.

Felsökning av specifika problem

Följande nya meddelanden loggas i systemhändelseloggen på Windows Server 2012-domänkontrollanter. Automatiserade AD-hälsospårningssystem, till exempel System Center Operations Manager, bör övervaka dessa händelser. alla är anmärkningsvärda och vissa är indikatorer på kritiska domänproblem.

Se även

• Hantera RID-utfärdande i Windows Server 2012