Kerberos в Active Directory с использованием единого входа с ограниченным двойным прыжком и олицетворением не удается обновить билет службы

Question

Более глубокое изучение ограниченного делегирования Kerberos, которое уже обсуждалось в
Клиент-серверном приложении, как создать процесс в удаленной системе в качестве пользователя домена без передачи имени пользователя / пароля этого пользователя в удаленную систему?
поддержка ограниченного делегирования Kerberos с использованием SSPI для многопроцессорных систем

У меня есть распределенное приложение, работающее на нескольких серверах и использующее SSO через токены Kerberos для аутентификации пользователей, и все готово (и работает ) как обсуждено в вышеупомянутых темах. Вкратце,

1. Пользователь подключается к службе, работающей на сервере Server1
2. Сервер1 отправит задание пользователя на сервер Server2, на котором запущена другая служба под учетной записью участника службы
   a. Сервер1 запрашивает (и получает) билет на соответствующий SPN
   b. Сервер1 передает билет на Сервер 2
3. Сервер2 анализирует этот билет (то есть AcquireCredentialsHandle и AcceptSecurityContext ), а затем вызывает QuerySecurityContextToken , за которым следует DuplicateHandle , CreateProcess , передает дубликат дескриптора дочернему процессу, а затем дочерний процесс вызывает ImpersonateLoggedOnUser
4. Дочерний процесс на сервере Server2 теперь выполняется выдает себя за оригинального пользователя и может подключаться к сетевым ресурсам под этим пользователем на каком-либо сервере3

Итак, все работает просто отлично ... пока не перестанет. Билет на обслуживание, полученный на шаге 2а, имеет срок службы до 10 часов (при условии, что AD установлен по умолчанию для 10-часового срока действия для билетов на обслуживание). Причиной того, что срок действия билета иногда составляет менее 10 часов, является то, что между шагами 1 и 2 может быть значительная задержка, например, пользователь может выполнить некоторую подготовительную работу в течение целого дня перед отправкой работы на обработку. Таким образом, время окончания заявки на обслуживание составит 10 часов с момента первоначального входа пользователя в систему, т.е. соответствует времени окончания TGT, сгенерированного при подключении пользователя.

Примерно за 5 минут до истечения срока действия заявки на обслуживание Server2, похоже, пытается обновить эту заявку, и в klist появляется новый билет для LUID дочернего процесса на Server2. Однако этот новый тикет выглядит «неправильно отформатированным», и в этот момент клиентский процесс теряет возможность доступа к сетевым ресурсам по мере того, как пользователь подражает. В частности, хотя клиентский процесс по-прежнему содержит действительный билет службы Kerberos на ресурсы Server3, при обращении от Server2 к Server3 он переключается с проверки подлинности Kerberos на проверку подлинности NTLM, после чего Server3 отклоняет его.

Вот пример вывода klist для LUID, выполняющего дочерний процесс на Server2 в момент сбоя;

Current LogonId is 0:0x5777e  
Targeted LogonId is 0:0x3966b5

Cached Tickets: (5)

#0>     Client: user @ VNET.COM
        Server: MSSQLSvc/sql.vnet.com:1433 @ VNET.COM
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 2/20/2020 22:21:02 (local)
        End Time:   2/21/2020 7:07:45 (local)
        Renew Time: 2/27/2020 21:07:45 (local)
        Session Key Type: RSADSI RC4-HMAC(NT)
        Cache Flags: 0
        Kdc Called: DC.Vnet.com

#1>     Client: user @ VNET.COM
        Server: ldap/DC.Vnet.com/Vnet.com @ VNET.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
        Start Time: 2/20/2020 22:21:02 (local)
        End Time:   2/21/2020 7:07:45 (local)
        Renew Time: 2/27/2020 21:07:45 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: DC.Vnet.com

#2>     Client: user @ VNET.COM
        Server: svc @
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0xa10000 -> renewable pre_authent name_canonicalize
        Start Time: 2/20/2020 22:23:37 (local)
        End Time:   2/21/2020 7:07:45 (local)
        Renew Time: 2/27/2020 21:07:45 (local)
        Session Key Type: RSADSI RC4-HMAC(NT)
        Cache Flags: 0x4 -> S4U
        Kdc Called: DC.Vnet.com

