SQL Job schlägt fehl. Job wirft Fehler '...untrusted domain...'

[SabineW]

Hallo Zusammen,
auf einem Microsoft SQL Server 2016 laufen (unter anderem auch) 2 Job, die jeweils eine Windows-Batchdatei auf dem Server aufrufen. Mit Hilfe dieser Batch-Datei werden verschiedene Parameter konfiguriert und damit ein sqlcmd-Skript gestartet.
Beide Jobs laufen unter dem 'SQL Server Agent Service Account'. Einer dieser beiden Job läuft ohne Problem. In der Protokolldatei kann ich sehen, dass er auch tatsächlich mit dem Account ausgeführt wird.
Und der 2. Job bricht mit der Fehlermeldung 'Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication.' ab. Das Verwirrende daran ist, dass beide Skripte auf dem gleichen Server (nämlich dem Server selbst) aufgerufen werden. Wie kann es sein, dass die eigene Maschine als untrusted Domain erkannt wird?
Auch ein kleines Test-Batch, welches ich eingerichtet habe, bekomme ich nicht zum Laufen bekomme. Die gleiche Fehlermeldung.
Im Log kann ich sehen, das der User der gleiche wie im funktionierenden Skript ist.
Dann habe ich was von einem Schalter -E gelesen:
(
-E
Verwendet eine vertrauenswürdige Verbindung anstelle eines Benutzernamens und eines Kennworts für die Anmeldung bei SQL Server. Standardmäßig wird von sqlcmd die vertrauenswürdige Verbindung verwendet, wenn -E nicht angegeben ist.
)
Hat aber leider nicht funktioniert.

Was kann da an dem funktionierenden Job anders sein?

An welche Stellen kann ich noch nach dem Fehler suchen?

Auch für den kleinsten Hinweis oder unwahrscheinlichsten Tipp bin ich dankbar.

Liebe Grüße
Sabine

 

[Tommi]

Hallo Sabine,

ist natürlich die Frage, welche Parameter genau dem SQLCMD mitgegeben werden.
Vielleicht kannst du die Aufruf-Zeile mal posten, dann sieht man vielleicht mehr.

Aber hier natürlich noch einmal der MS-Link zu SQLCMD von Microsoft (Kennst du sicher schon, aber sicher ist sicher).
SQLCMD-Hilfsprogramm - SQL Server | Microsoft Docs

Vielleicht versuchst du in deinem Test-Batch mal einen Aufruf mit explizit angegebenen User (-U) und Passwort (-P ) und schaust mal, was dann passiert.
Ist denn sicher gestellt, dass in der Batch-Datei auch der SQL-Server angesprochen wird, der auf dem lokalen Rechner läuft, auf dem die Batch-Datei ausgeführt wird?
Wenn der SQL-Server, den du ansprechen willst, nicht die Standard-Instanz oder ein anderer SQL-Server ist, kann das auch eine Ursache sein, wenn das nicht richtig angegeben ist (siehe Parameter -S)

Viele Grüße,
Tommi

 

[SabineW]

Guten Morgen Tommi,
vielen Dank für die Hinweise und Tipps.

Hier ist der Aufruf in meiner Testdatei:
whoami > e:\SabineExecSQL\log.txt
sqlcmd -d "<Datenbank>" -S "<Server>" -i "e:\SabineExecSQL\Statement.sql" -o "e:\SabineExecSQL\result.txt"

Inhalt der Datei Statement.sql:
select @@servername

Gebe ich einen User und Passwort an, dann funktioniert es, von daher passen die Einträge <Datenbank> und <Server>.

Gibt es denn irgendwo die Möglichkeit, sqlcmd etwas gesprächiger zu machen? Verbose, Debug, Trace oder so was? In der Beschreibung habe ich nichts gefunden.

Danke und liebe Grüße
Sabine

 

[Tommi]

Hallo Sabine,

erst einmal die Antwort auf deine Frage: das ist Microsoft! Hier sind die Fehlermeldungen an sich nur selten so geschrieben, dass man sofort versteht, was man beachten muss und wo der Fehler zu suchen ist.
Daher kann ich die Frage, ob SQLMD "gesprächiger" gemacht werden kann nur verneinen.

