Windows Server 2016: Fehler in den Benutzerprofil-Sicherheitsberechtigungen

[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.

Windows Server 2016 Version

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).

User Profil Berechtigungen(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
(Desktop-Berechtigungen)


Anzeige

Der vorhergehende Screenshot zeigt, dass die Nutzer Dateien erstellen, schreiben und ändern können.

Berechtigungen korrekt
(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.

Fehlermeldung Berechtigungen

  • 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
Dieser Beitrag wurde unter Sicherheit, Windows Server abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

16 Antworten zu Windows Server 2016: Fehler in den Benutzerprofil-Sicherheitsberechtigungen


  1. Anzeige
  2. Anonymous sagt:

    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.

  3. Jörn Walter sagt:

    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

    • riedenthied sagt:

      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.

    • Martin Feuerstein sagt:

      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.

  4. Anzeige

  5. 1ST1 sagt:

    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?

    • Martin Feuerstein sagt:

      Oder Default-Profil von einem sauberen Betriebssystem gleicher Version über alle bereits installierten Server drüberbügeln.

    • Martin Feuerstein sagt:

      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.

  6. Mark Heitbrink sagt:

    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/

    • Martin Feuerstein sagt:

      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?)

  7. Mark Heitbrink sagt:

    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

    • Martin Feuerstein sagt:

      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.

    • GPBurth sagt:

      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.

  8. Henry Barson sagt:

    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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (SEO-Posts/SPAM lösche ich). Kommentare abseits des Themas bitte unter Diskussion.