Active directory на виртуальной машине

Установка нового леса Active Directory с помощью Azure CLI Install a new Active Directory forest using Azure CLI

AD DS могут выполняться на виртуальной машине Azure так же, как и во многих локальных экземплярах. AD DS can run on an Azure virtual machine (VM) in the same way it runs in many on-premises instances. В этой статье описывается развертывание нового леса AD DS на двух новых контроллерах домена в группе доступности Azure с помощью портал Azure и Azure CLI. This article walks you through deploying a new AD DS Forest, on two new domain controllers, in an Azure availability set using the Azure portal and Azure CLI. Многие клиенты считают это руководство полезным при создании лаборатории или подготовке к развертыванию контроллеров домена в Azure. Many customers find this guidance helpful when creating a lab or preparing to deploy domain controllers in Azure.

Компоненты Components

Неохваченные элементы Items that are not covered

Создание тестовой среды Build the test environment

Azure CLI используется для создания ресурсов Azure и управления ими из командной строки или с помощью скриптов. The Azure CLI is used to create and manage Azure resources from the command line or in scripts. В этом руководстве содержатся сведения об использовании Azure CLI для развертывания виртуальных машин под Windows Server 2019. This tutorial details using the Azure CLI to deploy virtual machines running Windows Server 2019. После завершения развертывания подключитесь к серверам и установите AD DS. Once deployment is complete, we connect to the servers and install AD DS.

Если у вас еще нет подписки Azure, создайте бесплатную учетную запись Azure, прежде чем начинать работу. If you don’t have an Azure subscription, create a free account before you begin.

Использование Azure CLI Using Azure CLI

Следующий сценарий автоматизирует процесс создания двух виртуальных машин Windows Server 2019 с целью создания контроллеров домена для нового Active Directory леса в Azure. The following script automates the process of building two Windows Server 2019 VMs, for the purpose of building domain controllers for a new Active Directory Forest in Azure. Администратор может изменить приведенные ниже переменные в соответствии со своими потребностями, а затем завершить их как одну операцию. An administrator can modify the variables below to suit their needs, then complete, as one operation. Скрипт создает необходимую группу ресурсов, группу безопасности сети и правило трафика для удаленный рабочий стол, виртуальной сети и подсети, а также группы доступности. The script creates the necessary resource group, network security group with a traffic rule for Remote Desktop, virtual network and subnet, and availability group. Затем все виртуальные машины создаются с использованием диска данных объемом 20 ГБ с отключенным кэшированием для AD DS для установки. The VMs are each then built with a 20 GB data disk with caching disabled for AD DS to be installed to.

DNS и Active Directory DNS and Active Directory

Если виртуальные машины Azure, созданные в рамках этого процесса, будут расширением существующей локальной инфраструктуры Active Directory, перед развертыванием необходимо изменить параметры DNS в виртуальной сети, чтобы они включали локальные DNS-серверы. If the Azure virtual machines created as part of this process will be an extension of an existing on-premises Active Directory infrastructure, the DNS settings on the virtual network must be changed to include your on-premises DNS servers before deployment. Этот шаг важен, чтобы позволить вновь созданным контроллерам домена в Azure Разрешать локальные ресурсы и выполнять репликацию. This step is important to allow the newly created Domain Controllers in Azure to resolve on-premises resources and allow for replication to occur. Дополнительные сведения о DNS, Azure и настройке параметров можно найти в разделе разрешение имен разделов, использующих собственный DNS-сервер. More information about DNS, Azure, and how to configure settings can be found in the section Name resolution that uses your own DNS server.

После повышения уровня новых контроллеров домена в Azure им необходимо назначить основной и дополнительный DNS-серверы для виртуальной сети, а все локальные DNS-серверы будут понижены до третьего и более поздних. After promoting the new domain controllers in Azure, they will need to be set to the primary and secondary DNS Servers for the virtual network, and any on-premises DNS Servers would be demoted to tertiary and beyond. Дополнительные сведения об изменении DNS-серверов можно найти в статье Создание, изменение и удаление виртуальной сети. More information on changing DNS Servers can be found in the article Create, change, or delete a virtual network.

Сведения о расширении локальной сети в Azure можно найти в статье Создание VPN-подключения типа “сеть — сеть”. Information about extending an on-premises network to Azure can be found in the article Creating a site-to-site VPN connection.

Настройка виртуальных машин и установка служб домен Active Directory Configure the VMs and install Active Directory Domain Services

После завершения выполнения скрипта перейдите к портал Azure, а затем — к виртуальным машинам. After the script completes, browse to the Azure portal, then Virtual machines.

Настройка первого контроллера домена Configure the first Domain Controller

Подключитесь к AZDC01 с помощью учетных данных, указанных в сценарии. Connect to AZDC01 using the credentials you provided in the script.

Проверка предварительных требований выдаст предупреждение о том, что физическому сетевому адаптеру не назначены статические IP-адреса, вы можете спокойно проигнорировать его, так как в виртуальной сети Azure назначены статические адреса. The Prerequisites Check will warn you that the physical network adapter does not have static IP address(es) assigned, you can safely ignore this as static IPs are assigned in the Azure virtual network.

Когда мастер завершит процесс установки, виртуальная машина перезагружается. When the wizard completes the install process, the VM reboots.

После завершения перезагрузки виртуальной машины Войдите в систему с использованием учетных данных, которые использовались ранее, но на этот раз как член созданного домена. When the VM has completed rebooting, log back in with the credentials used before, but this time as a member of the domain you created.

Первый вход в систему после повышения роли контроллера домена может занять больше времени, чем обычная, и это нормально. The first logon after promotion to a domain controller may take longer than normal and this is OK. Возьмите кружки в чай, кафе, воды или другие напитки по своему усмотрению. Grab a cup of tea, coffee, water, or other beverage of choice.

Настройка DNS Configure DNS

После повышения уровня первого сервера в Azure серверы должны быть установлены на основной и дополнительный DNS-серверы для виртуальной сети, а все локальные DNS-серверы будут понижены до третьего и более поздних. After promoting the first server in Azure, the servers will need to be set to the primary and secondary DNS Servers for the virtual network, and any on-premises DNS Servers would be demoted to tertiary and beyond. Дополнительные сведения об изменении DNS-серверов можно найти в статье Создание, изменение и удаление виртуальной сети. More information on changing DNS Servers can be found in the article Create, change, or delete a virtual network.

Настройка второго контроллера домена Configure the second Domain Controller

Подключитесь к AZDC02 с помощью учетных данных, указанных в сценарии. Connect to AZDC02 using the credentials you provided in the script.

Проверка предварительных требований выдаст предупреждение о том, что для физического сетевого адаптера не назначены статические IP-адреса. The Prerequisites Check will warn you that the physical network adapter does not have static IP address(es) assigned. Вы можете спокойно проигнорировать это, так как статические IP-адреса назначены в виртуальной сети Azure. You can safely ignore this, as static IPs are assigned in the Azure virtual network.

Читайте также:  Для малышей собираем машину

Когда мастер завершит процесс установки, виртуальная машина перезагружается. When the wizard completes the install process, the VM reboots.

После завершения перезагрузки виртуальной машины Войдите в систему с использованием учетных данных, которые использовались ранее, но на этот раз как член домена CONTOSO.com. When the VM has completed rebooting, log back in with the credentials used before, but this time as a member of the CONTOSO.com domain

Виртуальные сети Azure теперь поддерживают IPv6, но если вы хотите установить для виртуальных машин предпочитаемый протокол IPv4 по протоколу IPv6, сведения о том, как выполнить эту задачу, можно найти в статье базы знаний руководство по настройке IPv6 в Windows для опытных пользователей. Azure virtual networks do now support IPv6, but in case you want to set your VMs to prefer IPv4 over IPv6, information on how to complete this task can be found in the KB article Guidance for configuring IPv6 in Windows for advanced users.

Заключение Wrap up

На этом этапе среда имеет пару контроллеров домена, и мы настроили виртуальную сеть Azure, чтобы дополнительные серверы можно было добавить в среду. At this point, the environment has a pair of domain controllers, and we have configured the Azure virtual network so that additional servers may be added to the environment. Задачи, выполняемые после установки служб домен Active Directory, например настройка сайтов и служб, аудит, резервное копирование и обеспечение безопасности встроенной учетной записи администратора, должны быть завершены на этом этапе. Post-install tasks for Active Directory Domain Services, like configuring sites and services, auditing, backup, and securing the built-in administrator account, should be completed at this point.

Удаление среды Removing the environment

Чтобы удалить среду, после завершения тестирования созданная ранее группа ресурсов может быть удалена. To remove the environment, when you have completed testing, the resource group we created above can be deleted. На этом шаге удаляются все компоненты, которые являются частью этой группы ресурсов. This step removes all of the components that are part of that resource group.

Удалить с помощью портал Azure Remove using the Azure portal

В портал Azure перейдите к группе ресурсов и выберите созданную группу ресурсов (в нашем примере это адоназуревмс), а затем выберите Удалить группу ресурсов. From the Azure portal, browse to Resource groups and choose the resource group we created (in this example ADonAzureVMs), then select Delete resource group. Процесс запрашивает подтверждение перед удалением всех ресурсов, содержащихся в группе ресурсов. The process asks for confirmation before deleting all the resources contained inside of the resource group.

Удалить с помощью Azure CLI Remove using the Azure CLI

В Azure CLI выполните следующую команду: From Azure CLI run the following command:

Источник

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

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

. Обычно компании начинают с консолидации своих физических серверов на хост-машинах в виде виртуальных машин. Естественно, руководство компаний стремится виртуализировать максимально возможное число серверов. Осуществляя этот процесс, компании часто следуют принципу «объект является виртуальным по умолчанию»: все приложения виртуализируются, если администраторы не могут представить веские основания для того, чтобы отказаться от этой процедуры. А можно ли виртуализировать Active Directory (AD)? Следует ли делать виртуальным весь лес AD или только его часть?

Каталоги виртуальные и физические

Первый и самый важный вопрос формулируется так: поддерживает ли Microsoft виртуальные контроллеры доменов (VDC)? Ведь если вы переведете часть жизненно важной инфраструктуры в официально не поддерживаемую среду, ваша карьера будет явно под угрозой. К счастью, Microsoft поддерживает VDC как часть серверного программного обеспечения на продуктах виртуализации как собственной разработки, так и созданных сторонними производителями; с подробным описанием политики поддержки можно ознакомиться в подготовленной сотрудниками Microsoft статье «Microsoft server software and supported virtualization environments» (support.microsoft.com/kb/957006). Но имейте в виду, что существует ряд важных рекомендаций, на которые следует обратить внимание. Ведь, даже удостоверившись, что та или иная среда поддерживается производителем, вы не можете застраховать себя от неприятностей. Конечно, сотрудники подразделения Microsoft Problem Resolution Services будут рады помочь вам — за соответствующее вознаграждение, но, если вы будете следовать сформулированным в данной статье рекомендациям, их помощь вам не потребуется.

Вам придется принять решение о том, в каких случаях нужно виртуализировать контроллер домена, а в каких — оставлять его в физической форме. По большому счету такой фактор, как рабочие характеристики, здесь уже не нужно принимать во внимание: разработанные компаниями VMware и Microsoft 64?разрядные гипервизоры обеспечивают превосходную производительность по сравнению с физическими компонентами; к примеру, в статье Microsoft «Performance and capacity requirements for Hyper-V» (technet.microsoft.com/library/dd277865 (office.12).aspx) приводятся результаты работы Microsoft Office SharePoint Server 2007 в виртуальной среде. Виртуальные кластеры на хосте дают возможность использовать такие средства, как VMware VMotion или Hyper-V Live Migration, позволяющие создавать высокодоступные контроллеры доменов с большей легкостью, чем когда-либо раньше. И все же, как я полагаю, существуют две веские причины для того, чтобы сохранять в лесу по крайней мере несколько физических контроллеров доменов: эти причины — отказоустойчивость и безопасность.

AD — отказоустойчивая система, ибо она является распределенной. Компания может иметь любое число контроллеров доменов, предоставляющих службу AD, — от рекомендуемого минимума в два DC до сотен контроллеров. Домен или лес могут продолжать функционировать после выхода из строя одного или большего числа контроллеров доменов, поскольку ни один из них не содержит уникальных данных, которые нельзя было бы восстановить или переустановить каким-либо иным образом. В сетях, где служба AD организована без применения средств виртуализации, отказоустойчивость реализуется по определению, поскольку каждый контроллер домена представляет собой отдельную физическую систему и эти системы размещаются в различных местах. При использовании виртуальной инфраструктуры ситуация иная. К примеру, на одной хост-системе может размещаться несколько контроллеров доменов, и в случае отказа этой системы все они могут выйти из строя. Или такой пример. Допустим, в соответствии со стандартным планом виртуализации вашей компании все серверы должны задействовать не локальные диски, а сети устройств хранения данных SAN. Из этого следует, что при выходе из строя сети SAN под угрозой оказывается функционирование большинства компонентов службы AD или вся служба целиком. Более подробную информацию о средствах хранения данных для AD можно найти во врезке «Контроллеры доменов: чем проще хранилище, тем лучше». Так что при составлении плана виртуализации для леса AD вам следует внимательно присмотреться к поддерживающей инфраструктуре и сотрудничать со специалистами по виртуализации, чтобы исключить возможность появления точек отказа. О диктуемых соображениями безопасности основаниях для того, чтобы не осуществлять виртуализацию контроллеров доменов, я расскажу ниже.

Я рекомендую оставлять в каждом домене по меньшей мере по два физических контроллера; один из них должен быть главным контроллером домена — владельцем соответствующей роли Flexible Single-Master Operation (FSMO) — хозяином PDC. Даже в случае сбоя, затрагивающего всю виртуальную инфраструктуру, такая архитектура гарантирует, что в вашем распоряжении будет полностью функциональный домен с распределенной отказоустойчивостью. Решайте сами, какой запас прочности вам может потребоваться. Но имейте в виду: расходы на эксплуатацию двух физических серверов не идут ни в какое сравнение с потенциальным ущербом, который понесет ваша компания в случае выхода из строя целого домена.

Создание и развертывание виртуальных контроллеров доменов

Итак, вы определили, какие контроллеры следует виртуализировать. Что ж, пришло время настроить ваши виртуальные контроллеры доменов. С технической точки зрения это достаточно просто. Если ваши контроллеры доменов функционируют под управлением систем Windows Server 2008 или Server 2008 R2, рассмотрите возможность использования в качестве операционной системы версию Server Core, характеризующуюся малой площадью атаки. Для процессора и памяти установите такие требования, которые способны обеспечить эмуляцию текущей конфигурации — или конфигурации, которую вы хотели бы иметь, если бы не ограничения бюджета. Удостоверьтесь в том, что на виртуальном контроллере домена установлены средства расширения возможностей виртуальной машины для вашего средства виртуализации (например, VMware Tools). Если вы работаете с платформой Hyper-V, позаботьтесь о том, чтобы виртуальный контроллер домена был оснащен современным сетевым адаптером, а не устаревшим; новейшие сетевые интерфейсные платы имеют гораздо более высокую производительность.

Читайте также:  Дтп с почтовыми машинами

Для типов жестких дисков вы можете использовать либо базовые, либо динамически расширяющиеся диски; согласно последним утверждениям представителей Microsoft, по своей производительности динамические диски Hyper-V R2 почти не уступают базовым. Однако требования к диску контроллера домена довольно статичны; поэтому, после того как вы определите оптимальный размер диска для вашего контроллера домена — опираясь на данные об использовании диска физического контроллера домена, — я рекомендую создать базовый диск того же размера. Кэширование записей на томах, содержащих базы данных AD и регистрационные файлы, по умолчанию отключено, для того чтобы прерывания в процессе ввода-вывода не приводили к повреждению данных.

Кроме того, стоит рассмотреть возможность развертывания в вашем лесу контроллеров доменов только для чтения, Read-Only Domain Controllers (RODC). Такой контроллер имеет лишь копию AD, предназначенную для чтения; пароли по умолчанию не предусмотрены. В результате снимается острота некоторых проблем обеспечения безопасности, связанных с эксплуатацией виртуальных контроллеров доменов. Для функционирования RODC требуется, по меньшей мере, версия Server 2008.

На своем VDC отключите функцию Synchronize time with host. Контроллеры доменов имеют собственную архитектуру синхронизации времени, и другие варианты синхронизации им не требуются. Если вы используете платформу Hyper-V, проследите за тем, чтобы антивирусная программа в родительском разделе исключала из проверок файлы VHD, расположенные в дочерних разделах, иначе при попытках запуска виртуальных машин вы можете столкнуться с проблемой снижения производительности и с сообщениями об ошибках.

Виртуальный контроллер домена можно разворачивать таким же образом, как и другие виртуальные машины, — как правило, с помощью средства управления, например Microsoft System Center Virtual Machine Manager (VMM) или VMware vCenter. Есле же вам требуется создать контроллер домена и широко использовать средства автоматизации, вы можете создать сценарий, предписывающий процессу Dcpromo выполняться факультативно по завершении развертывания; см. статьи Microsoft «Configuring the Automatic Installation of Active Directory» (tinyurl.com/22umult) и «How to Configure Guest Operating System Profile Scripts» (tinyurl.com/2fzotwg).

Администрирование виртуальных контроллеров

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

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

Резервные копии на основе образов (резервные копии на основе хостов). Восстановление с резервных копий на основе образов, в ходе которого администратор копирует либо иным образом резервирует содержащие VDC файлы виртуального жесткого диска, не поддерживается (за одним исключением). При выполнении такого рода операций операционная система и база данных AD возвращаются в предшествующее состояние без переустановки идентификатора вызова (версии локальной базы данных), так что всем остальным контроллерам домена ничего не известно о восстановлении целевого контроллера домена. В этой ситуации нарушается целостность данных AD, могут возникать устаревшие объекты, а также сценарии с возвратом номеров последовательного обновления update sequence number (USN); более подробные сведения об этой проблеме можно найти в подготовленной сотрудниками Microsoft статье «How to detect and recover from a USN rollback in Windows Server 2003» (support.microsoft.com/kb/875495).

Исключение составляет тот случай, когда в гостевой операционной системе выполняется система Windows Server 2003 или более новые версии, и утилита резервного копирования на хосте, скажем Windows Server Backup, вызывает гостевой модуль записи службы VSS (Volume Shadow Copy Service), чтобы гарантировать корректное резервирование гостевой системы. Windows 2003 была первой операционной системой, включающей эту службу. Гостевой модуль записи VSS выполняет моментальный снимок тома гостевой системы, обеспечивая тем самым целостность данных резервной копии. В случае восстановления VSS-совместимая программа восстановления извещает службу каталогов гостевой системы о том, что процедура восстановления выполнена. Во время этого процесса сбрасывается идентификатор вызова базы данных AD и партнеры по репликации данного контроллера домена извещаются о том, что восстановление состоялось, а значит, репликация, поступающая от этого контроллера, имеет законную силу.

Резервирование клиентов. Другой поддерживаемый метод резервирования содержимого виртуального контроллера домена состоит в снятии резервных копий клиентов, как это делается при работе с физическим контроллером домена. По скорости выполнения этот процесс уступает резервному копированию на основе хоста, в котором используется модуль записи VSS, однако он превосходит многие приложения резервного копирования на основе хоста в том отношении, что позволяет восстанавливать индивидуальные файлы в гостевой системе. Большинство таких приложений не поддерживают восстановление данных на уровне файлов, но наиболее развитые из них (например, Microsoft System Center Data Protection Manager 2010) также позволяют восстанавливать индивидуальные файлы гостевых операционных систем, поддерживающих VSS. Специалисты Microsoft привели свои рекомендации по резервному копированию и восстановлению виртуальных контроллеров доменов в статье «Backup and Restore Considerations for Virtualized Domain Controllers» (tinyurl.com/ydw8b5w).

А нужно ли резервировать содержимое каждого VDC? Мне представляется, что в небольших лесах целесообразно делать резервные копии состояния системы двух контроллеров в каждом домене. В лесах большего размера с крупными (свыше 5 Гбайт) базами данных AD (ntds.dit) или с географически рассредоточенными контроллерами доменов требуется большее количество. Здесь нужно руководствоваться следующим принципом: резервная копия должна находиться в той же локальной сети, что и контроллер домена, — это дает возможность ускорять процесс выполнения Dcpromo с использованием резервных носителей информации. Если у вас по какой-либо причине выйдет из строя тот или иной виртуальный контроллер домена, имейте в виду, что существуют более быстрые методы восстановления, чем восстановление с резервной копии. Информацию о других вариантах можно найти на странице DC Recovery моего ресурса Active Directory Recovery Flowchart по адресу tinyurl.com/adrecovery.

