MaxTokenSize и настройка размера токена Kerberos

Добрый день! Уважаемые читатели и гости одного из популярнейших IT блогов России Pyatilistnik.org. В прошлый раз мы с вами устранили причину черного экрана в Windows 10, так как эта ошибка перекочевала и в самую последнюю на текущий момент версию 1903, ая яй Microsoft. Сегодня я вам покажу, как решается ошибка ID 6, мы разберем параметр MaxTokenSize, отвечающий за размер билета Kerberos. Мы разберем, ситуации, когда его следует увеличить и на сколько. Благодаря этим действиям вы решите много проблем с применением GPO, запуска оснасток и прохождения аутентификации в разных сервисах. Уверен, что это будет полезная информация.

Описание ошибки Security-Kerberos ID 6 и ID 40960

У меня в организации давно идет переезд со старых серверов с Windows Server 2008 R2 на Windows Server 2016-19. На одном из старых серверов, у сотрудника технической поддержки возник ряд сложностей, а именно:

• При открытии оснастки "Active Directory - Пользователи и компьютеры" у него выскочила ошибка, о сетевой недоступности контроллера домена

• При запуске Data ONTAP 7G, выскакивала ошибка доступа (https://kb.netapp.com/app/answers/answer_view/a_id/1001986/)
• При открытии под данной учетной записью пользователя на данном сервере корпоративного сервиса в браузере, выскакивала ошибка, о его недоступности с кодом 400 (HTTP 400 Bad Request/The webpage cannot be found).

• К пользователю не применяются групповые политики
• Не получается зайти в SQL. Мы получаем ошибку:

При попытке обратиться по протоколу CIFS на контроллер домена, в моем случае, это \\ROOT (root.pyatilistnik.org), я получал ошибку:

А должно быть вот так.

Так же мое внимание привлекло предупреждение:

Из события с кодом ID 6, вам говорят, про какой-то параметр реестра MaxTokenSize и количество групп, к которым принадлежит пользователь, давайте разбираться, что это за зверь.

Что такое MaxTokenSize и каково его влияние

По мере роста срока службы Active Directory учетные записи пользователей становятся членами все большего числа групп безопасности. В некоторых случаях это может вызвать проблемы, которые обычно трудно распознать. Они часто выглядят как случайные сбои или сбои приложения: сбои приложения групповой политики, запуск веб-сайта, заканчивающийся ошибкой HTTP 400, сеанс входа в систему невозможен.

Информация о членстве в группе, используемая для создания токена доступа, отправляется в зашифрованном виде в билете Kerberos. Часть билета Kerberos, используемая для хранения этой информации о членстве в группе, называется Сертификатом атрибута привилегии (Privilege Attribute Certificate - PAC), для инкапсуляции информации, связанной с авторизацией, в соответствии с RFC4120. Информация авторизации, включенная в PAC, включает идентификаторы безопасности, информацию профиля пользователя, такую ​​как полное имя, домашний каталог и количество неверных паролей. Идентификаторы безопасности (SID), включенные в PAC, представляют текущий SID пользователя и любые экземпляры истории SID и членства в группах безопасности в пределах текущих групп доменов, групп доменов ресурсов и универсальных групп.

Если для максимального размера токена установлено слишком малое значение для хранения всей информации о членстве в группе для пользователя, токен не будет содержать полного членства в группах. Пользователь не сможет пройти проверку подлинности, поскольку маркер Kerberos, созданный во время попыток проверки подлинности, имеет фиксированный максимальный размер. Транспортные протоколы, такие как удаленный вызов процедур (RPC) и HTTP, полагаются на значение MaxTokenSize, когда они выделяют пространство памяти для обработки аутентификации. Это значение изменилось со времен Windows 2000. Сейчас мы находимся в самых последних версиях Windows со значением 48K.

В итоге MaxTokenSize - это предопределенный буфер для размещения запросов авторизации в токене Kerberos, который получил пользователь. По сути, Kerberos использует этот буфер авторизации, чтобы позволить таким протоколам, как HTTP, устанавливать распределение памяти для функций аутентификации. Таким образом, параметр MaxTokenSize сообщит Windows, насколько большим может быть запрос на проверку подлинности с использованием протокола, например, HTTP, до того, как запрос не будет выполнен.

История размера MaxTokenSize

• Windows 2000 имел размер 8000 байт
• Windows 2000 SP2 - 12 000 байт
• Windows 2003 - 12 000 байт
• Windows XP - 12 000 байт
• Windows Vista - 12 000 байт
• Windows 7 - 12 000 байт
• Windows 2008 - 12 000 байт
• Windows 2008 R2 - 12 000 байт
• Windows 8 - 48 000 байт
• Windows 2012 - 48 000 байт
• Windows 8.1 - 48 000 байт
• Windows 2012 R2 - 48 000 байт
• Windows 10 - 48 000 байт
• Windows Server 2019 - 48 000 байт

О чем не догадывается пользователь

Так что же происходит, когда пользователь пытается представить токен доступа, который больше, чем буфер MaxTokenSize, определенный на удаленном сервере Windows? Маркер доступа пользователя будет автоматически уменьшен в соответствии с настроенным размером буфера. Это означает, что SID (ключи) будут удалены с токена доступа во время запроса. SID, требуемый для доступа к ресурсу, может быть отфильтрован и привести к сообщению об отказе в доступе пользователю, даже если у него действительно есть соответствующие права в списке управления доступом. Выше я привел пример ошибки обращения в сетевому ресурсу.

Другая распространенная проблема, которая приводит к проблемам с буфером MaxTokenSize, связана с добавлением пользователей в большое количество групп. Большинство компаний растут и растет их инфраструктура Active Directory, и, по моему опыту, нередки проблемы MaxTokenSize после того, как пользователь был перенесен несколько раз (Мигрирован), а очистка членства в группе не проверена. Как только токен Kerberos пользователя растет и превосходит буфер MaxTokenSize, он начинает видеть сообщения об ошибках от приложений, использующих Kerberos для аутентификации.

По моему мнению, максимальный размер MaxTokenSize по умолчанию до Windows 7/2008 R2 был слишком низким и привел к тому, что многие бессонные ночи и заявки на устранение проблем, были вызваны именно этим фактором. Для администраторов Exchange, есть глубокое осознание проблемы MaxTokenSize, когда небольшие группы пользователей не смогли успешно установить соединения Outlook Anywhere (RPC/HTTP) с серверами клиентского доступа, но большинство пользователей могли без каких-либо проблем. Эти проблемы всегда являются скрытыми по своей природе, потому что их трудно устранить, и они могут казаться спорадическими по своей природе, что приводит к потере времени на устранение неисправностей.

Поле, содержащее идентификаторы безопасности участников группы в маркере доступа, теоретически может содержать не более 1024 идентификаторов безопасности. На самом деле это не 1024, а 1024 - 9 - это 1015 SID! Если пользователь состоит в более чем 1015 группах, LSA не может создать маркер доступа во время попытки входа в систему. В этом случае при входе пользователя отображается следующее сообщение об ошибке:

Расчет размера токена Kerberos

Существует математическая формула для расчета значения токена для пользователя: Microsoft документирует его в этой статье (https://support.microsoft.com/fr-fr/help/327825/problems-with-kerberos-authentication-when-a-user-belongs-to-many-grou), и мы можем взять его здесь:

TokenSize = 1200 байт + (40 байт X d ) + (8 байт X s )

• d : Представляет количество локальных групп, к которым принадлежит пользователь + количество универсальных групп вне домена учетной записи пользователя + количество групп, представленных в истории SID.
• s : представляет количество глобальных групп, к которым принадлежит пользователь + количество универсальных групп в домене учетной записи пользователя.
• 1200: представляет приблизительное значение для остальной части билета. Это значение может варьироваться в зависимости от таких факторов, как длина доменного имени DNS, имя клиента и другие факторы.

Мы можем использовать этот скрипт powershell для расчета стоимости билета для пользователя. Он использует формулу выше. Однако существует менее известный метод перечисления групп, к которым принадлежит пользователь, через команду NTDSUTIL / group membership evaluation, а затем запустить имя учетной записи NOMDEDOMAIN (https://support.microsoft.com/en-us/help/328889/logging-on-a-user-account-that-is-a-member-of-more-than-1010-groups-ma).

Как узнать текущий размер токена Kerberos у пользователя и компьютера

Для того, чтобы посмотреть текущие параметры размера MaxTokenSize на компьютере, вы можете воспользоваться оболочкой PowerShell. Открываем ее и вводим команду:

Как видим в моей Windows 10 значение у MaxTokenSize 48 КБ.

Чтобы узнать размер MaxTokenSize у текущего пользователя можно воспользоваться специальным скриптом, который выложил один инженер Microsoft, проходим по ссылке (https://gallery.technet.microsoft.com/scriptcenter/Check-for-MaxTokenSize-520e51e5) или у меня. Нажимаем загрузить скрипт.

Соглашаемся с лицензионным соглашением.

У вас выскочит уведомление, что он не имеет цифровой подписи, и нужно нажать R, чтобы его запустить, это связано с политикой Set-ExecutionPolicy, которая по умолчанию блокирует такие скрипты, как запускать скрипты и менять политику я подробно описывал, кому интересно посмотрите.

Далее вас спросят для какой операционной системы вы хотите рассчитать, это влияет только на то, будет ли выявлено превышение, так как я напомню, что у каждой версии операционной системы параметр MaxTokenSize может иметь свои значения. Я выберу для Windows 10 и нажимаю 6. В итоге мы видим, что мой пользователь Барбоскин имеет размер буфера MaxTokenSize в 4928 байт и до 48 000 мне очень далеко, так же там есть информация:

• There are 48 groups in the token. - общее количество групп в которых состоит пользователь
• There are 0 SIDs in the users SIDHistory. - есть ли группы из-за SIDHistory
• There are 4 SIDs in the users groups SIDHistory attributes. - атрибуты SID
• 7 are domain global scope security groups. - количество глобальных групп
  3 are domain local security groups. - количество доменных групп
  6 are universal security groups inside of the users domain. - количество универсальных групп
  22 are universal security groups outside of the users domain. - универсальные группы безопасности вне домена пользователя

Управление ограничением размера MaxTokenSize

Теперь когда мы понимаем, что у нас есть ограничение по умолчанию в старых операционных системах и более расширенное значение в новых, у вас есть два пути решения проблемы с размером буфера MaxTokenSize:

• Вы можете уменьшить количество групп в которые входит пользователь, так сказать провести аудит, я сомневаюсь, что ему нужны сотни групп или тысяча
• Второй вариант, это увеличить или локально или массово на всех компьютерах со старой версией ОС параметр MaxTokenSize до 48 000, максимальное значение 64 КБ.

С уменьшением параметра все понятно, давайте я покажу, как его увеличить на компьютере, так как настройка исключительно делается для его ветки реестра.

Увеличить MaxTokenSize через реестр Windows

Откройте редактор реестра Windows и перейдите в ветку:

Где вам необходимо создать DWORD (32-bit) Value с именем MaxTokenSize и значением 48 000

Увеличить MaxTokenSize через групповую политику

Для массового применения настройки мы с вами воспользуемся всеми прелестями групповой политики. Откройте оснастку "Управление групповой политикой" и создайте новый объект GPO.

Нас интересует настройка:

Выставите "Включено" и значение 48000. Напоминаю, что после сохранения настроек, вы должны дождаться, когда политика отреплецируется на все контроллеры домена, это 5 минут. После чего вы должны или принудительно обновить групповую политику или дождаться штатного автоматического обновления, это 90-120 минут, после чего, чтобы MaxTokenSize заработал, сервер нужно перезагрузить, иначе он будет работать со старым значением.

Теперь кстати после превышения кем-то порога значения MaxTokenSize у вас в логах системы будет записываться предупреждение с кодом ID 31. Ранее я говорил, что этот параметр политики решает ваши проблемы с использованием TOKENSZ и других утилит для определения MaxTokenSize - вот как. Если вы изучите подробности события 31 с предупреждением Kerberos-Key-Distribution-Center, вы заметите, что он предоставляет вам всю информацию, необходимую для определения оптимального MaxTokenSize в вашей среде. В следующем примере пользователь barboskin.g является участником более 1000 групп. Когда я пытаюсь войти barboskin.g с помощью команды RUNAS, я сгенерировал ID события 31. В описании события указываются имя участника службы, имя пользователя, размер запрошенного билета и размер порога. Это позволяет объединить все события 31 и определить максимальный размер запрашиваемого билета.

IIS, HTTP 400 - неверный запрос

В прошлом Microsoft указала, что можно увеличить размер MaxTokenSize до 65 535. Это то, что не рекомендуется, потому что некоторые приложения основаны на этом значении. Возьмите пример IIS. Как мы видели в этой статье , клиент использует заголовок   «Авторизация»  для предоставления серверу IIS элементов аутентификации (Ticket Kerberos). Следовательно, размер заголовка увеличивается с увеличением количества групп пользователей. Если заголовок HTTP увеличивается за пределы, установленные на сервере, сервер IIS может отклонить запрос и отправить сообщение об ошибке в качестве ответа (HTTP 400 - неверный запрос).

2 значения в реестре сервера для HTTP.sys позволяют вам контролировать максимальный размер каждого заголовка HTTP-запроса. По умолчанию эти значения отсутствуют, но могут быть созданы по мере необходимости в HKEY_LOCAL_MACHINE\System\CurrentControlSet \Services \HTTP\Parameters. Запись реестра MaxFieldLength указывает верхний предел общего размера строки запроса и заголовков. Обычно эта запись реестра настраивается с помощью записи реестра MaxRequestBytes. Если значение MaxRequestBytes меньше значения MaxFieldLength, значение MaxFieldLength корректируется.

Даже если его нет в реестре, MaxFieldLength по умолчанию устанавливается с Windows 2012 на 65 534. Из-за кодировки HTTP base64 заголовка HTTP значение MaxTokenSize не должно превышать 48 000 байтов (48 o X 1.333 = приблизительно 64 o). 1.333 представляет базовую кодировку 64, которая механически увеличивает размер заголовка. Вы можете прочитать эту статью, чтобы пойти дальше, расшифровав заголовок авторизации (http://remivernier.com/index.php/2018/09/16/exploration-des-entetes-http-www-authenticate/).

Сжатие SID ресурса KDC

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

Компоненты KDC для Windows Server 2012 помогают уменьшить размер PAC, используя сжатие SID ресурсов. По умолчанию Windows Server 2012 KDC всегда сжимает SID ресурса. Чтобы сжать идентификаторы ресурсов SID, KDC сохраняет SID домена ресурсов, членом которого является целевой ресурс. Затем он вставляет только часть RID каждого SID ресурса в часть ResourceGroupIds данных аутентификации. Сжатие SID ресурса уменьшает размер каждого сохраненного экземпляра SID ресурса, потому что SID домена сохраняется один раз, а не с каждым экземпляром. Без сжатия SID ресурса KDC вставляет все SID, добавленные доменом ресурса, в часть Extra-SIDструктуры PAC, которая является списком SID.

Interoperability

Другие реализации Kerberos могут не понимать сжатие группы ресурсов и поэтому несовместимы. В этих сценариях может потребоваться отключить сжатие группы ресурсов, чтобы обеспечить возможность взаимодействия KDC в Windows Server 2012 со сторонней реализацией Kerberos.

Сжатие SID ресурса включено по умолчанию; однако вы можете отключить его. Вы отключаете сжатие SID ресурса на KDC в Windows Server 2012 с помощью значения реестра DisableResourceGroupsFields в разделе реестра HKLM\Software\Microsoft\Windows\CurrentVersion \Policies\System\Kdc \Parameters. Это значение реестра имеет тип значения реестра DWORD. Вы полностью отключаете сжатие SID ресурса, когда устанавливаете значение реестра равным 1. KDC читает эту конфигурацию при создании заявки на обслуживание. При включенном бите KDC не использует сжатие SID ресурса при создании заявки на обслуживание.

На этом я заканчиваю свою стать про размер буфера MaxTokenSize. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.