Emprunt d'identité et informations d'identification pour les connexions
S’applique à : 
SQL Server
Dans l’intégration du CLR (Common Language Runtime) SQL Server, l’utilisation de l’authentification Windows est complexe, mais elle est plus sécurisée que l’utilisation de l’authentification SQL Server. Lorsque vous utilisez l'authentification Windows, gardez à l'esprit les points suivants.
Par défaut, un processus SQL Server qui se connecte à Windows acquiert le contexte de sécurité du compte de service Windows SQL Server. Mais il est possible de mapper une fonction CLR à une identité de proxy afin que ses connexions sortantes aient un contexte de sécurité différent de celui du compte de service Windows.
Dans certains cas, vous souhaiterez peut-être emprunter l’identité de l’appelant à l’aide de la propriété SqlContext.WindowsIdentity au lieu de l’exécuter en tant que compte de service. L’instance WindowsIdentity représente l’identité du client qui a appelé le code appelant et n’est disponible que lorsque le client a utilisé l’authentification Windows. Une fois que vous avez obtenu l’instance WindowsIdentity , vous pouvez appeler l’emprunt d’identité pour modifier le jeton de sécurité du thread, puis ouvrir ADO.NET connexions pour le compte du client.
Après avoir appelé SQLContext.WindowsIdentity.Impersonate, vous ne pouvez pas accéder aux données locales et vous ne pouvez pas accéder aux données système. Pour accéder à nouveau aux données, vous devez appeler WindowsImpersonationContext.Undo.
L’exemple suivant montre comment emprunter l’identité de l’appelant à l’aide de la propriété SqlContext.WindowsIdentity .
Visual C#
WindowsIdentity clientId = null;
WindowsImpersonationContext impersonatedUser = null;
clientId = SqlContext.WindowsIdentity;
// This outer try block is used to protect from
// exception filter attacks which would prevent
// the inner finally block from executing and
// resetting the impersonation.
try
{
try
{
impersonatedUser = clientId.Impersonate();
if (impersonatedUser != null)
return GetFileDetails(directoryPath);
else return null;
}
finally
{
if (impersonatedUser != null)
impersonatedUser.Undo();
}
}
catch
{
throw;
}
Remarque
Pour plus d’informations sur les modifications de comportement dans l’emprunt d’identité, consultez Changements cassants des fonctionnalités Moteur de base de données dans SQL Server 2016.
En outre, si vous avez obtenu l’instance d’identité Microsoft Windows, par défaut, vous ne pouvez pas propager cette instance à un autre ordinateur ; L’infrastructure de sécurité Windows restreint cela par défaut. Il existe cependant un mécanisme, appelé « délégation », qui permet la propagation d'identités Windows sur plusieurs ordinateurs approuvés. Vous pouvez en savoir plus sur la délégation dans l’article TechNet , « Transition de protocole Kerberos et délégation contrainte ».