SQL Agent – Owner des Jobs Danger

On voit trop souvent des travaux (Job) SQL Agent avec comme propriétaire un nom d’utilisateur et ceci n’est pas une bonne chose, laissez moi vous expliquer pourquoi :

Lorsque je crée un travail sur l’agent SQL, il me propose par défaut le login de la connexion en cours comme propriétaire :

Cela va très bien fonctionner tant que j’existe dans l’Active Directory de la société, mais que se passe-t-il si le compte « Maboite\csauget » est supprimé ? (Et oui la crise tout ça tout ça, je suis viré …)

Et bien le travail ne s’exécutera plus avec l’erreur suivante :

STATUS:              Failed

MESSAGES:        The job failed.  Unable to determine if the owner (Maboite\csauget) of job Mon Job has server access (reason: Unspecified error occurred on SQL Server. Connection may have been terminated by the server. [SQLSTATE HY000] (Error 0)).

Donc dans le meilleur des cas vous contrôlez vos jobs tous les jours vous constatez l’erreur et vous corrigez. Dans le pire des cas, le job de backup planifié quotidiennement ne se lance plus depuis le départ de votre très chère collègue et personne ne s’en est rendu compte depuis 6 mois.

Une solution simple est de mettre le compte SA en propriétaire, même si celui-ci est désactivé, le job se lancera sans problème.

Un certain nombre de légendes urbaines tourne autour de ce champ propriétaire :

•  « Si je met un compte ici, c’est lui qui exécute mon job », ce n’est pas complètement faux, si par exemple je met un login sql Lambda (Un datawriter sur une base par exemple) le job s’exécutera en son nom.
  Exemple :Avec un job :Dans ma table test je me retrouve bien avec le login : « Maboite\csauget », attention, ceci est possible car le login Maboite\csauget a des droits en écriture sur la base en question.Par contre, si j’essaie de lancer un autre type de tâche (Powershel par exemple) cela ne fonctionnera pas il sera nécessaire d’utiliser des proxy.

Message
Non-SysAdmins have been denied permission to run PowerShell job steps without a proxy account. The step failed.

• « Mettre SA est dangereux, car c’est SA qui exécute mon job »  en effet au vu de ce que je viens de vous dire, vous avez peur, vous vous dites que si vous mettez SA, tous ce qui sera exécuté aura les droits administrateurs sur SQL Server, et bien rassurez vous, ce n’est pas le cas. En effet, si un compte owner est Sysadmin alors ce sont les credentials du compte de service SQL Agent qui seront utilisés.