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

Я регулярно бываю на ежегодных саммитах Microsoft MVP, в ходе которых обладатели почетного звания «наиболее ценного специалиста», присваиваемого за высокий профессиональный уровень в различных областях, общаются с разработчиками и докладчиками. В секции служб каталогов редко можно услышать о радикальных изменениях. Обычно интерес вызывает выпуск новой версии операционной системы и то, насколько «большим» он является. К нынешнему выпуску применимы оба определения: и «новый», и «большой», что означает необходимость серьезного анализа. Рассмотрим основные изменения в системе удостоверений и безопасности, внесенные в Windows Server 2012.

Надо сказать, что эти изменения квалифицируются как эволюционные, а не революционные. Они лишь расширяют то, что составляет надежную основу Active Directory (AD). Натан Маггли из Microsoft однажды заметил, что внесение изменений в Active Directory похоже на приготовление пиццы для миллиона людей: каждому нужно что-то свое. Естественно, никто не хочет «раскачивать лодку», когда затронуты интересы 75 % мировых компаний. Однако эволюционные изменения нужны, поскольку они могут обозначать направление будущего развития продукта. В системе удостоверений и безопасности Windows Server 8 эти изменения затрагивают управление данными, AD и виртуализацию.

Управление данными

Прежде чем перейти к описанию изменений в системе удостоверений Windows Server 8, вспомним технологию, добавленную в Windows Server 2008 R2 – инфраструктуру классификации файлов File Classification Infrastructure (FCI). Эта новая функция прошла мимо меня и, возможно, мимо вас, поскольку относится к файловой системе, а не к системе удостоверений. Между FCI и удостоверениями существует связь, но вначале поясним, что такое FCI.

FCI позволяет определять свойства классификации файлов для файловых серверов, автоматически классифицировать файлы в соответствии с папкой, где они находятся, или же их содержимым, осуществлять управление файлами, например устанавливать срок, в течение которого возможен доступ к файлу, задавать стандартные команды, основанные на классификации файлов, а также генерировать отчеты, показывающие распределение свойства классификации на файловом сервере. С помощью FCI конечный пользователь (владелец контента) может вручную классифицировать файл, либо бизнес-приложения могут программным способом устанавливать свойства классификации файлов. Кроме того, FCI позволяет осуществлять поиск по ключевым словам или комбинациям символов, таким как номера социального страхования, и автоматически классифицировать файл как конфиденциальный или содержащий персональные данные.

Что это нам дает? С помощью FCI администратор может, например, перемещать данные из дорогостоящих онлайн-хранилищ в менее дорогостоящие и с меньшей скоростью доступа к данным, в зависимости от классификации файла и в соответствии с определяемой политикой. Можно устанавливать для файлов срок, по истечении которого они становятся недоступными. Упражняться с настройками FCI можно с помощью диспетчера ресурсов файлового сервера File Server Resource Manager (FSRM), для чего необходимо установить эту службу роли, а затем запустить ее из папки Administrative Tools. Это та же утилита, что позволяет управлять квотами, блокировкой файлов и отчетами хранилищ. Впрочем, в данном случае для нас важно то, что FCI является одним из краеугольных камней крупного компонента системы удостоверений и безопасности Windows Server 8, а именно, службы Dynamic Access Control (DAC).

DAC – одна из самых мощных новых функций Server 8, о которой уже говорилось в статье «Встречаем Windows Server 8», опубликованной в Windows IT Pro/RE № 1 за 2012 год. На самом общем уровне она связана с управлением информацией, в частности, с классификацией данных на файловом сервере, получением высокой степени контроля над данными, а также способностью продемонстрировать (например, в ходе аудиторской проверки) наличие такого контроля. В современной ИТ-инфраструктуре в этом есть насущная потребность, учитывая взрывное увеличение объемов данных, рост внешних угроз и тех затрат, которые несут компании при появлении брешей в системе защиты. FCI – это элемент DAC, обеспечивающий механизм классификации и тегирования файлов, от которого зависит применение политик DAC.

