Windows impersonation что это



Client Impersonation

Impersonation is useful in a distributed computing environment when servers must pass client requests to other server processes or to the operating system. In this case, a server impersonates the client’s security context. Other server processes can then handle the request as if the original client made it.

For example, a client makes a request to Server A. If Server A must query Server B to complete the request, Server A impersonates the client security context and makes the request to Server B on behalf of the client. Server B uses the original client’s security context, instead of the security identity for Server A, to determine whether to complete the task.

The server calls RpcImpersonateClient to overwrite the security for the server thread with the client security context. After the task is completed, the server calls RpcRevertToSelf or RpcRevertToSelfEx to restore the security context defined for the server thread.

When binding, the client can specify quality-of-service information about security which specifies how the server can impersonate the client. For example, one of the settings lets the client specify that the server is not allowed to impersonate it. For more information, see Quality of Service.

The capability to call other servers while impersonating the original client is called delegation. When delegation is used, a server impersonating a client can call another server, and can make network calls with the credentials of the client. That is, from the perspective of the second server, requests coming from the first server are indistinguishable from requests coming from the client. Not all security providers support delegation. Microsoft ships only one security provider that supports delegation: Kerberos.

Delegation can be a dangerous capability due to the privileges the client gives the server during a remote procedure call. This is why Kerberos allows calls with the impersonation level of delegation only if mutual authentication is requested. Domain administrators can limit the computers to which calls with delegation impersonation level are made to prevent unsuspecting clients from making calls to servers that could abuse their credentials.

One exception to the delegation rule exists: calls using ncalrpc. When these calls are made the server gets delegation rights, even if an impersonation level of impersonate is specified. That is, a server can call other servers on behalf of the client. This works for one remote call only. For example, if client A calls local server LB using ncalrpc local server LB can impersonate and call remote server RB. RB will be able to act on behalf of client A, but only on the remote computer that RB is running on. It cannot make another network call to remote computer C unless LB specified an impersonation level of delegate when it called RB.

The term impersonation represents two overlapping meanings. The first meaning of impersonation is the general process of acting on behalf of a client. The second meaning is the specific impersonation level called impersonation. The context of the text generally clarifies the meaning.

Источник

Олицетворение

Олицетворение — это возможность выполнения потока в контексте безопасности, отличном от контекста процесса, которому принадлежит поток. При выполнении в контексте безопасности клиента сервер «является» клиентом в некоторой степени. Поток сервера использует маркер доступа, представляющий учетные данные клиента для получения доступа к объектам, к которым у клиента есть доступ.

Основная причина олицетворения заключается в том, чтобы проверки доступа выполнялись по отношению к удостоверению клиента. Использование удостоверения клиента для проверок доступа может привести к ограничению или расширению доступа в зависимости от того, что у клиента есть разрешение. Например, предположим, что файловый сервер содержит файлы, содержащие конфиденциальную информацию, и что каждый из этих файлов защищен ACL. Чтобы предотвратить получение клиентом несанкционированного доступа к информации в этих файлах, сервер может олицетворять клиент перед доступом к файлам.

Маркеры доступа для олицетворения

Маркеры доступа — это объекты, описывающие контекст безопасности процесса или потока. Они предоставляют сведения, в том числе удостоверение учетной записи пользователя и подмножество привилегий, доступных для учетной записи пользователя. Каждый процесс имеет первичный маркер доступа , описывающий контекст безопасности учетной записи пользователя, связанной с процессом. По умолчанию система использует основной маркер, когда поток процесса взаимодействует с защищаемым объектом. Однако при олицетворении клиента поток имеет как основной маркер доступа, так и маркер олицетворения. Маркер олицетворения представляет контекст безопасности клиента, и этот маркер доступа используется для проверки доступа во время олицетворения. Когда олицетворение закончится, поток возвращается к использованию только основного маркера доступа.

Функцию OpenProcessToken можно использовать для получения дескриптора основного маркера процесса. Используйте функцию OpenThreadToken , чтобы получить дескриптор маркера олицетворения потока.

Источник

Client Impersonation (Authorization)

Impersonation is the ability of a thread to execute using different security information than the process that owns the thread. Typically, a thread in a server application impersonates a client. This allows the server thread to act on behalf of that client to access objects on the server or validate access to the client’s own objects.

The Microsoft Windows API provides the following functions to begin an impersonation:

  • A DDE server application can call the DdeImpersonateClient function to impersonate a client.
  • A named-pipe server can call the ImpersonateNamedPipeClient function.
  • You can call the ImpersonateLoggedOnUser function to impersonate the security context of a logged-on user’s access token.
  • The ImpersonateSelf function enables a thread to generate a copy of its own access token. This is useful when an application needs to change the security context of a single thread. For example, sometimes only one thread of a process needs to enable a privilege.
  • You can call the SetThreadToken function to cause the target thread to run in the security context of a specified impersonation token.
  • A Microsoft Remote Procedure Call (RPC) server application can call the RpcImpersonateClient function to impersonate a client.
  • A security package or application server can call the ImpersonateSecurityContext function to impersonate a client.

For most of these impersonations, the impersonating thread can revert to its own security context by calling the RevertToSelf function. The exception is the RPC impersonation, in which the RPC server application calls RpcRevertToSelf or RpcRevertToSelfEx to revert to its own security context.

Источник

Delegation and Impersonation

In client/server scenarios, it is common for one server to call another server to accomplish some task on a client’s behalf. The situation where a server is given the authority to act on a client’s behalf is called delegation.

