Użytkownik bez logowania nie jest powiązany z żadnym kontem serwera i służy m.in. do przenoszenia uprawnień.
Użytkownik bazy danych bez obiektu login
W SQL Server użytkownik utworzony bez logowania jest obiektem istniejącym wyłącznie w konkretnej bazie danych. Nie odpowiada mu obiekt serwerowy typu LOGIN, dlatego nie służy do bezpośredniego uwierzytelniania osoby ani aplikacji podczas otwierania sesji. Taki użytkownik może jednak występować jako podmiot uprawnień wewnątrz bazy. Jego utworzenie wykonuje się poleceniem CREATE USER [NazwaUzytkownika] WITHOUT LOGIN;.
Login jest rozpoznawany na poziomie instancji SQL Server, natomiast użytkownik należy do poziomu bazy danych. W przypadku instrukcji WITHOUT LOGIN SQL Server tworzy użytkownika bez powiązania z nazwą logowania, kontem Windows lub innym mechanizmem uwierzytelniania. Aby sprawdzić istniejące obiekty tego typu, można odczytać katalog systemowy, na przykład filtrując widok sys.database_principals według kolumny authentication_type_desc oraz typu użytkownika.
Tworzenie i nadawanie uprawnień
Po utworzeniu użytkownik bez logowania może otrzymać uprawnienia do obiektów bazy, takich jak tabele, widoki, procedury składowane i funkcje. Uprawnienia można nadać bezpośrednio poleceniem GRANT, odebrać przez REVOKE albo zablokować poleceniem DENY. Przykładowo, instrukcja GRANT SELECT ON SCHEMA::Raporty TO [NazwaUzytkownika]; przypisuje temu użytkownikowi prawo odczytu obiektów należących do schematu Raporty, zgodnie z zakresem obowiązującym dla uprawnień schematu.
Użytkownika można także dodać do roli bazodanowej za pomocą ALTER ROLE [NazwaRoli] ADD MEMBER [NazwaUzytkownika];. Wtedy efektywne uprawnienia wynikają również z członkostwa w tej roli. Sam fakt utworzenia użytkownika nie daje automatycznie dostępu do danych. Nie należy mylić go z użytkownikiem typu GUEST, który jest specjalnym mechanizmem umożliwiającym dostęp do bazy dla określonych loginów bez odpowiadającego im użytkownika bazodanowego.
Przenoszenie właściciela i kontrola kontekstu wykonania
Jednym z zastosowań użytkownika bez logowania jest przejęcie własności obiektu lub schematu. W SQL Server właściciel obiektu jest podmiotem bezpieczeństwa, dlatego można zmienić autoryzację poleceniem ALTER AUTHORIZATION ON SCHEMA::Raporty TO [NazwaUzytkownika];, jeżeli wykonujący instrukcję ma wymagane uprawnienia. Taki użytkownik może pełnić funkcję stabilnego właściciela, niezależnego od konkretnego konta pracownika lub loginu technicznego. Ułatwia to przenoszenie obiektów i uprawnień między środowiskami, ponieważ właściciel nie musi być powiązany z loginem istniejącym tylko na jednej instancji.
Użytkownik bez logowania może również służyć jako kontekst bezpieczeństwa dla modułu wykonywanego z klauzulą EXECUTE AS USER. Przykładowo procedura może wykonywać określone operacje w kontekście tego użytkownika, a następnie powrócić do wcześniejszego kontekstu przez REVERT. Nie oznacza to ominięcia kontroli dostępu: SQL Server nadal sprawdza uprawnienia wynikające z użytkownika, jego ról, właścicieli obiektów i łańcucha własności. Przy projektowaniu takiego mechanizmu trzeba sprawdzić, czy kontekst nie uzyskuje szerszego dostępu niż wymagany przez procedurę.
Weryfikacja po utworzeniu użytkownika w SQL Server
Przed utworzeniem obiektu należy upewnić się, że w bazie nie istnieje już użytkownik o tej samej nazwie. Przydatne jest zapytanie do sys.database_principals, ponieważ powtórzenie instrukcji CREATE USER dla istniejącej nazwy zakończy się błędem. Po utworzeniu warto sprawdzić typ podmiotu, identyfikator, właściciela oraz przypisane role i uprawnienia. Szczególną uwagę należy zwrócić na użytkowników o podobnych nazwach, ponieważ nazwa użytkownika bez logowania nie wskazuje, kto faktycznie uruchomił sesję.
Jeżeli problem dotyczy braku dostępu, trzeba rozdzielić trzy kwestie: uwierzytelnienie loginu do instancji, mapowanie loginu na użytkownika w bazie oraz autoryzację operacji na konkretnym obiekcie. Użytkownik utworzony przez WITHOUT LOGIN nie naprawi błędu logowania i nie zastąpi konfiguracji konta Windows ani loginu SQL Server. W środowisku lokalnym lub biurowym można natomiast przeanalizować definicje baz, procedur i ról, aby ustalić, czy taki użytkownik jest potrzebny, czy ma właściwego właściciela i czy zakres jego uprawnień odpowiada rzeczywistemu przepływowi danych.