Active Directory

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

Реализация более высокой степени контроля доступа на файловых серверах и на всех ресурсах, поддерживающих списки контроля доступа access control lists (ACL) в будущих версиях операционной системы требует от AD поддержки утверждений. Напомним, что утверждение является одним из аспектов проверки подлинности и несет информацию (например, электронный адрес), которую доверенный источник (например, локальный удостоверяющий центр Certificate Authority (CA)) передает об объекте (например, об учетной записи). Утверждения уже стали общепринятым понятием в сфере «облачных» удостоверений и являются основным компонентом технологии федерации, позволяющей безопасно предоставлять локальные удостоверения в ведение «облачных» служб. Однако до Server 2012 в AD не существовало понятия утверждений, и для преобразования атрибутов AD в утверждения приходилось пользоваться службами Active Directory Federation Services (AD FS). Утверждения использовались главным образом внешними службами, поскольку традиционные корпоративные приложения их не понимали. Теперь ситуация меняется, и AD переходит к принятию утверждений. Это изменение чрезвычайно важно, и каждый администратор AD должен понимать, что удостоверения на основе утверждений станут частью его будущей работы.

В части изменений в Server 2012, связанных исключительно с AD, самым большим достижением стало упрощение развертывания AD. Любой, кто бывал на форумах, посвященных AD, знает, что вопросы, касающиеся Adprep, Dcpromo, дублирования и виртуализации контроллеров домена DC, а также решений по развертыванию DNS, обсуждаются очень часто. Эти изменения определенно попадают в категорию «эволюционных», поскольку являются развитием существующих функций AD.

Обновление и повышение статуса DC существенно упрощены. Функции Dcpromo теперь выполняет мастер Active Directory Domain Services Configuration Wizard, полностью интегрированный в диспетчер Server Manager. Он прост в использовании и максимально облегчает работу по повышению статуса.

Мастер автоматизирует процессы Adprep /forestprep и /domainprep (хотя при желании можно запустить их вручную). Бывший главный консультант по AD Дин Уэллс, теперь входящий в группу Microsoft AD, заметил, что было ошибкой открывать процесс Adprep администраторам, так как лавина звонков в группу поддержки была неадекватна реальным проблемам. Повышение статуса предполагает тщательную проверку наличия необходимых условий перед развертыванием, поэтому в случае крупных проблем в среде AD процесс выполняться не будет. Кроме того, процесс имеет расширенные параметры IFM и полноценно реализуется при удаленном взаимодействии.

Виртуализация

Еще одним аспектом упрощения развертывания AD стало укрепление защиты виртуальных контроллеров домена, что также обеспечивает безопасность их клонирования. Восстановление виртуального контроллера домена из резервной копии образа или сделанного ранее моментального снимка порождало риск нарушения ссылочной целостности (возврат номера последовательного обновления USN) всей распределенной базы данных AD в домене или в лесу, потому что в отличие от стандартных процедур, восстановленный контроллер домена не содержал информации о том, что он был восстановлен. В Windows Server 2012 для доменных служб Active Directory (AD DS) введен уникальный 64-разрядный идентификатор VM-Gen ID (подобный GUID), ассоциированный с гипервизором. Назначение VM-Gen ID – выявлять экземпляры моментального снимка виртуальной машины и передавать их виртуальной машине. При таком уведомлении контроллер домена предпринимает защитные меры (например, отменяет пул идентификаторов записи (RID) и сбрасывает ID обращения) для предотвращения возврата USN.

Клонирование контроллера домена, которое эти «безопасные с точки зрения виртуализации» усовершенствования сделали реализуемым и поддерживаемым вариантом, открывает целый ряд потенциальных возможностей (см. врезку «7 шагов клонирования виртуального контроллера домена Windows Server 2012»). Оно позволяет свести к минимуму необходимость повышения статуса контроллера домена, поскольку в большинстве случаев можно будет ограничиться клонированием нового контроллера домена из текущего, что значительно проще и быстрее.

