Ik ben tot een oplossing voor dat probleem gekomen. Weet niet waarom het zou werken, maar toch. :)Het gaat absoluut om veiligheid.
Ik heb onderzocht dat SQL Agent wordt uitgevoerd namens de domeingebruiker, zeg DOMAIN\User .Het heeft een volledige set beheerdersrechten op de server (serverrol 'sysadmin', enz.). SQL Server zelf draait onder diezelfde gebruiker.
De stap van de taak die oproep naar sp_send_dbmail . bevat draait onder dezelfde DOMAIN\User .
Ik heb dat ook gevonden bij het uitvoeren van het querygedeelte van sp_send_dbmail het probeert exec xp_logininfo 'DOMAIN\User' . uit te voeren om te controleren aan de hand van Active Directory of die gebruiker in orde is. En verrassing:er is zeker iets niet in orde. Deze controle eindigt met:
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.
Dat kan met enige waarschijnlijkheid betekenen dat het wachtwoord van die gebruiker is verlopen of dat de gebruiker is vergrendeld of andere onaangename dingen voor die persoon.
Ik besloot dat het te riskant is om van gebruiker voor Agent te veranderen. Dus ik kom op het verzenden van e-mail namens 'sa' die dezelfde 'sysadmin'-serverrol heeft maar SQL-autorisatie en deze AD-controlestap weglaat.
Het lijkt erop dat een gebruiker die zich voordoet als beheerder, de echte beheerder vraagt om gevaarlijke code voor hem uit te voeren :)
Dus de laatste code van deze taak is de eerste en de enige stap die hier op lijkt:
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