Проблемы с проверкой подлинности Kerberos, возникающие в том случае, когда пользователь принадлежит к нескольким группам

  • Статья

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

Применимо к: Windows 10 – все выпуски, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер базы знаний: 327825

Симптомы

У пользователя, который принадлежит к большому количеству групп безопасности, возникли проблемы с проверкой подлинности. При проверке подлинности пользователь может увидеть сообщение, например HTTP 400 — недопустимый запрос (слишком длинный заголовок запроса). У пользователя также возникают проблемы с доступом к ресурсам, и параметры групповая политика пользователя могут обновиться неправильно.

Дополнительные сведения о контексте ошибки см. в разделе Ответы http-запросов 400 Bad Request (слишком длинный заголовок запроса) на HTTP-запросы.

Примечание.

При аналогичных условиях проверка подлинности Windows NTLM работает должным образом. Проблема проверки подлинности Kerberos может не отображаться, если вы не проанализируете поведение Windows. Однако в таких сценариях Windows может не обновить параметры групповая политика.

Это происходит в любой из поддерживаемых в настоящее время версий Windows. Сведения о поддерживаемых в настоящее время версиях Windows см. в справке по жизненному циклу Windows.

Причина

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

В рамках службы проверки подлинности Exchange Windows создает маркер для представления пользователя в целях авторизации. Этот маркер (также называемый контекстом авторизации) включает идентификаторы безопасности (SID) пользователя и идентификаторы безопасности всех групп, к которым принадлежит пользователь. Он также включает все идентификаторы безопасности, хранящиеся в атрибуте учетной sIDHistory записи пользователя. Kerberos сохраняет этот маркер в структуре данных сертификата атрибута привилегий (PAC) в билете kerberos Ticket-Getting (TGT). Начиная с Windows Server 2012, Kerberos также сохраняет маркер в структуре данных сведений о утверждениях Active Directory (динамические контроль доступа) в билете Kerberos. Если пользователь является членом большого количества групп и имеется много утверждений для пользователя или используемого устройства, эти поля могут занимать много пробелов в билете.

Маркер имеет фиксированный максимальный размер (MaxTokenSize). Транспортные протоколы, такие как удаленный вызов процедуры (RPC) и HTTP, используют MaxTokenSize значение при выделении буферов для операций проверки подлинности. MaxTokenSize имеет следующее значение по умолчанию в зависимости от версии Windows, которая создает маркер:

  • Windows Server 2008 R2 и более ранних версий, а также Windows 7 и более ранних версий: 12 000 байт
  • Windows Server 2012 и более поздних версий, а также Windows 8 и более поздних версий: 48 000 байт.

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

Примечание.

На максимальное количество групп влияют и другие факторы. Например, идентификаторы безопасности для глобальных и локальных групп домена имеют меньшие требования к пространству. Windows Server 2012 и более поздних версиях добавляют сведения о утверждениях в билет Kerberos, а также сжимают идентификаторы безопасности ресурсов. Оба компонента изменяют требования к пространству.

Разрешение

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

Важно!

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

На каждом из этих компьютеров задайте MaxTokenSize для записи реестра большее значение. Эту запись можно найти в подразделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters . Компьютеры должны быть перезагружены после внесения этого изменения.

Дополнительные сведения об определении нового значения для MaxTokenSizeсм. в разделе Вычисление максимального размера маркера этой статьи.

Например, рассмотрим пользователя, который использует веб-приложение, использующее SQL Server клиент. В рамках процесса проверки подлинности клиент SQL Server передает маркер пользователя в серверную базу данных SQL Server. В этом случае необходимо настроить MaxTokenSize запись реестра на каждом из следующих компьютеров:

  • Клиентский компьютер, на котором работает Интернет-Обозреватель
  • Веб-сервер, на котором запущены службы IIS
  • Клиентский компьютер SQL Server
  • Компьютер базы данных SQL Server

В Windows Server 2012 (и более поздних версиях) Windows может записывать событие (с идентификатором события 31), если размер маркера проходит определенное пороговое значение. Чтобы включить это поведение, необходимо настроить групповая политика параметр Конфигурация компьютера\Административные шаблоны\System\KDC\Warning для больших билетов Kerberos.

Вычисление максимального размера маркера

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

TokenSize = 1200 + 40d + 8 с

Для Windows Server 2012 (и более поздних версий) эта формула определяет ее компоненты следующим образом:

  • 1200. Предполагаемое значение накладных расходов для билета Kerberos. Это значение может отличаться в зависимости от таких факторов, как длина доменного имени DNS и длина имени клиента.
  • г. Сумма следующих значений:
    • Количество членов в универсальных группах, которые находятся за пределами домена учетной записи пользователя.
    • Количество идентификаторов безопасности, хранящихся в атрибуте учетной sIDHistory записи. Это значение учитывает членство в группах и идентификаторы безопасности пользователей.
  • s. Сумма следующих значений:
    • Количество членства в универсальных группах, которые находятся в домене учетной записи пользователя.
    • Число членов в локальных группах домена.
    • Число членов в глобальных группах.

