Der Unterschied zwischen dem Konto "Lokales System" und dem Konto "Netzwerkdienst"?


386

Ich habe einen Windows-Dienst geschrieben, der einen separaten Prozess erzeugt. Dieser Prozess erstellt ein COM-Objekt. Wenn der Dienst unter dem Konto "Lokales System" ausgeführt wird, funktioniert alles einwandfrei. Wenn der Dienst jedoch unter dem Konto "Netzwerkdienst" ausgeführt wird, wird der externe Prozess gestartet, das COM-Objekt kann jedoch nicht erstellt werden. Der von der COM-Objekterstellung zurückgegebene Fehler ist kein Standard-COM-Fehler (ich denke, er ist spezifisch für das zu erstellende COM-Objekt).

Wie bestimme ich, wie sich die beiden Konten "Lokales System" und "Netzwerkdienst" unterscheiden? Diese eingebauten Konten scheinen sehr mysteriös zu sein und niemand scheint viel über sie zu wissen.

Antworten:


701

Da die Funktionalität von Standarddienstkonten so verwirrend ist, werde ich versuchen, einen kurzen Überblick zu geben.

Zuerst die tatsächlichen Konten:

  • LocalService- Konto (bevorzugt)

    Ein eingeschränktes Dienstkonto, das dem Netzwerkdienst sehr ähnlich ist und Standarddienste mit den geringsten Berechtigungen ausführen soll. Im Gegensatz zum Netzwerkdienst greift er jedoch als anonymer Benutzer auf das Netzwerk zu .

    • Name: NT AUTHORITY\LocalService
    • Das Konto hat kein Passwort (alle von Ihnen angegebenen Passwortinformationen werden ignoriert).
    • HKCU repräsentiert das LocalService- Benutzerkonto
    • hat minimale Berechtigungen auf dem lokalen Computer
    • präsentiert anonyme Anmeldeinformationen im Netzwerk
    • SID : S-1-5-19
    • hat ein eigenes Profil unter dem Registrierungsschlüssel HKEY_USERS ( HKEY_USERS\S-1-5-19)

     

  • NetworkService- Konto

    Eingeschränktes Dienstkonto, mit dem standardmäßige privilegierte Dienste ausgeführt werden sollen. Dieses Konto ist weitaus eingeschränkter als das lokale System (oder sogar der Administrator), hat jedoch weiterhin das Recht, als Computer auf das Netzwerk zuzugreifen (siehe Einschränkung oben).

    • NT AUTHORITY\NetworkService
    • Das Konto hat kein Passwort (alle von Ihnen angegebenen Passwortinformationen werden ignoriert).
    • HKCU repräsentiert das NetworkService- Benutzerkonto
    • hat minimale Berechtigungen auf dem lokalen Computer
    • präsentiert die Anmeldeinformationen des Computers (z. B. MANGO$) Remote-Servern
    • SID : S-1-5-20
    • hat ein eigenes Profil unter dem Registrierungsschlüssel HKEY_USERS ( HKEY_USERS\S-1-5-20)
    • Wenn Sie versuchen, eine Aufgabe damit zu planen, rufen Sie NETWORK SERVICEdas Dialogfeld Benutzer oder Gruppe auswählen auf

     

  • LocalSystem- Konto (gefährlich, nicht verwenden!)

    Vollständig vertrauenswürdiges Konto, mehr als das Administratorkonto. Es gibt nichts auf einer einzelnen Box, was dieses Konto nicht kann, und es hat das Recht, als Computer auf das Netzwerk zuzugreifen (dies erfordert Active Directory und das Erteilen der Berechtigungen für das Computerkonto für etwas).

    • Name: .\LocalSystem(kann auch LocalSystemoder verwenden ComputerName\LocalSystem)
    • Das Konto hat kein Passwort (alle von Ihnen angegebenen Passwortinformationen werden ignoriert).
    • SID : S-1-5-18
    • hat kein eigenes Profil ( HKCUrepräsentiert den Standardbenutzer )
    • verfügt über umfangreiche Berechtigungen auf dem lokalen Computer
    • präsentiert die Anmeldeinformationen des Computers (z. B. MANGO$) Remote-Servern

     

Wenn oben über den Zugriff auf das Netzwerk gesprochen wird, bezieht sich dies ausschließlich auf SPNEGO (Negotiate), NTLM und Kerberos und nicht auf einen anderen Authentifizierungsmechanismus. Beispielsweise kann die Verarbeitung so ausgeführt werden, dass LocalServiceweiterhin auf das Internet zugegriffen werden kann.

