Jak przyznać dostęp sieciowy do konta LocalSystem?

Jak udzielasz dostępu do zasobów sieciowych do LocalSystemkonta (NT AUTHORITY \ SYSTEM)?

tło

Podczas uzyskiwania dostępu do sieci konto LocalSystem działa jak komputer w sieci :

Konto LocalSystem

Konto LocalSystem jest predefiniowanym kontem lokalnym używanym przez menedżera kontroli usług.

... i działa jako komputer w sieci.

Lub jeszcze raz to samo: konto LocalSystem działa jak komputer w sieci :

Gdy usługa działa na koncie LocalSystem na komputerze będącym członkiem domeny, usługa ma dostęp do sieci niezależnie od konta komputera lub dowolnej grupy, do której należy konto komputera.

W jaki sposób można przyznać komputerowi dostęp do udostępnionego folderu i plików?

Uwaga :

Konta komputerowe zazwyczaj mają kilka uprawnień i nie należą do grup.

Jak więc przyznać dostęp komputerowy do jednej z moich akcji; biorąc pod uwagę, że „ wszyscy ” mają już dostęp?

Uwaga : grupa robocza

| Account        | Presents credentials |
|----------------|----------------------|
| LocalSystem    | Machine$             |
| LocalService   | Anonymous            |
| NetworkService | Machine$             |

— Ian Boyd
źródło

To pytanie jest nieco związane z wcześniejszym pytaniem dotyczącym umożliwienia anonimowego dostępu do udziału - przynajmniej wydaje się, że można je rozwiązać za pomocą anonimowo dostępnego udziału.

— CodeFox,

Odpowiedzi:

W środowisku domeny możesz przyznać prawa dostępu do kont komputerów; dotyczy to procesów działających na tych komputerach jako LocalSystemlub NetworkService(ale nie LocalServiceprzedstawiających anonimowych poświadczeń w sieci) podczas łączenia się z systemami zdalnymi.

Tak więc, jeśli masz komputer o nazwie MANGO, będziesz mieć konto komputera usługi Active Directory MANGO$, do którego możesz przyznać uprawnienia.

wprowadź opis zdjęcia tutaj

Uwaga : Nie można tego zrobić w środowisku grupy roboczej; dotyczy to tylko domen.

— Massimo
źródło

+1 i zaakceptowane. Ale: LocalService może uzyskać dostęp do sieci, po prostu „przedstawia anonimowe poświadczenia w sieci” ( msdn.microsoft.com/en-us/library/ms684188(VS.85).aspx )

— Ian Boyd

Wystarczy wspomnieć, że spędziłem niemałą ilość czasu próbując sprawić, by działało w wielu domenach, nie sądzę, aby było to możliwe. tzn. \\ DOMAIN2 \ MANGO $ nie wydaje się udzielać dostępu.

— BennyB

Działa to tylko wtedy, gdy domeny są w relacji zaufania; w przeciwnym razie masz rację, to nie działa.

— Massimo,

Myślałem, że codzienne grupy obejmują uwierzytelnionych użytkowników, a także konto local_service i local_system?

— kakacii

Pamiętaj, że LocalSystemmoże również uzyskać dostęp do wszystkiego, co może zrobić każdy inny proces. Może w ten sposób wykraść dane logowania zalogowanych użytkowników.

— Demi

Ty nie. Jeśli potrzebujesz usługi do łączenia się ze zdalnymi plikami lub innymi usługami sieciowymi, chcesz, aby usługa była uruchamiana jako konto nazwane, a na komputerze zdalnym przypisz prawa do tego konta o nazwie.

Byłoby naprawdę najlepiej, gdybyś dokładnie wyjaśnił, co próbujesz zrobić - w ten sposób uzyskasz najlepsze odpowiedzi.

— mfinni
źródło

Całkowicie niepoprawny. Możesz przyznać uprawnienia kontom komputerów (a tym samym usługom działającym jako one) dokładnie w ten sam sposób, w jaki możesz je przyznać kontom użytkowników. Istnieją oczywiście scenariusze, w których może nie być to najlepsze rozwiązanie, ale jest to całkowicie wykonalne.

— Massimo,

Odpowiedź wyglądała dokładnie tak, to jest powód mojej opinii; także oryginalny plakat wydaje się dość dobrze znać różnicę między kontem użytkownika a kontem komputerowym, więc udzielenie odpowiedzi na pytanie „nie rób tego” po prostu nie wydawało mi się właściwe.

— Massimo,

Poza tym istnieją bardzo uzasadnione scenariusze, w których konieczne byłoby przyznanie uprawnień do kont komputerów. Pomyśl tylko o skryptach uruchamiania komputera, wdrożeniu oprogramowania GPO lub usługach, które po prostu chcą działać jako LocalSystem i nic na to nie poradzisz. Oczywiście nie twierdzę, że jest to najlepsza praktyka lub „właściwe” rozwiązanie; ale jeśli ktoś zapyta „jak to zrobić?” Myślę, że „nie rób tego” zdecydowanie nie jest poprawną odpowiedzią.

— Massimo,

W środowisku grupy roboczej nie można przypisywać praw na MachineB do konta użytkownika zdefiniowanego na MachineA ... poza tym zapytano go, jak przypisać prawa do konta maschine , więc na to odpowiedziałem; i powiedziałem również, że nie byłoby to możliwe bez domeny.

— Massimo,

Ian - jeśli o to ci chodzi, zwykle lepiej jest użyć SQL Server Agent i jego konta lub skorzystać z Integration Services. Możesz uzyskać więcej szczegółów, gdy zadajesz szczegółowe pytanie, i nadal może ono być bardzo przydatne w sytuacjach innych czytelników.

— mfinni

-1

To jest proste:

Umieść konto AD urządzenia w lokalnej grupie administratorów, a następnie urządzenie (lub jego lokalne konto administratora) będzie mogło w pełni uzyskać dostęp do miejsca docelowego ZA CAŁĄ siecią. Testowane dzisiaj, działa dobrze.

— Frank Wolf
źródło

Chociaż jest to funkcjonalne, NIE jest to zalecane ani najlepsza praktyka. Local SystemKonto nazywa lokalny powodu. Jeśli chcesz, aby coś miało dostęp do sieci, usługę lub inną usługę należy zmienić, aby działała jako inny użytkownik. To byłoby jak przyznanie guestkonta administratorowi komputera. To działałoby, ale to przeczy celowi, do czego został zbudowany.

— Cory Knutson