Моментальные снимки виртуальных машин. Восстановление виртуальных контроллеров доменов с использованием моментальных снимков виртуальных машин не поддерживается. Эти моментальные снимки (не путать с моментальными снимками каталогов, выполняемыми с помощью Ntdsutil, а также с моментальными снимками томов, выполняемыми с помощью VSS) формируются посредством ввода данных о состоянии виртуальной машины на определенный момент времени. При восстановлении виртуального контроллера домена до его предшествующего состояния с помощью сохраненного моментального снимка в каталоге возникают те же ошибки несоответствия, что и при резервировании на основе образа.

Клонирование. Клонирование контроллера домена посредством дублирования файла жесткого диска VDC не поддерживается. Если клонированный VDC подключается к сети в том же лесу, что и исходный контроллер, и вы разрешаете тут же возникающие проблемы с идентичными именами серверов и IP-адресами, перед вами встанут проблемы с повторяющимися глобальными уникальными идентификаторами агента службы каталога Directory Service Agent (DSA), повторяющимися идентификаторами безопасности, повторяющимися пулами относительных идентификаторов Relative Identifier (RID), причем ситуация усугубляется в случае, когда клонированный VDC является хозяином роли RID — c проблемами защищенного канала, с обновлениями пароля учетной записи системы — словом, лучше со всем этим не связываться.

Преобразование физического объекта в виртуальный (physical to virtual conversion, P2V). Преобразование типа P2V поддерживается, но лишь в том случае, если исходный физический контроллер домена не подключен к сети; это требование поддерживает VMM 2008. При преобразовании P2V контроллера домена в ситуации, когда исходный контроллер подключен к сети, возникают те же проблемы, что и при клонировании. В целом я считаю, что подготовка и повышение уровня нового виртуального контроллера домена связаны с меньшим риском и выполняются почти так же быстро, как преобразование P2V существующего контроллера домена.

Читайте также:  Гоночная машина простым карандашом

Приостановка. Приостановка виртуального контроллера домена (то есть перевод его в автономное состояние), в сущности, допускается, но «не приостанавливайте контроллер домена на длительное время», как говорится в статье Microsoft «Considerations when hosting Active Directory domain controller in virtual hosting environments» (support.microsoft.com/kb/888794). Что происходит во время приостановки контроллера домена? С точки зрения его партнеров по репликации, контроллер внезапно изымается из сети — как если бы кто-то выдернул сетевой кабель. Когда приостановленный контроллер домена вновь «оживает», создается впечатление, что произошел скачок во времени. Срок действия его билетов Kerberos истек, системные пароли, возможно, требуют обновления, а если приостановка длилась дольше времени жизни отмеченного для полного удаления объекта, контроллер уже нельзя использовать для репликации, его нужно перестраивать. Я бы рекомендовал не злоупотреблять приостановками работы контроллера домена и следить за тем, чтобы паузы не были слишком длинными.

Стандартизированная конфигурация. Для работы виртуальной машины требуется особый уровень аппаратных абстракций (hardware abstraction layer, HAL) и особый набор драйверов устройств, отличные от тех, что используются при эксплуатации физических контроллеров доменов. Поэтому для виртуальных контроллеров доменов необходим отдельный стандарт сборки операционной системы. Большинство компаний применяют по меньшей мере две стандартные конфигурации сборки — одну для широко используемых аппаратных компонентов, жизнь которых близка к завершению, другую для новой аппаратуры, получающей более широкое распространение. Виртуальным машинам с их особым уровнем HAL и набором драйверов устройств потребуется третья конфигурация сборки.

Безопасность виртуальных контроллеров доменов

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

Защита виртуальных дисков. Доступ к виртуальным дискам VDC равнозначен предоставлению физического доступа к физическому контроллеру домена; если вы предоставляете такой доступ, то уже не можете гарантировать безопасность. Доступ к файлам этих виртуальных дисков должен быть соответствующим образом защищен, особенно с учетом того обстоятельства, что в соответствии с потребностями администрации виртуального хоста доступ к ним будет требоваться большему числу людей. Следовательно, администраторы хостов, администраторы филиалов, администраторы хранилищ сетей SAN и администраторы центров обработки данных — все это группы, членов которых, возможно, придется вносить в список служащих, имеющих доступ к данным корпоративных каталогов.

