SSIS vs. SQL: Identitätswechsel — wie ein Agent-Job an die Ressourcen kommt, die er braucht

Ein SQL-Server-Agent-Job, der eine CSV-Datei von einem File Share lesen soll, scheitert mit Access is denied — der Service-Account des Agents hat auf dieser Freigabe keine Berechtigung. Statt dem Service-Account immer mehr Rechte zu geben, wechselt der Job-Step die Identität: Identitätswechsel (englisch impersonation) zur Laufzeit, im SQL Server Agent über einen Proxy. Eine Grenze bleibt: Reine Transact-SQL Script-Steps kennen keinen Proxy und damit keinen Windows-Identitätswechsel. Der Workaround führt über ein SSIS-Paket oder einen CmdExec-Step. Ob er trägt, entscheidet eine Frage, die leicht übersehen wird: Wer liest die Datei tatsächlich?

Was dich erwartet:

• In welchem Sicherheitskontext ein Job-Step ohne Proxy läuft — Service-Account beim Proxy-fähigen Step, Job-Owner beim T-SQL-Step — und warum beides selten passt.
• Schritt-für-Schritt-Anlage Credential → Proxy → Job-Step, parallel in SSMS-GUI und T-SQL.
• Warum reine Transact-SQL Script-Steps keinen Proxy unterstützen, wieso EXECUTE AS dort kein Ersatz ist — und wie sich die Lücke über einen SSIS-Wrapper oder CmdExec mit sqlcmd.exe schließen lässt, samt der Frage, welcher Prozess die Datei dabei wirklich liest.
• Was Identitätswechsel jenseits On-Prem heißt: Group Managed Service Accounts (gMSA), Azure SQL Managed Instance, Azure Data Factory mit Managed Identity, SQL Server on Linux, Container/Pod-Identity.

Voraussetzung: SQL Server 2017+ unter Windows, SSMS für die GUI-Konfiguration und ein Login mit ausreichenden Rechten. CREATE CREDENTIAL verlangt die Server-Permission ALTER ANY CREDENTIAL, das Anlegen und Freigeben eines Proxys über sp_add_proxy und sp_grant_login_to_proxy ist standardmäßig der Server-Rolle sysadmin vorbehalten. EXECUTE-Rechte auf diese msdb-Prozeduren lassen sich zwar delegieren, können laut MS-Doku aber bei einem SQL-Server-Upgrade zurückgesetzt werden.

Inhalt

• Überblick
• Das Service-Account-Problem
• Die Lösung: Credential + Proxy-User
• Schritt für Schritt: Konfiguration
• Sackgasse: T-SQL-Script-Step hat kein Run As
• Identitätswechsel jenseits On-Prem-Agent
• Take-Away
• FAQ
• Verwandte Artikel

Überblick

SQL Server Integration Services (SSIS) ist ein mächtiges Toolset für die Entwicklung von ETL-Strecken. Es gibt viele gute Gründe für einen Einsatz von SSIS und genauso viele, die dagegen sprechen. Beschränkt man sich auf den Microsoft-Stack, kommt als Alternative für die Entwicklung komplexer ETL-Strecken im Wesentlichen nur noch Transact-SQL (T-SQL) in Frage.

Dieser Artikel gehört zu einer Serie von Artikeln, die wichtige Entscheidungskriterien für die Wahl zwischen SSIS und T-SQL beleuchten.

Wird ein SQL-Server-Agent-Job gestartet, läuft ein Step ohne konfigurierten Proxy standardmäßig im Sicherheitskontext des Service-Accounts des SQL Server Agent. Die Ausnahme sind Transact-SQL Script-Steps: Sie laufen im SQL-Sicherheitskontext des Job-Owners, bei sysadmin-Ownern faktisch unbeschränkt (dazu unten mehr). Der Service-Account selbst wird beim Setup festgelegt — entweder als explizites Domänen-/Maschinen-Konto oder als lokales Systemkonto NT AUTHORITY\System.

