Windows Server 2016 Support-Ende: Active Directory Domain Controller Upgrade vor dem 12. Januar 2027

Ein Active-Directory-Domain-Controller-Upgrade wegen des Support-Endes von Windows Server 2016 ist ein terminiertes Projekt mit einer festen Frist, kein Backlog-Posten, den man endlos aufschieben kann. Microsofts Windows-Server-Team stellt unmissverständlich fest, dass „der erweiterte Support für Windows Server 2016 am 12. Januar 2027 endet", und der Microsoft-Lifecycle-Eintrag für Windows Server 2016 bestätigt, dass das Produkt der Fixed Lifecycle Policy folgt, mit einem erweiterten Enddatum im Januar 2027. Der Mainstream-Support endete bereits im Januar 2022.

Der unangenehme Teil sind selten die Domänencontroller selbst. Die meisten Teams können einen DC-Neuaufbau problemlos einplanen. Was sie wirklich blockiert, ist eine kurze Liste geschäftskritischer Hosts und Appliances, die sich nicht aktualisieren lassen — und diese Hosts tragen nicht nur ihr eigenes Risiko. Weil Kerberos-Verschlüsselungsstandards, Funktionsebenen und domänenweite Hardening-Einstellungen Eigenschaften der Domäne sind, zieht eine Handvoll nicht patchbarer Maschinen das gesamte Verzeichnis auf ihr Sicherheitsniveau herunter.

Windows Server 2016 Support-Ende: Frist für das Active-Directory-Domain-Controller-Upgrade

Windows Server 2016 folgt Microsofts Fixed Lifecycle Policy, die „mindestens fünf Jahre Mainstream-Support" sowie „für einige Produkte einen zusätzlichen Zeitraum an erweitertem Support" zusagt. Die oft zitierte Zahl von zehn Jahren stammt von einer anderen Seite: Microsoft beschreibt den Windows Server Long Term Servicing Channel als „mindestens 10 Jahre Support: fünf Jahre Mainstream-Support und fünf Jahre erweiterten Support, der reguläre Sicherheitsupdates einschließt". Der erweiterte Support ist die Phase, in der noch Sicherheitsupdates ausgeliefert werden. Sobald sie endet, hört das auf.

Microsofts eigene Einordnung dessen, was das Support-Ende für ein Server-Betriebssystem bedeutet, ist unverblümt: Erreichen Produkte das Support-Ende, „bedeutet das auch das Ende von Sicherheitsupdates und Bulletins" — eine Situation, die „Sicherheits- oder Compliance-Probleme verursachen und Geschäftsanwendungen gefährden kann".

Am 25. Februar 2026 kündigte Microsoft Extended Security Updates für Windows Server 2016 an. Diese Updates werden „über das Azure-Portal" bereitgestellt, und ESU „aktiviert durch Azure Arc" wird als Zugang zu zusätzlichen Azure-Vorteilen positioniert, darunter Lizenzflexibilität und Azure-Verwaltungsfunktionen. Microsofts Empfehlung im selben Beitrag lautet, auf Windows Server 2025 zu aktualisieren oder nach Azure zu migrieren — ESU wird als Brücke dargestellt, nicht als Ziel.

Speziell für einen Domänencontroller ist das Risiko nicht abstrakt. ANSSIs Active-Directory-Checkpoint-Katalog enthält einen eigenen Befund mit dem Titel „DC/RODC mit veraltetem Betriebssystem" und beschreibt damit Domänencontroller, auf denen „Betriebssysteme laufen, für die Microsoft keine Sicherheitsupdates mehr veröffentlicht. Jede neue Schwachstelle, die auf diesen Betriebssystemen gefunden wird, bleibt somit ausnutzbar." Die Abhilfe ist eine einzige Zeile: „Migrieren Sie diese veralteten Betriebssysteme so schnell wie möglich, vorzugsweise auf die neueste Windows-Version."

Warum ein einziger Legacy-Host die gesamte Domäne festhält

Das ist der kontraintuitive Teil, und genau daran scheitern die meisten 2027-Migrationspläne leise.

Funktionsebenen werden von Ihrem schlechtesten Domänencontroller begrenzt

Die Gesamtstruktur- und Domänenfunktionsebene bestimmt, welche AD-DS-Funktionen verfügbar sind — und Microsofts Interoperabilitätsmatrix der Funktionsebenen macht diese Abhängigkeit explizit. Ein Windows Server 2012 R2 DC kann nicht auf der Funktionsebene von Windows Server 2016 laufen. Ein Windows Server 2016-, 2019- oder 2022-DC kann nicht auf der Funktionsebene von Windows Server 2025 laufen.