#3>     Client: user @ VNET.COM
        Server: svc @
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0xa10000 -> renewable pre_authent name_canonicalize
        Start Time: 2/20/2020 22:23:37 (local)
        End Time:   2/21/2020 7:07:45 (local)
        Renew Time: 2/27/2020 21:07:45 (local)
        Session Key Type: RSADSI RC4-HMAC(NT)
        Cache Flags: 0x4 -> S4U
        Kdc Called: DC.Vnet.com

#4>     Client: user @ VNET.COM
        Server: SVCD/APP.Vnet.com @ VNET.COM
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 2/20/2020 22:11:39 (local)
        End Time:   2/20/2020 22:26:39 (local)
        Renew Time: 0
        Session Key Type: RSADSI RC4-HMAC(NT)
        Cache Flags: 0x8 -> ASC
        Kdc Called:

В приведенном выше листинге билет № 4 является оригинальным сервисным билетом, запрошенным на шаге 2а; имя участника-службы « SVCD / APP. Vnet .com », а учетная запись домена, связанная с этим именем участника-службы (и выполняющая процесс службы Server2), « sv c» , Этот билет использовался для создания контекста безопасности пользователя на сервере Server2, и дочерний процесс имитировал этот контекст безопасности. Билеты # 0 и # 1 были сгенерированы после олицетворения, когда дочерний процесс пытался связаться с серверами LDAP и MS SQL (для работы, которую должен выполнить дочерний процесс), так что это подтверждает, что все установки ограниченного делегирования хороши, а дочерний процесс работает, как ожидается, до 10 часов. В некоторых случаях билеты № 0 и № 1 необходимо обновить - и они успешно обновлены, и процесс продолжается.

Теперь проблема: тикеты # 2 и # 3 были сгенерированы за несколько минут до окончания # 4, но мне кажется странным то, что часть ServerRealm, то есть « sv c @ … »пусто. Кроме того, в момент генерирования этих билетов дочерний процесс Server2 перестает иметь возможность открывать новые подключения MS SQL к Server3 (и на Server3 события отклонения входа ANONYMOUS регистрируются с соответствующими метками времени). Я должен также упомянуть, что хотя в приведенном выше примере есть два идентичных билета для « Server: sv c @ », в некоторых случаях я вижу 7, 14, а иногда даже 30+ идентичных билетов, подобных этому , Все они выпущены одновременно, как будто есть какая-то попытка Френти c на Server2 получить то, что ему нужно от KD C, но безуспешно.

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

На данный момент я не уверен, в чем проблема;
a) Настройка AD (т. Е. С ограниченными деталями делегирования) или
b) в разрешениях для « sv». c ”доменная учетная запись (она имеет SetImpersonatePrivilege , но может потребоваться что-то еще) или
c) в способе передачи контекста безопасности пользователя между родительским процессом и дочерним процессом в Server2 или
d) что-то совершенно другое

До сих пор, после прочтения и исследования этого в течение значительного периода времени, я пробовал различные перестановки последовательности для c) (например, используйте Вместо этого DuplicateTokenEx + CreateProcessAsUser , переключая различные флаги для дублирующих дескрипторов и токенов, и т. Д. c.), Но я не знаю, что (если что-нибудь) я могу и должен делать с а) и б). Я попытался изменить некоторые настройки, но безрезультатно, но я избегал использования «ядерных» опций, таких как настройка SeTcbPrivilege для учетной записи sv c, поскольку это не было бы приемлемым решением в моем случае.

Последнее замечание: в билете № 4 отсутствуют « Kd c Called » и « Renew Time », но у меня сложилось впечатление, что это нормальное явление. для непрозрачных билетов, полученных через InitializeSecurityContext .

Что мне нужно изменить, чтобы дочерний процесс на сервере Server2 работал после первоначальных 10 часов?