Mit dieser Auswahl hat der Service-Account einen festen Satz an Berechtigungen, die selten zu allen Jobs passen. Das lokale Systemkonto NT AUTHORITY\System hat umfassende Rechte an lokalen Ressourcen und ist Mitglied der Windows-Gruppe Administratoren. Bei Netzwerk-Zugriffen tritt es dagegen als Computerkonto der Maschine auf (DOMAIN\RECHNER$) — und dass ein File Share, eine fremde Instanz oder eine Cross-Domain-Ressource ausgerechnet dieses Computerkonto berechtigt, ist die Ausnahme, nicht die Regel.

Nach dem Need-to-Know-Prinzip (jeder Account bekommt genau die Rechte, die er für seine Aufgabe braucht — nicht mehr, nicht weniger) sollte ein Job-Step unter einem dedizierten Account laufen, dessen Rechte zur konkreten Aufgabe passen. Da in einem typischen SQL Server Agent dutzende Jobs mit sehr unterschiedlichen Anforderungen konfiguriert sind, lässt sich das nicht über einen einzigen Service-Account abbilden.

Microsofts Antwort darauf ist der Identitätswechsel (englisch impersonation) zur Laufzeit. Konkret: Ein einzelner Job-Step kann unter einem anderen Login als dem Service-Account ausgeführt werden, indem ein Proxy-User (im Microsoft-Wortlaut ein SQL Server Agent Proxy) zugewiesen wird.

Das Service-Account-Problem

Spürbar wird die Reibung, sobald ein Job-Step auf Ressourcen außerhalb der SQL-Server-Instanz zugreifen muss:

• File Share für CSV-/Excel-Quelldateien, auf den der Service-Account keine Berechtigung hat.
• Datenquellen anderer SQL-Server-Instanzen, an denen der Service-Account kein Login besitzt.
• Domain-Ressourcen (LDAP-Abfragen, Active-Directory-Lookups), für die nur ein dediziertes Service-Konto berechtigt ist.
• Cloud-Endpoints (Storage Accounts, externe APIs), die ein anderes Auth-Token verlangen als das, was der Service-Account beistellt.

Die naive Lösung wäre, dem Service-Account einfach mehr Rechte zu geben. Das skaliert aber nicht: Jede zusätzliche Berechtigung vergrößert die Angriffsfläche und vermischt die Rechte unterschiedlicher Job-Welten. Spätestens wenn ein Job nur lesen darf und ein anderer auch schreiben und löschen soll, kollidieren die Anforderungen.

Die Lösung: Credential + Proxy-User

Microsoft trennt die Identitäts-Konfiguration in zwei Objekte:

• Credential — ein Objekt auf Instanz-Ebene (im SSMS-Pfad Security → Credentials), das eine Windows-Identity (Domain-Konto, lokales Konto) samt zugehörigem Secret kapselt. Das Credential lebt im Server, nicht im Agent.
• Proxy — ein Objekt auf Agent-Ebene (im SSMS-Pfad SQL Server Agent → Proxies → <Subsystem>, z. B. SSIS Package Execution), das ein Credential einem bestimmten Subsystem zuordnet und an Job-Steps freigibt.

Im Run As-Feld des Job-Steps wird statt des Service-Accounts der Proxy eingetragen. Sobald der Step startet, wechselt der Agent intern auf die im Credential hinterlegte Windows-Identität und führt den Step in deren Sicherheitskontext aus.

Schritt für Schritt: Konfiguration

Die Konfiguration besteht aus drei Schritten und ist im Folgenden in beiden Varianten gezeigt, über die SSMS-GUI und über T-SQL. Beide Wege führen zum selben Endzustand. Welche Variante besser passt, hängt davon ab, ob das Setup einmalig manuell erfolgt oder reproduzierbar im Skript stehen soll.

Schritt 1 — Credential anlegen

Im SSMS-Object-Explorer geht der Weg über Security → Credentials und dort per Rechtsklick auf New Credential…. Der Dialog verlangt einen Credential-Namen, die Identity (typischerweise ein Domain-Konto im Format DOMAIN\konto) und das zugehörige Passwort.

Programmatisch:

  1: USE [master];
  2: GO
  3: 
  4: CREATE CREDENTIAL [cred_etl_proxy]
  5: WITH
  6:     IDENTITY = N'DOMAIN\svc_etl_proxy'
  7:    ,SECRET   = N'<password>';
  8: GO

  1: USE [master];
  2: GO
  3: 
  4: CREATE CREDENTIAL [cred_etl_proxy]
  5: WITH
  6:     IDENTITY = N'DOMAIN\svc_etl_proxy'
  7:    ,SECRET   = N'<password>';
  8: GO

