Active Directory 2008

Как уже не раз говорилось, Windows Server 2008 представляет собой принципиальное обновление серверной платформы, фактически сравнимое (по крайней мере, с точки зрения Microsoft) с появлением Windows NT. Соответственно, количество новинок в ОС просто огромно, при этом многие важные изменения коснулись и хорошо известных подсистем. В их числе и служба Active Directory (AD), которая является одной из наиболее востребованных, и потому неуклонно совершенствуется от релиза к релизу.

Прежде всего отметим, что Directory Services в Windows Server 2008 теперь состоит, по сути, из двух основных компонентов:

• AD DS (Active Directory Domain Services) – непосредственно служба каталога со всеми соответствующими функциями (авторизация, аутентификация и т. д.);
• AD LDS (Active Directory Lightweight Domain Services), ранее носивший имя ADAM, – обеспечивает возможность развернуть LDAP-каталог для приложений, которые не нуждаются в полновесной инфраструктуре AD либо требуют определенной изоляции.

В дальнейшем речь пойдет именно о первом, тем более что изменений и доработок в нем весьма много – мы приведем список лишь наиболее существенных и ниже рассмотрим их подробнее:

• обновление схемы AD;
• расширение политик паролей;
• появление роли RODC (Read Only Domain Controller);
• совершенствование аудита;
• возможность перезапуска AD DS;
• инструмент Database Mounting Tool.

Изменения в схеме AD

В схему добавлено большое количество объектов и атрибутов, которые существенно расширяют возможности каталога. Исчерпывающую информацию по данному вопросу можно найти на сайте Microsoft (например, msdn2.microsoft.com/en-us/library/ms675085.aspx), мы же рассмотрим только такой класс объектов, как PSO (Password Settings Objects).

Расположение контейнера Password Settings Container в дереве AD

Традиционно, начиная еще с Windows NT, в рамках домена (в том числе и AD) администратор мог настроить лишь одну политику паролей, и она распространялась на все учетные записи. Поэтому для реализации нескольких политик приходилось прибегать к различным ухищрениям – к примеру, создавать дочерние домены с собственными политиками и разносить пользователей по ним. Естественно, это создавало дополнительные сложности при администрировании инфраструктуры предприятия. Наконец, в Windows Server 2008 данное ограничение снято, для чего и реализован новый контейнер Password Service Container (PSC), расширяющий стандартную схему AD. Внутри него администратор может создавать объекты политики паролей PSO (Password Settings Objects), и для каждого из них устанавливать значения 9 обязательных атрибутов, которые сами по себе не изменились со времен Windows Server 2003.

Отметим, что Password Settings Objects не являются расширением групповых политик, поэтому при работе с ними имеется определенная специфика. Начнем, пожалуй, с того, что объекты PSO применяются только к отдельным пользователям или глобальным группам, но не к организационным единицам. Технически их можно привязать и к универсальным, и локальным группам, но функционировать они будут лишь на глобальных. В связи с этим Microsoft рекомендует создавать необходимое количество последних, распределять по ним сотрудников и назначать каждой соответствующий PSO. При этом к одному пользователю могут быть привязаны несколько таких объектов, поэтому дополнительно введен специальный атрибут msDS-PasswordSettingsPrecedence (целого типа), с помощью которого указывается приоритет PSO (тем выше, чем меньше значение).

Таким образом, в отличие от групповых политик, тут не происходит слияния настроек, а в силу вступает только один объект, имеющий наибольший приоритет. Если же с пользователем не связан ни один PSO, то применяется Default Domain Policies. Чтобы помочь администраторам разобраться в этом механизме, для AD предлагается специальная надстройка (Result Set Of Policy), показывающая, основываясь на атрибуте msDS-ResultantPro, какие именно политики будут задействованы на самом деле.

