Patchday Oktober 2026: Domain Controller zuerst — aber in der richtigen Reihenfolge

/01Was der Oktober-Patchday für Active Directory bedeutet

Für Domain Controller heißt der Oktober-Patchday: das kumulative Update dieses Monats in den nächsten Tagen auf jeden DC, gestaffelt und mit Replikationsprüfung dazwischen. Der Grund ist CVE-2026-70229, eine kritisch eingestufte Codeausführung in den Active Directory Domain Services, die ohne Anmeldung über das Netz erreichbar ist — und eine Reihe von Lücken in DNS- und DHCP-Server, die auf den meisten DCs im Mittelstand als Rolle mitlaufen.

Der Patchday selbst war am 13. Oktober 2026. BleepingComputer zählt 1.411 behobene Lücken und 70 kritische, nennt die Zahlen aber selbst „ungefähr“: Die Summe der Kategorien ergibt dort nur 1.389. Für den DC zählt ohnehin nur, welche Einträge seine Rollen betreffen.

Was dieser Beitrag nicht ist: eine Methodik für Patch-Management. Wie man aus tausend CVE-Einträgen im Monat eine Reihenfolge baut, steht im Beitrag zum CVE-Rekordjahr und risikobasiertem Patchen. Hier geht es um einen konkreten Monat und um eine konkrete Serverklasse: den Windows Server mit der Rolle Domain Controller, dazu AD FS, wo vorhanden.

Und ein Wort zur Lage: Für keine der AD-Lücken meldet Microsoft eine Ausnutzung oder Veröffentlichung vor dem Patch. Ausgenutzt wird in diesem Monat CVE-2026-96951, eine Umgehung von Mark of the Web in der Windows Shell, die CISA am 13.10. in den KEV-Katalog aufgenommen hat. Sie trifft vor allem Arbeitsplätze und Terminalserver, deren Nutzer Anhänge öffnen — nicht den DC.

/02Die Einträge, die einen Domain Controller treffen

Ein typischer DC im Mittelstand ist mehr als ein DC. Er ist DNS-Server für das ganze Netz, oft DHCP-Server, manchmal Zertifizierungsstelle und gelegentlich noch Dateiablage. Jede dieser Rollen bringt im Oktober eigene Einträge mit. Die folgende Auswahl stammt aus den Rohdaten des Microsoft Security Response Center für den Oktober 2026; die Bewertung „Ausnutzung“ ist Microsofts eigener Exploitability Index.

Dazu kommen weitere Einträge der Stufe „Wichtig“: drei Denial-of-Service-Lücken in den AD DS, mehrere Kerberos-Rechteausweitungen, drei Netlogon-Einträge und insgesamt zehn Codeausführungen im DNS-Server. Keiner davon ist laut Microsoft vor dem Patch öffentlich bekannt oder ausgenutzt worden.

In der Praxis zählt die Rollenverteilung mehr als jede einzelne Zeile. Wer DNS und DHCP auf den DCs betreibt, hat in diesem Monat drei Gründe statt einem, die DCs nicht bis zum nächsten Wartungsfenster liegen zu lassen. Wer DHCP auf eine eigene Instanz oder die Firewall ausgelagert hat, kann die DHCP-Zeilen für die DCs streichen — muss sie aber für den anderen Server mitnehmen, falls der ein Windows Server ist.

Alle genannten Lücken schließt dasselbe kumulative Update je Serverversion. Es gibt im Oktober keinen separaten AD-Patch, den man einzeln einspielen oder weglassen könnte.

/03CVE-2026-70229: kritisch, aber CVSS 8,1 — der Widerspruch

Zu CVE-2026-70229 kursieren zwei Zahlen. Microsoft selbst bewertet die Lücke mit CVSS 3.1 8,1, Vektor AV:N/AC:H/PR:N/UI:N: über das Netz, ohne Anmeldung, ohne Zutun eines Nutzers, aber mit hoher Angriffskomplexität. In einigen Zusammenfassungen taucht für dieselbe Lücke eine 9,8 auf. Eine Primärquelle dafür haben wir nicht gefunden: Weder die MSRC-Rohdaten noch der NVD-Eintrag (Stand 22.10.2026 „Awaiting Analysis“, nur Microsofts Wertung) nennen sie.

Unsere Vermutung, ausdrücklich als solche: Die 9,8-Lücken dieses Monats auf dem DC gehören zum DNS- und DHCP-Server, nicht zu den AD DS.

