Résoudre les échecs des tâches de SQL Server Agent avec des gMSA

S’applique à : SQL Server sur Windows

Résumé

Cet article vous aide à résoudre les échecs d’étapes de tâche de SQL Server Agent qui se produisent après avoir modifié le compte de service SQL Server Agent en un compte de service géré par un groupe (gMSA). Il couvre SQL Server Integration Services (SSIS), le plan de maintenance, la sauvegarde, PowerShell et les étapes de travail CmdExec qui échouent, car la nouvelle identité d'exécution n'a pas les autorisations requises pour le partage, NTFS, le proxy, les informations d'identification ou le package.

Avant de commencer, consultez les prérequis et exécutez la liste de contrôle de validation rapide dans Résoudre les échecs de configuration, de démarrage et d’authentification de SQL Server avec des gMSA.

Symptoms

  • SQL Server Agent démarre, mais les étapes du travail SSIS, plan de maintenance, sauvegarde, PowerShell ou CmdExec échouent.
  • Les étapes de travail ont commencé à échouer une fois que le compte de service SQL Server Agent a été remplacé par un compte de service gMSA.
  • Les erreurs identifient un composant manquant, un fichier, un proxy, des informations d’identification, un partage ou une autorisation NTFS.

Cause

Un échec d’une étape de tâche survenant après une modification du compte de service est généralement un problème d’accès pour la nouvelle identité, et non un problème de gestion de mot de passe gMSA. Les étapes de travail qui n'utilisent pas de proxy s'exécutent en tant que compte de service SQL Server Agent. Accordez donc à gMSA chaque partage, NTFS et autorisation de destination que le compte précédent avait.

Diagnostiquer les échecs des tâches de l’Agent SQL Server

  1. Identifiez le sous-système d’étape de travail défaillant et la première erreur actionnable dans l’historique des travaux.
  2. Vérifiez l’identité qui exécute réellement l’étape : le compte de service SQL Server Agent ou un compte proxy. Pour plus d’informations, consultez Créer un proxy SQL Server Agent.
  3. Pour les chemins d’accès réseau et les ressources de destination, vérifiez que les autorisations de partage et NTFS sont accordées au gMSA au format <DomainName>\<GmsaName>$, y compris le signe dollar final. Remplacez <GmsaName> et <DomainName> par les noms de domaine et de compte.
  4. Vérifiez que le gMSA dispose des autorisations requises sur le service de destination, comme une cible de sauvegarde, un serveur lié ou un partage de fichiers.

Résultat attendu : l’identité d’exécution dispose d’une autorisation explicite sur chaque ressource que l’étape de travail utilise.

Résoudre les échecs des tâches de l’Agent SQL Server

Utilisez la solution qui correspond à la première erreur actionnable dans l’historique des travaux.

Accorder des autorisations sur la ressource de destination à l’identité d’exécution

  1. Déterminez le compte sous lequel l’étape de travail ayant échoué s’exécute :

    • Une étape de travail CmdExec qui ne spécifie pas de proxy s'exécute sous le compte de service de SQL Server Agent.
    • Étape de travail qui spécifie un proxy SQL Server Agent s’exécute sous le compte Windows stocké dans les informations d’identification du proxy.
    • Une étape de travail Transact-SQL n'utilise pas de proxy SQL Server Agent. Il s’exécute dans le contexte de sécurité du propriétaire du travail. Si le propriétaire du travail est membre du sysadmin rôle serveur fixe, l’étape s’exécute sous le compte de service SQL Server Agent, sauf si un autre utilisateur de base de données est spécifié.

  2. Accordez les autorisations requises à l’identité d’exécution :

    • Si l’étape du travail s’exécute sous le compte de service SQL Server Agent et que ce compte est un gMSA, spécifiez la forme de compte d’ordinateur gMSA de l’identifiant, qui inclut un signe dollar final ($). Par exemple : CONTOSO\SQLAgentSvc$.
    • Si l’étape du travail utilise un proxy, accordez des autorisations au compte Windows associé aux informations d’identification du proxy, et non automatiquement au compte de service SQL Server Agent ou gMSA.
    • Pour un partage de fichiers, accordez uniquement les autorisations requises à l’identité d’exécution sur le partage SMB et le dossier NTFS sous-jacent.

  3. Pour vérifier l’identité et le partage d’accès, exécutez temporairement les commandes suivantes dans une étape CmdExec d’un travail qui utilise la même configuration Run as que l’étape en échec.

    whoami
