Konto usługi sieciowej uzyskujące dostęp do udziału folderu


31

Mam prosty scenariusz. Na serwerze ServerA znajduje się aplikacja działająca pod wbudowanym kontem usługi sieciowej. Musi czytać i zapisywać pliki w udziale folderów na ServerB. Jakie uprawnienia muszę ustawić dla udziału folderu na ServerB?

Mogę go uruchomić, otwierając okno dialogowe bezpieczeństwa udziału, dodając nowego użytkownika zabezpieczeń, klikając „Typy obiektów” i upewniając się, że zaznaczone jest „Komputery”, a następnie dodając ServerA z dostępem do odczytu / zapisu. W ten sposób, jakie konta uzyskują dostęp do udziału? Tylko usługa sieciowa? Wszystkie konta lokalne na serwerze A? Co powinienem zrobić, aby udzielić dostępu do konta ServerA Network Service do udziału ServerB?

Uwaga:
wiem, że jest to podobne do tego pytania . Jednak w moim scenariuszu serwer A i serwer B znajdują się w tej samej domenie.

Odpowiedzi:


27

„Uprawnienia do udostępniania” mogą być „Wszyscy / Pełna kontrola” - naprawdę ważne są tylko uprawnienia NTFS. (Podaj tutaj argumenty religijne osób, które mają niezdrowe przywiązanie do „Uprawnienia do udostępniania” tutaj ...)

W uprawnieniach NTFS do folderu na ServerB można było uzyskać albo „DOMAIN \ ServerA - Modify” lub „DOMAIN \ ServerA - Write”, w zależności od tego, czy trzeba było modyfikować istniejące pliki, czy nie. (Modyfikacja jest naprawdę preferowana, ponieważ aplikacja może ponownie otworzyć plik po utworzeniu go w celu dalszego zapisu - Modyfikacja daje mu to prawo, ale Zapis nie.)

Dostęp będą miały tylko konteksty „SYSTEM” i „Usługa sieciowa” na serwerze A, zakładając, że w uprawnieniu nazwiesz „DOMAIN \ ServerA”. Lokalne konta użytkowników na serwerze ServerA różnią się od kontekstu „DOMAIN \ ServerA” (i trzeba by je nazwać indywidualnie, jeśli w jakiś sposób chcesz im przyznać dostęp).

Na marginesie: role serwera zmieniają się. Możesz chcieć utworzyć grupę w AD dla tej roli, umieścić ServerA w tej grupie i przyznać uprawnienia grupy. Jeśli kiedykolwiek zmienisz rolę ServerA i zastąpisz ją, powiedzmy, ServerC, wystarczy zmienić członkostwo w grupie i nigdy więcej nie musisz dotykać uprawnienia do folderu. Wielu administratorów zastanawia się nad tego rodzaju nazwami użytkowników w uprawnieniach, ale zapominają, że „komputery też są ludźmi”, a ich role czasami się zmieniają. Minimalizowanie pracy w przyszłości (i twojej zdolności do popełniania błędów) jest tym, na czym polega efektywność w tej grze ...


1
Nie można faktycznie przyznać kontom lokalnym na jednym komputerze dostępu do zasobów na innym komputerze.
pipTheGeek

3
@pip: Możesz jednak utworzyć lokalny zasób o tej samej nazwie użytkownika i haśle na zdalnym komputerze, a następnie udzielić temu kontowi wymaganego dostępu. Wynik końcowy jest taki sam.
John Rennie,

8
Usługa sieciowa jest wyjątkiem. To jest mapa całej jako konto komputera. W systemie Windows 2000 konto systemowe zrobiło to samo.
K. Brian Kelley,

1
Nie wydaje się to możliwe dokładnie tak, jak opisano w systemie Windows Server 2008+. Nie mogę dodać serwera jako „domena \ serwer”, ale mogę (jeśli dołączę komputery z „całego katalogu”) tylko jako „serwer”. Ponadto po dodaniu serwer jest oznaczony jako „serwer $”.
Kenny Evitt

12

Konto usługi sieciowej komputera zostanie zamapowane na inny zaufany komputer jako konto nazwy komputera. Na przykład jeśli działasz jako konto usługi sieciowej na serwerze A w MyDomain, powinno to być odwzorowane na MyDomain \ ServerA $ (tak, znak dolara jest konieczny). Widzisz to dość często, gdy masz uruchomione aplikacje IIS jako konto usługi sieciowej łączące się z serwerem SQL Server na innym serwerze, takim jak skalowana instalacja SSRS lub Microsoft CRM.


5

Zgadzam się z Evanem. Uważam jednak, że idealnym rozwiązaniem, jeśli bezpieczeństwo jest dla Ciebie ważne, byłoby utworzenie konta użytkownika specjalnie dla tej aplikacji / usługi, aby działało jako i udzielenie temu kontu niezbędnych uprawnień do folderu współdzielonego. W ten sposób możesz mieć pewność, że tylko ta aplikacja / usługa uzyskuje dostęp do udziału. Może to być jednak przesada.

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.