Das allgemeine Problem bei der Ausführung als Standard-Out-of-the-Box-Konto besteht darin, dass Sie, wenn Sie eine der Standardberechtigungen ändern, die Dinge erweitern, die alles ausführen kann, was dieses Konto ausführen kann. Wenn Sie einer Datenbank DBO gewähren, kann Ihr Dienst, der als lokaler Dienst oder Netzwerkdienst ausgeführt wird, nicht nur auf diese Datenbank zugreifen, sondern auch auf alles andere, das als diese Konten ausgeführt wird. Wenn jeder Entwickler dies tut, verfügt der Computer über ein Dienstkonto, das über die Berechtigung verfügt, praktisch alles zu tun (insbesondere die Obermenge aller verschiedenen zusätzlichen Berechtigungen, die diesem Konto gewährt werden).

Aus Sicherheitsgründen ist es immer vorzuziehen, als Ihr eigenes Dienstkonto zu arbeiten, das genau die Berechtigungen hat, die Sie benötigen, um das zu tun, was Ihr Dienst tut, und sonst nichts. Die Kosten für diesen Ansatz sind jedoch die Einrichtung Ihres Dienstkontos und die Verwaltung des Kennworts. Es ist ein Balanceakt, den jede Anwendung verwalten muss.

In Ihrem speziellen Fall besteht das Problem, das Sie wahrscheinlich sehen, darin, dass die DCOM- oder COM + -Aktivierung auf einen bestimmten Satz von Konten beschränkt ist. In Windows XP SP2, Windows Server 2003 und höher war die Aktivierungsberechtigung erheblich eingeschränkt. Sie sollten das MMC-Snapin für Komponentendienste verwenden, um Ihr spezifisches COM-Objekt zu untersuchen und die Aktivierungsberechtigungen anzuzeigen. Wenn Sie als Computerkonto nicht auf etwas im Netzwerk zugreifen, sollten Sie ernsthaft in Betracht ziehen, den lokalen Dienst zu verwenden (nicht das lokale System, bei dem es sich im Grunde um das Betriebssystem handelt).


In Windows Server 2003 Sie können nicht eine geplante Aufgabe ausgeführt werden als

  • NT_AUTHORITY\LocalService (auch bekannt als Local Service Account) oder
  • NT AUTHORITY\NetworkService (auch bekannt als Network Service Account).

Diese Funktion wurde nur mit Task Scheduler 2.0 hinzugefügt , der nur in Windows Vista / Windows Server 2008 und höher verfügbar ist.

Ein Dienst, der wie ausgeführt wird, NetworkServicezeigt die Anmeldeinformationen des Computers im Netzwerk an. Dies bedeutet, dass Ihr Computer, wenn er aufgerufen wurde mango, als Computerkonto angezeigt wird MANGO$ :

Geben Sie hier die Bildbeschreibung ein


7
Ich denke, dass verwaltete Dienstkonten einige der Probleme beim Einrichten des Kontos und beim Verwalten des Kennworts beseitigen (oder es besser an einen Domänenadministrator oder -delegierten weitergeben).
Carl G

1
Hallo, danke für die Erklärung. Ich habe jedoch eine Frage: Mit dem lokalen System- / Netzwerkdienstkonto können Einträge zu Containern im Active Directory hinzugefügt / entfernt werden (vorausgesetzt, der Container im Active Directory hat dem Computer, auf dem diese Windows-Dienste ausgeführt werden, die vollständigen Berechtigungen erteilt). Bitte beachten Sie, dass alles funktioniert, wenn ich den Dienst als einer der Domänenbenutzer ausgeführt habe, jedoch nicht als lokaler System- / Netzwerkdienst (für Details stackoverflow.com/questions/20943436/… ). Grüße
Träumer

1
Ja, das sollte es. Ich werde Ihre Frage direkt beantworten, da diese Frage abstrakter ist und dies eine spezifische Implementierung ist.
Peter Oehlert

7
Beachten Sie, dass "anonymer" Benutzer nicht nur kein Mitglied von "authentifizierten Benutzern" ist, sondern auch kein Mitglied von "jedem" unter Windows. In Windows-Netzwerken hat "anonym" nur Zugriff auf Ressourcen, die explizit "anonym" gewährt wurden - standardmäßig nichts.
David

1
@ HakamFostok Ich habe nicht viel Referenz. Wenn ich mich richtig erinnere, hat Dan Brown einige davon in seinem Buch Programming Windows Security behandelt. Es gibt viel in der Windows-Hilfe und in den MSDN-Dokumenten, aber ich habe keine spezifische Referenz. Jeff Richters Buch (e) über Programmierfenster sowie Inside Windows (3. oder 4. Ausgabe) von Soloman & Russinovich haben ebenfalls einige.
Peter Oehlert
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.