Розмір квитка Kerberos і проблеми його зростання

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

У нашому кейсі проблема виявлялася таким чином. Деякі користувачі не могли отримати доступ до ряду розгорнутих служб. Зокрема, спостерігалися проблема при спробі підключення до RDS фермі (помилка "Access denied")

В логах серверів Remote Desktop фіксувалася помилка Event Id 6:

The kerberos SSPI package generated an output token of size 22041 bytes, which was too large to fit in the token buffer of size 12000 bytes, provided by process id 4.
The output SSPI token being too large is probably the result of the user user @ domain being a member of a large number of groups.
It is recommended to minimize the number of groups a user belongs to. If the problem can not be corrected by reduction of the group memberships of this user, please contact your system administrator to increase the maximum token size, which in term is configured machine-wide via the following registry value: HKLM \ SYSTEM \ CurrentControlSet \ Control \ Lsa \ Kerberos \ Parameters \ MaxTokenSize.

При спробі підключення до SQL Server, спостерігалася така помилка:

Невідома помилка, пов'язана з базою даних.

SQL State: HY000, SQL Error Code: 0

Can not generate SSPI context. Зверніться до адміністратора системи.

А в журналі реєструвалася помилка Event Id -40960

The Security System detected an authentication error for the server XXXXXX. The failure code from authentication protocol Kerberos was "Buffer Too Small
The buffer is too small to contain the entry. No information has been written to the buffer. (0xc0000023).

Перевірка прав доступу до ресурсів проблеми не виявила. В ході подальшого розслідування інциденту виявилася залежність - все "проблемні" користувачі перебували у великій кількості груп безпеки Active Directory (з урахуванням вкладених груп більше 200). Таким чином, поступово ми прийшли до висновку, що проблема полягає в перевищенні максимального довжини квитка Kerberos, використовуваного для авторизації користувачів.

зміст:

  • Розмір квитка Kerberos
  • Як дізнатися поточний розмір квитка Kerberos користувача
  • Зменшення розміру токена Kerberos для користувача
  • Як збільшити розмір токена Kerberos

Розмір квитка Kerberos

Розмір квитка Kerberos залежить від наступних факторів:

  • Кількості груп безпеки Active Directory (в тому числі вкладених) створені учасником (групи типу distribution в токен не включаються)
  • використання SIDHistory.Примітка. Проблема з перевищенням максимального розміру квитка особливо часто зустрічається при міграції користувачів між доменами Active Directory і збереженні доступу до ресурсів старого домену через механізм SIDHistory
  • Використовуваного механізму аутентифікації (звичайний парольний або мультифакторний, наприклад, смарт карти)
  • Довірена чи обліковий запис для делегування чи ні

Kerberos використовує буфер для зберігання авторизаційної інформації і передає його розмір додатків, що використовують Kerberos. системний параметр MaxTokenSize - як раз і визначає розмір буфера. Розмір буфера має значення, тому що деякі протоколи, такі як RPC і HTTP, використовують його при виділенні блоку пам'яті для аутентифікації. Якщо авторизовані дані користувача, що намагається аутентифицироваться, перевищують розмір MaxTokenSize, спроба аутентифікація вважається невдалою. Цим можна пояснити помилки аутентифікації при доступі до IIS, в той час як файловий доступ до мережевих ресурсів зберігається.

За замовчуванням, розмір буфера Kerberos (MaxTokenSize)

  • У Windows 7 і Windows Server 2008R2 - 12 Кб.
  • У Windows 8 і Windows Server 2012 розмір збільшений до 48Кб.

Таким чином, якщо користувач полягає в великій кількості групах, всі описи груп просто не поміщаються 12 КБ, і при доступі до деяких ресурсів відбувається збій перевірки автентичності.

Порада. Є жорсткий ліміт на кількість груп, в яких може складатися користувач. Ліміт становить 1015 груп. При перевищенні кількості груп піт вході користувача в систему з'являється помилка "The system can not log you on due to the following error: During a logon attempt, the user's security context accumulated too many security IDs. Please try again or consult your system administrator"

Як дізнатися поточний розмір квитка Kerberos користувача

У Windows відсутні зручні вбудованими кошти, що дозволяють дізнатися розмір токена Kerberos для конкретного користувача.

Для отримання поточного розмір квитка скористаємося стороннім скриптом Powershell CheckMaxTokenSize.ps1 (від Tim Springston - Microsoft). Скрипт дозволяє отримати поточний розмір токена зазначеного користувача, кількість груп безпеки, в яких він включений, кількість SID, що зберігаються в SIDHistory користувача, а також довірена чи обліковий запис для делегування чи ні

Щоб скористатися скриптом, скачайте його за посиланням вище і збережіть з ім'ям CheckMaxTokenSize.ps1

Відключаємо перевірку скриптів:

Set-ExecutionPolicy RemoteSigned
Переходимо в каталог зі скриптом

Cd c: \ install \ ps
І дізнаємося розмір квитка Kerberos для користувача user_name:

.\ CheckMaxTokenSize.ps1 -Principals 'user_name' -OSEmulation $ true -Details $ true

Скрипт просить вказати для якого оточення слід обчислити розмір квитка користувача. Є два варіанта

1 - У Windows 7 / Windows Server 2008 R2 і більш ранніх (розмір токена 12К)

4 - У Windows 8 / Windows Server 2012 і наступних ОС (розмір токена 48K)

Натиснемо 1 і Enter. Через деякий час (3-4 хвилини) скрипт поверне наступну інформацію:

Token Details for user user_name
**********************************
User's domain is CORP.
Total estimated token size is 22648.
For access to DCs and delegatable resources the total estimated token delegation size is 45296.
Effective MaxTokenSize value is: 12000
Problem detected. The token was too large for consistent authorization. Alter the maximum size per KB http://support.microsoft.com/kb/327825 and consider reducing direct and transitive group memberships.
* Token Details for user_name *
There are 957 groups in the token.
There are SIDs in the users SIDHistory.
There are 248 SIDs in the users groups SIDHistory attributes.
There are 248 total SIDHistories for user and groups user is a member of.
1188 are domain global scope security groups.
37 are domain local security groups.
68 are universal security groups inside of the users domain.
0 are universal security groups outside of the users domain.
Group Details included in output file at C: \ Windows \ temp \ TokenSizeDetails.txt
SIDHistory details included in output file at C: \ Windows \ temp \ TokenSizeDetails.txt

Таким чином, ми визначили, що користувач user_name складається в 957 доменних групах безпеки, а розмір його квитка Kerberos - 22648, що майже в 2 рази більше, ніж стандартний розмір Kerberos Token Size в Windows 7 / Windows Server 2008 R.

Таким чином, щоб вирішити проблему з аутентифікацією, потрібно або зменшити розмір токена користувача, або збільшити розмір буфера на всіх серверних системах, на яких спостерігається проблема з авторизацією Kerberos.

Зменшення розміру токена Kerberos для користувача

Якщо можливо, спробуйте зменшити розмір квитка Kerberos користувача за рахунок:

  • Зменшення кількості груп, в яких створені учасником.Порада. Цьому може сприяти впровадження нового механізму контролю доступу до файлових ресурсів, що з'явився в Windows Server 2012 - Dynamic Access Control
  • Очищення SID History
  • Відмова від довірених на делегування облікових записів (істотно скорочує розмір токена)

Як збільшити розмір токена Kerberos

У тому випадку, якщо скоротити розмір квитка Kerberos користувачів не представляється можливим, можна збільшити розмір буфера для нього. Для цього в реєстрі є спеціальний параметр MaxTokenSize.

Microsoft не рекомендує встановлювати розмір MaxTokenSize більш 64Кб, в загальному випадку рекомендується спочатку збільшити ліміт до 48Кб (ліміт для Windows 8/2012). Щоб збільшити розмір буфера:

  1. Відкрийте редактор реєстру і перейдіть в розділ HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ Lsa \ Kerberos \ Parameters.
  2. Створіть новий параметр типу DWORD (32-bit) Value з ім'ям MaxTokenSize
  3. Вкажіть бажане значення для максимального розмір буфера (ми вказали 48000, тому що розміри токена користувачів не перевищують цього значення)
  4. перезавантажте систему

Цю операцію потрібно виконати на всіх серверних системах, на яких спостерігається проблеми аутентифікації.

Якщо проблеми аутентіфкаціі спостерігаються на сайтах IIS, потрібно також збільшити розмір заголовка HTTP до 64 КБ (0000ffff). За замовчуванням максимальний розмір заголовка - 16 КБ. Для цього на серверах IIS потрібно внести наступні зміни до реєстру (також буде потрібно перезавантаження):

HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ HTTP \ Parameters \ MaxFieldLength
DWORD: 0000ffff

HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ HTTP \ Parameters \ MaxRequestBytes
DWORD: 0000ffff

У Windows 8 і Windows Server 2012 з'явилася нова політика, яка дозволяє задати розмір максимальний MaxTokenSize - Set maximum Kerberos SSPI context token buffer size. Знаходиться вона в розділі Computer Configuration -> Policies -> Administrative Templates -> System -> Kerberos.

Крім того, є ще одна цікава політика Warning for large Kerberos tickets , що дозволяє налаштувати висновок в системний лог попереджень про перевищення розміру квитка.

Після включення політики при перевищенні порогового розміру квитка, в журналі будуть фіксувати подій Event 31 з текстом:

A ticket to the service ldap / »DC Name» / »DomainName» is issued for account «AccountName» @ »DomainName». The size of the encrypted part of this ticket is 17421 bytes, which is close or greater than the configured ticket size threshold (12000 bytes). This ticket or any additional tickets issued from this ticket might result in authentication failures if the client or server application allocates SSPI token buffers bounded by a value that is close to the threshold value.

.