Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

SQL Server 2016 Grundkurs: Architektur, Komponenten und Installation

SQL-Server-Proxykonten

Testen Sie unsere 2019 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Erfahren Sie in diesem Film, bei welchen Anwendungsfällen Sie im SQL Server Agent Proxykonten einrichten sollten und welchen Mehrwert Ihnen die Nutzung von Proxykonten bietet.
09:29

Transkript

In diesem Video geht es um die SQL Server-Agent Proxykonten, die ich Ihnen vorstellen möchte, damit Sie ein Bild dafür bekommen, für welche Szenarien beziehungsweise Anwendungsfälle das geeignet ist und was Sie für einen Mehrwert durch die Nutzung der Proxykonten in Ihrer Umgebung haben. Im SQL Server Management Studio bin ich verbunden mit der Instanz SRVSQL1. Ich gehe zum SQL Server-Agent, öffne den Knoten und habe hier den Knoten für die Proxys. Wenn ich das öffne, hier ist zwar überall jetzt ein Plüster davor zu sehen, aber wenn ich das anklicke, sieht man, dass hier keine Proxys definiert sind, das sind lediglich erstmal nur Ordnerstrukturen, also ein Strukturelement. Und die Frage, die man sich jetzt stellt, wo bin ich hier überhaupt, was kann ich machen, es hängt im Agent, was hat das für eine Bedeutung? Zum einen muss ich hier ganz klar festhalten, im Agent werden Aufträge ausgeführt, Punkt 1. So ein Auftrag besteht aus Schritten und so ein Schritt ist von einem bestimmten Typ, in dem Fall T-SQL. Jetzt würde ich hier einen neuen Step mal dazunehmen und sagen, okay, hier ist der Typ, hier steht "Ausführen als" und wenn ich jetzt zum Beispiel ein Integration Services Paket ausführen will, habe ich die Möglichkeit, aktuell hier dieses Konto des SQL Server-Agent auszuwählen. Ich schreibe mal hier oben rein, dass es sich um SSIS handelt und das Thema "Wartung". Und SSIS oder SSS Pakete ausführen heißt, die Pakete haben eine Quelle, wo die liegen. SQL Server, ja, jetzt ist man natürlich hier an der Stelle mal etwas schneller, wenn man den Namen direkt einträgt, ansonsten browst er und guckt, was er hier an Servern findet. Also ich gebe jetzt mein SQL Server an. Das ist in dem Fall der SRVSQL1, und habe im Anschluss hier unten die Paketquellen. Da ist die Instanz, hier die Pakete. Gehe auf "Durchsuchen" und habe jetzt hier einen Wartungsplan liegen. So, also ich will mithilfe der Integration Services mit diesem Konto, das Dienstkonto des Agent, diese Ausführen, sageOK. OK, bestätige das mal und habe das jetzt so definiert. Wenn ich jetzt hier draufgehe, sage Auftrag starten bei Schritt, führe das aus, dann wird das Ganze ausgeführt und ist erledigt. Wenn ich jetzt in den Verlauf gehe, Auftragsverlauf anzeigen, dann habe ich hier oben den Verlauf, machen wir mal ein bisschen größer, so DBCC CHECKDB, hier das ist eingetragen und ja, das ist doch erstmal problemlos soweit gelaufen, überhaupt kein Problem. Was auffällt ist, dass offensichtlich das nur zwei Schritte sind, diese Geschichte DBCC CHECK und Backup und der eine Schritt, den ich gerade definiert habe, der fehlt. Also gehe ich rein, gehe zu den Schritten, bearbeite die Schritte, guck mir das also an und hier das war soweit okay, das ist der erste T-SQL, der zweite T-SQL und an sich hätte der dritte hier auch noch ausgeführt werden müssen. Ist nicht der Fall. Jetzt gucke ich mir mal die einzelnen Schritte an, das heißt klar, ich habe jetzt hier meine Zeitpläne. Und wenn ich wechsele, kriege ich zum Beispiel eine Meldung, die folgenden Auftragsschritte können mit der aktuellen Auftragsschritt-Ablauflogik nicht erreicht werden, also der kommt zu dem letzten nicht mehr hin, ist dieses Verhalten beabsichtigt, nein. Hier hinten sehe ich, dass hier jeweils bei der Logik steht, "Beenden des Auftrags mit", hier auch, also gehe ich noch mal zu "Bearbeiten", "Erweitert" und hier sehe ich, zum nächsten Schrittwechsel bei Fehler "Beenden des Auftrags mit Fehlermeldung, OK. Der nächste, "Bearbeiten", "Erweitert" und hier steht beides Mal beenden, so wie bei Erfolg, als auch hier, das liegt daran, weil ich zuvor diesen Job beendet hatte und erst nachträglich diesen einen Schritt hinzugefügt habe. Also muss ich natürlich sagen, von der Logik bitte zum nächsten Schritt auch wechseln. Das kann man jetzt noch mal sagen, wie man das hier möchte, wechseln zu Schritt, wechseln zu Schritt. Oder eben einfach zum nächsten Schritt wechseln oder beenden mit Fehler. Okay, ich führe das abermals aus. Auftrag starten bei Schritt, starten. Und schaue ich mal, mit Erfolg gelaufen. Soweit erstmal so gut. In den Verlauf. Jetzt sehe ich, dass drei Schritte existieren, eins, zwei, drei. Und ja, wenn ich mir die Details angucke zu den Schritten hier unten, ich sehe immer das ausführende Konto, Paketausführung, SQL Service, SQL Service SQL Service. So weit so gut. Jetzt geht´s genau um diese Proxys und diese Proxys kann ich jetzt hier einrichten, SSIS-Paketausführung, rechte Maustaste, neuer Proxy. SSIS Proxy und jetzt muss ich hier eine sogenannte Anmeldeinformation selektieren. Also Objekttyp gibt es dort nur Anmeldeinformationen durchsuchen. Und hier habe ich jetzt einen sogenannten Integration Services User. Okay, auch nur der eine in der Liste. Das müssen wir uns mal anschauen, wo der herkommt. Zugeordnet. Zugeordnet. OK. Da stand Anmeldeinformationen. Das heißt, diese Anmeldeinformationen werden aus dem Knoten Sicherheit unter Anmeldeinformationen geholt, hier ist die, da ist die Anmeldeinformation und da habe ich eine Identität eingetragen, einen Dämonenbenutzer. Wenn ich hier draufgehe, kann ich lokale Windows-Konten oder im Active Directory meine Domäne durchsuchen. Und ich habe natürlich zuvor für die Integration Services diesen SSIS-User als Domänenbenutzer auch angelegt. Muss hier sein Kennwort bestätigen. Und damit habe ich die Anmeldeinformationen. Die Anmeldeinformation wird dann genutzt für das jeweilige Proxy-Konto, hier aktualisiere ich. Da ist es. So, jetzt kommt der entscheidende Schritt, jetzt stelle ich in dem Wartungsjob bei den Schritten, diesen Schritt um, indem ich sage, ich möchte es nicht mehr im Kontext des Agents, sondern im Kontext dieses Users ausführen, OK. Okay, jetzt schauen wir mal. Jetzt müsste hier das Ding eigentlich gegen die Wand knallen, weil vielleicht irgendwelche Berechtigungen für diesen User nicht korrekt gesetzt sind. Schauen wir uns das mal an. Ich starte das Ganze mal. Wenn es natürlich jetzt durchläuft... aha, wie zu erwarten, der Fehler, Fehler beim Auftrag, also das was vorhin noch funktionierte, schlägt jetzt fehl. Und wenn ich jetzt in den Verlauf mal reingehe, die Verlaufsinformation mir anzeige, sehe ich, dass dieser Step fehlschlägt und kann dann hier unten nützliche Hinweise finden. Auf jeden Fall sehe ich, dass das jetzt der User ist, in dessen Kontext das ausgeführt wird und das kann man sich natürlich vorstellen, dass dieser User, der ist jetzt von den Berechtigungen her nicht konfiguriert, entsprechend nicht die notwendigen Rechte hat, um diese Schritte auszuführen, aber genau das ist das, worum es geht. Das heißt, wenn wir uns diese Geschichte jetzt mit den Proxys noch mal zusammenfassend anschauen: Wir haben also im SQL Server diese Proxykonten. Die bieten die Möglichkeit, Auftragsschritte unter einem anderen Konto als das Konto des SQL Server-Agent auszuführen, also nicht das Dienstkonto des Agents, sondern separate dedizierte Konten. Eins vielleicht für CMD, eins für Integration Services, eins für Power Shell. Ich kann also das Ganze, sagte ich eben, für Power Shell, Integration Services aber auch an Analyseservices ausführen. Also Proxys können für diese Subsysteme verwendet werden, im Grunde muss man sich merken, ich mache hier etwas, was aus dem SQL Server heraus, aus dem Datenbankmodul angetriggert wird. Aber das sind hier Aktivitäten, die nach Außen gehen, die mein SQL Server verlassen und dort gehe ich über solche Stellvertreter, über diese Proxykonten. Dem Proxy im SQL Server Agent werden Anmeldeinformationen zugeordnet, ich habe also unter "Sicherheit" einen Knoten "Anmeldeinformationen", dort werde ich mir einen Windows lokalen oder Domänenbenutzer aus, der dann dem Proxy zugewiesen wird. Und Fazit aus der ganzen Geschichte, Proxys erhöhen die Sicherheit in der SQL Server Umgebung, was aus meiner Sicht ein schönes Thema ist. Seit SQL Server 2005 erwähne ich das immer in meinen Präsenzseminaren und wir reden darüber. Ich glaube ich hatte in der ganzen Zeit ein Seminarteilnehmer, der sage, wow, genau das brauche ich. Allen anderen ist es leider oft viel zu komplex, als dass sie sich hinsetzen und die Mühe machen, dort über Proxys zu gehen, weil oft ist es natürlich einfacher zu sagen, ach ja, im Konto oder im Kontext des Agent und gut ist.

SQL Server 2016 Grundkurs: Architektur, Komponenten und Installation

Lernen Sie die Architektur und Komponenten des SQL Server 2016 kennen, installieren Sie ihn und unternehmen Sie die ersten Schritte in der Administration.

4 Std. 57 min (46 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:19.04.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!