Warum „kritisch“ und 8,1 kein Fehler sind

Die Microsoft-Einstufung (Kritisch, Wichtig, Mittel) und der CVSS-Wert messen Verschiedenes. CVSS beschreibt die technischen Eigenschaften einer Lücke. Die Einstufung ist Microsofts Gesamturteil, in das auch eingeht, ob ein Angreifer ohne Mitwirkung des Opfers Code ausführen kann. Das erklärt die scheinbar verkehrten Paare in der Tabelle oben: AD FS CVE-2026-96252 mit 9,1 ist „wichtig“, CVE-2026-96222 mit 7,4 „kritisch“. Und zwei DNS-Lücken mit 9,8 sind „wichtig“.

Das „hoch“ bei der Angriffskomplexität begründet Microsoft in der FAQ zur Lücke: Die Ausnutzung brauche bestimmte Netzkonfigurationen und ein günstiges Timing und sei nur in begrenzten Szenarien beobachtet worden. Gleichzeitig steht im Exploitability Index „Exploitation More Likely“. Das ist kein Widerspruch, sondern eine Prognose: schwer zuverlässig auszunutzen, aber ein Ziel, an dem Angreifer arbeiten werden.

Wer intern mit Schwellwerten arbeitet („alles ab 9,0 innerhalb von 72 Stunden“), sollte genau hier nachsteuern. Eine reine CVSS-Schwelle hätte in diesem Monat die DNS- und DHCP-Lücken nach vorn geholt und die AD-DS-Lücke in die zweite Reihe gestellt. Ergänzende Signale wie der EPSS-Wert stehen für so junge Einträge oft noch gar nicht stabil zur Verfügung.

/04AD FS: zwei kritische Spoofing-Lücken und die DKM-Korrektur

AD FS ist in vielen Mittelstandsumgebungen ein Überbleibsel: eingeführt für die Anmeldung an Microsoft 365, bevor Entra ID mit Password Hash Sync oder Pass-through-Authentifizierung zum Standard wurde. Wenn es noch läuft, ist es aus dem Internet erreichbar — über einen Web Application Proxy oder direkt — und genau das macht die beiden kritischen Spoofing-Lücken CVE-2026-96222 und CVE-2026-108131 relevant. Wer sich gegenüber AD FS als jemand anderes ausgeben kann, bekommt im ungünstigsten Fall ein Token für Single-Sign-on-Anwendungen.

CVE-2026-96222 beschreibt Microsoft als fehlerhafte Zertifikatsprüfung in AD FS. Auffällig: Der Eintrag listet neben dem Windows-Update auch .NET-Framework-Pakete und Visual Studio. Für den AD-FS-Server heißt das, das .NET-Framework-Update vom Oktober gehört ebenso auf die Liste wie das kumulative Windows-Update. Prüfen Sie nach dem Patch, ob beide installiert sind.

Die stille Änderung: DKM-Container

Das Oktober-Update ändert laut Microsoft außerdem ein Standardverhalten. AD FS legt seinen Schlüssel für die Token-Signatur verschlüsselt im Active Directory ab, im sogenannten DKM-Container. Unsichere Berechtigungen auf diesem Container korrigiert das Update nun standardmäßig selbst. Abschalten lässt sich das über den Registrywert RemediateDkmAcl = 0; für Pfad und Einzelheiten verweisen die KB-Artikel auf Microsofts Hinweise zu CVE-2026-56155 („AD FS Distributed Key Manager container ACL hardening“).

Ehrlich: Abschalten sollte man das nur mit gutem Grund. Wer aber eigene Dienstkonten oder Werkzeuge hat, die auf den DKM-Container zugreifen — Monitoring, Sicherung, Migrationsskripte —, sollte nach dem Update prüfen, ob die noch laufen. Ein neuer Zugriffsfehler auf den DKM-Container ist dann zuerst ein Hinweis auf die Korrektur, nicht auf einen Defekt.

# Auf dem primären AD-FS-Server: Farmzustand vor und nach dem Update
Get-AdfsFarmInformation | Select-Object CurrentFarmBehavior, FarmNodes
Get-AdfsProperties | Select-Object HostName, EnableIdPInitiatedSignonPage
# Anmeldung testen (im Browser, intern und extern) — die Testseite ist ab AD FS 2016
# standardmäßig aus; sonst mit einer echten Anwendung (z. B. Microsoft 365) testen
# https://<adfs-name>/adfs/ls/idpinitiatedsignon.aspx

