Трудно поверить, но с тех пор, как на свет появилась служба Active Directory, прошло уже целых десять лет. Во времена Windows NT она была поистине революционным продуктом и с годами становилась все лучше. Однако и эта служба не идеальна, в ней есть свои недоработки. В настоящей статье я расскажу о некоторых досадных недостатках AD, а также о мерах, принимаемых специалистами Microsoft для их устранения. Кроме того, я предложу обходные пути для преодоления затруднений, над которыми все еще бьются обитатели кампуса Ред-Уэст корпорации Microsoft.

AD и управление контроллерами доменов

Одна из проблем, возникших с выпуском системы Windows 2000 Server, — это отсутствие разделения между администрированием домена AD или леса, с одной стороны, и администрированием поддерживающих его контроллеров доменов (DC) — с другой. Иными словами, чтобы получить полный набор полномочий для администрирования контроллеров доменов, пользователь должен иметь полномочия администратора домена. Позиция Microsoft состоит в следующем: если вы имеете права доступа к контроллеру домена на уровне администратора, вам должны быть предоставлены и права администратора домена, потому что упомянутый доступ позволяет вам «расколоть» DC и повысить уровень своих полномочий. Операторы компьютеров имеют физический доступ к контроллерам доменов, а это значит, что теоретически они могут получить доступ, когда захотят. Рассуждения противников этой точки зрения имеют сугубо практический характер. Работа оператора компьютера состоит в том, чтобы осуществлять административное управление серверами в центре обработки данных, и для DC не следует делать исключения. С практической точки зрения нецелесообразно выступать за то, чтобы оператору предоставлялись полномочия администратора системы только потому, что он имеет к ней физический доступ. В соответствии с базовыми принципами обеспечения безопасности число администраторов домена необходимо сводить к минимуму, что, соответственно, исключает из их числа многих операторов вычислительных систем.

