[English]Blog-Leser Martin Feuerstein hat mich in einem Kommentar auf einen Fehler in den Sicherheitsberechtigungen von Windows Server 2016 hingewiesen, den ich hier in Form eines Blog-Beitrags wiedergebe.
Anzeige
So steht die Information aus diesem Kommentar (danke dafür) eventuell noch etwas länger im Fokus, wird von Dritten gelesen, und es es kann jemand nachvollziehen bzw. bestätigen.
Umgebung: Windows Server 2016 und Terminalserver
Die Umgebung von Martin ist ein Windows Server 2016 mit deutschen Spracheinstellungen (das Problem gibt es aber auch in der englischen Fassung). Auf diesem werden Windows Terminalserver für die Benutzer verwendet.
Das Problem: Fehler in den Sicherheitsberechtigungen
Martin schreibt, dass es einen Fehler in den Sicherheitsberechtigungen von Windows Server 2016 gäbe. Bei der Einführung neuer Terminalserver mit Windows Server 2016 wurden verschiedenen Benutzern mit neuen Benutzerprofilen Dateien anderer Benutzer angezeigt (sichtbar am Eigentümer der jeweiligen Datei).
Anzeige
(Falsche Berechtigungen)
Die Ursache liegt darin, dass Sicherheitsberechtigungen in allen Unterordnern des Default-Profils, also Desktop, Dokumente, Musik etc., fehlerhaft gesetzt sind (siehe obiger Screenshot).
(Desktop-Berechtigungen)
Der vorhergehende Screenshot zeigt, dass die Nutzer Dateien erstellen, schreiben und ändern können.
(Berechtigungen korrekt)
Obiger Screenshot zeigt die Berechtigungen von Documents auf einem System, wo keine Probleme auftreten. Die falsch gesetzten Berechtigungen haben folgende Auswirkungen:
- Benutzer erhalten die Berechtigung zum Erstellen von Dateien und Ordnern.
- Außerdem erscheint beim Öffnen des Eigenschaften-Dialogfeld die Fehlermeldung, dass die Reihenfolge der Sicherheitsberechtigungen fehlerhaft sei.
- Verschiedene Programme, darunter Microsoft Office und der PDF-Drucker des Foxit-Readers bieten den Desktop des Default User als Speicherort an, wenn das Dialogfeld zur Dateiauswahl geöffnet wird.
Martin fasst es so zusammen: Bereits umgestellte Benutzer haben beim Speichern nicht aufgepasst, so dass die Dateien auf dem Desktop des Default User abgelegt wurden. Bei den nachfolgend umgestellten Benutzern wurde das Default User-Profil als Vorlage kopiert, so dass diesen die fremden Dateien vom Default-Desktop auf ihren Desktop im Benutzerprofil kopiert bekamen.
Martin schreibt, dass das Problem bei einem englischsprachigen Windows Server 2016 auch auftritt. In Windows Server 2019 und Windows 10 1909 sind diese Extra-Berechtigungen, laut Martin nicht vorhanden.
Die Folgen dieses Verhaltens
Lässt man sich die Folgen dieser fehlerhaften Konfiguration durch den Kopf gehen, haben IT-Verantwortliche ein Problem. Martin benennt beispielsweise folgende Szenarien.
- ein Benutzer könnte versehentlich geschützte Daten anderen Benutzern mit neuen Profilen zugänglich machen
- ein Benutzer könnte vorsätzlich verstörende Daten für neue Benutzer bereitstellen
- ein Benutzer (ohne Admin-Rechte!) könnte bei neu erzeugten Profilen für Administratoren (und Domänen-Admins!) ein Ei ins Nest legen
Gerade der letztgenannte Punkt ist ein Sicherheitsproblem, da der Benutzer zum Beispiel eine Verknüpfung zu einem schädlichen Skript in den Autostart-Ordner des Startmenüs ablegen könnte.
Es gibt eine Lösung
Martin Feuerstein hat in seinem Kommentar gleich die Lösung mitgeliefert, mit der Administratoren die Berechtigungen für den Default-Profilordner zurücksetzen. Dazu eine administrative Eingabeaufforderung öffnen und den nachfolgenden Befehl eintippen:
ICACLS c:\users\default\* /T /Q /C /RESET
Die in obigem Befehl aufgeführten Parameter sind im Blog-Beitrag How to reset NTFS permissions with ICACLS von Is Solving beschrieben.
An dieser Stelle nochmals danke an Martin Feuerstein für seine Beschreibung und Analyse samt Fix. An euch die Frage: Ist das schon jemand aufgefallen? Und noch brennender interessiert die Frage, ob der Effekt auch bei anderen fremdsprachigen Oberflächen (französisch, niederländisch etc.) auftritt. Martin schrieb mir im Nachgang, dass er das Verhalten an einem englischsprachigen Windows Server 2016 auch feststellen konnte. Ich stelle den Beitrag auch mal in den englischsprachigen Blog – vielleicht ergibt sich da noch eine Erkenntnis.
Anmerkung von Martin: Das Default-Profil ist nicht angepasst. Die fehlerhaften Berechtigungen konnte er an anderen Windows Server 2016, auch ohne Remotedesktop-Rolle, in einer anderen Umgebung nachvollziehen.
Anzeige
https://beingwinsysadmin.blogspot.com/2017/07/bug-windows-10-default-user-profile-is.html?m=1 hat das bereits 2017 thematisiert. Ich hatte es auch vertieft unter https://administrator.de/wissen/2016er-terminalserveradmins-aufgepasst-kontrollieren-tut-not-345218.html
Nach wie vor ist es nicht vollständig von Microsoft gefixt – nur der Autostartordner ist nicht mehr beschreibbar, der Rest schon. Microsoft weiß das, ändert es jedoch nicht und fördert Admins auf, das selber zu machen. Macht bloß kaum jemand.
Alle Win10, die jemals auf 1607 waren, sind ebenfalls betroffen.
Tragweite war: Domänenübernahme, denn Autostart-Skripte können remote elevated handeln und UAC stoppt das nicht.
Danke für die Ergänzung – ist wohl an mir vorbei gegangen.
Nee, das hattest Du sogar thematisiert: https://www.borncity.com/blog/2017/07/09/windows-10-merkwrdigkeit-default-profil-mit-vollzugriff/
Es ist das Selbe. "Alle Jahre wieder…" :-)
Hier kam ja noch dazu, dass der Dateiauswahldialog den Benutzern den Default-Desktop angezeigt hat und die dort versehentlich Dinge abgelegt haben. Da unsere CALs "nur" 2016 sind, ging der Wechsel zum Supportende erstmal von 2008 R2 auf 2016 anstatt auf 2019.
Hallo, ich kenne das Problem nicht, habe aber mal nachgesehen und kann folgendes mitteilen. Auf meinen TSen der gleichen Version sieht es wie folgt aus. Das betrifft auch den Ordner Documents etc.
https://www.der-windows-papst.de/download/Windows-Terminal-Server-2016-Default-User-Rights.png
Schau mal in einen Unterordern, z.B. C:\Users\Default\AppData. Da sieht es auf den 2016ern offenbar überall aus wie beschrieben. Egal, ob TS oder nicht.
Danke Günter für den Blog-Post. Das muss man erstmal kennen.
Hatte im Zuge der Recherche auch einen Bekannten nach den von ihm betreuten Servern gefragt. Da war auch so ein halb-englisch-deutsches System wie in deinem Screenshot dabei – und dort war auch auf Unterordnern wie Documents die Berechtigung korrekt gesetzt, abgesehen vom zusätzlichen Everyone, der beim deutschsprachigen Server nicht drin ist.
Mit ICACLS c:\users\default\* /T /Q /C /RESET kann man das Default-Profil reparieren, zusätzlich sollte man aber schauen, dass innerhalb dieses Profils auch der Autostart-Ordner leer ist… Ich vermute außerdem, dass sämtliche bereits angelegten Profil-Ordner nochmal durchgecheckt werden müssten, oder?
Oder Default-Profil von einem sauberen Betriebssystem gleicher Version über alle bereits installierten Server drüberbügeln.
Wie man die bereits angelegten Profile ohne einzelne Handarbeit durchchecken soll… puuh.
Da müsste für jeden Vergleich noch ein ggf. verändertes Profil mit jedem lokalen oder Roaming-Profil verglichen werden, um zu ermitteln, ob eine Änderung von einem veränderten Default-Profil oder durch eine Nutzeraktion herrührt. Da würde ich eher nochmal alle Profile zurücksetzen (tschüss, Firefox-Lesezeichen) und ansonsten auf die Ordnerumleitung für den Rest vertrauen wollen.
Analysen der Benutzerprofile inkl. Inhalteordnern könnten aber auch eine Mitsprache des Personalrats oder der Dienststelle erfordern.
Ich habe seit Jahren keine Terminalserver ohne Ordnerumleitung gesehen. Egal ob persönliche Userbezogene oder als schreibgeschützte "GruppenOrdner" zB für den Desktop.
ich kann nicht bestätigen, das der "Standard Speicherort" das Default User Profil ist.
generell gibt es divers ACL Altlasten im System, siehe:
https://www.gruppenrichtlinien.de/artikel/applocker-oder-software-restriction-policies-loecher-im-sicherheitszaun/
Ist bei den Nutzern nach der ersten Anmeldung/Nutzung der Funktion zum Speichern genau so passiert, sowohl Office als auch PDF-Drucker – evt. gab es dort keine Änderung des voreingestellten Registry-Pfades beim Öffnen des Dialogs, weil diese für den Nutzer nicht schreibgeschützt waren? (also die ACLs das Schreiben nicht verboten haben?)
Gerade geschaut: Server 2019 hat den Fehler nicht.
Jetzt könnte man ja sagen, die Lösung im Jahre 2019 ist:
kein 3 Jahres altes Server OS einführen … :-D
Die Server-CALs für Server 2016 waren schon gekauft, da zuvor schon andere Server 2016 eingeführt wurden. Mit der Anschaffung der TS CALs (2019) wollten wir aber nicht alle Server CALs neu kaufen – also TS auf 2016 installiert. 2016 hat immerhin noch bis 2021 Mainstream Support und bis 2026 Extended Support! Bei NT4 bis 7 gab es wenigstens noch Service Packs und neue Funktionen.
Es soll – natürlich nur gerüchteweise :-) – LOB-Programme geben, die auch im Dezember 2019 nicht mit Server 2019 umgehen können – oder wenigstens nicht offiziell vom Hersteller dafür freigegeben sind.
Ich bin ja schon froh, dass Server 2016 inzwischen weitgehend freigegeben ist.
Es mag zwar ggf. nicht im direkten Zusammenhang mit dem icacls reset stehen, aber seitdem gibt es auf dem 2016er TS bei uns nicht mehr das Problem mit dem schreibgeschützten Papierkorb (man muss direkt löschen, in den Papierkorb verschieben verlangte erhöhte Rechte), kam nur selten und nicht bei jedem TS-Benutzer vor.