Ausführen eines SSIS-Pakets eines Domänenbenutzers von SQL Server, das auf einem lokalen Dienstkonto ausgeführt wird

Ich möchte ein SSIS-Paket ausführen, das Aufgaben zum Übertragen von SQL Server-Objekten enthält. Die beteiligten Server befinden sich in derselben Domäne, die SQL Server-Dienste werden jedoch auf lokalen Dienstkonten ausgeführt. Die Umgebung sieht also so aus:

Domain

Server 1

SQL Server wird auf einem lokalen Konto ausgeführt
Im Dateisystem: SSIS-Paket
In SQL Server Agent: ein Job

Server 2

SQL Server wird auf einem lokalen Konto ausgeführt

Um mich bei beiden Servern anmelden zu können, habe ich ein Domänenkonto erstellt, das als Dienstkonto verwendet werden soll. Wenn ich dieses Domänenkonto verwende, um mich bei Server 1 anzumelden und das Paket dann vom Dateisystem aus auszuführen, ist jeder Schritt erfolgreich. Wenn ich jedoch versuche, den Job zu SQL Server hinzuzufügen, tritt eines der folgenden Probleme auf:

Situation 1. Jobinhaber: lokales Konto; Führen Sie den SSIS-Schritt als Proxy für das Domänenkonto aus . Wenn ich den Jobbesitzer auf ein lokales Konto setze, den Job aber als Proxy für das Domänenkonto ausführe, wird der Job selbst erfolgreich ausgeführt, aber das Paket löst Fehler wie aus

Die Ausführung schlug mit folgendem Fehler fehl: "Das Verzeichnis 'LocalApplicationData' existiert nicht."

Dieser Fehler kann behoben werden, indem auf Server 1 ein Login mit Administratorrechten für den Domänenbenutzer erstellt wird. Dies ist jedoch offensichtlich keine wünschenswerte Lösung. Das Hinzufügen des Kontos zu einer der SQL Server-Agenten- / DTS-Gruppen funktioniert ebenfalls nicht.

Situation 2. Jobinhaber: Domain-Konto; Führen Sie den SSIS-Schritt als Proxy für das Domänenkonto aus . Wenn ich sowohl den Jobbesitzer als auch "Als Benutzer ausführen" für den Schritt zum Domänenkonto festlege, wird der Job mit dem folgenden Fehler überhaupt nicht gestartet:

Es kann nicht festgestellt werden, ob der Eigentümer (Domäne \ Domänenbenutzer) des Jobs Job nameServerzugriff hat (Grund: Es konnten keine Informationen zur Windows NT-Gruppe / zum Benutzer 'Domäne \ Domänenbenutzer', Fehlercode 0x5, abgerufen werden. [SQLSTATE 42000] (Fehler 15404)) .

Ich glaube, der letzte Fehler ist, dass SQL Server auf einem lokalen Konto ausgeführt wird und daher nicht prüfen kann, welche Rechte Domänenkonten haben.

Was ist der richtige Weg, um den Job zum Laufen zu bringen? Situation 2 fühlt sich für mich sauberer an, scheint aber unmöglich, da SQL Server auf einem lokalen Konto ausgeführt wird. Situation 1 würde auch funktionieren, aber es wird nicht passieren, dass einem Domänenbenutzer Administratorrechte auf meinem SQL Server erteilt werden.

AKTUALISIEREN:

@ JonSeigel und @ Mr.Brownstone:

Es erscheint plausibel, dass dieses Problem auf den Mangel an Berechtigungen zurückzuführen ist. Der Fehler betrifft jedoch die nicht vorhandene 'LocalApplicationData' - einen der Ordner, die für jedes Konto generiert werden. Ich habe mich bereits mit den Anmeldeinformationen, unter denen das Paket ausgeführt wird, beim Server angemeldet (hiermit ein Profilverzeichnis erstellen) und verschiedene Kombinationen von Berechtigungen für das Profilverzeichnis ausprobiert. Selbst wenn fast alle Berechtigungen für dieses bestimmte Verzeichnis manuell erteilt werden, wird der oben genannte Fehler angezeigt.

Während ich weiter recherchierte, stieß ich unter http://www.sqlservercentral.com/Forums/Topic391332-148-1.aspx#bm391441 auf einen Forenthread, der ziemlich ähnlich ist - allerdings auch ohne Lösung.

sql-server ssis

— vstrien
quelle

Gibt es einen Grund, warum Sie kein Domänenkonto für SQL-Dienste verwenden?

— Eric Higgins

Ja, aber ich weiß nicht aus welchem Grund (ich denke, der DTAP-Zyklus und die Domain sind nicht überall verfügbar). Wie auch immer, es ist eine gegebene Umgebung, die ich nicht ändern darf.

— Vstrien

Situation Nr. 1 scheint die Antwort zu sein. Ich denke, die Fehlermeldung, die Sie erhalten, stammt aus dem Paket. Mit anderen Worten, das Paket wird ausgeführt, für eine darin enthaltene Aufgabe sind jedoch mehr Berechtigungen erforderlich, als dem Dienstkonto gewährt wurde. Möglicherweise müssen Sie dem Konto keine Berechtigungen auf Administratorebene erteilen, damit es erfolgreich ist (stattdessen granulare Berechtigungen erteilen oder den Prozess so ändern, dass die Berechtigungen nicht benötigt werden).

— Jon Seigel

Können Sie dem Remote-SQL Server (Server 2) SQL-Anmeldungen (SQL-Authentifizierung) hinzufügen? Wenn Sie diese Option haben, können Sie die SQL-Anmeldung in der für das Ziel verwendeten SSIS-Verbindung verwenden. Das bedeutet, dass Sie ein Passwort verwenden müssen, um das Paket zu verschlüsseln, aber es wird Ihr Problem lösen.

— Roi Gavish

@Justicator: Vielleicht als letztes Mittel. Wenn jedoch Domänenanmeldungen möglich sind, bevorzuge ich die Verwendung der SQL-Authentifizierung.

— Vstrien

Meine persönliche Meinung ist, dass Option 1 der richtige Weg ist. Ich sehe jedoch keine Notwendigkeit, dass Sie dem Domänenadministrator lokalen Administratorzugriff gewähren müssen. Es scheint mir, dass der Zugriff auf bestimmte Ordner und Dateien erforderlich ist, sodass Sie dem Domänenbenutzer nur Zugriff auf die Ressourcen gewähren können, die für die erfolgreiche Ausführung des Pakets erforderlich sind. Dies kann über das Dialogfeld Eigenschaften von Datei / Ordner erfolgen und die Registerkarte Sicherheit auswählen. Es sollte nicht erforderlich sein, sie für jede Datei und jeden Ordner festzulegen, da Sie die Berechtigungen des übergeordneten Verzeichnisses festlegen und festlegen können, dass untergeordnete Eigenschaften überschrieben werden.

Ich hoffe das hilft dir.

— Herr Brownstone
quelle