Różnica między kontem „System lokalny” a kontem „Usługa sieciowa”?


386

Napisałem usługę systemu Windows, która tworzy osobny proces. Ten proces tworzy obiekt COM. Jeśli usługa działa na koncie „System lokalny”, wszystko działa poprawnie, ale jeśli usługa działa na koncie „Usługa sieciowa”, proces zewnętrzny uruchamia się, ale nie tworzy obiektu COM. Błąd zwrócony podczas tworzenia obiektu COM nie jest standardowym błędem COM (myślę, że jest specyficzny dla tworzonego obiektu COM).

Jak więc ustalić, w jaki sposób różnią się dwa konta, „System lokalny” i „Usługa sieciowa”? Te wbudowane konta wydają się bardzo tajemnicze i nikt nie wydaje się o nich dużo wiedzieć.

Odpowiedzi:


701

Ponieważ istnieje wiele nieporozumień dotyczących funkcjonalności standardowych kont usług, postaram się szybko z nich zrezygnować.

Najpierw rzeczywiste konta:

  • Konto LocalService (preferowane)

    Konto usługi ograniczonej, bardzo podobne do usługi sieciowej i przeznaczone do uruchamiania standardowych usług najmniej uprzywilejowanych. Jednak w przeciwieństwie do usługi sieciowej uzyskuje dostęp do sieci jako użytkownik anonimowy .

    • Imię: NT AUTHORITY\LocalService
    • konto nie ma hasła (wszelkie podane przez Ciebie informacje o haśle są ignorowane)
    • HKCU reprezentuje konto użytkownika LocalService
    • ma minimalne uprawnienia na komputerze lokalnym
    • przedstawia anonimowe poświadczenia w sieci
    • SID : S-1-5-19
    • ma własny profil pod kluczem rejestru HKEY_USERS ( HKEY_USERS\S-1-5-19)

     

  • Konto NetworkService

    Konto usługi ograniczonej przeznaczone do uruchamiania standardowych usług uprzywilejowanych. To konto jest znacznie bardziej ograniczone niż System lokalny (lub nawet Administrator), ale nadal ma prawo dostępu do sieci jako komputera (patrz zastrzeżenie powyżej).

    • NT AUTHORITY\NetworkService
    • konto nie ma hasła (wszelkie podane przez Ciebie informacje o haśle są ignorowane)
    • HKCU reprezentuje konto użytkownika NetworkService
    • ma minimalne uprawnienia na komputerze lokalnym
    • przedstawia dane uwierzytelniające komputera (np. MANGO$) zdalnym serwerom
    • SID : S-1-5-20
    • ma własny profil pod kluczem rejestru HKEY_USERS ( HKEY_USERS\S-1-5-20)
    • Jeśli próbujesz zaplanować użycie zadania, wejdź NETWORK SERVICEw okno dialogowe Wybierz użytkownika lub grupę

     

  • Konto LocalSystem (niebezpieczne, nie używaj!)

    Konto całkowicie zaufane, bardziej niż konto administratora. Na jednym urządzeniu nie ma niczego, czego nie może zrobić to konto i ma on prawo dostępu do sieci jako komputera (wymaga to usługi Active Directory i przyznania uprawnień konta na komputer do czegoś)

    • Nazwa: .\LocalSystem(można również użyć LocalSystemlub ComputerName\LocalSystem)
    • konto nie ma hasła (wszelkie podane przez Ciebie informacje o haśle są ignorowane)
    • SID : S-1-5-18
    • nie ma własnego profilu ( HKCUreprezentuje domyślnego użytkownika)
    • ma szerokie uprawnienia na komputerze lokalnym
    • przedstawia dane uwierzytelniające komputera (np. MANGO$) zdalnym serwerom

     

Powyżej, gdy mówimy o dostępie do sieci, dotyczy to wyłącznie SPNEGO (Negotiate), NTLM i Kerberos, a nie żadnego innego mechanizmu uwierzytelniania. Na przykład przetwarzanie działa, ponieważ LocalServicenadal można uzyskać dostęp do Internetu.

