Поддержка Kerberos ограниченного делегирования с использованием SSPI для многопроцессорных

Question

Мне нужно поддерживать ограниченное делегирование Kerberos для нашего продукта C++ HTTP-сервера в Windows с использованием SSPI.

Для одного сервера процессов можно использовать следующий рабочий процесс, и у меня есть рабочий прототип. 1) Вызовите AcquireCredentialsHandle 2) Вызовите AcceptSecurityContext 3) Вызовите ImpersonateSecurityContext 4) Сделайте делегирование 5) Вызовите RevertSecurityContext

Тем не менее HTTP-сервер C++ имеет главный процесс и рабочий процесс. Оба процесса выполняются на одном компьютере и используют одну и ту же учетную запись службы, и каждый клиентский запрос может поступать от разных пользователей. Главный процесс может обрабатывать аутентификацию SPNEGO и Kerberos с использованием AcquireCredentialsHandle и AcceptSecurityContext, но он не знает, какой ресурс ему нужно делегировать, только знания рабочего процесса. Какие SSPI можно использовать для пересылки контекста безопасности клиента работнику, чтобы работник мог выполнять олицетворение / делегирование?

Кажется, одно из возможных решений - получить идентификацию клиента в мастере, передать ее работнику; тогда в рабочем используйте LsaLogonUser и ImpersonateLoggedOnUser. Однако, поскольку LsaLogonUser разрешает вход без пароля, наш эксперт по безопасности категорически против его использования.

У SSPI также есть ExportSecurityContext и ImportSecurityContext, но документация очень расплывчата и не уверена, может ли она помочь в моем случае использования. Поскольку в документации ImpersonateSecurityContext говорится, что она "позволяет серверу выдавать себя за клиента с помощью токена, ранее полученного при вызове AcceptSecurityContext (General) или QuerySecurityContextToken.", Кажется, я не могу вызвать ImpersonateSecurityContext после ImportSecurityContext.

Любое предложение приветствуется.

Answer 1

Вам нужно получить дескриптор токена в родительском процессе и скопировать его в дочерний процесс.

Вы делаете это так:

В вызове родительского процесса ImpersonateSecurityContext как обычно. Это установит вашу личность. Тогда позвони QuerySecurityContextToken чтобы получить маркер к этой идентичности. Как только у вас есть вызов ручки DuplicateHandle, но где целевой процесс является дескриптором дочернего процесса. Возвращенный lpTargetHandle является дескриптором с локальной ссылкой в целевом процессе (дочернем). Вам нужно будет как-то передать это значение целевому процессу.

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

Имейте в виду, что дочернему процессу понадобится SeImpersonatePrivilege.