Когда речь заходит об обработке информации на уровне предприятия и об идентификационных данных организации, мы обычно рассуждаем в терминах крупномасштабных системных архитектур. Но архитектуры могут масштабироваться от гигантских до миниатюрных — до уровня пакетов, передаваемых по проводам. Последнее время в своих статьях я касался нескольких важных вопросов, связанных с идентичностью, с которыми администраторам приходится иметь дело сегодня, — к примеру, проблемы организации безопасного подключения компании к той самой «станции обслуживания на небесах» (иначе именуемой «облаком»). На этот раз я хотел бы поговорить о предмете, расположенном на другом конце шкалы идентичности, который по меркам ИТ-иерархии относится чуть ли не к атомарному уровню, — о маркере доступа к системе безопасности Active Directory (AD). Эта крохотная частица управляет процессами авторизации в домене AD, и, если администратор не уделяет ей достаточного внимания, он может столкнуться с серьезными проблемами.

Маркер в билете

Протокол безопасности Kerberos — это краеугольный камень, на котором строится практически все здание AD. Строго говоря, протокол Kerberos отвечает только за аутентификацию (безопасную проверку подлинности пользователя в компьютерной сети). Но выпустив в свет Windows 2000, корпорация Microsoft расширила сферу применения протокола, который теперь участвует и в решении проблемы авторизации (то есть определяет, имеет ли тот или иной пользователь право на доступ к ресурсу). Специалисты Microsoft сразу же подверглись критике за то, что они, преследуя собственные цели, расширили существующие стандарты, в результате чего возникли проблемы совместимости с другими системами Kerberos. В данном случае стандарт Kerberos действительно получает возможность расширения; это делается с помощью добавления в билет на получение билета ticket-granting ticket (TGT) особого определяемого пользователем поля. Оно выполняет функцию адреса-заполнителя и именуется сертификатом атрибута привилегий Privilege Attribute Certificate (PAC). По замыслу специалистов Microsoft, маркер доступа к системе безопасности хранится в поле PAC билета Kerberos и предназначается для осуществления авторизации.

Как создается маркер доступа? Когда пользователь успешно проходит проверку подлинности в домене AD, служба аутентификации центра распространения ключей Kerberos направляет локальной службе каталогов, а также ближайшему глобальному каталогу запросы с целью определения, членом каких групп является данный пользователь. Затем служба аутентификации генерирует маркер доступа, содержащий эти группы и их идентификаторы безопасности, а также имя пользователя и его идентификатор безопасности, после чего добавляет этот маркер в билет TGT.

Чрезмерное разрастание маркеров

Размеры поля PAC и соответствующего маркера доступа — величины конечные; это поле не может вместить в себя маркер доступа, превосходящий его по размерам. Поэтому максимальное значение для числа групп, членом которых может являться тот или иной пользователь, составляет порядка 1015. К этому показателю мы придем, если из 1024 (максимальное число идентификаторов безопасности, которые могут храниться в поле PAC) вычтем непостоянное число хорошо известных групп, которые локальная система безопасности Local Security Authority, LSA) включает в маркер доступа. Более подробные сведения можно найти в статье Microsoft «Users who are members of more than 1,015 groups may fail logon authentication» по адресу support.microsoft.com/kb/328889. Такое пороговое значение кому-то покажется очень высоким, но имейте в виду, что пользователь может «упереться» в этот ограничитель, став членом всего-навсего 270 групп, а связанные с ним неудобства он начнет ощущать задолго до того, как выйдет на этот уровень. В данной ситуации, известной как чрезмерное разрастание маркеров, не стоит рассчитывать, что проблемы возникнут лишь у одного пользователя. От этого пострадают многие.