Впрочем, и сам процесс создания PSO является далеко не тривиальной задачей. Для этого существуют несколько способов, один из них, к примеру, предполагает создание специального файла pso.ldf, указывающего значения тех самых 9 обязательных атрибутов, а также имя пользователя, и последующее применение к нему утилиты LDIFDE. Также можно воспользоваться MMC-оснасткой ADSI Edit (она идет в базовой комплектации и в отличие от Windows Server 2003 не требует установки Support Tools). Процедура значительно проще, хотя и предполагает знания типов переменных и значений, которые они могут принимать.

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

RODC

Как известно, в Windows NT было два типа контроллеров домена, а именно: PDC (Primary Domain Controller) и BDC (Backup Domain Controller). Если в первом допускалось производить любые изменения с каталогом, то второй был доступен только для чтения. В Windows Server 2000/2003 роль BDC исчезла как таковая, и все контроллеры домена по определению являлись PDC. Однако в Windows Server 2008 появился, по сути, аналог BDC, хотя и под новым названием – RODC (Read Only Domain Controller). Какие же цели преследовала Microsoft, возвращаясь к старым идеям? Ответ весьма прост: повышение безопасности домена и уменьшение репликационного трафика между сайтами. Для этого RODC, естественно, наделен некоторыми специфическими особенностями:

• копия каталога доступна только для чтения;
• то же касается и службы DNS, если она интегрирована с AD;
• допускается только односторонняя репликация;
• производится кэширование параметров определенных учетных записей;
• обеспечивается разделение административных прав.

Данная роль назначается в процессе установки AD. БД RODC содержит в себе все три раздела AD (схему, конфигурацию и доменную информацию), поддерживается и Global Catalog, но также только в режиме чтения. Таким образом, RODC хранит те же объекты и атрибуты, что и полнофункциональный контроллер домена, за исключением паролей пользователей (по умолчанию они не реплицируются). Однако существуют различные приложения, использующие AD для размещения своей информации (паролей, учетных данных и т. д.), которая понадобиться и на RODC. Чтобы реплицировать подобные объекты из основного каталога, достаточно в свойствах их класса установить значение 1 для флага shemaFlagEX.

PSO можно создавать и в графическом режиме с помощью ADSI Edit

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

Одностороння репликация подразумевает, что RODC может только принимать и обрабатывать информацию, но не пересылать свои (в копию входят база данных AD и папка SYSVOL). Полная репликация возможна только между контроллерами, работающими на Windows Server 2008. Это не значит, что RODC нельзя использовать совместно с основным контроллером под управлением Windows Server 2003, однако при этом корректно синхронизируется только схема и конфигурация, но не доменная информация.

Имеется и ряд других ограничений, обусловленных невозможностью внесения изменений в базу данных, в частности, в RODC недоступна роль Operation Master и работа в режиме bridge head (т. е. сервера, отвечающего за репликацию данных между сайтами). Для аутентификации пользователей смарт-карт также потребуется дополнительная настройка. Дело в том, что по умолчанию RODC не выдает цифровые сертификаты, поэтому сначала необходимо на Certificate Authority в свойствах шаблона наделить соответствующим правом группу ERODC (в которую как раз и входят все RODC).

Работа с паролями вообще осуществляется особым образом. По умолчанию RODC не хранит хэши паролей, в результате чего не может самостоятельно выполнить аутентификацию пользователя (так как нельзя проверить пароль). Поэтому он перенаправляет запрос на основной контроллер домена, располагающий, естественно, хэшами. Тот обрабатывает запрос, генерирует билет Kerberos и возвращает его RODC. Все это порождает довольно большой трафик, что особенно критично для медленных каналов между удаленными филиалами. Более того, при нарушении коммуникаций между RODC и основным контроллером аутентификация становится попросту невозможна.

Роль RODC назначается в процессе начальной конфигурации AD

Именно поэтому в RODC была добавлена функция кэширования хэшей паролей для определенных учетных записей (к примеру, только для пользователей, работающих в данном филиале). Кроме того, для повышения безопасности даже запись Kerberos (KRBTGT) на каждом RODC имеет свою уникальную структуру, в отличие от полнофункциональных контроллеров, где она одна для всех. Таким образом, в пределах RODC риску подвергаются только те пароли, для которых было настроено кэширование.

