Widok sys.server_principals z kontami AD

Konta AD widoczne w sys.server_principals to logowania zmapowane bezpośrednio z Active Directory.

Widok sys.server_principals z kontami AD — czym jest

Widok sys.server_principals przedstawia podmioty, które mogą uwierzytelniać się na poziomie instancji Microsoft SQL Server. Znajdują się w nim między innymi logowania utworzone lokalnie w silniku, logowania oparte na grupach lub użytkownikach Active Directory, a także wbudowane konta używane przez samą platformę. Wpis dotyczący konta AD nie oznacza jeszcze, że dana osoba ma dostęp do każdej bazy ani że może wykonywać dowolne operacje. Oznacza przede wszystkim, że tożsamość z katalogu została rozpoznana przez instancję jako możliwy podmiot logowania.

W praktyce konto lub grupa AD może być widoczna w tym widoku jako principal na poziomie serwera. Taki wpis ma własny identyfikator, nazwę, typ oraz właściwości związane z uwierzytelnianiem i uprawnieniami. Nazwa zwykle zawiera domenę i nazwę obiektu, na przykład zapis przypominający DOMENA\uzytkownik albo DOMENA\Grupa-SQL. Sposób prezentacji zależy od rodzaju obiektu, wersji SQL Server, ustawień domenowych oraz metody, która została użyta do utworzenia logowania.

Najważniejsze jest rozróżnienie pomiędzy logowaniem a użytkownikiem bazy danych. Logowanie znajduje się na poziomie instancji i odpowiada za przejście pierwszego etapu uwierzytelniania. Użytkownik bazy danych działa natomiast w konkretnej bazie i otrzymuje tam członkostwo w rolach lub uprawnienia do obiektów. Jedno logowanie może mieć odpowiadającego użytkownika w kilku bazach, a w każdej z nich zakres dostępu może być inny. Sam odczyt nazwy w sys.server_principals nie jest więc wystarczającą podstawą do oceny faktycznych możliwości konta.

Widok sys.server_principals z kontami AD — kontekst techniczny i porównania

Warto porównać kilka typów wpisów, ponieważ podobna nazwa nie zawsze oznacza identyczne zachowanie. Logowanie SQL Server korzysta z mechanizmu kont utrzymywanych przez silnik i zwykle jest rozpoznawane po typie wskazującym uwierzytelnianie SQL. Obiekt AD korzysta natomiast z tożsamości zarządzanej poza instancją. Może to być pojedynczy użytkownik, grupa bezpieczeństwa albo inny obiekt katalogowy dopuszczony przez środowisko. Dla administratora różnica ma znaczenie podczas analizy cyklu życia kont, zmian członkostwa w grupach oraz wyłączania dostępu.

Grupa AD często upraszcza zarządzanie uprawnieniami. Zamiast dodawać każdą osobę osobno, można utworzyć jedno logowanie dla grupy i przypisać mu odpowiednie role. W takim modelu zmiana składu zespołu odbywa się w katalogu, a konfiguracja instancji pozostaje stabilna. Trzeba jednak pamiętać, że uprawnienia wynikające z członkostwa mogą być pośrednie. Użytkownik może nie mieć osobnego wpisu w sys.server_principals, a mimo to uzyskać dostęp przez grupę, grupę zagnieżdżoną albo inną relację określoną w zasadach katalogowych.

Obecność wpisu można zestawić z jego stanem. Niektóre logowania mogą być wyłączone, mieć zmienione właściwości albo pozostawać po dawnym wdrożeniu. Nazwa principal nie mówi również, kiedy konto było ostatnio używane. Do pełniejszej oceny potrzebne są informacje z katalogu, konfiguracji instancji, mapowania w bazach oraz rejestrów logowania. Nie należy wyciągać wniosku o aktywności wyłącznie na podstawie tego, że nazwa nadal pojawia się w widoku.

Znaczenie ma także zgodność identyfikatora zabezpieczeń. Nazwa obiektu w katalogu może zostać ponownie użyta po usunięciu pierwotnego konta, lecz nowy obiekt nie musi mieć tego samego identyfikatora. Dlatego przy porządkowaniu starych wpisów należy weryfikować tożsamość obiektu, a nie tylko porównywać tekstową nazwę. Taka kontrola pomaga uniknąć przypisania dostępu niewłaściwej osobie lub grupie.

Widok sys.server_principals z kontami AD — typowe problemy i błędne interpretacje

Częstym problemem jest brak możliwości utworzenia logowania dla wskazanego użytkownika lub grupy. Przyczyną może być nieprawidłowa nazwa, brak rozpoznania domeny, niedostępność kontrolera katalogu, ograniczenia uprawnień osoby wykonującej operację albo różnica pomiędzy środowiskiem, w którym działa instancja, a środowiskiem użytkownika. Sam fakt, że konto istnieje w katalogu, nie gwarantuje, że zostanie poprawnie znalezione z poziomu SQL Server.

Inny przypadek to błąd logowania mimo obecności principal w widoku. Wtedy należy rozdzielić kilka etapów: rozpoznanie tożsamości, dopuszczenie logowania na poziomie instancji, znalezienie użytkownika w wybranej bazie oraz sprawdzenie uprawnień do konkretnego obiektu. Awaria może występować tylko w jednym z tych miejsc. Na przykład logowanie może działać przy połączeniu z instancją, ale brak użytkownika w bazie docelowej może uniemożliwić korzystanie z tabel lub procedur.

