Existe-t-il un moyen de savoir qui a changé le mot de passe pour une connexion?


11

J'essaie de savoir qui a changé le mot de passe pour une connexion dans SQL Server 2008 R2.

J'ai déjà vérifié la trace par défaut - et il n'enregistre pas cet événement. La trace par défaut comprendra ces événements liés à la sécurité:

/*
    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 
*/

Aussi, regardé dans la sauvegarde du journal des transactions pour le découvrir, mais pas de chance.

Existe-t-il un autre moyen de le savoir?

De plus, je suis conscient qu'une trace côté serveur aidera, mais malheureusement dans notre trace côté serveur, nous n'avons pas inclus le Audit Login Change Password Event.

Le meilleur article que j'ai trouvé provient d'Aaron Bertrand: Suivi des modifications de mot de passe de connexion dans SQL Server


2
Je voudrais configurer une des suggestions d'Aaron, puis sauvegarder le hachage de mot de passe actuel quelque part, puis changer le mot de passe. Voyez qui crie .. ou s'il est simplement changé au hasard, vous avez alors la trace en place pour les attraper.
Kenneth Fisher

Il n'est pas tout à fait clair si le mot de passe a été modifié pour y accéder ou pour empêcher l'accès à quelqu'un d'autre. Je le dis simplement parce que quelqu'un pourrait ne pas crier. Kin pourrait également ne pas savoir quel était le mot de passe d'origine.
Aaron Bertrand

Le mot de passe d'origine pourrait être réinitialisé à l'aide du hachage (demandez-moi comment je sais haha), qui devrait être quelque part dans le journal des transactions.
Jon Seigel

Réponses:


11

Mon article vous aidera si vous le configurez à l'avance, mais pas lorsque l'événement s'est produit dans le passé et qu'aucun mécanisme d'audit n'a été configuré.

Il y a cependant encore de l'espoir. Disons que je l'ai fait:

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

Ces informations se trouvent dans la trace par défaut sous EventClass 104 (Audit Addlogin Event). Cependant, si je change le mot de passe en utilisant l'une de ces méthodes:

ALTER LOGIN flooberella WITH PASSWORD = N'y';

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

Ces événements ne sont pas capturés par la trace par défaut, pour des raisons de sécurité évidentes - il ne devrait pas être possible à quiconque ayant accès à la trace par défaut de déterminer le mot de passe de quelqu'un d'autre, ni de faciliter la découverte de un mot de passe a été modifié (interroger la fréquence de ces événements, par exemple, peut révéler certaines propriétés de votre stratégie de sécurité).

Alors, que pouvez-vous faire d'autre? Bien que cela repose sur les informations toujours présentes dans le journal et sur l'utilisation d'une commande DBCC non documentée sur une base de données système (vous souhaiterez peut-être sauvegarder le maître et le restaurer ailleurs), vous pouvez obtenir des informations du journal des transactions, par exemple:

DBCC LOG(master, 1);

Cela produira, pour les deux commandes ci-dessus, des lignes avec les informations (partielles) suivantes:

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

Cela ne semble pas beaucoup, mais prenez maintenant cette partie 0x de la description, puis faites:

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

Pistolet fumant! Il s'agit de la personne responsable de cet événement.

Bien sûr, s'ils utilisent la ALTER LOGINsyntaxe pour toutes les opérations (qu'ils devraient utiliser à la place sp_password), vous ne pouvez pas faire la distinction entre quelqu'un qui change la base de données par défaut et quelqu'un qui change le mot de passe. Vous pouvez également ne pas dire (au moins que je peux voir) qui logger ce touché, seulement que cette personne a changé une connexion. Jon semble penser que ces informations sont également dans le journal, mais je n'ai pas réussi à les trouver (contrairement aux informations de temps, que j'ai en quelque sorte fait défiler à droite).


Il peut y avoir différentes réponses pour les utilisateurs confinés dans SQL Server 2012 - bien que je soupçonne que les modifications de mot de passe sont toujours obscurcies de manière similaire. Laissera cela pour une question distincte.


Je pense que vous pouvez utiliser fn_dblog/ fn_dump_dblogcontre master(ou une copie de celui-ci) pour déterminer quel principal a été modifié, même si vous devez utiliser spelunk DBCC PAGE.
Jon Seigel

Recherchez le LOP_XACT_BEGINpour ce que Transaction IDvous avez trouvé. Il contiendra l'heure exacte et le SID de la connexion qui l'a démarré.
Remus Rusanu

@Jon vous le pensez, mais l'ID de page et l'ID d'emplacement sont NULS.
Aaron Bertrand

Il doit y avoir un moyen pour SQL de savoir comment annuler la transaction ... peut-être que ce n'est tout simplement pas exposer ces valeurs dans le TVF même si elles sont réellement là.
Jon Seigel

@Jon allez-y et jetez un œil DBCC LOG(master,3);(ou l' fn_dblog()équivalent) et voyez si vous pouvez repérer tout ce qui pourrait aider à identifier la cible. Lorsque je le fais, BEGIN TRANSACTION; ALTER LOGIN...j'obtiens des informations encore moins utiles, qui disparaissent si je recule et deviennent celles ci-dessus si je m'engage.
Aaron Bertrand

4

c'est plus long qu'un commentaire, poster comme réponse

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 Cela ne sera utile que si vous interrogez directement le contenu du T-log, mais si vous essayez de lire à partir d'une sauvegarde du T-log, les SID seront coupés. De plus, chaque fois que fn_dump_dblog est appelé, il crée un nouveau planificateur SQLOS caché et jusqu'à trois threads, qui ne disparaîtront jamais et ne seront jamais réutilisés.
Kin Shah

1

Vous pouvez utiliser le déclencheur DDL au niveau du serveur (notez que pour cet exemple, vous devez activer et définir la fonctionnalité de messagerie de base de données 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
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.