Windows-uppdateringar lägger till nya NTLM-direktautentiseringsskydd för CVE-2022-21857

Ursprungligt KB-nummer: 5010576

När du har installerat Windows-uppdateringarna från 11 januari 2022 eller senare som innehåller skydd för CVE-2022-21857, tillämpar domänkontrollanter (DCs) nya säkerhetskontroller för NTLM-begäranden om direktautentisering som skickas av en betrodd domän över en domän eller ett skogsförtroende eller skickas av en skrivskyddad domänkontrollant (RODC) över ett säkert kanalförtroende. De nya säkerhetskontrollerna kräver att domänen eller klienten som autentiseras är lämplig för det förtroende som används. Mer specifikt avvisar säkerhetskontroller som är lämpliga för den förtroendetyp som används NTLM-begäran om direktautentisering om följande krav inte uppfylls:

• Begäranden över ett domänförtroende måste använda samma domännamn som den betrodda domänen.
• Begäranden över ett skogsförtroende måste använda ett domännamn som är medlem i den betrodda skogen och som inte har någon namnkollision från andra skogar.
• Begäranden som vidarebefordras av en RODC måste använda ett klientnamn som RODC tidigare har behörighet att cachelagrat hemligheter för.

För att stödja valideringar av domän- och skogsförtroende uppdateras den primära domänkontrollanten (PDC) för rotdomänen i varje skog för att regelbundet utfärda LDAP-frågor (Lightweight Directory Access Protocol). Frågorna utfärdas var åttonde timme för alla domännamn i varje betrodd skog, som kallas "genomsökning av förtroende". Dessa domännamn lagras i msDS-TrustForestTrustInfo attributet för motsvarande betrodda domänobjekt (TDO).

Förutsättningar

Allt som blockerar LDAP-aktivitetstrafik, autentisering och auktorisering från en betrodd skogs PDC till den betrodda skogen orsaka ett problem när nya förtroendegenomsökningsbeteenden läggs till av uppdateringarna:

• Om brandväggar används måste TCP- och UDP-portarna 389 tillåtas mellan den betrodda PDC:n och betrodda domän-DCs, samt kommunikationen för att hantera förtroendet (namnmatchning, RPC för NTLM och port 88 för Kerberos).
• PDC för den betrodda skogen behöver också åtkomst till den här datorn från nätverksanvändarbehörigheten för att autentisera till domän-DC:er som är betrodda. Som standard har "autentiserade användare" användarbehörigheten som innehåller den betrodda domänen PDC.
• PDC:n i den betrodda domänen måste ha tillräcklig läsbehörighet för containern för betrodda skogspartitioner i konfigurations-NC och underordnade objekt. Som standard har "autentiserade användare" åtkomsten, vilket gäller för den anropande betrodda domänen PDC.
• När selektiv autentisering är aktiverat måste PDC i den betrodda skogen beviljas behörighet att autentisera behörighet till domänkontrollantens konton för betrodda skogar för att skydda skogarna med förtroende.

Om en betrodd skog inte tillåter att den betrodda skogen frågar efter förtroendeinformation kan den betrodda skogen riskera NTLM-reläattacker.

Till exempel litar skog A på skog B och skog C litar på skog B. Om skog A vägrar att tillåta autentisering eller LDAP-aktivitet från rotdomänen i skog B, riskerar skog A att drabbas av en NTLM-reläattack från en skadlig eller komprometterad skog C.

Nya händelser

Följande händelser läggs till som delar av skyddet för CVE-2022-21857 och loggas i systemhändelseloggen.

Netlogon-tjänstrelaterade händelser

Som standard begränsar Netlogon-tjänsten händelser för varningar och felvillkor, vilket innebär att den inte loggar varningar per begäran eller felhändelser. I stället loggas sammanfattningshändelser (Netlogon-händelse-ID 5832 och Netlogon-händelse-ID 5833) en gång per dag för NTLM-direktautentiseringar som antingen blockeras av de nya säkerhetskontrollerna som infördes i den här uppdateringen, eller som bör ha blockerats men tilläts på grund av förekomsten av en administratörskonfigurerad undantagsflagga.

Om antingen Netlogon-händelse-ID 5832 eller Netlogon-händelse-ID 5833 loggas och du behöver mer information inaktiverar du händelsebegränsningen genom att skapa och ange ThrottleNTLMPassThroughAuthEvents värdet REG_DWORD till noll i följande registersökväg:

HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

LSA-relaterade händelser (Local Security Authority)

