До начала встречи остается пять минут, и тут выясняется, что директор не может подключиться к презентации на корпоративном хранилище SAN. Вы пытаетесь просмотреть его учетную запись, чтобы проверить наличие необходимых разрешений, и видите, что учетной записи нет вообще! Проверяете регистрационный журнал изменений и понимаете, в чем дело: младший администратор удалил учетную запись Стива Джонсона, который недавно вышел на пенсию. Хорошо, что обнаружилась причина — ошибочное удаление учетной записи. Вас охватывает паника. Однако директор — опытный докладчик и умело заполняет паузу, пока вы вводите его пользовательскую учетную запись и пароль и добавляете его ко всем группам в других доменах. Все обошлось, директор получает доступ к презентации и своим материалам. К счастью он понимает, что ошибки бывают. Однако не хотелось бы, чтобы такое случалось!

Большинство администраторов оказывались в подобных ситуациях, когда случайно уничтожались или удалялись пользователи из групп или пользователей с разрешенным доступом. Можно купить дорогие утилиты резервирования AD или установить сложные сценарии. Однако хорошо было бы вообще не попадать в подобное положение.

Давайте выясним, как защитить объекты AD от ошибок администраторов. Вот один из способов решения этой задачи: администраторы должны проверять изменения, вносимые другими администраторами, до их реализации. Можно воспользоваться инструментами независимых поставщиков для автоматизации изменений. Существует еще одно малоизвестное решение — выборочная аутентификация (selective authentication), введенная в Windows Server 2003, при внешних доверительных отношениях.

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

Рассмотрим, как устанавливать среду AD для аутентификации.

  1. В рабочем лесу AD нужно создать промежуточный сайт, который содержит один контроллер домена (DC) без ассоциированных подсетей. Установите строгий график репликации, по которому вы разрешаете репликацию на определенное время или считаете необходимым запускать всю репликацию вручную. Выключение всей репликации по графику по соединению сайта приведет к ошибке на других DC. Это ограничение репликации контролируется графиком соединения сайта.
  2. Установите второй лес (известный также под именем Admin Forest), который содержит два или больше контроллеров домена для обеспечения дублирования. Замените все учетные записи администратора на те, которые нужны для подтверждения изменений в этом лесу.
  3. Установите внешние доверительные отношения между этими двумя лесами. Хотя доверительные отношения устанавливаются с имеющимся доменом или лесом, они должны быть установлены как однонаправленные отношения доверия, где исходящий или доверительный домен является административным доменом, а доверяющая сторона является рабочим сайтом AD. Вместо метода аутентификации по умолчанию выберите метод доверительной аутентификации.
  4. Установите разрешение на выполнение аутентификации. Теперь у нас есть одна группа административных учетных записей в Admin Forest, которая может устанавливать отношения с производственным лесом, но которую нельзя аутентифицировать для выделения в нем ресурсов. Поэтому следует установить разрешение Allowed to Authenticate («разрешить аутентификацию») для группы администраторов на контроллере домена в промежуточном сайте.
  5. Предоставьте права. Выполните стандартную процедуру делегирования для предоставления прав тем администраторам, которым это нужно для работы (добавления или удаления объектов, изменения свойств DNS или создания объектов групповой политики GPO).

Выборочная аутентификация вместе с разрешением Allowed to Authenticate на одном только DC предусматривает выполнение всех изменений только с этой системы. С данной настройкой администраторы могут выполнять свою работу, а ошибки ограничиваются только одним DC на сайте, на котором не осуществляется аутентификация других пользователей. Все изменения остаются локальными до тех пор, пока не будут разрешены. Если график репликации устанавливается вручную (нет запланированных заданий по репликации), то все изменения не распространяются до их специального одобрения и развертывания, которое производится вручную.

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

Как проверяющий администратор контролирует изменения? В более ранних версиях Windows и 2003 проще всего было включить параметр Audit DS Changes (проверять изменения DS) в политике аудита DC. При этом все изменения отражались на записываемом DC в регистрационном журнале безопасности, а администратор должен был только просмотреть регистрационный журнал и изучать события с изменениями, которые произошли с момента последней репликации.