Das <password> ist nur ein Platzhalter — ein hartkodierter Klartext im Skript ist im Production-Setup ein klares Anti-Pattern. Im Produktivbetrieb wird das Secret stattdessen beim Deployment aus einer sicheren Quelle nachgeladen, etwa aus Azure Key Vault oder einer verschlüsselten Konfigurationsdatei. Die Datei mit dem Klartext landet damit nie im Repository. Ein Passwort braucht das Credential allerdings in jedem Fall: Konten ohne abrufbares Passwort (etwa gMSAs, siehe unten) lassen sich hier nicht hinterlegen.

Schritt 2 — Proxy-User anlegen

Der entsprechende Weg in SSMS führt über SQL Server Agent → Proxies → SSIS Package Execution und einen Rechtsklick auf New Proxy…. Im Dialog werden Proxy-Name, zugeordnetes Credential und das Subsystem (SSIS Package Execution) gesetzt. Unter „Principals“ wird zusätzlich festgelegt, welche Logins den Proxy bei der Job-Step-Konfiguration überhaupt auswählen dürfen.

Programmatisch:

  1: USE [msdb];
  2: GO
  3: 
  4: -- Proxy anlegen
  5: EXEC dbo.sp_add_proxy
  6:     @proxy_name      = N'proxy_etl_fileshare'
  7:    ,@credential_name = N'cred_etl_proxy'
  8:    ,@enabled         = 1;
  9: GO
 10: 
 11: -- Proxy auf das SSIS-Subsystem berechtigen (ID 11 — SSMS skriptet die ID)
 12: EXEC dbo.sp_grant_proxy_to_subsystem
 13:     @proxy_name   = N'proxy_etl_fileshare'
 14:    ,@subsystem_id = 11;
 15: GO
 16: 
 17: -- Login berechtigen, den Proxy bei Job-Step-Konfiguration zu verwenden
 18: EXEC dbo.sp_grant_login_to_proxy
 19:     @proxy_name = N'proxy_etl_fileshare'
 20:    ,@login_name = N'DOMAIN\bi_developer';
 21: GO

  1: USE [msdb];
  2: GO
  3: 
  4: -- Proxy anlegen
  5: EXEC dbo.sp_add_proxy
  6:     @proxy_name      = N'proxy_etl_fileshare'
  7:    ,@credential_name = N'cred_etl_proxy'
  8:    ,@enabled         = 1;
  9: GO
 10: 
 11: -- Proxy auf das SSIS-Subsystem berechtigen (ID 11 — SSMS skriptet die ID)
 12: EXEC dbo.sp_grant_proxy_to_subsystem
 13:     @proxy_name   = N'proxy_etl_fileshare'
 14:    ,@subsystem_id = 11;
 15: GO
 16: 
 17: -- Login berechtigen, den Proxy bei Job-Step-Konfiguration zu verwenden
 18: EXEC dbo.sp_grant_login_to_proxy
 19:     @proxy_name = N'proxy_etl_fileshare'
 20:    ,@login_name = N'DOMAIN\bi_developer';
 21: GO

Ein Stolperstein steckt im Subsystem-Parameter: Die Subsystem-Namen sind zwischen den Agent-Prozeduren nicht einheitlich dokumentiert. sp_add_jobstep dokumentiert für SSIS-Steps den Wert SSIS, sp_grant_proxy_to_subsystem dagegen den historischen Namen Dts. Das Skript oben folgt deshalb dem Weg, den SSMS selbst beim Skripten eines Proxys nimmt — die dokumentierte numerische @subsystem_id (11 für SSIS-Pakete). Wer sichergehen will, prüft das Wertepaar vorab auf der eigenen Instanz: SELECT subsystem_id, subsystem FROM msdb.dbo.syssubsystems;.

Ein Proxy sollte dabei immer nur auf die tatsächlich benötigten Subsysteme berechtigt werden. Eine Pauschal-Berechtigung über alle Subsysteme vergrößert die Angriffsfläche unnötig und steht im Widerspruch zum Need-to-Know-Prinzip.