Aber nach dem Test mit dem expliziten angeben von User und Passwort, der ja funktioniert hat, vermute ich, dass die neue Batch-Datei für den Dienst-Account des SQL Server Agent nicht ausführbar berechtigt ist.
Die funktionierende Batch-Datei ist hier bestimmt speziell berechtigt.

Das kann man zwar so machen, aber dann ...


Es gibt 2 Möglichkeiten, beide sind von Microsoft so mal vorgeschlagen:

1. Den Dienst des SQL Server Accounts mit einem technischen AD-Account starten. Diesen technischen Account kann man dann entsprechend an verschiedenen Stellen berechtigen.
2. einen Proxy im SQL Server Agent einrichten (mein genereller Vorschlag, da dann mit dem Dienst kein Unfug getrieben werden kann, je nachdem, welche Berechtigung dieser bekommt)

Für den 1. Punkt muss einfach auf dem Server für den Dienst des SQL Server Agent das Anmelde-Konto geändert werden. Hier kann man einen beliebigen AD-Account angeben. Der Dienst hat dann die Berechtigungen des AD-Kontos (nicht vergessen den lokalen Server zu berechtigen!).

Mein Favorit ist aber Punkt 2.
Dafür muss man im SQL Server eine Berechtigung auf der Instanz anlegen, auf der auch der SQL Server Agent läuft.

Englisch: Security - Credentials
Deutsch: Sicherheit - Anmeldeinformationen​

Hier kann man einen AD-Account angeben und das Passwort verschlüsselt mitgeben (Du kannst das ja zum Test mit deinem Account ausprobieren, aber eigentlich gehört dort ebenfalls ein technischer Account eingetragen)




Im nächsten Schritt muss im SQL Server Agent ein Proxy angelegt werden. Dieser kann für verschiedene Ausführungen im SQL Server Agent berechtigt werden. Für die Ausführung einer Batch-Datei ist das natürlich das CmdExec.
Im Proxy kannst als Credential bzw. Anmeldeinformationsnamen die vorher angelegten Credentials aus Schritt 1 angeben.




Im Job kann man dann neben der Ausführung des SQL Server Agent Dienst dann auch diesen Proxy auswählen, wenn eine Ausführungsart im Schritt ausgewählt wird, für die dieser Proxy berechtigt wurde.




Ich denke, so wirst du es stabil zum laufen bekommen.

Viele Grüße,
Tommi

 

[SabineW]

Hi Tommi,
vielen Dank für die ausführliche Beschreibung.
Punkt 1 habe wir schon umgesetzt. Die Dienste laufen alle unter technischen Usern.
Punkt 2 kläre ich mal mit unserem Datenbank-Admin, der hat das Password für den technischen User.
Ich melde mich wieder.

Danke soweit schon mal.

Liebe Grüße
Sabine

 

[SabineW]

Hi Tommi, hallo Zusammen,
hat eine Weile gedauert, aber jetzt konnte ich testen. Das Ergebnis ist leider das Gleiche geblieben. Nach wie vor kommt die Meldung 'Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server : Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication..'
In der Datei log.txt kann ich auch sehen, dass der richtige User verwendet wird.
Wenn ich jetzt so drüber nachdenke, war das Ausführen von CmdExec auch nie ein Problem. Es wurde ja immer was in die log.txt geschrieben.
Das Problem ist das Ausführen der sqlcmd. An der scheitert's.

 

[Chuky666]

Aloha

ich denke mal das wird in einem wirren raten ausarten...

Ich hau einfach mal ein paar Gedanken raus, kenne leider nicht deine bat Dateien und weißt nicht was die wo wie mit wem wann machen sollen.
also... Hast du mal versucht die bat als erstes ausführen zu lassen wo gemeckert wird?
Hast du mal versucht das Script der zweiten bat innerhalb der ersten auszuführen? Sprich beide zusammenführen.

 

[SabineW]

Hi Chuky666,
weiter oben hatte ich das ja schon beschrieben. Muss aber eben selbst feststellen, dass es nicht ganz gerade aus zu verstehen ist. Hier noch mal etwas detaillierter:

Kommando im Job:

call E:\SabineExecSQL\Call.cmd
​

Inhalt der Datei Call.cmd:

whoami > e:\SabineExecSQL\log.txt
sqlcmd -d "<Datenbank>" -S "<Server>" -i "e:\SabineExecSQL\Statement.sql" -o "e:\SabineExecSQL\result.txt"​

(Wobei <Datenbank> und <Server> mit echten Werten gefüllt sind.)

Inhalt der Datei Statement.sql:

select @@servername
​

Ablauf ist also der folgenden:

• Im Job wird die Batch 'Call.cmd' gestartet
• 1. Schritt in der Batch: 'whoami' -> Hier will ich wissen, wer tatäschlich den Job ausführt und die Batch startet.
• 2. Schritt in der Batch_ 'sqlcmd' -> Da soll jetzt was auf der Datenbank ausgeführt werden; und das steht in der Datei Statement.sql
• 1. Zeile Statement.sql: select @@Servername -> Will wissen, ob ich auf dem richtigen Server drauf bin.

​

 

[Chuky666]

Nabend Sabine

hast du denn mal alle Step´s, angefangen vom SQL-Statement, einzeln ausgeführt und zwar als der User mit dem du bisher Probleme hast? Mir scheint es das der besagte User ein Recht fehlt... jetzt ist nur die Frage an welcher stelle

 

[dabadepdu]

Meine MSSQL Zeit ist schon was her, also keine Garantie auf Hilfe:
Dein Beitrag #8 sieht so aus, als ob Du nicht explizit einen User angibst. Das ist wahrscheinlich gewollt. Du möchtest mit den Rechten des angemeldeten Users arbeiten. Diese ganze Mechanik funktioniert minimal nur, wenn
a) der PC in die Domäne eingebunden ist
und
b) der angemeldete User ebenfalls ein Domänen User ist

a) dürfte irgendwie klar sein, b) ist nicht selbstverständlich und man kann sich ohne weiteres mit einem lokalen User an einem Domänenrechner anmelden. Der hat dann halt in der Domäne nichts zu "sagen".

Einfachste Abhilfe ist m.E. dieses Rechteproblem "an sich zu reißen" und eine explizite Anmeldung mit einem Datenbank User zu machen. Es wäre mindestens ein erster Schritt. Vielleicht lässt sich aber auch ganz einfach klären, dass a) oder b) in Deinem Fall für den "technischen User" nicht gegeben sind.

Tommy hat das schon aus SQL Server Sicht beschrieben. Deine genauere Beschreibung lässt m.E. nicht erkennen, dass Du was an Deinen Anmelde Verfahren / Nutzern geändert hast. Die komplette Storry beginnt bei Domänenrechten mit der Anmeldung an Windows.
Apropos: Was kommt denn bei deinen Whoami und @@Servername raus? Wie lautet der Rechnername? (nicht der Servername)
Falls Du keine echten Daten veröffentlichen willst, geht es auch symbolisch.
SuperDomäne
SuperRechensklave
SuperUser
SuperSQLUser
usw.
Trotzdem sollte es exakt wiedergegeben werden. Und einfach nur als Hinweise, es gibt eine große Menge Möglichkeiten, sich richtig oder falsch anzumelden, Link zum Scrollen:
Microsoft ODBC Driver 13 for SQL Server Connection Strings - ConnectionStrings.com

 

[SabineW]

Hallo Zusammen,
da mir das Thema absolut keine Ruhe gelassen hat, habe ich parallel noch ein bisschen rumgesucht und bin auf einen Hinweis gestoßen.
Ruft mal sqlcmd direkt auf dem Server auf, dann benötigt man keine Server-Adresse. Stattdessen soll man nur im Parameter -S einen Punkt eingeben. Also so "-S ."
Leider weiß ich nicht mehr auf welcher Seite das war, aber es hat funktioniert. Zwar ist mir immer noch unklar, warum der andere Job fehlerfrei läuft, ist mir jetzt aber auch egal.
So geht's und gut ist.
Danke Euch allen für die Unterstützung.

lg
Sabine