Mi artículo ayudará si lo configura con anticipación, pero no cuando el evento ocurrió en el pasado y no tenía ningún tipo de mecanismo de auditoría configurado.
Sin embargo, todavía hay esperanza. Digamos que hice esto:
CREATE LOGIN flooberella WITH PASSWORD = N'x', CHECK_POLICY = OFF;
Esta información se encuentra en el rastreo predeterminado en EventClass 104 (Audit Addlogin Event). Sin embargo, si cambio la contraseña usando cualquiera de estos métodos:
ALTER LOGIN flooberella WITH PASSWORD = N'y';
EXEC sp_password N'y', N'z', N'flooberella';
Estos eventos no son capturados por la traza predeterminada, por razones obvias de seguridad: no debería ser posible para cualquier persona con acceso a la traza predeterminada averiguar cuál es la contraseña de otra persona, ni quieren que sea fácil incluso descubrir que se ha cambiado una contraseña (al sondear la frecuencia de estos eventos, por ejemplo, puede revelar ciertas propiedades de su estrategia de seguridad).
Entonces, ¿qué más puedes hacer? Si bien esto se basa en la información que todavía está en el registro, y también se basa en el uso de un comando DBCC no documentado contra una base de datos del sistema (es posible que desee hacer una copia de seguridad del maestro y restaurarlo en otro lugar), puede obtener alguna información del registro de transacciones, p.ej:
DBCC LOG(master, 1);
Esto generará, para los dos comandos anteriores, filas con la siguiente información (parcial):
Current LSN Description
====================== ======================================================================
000000f2:000001b8:0002 ALTER LOGIN;0x01050000000000051500000093a3bcd7a9f8fb1417ab13bce8030000
000000f2:000001b8:0004 Alter login change password;0x01050000000000 ... same sid as above ...
No parece mucho, pero ahora toma esa porción 0x de la descripción, y luego haz:
SELECT name FROM sys.server_principals
WHERE sid = 0x01050000000000051500000093a3bcd7a9f8fb1417ab13bce8030000;
¡Pistola humeante! Esta es la persona responsable de ese evento.
Por supuesto, si usan la ALTER LOGIN
sintaxis para todas las operaciones (que deberían usar en lugar de sp_password
), no puede distinguir entre alguien que cambia la base de datos predeterminada y alguien que cambia la contraseña. Tampoco puede decir (al menos eso puedo ver) qué inicio de sesión afectó, solo que esta persona cambió un inicio de sesión. Jon parece pensar que esta información también está en el registro, pero no pude encontrarla (a diferencia de la información de tiempo, que de alguna manera me desplacé más allá).
Puede haber diferentes respuestas para los usuarios contenidos en SQL Server 2012, aunque sospecho que los cambios de contraseña todavía se ofuscan de manera similar. Dejaré eso para una pregunta separada.