Konto usługi SQL Server Uprawnienia i prawa systemu Windows


12

Moje pytanie brzmi: jeśli utworzysz nowe konto użytkownika domeny dla każdego procesu SQL Server, jakie uprawnienia należy ustawić dla każdego konta? Czy menedżer konfiguracji SQL faktycznie się tym zajmuje i właśnie miałem nieprzewidziany problem?

Dość często muszę konfigurować Microsoft SQL Server i zastanawiałem się, czy ktoś może udzielić porady na temat konfigurowania kont, na których usługi powinny działać. IMO zostało to niejasno udokumentowane przez Microsoft, podczas gdy wskazują one właściwy kierunek, nigdy nie udało mi się znaleźć żadnych konkretnych przykładów.

Podsumowując to, co do tej pory widziałem:

W przypadku prostych wdrożeń \ środowisk programistycznych można używać domyślnych kont wirtualnych, z których korzysta instalator: np NT SERVICE\MSSQLSERVER

Unikaj korzystania z SYSTEMkonta, nie jest to bezpieczne.

W środowiskach produkcyjnych i domenowych zaleca się korzystanie z konta usługi zarządzanej lub utworzenie konta użytkownika domeny (nie administratora) dla każdej usługi. Podobno jeśli użyjesz konta domeny w czasie instalacji, instalator ustawi dla ciebie wszelkie wymagane uprawnienia.

W przypadku zmiany konta usługi w istniejącej instalacji z konta wirtualnego na konto domeny zaleca się użycie menedżera konfiguracji SQL Server do ustawienia nowych kont usług. Podobno ustawi to dla ciebie wszelkie wymagane uprawnienia.

Właśnie próbowałem zmienić konto usługi w istniejącej instalacji na konto domeny i dawałoby mi to awarię logowania, dopóki nie udzielę uprawnienia do konta log on as service, co jest sprzeczne z częścią, w której menedżer konfiguracji programu SQL Server ustawi wszelkie wymagane uprawnienia. (Chociaż nie jestem pewien, czy obiekt GPO mógł ingerować w ustawianie lokalnych zasad bezpieczeństwa)

Firma Microsoft udostępnia listę uprawnień, które Instalator programu SQL Server przyznaje na tej stronie .

Ale nie jest dla mnie jasne, czy jest to coś, co powinienem zrobić ręcznie dla użytkownika, który tworzę, aby uruchomić usługę jako, czy też użycie menedżera konfiguracji SQL powinno automatycznie ustawić te uprawnienia.

SQL Server 2014, kontroler domeny działa w systemie Windows Server 2008 R2.


Która wersja SQL? Czy to środowisko AD? Jeśli tak, jaki jest poziom domeny?
Katherine Villyard,

Dzięki, dodałem wersje do pytania. SQL Server 2014, kontroler domeny jest na poziomie funkcjonalności Windows Server 2008 R2

1
Nie wygląda mi to na niejasną dokumentację. Wygląda to dość kompleksowo. - msdn.microsoft.com/en-us/library/ms143504.aspx

Tak, zgadzam się, ogólna dokumentacja jest dobra, ale to, o czym nie jestem pewien, było niejasne, o to mi chodziło. Masz rację, w zasadzie dokumentacja jest bardzo szczegółowa.
plumdog

Odpowiedzi:


10

Dość często muszę konfigurować MS SQL Server i zastanawiałem się, czy ktoś może udzielić porady na temat konfigurowania kont, na których usługi powinny działać. IMO zostało to niejasno udokumentowane przez Microsoft, podczas gdy wskazują one właściwy kierunek, nigdy nie udało mi się znaleźć żadnych konkretnych przykładów.

Jest to właściwie dokładnie udokumentowane: http://msdn.microsoft.com/en-us/library/ms143504.aspx

Czy jest jakaś część, której nie jesteś pewien?

W przypadku prostych wdrożeń \ środowisk programistycznych można używać domyślnych kont wirtualnych, z których korzysta instalator: np. NT SERVICE \ MSSQLSERVER

Będzie to zależeć od środowiska. Ja osobiście nienawidzę znajdowania kogoś, kto skonfiguruje serwer przy użyciu konta lokalnego i proszenie o dostęp do zasobów sieciowych w przyszłości, między innymi.

W środowiskach produkcyjnych i domenowych zaleca się korzystanie z konta usługi zarządzanej lub utworzenie konta użytkownika domeny (nie administratora) dla każdej usługi.

