none
SSIS Katalog Paketvalidierung schlägt fehl mit anonymous login - Schwarmwissen gefragt RRS feed

  • Frage

  • Hallo zusammen,

    hier kurz mein Szenario: Auf einem Server A gibt es einen SSIS Katalog und ein entsprechendes Paket. Dieses Paket soll in eine DB auf Server A schreiben und Daten von einem Server B abholen.

    Das klappt auch alles wunderbar, brav mit Proxykonto usw usw.

    Jetzt das große aber:  Wenn ich von meinem lokalen SSMS auf Server A gehe und das Paket validiere, dann schlägt dies mit der Fehlermeldung fehl OLE DB error has occured 0x80040E4D .....login failed for user NT Auth\anonymous logon.

    Server A und Server B haben SPNs sauber gesetzt. Das ausführende SQLSvc Konto von Server A hat eine Contrained delegation zu Server B und laut MS Kerberos Configuration Manager gibt es auch keine offensichtlichen Delegationsprobleme.

    Darüber hinaus hab ich mal schnell einen Linked server von A nach B eingerichtet mit Windows Auth  und da klappt der Zugriff Client PC-Server A -> Server B auch.

    Nur die Paketvalidierung will nicht.  Ich sehe das für mich jetzt als minor issue an, da das Paket (als Agent Job ausgeführt) ja läuft. Aber irgendwie dennoch ärgerlich.

    Daher die Frage in die Runde: an welcher Stelle könnte es da noch klemmen? Im Moment finde ich die Ursache nicht und wie bereits beschrieben, SPNs sind sauber da und die Delegierung klappt ja (linked server test).

    Gruß

    Dirk


    May you never suffer the sentiment of spending a day without any purpose

    Dienstag, 13. März 2018 10:08

Antworten

  • So,

    um jetzt die Finale "Lösung" an der Stelle zu präsentieren:

    Es macht einen Unterschied, ob man bei dem ausführenden Service Konto, das man initial anspricht (Server A) eine "constrained delegation" eingerichtet hat, also gezielt auf bestimmte Dienste hin delegiert oder ob man die Option "Benutzer bei der Delegierung aller Dienste (nur Kerberos) vertrauen" eingestellt hat.

    Ich war zu Beginn sehr restriktiv und hab die constrained delegation ausgewählt. Damit klappt mein Szenario tatsächlich nicht. Stattdessen hab ich das betroffene Dienstekonto umgestellt auf Delegierung aller Dienste (nur Kerberos). Dann eine Weile abwarten, bis sich das im AD sauber herum spricht und auf einmal ist das Problem gelöst bzw. klappt nun alles wie erwartet. Dennoch hätte ich eine gezielte Delegierung irgendwie "schicker" gefunden.

    Gruß Dirk


    May you never suffer the sentiment of spending a day without any purpose

    • Als Antwort markiert Dirk Hondong Montag, 19. März 2018 13:08
    Montag, 19. März 2018 13:08