Ein einziger überlebender 2012-R2-Domänencontroller begrenzt daher die gesamte Domäne auf das 2012-R2-Niveau, was Sie jede seither eingeführte Funktion kostet — einschließlich der Domänenebene-Funktionen von Windows Server 2016 (automatisches Rotieren von NTLM- und anderen passwortbasierten Geheimnissen bei Konten, die für Smartcard bei interaktiver Anmeldung erforderlich konfiguriert sind, Unterstützung für die Zulassung von Netzwerk-NTLM, wenn ein Benutzer auf bestimmte domänenbeigetretene Geräte beschränkt ist, sowie die neue Public-Key-Identitäts-SID für Kerberos-Clients, die sich mit der PKInit Freshness Extension authentifizieren) sowie das optionale Feature „32k-Datenbankseiten" der Windows-Server-2025-Ebene.

ANSSIs Checkliste behandelt dies als eigenständigen, gestuften Mangel unter „Unzureichende Funktionsebenen von Gesamtstruktur und Domänen": Der Alarm löst auf der ersten Reifestufe aus, wenn die Gesamtstruktur-Funktionsebene unter Windows Server 2008 R2 liegt, auf Stufe 3 unter Windows Server 2012 R2, und auf Stufe 4 unter dem Niveau von Windows Server 2016. Die genannte Begründung: „Die Verwendung einer schwachen Funktionsebene beraubt die Gesamtstruktur wichtiger Sicherheitsfunktionen".

Legacy-Clients halten Ihre Kerberos-Kryptografie als Geisel

Derselbe Mechanismus gilt für die Verschlüsselung. Microsofts Anleitung zum Erkennen und Beheben von RC4-Nutzung in Kerberos erklärt, dass RC4 „in Windows-Umgebungen typischerweise verwendet wird, wenn Konten oder Geräte stärkere Verschlüsselungstypen wie AES-SHA1 nicht unterstützen" — und dass der KDC, wenn ein Konto keinen Wert für msDS-SupportedEncryptionTypes besitzt, auf den domänenweiten Wert DefaultDomainSupportedEncTypes zurückfällt.

Dieser Fallback ist die Falle. Wird DefaultDomainSupportedEncTypes gelockert, damit eine Appliance weiterläuft, „ändert das nach Microsofts eigenen Worten das Verhalten aller Konten, die keinen Wert besitzen". Ein Host, eine domänenweite Regression. Das ist derselbe Mechanismus, der hinter dem Kerberos-RC4-Fallback steckt, und er ist es, der Kerberoasting wirtschaftlich attraktiv hält: RC4-verschlüsselte Diensttickets lassen sich offline weit schneller knacken als AES-verschlüsselte.

Windows Server 2025 schließt diese Tür vollständig, und Microsofts Warnung ist es wert, in voller Länge zitiert zu werden:

Lesen Sie den letzten Satz noch einmal. Ein einziges reines RC4-Gerät schwächt die Domäne nicht nur — es kann Sie zwingen, ältere Domänencontroller zu behalten, was wiederum Ihre Funktionsebene begrenzt, was wiederum das Hardening blockiert, das Sie eigentlich ausrollen wollten. Die Abhängigkeit läuft rückwärts, von der Appliance zum Verzeichnis.

Die Änderung des RC4-Standardwerts ist bereits ausgeliefert

Das ist kein zukünftiges Problem. KB5073381, das sich mit CVE-2026-20833 befasst, hat die Änderung in Phasen ausgerollt:

Die Rollback-Notlösung existiert nicht mehr. Wenn eine Legacy-Abhängigkeit nur wegen des alten RC4-Standardwerts funktioniert hat, ist sie bereits kaputt oder bereits mit einer expliziten Ausnahme abgesichert.

Erkennung

Beginnen Sie mit drei Inventuren. Keine davon erfordert einen Agenten, und alle drei sind günstig genug, um sie wöchentlich auszuführen.

1. Verteilung der Betriebssysteme über die Computerobjekte. Das Attribut operatingSystem wird von der Maschine selbst beim Domänenbeitritt gesetzt und bei jedem Start aktualisiert — daher ist es ein brauchbarer, wenn auch nicht maßgeblicher, erster Ansatzpunkt:

Get-ADComputer -Filter * -Properties OperatingSystem, OperatingSystemVersion, LastLogonDate |
    Where-Object { $_.Enabled -eq $true } |
    Group-Object OperatingSystem |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Gleichen Sie das mit LastLogonDate ab: Ein veraltetes Betriebssystem, das seit einem Jahr nicht mehr authentifiziert hat, ist eine Aufräumaufgabe, kein Migrationsblocker. Behandeln Sie diejenigen, die sich diese Woche angemeldet haben, als die eigentliche Einschränkung. Das ergänzt die Überprüfung der Maschinenidentität aus Active Directory Computerobjekte als Angriffsfläche — jener Artikel behandelt das Finden veralteter und gefährlicher Maschinenobjekte; dieser hier behandelt, was zu tun ist, wenn Sie sie nicht löschen können.

2. Betriebssystemversionen der Domänencontroller und aktuelle Funktionsebenen.

Get-ADDomainController -Filter * |
    Select-Object HostName, OperatingSystem, OperatingSystemVersion, IsGlobalCatalog, Site

(Get-ADForest).ForestMode
(Get-ADDomain).DomainMode
Get-ADObject (Get-ADDomain).DistinguishedName -Properties 'msDS-Behavior-Version'

3. Tatsächliche RC4-Nutzung. Microsoft veröffentlicht zwei Open-Source-Skripte, List-AccountKeys.ps1 und Get-KerbEncryptionUsage.ps1, im Kerberos-Crypto-Repository:

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4

Um Konten zu finden, die per Konfiguration und nicht aufgrund fehlender Fähigkeit auf RC4 festgelegt sind, fragen Sie das Attribut direkt ab — der Dezimalwert 4 steht für ausschließlich RC4:

Get-ADObject -Filter "msDS-SupportedEncryptionTypes -eq 4" -Properties msDS-SupportedEncryptionTypes |
    Select-Object DistinguishedName, ObjectClass

Abhilfe

Schritt 1 — Ausnahme pro Konto festlegen, niemals pro Domäne. Microsoft nennt zwei Optionen, wenn ein Konto auf den Domänenstandard zurückfällt, und nur eine davon ist in großem Maßstab sicher: „Definieren Sie den spezifischen Wert von msDS-SupportedEncryptionTypes in den Kontoeigenschaften, damit das Konto nicht auf den Wert DefaultDomainSupportedEncTypes zurückfällt." Nutzen Sie diese Option. Reservieren Sie den domänenweiten Wert für Verschärfungen, nicht für Lockerungen — der Registrierungspfad, um ausschließlich AES-SHA1 zu erzwingen, lautet HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC, Wert DefaultDomainSupportedEncTypes (REG_DWORD), gesetzt auf 0x18.

Schritt 2 — Was Sie nicht aktualisieren können, unter Quarantäne stellen. Für jeden Host, der über den 12. Januar 2027 hinaus bestehen bleiben muss:

1. Tier-0-Anmeldung verweigern. Kein Domain Admin, kein Dienstkonto mit domänenweiten Rechten, keine Delegierung sollte sich jemals an einem nicht patchbaren Host authentifizieren.
2. Auf der Netzwerkebene auf die konkret benötigten Ports und Gegenstellen beschränken.
3. Kerberos-Etypes über ein gezieltes GPO statt über eine Domänenrichtlinie einschränken. Setzen Sie unter Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen die Einstellung Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren, beschränkt auf die OU, die ausschließlich die Legacy-Hosts enthält.
4. Signierung überall sonst erzwingen, damit der schwache Host nicht als Relay-Pivot missbraucht werden kann — siehe SMB-Signierung und LDAP-Signierung.

Schritt 3 — Zuerst und sauber die Domänencontroller aktualisieren. Microsoft äußert sich explizit zu der Methode: „Der empfohlene Weg, eine Domäne zu aktualisieren, ist eine saubere Betriebssysteminstallation, um neue Server zu DCs mit einer neueren Windows-Server-Version hochzustufen und die älteren DCs bei Bedarf herabzustufen. Diese Methode ist einer Aktualisierung des Betriebssystems auf einem bestehenden DC vorzuziehen." Die dokumentierte Abfolge lautet: den neuen Server der Domäne beitreten lassen, die AD-DS-Rolle installieren (die automatisch adprep ausführt), ihn hochstufen, die FSMO-Rollen mit Move-ADDirectoryServerOperationMasterRole verschieben und anschließend den alten DC herabstufen und entfernen.

