Jak mogę sprawdzić ustawienia zabezpieczeń punktu końcowego programu SQL Server?

Jestem w trakcie tworzenia środowiska TEST dla naszych programistów SQL Server.

W produkcji mamy 3 serwery SQL, SQL01zawiera kilka baz danych, które są dublowane SQL02. SQL03działa jako świadek w „wysokim bezpieczeństwie z automatycznym przełączaniem awaryjnym” lub konfiguracją synchroniczną.

Użyłem VMWare P2V do wirtualizacji wszystkich trzech maszyn na osobny sprzęt, ponownie skonfigurowałem identyfikatory SID tych maszyn i zaczarowałem adresy IP naszych serwerów produkcyjnych z tych nowych maszyn.

Początkowo zapomniałem zakopać czarną maszynę świadka produkcji, więc bazy danych na maszynach TEST nadal używały SQL03maszyny jako świadka. Zauważywszy problem, postanowiłem zmienić konfigurację baz danych w TEST, aby wskazać nowo zwirtualizowanego świadka TEST, nazwij go TEST03.

Aby ponownie skonfigurować bazę danych, aby używała nowego świadka, wprowadziłem następującą komendę na serwerze podstawowym TEST01:

ALTER DATABASE [TestDB] SET WITNESS = 'TCP://TEST03.domain.inet:5022';

Odpowiedź była nieoczekiwana:

The ALTER DATABASE command could not be sent to the remote server instance
'TCP://TEST03.domain.inet:5022'.  The database mirroring configuration was
not changed.  Verify that the server is connected, and try again.

Byłem bardzo zakłopotany tym komunikatem o błędzie, ponieważ konfiguracja działa na maszynach produkcyjnych i nie została w żaden sposób zmodyfikowana na maszynach testowych.

Aby to zadziałało, musiałem utworzyć LOGINświadka testowego:

CREATE LOGIN [DOMAIN\SQLServiceAccount] FOR WINDOWS WITH DEFAULT_DATABASE [Master];

i GRANTma CONNECTprawo do danego punktu końcowego:

GRANT CONNECT ON ENDPOINT::Mirroring TO [DOMAIN\SQLServiceAccount];

Byłem wtedy w stanie z powodzeniem skierować lustrzane bazy danych w środowisku TEST na nowego świadka testowego.

Jak mogę sprawdzić punkt końcowy świadka produkcyjnego, aby zobaczyć, jakie zabezpieczenia są z tym związane?

Zakładam, że musi istnieć jakiś katalog systemu, który mogę sprawdzić, jednak Books-on-Line nie wydaje się mieć nic konkretnego dla punktów końcowych, a Bing ma się dobrze, Bingless ...

Dodatkowe informacje:

SELECT ep.endpoint_id, p.class_desc, p.permission_name, ep.name, sp.name 
FROM sys.server_permissions p
    INNER JOIN sys.endpoints ep ON p.major_id = ep.endpoint_id
    INNER JOIN sys.server_principals sp ON p.grantee_principal_id = sp.principal_id
WHERE class = '105';

zwroty:

endpoint_id class_desc  permission_name endpoint_name   principal_name
2           ENDPOINT    CONNECT TSQL    Local Machine   public
3           ENDPOINT    CONNECT TSQL    Named Pipes     public
4           ENDPOINT    CONNECT TSQL    Default TCP     public
5           ENDPOINT    CONNECT TSQL    Default VIA     public

I:

SELECT name, endpoint_id, protocol_desc, type_desc, role_desc 
FROM sys.database_mirroring_endpoints;

Zwroty:

name        endpoint_id  protocol_desc  type_desc           role_desc 
Mirroring   65536        TCP            DATABASE_MIRRORING  WITNESS

Wygląda na to, że nie ma wpisu sys.server_permissionsdla lustrzanego obiektu punktu końcowego. Nie major_idi nie minor_idpasuje do 65536. Ponadto żadna z systemowych baz danych nie zawiera odniesienia do punktu końcowego.

Jestem zagubiony.

Po spędzeniu części dnia na przenoszeniu lustrzanych baz danych z serwera na serwer w naszym środowisku DEV w ramach przygotowań do przejścia na SQL Server 2012, natknąłem się na ten dokument MSDN, który wyjaśnia, że ​​zabezpieczenia ENDPOINT są określane wyłącznie na podstawie rodzaju konta SQL Server działa pod. Jeśli SQL Server używa konta domeny, to konto automatycznie ma dostęp do punktu końcowego. Jeśli SQL Server korzysta z wbudowanego konta, takiego jak [Usługa sieciowa] lub [System lokalny] itp., Punkt końcowy musi być skonfigurowany za pomocą certyfikatu bezpieczeństwa, a tylko posiadacze certyfikatu mogą uzyskać dostęp do punktu końcowego.

Odpowiednia sekcja z dokumentu:

Określanie typu uwierzytelnienia dla punktu końcowego dublowania bazy danych