Schritt 3 — Job-Step auf Proxy umstellen

Im Job-Step-Editor (erreichbar über SQL Server Agent → Jobs → <job_name> → Steps → <step_name> → Edit…) wird im Run As-Dropdown der Default-Eintrag SQL Server Agent Service Account durch den neu angelegten Proxy ersetzt.

Programmatisch:

  1: USE [msdb];
  2: GO
  3: 
  4: EXEC dbo.sp_update_jobstep
  5:     @job_name   = N'job_etl_load_daily'
  6:    ,@step_id    = 1
  7:    ,@proxy_name = N'proxy_etl_fileshare';
  8: GO

  1: USE [msdb];
  2: GO
  3: 
  4: EXEC dbo.sp_update_jobstep
  5:     @job_name   = N'job_etl_load_daily'
  6:    ,@step_id    = 1
  7:    ,@proxy_name = N'proxy_etl_fileshare';
  8: GO

Beim nächsten Job-Lauf führt der Agent diesen Step nicht mehr unter dem Service-Account aus, sondern im Sicherheitskontext der im Credential hinterlegten Windows-Identität DOMAIN\svc_etl_proxy.

Sackgasse: T-SQL-Script-Step hat kein Run As

Die Run As-Property ist allerdings nicht für jeden Step-Typ verfügbar. Welche Subsysteme die Konfiguration zulassen und welche nicht, fasst die folgende Tabelle zusammen:

Die Subsystem-Namen in der Tabelle folgen dem Vokabular von sp_add_jobstep — für den Proxy-Grant gilt die Namens-Abweichung aus Schritt 2 (dort Dts bzw. die @subsystem_id).

Transact-SQL Script-Steps laufen ganz ohne Proxy-Mechanik: Sie werden direkt in der Datenbank-Engine ausgeführt, und zwar im SQL-Sicherheitskontext des Job-Owners, nicht des Service-Accounts. Ist der Owner sysadmin, läuft der Step unbeschränkt und kann über den Parameter @database_user_name gezielt auf einen anderen Datenbank-User heruntergestuft werden. Was in diesem Subsystem fehlt, ist die Proxy-Zuweisung — und damit der Wechsel auf eine andere Windows-Identität.

EXECUTE AS ist kein Agent-Proxy

Der Einwand liegt nahe: T-SQL kennt doch EXECUTE AS LOGIN = '…' — ist das nicht derselbe Identitätswechsel? Nein, es sind zwei verschiedene Ebenen. EXECUTE AS (wie auch @database_user_name) wechselt den SQL-Sicherheitskontext innerhalb der Instanz: Berechtigungen auf Tabellen, Prozeduren, Datenbanken. Der Windows-Token des Prozesses bleibt davon unberührt. Für das Eingangs-Szenario mit der CSV-Datei auf dem File Share, auf dem der Service-Account nichts darf, hilft EXECUTE AS deshalb nicht weiter. Eine reine T-SQL-Strecke aus Stored Procedures und Skripten lässt sich auf Windows-Ebene über diesen Weg nicht impersonieren.

In der Praxis haben sich für diese Lücke zwei Workarounds etabliert:

Workaround 1: SSIS-Paket als Wrapper. Das eigentliche T-SQL bleibt in Stored Procedures, und das SSIS-Paket enthält nur einen oder wenige Execute SQL Task-Container, die diese SPs aufrufen. Der Job-Step ist damit wieder vom Typ SSIS Package Execution und unterstützt Run As. Wie weit der Wrapper trägt, hängt allerdings davon ab, welcher Prozess die externe Ressource tatsächlich liest — dazu gleich mehr. Argumentation und Diff-Pragmatik dieses Ansatzes vertieft der Folge-Artikel SSIS vs. SQL: Lesbarkeit und Wartbarkeit.

Workaround 2: CmdExec-Step mit sqlcmd.exe. Der Step ist hier vom Typ Operating System (CmdExec) (Subsystem-Name CmdExec) und unterstützt damit ebenfalls Run As. Ausgeführt wird sqlcmd.exe mit dem T-SQL-Skript als Parameter:

