Mój artykuł pomoże, jeśli skonfigurujesz go z wyprzedzeniem, ale nie wtedy, gdy wydarzenie miało miejsce w przeszłości i nie miałeś skonfigurowanego żadnego mechanizmu kontroli.
Jednak wciąż jest nadzieja. Powiedzmy, że to zrobiłem:
CREATE LOGIN flooberella WITH PASSWORD = N'x', CHECK_POLICY = OFF;
Informacje te znajdują się w domyślnym zapisie w EventClass 104 (Audit Addlogin Event). Jeśli jednak zmienię hasło przy użyciu jednej z następujących metod:
ALTER LOGIN flooberella WITH PASSWORD = N'y';
EXEC sp_password N'y', N'z', N'flooberella';
Zdarzenia te nie są przechwytywane przez domyślny ślad, z oczywistych względów bezpieczeństwa - nikt nie powinien mieć dostępu do domyślnego śledzenia, aby dowiedzieć się, jakie jest hasło innej osoby, ani nie chce ułatwić, aby dowiedzieć się, że hasło zostało zmienione (na przykład sondowanie częstotliwości tych zdarzeń może ujawnić pewne właściwości strategii bezpieczeństwa).
Co jeszcze możesz zrobić? Chociaż polega to na tym, że informacje nadal znajdują się w dzienniku, a także na użyciu nieudokumentowanej komendy DBCC względem systemowej bazy danych (możesz wykonać kopię zapasową wzorca i przywrócić ją w innym miejscu), możesz uzyskać pewne informacje z dziennika transakcji, na przykład:
DBCC LOG(master, 1);
Spowoduje to, dla powyższych dwóch poleceń, wiersze z następującymi (częściowymi) informacjami:
Current LSN Description
====================== ======================================================================
000000f2:000001b8:0002 ALTER LOGIN;0x01050000000000051500000093a3bcd7a9f8fb1417ab13bce8030000
000000f2:000001b8:0004 Alter login change password;0x01050000000000 ... same sid as above ...
Nie wydaje się to dużo, ale teraz weź tę część 0x opisu, a następnie wykonaj:
SELECT name FROM sys.server_principals
WHERE sid = 0x01050000000000051500000093a3bcd7a9f8fb1417ab13bce8030000;
Palenie pistoletu! To osoba odpowiedzialna za to wydarzenie.
Oczywiście, jeśli używają ALTER LOGIN
składni do wszystkich operacji (których powinni używać zamiast sp_password
), nie można odróżnić osoby zmieniającej domyślną bazę danych od osoby zmieniającej hasło. Nie można też powiedzieć (przynajmniej to widzę), które zalogować to wpływ, tylko że ta osoba zmieniła się zalogować. Jon wydaje się myśleć, że ta informacja również znajduje się w dzienniku, ale nie udało mi się jej znaleźć (w przeciwieństwie do informacji o czasie, które jakoś przewinęłam w przeszłość).
W SQL Server 2012 mogą być różne odpowiedzi dla zamkniętych użytkowników - choć podejrzewam, że zmiany haseł są nadal zaciemniane w podobny sposób. Pozostawię to na osobne pytanie.