Fehler beim Authentifizieren des Proxy-Kontos beim Ausführen des SSIS-Jobs

Ich habe eine SQL Server-Instanz, die jede Nacht 5 geplante Aufgaben ausführt, von denen jede SSIS-Pakete ausführt.

Diese Pakete werden seit Jahren ausgeführt und die zugehörigen Schritte werden über ein Proxy-Konto (PackageExecutor) ausgeführt. PackageExecuter ist einem SQL-Berechtigungsnachweis zugeordnet, der ein früheres Domänenadministratorkonto war.

Bald wird die mit diesem Administratorkonto verknüpfte Domain heruntergefahren. Ich muss ein neues Konto in einer neuen Domain als Administratorkonto verwenden, das meinem Roxy PackageExecutor zugeordnet ist. Als ich einen neuen Berechtigungsnachweis für das neue Administratorkonto erstellt und ihn mit PackageExecutor verknüpft habe, wurde beim Versuch, einen meiner SQL-Jobs als Test auszuführen, der folgende Fehler angezeigt:

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.

Wenn ich diesen einigermaßen expliziten Fehler verstehe, sagt es mir, dass die mit meinem Proxy verknüpften Berechtigungsnachweiskonten korrekt sind. Wie validiere ich das?

Ich weiß, dass dieses Konto legitim ist. Ich habe es bereits jeder zugeordneten Servergruppe zugeordnet und es zu einem Sysadmin-Benutzer auf dem Server gemacht.

Was könnte dieses Problem verursachen?

Um es klar auszudrücken, habe ich den Kontonamen oder das Kennwort für den Proxy-Berechtigungsnachweis nicht falsch eingegeben. Als ich jedoch den Kontonamen eingab Domain\Admin_Accountund auf die Schaltfläche Namen überprüfen klickte, wandelte SQL Server die Benutzer-ID automatisch in die vollqualifizierte Version um. Ich bin mir nicht sicher, ob dies etwas mit diesem Problem zu tun hat.

Ich bin ein bisschen ratlos. Ich habe meinem Anmeldeinformationskonto vollen Zugriff auf alles gegeben, was mir einfällt. Was muss ich möglicherweise tun, damit dies funktioniert?

AKTUALISIEREN

Entschuldigung, noch eine kurze Erwähnung. Ich habe diesen MSDN kb Artikel gefunden . Die Auflösungsmethode Nr. 1 ist das, was ich seit Jahren mache. Die anderen scheinen sich nicht zu bewerben, oder mir fehlt etwas. Irgendwelche Tipps oder Klarstellungen wären von Vorteil.

Nur für den Fall, dass andere aus dem gleichen Grund hierher gekommen sind. Stellen Sie sicher, dass das Konto, das Ihr Proxy / Berechtigungsnachweis verwendet, ein Benutzer in seiner Standarddatenbank in SQL Security ist.

Wir haben alle anderen Vorschläge durchgesehen (Überprüfung, ob sich das Kennwort nicht geändert hat, Wechsel zu einem lokalen Dienstkonto für SQL Agent-Benutzer, Neuerstellung der Anmeldeinformationen und des Proxys usw.) und bis wir sichergestellt haben, dass das Konto standardmäßig ein Benutzer ist Aus irgendeinem Grund hat DB beim Versuch, sich bei AD zu authentifizieren, eine Null-SID übergeben.

Ein Kommentar zu dieser alten Frage des Frageautors RLH hat für mich gearbeitet, nachdem ich alle anderen Antworten ausprobiert hatte. Deshalb füge ich ihn als Antwort hinzu:

Ich glaube, ich habe dieses Problem gelöst, aber ich weiß nicht warum. Kurz gesagt, anstatt SSMS auf meinem PC zu verwenden, habe ich mich beim Server angemeldet und mich mit dem Konto angemeldet, das dem neuen Berechtigungsnachweis zugeordnet ist. Ich habe die Anmeldeinformationen entfernt, erneut erstellt (diesmal hat sich SQL Server nicht bei @ domain.com beschwert) und dann versucht, einen der Jobs zu testen. Es funktionierte! Anscheinend hat dies etwas geändert und SQL Server dabei geholfen, das Konto aufzulösen.

Starten Sie zuerst den SQL Server-Agenten neu. Ich hatte ein ähnliches Problem und ging so weit, den Proxy und die Anmeldeinformationen neu zu erstellen, aber es funktionierte immer noch nicht. Wir hatten gestern einen Absturzspeicherauszug, der anscheinend die Verbindung unterbrochen hat und die Anmeldeinformationen nicht erkannt hat. Beim Neustart des Agenten und von voilà hat es wieder funktioniert.

Ich bezweifle, dass es viele Menschen gibt, die den gleichen Fehler machen wie ich ...

Ich war in Management Studio mit dem falschen Server verbunden, habe also weiterhin den Benutzernamen und das Kennwort eingegeben und diesen Fehler erhalten. Ich habe den Job auch auf dem falschen Server eingerichtet.

Überprüfen Sie daher, ob die SQL Server-Instanz, mit der Sie verbunden sind, diejenige ist, auf der die Anmeldeinformationen vorhanden sind.

Ich habe einen Berechtigungsnachweis, der unter einem generischen Domänenkonto (AD) ausgeführt wird. Ich habe das Passwort letzte Woche geändert. Das hat die SSIS-Jobs gebrochen. Durch das Aktualisieren des Passworts wurde das Problem behoben.

Ich habe den gleichen Fehler erhalten, ich habe ein Proxy-Konto mit meinen eigenen Anmeldeinformationen für die Datenbanksicherheit verwendet und das Kennwort wurde geändert. Nachdem ich es in den Sicherheits-> Anmeldeinformationen geändert hatte, funktionierte das Paket.

Mein Problem war, dass der SQL Agent-Dienst unter einem Konto ausgeführt wurde, das nicht mehr vorhanden war. Nachdem ich den Agentendienst mit einem gültigen Dienstkonto aktualisiert (siehe hier ) und neu gestartet habe, wurde mein Problem behoben.

_{Community-Wiki-Antwort, die ursprünglich als Kommentar des Frageautors hinterlassen wurde:}

Ich glaube, ich habe dieses Problem gelöst, aber ich weiß nicht warum.

Kurz gesagt, anstatt SSMS auf meinem PC zu verwenden, habe ich mich beim Server angemeldet und mich mit dem Konto angemeldet, das dem neuen Berechtigungsnachweis zugeordnet ist. Ich habe das Credo entfernt, es erneut erstellt (diesmal hat SQL Server keinen Fehler gemacht @domain.com) und dann versucht, einen der Jobs zu testen.

Es funktionierte?! Anscheinend hat dies etwas geändert und SQL Server dabei geholfen, das Konto aufzulösen.

In meinem Fall wurde der SQL Server-Agent unter einem Dienstkonto ausgeführt. Er wurde im Format "abc@Xyz.com" (Benutzername@domainName.com) angegeben. Ich habe das Format in "xyz \ abc" geändert, dh Domänenname \ Benutzername und Proxy funktionierte gut. Tatsächlich seltsam. Ich frage mich immer noch, was sich geändert hat.

Zuvor gemeldete Fehlermeldung: Die Ausführung von Schritt 1 kann nicht gestartet werden (Grund: Fehler beim Authentifizieren des Proxys, Systemfehler: Der Benutzername oder das Kennwort sind falsch). Der Schritt ist fehlgeschlagen.