sqlcmd.exe -E -S server\instance -d database -i path\to\script.sql

sqlcmd.exe -E -S server\instance -d database -i path\to\script.sql

Caveats:

• -E setzt Windows-Authentifizierung gegen den SQL Server voraus, mit der Identity des Proxy-Credentials. Das funktioniert, sobald das Credential ein Windows-Konto kapselt.
• -U <login> -P <password> ist die SQL-Authentication-Variante. Das Passwort als Klartext im Step-Kommando ist ein Production-Anti-Pattern.
• Das Logging reduziert sich auf den Step-Output (stdout/stderr). Die SSIS-typischen ETL-Logging-Strecken (Execution-Log-Tabellen, SSISDB-Reports) entfallen.

Wer liest die Datei — Step-Prozess oder Engine?

Beide Workarounds haben dieselbe Feinheit, an der sie in der Praxis stehen oder fallen: Der Proxy wechselt die Windows-Identität des Step-Prozesses, nicht die der Datenbank-Engine. Liest das SSIS-Paket die CSV-Datei selbst (Flat File Source im Data Flow), greift der SSIS-Prozess unter der Proxy-Identität zu — der Wrapper trägt. Ruft der Step dagegen nur eine Stored Procedure auf, die die Datei per BULK INSERT oder OPENROWSET(BULK …) lädt, liest die SQL-Server-Engine die Datei, und die läuft unverändert unter ihrem eigenen Service-Account.

Ganz verloren ist dieser Fall nicht. Verbindet sich der Step per Windows-Authentifizierung, impersoniert die Engine beim Datei-Zugriff den Aufrufer, also die Proxy-Identität. Für UNC-Pfade auf einem dritten Rechner ist das aber der klassische Doppel-Hop, der nur mit konfigurierter Kerberos-Delegation funktioniert (die MS-Doku behandelt das unter „security account delegation“ samt Fehler 4861). Wer sich darauf nicht einlassen will, verlagert den Datei-Zugriff dahin, wo der Proxy direkt wirkt — in den Step-Prozess.

Wer den Komfort der SSIS-Logging-Welt nicht aufgeben möchte, fährt mit Workaround 1 deutlich besser. sqlcmd ist die richtige Wahl, wenn das Setup ohnehin ohne SSIS-Stack auskommen soll.

Identitätswechsel jenseits On-Prem-Agent

Das Proxy-Konzept stammt aus der Zeit von SQL Server 2005, das Credentials und Agent-Proxies eingeführt hat, und passt zum klassischen On-Prem-Stack mit Windows-Domäne. In einem 2026er-Setup trifft man dagegen auf eine deutlich veränderte Auth-Landschaft:

• Group Managed Service Accounts (gMSA). Microsoft empfiehlt seit Windows Server 2012 gMSAs als modernen Ersatz für statisch verkonfigurierte Service-Accounts: automatische Passwort-Rotation, kein Klartext-Storage, an Computer-/Service-Konten gebunden. Der Ansatzpunkt ist dabei der Agent-Service-Account selbst — läuft der SQL Server Agent als gMSA, laufen alle Steps ohne Proxy unter einer Identität ohne statisches Passwort. Als Proxy-Credential taugt eine gMSA dagegen nicht: Ein Credential verlangt ein hinterlegtes Secret, und das Passwort einer gMSA verwaltet das Active Directory und ist nicht abrufbar. Windows Server 2025 ergänzt das Bild zusätzlich um delegated Managed Service Accounts (dMSA): eine gehärtete Variante für einzelne, an eine konkrete Maschine gebundene Services, die zusätzlich gegen Pass-the-Hash- und Pass-the-Ticket-Angriffe absichert. dMSA ist kein gMSA-Ersatz, sondern ein zweites Werkzeug im selben Werkzeugkasten.
• Azure SQL Managed Instance. Hat einen SQL Server Agent mit eingeschränktem Funktions-Umfang — Proxies werden in MI nicht unterstützt. Identitäts-Brücken für SSIS-Pakete oder externe Ressourcen-Zugriffe laufen stattdessen über die Managed Identity der MI selbst oder über eine Azure-Data-Factory-Integration mit eigener Managed Identity. PowerShell- und CmdExec-Steps sind weiterhin verfügbar. Analysis Services, Merge Replication und Queue Reader fehlen.
• Azure Data Factory. Ersetzt klassische Agent-Jobs durch Triggers + Activities. Statt eines Proxy-Users mit Credential wird der Factory eine System-/User-assigned Managed Identity zugewiesen, die in Zielsystemen (Storage, SQL, Key Vault) als Identity gestattet wird. Kein statisches Secret mehr, keine separate Proxy-Konfiguration nötig. Microsoft positioniert Data Factory in Microsoft Fabric als Nachfolge-Plattform. Azure Synapse Pipelines bleiben technisch verfügbar, werden strategisch aber in Fabric überführt.
• SQL Server on Linux. Unterstützt SQL Server Agent, aber das Proxy-Konzept für Windows-Authentifizierung greift nicht 1:1 — Linux-Auth gegen File Shares läuft über das OS-Mount (CIFS, NFS), nicht über den Agent-Proxy.
• Containerized SQL Server (Docker, Kubernetes). Das Service-Account-Modell verschiebt sich auf Pod-Identity / Workload Identity. Der klassische Proxy-Stack verliert dort an Bedeutung.