В Windows Server 2008 реализованы более удобные инструменты для просмотра изменений в службе каталога, например Dsmain. С помощью этого инструмента можно установить базу данных LDAP, которая создается как резервная копия (или с помощью утилиты Ntdsutil). Затем можно использовать сценарий для сравнения всех объектов между автономной резервной копией LDAP и рабочим лесом промежуточного сайта, что позволит увидеть все изменения до их реализации. В Windows Server 2008 также усовершенствована проверка изменений, можно получить больше информации об изменениях, а также создать специальные представления, чтобы видеть только измененные объекты.

Инструменты для проверки от независимых разработчиков позволяют в реальном времени отбирать изменения и сравнивать различные базы данных на разных DC, что упрощает получение информации о сделанных изменениях.

При доверительной аутентификации все происходило бы по-другому. Младший администратор при удалении учетной записи Стива Джонсона регистрировался бы на консоли управления MMC Active Directory Users and Computers в Admin Forest со своей учетной записью, которая также была бы в Admin Forest. Он перешел бы в рабочий лес и попытался подключиться к DC. Поскольку во внешнем доверительном отношении используется выборочная аутентификация, он может подключиться только к промежуточному DC — все другие DC выдадут ему сообщение о запрете доступа. Он ищет Steve Joh* и случайно удаляет учетную запись Стива Йохансона на промежуточном DC. Да, ошибка произошла, но она локализована только на промежуточном DC.

Проверяющий администратор заходит в рабочий лес и просматривает изменения на промежуточном DC. Он обращает внимание, что учетная запись Стива Йохансона удалена. Не выполняя репликацию изменения на другой сайт и не разрешая его распространение в лесу, он обсуждает проблему с младшим администратором. В результате его действий доступ к ресурсам обеспечен, влияние ошибки нейтрализуется.

Хочу сделать несколько замечаний на случай применения этого решения.

  • Вероятность ошибочного изменения DS, влияющего на рабочую среду, уменьшается, но не исключается. Проверяющий администратор может не заметить ошибку, и неверное изменение может распространиться. При проверке также можно пропустить ошибку.
  • Учетные записи администратора домена и предприятия все еще остаются в рабочем лесу, и внести изменения можно с их помощью. Поэтому в случае необходимости администраторы могли бы обмануть систему и распространить изменения на все DC в рабочем лесу, не реализуя их на промежуточном DC.

Хотя вероятность ошибки существует, все же потенциальные преимущества этого решения не вызывают сомнений. Помимо очевидного преимущества (уменьшается вероятность того, что ошибочное изменение повлияет на рабочую среду), есть и другие плюсы:

  • существует непосредственный способ проверки и получения отчета об изменениях наследованных объектов (особенно если используется Server 2008), поскольку каждое изменение происходит на одном контроллере домена;
  • повышается защита от рисков компрометации учетной записи. Если учетная запись администратора скомпрометирована, риск ограничивается контроллером промежуточного домена. Поэтому надо будет очистить только один контроллер домена, при этом другие контроллеры из Admin Forest останутся чистыми. Таким образом, понадобится меньше усилий, чем в случае повторной реконструкции AD и всех ее данных.

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

Но это решение подходит для:

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

Использование доверительной аутентификации во внешних отношениях доверия дает эффективное решение защиты объектов AD от ошибок администратора. Данный способ потребует предварительной работы по настройке, зато затраты окупятся в дальнейшем. Это одна из самых простых технологий Microsoft, но выборочная аутентификация с успехом послужит средством повышения безопасности и убережет от многих неприятностей.

Джеймс Дей (james.day@nuaxis.com) — старший системный инженер в компании NuAxis. Специалист по внедрению Active Directory (AD). Имеет сертификаты MCITP: Enterprise Administrator и MCITP: Server Administrator for Windows Server 2008, а также CompTia Security +