В Windows Server 2008 R2 и более ранних версиях используется та же формула. Однако в этих версиях число членства в локальных группах домена считается частью значения d , а не значения s .

Если у вас есть MaxTokenSize значение 0x0000FFFF (64 КБ), вы можете буферировать приблизительно 1600 идентификаторов безопасности D-класса или примерно 8000 идентификаторов безопасности S-класса. Однако на значение, которое можно безопасно использовать для MaxTokenSize, влияет ряд других факторов, включая следующие:

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

  • Если у вас несколько доверительных отношений, настройте отношения доверия для фильтрации идентификаторов безопасности. Такая конфигурация снижает влияние размера билета Kerberos.

  • Если вы используете Windows Server 2012 или более поздней версии, на требования к пространству идентификаторов безопасности также влияют следующие факторы:

    • Существует новая схема сжатия идентификаторов БЕЗОПАСНОСТИ в PAC. Дополнительные сведения см. в разделе Сжатие идентификаторов безопасности ресурсов KDC. Эта функция уменьшает размер, необходимый для идентификаторов БЕЗОПАСНОСТИ в билете.
    • Динамическая контроль доступа добавляет утверждения Active Directory в билет, увеличивая требования к размеру. Однако после развертывания утверждений с Windows Server 2012 файловыми серверами можно ожидать поэтапного отказа от значительного числа групп, управляющих доступом к файлам. Это сокращение, в свою очередь, может уменьшить размер, необходимый для билета. Дополнительные сведения см. в статье Динамические контроль доступа: обзор сценария.

  • Если вы настроили Kerberos для использования неограниченного MaxTokenSizeделегирования, необходимо удвоить TokenSize значение из формулы, чтобы получить допустимую оценку .

    Важно!

    В 2019 году корпорация Майкрософт отправляла в Windows обновления, которые по умолчанию изменили конфигурацию неограниченного делегирования для Kerberos на отключенную. Дополнительные сведения см. в разделе Обновления делегирования TGT через входящие отношения доверия в Windows Server.

    Поскольку сжатие идентификаторов безопасности ресурсов широко используется, а неограниченное делегирование не рекомендуется, MaxTokenSize для всех сценариев должно быть достаточно 48 000 или больше.

Известные проблемы, влияющие на MaxTokenSize

Для MaxTokenSize большинства реализаций должно быть достаточно 48 000 байт. Это значение по умолчанию в Windows Server 2012 и более поздних версиях. Однако если вы решили использовать большее значение, ознакомьтесь с известными проблемами в этом разделе.

  • Ограничение размера в 1010 идентификаторов безопасности группы для маркера доступа LSA

    Эта проблема похожа на то, что пользователь, имеющий слишком много членства в группах, не может пройти проверку подлинности, но вычисления и условия, которые регулируют проблему, отличаются. Например, пользователь может столкнуться с этой проблемой при использовании проверки подлинности Kerberos или проверки подлинности Windows NTLM. Дополнительные сведения см. в статье Ведение журнала в учетной записи пользователя, которая входит в более чем 1010 групп, может завершиться ошибкой на компьютере под управлением Windows Server.

  • Известная проблема при использовании значений MaxTokenSize больше 48 000

    Для устранения вектора атаки типа "отказ в обслуживании" сервер IIS использует ограниченный размер буфера HTTP-запросов 64 КБ. Билет Kerberos, который является частью HTTP-запроса, закодирован как Base64 (6 бит, расширенный до 8 бит). Таким образом, билет Kerberos использует 133 процента от первоначального размера. Таким образом, если максимальный размер буфера в IIS составляет 64 КБ, билет Kerberos может использовать 48 000 байт.

    Если для записи реестра задано MaxTokenSize значение, превышающее 48 000 байт, а буферное пространство используется для идентификаторов безопасности, может возникнуть ошибка IIS. Однако если для записи реестра задано MaxTokenSize значение 48 000 байт, а пространство используется для идентификаторов безопасности и утверждений, возникает ошибка Kerberos.

    Дополнительные сведения о размерах буферов IIS см. в статье Ограничение размера заголовка для передачи HTTP, которую IIS принимает от клиента в Windows 2000.

  • Известные проблемы при использовании значений MaxTokenSize больше 65 535

    В предыдущих версиях этой статьи обсуждались значения до 100 000 байт для MaxTokenSize. Однако мы обнаружили, что в версиях администратора SMS возникают проблемы, если MaxTokenSize имеет значение 100 000 байт или больше.

    Мы также определили, что протокол IPSEC IKE не позволяет большому двоичному объекту безопасности быть больше 66 536 байт, и он также завершится ошибкой, если MaxTokenSize задано большее значение.