J’ai déjà eu plusieurs fois à répondre à la question suivante : Sous quel contexte utilisateur s’exécute un travail SQL Server ? Est ce qu’il utilise le compte de service du compte de l’agent ou bien le contexte de son propriétaire ?

La réponse est : cela dépend du contexte  (cela aurait été trop facile sinon :D).

Prenons un exemple simple pour bien comprendre :

Un job SQL Server avec comme propriétaire un compte de connexion test_login sans privilèges particuliers. Le job en question est constitué de 2 étapes :

• une étape TSQL avec la requête SELECT SYSTEM_USER
• une étape de type cmdExec qui exécute un « dir E:\*.* »

On exécute le job et on peut faire le constat suivant :

Le job s’exécute dans le contexte du propriétaire du job (Executed as user:test_login). Cependant la 2ème étape est en erreur mais cela reste logique. En effet pour exécuter une commande de type cmdExec il faut soit faire partir du rôle sysadmin soit utiliser un compte de proxy qui est autorisé à exécuter une telle commande.

 

Nous allons donc dans ce 2ème test ajouter le compte de connexion test_user au rôle de serveur sysadmin et exécuter à nouveau notre job. Voici le résultat :

Cette fois-ci le job s’est exécuté sans problème mais le plus intéressant est le contexte qui a été utilisé ici. L’utilisateur concerné est en réalité le compte de service de l’agent SQL Server (TESTLLAB2\sql2k8svcaccount). Comme vous le savez sans doute ce compte de service est sysadmin sur l’instance SQL Server. Donc quand un compte de connexion est sysadmin c’est le compte de service de l’agent SQL qui est utilisé.

Bien entendu on ne peut pas élever les privilèges d’un compte de connexion uniquement pour qu’il puisse exécuter une commande de type cmdExec. Une bonne pratique est d’utiliser un compte de proxy associé à un credential qui sera autorisé à initier des ordres de type cmdExec. C’est ce que nous allons faire ici. Après exécution du job voici le résultat :

On peut remarquer que le contexte utilisé lors de la 1ère étape est bien celui attendu : test_login qui est, pour rappel, le propriétaire de notre job. Comme nous avons paramétré un compte de proxy (TESTLLAB2\proxycmdexec)pour l’exécution de la 2ème étape c’est le contexte de ce dernier qui est utilisé.

Voilà pour la démonstration !!

David BARBARIN (Mikedavem)
MVP SQL Server