Il mio articolo sarà di aiuto se lo hai impostato in anticipo, ma non quando l'evento si è verificato in passato e non hai impostato alcun tipo di meccanismo di controllo.
C'è ancora speranza, però. Diciamo che ho fatto questo:
CREATE LOGIN flooberella WITH PASSWORD = N'x', CHECK_POLICY = OFF;
Questa informazione si trova nella traccia predefinita in EventClass 104 (Audit Addlogin Event). Tuttavia, se cambio la password utilizzando uno di questi metodi:
ALTER LOGIN flooberella WITH PASSWORD = N'y';
EXEC sp_password N'y', N'z', N'flooberella';
Questi eventi non vengono acquisiti dalla traccia predefinita, per ovvi motivi di sicurezza: non dovrebbe essere possibile per chiunque abbia accesso alla traccia predefinita per capire qual è la password di qualcun altro, né vogliono renderlo facile nemmeno scoprire che una password è stata modificata (il polling della frequenza di questi eventi, ad esempio, può rivelare alcune proprietà della tua strategia di sicurezza).
Quindi cos'altro puoi fare? Sebbene ciò si basi sulle informazioni ancora presenti nel registro e si basi anche sull'uso di un comando DBCC non documentato su un database di sistema (è possibile eseguire il backup del master e ripristinarlo altrove), è possibile ottenere alcune informazioni dal registro delle transazioni, per esempio:
DBCC LOG(master, 1);
Ciò produrrà, per i due comandi precedenti, righe con le seguenti informazioni (parziali):
Current LSN Description
====================== ======================================================================
000000f2:000001b8:0002 ALTER LOGIN;0x01050000000000051500000093a3bcd7a9f8fb1417ab13bce8030000
000000f2:000001b8:0004 Alter login change password;0x01050000000000 ... same sid as above ...
Non sembra molto, ma ora prendi quella parte 0x della descrizione, e poi fai:
SELECT name FROM sys.server_principals
WHERE sid = 0x01050000000000051500000093a3bcd7a9f8fb1417ab13bce8030000;
Pistola fumante! Questa è la persona responsabile di quell'evento.
Naturalmente, se usano la ALTER LOGIN
sintassi per tutte le operazioni (che dovrebbero usare invece di sp_password
), non è possibile distinguere tra qualcuno che modifica il database predefinito e qualcuno che cambia la password. Inoltre non puoi dire (almeno che posso vedere) quale accesso ha interessato questo, solo che questa persona ha cambiato un accesso. Jon sembra pensare che anche queste informazioni siano nel registro, ma non sono riuscito a trovarle (a differenza delle informazioni temporali, che in qualche modo ho fatto scorrere oltre).
Potrebbero esserci risposte diverse per gli utenti contenuti in SQL Server 2012, anche se sospetto che le modifiche alla password siano ancora offuscate in modi simili. Lo lascerò per una domanda separata.