Níveis de representação (autorização)

A enumeração SECURITY_IMPERSONATION_LEVEL define quatro níveis de representação que determinam as operações que um servidor pode executar no contexto do cliente.

Nível de representação	Descrição
SecurityAnonymous	O servidor não pode representar ou identificar o cliente.
SecurityIdentification	O servidor pode obter a identidade e os privilégios do cliente, mas não pode representar o cliente.
SecurityImpersonation	O servidor pode representar o contexto de segurança do cliente no sistema local.
SecurityDelegation	O servidor pode representar o contexto de segurança do cliente em sistemas remotos.

 

O cliente de uma conexão de pipe, RPC ou DDE nomeada pode controlar o nível de representação. Por exemplo, um cliente de pipe nomeado pode chamar a função CreateFile para abrir um identificador para um pipe nomeado e especificar o nível de representação do servidor.

Quando a conexão de pipe nomeado, RPC ou DDE é remota, os sinalizadores passados para CreateFile para definir o nível de representação são ignorados. Nesse caso, o nível de representação do cliente é determinado pelos níveis de representação habilitados pelo servidor, que é definido por um sinalizador na conta do servidor no serviço de diretório. Por exemplo, se o servidor estiver habilitado para delegação, o nível de representação do cliente também será definido como delegação mesmo que os sinalizadores passados para CreateFile especifiquem o nível de representação de identificação.

Os clientes DDE usam a função DdeSetQualityOfService com a estrutura SECURITY_QUALITY_OF_SERVICE para especificar o nível de representação. O nível SecurityImpersonation é o padrão para servidores nomeados pipe, RPC e DDE. As funções ImpersonateSelf, DuplicateToken e DuplicateTokenEx permitem que o chamador especifique um nível de representação. Use a função GetTokenInformation para recuperar o nível de representação de um token de acesso.

No nível SecurityImpersonation, a maioria das ações do thread ocorre no contexto de segurança do token de representação do thread e não no token primário do processo que possui o thread. Por exemplo, se um thread de representação abrir um objeto protegível, o sistema usará o token de representação para marcar o acesso do thread. Da mesma forma, se um thread de representação criar um novo objeto, por exemplo, chamando a função CreateFile , o proprietário do novo objeto será o proprietário padrão do token de acesso do cliente.

No entanto, o sistema usa o token primário do processo em vez do token de representação do thread de chamada nas seguintes situações:

• Se um thread de representação chamar a função CreateProcess , o novo processo sempre herdará o token primário do processo.
• Para funções que exigem o privilégio SE_TCB_NAME, como a função LogonUser , o sistema sempre verifica o privilégio no token primário do processo.
• Para funções que exigem o privilégio SE_AUDIT_NAME, como a função ObjectOpenAuditAlarm , o sistema sempre verifica o privilégio no token primário do processo.
• Em uma chamada para a função OpenThreadToken , um thread pode especificar se a função usa o token de representação ou o token primário para determinar se deseja conceder o acesso solicitado.