Обойти это препятствие можно двумя способами. Первый состоит в том, чтобы предоставлять группам безопасности операторов вычислительных систем только те права, которые необходимы для выполнения их производственных обязанностей. Действия, которые невозможно делегировать (то есть действия, требующие административных полномочий, которые могут повлиять на работоспособность AD), должны выполнять администраторы доменов. В документе Microsoft «Best Practices for Delegating Active Directory Administration» (http://bit.ly/5ByrEy) подробно описывается план делегирования полномочий по управлению обслуживанием AD.

Второй способ — модернизировать систему до уровня Windows Server 2008 R2 и везде, где возможно, использовать контроллеры доменов с доступом только для чтения Read-Only Domain Controllers (RODC). RODC — это такой тип контроллера домена, на котором локально хранится копия AD с доступом только для чтения, а элементы паролей не хранятся вообще. Не столь широко известна другая особенность RODC: на нем административные роли разделяются. В отличие от полноценных DC, административные задачи для RODC могут быть делегированы отдельным пользователям или группам без угрозы для безопасности всего леса. Безопасное предоставление административных прав для работы с контроллером RODC возможно потому, что, в отличие от полноценных DC, контроллеры RODC не являются доверенными контроллерами с точки зрения остальных систем леса. Изменения, внесенные в RODC, в лесу не реплицируются; контроллеры «только для чтения» лишь получают изменения, внесенные в другие контроллеры. Пароли никогда не хранятся в системах RODC, за исключением тех случаев, когда администратор явно соответствующим образом задает политику репликации паролей на одном из объектов «компьютер» контроллера RODC. В итоге предоставление оператору RODC прав администратора не влечет за собой угрозу безопасности леса. Процесс активации функции разделения ролей на контроллерах RODC описывается в статье TechNet «Administrator Role Separation» (http://bit.ly/4QlfFs); из статьи «Read-Only Domain Controller Planning and Deployment Guide» (http://bit.ly/2lGULi) можно почерпнуть сведения о том, как размещать контроллеры RODC на предприятии. Более подробная информация о контроллерах RODC Server 2008 приведена в статье «Fortify Remote-Server Security», www.windowsitpro.com.

Пароли учетных записей служб

Проблема паролей учетных записей служб возникла раньше многих других «заморочек» службы AD. Учетная запись службы — это пользовательский объект, выделенный для запуска серверной службы, например Microsoft SQL Server. Как и в случае с любым другим пользовательским объектом, пароль необходимо регулярно менять: таково требование безопасности. Так вот, проблема в том, что пароли учетных записей служб жестко встроены в свойства соответствующих служб. Если изменить пароль учетной записи, но не внести при этом необходимых изменений по месту расположения службы и не перезапустить ее, возникнут проблемы с повторным запуском службы аутентификации. Но ведь мало кто из ИТ-специалистов готов прерывать работу производственного приложения только для того, чтобы изменить пароль. Эта трудность возникла с появлением Windows NT, то есть более 15 лет назад.

Система Server 2008 R2, оснащенная функцией Managed Service Accounts (MSA) — «управляемые учетные записи служб» — решает проблему раз и навсегда. MSA — это особые учетные записи, которые автоматически обновляют свои пароли и одновременно изменяют пароли соответствующих служб на управляемом компьютере. Более подробные сведения об учетных записях MSA и об их использовании можно найти в статье «Use MSAs to Ease the Pain of Administering Service Accounts», www.windowsitpro.com. Удобно, что для использования учетных записей MSA не нужны контроллеры доменов Server 2008 R2; от администратора требуется только выполнение команды adprep/forestprep для обновления схемы леса до уровня Server 2008 R2. Однако для использования MSA необходимо, чтобы на сервере работала система Server 2008 R2.

Бюджет ИТ-подразделений в наши дни обычно не слишком велик, но решение этой проблемы имеет большое значение с точки зрения безопасности. Мало того, речь идет о прекрасном аргументе в пользу модернизации до уровня Server 2008 R2.

Настройка подсетей сайта

Признаюсь, умение настраивать подсети IP никогда не входило в число моих достоинств. На уроках по сетям TCP/IP я откровенно скучал, а на задачи по настройке масок подсетей таким образом, чтобы они «один в один» подходили к диапазону IP-адресов для моего узла AD, я всегда тратил больше времени, чем остальные. Необъяснимым образом с появлением систем Server 2008 R2 и Server 2008 эта задача усложнилась: потребовалось вводить диапазон подсетей с помощью сетевых префиксов (таких, как 192.168.1.0/20). Я давно знал, что мне не дано быть сетевым инженером, но, в конце концов, обслуживание списка IP-подсетей, определяющих узел AD, — это один из стандартных навыков, без которого не обойтись ни одному администратору AD. К счастью, я обнаружил несколько сайтов с калькуляторами IP-подсетей, которые могут выполнять за меня всю черную работу.

Неплохо функционирует программа IP Subnet Mask Calculator, выложенная по адресу www.subnet-calculator.com. Если вам требуется бесплатно распространяемое приложение, которое можно загрузить на клиентскую систему, испытайте разработанный компанией WildPackets продукт IP Subnet Calculator. Он размещен по адресу www.wildpackets.com/resources/free_utilities/ipsubnetcalc. Эти приложения дают возможность выполнять сценарии «что, если» и выбирать настраиваемую маску подсети или сетевой префикс, покрывающий требуемый диапазон IP-адресов, и ничего более.

Воссоздание контроллера домена AD

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

Однако, если вы уверены, что операционная система контроллера функционирует нормально и корень проблемы — в AD, можно обойтись без неприятной процедуры восстановления, воспользовавшись командой dcpromo/forceremove. Это малоизвестное средство удаляет с сервера AD, но оставляет без изменений серверную операционную систему. Вам придется выполнить очистку метаданных, но время простоя будет сокращено, поскольку отпадет необходимость в переустановке операционной системы. По завершении принудительного удаления и очистки метаданных вы сможете вновь повысить статус сервера до уровня DC.

Очистка метаданных

Чтобы как можно быстрее вернуть в строй отказавший DC, очистку метаданных следует выполнять в процессе принудительного удаления и перезагрузки. Очистка метаданных — это осуществляемый вручную процесс удаления из AD сведений об отказавшем DC (то есть его метаданных), которые в противном случае были бы автоматически удалены процессом dcpromo. Сама по себе очистка метаданных — процедура весьма нудная; администратору приходится работать с использованием команд Ntdsutil на контроллере домена, причем команды эти отнюдь не очевидны. К счастью, группой инженеров Microsoft был написан сценарий, удаляющий метаданные AD DC, которые остаются после выполнения команды dcpromo/forceremoval. Этот сценарий с графическим интерфейсом Metadata Cleanup Utility можно загрузить с сайта TechNet Script Center Repository по адресу http://bit.ly/byByot. Сценарий несовместим с системой Server 2008 R2, однако в том и нет нужды.

С выпуском новейших версий Windows Server выполнять процесс очистки метаданных стало проще. Начиная с версии Server 2008 для этого достаточно одного щелчка мышью. Запустите оснастку Active Directory Sites and Services консоли MMC (Microsoft Management Console), а именно dssite.msc, откройте сайт, к которому относится вышедший из строя DC (по умолчанию принимается сайт с логическим именем Default-First-Site-Name), откройте контейнер Servers, выберите контроллер домена, который следует убрать, и удалите его, щелкнув правой кнопкой мыши. В средах Windows 2000 и Windows Server 2003, а также при использовании различных пакетов обновлений Windows 2003 в процессе удаления компьютерного объекта DC отображаются предупреждения о том, что выполнение очистки метаданных по-прежнему необходимо. В системах Server 2008 R2 и Server 2008 процесс удаления влечет за собой очистку метаданных. И хотя сама по себе эта функция не является достаточным основанием для модернизации, она, несомненно, дает пользователям дополнительные преимущества.

С обновлением или без

Как и всякий сложный программный продукт, служба AD не свободна от недостатков. Сотрудники подразделения Microsoft Directory Services знают обо всех затруднениях и работают над их устранением. Проблема заключается в том, как усовершенствовать службу и облегчить процесс ее эксплуатации, оставаясь при этом в границах проекта и обходясь без излишних затрат времени и ресурсов при внесении изменений. Новые функции не всегда можно реализовать на базе существующей операционной системы, поэтому в ряде случаев воспользоваться тем или иным решением можно только после модернизации системы. Но иногда, вооружившись необходимыми знаниями, мы можем решать проблемы AD с помощью «фланговых маневров».

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

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF