Tw-city.info

IT Новости
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Контроллер домена на виртуальной машине

Развертывание Active Directory

В сценарии приводится пример развертывания Active Directory в Яндекс.Облаке.

Чтобы развернуть инфраструктуру Active Directory:

Подготовьте облако к работе

Перед тем, как разворачивать серверы, нужно зарегистрироваться в Облаке и создать платежный аккаунт:

  1. Перейдите в консоль управления, затем войдите в Яндекс.Облако или зарегистрируйтесь, если вы еще не зарегистрированы.
  2. На странице биллинга убедитесь, что у вас подключен платежный аккаунт, и он находится в статусе ACTIVE или TRIAL_ACTIVE . Если платежного аккаунта нет, создайте его.

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

Необходимые платные ресурсы

В стоимость инсталляции Active Directory входят:

  • плата за постоянно запущенные виртуальные машины (см. тарифы Yandex Compute Cloud);
  • плата за использование динамических или статических публичных IP-адресов (см. тарифы Yandex Virtual Private Cloud);
  • стоимость исходящего трафика из Облака в интернет (см. тарифы Yandex Compute Cloud).

Создайте облачную сеть и подсети

Создайте облачную сеть ad-network с подсетями во всех зонах доступности, где будут находиться виртуальные машины.

Создайте облачную сеть:

  1. Откройте раздел Virtual Private Cloud в каталоге, где требуется создать облачную сеть.
  2. Нажмите кнопку Создать сеть.
  3. Задайте имя сети: ad-network .
  4. Нажмите кнопку Создать сеть.

Чтобы создать облачную сеть, выполните команду:

Создайте три подсети в сети ad-network :

Чтобы создать подсеть:

  1. Откройте раздел Virtual Private Cloud в каталоге, где требуется создать подсеть.
  2. Нажмите на имя облачной сети.
  3. Нажмите кнопку Добавить подсеть.
  4. Заполните форму: введите имя подсети ad-subnet-a , выберите зону доступности ru-central1-a из выпадающего списка.
  5. Введите CIDR подсети: IP-адрес и маску подсети: 10.1.0.0/16 . Подробнее про диапазоны IP-адресов в подсетях читайте в разделе Облачные сети и подсети.
  6. Нажмите кнопку Создать подсеть.

Повторите шаги еще для двух подсетей ad-subnet-b и ad-subnet-c в зонах доступности ru-central1-b и ru-central1-c с CIDR 10.2.0.0/16 и 10.3.0.0/16 соответственно.

Чтобы создать подсети, выполните команды:

Создайте скрипт для управления локальной учетной записью администратора

Создайте файл setpass , содержащий скрипт, который будет устанавливать пароль для локальной учетной записи администратора при создании виртуальных машин через CLI:

Пароль должен соответствовать требованиям к сложности.

Подробные рекомендации по защите Active Directory читайте на сайте разработчика.

Создайте ВМ для Active Directory

Создайте две виртуальных машины для контроллеров домена Active Directory. Эти машины не будут иметь доступа в интернет.

На странице каталога в консоли управления нажмите кнопку Создать ресурс и выберите Виртуальная машина.

В поле Имя введите имя виртуальной машины: ad-vm-a .

В блоке Публичные образы нажмите кнопку Выбрать. В открывшемся окне выберите образ 2016 Datacenter.

В блоке Диски укажите размер загрузочного диска 35 ГБ.

В блоке Вычислительные ресурсы:

  • Выберите платформу: Intel Cascade Lake.
  • Укажите необходимое количество vCPU и объем RAM:
    • vCPU — 4.
    • Гарантированная доля vCPU — 100%.
    • RAM — 8 ГБ.

В блоке Сетевые настройки нажмите кнопку Добавить сеть и выберите сеть exchange-network . Выберите подсеть exchange-subnet-a . В блоке Публичный адрес выберите вариант Без адреса.

В блоке Доступ укажите данные для доступа на виртуальную машину:

  • В поле Пароль укажите ваш пароль.

Нажмите кнопку Создать ВМ.

Повторите операцию для ВМ с именем ad-vm-b в зоне доступности ru-central1-a и подключите ее к подсети exchange-subnet-b

Создайте ВМ для бастионного хоста

Для настройки машин с Active Directory будет использоваться файловый сервер с выходом в интернет.

На странице каталога в консоли управления нажмите кнопку Создать ресурс и выберите Виртуальная машина.

В поле Имя введите имя виртуальной машины: jump-server-vm .