När en felkod ingår i några av de felrelaterade händelserna måste du aktivera spårning för ytterligare undersökningar.

Förbättringar av Netlogon-loggning och LSA-loggning

Netlogon-loggning (%windir%\debug\netlogon.log) och LSA-loggning (lsp.log) uppdateras för att stödja förbättringarna i uppdateringarna.

Aktivera och inaktivera Netlogon-loggning (netlogon.log)

• Om du vill aktivera Netlogon-loggning kör du följande kommando:

  nltest /dbflag:2080ffff
  

• Om du vill inaktivera Netlogon-loggning efter undersökningarna kör du följande kommando:

  nltest /dbflag:0
  

Aktivera och inaktivera LSA-loggning (lsp.log) med hjälp av PowerShell

• Om du vill aktivera LSA-loggning kör du följande cmdletar:

  Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgInfoLevel -Value 0x1820000 -Type dword -Force 
  Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgTraceOptions -Value 0x1 -Type dword -Force
  
  

• Om du vill inaktivera LSA-loggning kör du följande cmdletar:

  Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgInfoLevel -Value 0x0 -Type dword -Force 
  Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgTraceOptions -Value 0x0 -Type dword -Force
  
  

Aktivera och inaktivera LSA-loggning (lsp.log) med hjälp av reg.exe (för äldre operativsystem utan PowerShell)

• Om du vill aktivera LSA-loggning kör du följande reg-kommandon:

  reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /V LspDbgTraceOptions /t REG_DWORD /d 1 /f 
  reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /V LspDbgInfoLevel /t REG_DWORD /d 0x1820000 /f
  

• Om du vill inaktivera LSA-loggning kör du följande reg-kommandon:

  reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /V LspDbgTraceOptions /t REG_DWORD /d 0 /f 
  reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /V LspDbgInfoLevel /t REG_DWORD /d 0x0 /f
  

Förbättringar av nltest.exe och netdom.exe verktyg

Verktygen nltest.exe och netdom.exe uppdateras för att stödja förbättringarna i den här uppdateringen.

Nltest.exe förbättringar

Verktyget nltest.exe kan köra frågor mot och visa alla poster i ett msDS-TrustForestTrustInfo attribut för ett betrott domänobjekt med hjälp av följande kommando:

nltest.exe /lsaqueryfti:<Trusting Forest Name>

Här är ett exempel med utdata:

C:\Windows\System32>nltest.exe /lsaqueryfti:contoso.com 
TLN: contoso.com 
Dom: contoso.com 
Scan: contoso.com Sid:(null) Flags:0x0 
The command completed successfully

Netdom.exe förbättringar

Verktyget netdom.exe kan initiera de nya pdc-säkerhetsskanneråtgärderna och ange en undantagsflagga för säkerhetskontroll för en specifik betrodd domän eller en specifik underordnad domän i en betrodd skog.

• Initiera PDC-säkerhetsskanneråtgärderna.

  • Kör följande kommandon för alla skogar som är betrodda:

    netdom trust <Local Forest> /Domain:* /InvokeTrustScanner
    

  • Kör följande kommandon för en specifik betrodd skog:

    netdom trust <Local Forest> /Domain:<Trusting Forest> /InvokeTrustScanner
    

    Kommentar

    Det här kommandot måste köras lokalt på PDC för den lokala skogen.

  Det här kommandot kan bara initiera åtgärden. Om du vill ta reda på resultatet letar du efter de nya LSA-händelserna i systemhändelseloggen och aktiverar LSA-spårning om det behövs.

Undersöka misslyckade NTLM-direktautentiseringar

Här är de grundläggande stegen:

1. Aktivera Netlogon- och LSA-loggning på alla berörda domänkontrollanter.

2. Återskapa problemet.

3. Inaktivera Netlogon- och LSA-loggning.

4. Sök efter följande termer i filen netlogon.log och granska eventuella loggposter som beskriver felen:

   • "LsaIFilterInboundNamespace"
   • "NlpValidateNTLMTargetInfo"
   • "NlpVerifyTargetServerRODCCachability"
   • "ResourceDomainNameCollidesWithLocalForest"

5. Sök efter termen "LsaDbpFilterInboundNamespace" i filen lsp.log och granska eventuella loggposter som beskriver felen.

Undersöka misslyckade PDC-förtroendegenomsökningsåtgärder

Här är de grundläggande stegen:

1. Aktivera LSA-loggning på PDC.

   För specifika åtgärder för säkerhetsskanner kan den här spårningen begränsas till flaggan TRACE_LEVEL_LSP_FOREST_SCANNER.

2. Återskapa problemet med hjälp av den nya netdom.exe /InvokeTrustScanner funktionen.

3. Inaktivera LSA-loggning.

4. Sök i lsp.log-filen efter termen "fail" (misslyckas) eller "failed" (misslyckades) och granska loggposterna.

Säkerhetsskannern kan misslyckas med följande orsaker:

• Behörigheter saknas i partitionscontainern.

• Brandväggsportarna som behövs mellan domänkontrollanter och mellan medlemmar och domänkontrollanter är inte öppna. Här är brandväggsportarna:

  • UDP+TCP/389
  • TCP/88
  • UDP+TCP/53

Problemreducering

Om autentiseringar misslyckas på grund av kollisioner med domännamn, felkonfiguration eller oförutsedda omständigheter byter du namn på de kolliderande domänerna för att förhindra kollision för att åtgärda problemet.

Om autentiseringar över ett rodc-säkert kanalförtroende misslyckas kontaktar du Microsofts support för det här problemet eftersom det inte finns några åtgärder.

Om PDC-förtroendeskannern misslyckas beror åtgärden på en specifik kontext. Domänkontrollanter i en betrodd skog beviljas till exempel inte LDAP-frågebehörigheter till konfigurationsnamngivningskontexten (NC) för den betrodda skogen. Åtgärden är att bevilja behörigheterna.

Vanliga frågor (FAQ)

• F1: Går det att konfigurera frekvensen för PDC-förtroendeskannern?

  A1: Nej.

• F2: Anropas PDC-förtroendeskannern automatiskt när ett nytt skogsförtroende skapas?

  A2: Nej. Administratörer kan anropa den manuellt om det behövs, annars genomsöks den nya skogen vid nästa vanliga intervall.

• F3: Kan de nya skannerposterna ändras av domänadministratörer?

  S3: Ja, men det rekommenderas inte eller stöds inte. Om skannerposter skapas, ändras eller tas bort oväntat återställer PDC-säkerhetsskannern ändringarna nästa gång de körs.

• F4: Jag är säker på att NTLM inte används i min miljö. Hur inaktiverar jag det här beteendet?

  S4: I allmänhet kan inte de nya beteendena inaktiveras. Rodc-specifika säkerhetsvalideringar kan inte inaktiveras. Du kan ange en undantagsflagga för säkerhetskontroll för ett domänförtroendefall eller ett skogsförtroendefall.

• F5: Behöver jag göra några konfigurationsändringar innan jag installerar den här uppdateringen?

  A5: Kanske. Kontrollera att konfigurationen uppfyller kraven enligt beskrivningen i avsnittet Krav .

• F6: Behöver jag korrigera mina domänkontrollanter i någon specifik ordning för att den här uppdateringen ska börja gälla?

  S6: Alla varianter av korrigeringsordning stöds. Den nya PDC-förtroendeskanneråtgärden börjar gälla först när PDC har korrigerats. Alla korrigerade domänkontrollanter börjar omedelbart tillämpa RODC-begränsningarna. Korrigerade icke-PDC:er tillämpar inte NTLM-direktbegränsningar förrän PDC har korrigerats och börjar skapa nya skannerposter i attributen msDS-TrustForestTrustInfo. Icke-korrigerade domänkontrollanter (icke-PDC) ignorerar de nya skannerposterna när de finns.

• F7: När kommer min skog att vara säker?

  S7: Skogen är säker när alla domänkontrollanter i alla domäner har den här uppdateringen installerad. Förtroende för skogar är säkert när PDC-förtroendeskannern har slutfört minst en lyckad åtgärd och replikeringen har slutförts.

• F8: Jag kontrollerar inte mina betrodda domäner eller skogar. Hur kan jag se till att min skog är säker?

  A8: Se föregående fråga. Skogens säkerhet beror inte på korrigeringsstatusen för betrodda domäner eller skogar. Vi rekommenderar att alla kunder korrigerar sina domänkontrollanter. Ändra dessutom konfigurationen som beskrivs i avsnittet Förutsättningar .

Referenser

Mer information om den specifika tekniska informationen finns i:

• [MS-ADTS]: Active Directory Technical Specification
• [MS-LSAD]: Fjärrprotokoll för lokal säkerhetsmyndighet (domänprincip)
• [MS-NRPC]: Netlogon Remote Protocol