Доступ через консоль. Админи­стра­торам DC следует предоставлять доступ к виртуальным контроллерам доменов через консоль — таким же образом, каким они получали бы доступ к физическим DC через внешнюю консольную утилиту, не требующую установки операционной системы. В организациях, эксплуатирующих продукты VMware, управлять доступом через консоль можно с помощью vCenter Server, а в компаниях, где используется платформа Hyper-V, с этой целью можно применять диспетчер Authorization Manager (AzMan) или портал VMM Self-Service Portal.

Сведения о состоянии контроллеров доменов. Образно выражаясь, полнофункциональные виртуальные DC содержат «ключи от всего королевства», и сотрудники с правами административного доступа к хосту имеют возможность влиять и, возможно, мешать работе VDC на этом хосте. Важно довести до всех сотрудников, имеющих доступ к хостам, информацию о последствиях, вытекающих из того факта, что на их физических серверах размещаются контроллеры доменов.

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

Предварительная подготовка

Виртуализация части инфраструктуры AD может быть выгодна для корпорации, но администратору AD она не сулит никаких преимуществ. Конечно, эту операцию можно осуществить, и Microsoft ее поддерживает, но, перед тем как приступать к виртуализации, следует провести тщательную подготовку. Основные файлы документации Microsoft по VDC можно найти в статье TechNet «Running Domain Controllers in Hyper-V» (tinyurl.com/2fm7hd8). Не подвергайте VDC каким-либо манипуляциям, непонятным для их служб каталогов, и помните, что преимущества, которые несет виртуализация контроллеров доменов, оборачиваются необходимостью прилагать дополнительные усилия по обеспечению их безопасности.

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

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

Сеть хранения данных может упростить этот процесс. Дело в том, что перемещать дисковые файлы в данном случае не обязательно: изменениям подвергаются машины, обращающиеся к этим файлам. В зависимости от конфигурации в централизованной сети хранения данных файл диска виртуальной машины может выполняться в центре обработки данных в Калифорнии, после чего быстро изменяться так, что этот файл поступает в распоряжение сервера, находящегося в Нью-Йорке. Когда сеть хранения данных настраивается как хранилище общего доступа, появляется возможность объединить несколько виртуальных машин в отказоустойчивый виртуальный кластер.

Но следует ли размещать в сети устройств хранения данных контроллеры доменов? Active Directory (AD) — система распределенная. Ее отказоустойчивость проистекает из того обстоятельства, что компоненты системы — скажем, диски — разбросаны по всему предприятию. Когда мы начинаем консолидировать эти компоненты, система теряет отказоустойчивость. Требования к диску у контроллера домена довольно скромны. Он должен поддерживать индексированный последовательный файл базы данных, чтение которого выполняется чаще, чем запись в него, и размеры которого обычно не достигают 10 Гбайт. Но доступность каждого домена AD является абсолютно необходимой.

Если в соответствии с правилами, принятыми в вашем дата-центре, все диски виртуальных машин должны располагаться в сети хранения данных и, если эта сеть дает сбой, ваш домен или даже целый лес выходит из строя — до тех пор, пока не будет восстановлено функционирование сети хранения данных. На это вы можете сказать, что сети хранения данных редко выходят из строя, но я должен возразить, что, когда вы работаете с таким базисным компонентом ИТ-инфраструктуры компании, как AD, взаимозависимость систем должна быть минимальной. Очевидно, что вследствие сбоя в работе сети хранения данных многие серверы приложений не смогут функционировать, но надо иметь в виду, что полностью избыточная сеть SAN может обойтись крайне дорого и потому ее реализация окажется экономически нецелесообразной. С другой стороны, разве вы хотели бы потерять при этом возможность регистрироваться в сети?

При использовании распределенного простого приложения базы данных, такого как AD, хранилище сети SAN не только не является необходимым, но и повышает риск возникновения единственной точки отказа. В случае применения локальных дисков один контроллер домена может выйти из строя из-за отказа диска, но неполадки коснутся лишь этого DC. Если же вы разместите базы данных AD своего контроллера домена в сети SAN, функционирование вашего леса будет зависеть от этой сети хранения данных. Моя рекомендация: простота — залог успеха. Используйте локальные решения.

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

Источник

Интересные факты и лайфхаки