Lors de la mise en place des audits de sécurité je me suis heurté à cette fameuse erreur 33203 sur une instance nommée qui indique explicitement que SQL Server ne peut pas écrire dan le journal de sécurité Windows.  Ma configuration est la suivante : SQL Server 2012 SP1  et Windows 2012 Server.

Je précise avant de commencer que les prérequis de fonctionnement des audits avec le journal de sécurité Windows sont respectés. La conséquence directe de l’erreur 33203 est qu’au évènement n’est enregistré dans le journal de sécurité Windows, ce qui est plutôt gênant pour des audits. De plus les journaux des erreurs Windows et SQL Server ne sont pas spécialement bavards quant à la cause de cette erreur.

 

 

Dans ce cas comment savoir ce qui empêche SQL Server d’écrire dans le journal ? Je dois dire que les outils sysinternals sont bien utiles dans ces moments et en particulier procmon.

Une capture procmon me donne ceci lorsque j’active un objet d’audit depuis SQL Server :

 

On peut remarquer ici que SQL Server tente un accès à la clé de registre HKLM\System\CurrentControlSet\Services\EventLog\Security et que cet accès lui est visiblement refusé. Un message est également inscrit dans le journal des erreurs SQL. Pas de souci, nous allons configurer les permissions adéquates sur cette clé de registre.

 

 

Le paramétrage des permissions a visiblement permis à l’instance SQL Server de créer une nouvelle clé de registre dans HKLM\System\CurrentControlSet\Services\EventLog\Security :

 

…

 

Me croyant sauvé, j’active mes audits mais je me heurte à une nouvelle erreur. Une nouvelle trace procmon me révèle le problème suivant :

 

 

SQL Server tente de lire le fichier C:\Windows\System32\LogFiles\Sum\Api.log mais encore un fois ce dernier se voit refuser l’accès. Le paramétrage en lecture seule du fichier Api.log me permet enfin d’activer mes audits et de valider que les évènements soient bien enregistrés dans le journal de sécurité Windows. Ce deuxième problème visiblement a été remonté chez Microsoft et est toujours d’actualité. A noter que je n’ai eu ce souci que pour mon instance nommé dans mon cas.

 

Quelques remarques supplémentaires :

• Le fait d’enlever le compte de service SQL des permissions de la clé de registre HKLM\System\CurrentControlSet\Services\EventLog\Security ne semble plus être gênant à partir du moment où la nouvelle clé a été créé.
• Il n’est pas possible cependant d’enlever les permissions sur le fichier C:\Windows\System32\LogFiles\Sum\Api.log sous peine d’avoir dans le journal des évènements Windows le type d’erreur suivant et plus d’évènement d’audit enregistré. A voir si le problème sera résolu plus tard par Microsoft (dans un CU4 peut être ?) avec Windows Server 2012. L’ensemble des problèmes répertoriés concerneraient Windows Server 2012.
• Je ne pense pas que le problème soit lié à la version de SQL Server. Si j’ai le temps je testerai sur une version SQL Server 2008 R2 et mettrait à jour mon blog.

 

 

Bonne activation d’audit !!

 

David BARBARIN (Mikedavem)
MVP SQL Server