Veröffentlicht 31. Januar 20187 j Hallo liebe Community, beim aufsetzen unseres ADFS Features kam gegen Ende eine Fehlermeldung Domänen- und Kontonamen: NT SERVICE\MSSQL$ MICROSOFT ##WID Dieses Konto hat nicht die benötigten Rechte, sich als Service anzumelden. Im folgenden Microsoft-Artikel fand ich einen funktionierenden Workaround:https://support.microsoft.com/de-de/help/2832204/-mssql-microsoft-wid-service-was-unable-to-log-on-as-nt-service-mssql Wer nicht den Artikel lesen will unter folgendem Pfad wurde "NT Service/ALL SERVICES" : Zitat Gruppenrichtlinie editieren -> Default Domain Policy -> Computer Konfiguration -> Richtlinien -> Windows Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinie -> Zuweisen von Benutzerrechten -> Anmelden als Dienst -> [NT Serivce\ALL SERVICES] hinzufügen. Was genau heißt das jetzt für die Domäne. Recherchen ergaben zur Riskobewertung keine aussagekräftigen Ergebnisse. Und was genau bedeutet das "Anmelden als Dienst / Log In as a Service" bzw. wie kann man das etwas anschaulicher sehen? Liebe Grüße aus NBG Bearbeitet 31. Januar 20187 j von tschulian
31. Januar 20187 j Hallo @tschulian! Den Artikel dazu in der MSDN hast du gelesen? https://technet.microsoft.com/de-de/library/mt629230(v=vs.85).aspx Auszug: Zitat Sicherheitsrisiko Das Benutzerrecht Anmelden als Dienst gestattet es Konten, Netzwerkdienste oder Dienste zu starten, die kontinuierlich auf einem Computer ausgeführt werden, auch wenn niemand an der Konsole angemeldet ist. Da nur Benutzer mit Administratorrechten Dienste installieren und konfigurieren können, reduziert sich das Risiko. Ein Angreifer, der bereits über einen solch umfangreichen Zugriff verfügt, könnte den Dienst so konfigurieren, dass er unter dem lokalen Systemkonto ausgeführt wird.[...] Wenn dir das nicht reicht, kannst du deine Frage etwas spezifizieren? Gruß, Goulasz
31. Januar 20187 j Autor vor einer Stunde schrieb Goulasz: Hallo @tschulian! Den Artikel dazu in der MSDN hast du gelesen? https://technet.microsoft.com/de-de/library/mt629230(v=vs.85).aspx Auszug: Wenn dir das nicht reicht, kannst du deine Frage etwas spezifizieren? Gruß, Goulasz Den Artikel hatte ich gefunden und auch durchgelesen. Allerdings versteh ich -selbst mit hilfe dieses Artikels - nicht ganz, welcher voraussetzungen erfüllt sein müssen, damit durch diesen Change ein Risiko entsteht. Deshalb hier die Frage ob es jemand in eigenen Worten erklären möchte.
31. Januar 20187 j Hallo @tschulian! Wie es unter der Haube mit Diensten konkret aussieht, kann ich dir leider nicht beantworten, dafür bin ich kein Admin, der sich damit in der Tiefe beschäftigt. Du hast auf einem IIS ja üblicherweise einen Servicebenutzer, der als Benutzer für die Webseite fungiert. Wenn der Benutzer administrative Rechte hat (was er nicht haben sollte) und sich jemand über die Webseite über wie auch immer geartete Vulnerabilities des IIS-Servicebenutzers bemächtigt, hat er ein Konto mit administrativen Rechten, mit dem der/die Angreifer_in Schindluder auf deinem Webserver treiben kann. Den potentiellen Schaden kannst du über das Principle of Least Privilege minimieren. Davon abgesehen fallen mir allgemein zum Thema "Zugriff zu einem Konto erlangen, zudem man keinen Zugriff erlangen sollte" die üblichen Verdächtigen ein, sprich: Privilege Escalation Sensitive Data Exposure Broken Access Control etc. Für alles andere und die für Dienste relevanten Szenarien, in denen es mit der von dir beschriebenen Einstellung weitere Risiken gibt, räume ich das Feld für die Experten. Gruß, Goulasz
Erstelle ein Konto oder melde dich an, um einen Kommentar zu schreiben.