Mythos #7: DFL/FFL und seine Auswirkung auf die Clients

der DFL/FFL hat noch NIE NICHT einen Einfluss auf unterstützte Client OS gehabt und wird er auch nicht !1!11
 

Wer noch nicht auf dem ihm möglich höchsten Level steht macht das bitte jetzt. JETZT! Wer sich nicht traut, darf mich beauftragen, ich nehme für den Click pauschal 2.875,00 € pro Domain Controller. Nicht, weil ich Angst habe, sondern weil es leicht verdientes Geld ist. :-D

Für alle noch Mal zum mitschreiben: Domain Function Level (DFL) und Forest Function Level (FFL) sind einzig und allein zum Thema Replikation interessant, welches DC OS noch mitspielen kann, wobei der älteste DC den Level bestimmt, als kleinster gemeinsamer Nenner. Die Domain Controller einigen sich mit diesem Level auf die Datenbankfelder, Attribute und freigeschaltete Funktionen des AD. Die Verwalter des AD (die Domain Controller) müssen wissen, was es gibt und was sie untereinander transferieren müssen. Logischerweise kann ein altes OS, diese Funktion nicht immer bieten, sodass der Level des AD bis zur Ablösung des ältesten DC OS durch diesen bestimmt wird. Mit dem demote des ältesten DC OS kann der Level sofort angehoben werden.

Große Änderungen kommen mit einem neuen OS, wohingegen eine reine Schema Erweiterung auf Attribut Ebene nichts mit dem Level zu tun hat. Als Beispiele kann man hier Bitlocker nehmen, das zunächst eine Schema Erweiterung benötigte und noch nicht "nativ" im Server 2003 vorhanden war, die Integration kam im AD 2008. LAPS Legacy spielt in derselben Liga, es kam eine Schemaerweiterung die unabhängig vom AD Level ist/war. Das neue LAPS Native benötigt allerdings den AD Level 2016, wenn die Kennworte verschlüsselt gespeichert werden sollen. Das ist im Gegensatz zum reinen Attribut/Datenfeld, in dem Daten abgelegt werden eine Funktionalität, die erst in einer neueren OS/DC Version, ab Server 2016 zur Verfügung steht.

Den authentifizierenden Clients und Memberserver ist der DFL/FFL komplett egal. Die möchten nur eine Domäne finden und suchen dann das eigene Objekt im AD.

Es gab bislang einen einzigen "Unruhe Herd" beim Anheben des DFL/FFL, damals mit der Schema Version des Server 2008, bzw. 2008R2. Mit der Version 2008 hat Microsoft angefangen von DES/3DES für Kerberos Tickets auf RC4, AES128/256 umzustellen und mit 2008 R2, wurde DES/3DES abgestellt. Dem Windows Client/Server war das egal und es hat keiner gemerkt. Je nach Integration der DC OS hatte man also eine Übergangsphase oder einen harten Cut. Einige Drittanbieter, z.B.: SAP hatten Probleme mit der Kerberos Anmeldung, da die 9 Jahre alte etablierte DES Technik nicht mehr unterstützt wurde. Jetzt könnte man denken, das ein Hersteller so eine große Änderung mitbekommt und passend handelt. Denken kann man viel, die Reaktion benötigt Zeit und so gibt ging es mit einigen Herstellern.

Angeber Information: Wer mal in letzter Zeit über einen AD Audit gestolpert ist, oder  mit PingCastle, PurpleKnight selbst geschaut hat, der wurde wahrscheinlich auf die Änderung des krbtgt Konto Kennworts hingewiesen. In alten AD Strukturen, war die letzte Änderung des Kennworts ziemlich genau zum Zeitpunkt der DFL/FFL Anhebung auf 2008. Der Stempel des krbtgt Agenten musste von DES auf AES geändert werden und dafür benötigte er ein neuen Geheimnis, deswegen die Kennwortänderung.

Man kann einen Client "Alt"-Kompatible zwingen. Ganz wichtig: Das Operatingsystem wählt per Default IMMER! die bestmögliche (erlaubte) Verschlüsselung. Aktuell sollte man nur noch AES und "zukünftige" erlauben.

Richtlinie\Computerkonfiguration\Lokale Richtlinien\Sicherheitsoptionen
Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren

RC4 ist relativ trivial abzuschalten, da die Clients/Server sowiesoschon AES machen und mandie alten Kennworte der Dienstkonten in letzter Zeit geändert haben sollte.

Windows XP wird schon seit einem Update aus 2024? 2023? die Neuaufnahme/Domainjoin in ein AD 2016 aufwärts verweigert. Das hat ebenfalls nichts mit dem AD Level uz tun, sondern mit einem Sicherheitsupdate, das integriert wurde. Bestehende Trusts zu Clients sind nicht von dem Update betroffen. Wer also noch wirklich alte Clients auf Dauer betreiben muss, wird um eine zusätzliche ungepatchte Domäne nicht herumkommen. Das diese dann besonders abgesichert gehört versteht sich von selbst.

Zusatz Info:
Decrypting the Selection of Supported Kerberos Encryption Types
techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/decrypting-the-selection-of-supported-kerberos-encryption-types/1628797