Почему? Причина в том, что, когда другие механизмы, такие как RPC и HTTP, распределяют буферы для аутентификации, эффективность их действий зависит от значения параметра реестра MaxToken­Size (в разделе HKEY_LOCAL_MACHINE\SYSTEM\CCS\Control\Lsa\Kerberos\Parameters). По умолчанию величина MaxToken­Size (максимальный размер маркера) составляет 12 000 байт; если пользователь является членом более чем 120 групп, время его регистрации в системе может увеличиться; кроме того, такому пользователю, вероятно, придется иметь дело и с другими «чудачествами» системы. А если число групп, указанных в маркере доступа, значительно превысит упомянутый порог, это обернется ошибками аутентификации и авторизации вида «доступ запрещен» (Access Denied). Порог значения MaxTokenSize можно повысить, и тогда будет снято ограничение для пользователей, входящих в большее число групп. Дополнительную информацию по этой теме можно найти в статье Microsoft «How to use Group Policy to add the MaxTokenSize registry entry to multiple computers» по адресу support.microsoft.com/kb/938118. Впрочем, современные операционные системы, начиная с Windows Vista и Windows Server 2008, автоматически увеличивают порог значения MaxTokenSize, а значит, пользователи могут входить в состав большего числа групп. Но как бы то ни было, это решение не более чем полумера; пользователи, работающие с крупными маркерами доступа, в любом случае будут по-прежнему ощущать снижение производительности, а порог в 1015 групп будет, как и прежде, верхним пределом, сколь высоко мы бы ни поднимали вручную пороговое значение переменной MaxTokenSize.

Важно иметь в виду, что в процессе перечисления групп, членом которых является тот или иной пользователь, в общий перечень включаются и все промежуточные группы. Из этого следует, что в случае использования структур с высоким уровнем вложенности групп, которые могут быть весьма удобными с организационной точки зрения, средний размер маркеров доступа пользователя будет увеличиваться. К примеру, если вы являетесь членом группы безопасности пользователей г. Мьюлшу, входящей в состав группы пользователей графства Бейли, которая в свою очередь входит в состав группы пользователей региона Техас, являющейся членом группы пользователей региона США, это значит, что в вашем маркере доступа уже содержатся четыре идентификатора безопасности.

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

Еще одно слабое место, по которому чрезмерно разросшиеся маркеры могут нанести удар, имеет отношение к продукту Microsoft SharePoint. Начиная с версии SharePoint 2007 применяется требование, согласно которому только группам безопасности — но не спискам рассылки distribution lists (DL), не имеющим идентификаторов безопасности, — предоставляются разрешения на обращение к ресурсам SharePoint. Самое простое решение (кстати, я уверен, что именно его реализуют многие компании) состоит в том, чтобы преобразовать списки рассылки в группы безопасности. Такой путь чреват самыми тяжелыми последствиями — потому что, во-первых, вы, скорее всего, управляли списками рассылки не так, как группами безопасности для управления доступом, а во-вторых, потому что, после того как сведения обо всех этих списках рассылки найдут свое отражение в маркерах доступа ваших пользователей, размеры упомянутых маркеров резко увеличатся. Скажите, членом какого количества списков рассылки электронной почты вы являетесь? Известно ли вам хотя бы это?

«Экстремальная» диета для маркеров

Чтобы обеспечить хотя бы минимальный уровень работоспособности системы, администратор может прибегнуть к разного рода ухищрениям, но кардинальное решение проблемы разросшихся маркеров возможно лишь при условии использования ряда оптимальных методов управления группами и жизненным циклом объектов. Начнем с решений-«времянок».

Первое. Рассмотрите возможность установления для параметра MaxTokenSize максимального значения 64К (то есть 65 535). Проблему чрезмерного разрастания маркеров таким методом не решить, но он поможет вам предотвратить сбои в процедуре аутентификации при использовании механизмов RPC и HTTP, возникающих вследствие недостаточного размера MaxTokenSize. Упомянутая выше статья Microsoft «How to use Group Policy to add the MaxTokenSize registry entry to multiple computers» содержит сведения о том, как использовать групповую политику с целью установления данного значения для нескольких пользователей.

Второе. Чтобы узнать, в какие группы пользователей вы входите, проще всего воспользоваться утилитой командной строки Whoami, включенной в комплект поставки Windows. Кстати, Whoami предоставляет также информацию о текущем пользователе локальной системы; эта утилита весьма полезна в случаях, когда нужно уточнить, под каким именем вы на сей раз зарегистрировались в системе. Для получения данных о членстве в группах нужно задействовать параметр/groups; в этом случае утилита перечислит все указанные в вашем маркере доступа группы, как прямые, так и промежуточные, а также их идентификаторы безопасности.

