Log In as a Service - Riskobewertung

[tschulian]

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 2018 von tschulian

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

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  

[tschulian]

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.

[Goulasz]

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