/05Reihenfolge: welche Server in welcher Welle

Microsoft schreibt für diesen Monat keine Reihenfolge vor, und es gibt keine Durchsetzungsphase, die DCs und Clients aufeinander abstimmen müsste. Die folgende Staffelung ist unser Vorschlag aus dem Betrieb, ausgelegt auf eine Domäne mit zwei bis vier DCs, AD FS und einem Exchange-Server. Sie geht davon aus, dass die DCs als virtuelle Maschinen laufen, etwa auf Hyper-V oder Proxmox.

Zwei Entscheidungen in dieser Tabelle sind Erfahrungswerte, keine Microsoft-Vorgaben — für monatliche kumulative Updates dokumentiert Microsoft keine Reihenfolge der DCs. Der PDC-Emulator kommt bei uns zuletzt, weil er Sonderaufgaben trägt: Zeitquelle der Domäne, bevorzugtes Ziel für Kennwortänderungen und Kontosperren, Standardziel beim Bearbeiten von Gruppenrichtlinien. Ein Problem soll zuerst auf einem DC ohne diese Rollen auftreten. Zwingend ist das nicht: Microsofts alte Upgrade-Anleitungen setzten den PDC-Emulator sogar an den Anfang, als bloße Empfehlung. Und die internet-erreichbaren Systeme gehören vor die DCs, weil sie ohne Umweg angreifbar sind; ein DC ist das in einer sauber gebauten Umgebung nicht.

Wenn es nur einen DC gibt

Das kommt im Mittelstand öfter vor, als es sollte. Dann gibt es keine Staffelung, nur ein Wartungsfenster mit Neustart, in dem Anmeldung, DNS und DHCP für einige Minuten fehlen. Planen Sie das außerhalb der Arbeitszeit und mit einer frischen Systemstatus-Sicherung. Ein zweiter DC kostet eine kleine VM und, je nach Lizenzierung des Hosts, eine weitere Windows-Server-Lizenz; er ist die billigste Hochverfügbarkeits-Maßnahme, die es in einer Windows-Umgebung gibt.

Snapshots sind keine Sicherung für DCs

Ein Hypervisor-Snapshot vor dem Update ist bequem, für Domain Controller aber heikel. Das Zurücksetzen eines DC auf einen älteren Stand kann die Replikation durcheinanderbringen, wenn die Virtualisierungsumgebung die VM-Generation-ID nicht korrekt weiterreicht. Für DCs ist der Rückweg ein zweiter, gesunder DC plus Sicherung des Systemstatus — nicht der Snapshot.

# Systemstatus-Sicherung eines DC auf ein separates Volume (Beispiel E:)
wbadmin start systemstatebackup -backupTarget:E: -quiet

# Replikation vor und nach jedem DC prüfen
repadmin /replsummary
repadmin /showrepl * /csv | ConvertFrom-Csv | Where-Object { $_.'Number of Failures' -gt 0 }
dcdiag /q

Erwartet wird nach repadmin /replsummary in der Spalte „fails“ eine 0 bei jedem DC, und dcdiag /q gibt im Idealfall nichts aus — es meldet nur Fehler. Die Zeile mit Where-Object bleibt leer, wenn keine Replikationsverbindung Fehler hat.

/06Patchstand aller Domain Controller per PowerShell prüfen

Ob ein Update installiert ist, zeigt nicht die WSUS-Konsole und nicht der Haken in einem RMM-Werkzeug, sondern die Build-Nummer, mit der das System nach dem Neustart läuft. Sie setzt sich aus CurrentBuild und UBR (Update Build Revision) in der Registry zusammen. Das folgende Skript fragt alle DCs der Domäne ab und vergleicht mit den Ziel-Builds aus der Tabelle in Abschnitt /02.

