Microsoft SQL Server obsługuje dwa tryby autoryzacji – autoryzację SQL (wbudowaną) i autoryzację Windows (w tak zwanym trybie mieszanym). W skrócie, różnią się one tym, że w pierwszym przypadku do nawiązania połączenia z serwerem potrzebne są dane autoryzacyjne (użytkownik i hasło), natomiast w drugim używane są uprawnienia bieżącego użytkownika. Nie chcę się tutaj wgłębiać w wyjaśnienia i analizy Microsoftu o tym jak to autoryzacja Windows jest super bezpieczna a SQL jest be, faktem jest natomiast, że niektóre firmy nie życzą sobie, aby jakikolwiek użytkownik systemu (w tym także administrator) miał dostęp do danych przechowywanych w bazie.
Procedura blokowania autoryzacji Windows w SQL Serwerze jest prosta – należy we właściwościach loginów BuildIn\Administrators i BuildIn\Users ustawić pozwolenie na łączenie się z serwerem (permission to connect to database engine) na deny. Poza tym należy usunąć uprawnienie sysadmin dla loginu BuildIn\Administrators – inaczej administratorzy dalej będą mieli możliwość połączenia się z serwerem, a to z tego powodu, że nie ma możliwości zablokowania dostępu do serwera administratorowi serwera. Po wykonaniu powyższego możemy cieszyć się instancją serwera, do której mogą logować się tylko użytkownicy posiadający odpowiedni login na serwerze. Ale czy na pewno?
SQL Server 2005, tak jak i jego poprzednik obsługuje tryb pojedynczego użytkownika (single user mode). Tryb ten jest aktywowany, gdy usługa serwera zostanie uruchomiona z dodatkowym parametrem –m. Co ciekawe, tak uruchomiony serwer, oprócz obsługi tylko jednego połączenia, ustawia rolę sysadmin dla administratorów systemu (niejawnie). Konsekwencją tego i tego co już wspomniałem wyżej jest to, że można się podłączyć do zabezpieczonego serwera korzystając z mechanizmu autoryzacji Windows. Błąd? Ależ skądże. Cały trik doczekał się już własnej pozycji w KB (KB937682) i nosi dumną nazwę failure recovery mechanism.