Je suis venu à la solution de contournement de ce problème. Je ne sais pas pourquoi cela fonctionnerait, mais jamais moins. :) C'est définitivement une question de sécurité.
J'ai enquêté sur le fait que l'agent SQL s'exécute au nom de l'utilisateur du domaine, par exemple DOMAIN\User .Il dispose d'un ensemble complet de droits d'administrateur sur le serveur (rôle de serveur 'sysadmin', etc.). SQL Server lui-même s'exécute sous ce même utilisateur.
L'étape du travail qui contient l'appel à sp_send_dbmail s'exécute sous le même DOMAIN\User .
J'ai également tracé cela lors de l'exécution de la partie requête de sp_send_dbmail il essaie d'exécuterexec xp_logininfo 'DOMAIN\User' pour vérifier par rapport à Active Directory si cet utilisateur est OK. Et surprise :quelque chose ne va définitivement pas. Cette vérification se termine par :
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.
Cela, avec une certaine probabilité, peut signifier que le mot de passe de cet utilisateur est expiré ou que l'utilisateur est verrouillé ou toute autre chose non agréable pour ce type.
J'ai décidé qu'il était trop risqué de changer d'utilisateur pour l'agent. J'en viens donc à envoyer du courrier au nom de 'sa' qui a le même rôle de serveur 'sysadmin' mais l'autorisation SQL et omet cette étape de vérification AD.
Il semble qu'un utilisateur se faisant passer pour un administrateur demande au véritable administrateur d'exécuter un code dangereux pour lui :)
Donc, le code final de ce travail est la première et la seule étape ressemble à ceci :
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
