Steuerung von Aktualisierung auf Windows 11 für Computer in Unternehmen
In nicht verwalteten Umgebungen können Benutzer bei kompatibler Hardware den Upgrade auf Windows 11 initiieren, wenn sie in Einstellungen unter Update und Sicherheit nach verfügbaren Aktualisierungen suchen.
Werden in Unternehmen die Updates über WSUS verteilt, behält man wie gewohnt die Kontrolle darüber, welche Updates ausgerollt werden. Windows 11 wird in WSUS als eigenes Produkt verwaltet, das man erst abonnieren muss, um Aktualisierungen für Windows 11 zu erhalten.
Zielversion für Funktionsupdates festlegen
Mithilfe der Gruppenrichtlinien kann gesteuert werden, auf welche Version das Funktionsupdate erfolgen soll. Dafür vorgesehen ist die mit Windows 10 2004 eingeführte Option „Zielversion des Funktionsupdates auswählen“ unter „Windows Update für Unternehmen„.
Bisher war dort nur möglich das Release von Windows 10 festzulegen, um gezielt, beispielsweise die Version 21H1 anzufordern. Das genügt jedoch nicht mehr, weil die erste Version von Windows 11 dieselbe Version hat wie das letzte Windows 10, diese ebenfalls 21H2 ist.
Windows Update Gruppenrichtlinien
Das kumulative Windows Funktionsupdate vom 11 Oktober 2021 Update [21H2] erweiterte daher die ADMX-Templates, so dass man nun zusätzlich das Betriebssystem festlegen kann. Wird für Templates ein zentraler Store genutzt, müssen diese Vorlagen aktualisiert werden, da der letzte Update der ADMX-Vorlagen für 21H1 die Richtlinie Zielversion des Funktionsupdates auswählen nicht beinhaltet.
Zu finden ist die Einstellung bei Zielversion des Funktionsupdates auswählen unter Computerkonfiguration => Richtlinien => Administrative Vorlagen => Windows-Komponenten => Windows Update = Von Windows Update angebotene Updates verwalten.
In der neuen Vorlage trägt man unter Windows-Produktversion somit Windows 10 ein und unter Zielversion für Funktionsupdates 21H2. Wenn man die Aktualisierung auf Windows 11 vermeiden möchte. Sollte der Weg für Windows 11 freigegben sein, sorgt der entsprechende Eintrag für ein Upgrade auf Windows 11.
Wer nur einmal so hineinschauen möchte, kann die .msi-Datei mit 7-Zip entpacken. Enthalten sind die Gruppenrichtlinien für 22 verschiedene Sprachen, darunter natürlich auch Deutsch.
Active Directory Konten mit erhöhten Privilegien sind Sensitive Benutzerkonten und sollten daher durch Hinzufügen zur Gruppe Protected Users geschützt werden.
Ab Windows Server 2012 R2 wurde die Sicherheitsgruppe Geschützte Benutzer („Protected Users“) eingeführt. Mit der Mitgliedschaft dieser Gruppe werden Legacy-Funktionen automatisch blockiert. Legacy-Technologien wie die NTLM Authentifizierung können können ausgenutzt werden und erleichtert Angreifer den Diebstahl von Identitäten.
Active Directory Konten schützen
Die Gruppe „Geschützte Benutzer“ wurde mit Windows Server 2012 R2 und Windows 8.1 von Microsoft eingeführt um Konten zu härten. Die Gruppe („Protected Users“) ist standardmäßig im Container Users vorhanden. Konten die Mitglieder dieser Gruppe sind werden geschützt, insbesondere vor Pass-the-Hash und Pass-the-Ticket Angriffen durch Deaktivieren von NT LAN Manager (NTLM). Eine Legacy-Technologie und Authentifizierungsprotokoll, das aus Gründen der Abwärtskompatibilität noch vorhanden ist.
Schutz vor Sicherheitsbedrohungen
Mitgliedern der Gruppe („Protected Users“) wird zusätzlicher Schutz vor Sicherheitsbedrohungen bei der Authentifizierung geboten. Die zusätzlichen Schutzmaßnahmen werden nur bereitgestellt, wenn sich Benutzer bei Windows Server 2012 R2 mit Windows 8.1 und neuer anmelden. Für diese die vollständigen Schutzmaßnahmen die Domänenfunktionsebene auf Windows Server 2012 R2 (oder höher) festgelegt wurde.
Geschützte Benutzer sind in erster Linie für die Verwendung von Domänen- und Unternehmensadministratorkonten gedacht. Die besonders anfällig für Angriffe sind, da sie bei einer Kompromittierung einen weit geöffneten Zugriff auf Systeme ermöglichen. Das heißt nicht, dass andere Benutzerkonten, die als Ziel angesehen werden könnten, nicht zu geschützten Benutzern hinzugefügt werden können. Aufgrund der strengen Beschränkungen, die Mitgliedern von geschützten Benutzern auferlegt werden, ist es jedoch wichtig, vorher gründliche Tests durchzuführen.
NTLM verwendet für die Authentifizierung eines Benutzers einen Hashwert. Dabei handelt es sich um einen komplexen Code, der jedoch am Ende nichts anderes als ein Passwort ist. Wenn nun ein Angreifer in das Netzwerk eindringt, kann er den Hashwert abfangen und sich damit selbst authentifizieren.
Es ist ratsam. Sicherzustellen dass wenn hochprivilegierte Konten wie Domänen- und Unternehmensadministratoren hinzugefügt werden, mindestens ein Konto, das nicht für reguläre Verwaltungsaufgaben verwendet wird, außerhalb der Gruppe bleibt.
Active Directory Konten schützen mit Protected Users
Die folgenden Schutzmaßnahmen werden für Mitglieder der Gruppe („Protected Users“) aktiviert. Wenn sie sich von einem unterstützten Gerät aus anmelden, und die Domänenfunktionsebene auf Windows Server 2012 R2 oder höher sichergestellt ist:
Zwischengespeicherte Anmeldeinformationen werden blockiert. Zur Authentifizierung muss ein Domänencontroller verfügbar sein.
Langzeit-Kerberos-Schlüssel beim Anmelden werden nicht unterstützt.
Klartextkennwörter werden für die Windows-Digest-Authentifizierung oder die standardmäßige Delegierung von Anmeldeinformationen (CredSSP) nicht zwischengespeichert, selbst wenn die entsprechenden Richtlinien aktiviert sind.
Die maximale Lebensdauer für das Kerberos-Ticket des Benutzers liegt bei 240 Minuten.
Die Offline-Anmeldung an einem Gerät ist nicht mehr möglich.
NTLM und NTLM-Einwegfunktion (NTOWF) ist gesperrt.
Kerberos-Ticket-Granting-Tickets (TGT) können nicht länger als 4 Stunden Time-to-Live (TTL) verlängert werden.
Data Encryption Standard (DES) und RC4 können für die Kerberos-Vorauthentifizierung nicht verwendet werden.
Die constrained und unconstrained Kerberos-Delegation wird nicht unterstützt (kann zu Einschränkungen bei Administration führen).
Eingeschränkte und uneingeschränkte Delegierung ist blockiert.
Gruppenrichtlinien für geschützte Benutzer
Grundsätzlich können einige dieser Einschränkungen auch per Gruppenrichtlinien konfiguriert werden. Durch die Mitgliedschaft in der Gruppe der geschützten Benutzer werden diese aber automatisch wirksam und es besteht keine Gefahr, sie durch eine Fehlkonfiguration wieder aufzuheben.
Penetration Testing mit Mimikatz
Überprüfung auf Wirksamkeit der Einschränkungen durch die Sicherheitsgruppe, ermöglicht das Penetration-Hacking-Tool Mimikatz. Wenn das Konto nicht Mitglied der Gruppe („Protected Users“) ist, zeigt es unter anderem den NTLM-Hash an.
Mimikatz ist ein sehr leistungsstarkes Tool um Angriffe auf das Active Directory auszuführen. Es ermöglicht auf Klartextpasswörter, Passwort-Hashes sowie Kerberos Tickets zugreifen zu können, und um die Rechte in fremden Systemen auszuweiten und so die Kontrolle über ganze Firmennetzwerke zu übernehmen.
Das Tool kann im interaktiven Modus ausgeführt werden, indem man einfach mimikatz.exe aufruft, oder in der PowerShell mit Übergabe von Parameter und der Option exit um die Abfrage zu beenden.
Hier zu erkennen ist der NTLM-Hash in der Ausgabe, dies wenn das Konto nicht Mitglied von Protected Users ist.
Authentication Id : 0 ; 643260 (00000000:0009cc96)
Session : RemoteInteractive from 2
User Name : adadmin
Domain : COMPANY
Logon Server : ADDC01
Logon Time : 12/24/2019 11:43:56 AM
SID : S-1-5-21-1581655573-3923512380-696547694-500
msv :
[00000003] Primary
* Username : ADAdmin
* Domain : COMPANY
* NTLM : 5164b9a0fda665d56739954bbcc26833
* SHA1 : f8db297cb5ae403f8915675ceae78643d0d3b09f
[00010000] CredentialKeys
* NTLM : 5164b9a0fda665d56739954bbcc26833
* SHA1 : f8db297cb5ae403f8915675ceae78643d0d3b09f
tspkg :
wdigest :
* Username : ADAdmin
* Domain : COMPANY
* Password : (null)
kerberos :
* Username : adadmin
* Domain : AD.COMPANY.LOCAL
* Password : (null)
ssp : KO
Nach Aufnahme der Mitgliedschaft zur Gruppe Geschützte Benutzer („Protected Users“) erscheint der NTLM-Hash nicht mehr.
Die Mimikatz Binary kann man von Github: gentilkiwi/mimikatz herunterladen, beim Download wird der Browser eine Sicherheitswarnung ausgeben, wie etwa „Diese Datei enthält einen Virus oder Malware„, mit Klick auf Download erlauben kann der Download vorgesetzt werden.
UNBLOG verwendet Cookies, um Dein Online-Erlebnis zu verbessern. Mit "ACCEPT" gibst Du Deine Zustimmung zur Nutzung dieser Website und unseren Datenschutzbestimmungen, oder wähle Cookie settings.
Diese Website verwendet Cookies, um Ihre Erfahrung zu verbessern, während Sie durch die Website navigieren. Von diesen werden die Cookies, die nach Bedarf kategorisiert werden, in Ihrem Browser gespeichert, da sie für das Funktionieren der grundlegenden Funktionen der Website wesentlich sind. Wir verwenden auch Cookies von Drittanbietern, mit denen wir analysieren und verstehen können, wie Sie diese Website nutzen. Diese Cookies werden nur mit Ihrer Zustimmung in Ihrem Browser gespeichert. Sie haben auch die Möglichkeit, diese Cookies zu deaktivieren. Das Deaktivieren einiger dieser Cookies kann sich jedoch auf Ihre Browser-Erfahrung auswirken.
Notwendige Cookies sind unbedingt erforderlich, damit die Website ordnungsgemäß funktioniert. Diese Kategorie enthält nur Cookies, die grundlegende Funktionen und Sicherheitsmerkmale der Website gewährleisten. Diese Cookies speichern keine persönlichen Informationen.
Alle Cookies, die für die Funktion der Website möglicherweise nicht besonders erforderlich sind und speziell zur Erfassung personenbezogener Daten des Benutzers über Analysen, Anzeigen und andere eingebettete Inhalte verwendet werden, werden als nicht erforderliche Cookies bezeichnet. Es ist obligatorisch, die Zustimmung des Benutzers einzuholen, bevor diese Cookies auf Ihrer Website ausgeführt werden.