Ważne jest, aby zrozumieć, że konta usług SQL Server instancji serwera określają, jakiego rodzaju uwierzytelnienia można użyć dla punktów końcowych dublowania bazy danych, w następujący sposób:

Jeśli każda instancja serwera działa na koncie usługi domeny, możesz użyć uwierzytelnienia systemu Windows dla punktów końcowych dublowania bazy danych. Jeśli wszystkie instancje serwera działają jako to samo konto użytkownika domeny, prawidłowe loginy użytkownika istnieją automatycznie w obu głównych bazach danych. Upraszcza to konfigurację zabezpieczeń baz danych dostępności i jest zalecane.

Jeśli jakiekolwiek instancje serwera, na których znajdują się repliki dostępności dla grupy dostępności, działają jako różne konta, login każdego konta musi zostać utworzony w trybie głównym na drugiej instancji serwera. Następnie temu logowaniu należy przyznać uprawnienia CONNECT do połączenia z punktem końcowym dublowania bazy danych tej instancji serwera.

Jeśli instancje serwera korzystają z uwierzytelniania systemu Windows, można utworzyć punkty końcowe dublowania bazy danych za pomocą Transact-SQL, PowerShell lub Kreatora nowej grupy dostępności.

Uwaga:

Jeśli instancja serwera, która ma obsługiwać replikę dostępności, nie ma punktu końcowego dublowania bazy danych, Kreator nowej grupy dostępności może automatycznie utworzyć punkt końcowy dublowania bazy danych, który korzysta z uwierzytelniania systemu Windows.

Jeśli dowolna instancja serwera działa z wbudowanym kontem, takim jak System lokalny, Usługa lokalna lub Usługa sieciowa lub konto bez domeny, musisz użyć certyfikatów do uwierzytelnienia punktu końcowego. Jeśli używasz certyfikatów dla punktów końcowych dublowania bazy danych, administrator systemu musi skonfigurować każdą instancję serwera, aby używała certyfikatów zarówno dla połączeń wychodzących, jak i przychodzących.

Nie ma zautomatyzowanej metody konfigurowania zabezpieczeń dublowania bazy danych za pomocą certyfikatów. Konieczne będzie użycie instrukcji CREATE ENDPOINT Transact-SQL lub polecenia cmdlet PowerShell New-SqlHadrEndpoint. Aby uzyskać więcej informacji, zobacz UTWÓRZ ENDPOINT (Transact-SQL).

Remus Rusanu (w swojej odpowiedzi) poprawnie określił, jak określić bezpieczeństwo obowiązujące w punkcie końcowym dublowania; jak w:

SELECT ep.name, sp2.name AS Grantee, sp.name AS Grantor, p.permission_name, ep.state_desc
FROM sys.server_permissions p 
    INNER JOIN sys.endpoints ep ON p.major_id = ep.endpoint_id
    INNER JOIN sys.server_principals sp ON p.grantor_principal_id = sp.principal_id
    INNER JOIN sys.server_principals sp2 ON p.grantee_principal_id = sp2.principal_id
WHERE p.class_desc = 'ENDPOINT' AND ep.type_desc = 'DATABASE_MIRRORING'

Jednak w moim przypadku w SQL Server 2005 oryginalne punkty końcowe kopii lustrzanej nie pojawiają się w wynikach tego zapytania - zakładam, że dzieje się tak, ponieważ ich domyślne zabezpieczenia umożliwiają CONNECT dostęp do konta, na którym działa SQL Server (jak wyjaśniono powyżej).

Tak więc kanoniczna odpowiedź na pytanie, skąd wiesz, kto ma dostęp CONNECT do ENDPOINT, jest sumą powyższego zapytania i konta, którego używa SQL Server, wraz z wszelkimi możliwymi certyfikatami skonfigurowanymi z dostępem do punktu końcowego .

Tak się złożyło, że skonfigurowałem to dla produkcyjnej bazy danych i zastanawiałem się nad tym samym, ponieważ musiałem porównać konfigurację z inną sesją dublowania, aby upewnić się, że poprawnie ją dopasowałem.

sys.dm_db_mirroring_connectionspowinien zapewnić ci to, czego chcesz. Zawiera to, principal_nameco jest:

Nazwa loginu, który został sprawdzony pod kątem uprawnień do połączenia. W przypadku uwierzytelniania systemu Windows ta wartość jest nazwą zdalnego użytkownika. W przypadku uwierzytelniania certyfikatu ta wartość jest właścicielem certyfikatu.

Jeśli pracujesz z sesją, która jest wstrzymana, chociaż nie jestem pewien, czy nadal zwróciłoby to informacje, sądzę, że ma ona tylko aktywne połączenia.

Zobacz dokumentację Books Online dla sys.database_mirroring_endpoints

Do uprawnień obiektu serwera spojrzeć na zwykłym miejscu sys.server_permissions. Jak w każdym przypadku, gdy dotyczy to zabezpieczeń systemu Windows, sprawy są bardziej skomplikowane ze względu na członkostwo w grupach systemu Windows, należy także wziąć pod uwagę hierarchię uprawnień .