Ich bin gekommen, um dieses Problem zu umgehen. Ich weiß nicht, warum es funktionieren sollte, aber nichtsdestotrotz. :)Es geht definitiv um Sicherheit.
Ich habe untersucht, dass der SQL-Agent im Namen des Domänenbenutzers ausgeführt wird, sagen wir DOMÄNE\Benutzer .Es verfügt über alle Administratorrechte auf dem Server ('sysadmin'-Serverrolle usw.). SQL Server selbst wird unter demselben Benutzer ausgeführt.
Der Schritt des Jobs, der den Aufruf von sp_send_dbmail enthält läuft unter derselben DOMÄNE\Benutzer .
Ich habe das auch nachvollzogen, als ich den Abfrageteil von sp_send_dbmail ausgeführt habe es versucht exec xp_logininfo 'DOMAIN\User' auszuführen um mit Active Directory zu prüfen, ob dieser Benutzer in Ordnung ist. Und Überraschung:Irgendetwas ist definitiv nicht in Ordnung. Diese Prüfung endet mit:
Msg 15404, Level 16, State 19, Server SQLC002INS02\SQLC002INS02, Line 1
Could not obtain information about Windows NT group/user 'DOMAIN\User.', error code 0x2.
Das kann mit einiger Wahrscheinlichkeit alles bedeuten, dass das Passwort dieses Benutzers abgelaufen ist oder der Benutzer gesperrt ist oder andere unangenehme Dinge für diesen Typ.
Ich entschied, dass es zu riskant ist, den Benutzer für den Agenten zu ändern. Also komme ich dazu, E-Mails im Namen von „sa“ zu senden, die die gleiche „sysadmin“-Serverrolle, aber SQL-Autorisierung hat und diesen AD-Prüfschritt auslässt.
Es sieht so aus, als ob ein Benutzer, der sich als Administrator ausgibt, den echten Administrator bittet, gefährlichen Code für ihn auszuführen :)
Der endgültige Code dieses Jobs ist also der erste und einzige Schritt, der wie folgt aussieht:
execute as login = 'sa'
exec msdb.dbo.sp_send_dbmail
@profile_name = 'profile_name',
@recipients = '[email protected]',
@body = 'body',
@subject = 'subj',
--Parameters that refers to attached file
@attach_query_result_as_file = 1,
@query_result_header = 0,
@query_result_no_padding = 1,
@query = 'select 1',
@query_attachment_filename = 'test.csv'
revert