From a security standpoint, two issues arise regarding delegation:

  • What should the server be allowed to do when acting on the client’s behalf?
  • What identity is presented by the server when it calls other servers on behalf of a client?

To deal with these issues, COM provides the following functionality. The client can set an impersonation level that determines to what extent the server will be able to act as the client. If the client grants enough authority to the server, the server can impersonate (pretend to be) the client. When impersonating the client, the server is given access to only those objects or resources that the client has permission to use. The server, acting as a client, can also enable cloaking to mask its own identity and project the client’s identity in calls to other COM components.

Consider the scenario illustrated by the preceding figure, where A and B are processes on a different machine from C. Process A calls B, and B calls C. Client A sets the impersonation level. B sets the cloaking capability. If A sets an impersonation level that permits impersonation, B can impersonate A when calling C on A’s behalf. The identity that is presented to process C will be either A’s identity or B’s identity, depending on whether cloaking was enabled by B. If cloaking is enabled, the identity presented to process C will be that of A. If cloaking is not enabled, B’s identity will be presented to C.

For more information, see the following topics:

Источник

Олицетворение и делегирование клиента

В некоторых случаях серверное приложение должно представить удостоверение клиента для ресурсов, к которому он обращается от имени клиента, как правило, для проверки доступа или проверки подлинности для удостоверения клиента. В определенной степени сервер может действовать под удостоверением клиента — действие, называемое олицетворение клиента.

Олицетворение — это способность потока выполняться в контексте безопасности, отличном от возможности процесса, владеющего потоком. Поток сервера использует маркер доступа, представляющий учетные данные клиента, и при этом он может получить доступ к ресурсам, к которым клиент может получить доступ.

Использование олицетворения гарантирует, что сервер может точно делать то, что может сделать клиент. Доступ к ресурсам может быть ограничен или расширен в зависимости от того, что у клиента есть разрешение.

При подключении к базе данных может потребоваться олицетворение сервера при подключении к базе данных, чтобы база данных могла пройти проверку подлинности и авторизовать клиент для себя. Или, если приложение обращается к файлам, защищенным с помощью дескриптора безопасности, и чтобы клиент мог получить авторизованный доступ к информации в этих файлах, приложение может олицетворять клиент перед доступом к файлам.

Реализация олицетворения

Олицетворение требует участия как клиента, так и сервера (а в некоторых случаях системных администраторов). Клиент должен указать готовность разрешить серверу использовать свое удостоверение, а сервер должен явно предположить, что удостоверение клиента должно быть программно. Дополнительные сведения см. в разделах » Требования на стороне клиента для олицетворения и требования на стороне сервера для олицетворения».

Административные требования для олицетворения Delegate-Level

Чтобы эффективно использовать наиболее мощную форму олицетворения, делегирование, являющееся олицетворением клиентов по сети, учетные записи пользователей клиента и сервера должны быть правильно настроены в службе Active Directory для его поддержки (в дополнение к центру предоставления клиента для выполнения олицетворения на уровне делегата) следующим образом:

  • Удостоверение сервера должно быть отмечено как «Доверенный для делегирования» в службе Active Directory.
  • Удостоверение клиента не должно быть отмечено как «Учетная запись является конфиденциальной и не может быть делегировано» в службе Active Directory.

Эти функции конфигурации дают администратору домена высокий уровень контроля над делегированием, что желательно, учитывая степень доверия (и, следовательно, риск безопасности). Дополнительные сведения о делегировании см. в разделе «Делегирование и олицетворение».

Маскировочное

Наряду с центром, клиент предоставляет сервер через уровень олицетворения, возможность маскировки сервера в значительной степени определяет, как будет вести себя олицетворение. Маскировка влияет на то, какое удостоверение фактически представлено сервером при выполнении вызовов от имени клиента — собственного или собственного клиента. Дополнительные сведения см. в разделе «Маскировка».

Влияние на производительность

Олицетворение может значительно повлиять на производительность и масштабирование. Как правило, более дорого олицетворять клиента при вызове, чем делать звонок напрямую. Ниже приведены некоторые из вопросов, которые следует рассмотреть.

  • Вычислительные издержки передачи идентификаторов в сложных шаблонах, особенно если включена динамическая маскировка.
  • Общая сложность применения избыточной проверки безопасности в многочисленных местах, а не только централизованно на среднем уровне.
  • Такие ресурсы, как подключения к базе данных, при открытии олицетворения клиента, нельзя повторно использовать на нескольких клиентах — очень большой блок масштабирования.

Иногда единственным эффективным решением проблемы является использование олицетворения, но это решение следует тщательно взвешивать. Дополнительные сведения об этих проблемах см. в разделе «Безопасность многоуровневых приложений».

Очереди компонентов

Компоненты очереди не поддерживают олицетворение. Когда клиент выполняет вызов к объекту в очереди, вызов выполняется в средство записи, который упаковывают его как часть сообщения на сервер. Затем прослушиватель считывает сообщение из очереди и передает его проигрывателю, который вызывает фактический серверный компонент и вызывает тот же вызов метода. Таким образом, когда сервер получает вызов, исходный маркер клиента недоступен через олицетворение. Однако безопасность на основе ролей по-прежнему применяется, а программная безопасность с помощью интерфейса ISecurityCallContext будет работать. Дополнительные сведения см. в разделе «Безопасность компонентов в очереди».

Источник

You may also like...