Erreur lors de l'authentification du compte proxy lors de l'exécution du travail SSIS
J'ai une instance SQL Server qui exécute 5 tâches planifiées chaque nuit, chacune exécutant des packages SSIS.
Ces packages fonctionnent depuis des années et les étapes associées sont exécutées via un compte proxy (PackageExecutor). PackageExecuter est associé à un identifiant SQL qui était un ancien compte d'administrateur de domaine.
Bientôt, le domaine associé à ce compte administrateur va être arrêté. Je dois utiliser un nouveau compte, sur un nouveau domaine, comme compte administrateur associé à mon roxy, PackageExecutor. Lorsque j'ai créé un nouveau justificatif d'identité pour le nouveau compte Admin et l'ai associé à PackageExecutor, j'ai commencé à obtenir l'erreur suivante lorsque j'ai essayé d'exécuter l'un de mes travaux SQL comme test:
Unable to start execution of step 1 (reason: Error authenticating
proxy *Domain\Admin_Account*@*fully.qualified.domain.com*, system
error: Logon failure: unknown user name or bad password.). The step
failed.
Si je comprends cette erreur raisonnablement explicite, ce que cela me dit, c'est que les comptes d'informations d'identification, associés à mon proxy, sont corrects. Comment puis-je valider cela?
Je sais que ce compte est légitime - je l'ai déjà associé à chaque groupe de serveurs associé, j'en ai fait un utilisateur sysadmin sur le serveur.
Quelle pourrait être la cause de ce problème?
Pour être clair, je n'ai pas mal saisi le nom de compte ou le mot de passe associé aux informations d'identification du proxy. Cependant, lorsque j'ai entré le nom du compte Domain\Admin_Account et en cliquant sur le bouton Vérifier les noms, SQL Server a automatiquement transformé l'ID utilisateur en version complète. Je ne sais pas si cela a quelque chose à voir avec ce problème.
Je suis un peu perdu. J'ai donné à mon compte d'identification un accès complet à tout ce à quoi je peux penser. Que dois-je faire pour que cela fonctionne?
[~ # ~] mise à jour [~ # ~]
Désolé, encore une petite mention. J'ai trouvé cet article MSDN kb . La méthode de résolution # 1 est ce que je fais depuis des années. Les autres ne semblent pas appliquer, ou je manque quelque chose. Tout conseil ou clarification serait bénéfique.
Juste au cas où d'autres seraient arrivés ici pour la même raison. Assurez-vous que le compte que votre proxy/informations d'identification utilise est un utilisateur dans sa base de données par défaut dans SQL Security.
Nous sommes passés par toutes les autres suggestions (vérifier que le mot de passe n'a pas changé, passer à un compte de service local pour l'utilisateur de l'Agent SQL, reconstruire les informations d'identification et le proxy, etc.) et jusqu'à ce que nous nous soyons assurés que le compte était un utilisateur par défaut DB, pour une raison quelconque, le faisait passer un NID SID quand il essayait de s'authentifier auprès d'AD.
Essayez de redémarrer l'Agent serveur SQL d'abord. J'ai eu un problème similaire et suis allé jusqu'à recréer le proxy et les informations d'identification, mais cela n'a toujours pas fonctionné. Nous avons eu un vidage sur incident qui s'est produit hier et a apparemment rompu la connexion et n'a pas reconnu les informations d'identification. Redémarrage de l'agent et voilà, cela a fonctionné à nouveau.
Un commentaire sur cette ancienne question de l'auteur de la question, RLH a fonctionné pour moi après avoir essayé toutes les autres réponses, donc je l'ajoute comme réponse:
Je crois avoir résolu ce problème mais je ne sais pas pourquoi. En bref, au lieu d'utiliser SSMS sur mon PC, je me suis connecté à distance au serveur en me connectant avec le compte associé aux nouvelles informations d'identification. J'ai supprimé les informations d'identification, je les ai recréées (cette fois, SQL Server ne s'est pas plaint auprès de @ domain.com), puis j'ai tenté d'exécuter un test sur l'un des travaux. Ça a marché! Apparemment, cela a changé quelque chose et a aidé SQL Server à résoudre le compte.
J'obtenais la même erreur, j'utilisais un compte proxy avec mes propres informations d'identification de sécurité de base de données et le mot de passe avait changé. Une fois que je l'ai changé dans la sécurité -> informations d'identification, le package a commencé à fonctionner.
J'ai un justificatif d'identité exécuté sous un compte de domaine générique (AD). J'ai changé de mot de passe la semaine dernière. Cela a brisé les travaux SSIS. La mise à jour du mot de passe l'a corrigé.
Je doute qu'il y ait beaucoup de gens qui feront la même erreur que moi ...
J'étais connecté dans Management Studio au mauvais serveur, j'ai donc continué à taper le nom d'utilisateur et le mot de passe et à obtenir cette erreur. J'étais également en train de configurer le travail sur le mauvais serveur.
Vérifiez donc que l'instance SQL Server à laquelle vous êtes connecté est celle sur laquelle les informations d'identification existent.
Dans mon cas, l'agent SQL Server s'exécutait sous un compte de service, il était spécifié dans le format - "[email protected]" ([email protected]), j'ai changé le format en "xyz\abc", c'est-à-dire DomainName\Username et proxy a bien fonctionné. Étrange en effet. Je me demande encore ce qui a changé.
Message d'erreur signalé précédemment: impossible de démarrer l'exécution de l'étape 1 (raison: erreur d'authentification du proxy, erreur système: le nom d'utilisateur ou le mot de passe est incorrect). L'étape a échoué.
Réponse wiki communautaire initialement laissé comme commentaire par l'auteur de la question:
Je crois avoir résolu ce problème mais je ne sais pas pourquoi.
En bref, au lieu d'utiliser SSMS sur mon PC, je me suis connecté à distance au serveur en me connectant avec le compte associé aux nouvelles informations d'identification. J'ai supprimé le crédit, je l'ai recréé (cette fois, SQL Server n'a pas commis d'erreur au @domain.com) puis j'ai tenté d'exécuter un test sur l'un des travaux.
Ça a marché?! Apparemment, cela a changé quelque chose et a aidé SQL Server à résoudre le compte.
Mon problème était que le service d'agent SQL fonctionnait sous un compte qui n'existait plus. Une fois que j'ai mis à jour le service d'agent avec un compte de service valide (voir this ) et que je l'ai redémarré, mon problème a été résolu.