# Voraussetzung: RSAT-AD-PowerShell, WinRM auf den DCs, Domänen-Admin oder delegierte Rechte
$ziel = @{ '26100' = 33650; '20348' = 5761; '17763' = 9376; '14393' = 9612; '9600' = 23470; '9200' = 26434 }

Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    try {
        $r = Invoke-Command -ComputerName $dc -ErrorAction Stop -ScriptBlock {
            $cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
            $neustart = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
            $boot = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
            [pscustomobject]@{ Build = $cv.CurrentBuild; UBR = $cv.UBR; Neustart = $neustart; Boot = $boot }
        }
        $soll = $ziel[$r.Build]
        $status = if (-not $soll) { 'Version unbekannt' }
                  elseif ($r.UBR -ge $soll) { 'OK' }
                  else { 'FEHLT' }
        if ($r.Neustart) { $status += ' / Neustart ausstehend' }
        [pscustomobject]@{ DC = $dc; Ist = "$($r.Build).$($r.UBR)"; Soll = "$($r.Build).$soll"
                           Status = $status; LetzterStart = $r.Boot }
    } catch {
        [pscustomobject]@{ DC = $dc; Ist = '-'; Soll = '-'; Status = 'nicht erreichbar'; LetzterStart = $null }
    }
} | Sort-Object Status, DC | Format-Table -AutoSize

Eine Ausgabe sieht so aus (Beispiel, Namen und Ist-Stände erfunden):

DC                 Ist          Soll         Status                         LetzterStart
--                 ---          ----         ------                         ------------
dc03.firma.local   17763.9252   17763.9376   FEHLT / Neustart ausstehend    14.09.2026 22:10:41
dc04.aussen.local  -            -            nicht erreichbar
dc01.firma.local   20348.5761   20348.5761   OK                             20.10.2026 21:04:12
dc02.firma.local   20348.5761   20348.5761   OK                             21.10.2026 21:07:55

Statuslogik und Sortierung sind am 22.10.2026 mit PowerShell 7.4 gegen nachgestellte Werte getestet, die Abfrage per Invoke-Command nur in echten Domänen.

So lesen Sie das Ergebnis

• OK: Das System läuft mit dem Oktober-Stand oder einem neueren. Ein höherer UBR als das Soll ist in Ordnung, etwa nach einem späteren Update.
• FEHLT / Neustart ausstehend: Das Update ist installiert, wirkt aber nicht. Der häufigste Befund in der Praxis — besonders bei DCs, die niemand gern neu startet.
• FEHLT ohne Neustart-Hinweis: Das Update ist gar nicht angekommen. Freigabe in WSUS oder im Patch-Werkzeug prüfen, dann Windows Update auf dem DC direkt.
• Version unbekannt: Eine Serverversion, die im Skript nicht hinterlegt ist. Bei Build 9200 oder 9600 ohne ESU-Vertrag bleibt der Server ohne Oktober-Update — und mit dem Ende des dritten ESU-Jahres am 13.10.2026 kommt danach ohnehin nichts mehr.
• nicht erreichbar: WinRM gesperrt, Firewall oder DC offline.

Das Skript lässt sich mit einer anderen Quelle als Get-ADDomainController für alle Server verwenden, etwa mit Get-ADComputer -Filter 'OperatingSystem -like "*Server*"'. Zur Gegenprobe einzelner Server taugt Get-HotFix -Id KB5126655 -ComputerName dc01: Es zeigt, ob das Paket installiert ist — nicht, ob es nach einem Neustart schon wirkt. Für den monatlichen Nachweis reicht es, die Ausgabe mit Export-Csv abzulegen; im SIEM oder Monitoring lässt sich derselbe Wert als Abweichung alarmieren.

/07Bekannte Probleme und Stolpersteine

Exchange: Endpoint Mapper mit neuem Limit

Microsoft führt für das Oktober-Update ein bekanntes Problem auf, das nicht den DC, sondern Exchange trifft: Der Endpoint Mapper hat seit diesem Update ein Standardlimit von 512 gleichzeitigen Endpoint-Lookup-Aufrufen. Unter Last reicht das auf manchen Exchange-Servern nicht. Die Folgen laut Microsoft: Anmeldung an Outlook im Web scheitert, Mails bleiben im Postausgang, Warteschlangen wachsen, im Anwendungsprotokoll erscheint Ereignis 1006 mit MapiExceptionMdbOffline. Das tritt auch auf, wenn die Exchange-Sicherheitsupdates vom Oktober nicht installiert sind.

Microsoft nennt einen Registry-Workaround, der das Limit anhebt, und verweist dafür auf den Exchange-Blog. Bereiten Sie ihn vor, bevor Sie den Exchange-Server patchen, und setzen Sie ihn erst, wenn das Problem auftritt. Ob DCs mit sehr vielen RPC-Clients an dieselbe Grenze stoßen, dokumentiert Microsoft nicht. Für Exchange 2016 und 2019 kommt hinzu, dass deren Support laut Microsoft-Lebenszyklus bereits im Oktober 2025 geendet hat — die Frage stellt sich dort ohnehin neu.