Alle Antworten

  • Nachtrag zu dem Thema:

    Ich verbinde mich mit meinem lokalen SSMS gegen eine SQL Server 2016. Die Verbindung aus dem SSIS Paket heraus geht auf einen SQL Srv 2014er.  Aber das sollte nichts zur Sache tun.

    Ich vermute, dass es irgendwas mit dem Validierungsprozess per se zu tun hat und hier Credentials nicht sauber delegiert werden können. Wenn ich die Validierung direkt auf dem Server anstoße, dann läuft die problemlos durch.

    Gruß

    Dirk


    May you never suffer the sentiment of spending a day without any purpose

    Freitag, 16. März 2018 08:44
  • Hallo Dirk,

    das hört sich ja alles ziemlich mysteriös an. Hast Du schon mal wieder versucht mit dem Process-Monitor der Sache auf die Spur zu kommen?

    Welche Version vom SSMS setzt Du ein?


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Freitag, 16. März 2018 09:00
    Beantworter
  • Moin Christoph,

    den Process Monitor hab ich an der Stelle noch gar nicht eingesetzt. Lokal verwende ich das SSMS 17.5

    Ich bin ja davon ausgegangen, dass so was problemlos klappt. Kommt ja eigentlich ständig vor, dass man von einem Server A eine Verbindung zu Server B via SSIS aufbaut um Daten abzugreifen. Und es geht ja auch alles. Also wenn es als Job definiert ist. Wenn ich direkt aus dem SSMS heraus das Paket anstoßen möchte, dann schlägt es ja ebenso fehl.

    Werde mal gucken, dass ich kommende Woche etwas Zeit finde. Dann schnappe ich mir mal den Process Monitor.

    Gruß Dirk


    May you never suffer the sentiment of spending a day without any purpose

    Freitag, 16. März 2018 09:23
  • Bau doch mal dieses Statement in das Paket ein und protokolliere das Ergebnis irgendwo:

    select session_id, net_transport, auth_scheme, client_net_address from sys.dm_exec_connections where session_id=@@spid;


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Freitag, 16. März 2018 11:15
    Beantworter
  • Hi Christoph,

    ich hab gerade mal Deine schnelle logging Variante ausprobiert.  Es wird Kerberos verwendet, wenn das Paket läuft. Und ich bin auch per Kerberos am Server A angemeldet....

    Verbinde ich mich direkt gegen Server B, so hab ich auch da eine Kerberos Session.  Und hab gerade auch noch mal die linked Server Verbindung (SERVER A -> Server B) geprüft, die funktioniert auch.

    Dazu hab ich mir gerade eine Proc auf Server B mit Deinem Statement angelegt und via linked Server Verbindung ausgeführt.  Kerberos auth.

    Also das klappt, würde ich mal sagen.

    Gruß Dirk


    May you never suffer the sentiment of spending a day without any purpose

    Montag, 19. März 2018 09:21
  • Hallo,

    ich glaub, ich komm der Sache gerade etwas näher. Hab mal einen Kollegen gebeten ebenfalls die Paketvalidierung zu machen und es geht. Dann an seinem Rechner im Runas Kontext meiner Kennung ein SSMS geöffnet und es geht.

    Ergo hat es nichts mehr mit der eigentlichen Konfig oder der SSISDB zu tun. Mal schauen was die Netzwerker zu dem Thema beitragen können, da beide Clientrechner in unterschiedlichen Subnetzen sind.

    Gruß Dirk


    May you never suffer the sentiment of spending a day without any purpose

    • Als Antwort markiert Dirk Hondong Montag, 19. März 2018 12:25
    • Tag als Antwort aufgehoben Dirk Hondong Montag, 19. März 2018 13:08
    Montag, 19. März 2018 10:21
  • Super!

    Musste aber erst überlegen was "Runas Kontext" ist! ;-)


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Montag, 19. März 2018 10:56
    Beantworter
  • Super!

    Musste aber erst überlegen was "Runas Kontext" ist! ;-)


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Sorry,

    mein Fehler.  Hatte etwas zu schnell und in Denglisch getippt. :-)

    Gruß Dirk


    May you never suffer the sentiment of spending a day without any purpose

    Montag, 19. März 2018 12:25
  • So,

    um jetzt die Finale "Lösung" an der Stelle zu präsentieren:

    Es macht einen Unterschied, ob man bei dem ausführenden Service Konto, das man initial anspricht (Server A) eine "constrained delegation" eingerichtet hat, also gezielt auf bestimmte Dienste hin delegiert oder ob man die Option "Benutzer bei der Delegierung aller Dienste (nur Kerberos) vertrauen" eingestellt hat.

    Ich war zu Beginn sehr restriktiv und hab die constrained delegation ausgewählt. Damit klappt mein Szenario tatsächlich nicht. Stattdessen hab ich das betroffene Dienstekonto umgestellt auf Delegierung aller Dienste (nur Kerberos). Dann eine Weile abwarten, bis sich das im AD sauber herum spricht und auf einmal ist das Problem gelöst bzw. klappt nun alles wie erwartet. Dennoch hätte ich eine gezielte Delegierung irgendwie "schicker" gefunden.

    Gruß Dirk


    May you never suffer the sentiment of spending a day without any purpose

    • Als Antwort markiert Dirk Hondong Montag, 19. März 2018 13:08
    Montag, 19. März 2018 13:08