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
sql-server-2008-r2
security
permissions
logins
Kin Shah
la source
la source
Réponses:
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:
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:
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:
Cela produira, pour les deux commandes ci-dessus, des lignes avec les informations (partielles) suivantes:
Cela ne semble pas beaucoup, mais prenez maintenant cette partie 0x de la description, puis faites:
Pistolet fumant! Il s'agit de la personne responsable de cet événement.
Bien sûr, s'ils utilisent la
ALTER LOGIN
syntaxe pour toutes les opérations (qu'ils devraient utiliser à la placesp_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.
la source
fn_dblog
/fn_dump_dblog
contremaster
(ou une copie de celui-ci) pour déterminer quel principal a été modifié, même si vous devez utiliser spelunkDBCC PAGE
.LOP_XACT_BEGIN
pour ce queTransaction ID
vous avez trouvé. Il contiendra l'heure exacte et le SID de la connexion qui l'a démarré.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.c'est plus long qu'un commentaire, poster comme réponse
la source
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):
la source