Znowu zależy, ale generalnie zgodziłbym się (kontrprzykładem byłyby grupy dostępności, w których sensowne jest używanie jednego konta domeny we wszystkich instancjach).

Podobno jeśli użyjesz konta domeny w czasie instalacji, instalator ustawi dla ciebie wszelkie wymagane uprawnienia.

O ile nie wystąpi awaria itp., Zrobi to. Nie jestem pewien, dlaczego część „rzekomo”.

W przypadku zmiany konta usługi w istniejącej instalacji z konta wirtualnego na konto domeny zaleca się użycie menedżera konfiguracji SQL Server do ustawienia nowych kont usług. Podobno ustawi to dla ciebie wszelkie wymagane uprawnienia.

Zmieniając dowolną z usług SQL Server, zawsze używaj SSCM. Zawsze. Kropka. Ustawi podstawowe uprawnienia dla nowego konta. Jeśli przed użyciem lokalnego konta systemowego nie było nieograniczonych uprawnień do wszystkiego w systemie, oczekiwałbym, że coś się nie powiedzie po zmianie z powodu ściślejszej kontroli bezpieczeństwa. To nie jest błąd SSCM programu SQL Server, to błąd administratora polegający na nieprzyznaniu odpowiednich uprawnień EXTRA (takich jak dostęp do udziału sieciowego, ograniczonych folderów, elementów spoza zakresu instalacji SQL Server itp.)

Właśnie próbowałem zmienić konto usługi w istniejącej instalacji na konto domeny i dawałoby mi to awarię logowania, dopóki nie udzielę uprawnienia do logowania się jako usługa, co jest sprzeczne z częścią, w której menedżer konfiguracji programu SQL Server ustawi dowolne wymagane uprawnienia. (Chociaż nie jestem pewien, czy GPO mógł ingerować w ustawianie lokalnych zasad bezpieczeństwa)

Wygląda na to, że GPO powoduje problem (IMHO). Nie byłby to pierwszy raz :)

Więc moje pytanie brzmi: jeśli utworzysz nowe konto użytkownika domeny dla każdego z procesów SQL Server, jakie uprawnienia należy ustawić dla każdego konta?

Jawnie ustawiłbym wszelkie uprawnienia poza tymi wymienionymi w linku msdn, który mam powyżej (również udzielony przez @joeqwerty i w twoim OP). Na przykład w folderze „kopii zapasowej” w udziale sieciowym, na nowym dysku dodanym do przechowywania nowych baz danych (gdzie instalacja była już uruchomiona, ale dysk nie istniał) itp.

Ale nie jest dla mnie jasne, czy jest to coś, co powinienem zrobić ręcznie dla użytkownika, który tworzę, aby uruchomić usługę jako, czy też użycie menedżera konfiguracji SQL powinno automatycznie ustawić te uprawnienia.

Chyba że coś jest bardzo zepsute z serwerem, nie trzeba tego ręcznie podawać.


Dziękuję za odpowiedź, zgadzam się z twoimi komentarzami. Zainstalowałem serwer SQL na innej czystej maszynie wirtualnej, aby to sprawdzić, i mogłem zmienić konto wirtualne NT SERVICE / MSSQLSERVER na konto użytkownika domeny i działało to bez problemu. Myślę więc, że odpowiedź jest taka, jak powiedziałeś, użyj SQL Server Configuration Manager, aby zmienić dane logowania do konta użytkownika usługi i nie powinny być wymagane żadne dodatkowe uprawnienia.
plumdog

Jeden dodatkowy komentarz, przepraszam, że mogłem wyjaśnić moje pytanie, umieszczając mój główny punkt na górze postu, co zrobię w przyszłości. Główne pytanie, którego nie byłem pewien, brzmiało; [jeśli utworzysz nowe konto użytkownika domeny dla każdego procesu SQL Server, jakie uprawnienia należy ustawić dla każdego konta? ...]. Powodem, dla którego czułem, że dokumentacja była niejasna, jest to, że istnieje lista uprawnień, które są ustawione, ale nie jest jasne, czy SSCM je dla ciebie ustawi.
plumdog

@plumdog Na Twój drugi komentarz większość uprawnień udziela instalator. Konto usługi wirtualnej i identyfikator sid są z tym związane, dlatego SSCM powinien zawsze być używany, aby przekazywanie i usuwanie powiązanych z nim uprawnień odbywało się poprawnie, między innymi takich jak bezpieczeństwo związane z szyfrowaniem klucza głównego usługi itp. .
Sean Gallardy
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.