В большинстве филиалов крупных компаний нет возможности содержать квалифицированного IT-специалиста, обслуживающего локальный контроллер домена, а предоставлять такие полномочия пользователю, пусть даже весьма квалифицированному, – шаг рискованный. Поэтому RODC позволяет наделить избранные учетные записи (не из группы Domain Admins) правами, достаточными для обслуживания сервера (установки драйверов, выполнения резервного копирования, управления файловой системой и разделяемыми ресурсами), но не для вмешательства в работу AD.

Конечно, жизнь покажет, насколько оправдано появление роли RODC, но, похоже, что в инфраструктуре крупных распределенных организаций он займет далеко не последнее место.

Расширенный аудит

Доработки в области аудита коснулись непосредственно объектов AD (Directory Service Access). Раньше можно было отследить лишь сам факт изменения объекта и пользователя, выполнившего данные действия, но не характер действий или имя скорректированного параметра, что, естественно, доставляло массу трудностей, например, при восстановлении исходных значений. Теперь же в Windows Server 2008 контролируются любые операции с объектами AD (их создание, изменение, восстановление, перенос) и при этом предоставляются все необходимые сведения (в том числе, исходные и новые значения) – для этого в журнале Security появились новые типы событий (см. табл.). Таким образом можно легко устранять последствия некорректного вмешательства в каталог, не прибегая к таким трудоемким и кардинальным средствам, как, скажем, восстановление AD.

Перезапуск AD DS

В RODC также можно включить кэширование паролей

Процесс восстановления каталога в Windows Server 2003 весьма сложен и требует остановки сервера. Нужно запустить перезагрузку системы, при старте нажать F8 и выбрать режим Directory Services Restore Mode – в результате сервер будет загружен с остановленной службой DS. После этого можно произвести восстановление из резервной копии и еще раз выполнить перезагрузку. Само наличие такой возможности – безусловный плюс, но что делать, если на этом же сервере расположен файловый ресурс или бизнес-приложение, простой которого крайне нежелателен (такая ситуация, кстати, типична для украинских компаний). Других вариантов, однако, не было. В отличие от этого Windows Server 2008 позволяет останавливать и запускать Directory Services без перезагрузки всего сервера (как обычную службу). Это пригодится не только при восстановлении каталога, но и при проведении дефрагментации, установки обновлений и т. д.

Database Mounting Tool

В Windows Server 2008 появилась возможность перезапуска AD DS

Представим ситуацию, что в каталоге в неизвестное время был удален какой-либо объект (группа пользователей), а мы обладаем набором резервных копий за неделю, выполненных с периодичностью в 1 день. Чтобы отыскать нужную информацию, нам пришлось бы поочередно восстанавливать каждую из них, к примеру, на какой-либо альтернативной системе. А после выполнить еще одну процедуру восстановления, теперь уже в реальный каталог. Понятно, что это весьма длительный и трудоемкий процесс.

Опять же, раньше другого способа изучить содержимое резервной копии попросту не было. А в составе Windows Server 2008 появилась утилита Database Mounting Tool, которая умеет монтировать базу каталога и тем самым обеспечивает ее просмотр и изучение. Очевидно, что она способна значительно упростить решение описанной выше задачи, экономя время поиска и восстановления необходимого атрибута или объекта. К сожалению, у нее есть один недостаток, связанный с характером использования. Дело в том, что сама по себе Database Mounting Tool не предоставляет графических средств просмотра (хотя соответствующая MMC-оснастка смотрелась бы весьма логично), поэтому для ознакомления с содержимым базы придется применить еще одну утилиту LDP, которая не совсем удобна.

В заключение хочется еще раз отметить, что службы AD в Windows Server 2008 коснулись многочисленные изменения, в первую очередь, направленные на облегчение жизни системным администраторам. Однако в конечном итоге они должны привести к лучшей управляемости и повышенной безопасности, потребность в которых день ото дня становится только острее.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365