WSUS ohne Fehlerdetails

Seit einem früheren Update zeigt WSUS bei Synchronisationsfehlern keine Details mehr an; Microsoft hat die Funktion wegen einer Lücke vorübergehend entfernt und listet das im Oktober weiter als bekanntes Problem. Wer DCs über WSUS versorgt und eine stockende Synchronisation sieht, muss den Fehler anders suchen. Was nach WSUS kommt, steht im Beitrag Was kommt nach WSUS?.

Was wir außerdem regelmäßig sehen

• DC startet, aber Dienste fehlen: Nach dem Neustart braucht ein DC einige Minuten, bis Netlogon, DNS und die Replikation stehen. Den nächsten DC erst anfassen, wenn dcdiag /q leer bleibt.
• Zwei DCs im selben Wartungsfenster: Ein Patch-Werkzeug mit Gruppenrichtlinie „automatisch installieren und neu starten“ startet gern alle DCs gleichzeitig. Für DCs gehört der Neustart in eine eigene Gruppe mit eigenem Zeitfenster.
• Vergessene DCs: Ein DC in einer Außenstelle oder im Labor, der Teil der Domäne ist, aber in keiner Patchgruppe steht. Das Skript aus /06 findet ihn, weil es aus dem AD liest, nicht aus der Patchkonsole.
• NTLM-Protokollierung: Das Oktober-Update macht auf Server 2022 und 2019 ein erweitertes NTLM-Auditing verfügbar. Es zeigt, wer NTLM nutzt und warum. Wer es einschaltet, sollte Ereignisprotokoll und angeschlossenes SIEM auf das zusätzliche Volumen vorbereiten.
• Server 2025 und NTLMv1: Laut KB5126646 blockiert Windows jetzt standardmäßig aus NTLMv1 abgeleitete Anmeldedaten für Single Sign-on, wenn Credential Guard aus ist und der Wert BlockNtlmv1SSO nicht gesetzt ist. Microsoft nennt als mögliche Folge Störungen bei WLAN-, LAN- und VPN-Anmeldungen mit MS-CHAPv2.

/08Wann Eile geboten ist — und wann nicht

Für keine der AD-Lücken meldet Microsoft eine Ausnutzung vor dem Patch. Das ist kein Grund, bis zum Dezember zu warten, aber auch keiner für einen nächtlichen Notfalleinsatz ohne Sicherung. Die folgende Entscheidungstabelle ordnet ein, wie schnell Sie handeln sollten.

Wann ist das Thema für Sie irrelevant? Wenn Sie kein lokales Active Directory betreiben — reine Cloud-Umgebungen mit Entra ID und ohne Domain Controller sind von den AD-DS- und AD-FS-Einträgen nicht betroffen. Und wenn Ihr Dienstleister die DCs bereits im Oktober-Fenster gepatcht hat: Dann ist dieser Beitrag eine Kontrollliste, kein Auftrag. Das Skript aus /06 zeigt in einer Minute, welcher Fall vorliegt.

Wo es hakt: Eine saubere Staffelung kostet Zeit und Aufmerksamkeit über mehrere Tage, und sie verlangt, dass jemand nach jedem Neustart wirklich hinsieht. In kleinen Teams ist das der eigentliche Engpass, nicht das Update. Wer DCs ohne zweiten Mann patcht, sollte zumindest die Prüfung aus /05 als festen Runbook-Schritt hinterlegen. Mittelfristig gehört auch der Lebenszyklus auf den Tisch: Server 2016 als DC endet im Januar 2027, siehe Windows Server 2016 Support-Ende.

Ein DC, auf dem Angreifer Code ausführen, ist die ganze Domäne. Deshalb gehört neben das Patchen die Frage, wer überhaupt an die DCs herankommt: administrative Konten nur mit PAM und zeitlich begrenzten Rechten, DCs in einem eigenen Netzsegment, und die Anmeldeereignisse in einer Überwachung, die auch nachts jemand liest. Das ist keine Formsache — bei Ransomware-Fällen ist die Übernahme des AD fast immer der Schritt vor der Verschlüsselung.

/09Häufige Fragen