Über alle Varianten zieht sich dieselbe Pointe: Wer heute ein neues System aufsetzt, greift eher zu Managed Identity oder einem gMSA-Service-Account als zu einem statischen Domain-Konto mit Passwort. Bestehende On-Prem-Setups leben dagegen weiter mit Proxy und Credential — beim nächsten Refresh der Service-Accounts lohnt sich aber die Frage, ob ein gMSA als Agent-Konto das Setup nicht spürbar vereinfachen würde.

Take-Away

• Ein Proxy trennt die Sicherheitskontexte, sobald ein Job-Step Ressourcen braucht, für die der Service-Account keine Rechte hat und auch keine bekommen soll. Dem Service-Account immer mehr Rechte zu geben, skaliert nicht und vergrößert die Angriffsfläche.
• Credential + Proxy ist das klassische On-Prem-Pattern, umgesetzt in drei Schritten: zuerst das Credential im Security-Tree, dann der Proxy im SQL Server Agent-Tree pro benötigtem Subsystem, und zuletzt der Job-Step, der auf diesen Proxy umgestellt wird.
• Transact-SQL Script-Steps bleiben die Lücke, weil sie keinen Proxy unterstützen — EXECUTE AS wechselt nur den SQL-Kontext, nicht die Windows-Identität. Wer dort Windows-Impersonation braucht, weicht entweder auf ein SSIS-Paket als Wrapper oder auf einen CmdExec-Step mit sqlcmd.exe aus. In beiden Fällen wirkt der Proxy auf den Step-Prozess — Engine-seitige Datei-Zugriffe (BULK INSERT) brauchen zusätzlich Kerberos-Delegation.
• In der 2026er-Welt übernehmen Managed Identity (in Azure) und gMSA als Service-Account (on-prem) zunehmend die Rolle des klassischen Domänen-Kontos mit Passwort. Wer neu aufsetzt, beginnt am besten gleich dort. Wer ein bestehendes System pflegt, kann den Wechsel schrittweise vorbereiten.

FAQ

Verwandte Artikel

SSIS-vs.-SQL-Cluster:

• SSIS vs. SQL — die Cluster-Wurzel mit der grundsätzlichen Tool-Diskussion.
• SSIS vs. SQL: Lesbarkeit und Wartbarkeit — der Wartbarkeits-Folgesatz zum SSIS-Wrapper-Workaround dieses Artikels.
• SSIS vs. SQL: Quellcodeverwaltung — die Diff-Pragmatik des SSIS-Wrappers (warum ein dünnes .dtsx mit ausgelagerter SQL-Substanz das Beste aus beiden Welten gibt).

ETL-Kontext:

• Design Pattern // Architektur eines ETL-Prozesses — Big-Picture für die Strecken-Architektur.
• Datenqualität in einem ETL-Prozess — Datenqualitäts-Bausteine, die in jeder ETL-Pipeline mitlaufen müssen.
• Design Pattern // Protokollierung eines ETL-Prozesses mit SQL — Logging-Pattern als Komplement zum Run-As-Setup.