NETWORK SERVICE et LocalSystem s'authentifieront toujours en tant que compte correspondant localement (builtin\network service et builtin\system) mais les deux s'authentifieront en tant que compte de machine à distance.
Si vous voyez un échec comme Login failed for user 'DOMAIN\MACHINENAME$' cela signifie qu'un processus s'exécutant en tant que SERVICE RÉSEAU ou en tant que LocalSystem a accédé à une ressource distante, s'est authentifié en tant que compte machine et s'est vu refuser l'autorisation.
Un exemple typique serait une application ASP s'exécutant dans un pool d'applications défini pour utiliser les informations d'identification NETWORK SERVICE et se connectant à un serveur SQL distant :le pool d'applications s'authentifiera en tant que machine exécutant le pool d'applications, et ce compte de machine doit-il être autorisé à y accéder ?
Lorsque l'accès est refusé à un compte d'ordinateur, l'accès doit être accordé au compte d'ordinateur. Si le serveur refuse de se connecter à 'DOMAIN\MACHINE$', vous devez accorder des droits de connexion à 'DOMAIN\MACHINE$' et non à NETWORK SERVICE. Accorder l'accès au SERVICE RÉSEAU permettrait à un local processus s'exécutant en tant que SERVICE RÉSEAU pour se connecter, pas à distance, car le distant s'authentifiera en tant que, vous l'aurez deviné, DOMAIN\MACHINE$.
Si vous vous attendez à ce que l'application asp se connecte au serveur SQL distant en tant que connexion SQL et que vous obtenez des exceptions concernant DOMAIN\MACHINE$, cela signifie que vous utilisez la sécurité intégrée dans la chaîne de connexion. Si cela est inattendu, cela signifie que vous avez foiré les chaînes de connexion que vous utilisez.