Клонирование DC также имеет огромные (но еще недостаточно оцененные) преимущества в сфере аварийного восстановления леса. В современной поддерживаемой конфигурации восстановление осуществляется из базового контроллера домена леса (по одному на домен) с последующим запуском Dcpromo на других контроллерах до тех пор, пока в среде не накопится достаточно DC для поддержки пользователей. Проблема в том, что процесс Dcpromo отнимает много времени даже при установке с носителя (IFM) или при развертывании по сети. «Падение леса» – кошмар для администратора, если не повод для поиска другой работы, и каждая секунда, потраченная на восстановление, стоит тысячи или миллионы долларов. Клонирование контроллеров домена позволит наделать клонов базовых DC леса, что значительно быстрее, чем установка с IFM или развертывание по сети. Потенциальная экономия затрат только в этой сфере уже может стать достаточным обоснованием необходимости перехода на Server 2012 AD.

Заметные усовершенствования

Группа службы каталогов разместила в Интернете (blogs.technet.com/b/askds) новые рекомендации по диагностике проблем и тестированию технологий AD в Windows Server 2012. Эти изменения означают, что расширение среды AD станет проще не только для «облачных» информационных центров, но и для предприятий малого и среднего бизнеса, не имеющих своих специалистов по AD. Как уже упоминалось, изменения AD в Server 2012 не являются революционными, что отнюдь не умаляет их ценности. В этой области революционных изменений уже не требуется. Нужны усовершенствования, и разработчики AD их реализовали.

7 шагов клонирования виртуального контроллера домена Windows Server 2012

Клонирование (создание копии) виртуальной машины является большим преимуществом виртуализации, но при использовании предыдущих версий Windows Server клонирование контроллера домена (DC) Active Directory (AD) было небезопасным из-за распределенного характера AD. С выходом Windows Server 2012 ситуация изменилась, и теперь клонировать DC стало значительно проще. Ниже описано, как создать копию DC Server 2012, которую можно использовать снова и снова.

1.Разрешите виртуальному DC (VDC) клонирование, для чего добавьте его в группу безопасности «Клонируемые контроллеры домена». Это можно сделать с помощью любого средства управления AD, например оснастки Active Directory ADAC или Active Directory Users and Computers (ADUC), либо команды PowerShell Add-ADGroupMember.

2. С помощью команды Get-ADDCCloningExcludedApplicationList составьте список программ и служб, работающих на клонируемом VDC, для которых процесс может оказаться небезопасным.

3. Изучите список и добавьте те программы и службы, клонирование которых, как вы считаете, будет успешным (обратитесь к производителю либо проведите собственное тестирование), в файл CustomDCCloneAllowList.xml. Эта часть процесса еще раз подтверждает, что на DC должно функционировать минимальное число приложений и служб. Мне неизвестны какие-либо ограничения, препятствующие клонированию системы, реализованной в режиме Server Core или с минимальным интерфейсом сервера (MinShell).

4. Запустите команду New-ADDCCloneConfigFile на клонируемом VDC. Эта команда позволяет задать новые параметры клонируемого VDC, в частности, имя, IP-адрес, маску подсети, DNS-сервер и имя сайта AD, на котором он будет развернут.

5. Выключите исходный VDC и экспортируйте его (и, конечно, перезапустите узел, если он должен быть в работающем состоянии).

6. Импортируйте созданную копию (клон) на узел назначения и запустите ее.

7. В статье Microsoft «Виртуализация доменных служб Active Directory (AD DS)» (http://technet.microsoft.com/en-us/library/hh831734.aspx#virtualized_dc_cloning) подробно описан процесс клонирования и необходимые условия для его выполнения. Поскольку всякий раз, когда возникает необходимость клонирования, на исходном VDC приходится запускать команду New-ADDCCloneConfigFile, затем выключать его и экспортировать, для больших информационных центров, где клонирование выполняется часто, может оказаться удобным разместить исходный VDC на собственном сайте без пользовательских подсетей. В этом случае внезапное отключение VDC никак не отразится на ходе рабочего процесса.