В блоке Публичные образы нажмите кнопку Выбрать. В открывшемся окне выберите образ 2016 Datacenter.

В блоке Диски укажите размер загрузочного диска 35 ГБ.

В блоке Вычислительные ресурсы:

  • Выберите платформу: Intel Cascade Lake.
  • Укажите необходимое количество vCPU и объем RAM:
    • vCPU — 2.
    • Гарантированная доля vCPU — 100%.
    • RAM — 4 ГБ.

В блоке Сетевые настройки нажмите кнопку Добавить сеть и выберите сеть exchange-network . Выберите подсеть exchange-subnet-c . В блоке Публичный адрес выберите вариант Без адреса.

В блоке Доступ укажите данные для доступа на виртуальную машину:

  • В поле Пароль укажите ваш пароль.

Нажмите кнопку Создать ВМ.

Установите и настройте Active Directory

У машин с Active Directory нет доступа в интернет, поэтому их следует настраивать через ВМ jump-server-vm с помощью RDP.

Подключитесь к ВМ jump-server-vm с помощью RDP. Используйте логин Administrator и ваш пароль.

Запустите RDP и подключитесь к виртуальной машине ad-vm-a .

Запустите PowerShell и задайте статический адрес:

Создайте временную папку:

Установите роли Active Directory:

Создайте лес Active Directory:

Windows перезапустится автоматически. Снова откройте PowerShell.

Переименуйте сайт по умолчанию в ru-central1-a :

Создайте еще два сайта для других зон доступности:

Создайте подсети и привяжите их к сайтам:

Переименуйте сайт-линк и настройте репликацию:

Header Menu

Особенности развертывания виртуализированных контроллеров домена

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

