Livelli di rappresentazione (autorizzazione)
L'enumerazione SECURITY_IMPERSONATION_LEVEL definisce quattro livelli di rappresentazione che determinano le operazioni che un server può eseguire nel contesto del client.
| Livello di rappresentazione | Descrizione |
|---|---|
| SecurityAnonymous | Il server non può rappresentare o identificare il client. |
| SecurityIdentification | Il server può ottenere l'identità e i privilegi del client, ma non può rappresentare il client. |
| SecurityImpersonation | Il server può rappresentare il contesto di sicurezza del client nel sistema locale. |
| SecurityDelegation | Il server può rappresentare il contesto di sicurezza del client nei sistemi remoti. |
Il client di una connessione denominata pipe, RPC o DDE può controllare il livello di rappresentazione. Ad esempio, un client pipe denominato può chiamare la funzione CreateFile per aprire un handle a una pipe denominata e specificare il livello di rappresentazione del server.
Quando la connessione denominata pipe, RPC o DDE è remota, i flag passati a CreateFile per impostare il livello di rappresentazione vengono ignorati. In questo caso, il livello di rappresentazione del client è determinato dai livelli di rappresentazione abilitati dal server, che viene impostato da un flag sull'account del server nel servizio directory. Ad esempio, se il server è abilitato per la delega, il livello di rappresentazione del client verrà impostato anche sulla delega anche se i flag passati a CreateFile specificano il livello di rappresentazione dell'identificazione.
I client DDE usano la funzione DdeSetQualityOfService con la struttura SECURITY_QUALITY_OF_SERVICE per specificare il livello di rappresentazione. Il livello SecurityImpersonation è il valore predefinito per i server denominati pipe, RPC e DDE. Le funzioni ImpersonateSelf, DuplicateToken e DuplicateTokenEx consentono al chiamante di specificare un livello di rappresentazione. Usare la funzione GetTokenInformation per recuperare il livello di rappresentazione di un token di accesso.
A livello di SecurityImpersonation, la maggior parte delle azioni del thread si verifica nel contesto di sicurezza del token di rappresentazione del thread anziché nel token primario del processo proprietario del thread. Ad esempio, se un thread di rappresentazione apre un oggetto a protezione diretta, il sistema usa il token di rappresentazione per controllare l'accesso al thread. Analogamente, se un thread di rappresentazione crea un nuovo oggetto, ad esempio chiamando la funzione CreateFile , il proprietario del nuovo oggetto è il proprietario predefinito dal token di accesso del client.
Tuttavia, il sistema usa il token primario del processo anziché il token di rappresentazione del thread chiamante nelle situazioni seguenti:
- Se un thread di rappresentazione chiama la funzione CreateProcess , il nuovo processo eredita sempre il token primario del processo.
- Per le funzioni che richiedono il privilegio SE_TCB_NAME, ad esempio la funzione LogonUser , il sistema controlla sempre il privilegio nel token primario del processo.
- Per le funzioni che richiedono il privilegio SE_AUDIT_NAME, ad esempio la funzione ObjectOpenAuditAlarm , il sistema controlla sempre il privilegio nel token primario del processo.
- In una chiamata alla funzione OpenThreadToken , un thread può specificare se la funzione usa il token di rappresentazione o il token primario per determinare se concedere l'accesso richiesto.