Третье. Обратите внимание на программу Tokensz, которую можно загрузить со страницы www.microsoft.com/download/en/details.aspx?id=1448 центра загрузки Microsoft. Эта утилита позволит проверить настройку MaxTokenSize для того или иного пользователя, а при использовании параметра /calc_groups выдаст список групп, в которые этот пользователь входит. Подготовив соответствующий сценарий, вы сможете с помощью утилиты Tokensz проверить данные по всем своим пользователям (или по выборке пользователей), что даст вам возможность выявить слабые места. В утилите Ntdsutil реализована функция Group Membership Evaluation; выполните ее применительно к тому или иному пользователю, и вы получите подробные сведения о его маркере доступа. Наряду с перечислением групп пользователя эта утилита отображает сведения по истории идентификатора безопасности (включение этих данных увеличивает размер маркера доступа), а также информацию о типе группы. Иными словами, утилита Ntdsutil — хорошее подспорье для администратора, желающего ознакомиться с данными пользователей, у которых возникли серьезные проблемы в связи с разрастанием маркеров.

Четвертое. Еще одно временное решение состоит в том, чтобы проанализировать данные, касающиеся пользователей, которых в наибольшей степени затронула проблема маркеров, и определить, есть ли возможность просто вывести этих пользователей из состава групп, входить в которые им уже не обязательно. Здесь мы имеем дело с классическим симптомом неудовлетворительного управления учетными записями и жизненным циклом объектов, ведь ввести человека в состав той или иной группы при необходимости гораздо проще, чем убрать его из группы, когда потребуется. Воспользовавшись информацией, полученной с помощью функции Group Membership Evaluation, вы сможете минимизировать локальные группы доменов, членом которых является пользователь, и высвободить соответствующее пространство в маркере доступа. Специалисты Microsoft разработали специальный документ с подробным анализом проблемы чрезмерно разросшихся маркеров — Addressing Problems Due To Access Token Limitation (www.microsoft.com/download/en/details.aspx?displaylang=en&id=13749). В нем содержатся пошаговые инструкции по ликвидации последствий этой проблемы. Но, чтобы решить ее полностью, вам необходимо проанализировать свои действия по управлению группами безопасности. При этом особое внимание нужно будет обратить на следующие моменты.

  • Сводите к минимуму число вложенных групп — в целом к вложенным группам нет никаких претензий, просто не нужно ими чрезмерно увлекаться. Ведь довольно часто встречаются циклические вложения, состоящие из нескольких уровней. Попытки разобраться с ними кого угодно могут довести до белого каления, особенно когда решать проблему нужно быстро.
  • Используйте локальные группы домена в качестве последних групп на пути к ресурсу, и только в этом качестве. Везде, где это возможно, преобразуйте локальные группы домена в глобальные и универсальные группы. Вам нужно будет изучить все доводы за и против использования различных типов групп, особенно если вы работаете в многодоменном лесу. Каждый тип имеет свои достоинства и недостатки.
  • Тщательно изучите вопросы, связанные с управлением жизненным циклом групп. Это известная проблема в сетях с использованием AD. Нередко возникает необходимость быстро создать группу, срочно добавить в нее пользователей и сформировать ресурсы для новых проектов. Однако реже требуется с такой же степенью срочности удалять пользователей из групп, группы — из списков управления доступом серверов и фактически удалять группы, если эти действия не продиктованы соображениями безопасности данных или четко сформулированным планом жизненного цикла. Такие программы, как разработанный корпорацией Imanami продукт GroupID, специально предназначены для управления жизненным циклом групп; проблема в данном случае состоит в том, чтобы заставить администраторов ИТ отвечать за то, что является важным, но не срочным.
  • Ограничьте число администраторов, работающих с учетными записями. Чем меньше сотрудников имеют санкцию на создание групп, тем меньше вероятность того, что групп у вас образуется слишком много.

Насколько реальна опасность?

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

Шон Дьюби (sdeuby@windowsitpro.com) — старший аналитик в компании Platform Vision с 25-летним стажем работы в области корпоративных информационных систем. Внештатный редактор Windows IT Pro, имеет звание MVP