有没有办法找出谁更改了登录密码?


11

我试图找出谁更改了SQL Server 2008 R2中的登录密码。

我已经检查了默认跟踪-它不记录该事件。默认跟踪将包括以下与安全性有关的事件:

/*
    Audit Add DB user event
    Audit Add login to server role event
    Audit Add Member to DB role event
    Audit Add Role event
    Audit Add login event
    Audit Backup/Restore event
    Audit Change Database owner
    Audit DBCC event
    Audit Database Scope GDR event (Grant, Deny, Revoke)
    Audit Login Change Property event
    Audit Login Failed
    Audit Login GDR event
    Audit Schema Object GDR event
    Audit Schema Object Take Ownership
    Audit Server Starts and Stops 
*/

另外,调查事务日志备份可以发现这一点,但是没有运气。

还有其他方法可以找到答案吗?

另外,我知道服务器端跟踪会有所帮助,但是很遗憾,在我们的服务器端跟踪中,我们没有包含Audit Login Change Password Event

我发现的最佳文章来自Aaron Bertrand:跟踪SQL Server中的登录密码更改


2
我将设置Aaron的建议之一,然后将当前的密码哈希备份到某个地方,然后再更改密码。看看谁在尖叫..或只是随机改变回来,然后就可以追踪到他们了。
肯尼斯·费舍尔

密码是否已更改以获取访问权限或阻止他人访问尚不完全清楚。只是说那是因为有人可能不会尖叫。Kin可能也不知道原始密码是什么。
亚伦·伯特兰

可以使用哈希(请问我如何知道哈哈)来重置原始密码,该哈希应该位于事务日志中。
乔恩·塞格尔

Answers:


11

如果您事先进行设置,那么我的文章会有所帮助,但如果事件是过去发生的,而您没有设置任何类型的审核机制,则不会有所帮助。

但是仍然有希望。假设我这样做:

CREATE LOGIN flooberella WITH PASSWORD = N'x', CHECK_POLICY = OFF;

此信息位于EventClass 104(审核Addlogin事件)下的默认跟踪中。但是,如果我使用以下两种方法之一更改密码:

ALTER LOGIN flooberella WITH PASSWORD = N'y';

EXEC sp_password N'y', N'z', N'flooberella';

出于明显的安全原因,默认跟踪不会捕获这些事件-有权访问默认跟踪的任何人都不可能弄清楚别人的密码是什么,他们也不希望轻松地找到该密码密码已更改(例如,轮询这些事件的频率可以揭示安全策略的某些属性)。

那你还能做什么?尽管这依赖于日志中仍然存在的信息,并且还依赖于对系统数据库使用未记录的DBCC命令(您可能希望备份master并将其还原到其他位置),但是您可以从事务日志中获取一些信息,例如:

DBCC LOG(master, 1);

对于以上两个命令,这将产生具有以下(部分)信息的行:

Current LSN             Description
======================  ======================================================================
000000f2:000001b8:0002  ALTER LOGIN;0x01050000000000051500000093a3bcd7a9f8fb1417ab13bce8030000
000000f2:000001b8:0004  Alter login change password;0x01050000000000 ... same sid as above ...

看起来不多,但现在取描述的0x部分,然后执行:

SELECT name FROM sys.server_principals
  WHERE sid = 0x01050000000000051500000093a3bcd7a9f8fb1417ab13bce8030000;

抽烟的枪!这是负责该事件的人。

当然,如果他们ALTER LOGIN对所有操作都使用语法(应使用而不是sp_password),则您无法区分是更改默认数据库的人还是更改密码的人。您也不能告诉(至少我可以看到)该登录名受到影响,仅此人更改登录名。乔恩(Jon)似乎也认为该信息也在日志中,但是我找不到它(与时间信息不同,我以某种方式滚动过去了)。


对于SQL Server 2012中包含的用户,可能会有不同的答案-尽管我怀疑仍然以类似的方式混淆了密码更改。将留一个单独的问题。


我认为您可以使用fn_dblog/ fn_dump_dblog反对master(或它的副本)来找出更改了哪个主体,即使您必须使用来摸索DBCC PAGE
乔恩·塞格尔

认准LOP_XACT_BEGINTransaction ID你发现。它将包含确切的时间和启动它的登录名的SID。
Remus Rusanu 2014年

@Jon会这样认为,但是Page ID和Slot ID为NULL。
亚伦·伯特兰

