Назад | Перейти на главную страницу

Влияние увеличения MaxTokenSize для билетов Kerberos

Недавно, мигрировав с Netware на файловые серверы Windows, мы закончили тем, что создали лодку групп AD. Теперь мы столкнулись с некоторыми проблемами с аутентификацией и получением доступа к ресурсам.

После некоторого первоначального устранения неполадок мы обнаружили, что администраторы домена являются членами слишком большого количества групп (397 по последнему подсчету), а размер билета Kerberos превысил 12000 байт (равен 13783) (идентификатор события 6). Я нашел следующую статью, которая, кажется, точно описывает, что произошло, и некоторые предложения, как это исправить:

http://blogs.technet.com/b/surama/archive/2009/04/06/kerberos-authentication-problem-with-active-directory.aspx

Цель состоит в том, чтобы поднять ограничение MaxTokenSize до 65535 в реестре. Однако я не могу найти обсуждения того, как это будет иметь последствия? В долгосрочной перспективе цель состоит в том, чтобы рационализировать рост числа групп, но в краткосрочной перспективе это кажется исправлением. Был ли у кого-нибудь подобный опыт в прошлом и есть ли какие-то предостережения, о которых нам следует знать, прежде чем внедрять это изменение?

В настоящее время мы работаем на уровне доменов и лесов Server 2008, где все контроллеры домена являются 64-битными виртуальными машинами.

ОБНОВЛЕНИЕ. Итак, немного больше прочитав об этом, я вижу, что в Server 2012 по умолчанию установлено значение 48000 для MaxTokenSize. Это кажется разумным вариантом для нас. Одна вещь, о которой я не могу найти информацию, - это вероятное влияние пользователей, имеющих более крупные токены. Есть некоторые предположения, что это увеличит использование памяти на серверах IIS, но знает ли кто-нибудь, будет ли это иметь место на контроллерах домена и рядовых серверах (например, 32-битных серверах Citrix и т. Д.)?

Многие организации давно установили это значение на 65535. Есть много статей Microsoft kb, которые рекомендуют это. Раньше рекомендация была 100 000, пока Microsoft не поняла, что значение не работает, и исправила это до 65 535.

Если вы используете встроенную проверку подлинности Windows с веб-сайтами IIS (например, SharePoint), большие токены могут привести к неудачной проверке подлинности. Это легко решить, увеличив значение MaxRequestBytes для службы http.sys. Это связано с тем, что токен Kerberos с группами включен в каждый http-запрос. Существует также параметр IIS, который может улучшить производительность встроенной проверки подлинности, так что только первый запрос должен быть проверен.

Я бы посоветовал проверить ваши группы и преобразовать некоторые в группы рассылки, если только они не являются абсолютно необходимыми для группы безопасности. Даже при максимальном размере токена 65535 учетная запись может быть членом такого количества групп, что она не сможет войти в систему.

Это Максимум размер токена. Маркер будет потреблять столько памяти, сколько необходимо. Это не означает, что ВСЕ токены Kerberos всегда будут иметь размер 48000 байт.

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

В Windows2012 существует новое жесткое ограничение на количество групп, в которые может входить учетная запись пользователя: 1015.

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

Попробуйте удалить DOMAIN USERS из числа всех ненужных групп.

Вот хорошая статья для справки: https://blogs.technet.microsoft.com/shanecothran/2010/07/16/maxtokensize-and-kerberos-token-bloat/