Ogólny problem z uruchamianiem standardowego konta „po wyjęciu z pudełka” polega na tym, że jeśli zmodyfikujesz dowolne domyślne uprawnienia, rozszerzysz zestaw rzeczy, które działają tak, jak to konto. Jeśli więc przyznasz DBO bazie danych, twoja usługa działająca jako usługa lokalna lub usługa sieciowa może uzyskać dostęp do tej bazy danych, ale wszystko inne działa tak samo, jak te konta. Jeśli każdy programista to zrobi, komputer będzie miał konto usługi, które ma uprawnienia do wykonywania praktycznie wszystkiego (a dokładniej nadzbiór wszystkich różnych dodatkowych uprawnień przyznanych temu kontowi).

Z punktu widzenia bezpieczeństwa zawsze lepiej jest prowadzić jako własne konto usługi, które ma dokładnie takie same uprawnienia, jakich potrzebujesz, aby robić to, co robi Twoja usługa i nic więcej. Kosztem tego podejścia jest jednak utworzenie konta usługi i zarządzanie hasłem. Jest to działanie równoważące, którym każda aplikacja musi zarządzać.

W twoim konkretnym przypadku problemem, który prawdopodobnie widzisz, jest to, że aktywacja DCOM lub COM + jest ograniczona do danego zestawu kont. W systemie Windows XP SP2, Windows Server 2003 i nowszych uprawnienia do aktywacji zostały znacznie ograniczone. Należy użyć przystawki MMC Usługi składowe, aby zbadać konkretny obiekt COM i zobaczyć uprawnienia do aktywacji. Jeśli nie masz dostępu do niczego w sieci jako konta komputera, powinieneś poważnie rozważyć skorzystanie z usługi lokalnej (nie systemu lokalnego, który jest w zasadzie systemem operacyjnym).


W systemie Windows Server 2003 nie można uruchomić zaplanowanego zadania jako

  • NT_AUTHORITY\LocalService (zwane także kontem usługi lokalnej) lub
  • NT AUTHORITY\NetworkService (inaczej konto usługi sieciowej).

Ta funkcja została dodana tylko z Harmonogramem zadań 2.0 , który istnieje tylko w systemie Windows Vista / Windows Server 2008 i nowszych.

Usługa działająca jako NetworkServiceprzedstawia poświadczenia komputera w sieci. Oznacza to, że gdyby komputer został wywołany mango, byłby wyświetlany jako konto komputera MANGO$ :

wprowadź opis zdjęcia tutaj


7
Myślę, że konta usług zarządzanych usuwają część bólu związanego z konfigurowaniem konta i zarządzaniem hasłem (a raczej przekazują je administratorowi domeny lub delegatowi.)
Carl G

1
Cześć, dzięki za wyjaśnienie. Mam jednak jedno pytanie - za pomocą lokalnego systemu / konta usługi sieciowej można dodawać / usuwać wpisy do kontenerów w Active Directory (pod warunkiem, że kontener w Active Directory udzielił pełnych uprawnień komputerowi, na którym działają te usługi Windows). Należy pamiętać, że wszystko działa, gdy uruchomiłem usługę jako jeden z użytkowników domeny, ale nie jako lokalny system / usługa sieciowa (szczegóły stackoverflow.com/questions/20943436/... ) Pozdrawiam
Dreamer

1
Tak, powinno. Odpowiem bezpośrednio na twoje pytanie, ponieważ to pytanie jest bardziej abstrakcyjne i jest konkretną implementacją.
Peter Oehlert

7
Pamiętaj, że „anonimowy” użytkownik nie jest tylko członkiem „uwierzytelnionych użytkowników”, nie jest też członkiem „wszystkich” w systemie Windows. W sieciach Windows „anonimowy” ma dostęp tylko do zasobów, które zostały wyraźnie przyznane „anonimowemu” - domyślnie nic.
David

1
@HakamFostok Nie mam wiele referencji. Jeśli dobrze pamiętam, Dan Brown opisał niektóre z nich w swojej książce Programowanie zabezpieczeń systemu Windows. Jest wiele pomocy w systemie Windows i dokumentów MSDN, ale nie mam konkretnego odniesienia. Książka Jeffa Richtera na temat programowania okien, a także Inside Windows (3. lub 4. edycja) autorstwa Solomana i Russinovicha również ma kilka.
Peter Oehlert
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.