# Locate the current FSMO holders before you move anything
Get-ADDomain | Format-List InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | Format-List DomainNamingMaster, SchemaMaster

Entscheiden Sie sich stattdessen für eine In-Place-Aktualisierung, verlangt Microsoft, „adprep /forestprep und adprep /domainprep manuell auszuführen" — forestprep einmal pro Gesamtstruktur für jede neuere Windows-Server-Version, domainprep einmal in jeder Domäne mit DCs, die Sie aktualisieren, ebenfalls pro Version.

Schritt 4 — Das richtige Ziel wählen. Gemäß Microsofts unterstützten In-Place-Upgrade-Pfaden kann Windows Server 2016 per Installationsmedium in-place auf Windows Server 2019, 2022 oder 2025 aktualisiert werden. Windows Server 2012 R2 kann direkt auf Windows Server 2025 springen, denn „ab Windows Server 2025 können nicht geclusterte Systeme bis zu vier Versionen auf einmal überspringen" — Cluster-Rolling-Upgrades rücken jedoch weiterhin nur eine Version pro Schritt vor.

Schritt 5 — Funktionsebenen zuletzt anheben. Erst nachdem der letzte Legacy-DC herabgestuft und entfernt wurde. Beachten Sie, dass dies weitgehend eine Einbahnstraße ist: Ein Rollback der Gesamtstruktur-Funktionsebene ist nur auf eine Rückkehr zu Windows Server 2012 R2 oder Windows Server 2008 R2 aus einer Aktualisierung dieser Ebenen beschränkt, und ein Rollback auf Domänenebene existiert nur, wenn Sie auf Windows Server 2016 mit einer Gesamtstruktur-Ebene von Windows Server 2012 oder niedriger anheben.

🚨 Gefahr: Heben Sie die Funktionsebene nicht an, solange noch ein nicht unterstützter DC der Domäne angehört. Microsofts Anleitung besagt: Enthält die Gesamtstruktur DCs auf einer Funktionsebene, die älter ist als von einem neuen Betriebssystem unterstützt, „wird die Installation blockiert", und diese DCs „müssen entfernt und die Gesamtstruktur-Funktionsebene auf eine unterstützte Version angehoben werden, bevor Sie neuere Windows-Server-DCs zu Ihrer Gesamtstruktur hinzufügen."

Hier zählt die Reihenfolge mehr als die Geschwindigkeit. Erst Quarantäne, dann DCs aktualisieren, dann Ebenen anheben, dann die Kryptografie domänenweit verschärfen. Jede andere Reihenfolge bricht entweder die Produktion oder hinterlässt Ihnen eine auf dem Papier gehärtete Domäne, die trotzdem auf ihr schwächstes Mitglied zurückfällt — eines der wiederkehrenden Muster bei den häufigsten Active-Directory-Fehlkonfigurationen.

Wie EtcSec das erkennt

EtcSec deckt genau diese Abhängigkeitskette in einem einzigen schreibgeschützten Audit auf, ohne Agenten auf den Legacy-Hosts. COMPUTER_OS_OBSOLETE_NT, COMPUTER_OS_OBSOLETE_2008 und COMPUTER_OS_OBSOLETE_VISTA inventarisieren die Maschinenobjekte, deren Betriebssysteme keine Sicherheitsupdates mehr erhalten, geordnet danach, ob sie sich noch authentifizieren. PR001_5_1_DC_OS_OBSOLETE isoliert den weit gravierenderen Fall — einen Domänencontroller, der selbst ein veraltetes Betriebssystem ausführt — denn das ist die Prüfung, die entscheidet, ob Ihr Tier 0 überhaupt patchbar ist. ANSSI_R15_LOW_FUNCTIONAL_LEVEL meldet die aktuellen Gesamtstruktur- und Domänenfunktionsebenen im Vergleich zur empfohlenen Baseline, sodass Sie sofort sehen, welcher Legacy-DC das Verzeichnis begrenzt.

Zusammen beantworten diese Prüfungen die einzige Frage, die vor dem 12. Januar 2027 zählt: welche konkreten Hosts die Domäne zurückhalten und was tatsächlich kaputtginge, wenn Sie sie entfernten. Das erneute Ausführen des Audits nach jedem Abhilfeschritt belegt, dass sich das Niveau tatsächlich verändert hat — der Ansatz, der in Active-Directory-Sicherheit auditieren und Abhilfe nachweisen beschrieben wird.