dir "\\FileServer\BackupShare"

    Résultat attendu : la whoami commande retourne l’identité d’exécution attendue et la dir commande répertorie le contenu du partage.

  4. Supprimez l’étape de diagnostic temporaire après le test.

Corriger le proxy SQL Server Agent, les informations d’identification ou le contexte d’exécution de l’étape du travail

Examinez l’étape de tâche ayant échoué et vérifiez son sous-système ainsi que l’option Exécuter en tant que. Pour un sous-système qui prend en charge les proxys, créez ou utilisez un proxy qui répond aux conditions suivantes :

  • Fait référence à des informations d’identification pour le compte de Windows requis.
  • Est activé pour le sous-système des étapes de tâche.
  • Est disponible pour le rôle de connexion ou de SQL Server Agent propriétaire ou exécutant le travail.
  • Utilise un compte disposant des autorisations requises par l’étape de travail.

Attribuez le proxy à l’étape de la tâche. La création d’un proxy n’accorde pas d’autorisations de ressource au compte stocké dans ses informations d’identification. Accordez ces autorisations séparément et suivez le principe du privilège minimum. Pour plus d’informations, consultez Créer un proxy SQL Server Agent.

Résoudre les erreurs d’autorisation ou d’accès au package SSIS

Si une étape de travail SSIS échoue avec des erreurs d’autorisation ou d’accès au package, vérifiez que le compte exécutant l’étape de travail SSIS peut accéder aux ressources suivantes :

  • Emplacement du package SSIS.
  • Fichiers de configuration et fichiers de commande, s’ils sont utilisés.
  • Fichiers et dossiers référencés par le package.
  • Partages réseau.
  • Bases de données et autres sources de données.
  • Autres ressources externes requises par le package.

Si le package utilise des informations sensibles protégées par le paramètre SSIS ProtectionLevel , vérifiez que le compte d’exécution peut déchiffrer les informations requises. Une modification apportée au compte d'exécution SQL Server Agent peut entraîner l'échec d'un package SSIS lorsque le nouveau compte ne peut pas déchiffrer les secrets du package ou n'a pas l'autorisation d'accéder à une ressource externe. Pour plus d’informations, consultez le package SSIS ne s’exécute pas lorsqu’il est appelé à partir d’une étape de travail SQL Server Agent.

Installer ou réparer des composants manquants confirmés

Installez ou réparez uniquement les composants manquants et corrigez la compatibilité du déploiement ou du runtime SSIS séparément de la modification du compte. Si l’historique des travaux identifie un composant manquant, vérifiez que le composant est installé et disponible pour l’identité d’exécution avant de modifier les autorisations. Voici quelques exemples :

  • Composants SSIS.
  • Modules PowerShell requis par le travail.
  • Exécutables ou scripts personnalisés référencés par les étapes de tâche CmdExec.
  • Fournisseurs requis ou autres composants runtime.

Résolvez les erreurs de composant manquant ou d’exécution séparément des erreurs d’autorisation. Une fois le composant installé ou réparé, réexécutez le travail. En cas d’échec, passez en revue la première erreur actionnable dans l’historique des travaux.

Collecter des données de diagnostic

Si l’étape du travail échoue toujours après avoir effectué ces étapes, collectez l’historique des travaux ayant échoué et d’autres données de diagnostic pour le même intervalle d’échec. Pour obtenir les données de preuve spécifiques à gMSA et les journaux d’activité de SQL Server standard à collecter, consultez Collecte des données de diagnostic dans la vue d’ensemble de la résolution des problèmes gMSA. Utilisez ces données pour poursuivre l’enquête ou ouvrir un cas de support.

Contenu connexe

  • Dernière mise à jour :