Do pomyłek prowadzi również utożsamianie konta AD z kontem lokalnym SQL Server. Zmiana hasła domenowego, członkostwa w grupie i zasad blokady jest zarządzana inaczej niż zmiana danych logowania utrzymywanych przez silnik. W konsekwencji inna będzie ścieżka diagnostyczna oraz osoba odpowiedzialna za usunięcie problemu. Należy ustalić, jaki typ principal znajduje się w widoku, z jakiego źródła pochodzi tożsamość i kto administruje tym źródłem.

Ryzyko stwarza pozostawianie szerokich uprawnień grupom, których skład zmienia się bez odpowiedniej kontroli. Dotyczy to zwłaszcza grup ogólnych, kont technicznych oraz wpisów tworzonych tymczasowo na potrzeby wdrożenia. Audyt powinien obejmować nazwę principal, typ, stan, powiązane role oraz mapowanie do użytkowników baz danych. Warto też sprawdzić, czy wpis jest nadal potrzebny i czy jego zakres odpowiada aktualnemu zadaniu.

Nie należy usuwać wpisu tylko dlatego, że jego nazwa wygląda na nieużywaną. Przed zmianą trzeba ustalić zależności, sprawdzić aplikacje oraz potwierdzić, czy dostęp nie jest wykorzystywany przez proces wykonywany cyklicznie. Bezpieczniejsza analiza uwzględnia historię zmian, komunikaty błędów i uzgodnienie z właścicielem systemu. Dopiero później można rozważyć wyłączenie, ograniczenie albo usunięcie logowania.

Widok sys.server_principals z kontami AD — praktyczne wskazówki diagnostyczne

Analizę najlepiej rozpocząć od zebrania podstawowych danych o wpisie: nazwy, typu, identyfikatora oraz stanu. Następnie należy przejść do konkretnej bazy i sprawdzić, czy istnieje odpowiadający użytkownik oraz jakie ma członkostwa. Jeżeli konto należy do grupy, trzeba uwzględnić także uprawnienia odziedziczone. Dopiero taki zestaw informacji pokazuje, czy problem dotyczy uwierzytelniania, mapowania czy autoryzacji.

Przy porównywaniu środowisk warto używać tej samej metody i tych samych kryteriów. Wpis może występować na jednej instancji, a nie występować na innej, mimo że nazwa obiektu w katalogu jest identyczna. Należy sprawdzić, czy logowanie zostało utworzone lokalnie na każdej instancji, czy zastosowano skrypt wdrożeniowy oraz czy różnią się zasady rozpoznawania domeny. Pomocne jest dokumentowanie zmian w postaci daty, celu, właściciela i zakresu przyznanego dostępu.

Przydatne jest rozdzielenie uprawnień administracyjnych od dostępu do danych. Konto używane do codziennej pracy nie powinno otrzymywać szerszego zakresu tylko po to, aby ominąć problem z pojedynczym obiektem. Lepiej zidentyfikować brakujące uprawnienie, nadać je na właściwym poziomie i zweryfikować rezultat. W przypadku grup należy utrzymywać czytelne nazwy oraz opisy, dzięki którym późniejszy przegląd nie wymaga odtwarzania historii z pamięci administratora.

Warto także badać zachowanie po zmianach w katalogu. Usunięcie osoby z grupy powinno skutkować utratą dostępu zgodnie z przyjętym modelem, lecz aktywna sesja może zachować wcześniej uzyskany kontekst do czasu rozłączenia. Test powinien więc obejmować nowe połączenie, dostęp do wymaganej bazy oraz próbę operacji, która wcześniej była dozwolona. Wynik należy zapisać wraz z użytym kontem, grupami i czasem wykonania.

Widok sys.server_principals z kontami AD — kiedy zgłosić się do serwisu

Zgłoszenie problemu jest zasadne, gdy konto lub grupa AD pojawia się w sys.server_principals, lecz połączenie kończy się błędem, dostęp działa tylko z wybranej lokalizacji albo uprawnienia różnią się między podobnymi środowiskami. Warto przekazać komunikat błędu, nazwę instancji, nazwę bazy, używany typ uwierzytelniania oraz informację, czy problem dotyczy pojedynczego konta, czy całej grupy. Tak przygotowane dane skracają etap ustalania, w którym miejscu występuje niezgodność.

Pomoc może być potrzebna również przy porządkowaniu dawnych logowań, przeglądzie członkostw, sprawdzaniu mapowania użytkowników albo planowaniu bezpiecznej zmiany uprawnień. Szczególnej ostrożności wymagają sytuacje, w których nie wiadomo, czy wpis jest wykorzystywany przez aplikację lub zadanie automatyczne. Wtedy przed zmianą należy wykonać analizę zależności i ustalić procedurę wycofania modyfikacji.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się także diagnozowaniem problemów ze sprzętem laptopa i komputerami PC, gdy trudność z dostępem do narzędzi lub danych wynika z awarii urządzenia, systemu albo konfiguracji stanowiska. Przy zgłoszeniu warto opisać objawy, moment ich wystąpienia i ostatnie wykonane zmiany, aby możliwe było właściwe rozdzielenie problemu sprzętowego od ustawień konta.