Недопустимые действия при развертывании виртуализации

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

  • Не применяйте разностные виртуальные жесткие диски (VHD) на виртуальной машине, настраиваемой в качестве контроллера домена. Это слишком облегчает возврат к предыдущей версии, а также снижает производительность. Дополнительные сведения о типах виртуальных жестких дисков см. в статье «Мастер создания виртуального жесткого диска» (страница может быть на английском языке) http://go.microsoft.com/fwlink/?LinkID=137279.
  • Не клонируйте установку операционной системы без использования программы Sysprep.exe, поскольку идентификатор безопасности (SID) компьютера не будет обновлен. Дополнительные сведения об использовании программы подготовки системы (Sysprep) см. в разделе «Использование виртуальных жестких дисков» статьи «Способы развертывания операционной системы на виртуальную машину» (страница может быть на английском языке) (http://go.microsoft.com/fwlink/?LinkId=137100).
  • Чтобы предотвратить возникновение потенциально возможной ситуации отката номера последовательного обновления (USN), не используйте копии VHD-файла, который представляет уже развернутый контроллер домена, для развертывания дополнительных контроллеров домена. Следующие три пункта этого списка также рекомендуются с целью предотвращения потенциально возможной ситуации отката номера последовательного обновления. Дополнительные сведения об откате номера последовательного обновления см. в Приложение A: виртуализированные контроллеры домена и проблемы репликации.
  • Не используйте функцию экспорта Hyper-V для экспорта виртуальной машины, на которой выполняется контроллер домена.
Читать еще:  Работа в домене что это

Миграция из физической в виртуальную среду

System Center Virtual Machine Manager (VMM) 2008 обеспечивает единое управление физическими компьютерами и виртуальными машинами. Кроме того, это решение предоставляет возможность миграции физического компьютера на виртуальную машину. Это процесс известен как преобразование физического компьютера в виртуальную машину (P2V). Во время процесса преобразования P2V физический контроллер домена, миграция которого осуществляется, не должен быть включен одновременно с новой виртуальной машиной, чтобы избежать ситуации отката номера последовательного обновления, как описано в Приложение A: виртуализированные контроллеры домена и проблемы репликации.

Преобразование P2V необходимо выполнить в автономном режиме, чтобы данные каталога были согласованы, когда контроллер домена вновь включится. Вариант автономного режима предлагается и рекомендуется в мастере преобразования физического сервера. Описание различий между автономным и оперативным режимами см. в статье «P2V: преобразование физических компьютеров в виртуальные машины в VMM» (страница может быть на английском языке) (http://go.microsoft.com/fwlink/?LinkId=155072). Во время преобразования P2V виртуальная машина не должна быть подключена к сети. Сетевой адаптер виртуальной машины следует включать только после завершения процесса преобразования P2V и его проверки. На этом этапе исходный физический компьютер будет отключен. Не подключайте исходный физический компьютер обратно к сети, пока жесткий диск не будет переформатирован.

Использование миграции P2V для создания тестовых сред

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

Выполняется миграция на тестовую виртуальную машину одного рабочего контроллера домена из каждого домена преобразованием P2V согласно рекомендациям, приведенным в подразделе Миграция из физической в виртуальную среду. Физические рабочие компьютеры и тестовые виртуальные машины должны находиться в разных сетях, когда они вновь будут подключаться к сети. Чтобы избежать в тестовой среде откатов номера последовательного обновления, все контроллеры домена, миграция которых выполняется с физических компьютеров на виртуальные машины, должны быть отключены от сети. (Для этого необходимо остановить службу NTDS или перезагрузить компьютер в режиме восстановления служб каталогов (DSRM).) После отключения контроллеров домена от сети в среде не должны производиться обновления. Компьютеры должны оставаться отключенными от сети в процессе миграции P2V; ни один компьютер нельзя вновь подключать к сети, пока полностью не завершена миграция всех компьютеров. Дополнительные сведения об откате номера последовательного обновления см. в Приложение A: виртуализированные контроллеры домена и проблемы репликации.

Последующие тестовые контроллеры домена должны создаваться как реплики в тестовой среде.

Служба времени

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

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

Чтобы отключить синхронизацию времени с узлом в параметрах виртуальной машины, в разделе Службы интеграции диспетчера Hyper-V снимите флажок Синхронизация времени.

Дополнительные сведения об установке и использовании служб интеграции см. в руководстве «Начало работы с Hyper-V» (страница может быть на английском языке) http://go.microsoft.com/fwlink/?LinkId=137146.

Хранение

Чтобы оптимизировать производительность виртуальной машины, настроенной в качестве контроллера домена, следуйте приведенным ниже рекомендациям для хранения файлов операционной системы, Active Directory и VHD-файлов.

  • Хранение на виртуальной машине. Файл базы данных Active Directory (Ntds.dit), файлы журналов и SYSVOL-файлы должны храниться на виртуальном диске, отдельном от файлов операционной системы. Интеграционные компоненты необходимо устанавливать так, чтобы для интерфейса IDE можно было использовать виртуальные драйверы вместо эмуляции. Быстродействие виртуальных SCSI- и IDE-дисков одинаково при использовании ими виртуальных драйверов.
  • Хранение VHD-файлов на узле. Рекомендации. Рекомендации по хранению на узле относятся к хранению VHD-файлов. Чтобы обеспечить максимальную производительность, не храните VHD-файлы на диске, который часто используют другие службы или приложения, например на системном диске с установленной ОС Windows узла. Каждый VHD-файл рекомендуется хранить на отдельном разделе отдельно от операционной системы узла и остальных VHD-файлов. Оптимальная конфигурация достигается при хранении каждого VHD-файла на отдельном физическом диске.
  • Виртуальные жесткие диски фиксированного объема в сравнении с транзитными дисками. Существует много способов конфигурации хранилища для виртуальных машин. Если используются VHD-файлы, то виртуальные жесткие диски фиксированного объема более эффективны, чем динамические виртуальные жесткие диски, поскольку память для виртуальных жестких дисков фиксированного объема выделяется при их создании. Транзитные диски, используемые виртуальными машинами для доступа к физической среде хранения, еще лучше оптимизированы для обеспечения высокой производительности. Транзитные диски, по существу, являются физическими дисками или логическими номерами устройств (LUN), подключенными к виртуальной машине. Транзитные диски не поддерживают функцию создания моментального снимка. Поэтому транзитные диски являются предпочтительной конфигурацией жестких дисков, поскольку не рекомендуется использовать моментальные снимки для контроллеров домена.

Чтобы уменьшить вероятность повреждения данных Active Directory, используйте SCSI-контроллеры или отключите кэширование записей на ATA/IDE-дисках.

Читать еще:  Доменная учетная запись

Контроллер домена на виртуальной машине

Как известно, одним из требований к установке и настройке отказоустойчивого кластера в Windows Server 2012 является наличие контроллера домена. В данной статье речь пойдет о подготовке и конфигурации отказоустойчивого кластера (Failover Cluster) на базе сервера Demos R420 M2 без существующего контроллера домена. Необходимый для работы кластера контроллер домена будет интегрирован непосредственно в среду отказоустойчивого кластера в виртуальной машине.

Настройка будет включать следующие шаги:

  1. Начальные задачи для настройки, которые включают подготовку дисковой подсистемы сервера для работы в кластере и настройку сети между узлами.
  2. Установка роли Hyper-V на узлы кластера и настройка виртуальной машины для контроллера домена.
  3. Создание виртуальной машины на одном из узлов кластера.
  4. Установка и настройка ролей AD DS и DNS в виртуальной машине.
  5. Установка и настройка кластера с использованием контроллера домена в виртуальной машине.
  6. Подготовка и миграция виртуальной машины в кластер.

Перед началом настройки на все узлы рекомендуется:

  • Установить все доступные обновления операционной системы (обратите особое внимание на то, что на узлах должен быть установлен абсолютно одинаковый набор обновлений).
  • Обновить до последней версии драйверы и прошивки устройств, драйверы должны иметь подпись Microsoft.
  • Иcпользуйте в одном массиве идентичные SAS-диски вплоть до версии прошивки.

Подготовка к установке кластера

Настройка MPIO

Каждый узел сервера имеет доступ к общему дисковому хранилищу, которое позволяет разместить до 12 дисков. Для установки операционной системы используются внутренние посадочные места для 2.5” SATA/SSD дисков.

Диски в сервере подключены одновремено к двум узлам системы с использованием дублированной системы ввода/вывода (Multipath I/O), таким образом, в диспетчере устройств будет отображаться удвоенное количество дисков находящихся в хранилище.

Для настройки Multipath I/O на каждом узле запустите мастер установки ролей и компонентов и установите компоненту Multipath I/O.

В консоли сервера в меню Tools запустите MPIO. На вкладке Discover Multi-Paths установите галку Add support for SAS devices и нажмите Add. Перезагрузите сервер.

После перезагрузки в диспетчере устройств отображаются Multi-Path диски, принадлежащие дисковому хранилищу.

Данную процедуру необходимо выполнить на двух узлах.

Инициализация дисков

После этого необходимо сделать сброс каждого диска (Reset Disk) для того чтобы удалить все данные и метаинформацию, которые могут там содержаться. Сделать инициализацию (Initialize) дисков и после этого перевести диски в Offline. Инициализацию достаточно сделать на одном из узлов сервера. Данные операции доступны в оснастке Server Manager — File and Storage Services — Volumes — Disks.

Подготовка сетевых интерфейсов

В настройках интерфейса для подключения к локальной сети рекомендуется задать статические IP-адреса. Информация об IP-адресах и именах узлов кластера обязательно должна содержаться в прямой и обратной зоне DNS сервера. Убедитесь в работоспособности прямого и обратного разрешения имен. Для настройки сети между узлами кластера в Demos R420 M2 используется внутренний сетевой интерфейс Intel® I350 Gigabit Backplane Connection, в настройках которого вы можете выставить свою конфигурацию протокола TCP/IPv4. Неиспользуемые сетевые адаптеры рекомендуется поставить в состояние Disabled.

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

Одной из стратегических целей, которую преследует Microsoft в своих последних продуктах – виртуализация всего, что только возможно, что является естественным требованиям для тотальной миграции в облака. Специально для этого, в новых версиях Hyper-V и Active Directory, которые выходят в составе новой серверной ОС Windows Server 2012, был введен ряд существенных улучшений и дополнений. Например, Microsoft сообщает о том, что теперь в виртуальной машине Hyper-V можно запускать даже высоконагруженные сервера SQL. Кроме того Microsoft наконец-то реализовало возможность создавать полноценные виртуальные контроллеры домена.

Если вы помните, в Windows Server 2008 R2 существовали следующие проблемы с виртуализацией контроллеров домена Active Directory:

  • Нельзя создавать снапшот виртуального контроллера домена (если быть боле точным снапшот создать можно, но смысла это не имеет)
  • Виртуальный DC нельзя клонировать
  • Невозможна онлайн миграция V2V контроллера также
  • Восстановление виртуального DC средствами гипервизора невозможно
  • Для работы кластера Windows Server 2008 R2 требуется физический контроллер домена

Большинство из этих проблем связано с работой механизма USN (update sequence numbers). Вкратце напомним, в чем же была загвоздка. Для отслеживания обновлений между партнерами по репликации в лесу Active Directory используются идентификаторы USN. С помощью USN и ID вызова любой контроллер домена однозначно определяет, когда нужно принять и применить изменения в AD от партнеров по репликации, а когда переслать свои изменения. С помощью этого механизма обеспечивается непротиворечивость и актуальность базы AD.

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

В Windows Server 2012 контролеры домена теперь можно виртуализовать и работать с ними точно также, как с любой другой виртуальной машиной (можно делать снапшоты, клонировать DC и т.д.).

Данный функционал основывается на новой функции в Windows Server 2012 под названием VM-GenerationID. На данный момент эта функция поддерживается только в гипервизоре Hyper-V, но Microsoft рекомендует и другим производителям платформ виртуализации интегрировать данную функцию (в частности VMware уже заявила о поддержке технологии в следующей версии VSphere).

VM-Generation ID является функцией гипервизора и генерируется им при клонировании и или создании снапшота контроллера домена. VM-Generation ID представляет собой уникальный 128 битный идентификатор, который доступен приложениям через драйвер Windows Server 2012. Контроллер домена хранит значение VM-Generation ID в нереплицируемом атрибуте базы Active Directory. И перед применением изменений в базу Active Directory, контроллер домена сравнивает значение VM-Generation ID в своей базе AD со значением, полученным от гипервизора через драйвер Windows Server 2012. Если значения отличаются, осуществляется сброс параметров invocation ID и аннулирование RID. Таким образом контроллер домена определяет, что применен снапшот или контроллер домена клонирован, и актуализирует свою базу в соответствии с другими контроллерами домена AD.

Как клонировать виртуальный контроллер домена

Подготовка к клонированию DC

  • Требуется сервер Windows Server 2012 с ролью Hyper-V (вероятно, в будущем и другие гипервизоры будут поддерживать VM-GenerationID)
  • Установленный контроллер домена на Windows Server 2012 (физический или виртуальный) с ролью PDC. Найти сервер с ролью PDC можно с помощью команды:
  • Виртуальный контроллер домена с ОС Windows Server 2012 (не PDC), развернутый на сервере Windows Server 2012 Hyper-V server. Это тот самый контроллер домена.. который мы будем клонировать (пусть он будет называться VirtualDC1).
Читать еще:  Перемещаемый профиль пользователя в домене

Чтобы контроллер домена можно было клонировать, его нужно добавить в группу Cloneable Domain Controllers. Сделать это можно с помощью консоли Active Directory Users and Computers, панели управления Active Directory Administrative Center или же команды PowerShell.

Команда PowerShell будет выглядеть так:

На исходном контролере домена (VirtualDC1) запустим команду New-ADDCCloneConfigFile , с помощью которой настраиваются IP адрес и имя нового виртуального контролера домена (клона). Пусть это будет VirtualDC2.

Примечание: в данном случае новый контроллер домена будет находится в этом же сайте. Более подробно о других параметрах клонирования можно прочитать на TechNet-е ).

После этого из графического GUI Hyper-V Manager запускаем импорт виртуальной машины, выбрав в качестве параметра опцию Copy the virtual machine (create a new unique ID).

После окончания импорта переименуем виртуальную машину в VirtualDC2 и запустим ее. После ее загрузка запуститься процедура клонирования и через несколько мгновений в вашей сети появится новый виртуальный контроллер домена.

Развертывание Active Directory

В сценарии приводится пример развертывания Active Directory в Яндекс.Облаке.

Чтобы развернуть инфраструктуру Active Directory:

Подготовьте облако к работе

Перед тем, как разворачивать серверы, нужно зарегистрироваться в Облаке и создать платежный аккаунт:

  1. Перейдите в консоль управления, затем войдите в Яндекс.Облако или зарегистрируйтесь, если вы еще не зарегистрированы.
  2. На странице биллинга убедитесь, что у вас подключен платежный аккаунт, и он находится в статусе ACTIVE или TRIAL_ACTIVE . Если платежного аккаунта нет, создайте его.

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

Необходимые платные ресурсы

В стоимость инсталляции Active Directory входят:

  • плата за постоянно запущенные виртуальные машины (см. тарифы Yandex Compute Cloud);
  • плата за использование динамических или статических публичных IP-адресов (см. тарифы Yandex Virtual Private Cloud);
  • стоимость исходящего трафика из Облака в интернет (см. тарифы Yandex Compute Cloud).

Создайте облачную сеть и подсети

Создайте облачную сеть ad-network с подсетями во всех зонах доступности, где будут находиться виртуальные машины.

Создайте облачную сеть:

  1. Откройте раздел Virtual Private Cloud в каталоге, где требуется создать облачную сеть.
  2. Нажмите кнопку Создать сеть.
  3. Задайте имя сети: ad-network .
  4. Нажмите кнопку Создать сеть.

Чтобы создать облачную сеть, выполните команду:

Создайте три подсети в сети ad-network :

Чтобы создать подсеть:

  1. Откройте раздел Virtual Private Cloud в каталоге, где требуется создать подсеть.
  2. Нажмите на имя облачной сети.
  3. Нажмите кнопку Добавить подсеть.
  4. Заполните форму: введите имя подсети ad-subnet-a , выберите зону доступности ru-central1-a из выпадающего списка.
  5. Введите CIDR подсети: IP-адрес и маску подсети: 10.1.0.0/16 . Подробнее про диапазоны IP-адресов в подсетях читайте в разделе Облачные сети и подсети.
  6. Нажмите кнопку Создать подсеть.

Повторите шаги еще для двух подсетей ad-subnet-b и ad-subnet-c в зонах доступности ru-central1-b и ru-central1-c с CIDR 10.2.0.0/16 и 10.3.0.0/16 соответственно.

Чтобы создать подсети, выполните команды:

Создайте скрипт для управления локальной учетной записью администратора

Создайте файл setpass , содержащий скрипт, который будет устанавливать пароль для локальной учетной записи администратора при создании виртуальных машин через CLI:

Пароль должен соответствовать требованиям к сложности.

Подробные рекомендации по защите Active Directory читайте на сайте разработчика.

Создайте ВМ для Active Directory

Создайте две виртуальных машины для контроллеров домена Active Directory. Эти машины не будут иметь доступа в интернет.

На странице каталога в консоли управления нажмите кнопку Создать ресурс и выберите Виртуальная машина.

В поле Имя введите имя виртуальной машины: ad-vm-a .

В блоке Публичные образы нажмите кнопку Выбрать. В открывшемся окне выберите образ 2016 Datacenter.

В блоке Диски укажите размер загрузочного диска 35 ГБ.

В блоке Вычислительные ресурсы:

  • Выберите платформу: Intel Cascade Lake.
  • Укажите необходимое количество vCPU и объем RAM:
    • vCPU — 4.
    • Гарантированная доля vCPU — 100%.
    • RAM — 8 ГБ.

В блоке Сетевые настройки нажмите кнопку Добавить сеть и выберите сеть exchange-network . Выберите подсеть exchange-subnet-a . В блоке Публичный адрес выберите вариант Без адреса.

В блоке Доступ укажите данные для доступа на виртуальную машину:

  • В поле Пароль укажите ваш пароль.

Нажмите кнопку Создать ВМ.

Повторите операцию для ВМ с именем ad-vm-b в зоне доступности ru-central1-a и подключите ее к подсети exchange-subnet-b

Создайте ВМ для бастионного хоста

Для настройки машин с Active Directory будет использоваться файловый сервер с выходом в интернет.

На странице каталога в консоли управления нажмите кнопку Создать ресурс и выберите Виртуальная машина.

В поле Имя введите имя виртуальной машины: jump-server-vm .

В блоке Публичные образы нажмите кнопку Выбрать. В открывшемся окне выберите образ 2016 Datacenter.

В блоке Диски укажите размер загрузочного диска 35 ГБ.

В блоке Вычислительные ресурсы:

  • Выберите платформу: Intel Cascade Lake.
  • Укажите необходимое количество vCPU и объем RAM:
    • vCPU — 2.
    • Гарантированная доля vCPU — 100%.
    • RAM — 4 ГБ.

В блоке Сетевые настройки нажмите кнопку Добавить сеть и выберите сеть exchange-network . Выберите подсеть exchange-subnet-c . В блоке Публичный адрес выберите вариант Без адреса.

В блоке Доступ укажите данные для доступа на виртуальную машину:

  • В поле Пароль укажите ваш пароль.

Нажмите кнопку Создать ВМ.

Установите и настройте Active Directory

У машин с Active Directory нет доступа в интернет, поэтому их следует настраивать через ВМ jump-server-vm с помощью RDP.

Подключитесь к ВМ jump-server-vm с помощью RDP. Используйте логин Administrator и ваш пароль.

Запустите RDP и подключитесь к виртуальной машине ad-vm-a .

Запустите PowerShell и задайте статический адрес:

Создайте временную папку:

Установите роли Active Directory:

Создайте лес Active Directory:

Windows перезапустится автоматически. Снова откройте PowerShell.

Переименуйте сайт по умолчанию в ru-central1-a :

Создайте еще два сайта для других зон доступности:

Создайте подсети и привяжите их к сайтам:

Переименуйте сайт-линк и настройте репликацию:

Ссылка на основную публикацию
Adblock
detector