Niveles de suplantación (autorización)

La enumeración SECURITY_IMPERSONATION_LEVEL define cuatro niveles de suplantación que determinan las operaciones que un servidor puede realizar en el contexto del cliente.

Nivel de suplantación	Descripción
SecurityAnonymous	El servidor no puede suplantar ni identificar al cliente.
SecurityIdentification	El servidor puede obtener la identidad y los privilegios del cliente, pero no puede suplantar al cliente.
SecurityImpersonation	El servidor puede suplantar el contexto de seguridad del cliente en el sistema local.
SecurityDelegation	El servidor puede suplantar el contexto de seguridad del cliente en sistemas remotos.

 

El cliente de una canalización con nombre, RPC o conexión DDE puede controlar el nivel de suplantación. Por ejemplo, un cliente de canalización con nombre puede llamar a la función CreateFile para abrir un identificador en una canalización con nombre y especificar el nivel de suplantación del servidor.

Cuando la conexión de canalización con nombre, RPC o DDE es remota, se omiten las marcas pasadas a CreateFile para establecer el nivel de suplantación. En este caso, el nivel de suplantación del cliente viene determinado por los niveles de suplantación habilitados por el servidor, que se establece mediante una marca en la cuenta del servidor en el servicio de directorio. Por ejemplo, si el servidor está habilitado para la delegación, el nivel de suplantación del cliente también se establecerá en delegación aunque las marcas pasadas a CreateFile especifiquen el nivel de suplantación de identificación.

Los clientes DDE usan la función DdeSetQualityOfService con la estructura SECURITY_QUALITY_OF_SERVICE para especificar el nivel de suplantación. El nivel SecurityImpersonation es el valor predeterminado para los servidores de canalización, RPC y DDE con nombre. Las funciones ImpersonateSelf, DuplicateToken y DuplicateTokenEx permiten al autor de la llamada especificar un nivel de suplantación. Use la función GetTokenInformation para recuperar el nivel de suplantación de un token de acceso.

En el nivel SecurityImpersonation, la mayoría de las acciones del subproceso se producen en el contexto de seguridad del token de suplantación del subproceso en lugar de en el token principal del proceso que posee el subproceso. Por ejemplo, si un subproceso de suplantación abre un objeto protegible, el sistema usa el token de suplantación para comprobar el acceso del subproceso. Del mismo modo, si un subproceso de suplantación crea un nuevo objeto, por ejemplo llamando a la función CreateFile , el propietario del nuevo objeto es el propietario predeterminado del token de acceso del cliente.

Sin embargo, el sistema usa el token principal del proceso en lugar del token de suplantación del subproceso de llamada en las situaciones siguientes:

• Si un subproceso suplantador llama a la función CreateProcess , el nuevo proceso siempre hereda el token principal del proceso.
• En el caso de las funciones que requieren el privilegio SE_TCB_NAME, como la función LogonUser , el sistema siempre comprueba si hay privilegios en el token principal del proceso.
• En el caso de las funciones que requieren el privilegio SE_AUDIT_NAME, como la función ObjectOpenAuditAlarm , el sistema siempre comprueba el privilegio en el token principal del proceso.
• En una llamada a la función OpenThreadToken , un subproceso puede especificar si la función usa el token de suplantación o el token principal para determinar si se debe conceder el acceso solicitado.