Emprunt d'identité de client

L’emprunt d’identité est utile dans un environnement de calcul distribué lorsque les serveurs doivent transmettre des demandes clientes à d’autres processus serveur ou au système d’exploitation. Dans ce cas, un serveur emprunte l’identité du contexte de sécurité du client. D’autres processus serveur peuvent ensuite gérer la requête comme si le client d’origine l’avait effectuée.

Par exemple, un client effectue une demande au serveur A. Si le serveur A doit interroger le serveur B pour terminer la demande, le serveur A emprunte l’identité du contexte de sécurité du client et effectue la demande au serveur B au nom du client. Le serveur B utilise le contexte de sécurité du client d’origine, au lieu de l’identité de sécurité du serveur A, pour déterminer s’il faut terminer la tâche.

Le serveur appelle RpcImpersonateClient pour remplacer la sécurité du thread serveur par le contexte de sécurité du client. Une fois la tâche terminée, le serveur appelle RpcRevertToSelf ou RpcRevertToSelfEx pour restaurer le contexte de sécurité défini pour le thread serveur.

Lors de la liaison, le client peut spécifier des informations de qualité de service sur la sécurité, qui spécifient la façon dont le serveur peut emprunter l’identité du client. Par exemple, l’un des paramètres permet au client de spécifier que le serveur n’est pas autorisé à emprunter l’identité. Pour plus d’informations, consultez Qualité de service.

La possibilité d’appeler d’autres serveurs tout en empruntant l’identité du client d’origine est appelée délégation. Lorsque la délégation est utilisée, un serveur empruntant l’identité d’un client peut appeler un autre serveur et effectuer des appels réseau avec les informations d’identification du client. Autrement dit, du point de vue du deuxième serveur, les requêtes provenant du premier serveur ne peuvent pas être déduites des requêtes provenant du client. Tous les fournisseurs de sécurité ne prennent pas en charge la délégation. Microsoft n’envoie qu’un seul fournisseur de sécurité qui prend en charge la délégation : Kerberos.

La délégation peut être une fonctionnalité dangereuse en raison des privilèges accordés par le client au serveur lors d’un appel de procédure distante. C’est pourquoi Kerberos autorise les appels avec le niveau d’emprunt d’identité de délégation uniquement si l’authentification mutuelle est demandée. Les administrateurs de domaine peuvent limiter les ordinateurs auxquels sont effectués les appels avec un niveau d’emprunt d’identité de délégation pour empêcher les clients qui ne se méfient pas d’effectuer des appels à des serveurs susceptibles d’abuser de leurs informations d’identification.

Une exception à la règle de délégation existe : les appels à l’aide de ncalrpc. Lorsque ces appels sont effectués, le serveur obtient des droits de délégation, même si un niveau d’emprunt d’identité est spécifié. Autrement dit, un serveur peut appeler d’autres serveurs au nom du client. Cela fonctionne pour un seul appel distant. Par exemple, si le client A appelle le serveur local LB à l’aide du serveur local ncalrpc , LB peut emprunter l’identité et appeler le serveur distant RB. RB pourra agir pour le compte du client A, mais uniquement sur l’ordinateur distant sur lequel RB s’exécute. Il ne peut pas effectuer un autre appel réseau à l’ordinateur distant C, sauf si LB a spécifié un niveau d’emprunt d’identité de délégué lorsqu’il a appelé RB.