Поделиться через

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

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

Исходный номер базы знаний: 327825

Симптомы

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

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

Примечание.

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

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

Причина

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

В рамках Exchange службы проверки подлинности Windows создает маркер для представления пользователя в целях авторизации. Этот маркер (также называемый контекстом авторизации) включает идентификаторы безопасности (SID) пользователя, а также идентификаторы siD всех групп, к которым принадлежит пользователь. Он также включает все идентификаторы SID, хранящиеся в атрибуте учетной записи sIDHistory пользователя. Kerberos сохраняет этот токен в структуре данных сертификата атрибута привилегий (PAC) в билете Kerberos Ticket-Getting Ticket (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 может не применять параметры групповой политики для пользователя.

Примечание.

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

Решение

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

Внимание

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

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

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

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

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

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

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

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

TokenSize = 1200 + 40d + 8s

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

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

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

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

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

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

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

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

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

    Внимание

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

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

Известные проблемы, влияющие на 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 процентов исходного размера. Таким образом, если максимальный размер буфера составляет 64 КБ в IIS, билет Kerberos может использовать 48 000 байт.

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

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

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

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

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