SQL必须有一种方法来知道如何回滚事务…也许它只是不在TVF中公开那些值,即使它们确实存在。
乔恩·塞格尔

@Jon继续进行研究DBCC LOG(master,3);(或fn_dblog()等效的研究),看是否可以发现任何有助于确定目标的东西。当我这样做时,BEGIN TRANSACTION; ALTER LOGIN...我得到的有用信息就更少了,如果我回滚,这些信息就会消失,而当我提交时,这些信息就会变成上面的信息。
亚伦·伯特兰

4

这比评论要长,可以作为答案发布

select top(10) 
    [Transaction ID], 
    [Begin Time], 
    [Transaction Name], 
    [Transaction SID],
    SUSER_SNAME([Transaction SID])
from fn_dblog(null, null)
where Operation = 'LOP_BEGIN_XACT';

Transaction ID Begin Time               Transaction Name                  Transaction SID
-------------- ------------------------ --------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0000:00002b12  2014/01/08 20:10:14:890  Event_Session_Startup             NULL
0000:00002b13  2014/01/08 20:10:15:027  DBMgr::StartupDB                  NULL
0000:00002b14  2014/01/08 20:10:15:513  AddGuestUserToTempdb              NULL
0000:00002b15  2014/01/08 20:10:15:537  DBMgr::StartupDB                  NULL
0000:00002b16  2014/01/08 20:10:15:537  DBMgr::StartupDB                  NULL
0000:00002b17  2014/01/08 20:10:15:537  DBMgr::StartupDB                  NULL
0000:00002b18  2014/01/08 20:10:15:540  DBMgr::StartupDB                  NULL
0000:00002b19  2014/01/08 20:10:15:550  DBMgr::StartupDB                  NULL
0000:00002b1a  2014/01/11 11:49:42:760  AutoCreateQPStats                 0x010500000000000515000000A065CF7E784B9B5FE77C877084B65600
0000:00002b1b  2014/01/11 11:53:26:620  test_ack                          0x010500000000000515000000A065CF7E784B9B5FE77C877084B65600

(10 row(s) affected)

1
@RemusRusanu仅在您直接查询T日志中的内容时才有用,但是如果您尝试从T日志备份中读取内容,则SID将被砍掉。同样,每次调用fn_dump_dblog时,它都会创建一个新的隐藏SQLOS调度程序和最多三个线程,这些线程永远不会消失,也不会被重用。
Kin Shah 2014年

1

您可以在服务器级别使用DDL触发器(请注意,对于本示例,您必须启用并设置SQL Server数据库邮件功能):

CREATE Trigger [Trg_TrackLoginManagement]
on ALL Server
for DDL_LOGIN_EVENTS
as
set nocount on
declare @data xml,
          @EventType varchar(100),
          @EventTime datetime,
          @ServerName varchar(100),
          @AffectedLoginName varchar(100),
          @WhoDidIt varchar(100),
          @EmailSubject varchar(500),
          @EmailBody varchar(800),
          @EmailRecipients varchar(300)
set @EmailRecipients = 'name@domain.com'
set @data = eventdata()
set @EventType = @data.value('(/EVENT_INSTANCE/EventType)[1]', 'varchar(100)')
set @EventTime = @data.value('(/EVENT_INSTANCE/PostTime)[1]','datetime')
set @ServerName = @data.value('(/EVENT_INSTANCE/ServerName)[1]','varchar(100)')
set @AffectedLoginName = @data.value('(/EVENT_INSTANCE/ObjectName)[1]','varchar(100)')
set @WhoDidIt = @data.value('(/EVENT_INSTANCE/LoginName)[1]','varchar(100)')

set @EmailSubject = 'ALERT: DDL_LOGIN_Event: ' + @EventType + ' occured by ' + @WhoDidIt + ' on ' + @ServerName

set @EmailBody =  'DDL_Login_Event: ' + @EventType + char(10) + 
                 'Event Occured at: ' + convert(Varchar, @EventTime) + char(10) + 
                 'ServerName: ' + @ServerName + char(10) +
                 'Affected Login Name:      ' + @AffectedLoginName + char(10) + 
                 'Event Done by: ' + @WhoDidIt
EXEC msdb.dbo.sp_send_dbmail
    @recipients = @EmailRecipients,
    @body = @EmailBody,
    @subject = @EmailSubject ;
GO
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.