Microsoft Active Directory является стандартом в инфраструктуре, где требуется аутентификация пользователей и централизованное управление. Почти невозможно представить себе, как системные администраторы справлялись бы со своей работой без этой технологии. Однако использование Active Directory не только приносит большую пользу, но и налагает большую ответственность, требуя значительного времени и понимания процессов работы. Поэтому я предлагаю вашему вниманию несколько cтатей, которые расскажут, как успешно выполнять бэкап и восстановление Active Directory с помощью решений Veeam. В частности, я поясню, как Veeam помогает делать копии контроллеров домена (DC) или отдельных объектов AD и при необходимости восстановить их.
А начну я с того, что в сегодняшнем посте расскажу о возможностях бэкапа физических и виртуальных контроллеров домена, предоставляемых Veeam, и о том, что необходимо помнить во время бэкапа. За подробностями - под кат.
Сервисы Active Directory разработаны с учетом избыточности, поэтому привычные правила и тактики бэкапа необходимо адаптировать соответствующим образом. В данном случае будет неправильно использовать ту же политику бэкапа, что уже работает для серверов SQL или Exchange. Вот несколько рекомендаций, которые могут помочь при разработке политики бэкапа для Active Directory:
- Выясните, какие контроллеры домена в вашей среде выполняют роли FSMO (Flexible Single Master Operations).
Полезно: простая команда для проверки через командную строку: >netdom query fsmo
Выполняя полное восстановление домена, лучше начать с контроллера домена с наибольшим числом ролей FSMO - обычно это сервер с ролью эмулятора основного контроллера домена (PDC). В противном случае после восстановления вам придется переназначать соответствующие роли вручную (при помощи команды ntdsutil seize). - Если вы хотите защитить отдельные объекты, то у вас нет необходимости в бэкапе всех контроллеров, имеющихся на продакшен-площадке. Для восстановления отдельных объектов будет достаточно одной копии базы данных Active Directory (файл ntds.dit).
- Всегда есть возможность снизить риск случайного или намеренного удаления или изменения объектов AD. Можно порекомендовать делегирование административных полномочий, ограничение доступа с повышенными правами, а также репликацию на резервную площадку с предустановленной задержкой.
- Обычно рекомендуется выполнять бэкап контроллеров доменов поочередно и так, чтобы оно не пересекалось с репликацией DFS. Хотя современные решения знают, как решать эту проблему.
- Если вы используете виртуальную среду VMware, контроллер домена может быть недоступен по сети (например, он находится в зоне DMZ). В этой ситуации Veeam переключится на соединение через VMware VIX и сможет обработать этот контроллер.
Если у вас виртуальный DC
Так как сервисы Active Directory потребляют малую часть ресурсов системы, то контроллеры домена обычно становятся первыми кандидатами для виртуализации. Чтобы защитить виртуализованный контроллер с помощью Veeam, нужно установить и настроить Veeam Backup & Replication.Важно!
Решение работает с ВМ контроллера домена на Windows Server 2003 SP1 и выше, минимальный поддерживаемый функциональный уровень леса - Windows 2003. Учетной записи нужно предоставить права администратора Active Directory –- можно работать под учетной записью администратора предприятия или домена.
Процесс установки и настройки Veeam Backup & Replication уже неоднократно освещался – например, в видео, подготовленном системным инженером Veeam, поэтому обойдемся без подробностей. Предположим, что все настроено и готово к работе. Теперь нужно создать задание бэкапа контроллера домена. Процесс настройки довольно прост:
Резервную копию можно дополнительно сохранить в облако с помощью поставщика услуг Veeam Cloud Connect (VCC). Также ее можно перенести в другой репозиторий резервных копий, используя задания архивирования резервных копий или функционал архивирования на магнитную ленту. Самое главное, что теперь резервная копия хранится в надежном месте, и из нее в любой момент можно восстановить нужные данные.
Если у вас физический DC
Честно говоря, я надеюсь, что вы идете в ногу со временем, и в вашей компании контроллеры домена давно виртуализованы. Если это не так, то надеюсь, что вы их регулярно обновляете и они работают на относительно современных версиях ОС Windows Server -Windows Server 2008 (R2) и выше. (О нюансах работы с более старыми системами будет отдельная статья).Итак, у вас есть один или несколько физических контроллеров домена, работающих под Windows Server 2008 R2 и выше, и вы хотите их защитить. В этом случае вам потребуется Veeam Endpoint Backup - решение, предназначенное специально для защиты данных физических компьютеров и серверов. Veeam Endpoint Backup копирует нужные данные с физической машины и сохраняет их в файл резервной копии. В случае аварии вы сможете восстановить данные «на голое железо» или выполнить восстановление на уровне логического диска. Кроме того, вы сможете восстанавливать отдельные объекты с помощью Veeam Explorer для Microsoft Active Directory.
Делаем следующее:
Вот и все: бэкап выполнен, контроллер домена под защитой. Перейдите в репозиторий и найдите нужную резервную копию или цепочки резервных копий.
Если вы настроили репозиторий Veeam Backup & Replication в качестве целевого хранилища для резервных копий, то вновь созданные резервные копии будут отображаться в панели инфраструктуры Backups > Disk, пункт Endpoint Backups.
Вместо заключения
Разумеется, успешный бэкап - это хорошее начало, но далеко не все. Очевидно, что резервная копия ничего не стоит, если из нее нельзя восстановить данные. Поэтому в следующей статье я расскажу о различных сценариях восстановления Active Directory, включая восстановление контроллера домена, а также восстановление отдельных удаленных и измененных объектов с помощью собственных инструментов Microsoft и Veeam Explorer для Active Directory.Как вы знаете, службы Active Directory Domain Services (AD DS) устанавливаются на сервере, который называется контроллер домена (DC). В активный каталог домена AD можно добавить десятки дополнительных контроллеров для балансировки нагрузки, отказоустойчивости, уменьшения нагрузки на WAN каналы и т.д. Все контроллеры домена должны содержать одинаковую базу учетных записей пользователей, учетных записей компьютеров, групп и других объектов LDAP каталога.
Для корректной работы всем контроллерам домена необходимо синхронизироваться и копировать информацию между собой. Когда вы добавляете новый контроллер домена в существующий домен, контроллеры домена должны автоматически синхронизировать данные между собой. Если новый контроллер домена и существующий DC находятся в одном сайте, они могут легко реплицировать данные между собой. Если новый DC находится на удаленном сайте, то автоматическая репликация не так эффективна. Поскольку репликация будет идти через медленные (WAN каналы), которые как правило стоят дорого и скорость передачи данных по ним не велика.
В этой статье мы покажем, как добавить дополнительный контроллер домена в существующий домен Active Directory ().
Добавление дополнительного контроллера домена в существующий домен AD
Прежде всего, нам нужно установить роль Active Directory Domain Services на сервере, который будет новым DC.
Установка роли ADDS
Прежде всего, откройте консоль Server Manager. Когда откроется Server Manager, нажмите «Add roles and features», чтобы открыть консоль установки ролей сервера.
Пропустите страницу «Before you Begin». Выберите «Role-based or featured-based installation» нажмите кнопку «Next». На странице «Server Selection» снова нажмите кнопку «Next».
Выберите роль Active Directory Domain Services . В открывшемся окне нажмите кнопку «Add Features», чтобы добавить необходимые инструменты управления Active Directory Management Tools.
Когда процесс установки будет завершен, перезагрузите сервер, войдите в систему под администратором и выполните следующие действия.
Настройка дополнительного контроллера домена
Теперь в мастере установки ролей нажмите ссылку «Promote this server to a domain controller ».
Выберите «Add a domain controller to an existing domain», ниже укажите имя вашего домена AD. Если вы авторизованы под обычным пользователем, вы можете изменить учетные данные на администратора домена. Нажмите кнопку «Select», откроется новое окно, выберите имя вашего домена и нажмите «Ok», затем «Next».
На странице Domain Controller Options, можно выбрать, что нужно установить роль DNS-сервера на вашем DC. Также выберите роль Global Catalog. Введите пароль администратора для режима DSRM и подтвердите его, затем нажмите кнопку «Next».
На странице Additional options укажите сервер, с которым вы хотите выполнить первоначальную репликацию базы Active Directory (с указанного сервера будет скопирована схема и все объекты каталога AD). Вы можете сделать снимок (snapshot) текущего состояния Active Directory на одном из контроллеров домена и применить его на новой машине. После этого база AD этого сервера будет представлять собой точную копию имеющегося контроллера домена. Подробнее о функции Install From Media (IFM) – установки нового DC с носителя в одной из следующих статей ():
На страницах «Paths and Review options» нам ничего не придется настраивать, пропустите их, нажав кнопку «Next». На странице «Prerequisite», если вы видите какую-либо ошибку, проверьте и выполните все указанные требования, затем нажмите кнопку «Install».
Настройка репликации между новым и имеющимся контроллером домена
Мы почти закончили, теперь проверим и запустим репликацию между первичным DC (DC01..сайт). При копировании информации между этими двумя контроллерами домена данные базы Active Directory будут скопированы из DC01..сайт. После завершения процесса все данные корневого контроллера домена появятся на новом контроллере домена.
В «Server Manager» выберите вкладку «Tools» затем пункт «Active directory sites and services».
В левой панели разверните вкладку Sites -> Default-First-Site-Name -> Servers. Оба новых DC находятся в одном сайте AD (это подразумевает, что они находятся в одной подсети, либо сетях, соединенных высокоскоростным каналом связи). Затем выберите имя текущего сервера, на котором вы сейчас работаете, затем нажмите «NTDS Settings». В моем случае DC01 является корневым контроллером домена, в данный момент консоль запущена на DC02, который будет дополнительным контроллером домена.
Щелкните правой кнопкой мыши по элементу с именем «automatically generated». Нажмите «Replicate now». Появится предупреждение о запуске репликации между корневым контроллером домена и новым контроллером домена.
Сделайте то же самое для DC01. Разверните вкладку DC01 и нажмите «NTDS Settings». Щелкните правой кнопкой мыши на «automatically generated», затем нажмите «Replicate now». Оба сервера реплицируются друг с другом, и все содержимое DC01 будет скопировано в DC02.
Задача состоит в передаче ролей c основного контроллера домена Windows Server 2008 с Active Directory (AD) на резервный контроллер домена Windows Server 2012. Резервный контроллер домена (DCSERVER) должен стать основным, а тот, который сейчас основной (WIN-SRV-ST) должен стать резервным и в перспективе демонтироваться. Все действия выполняются на резервном сервере DCSERVER. Оба сервера работоспособны и «видят» друг друга.
Перед началом передачи ролей необходимо проверить, какой из серверов является хозяином ролей. Для этого вызываем командную строку Win+R >> cmd и вводим команду:
netdom query fsmo – запрос на определение хозяина ролей FSMO
По результату выполнения команды видно, что хозяин всех ролей контроллер домена, который у нас называется Win-srv-st, он сейчас основной.
Краткая справка:
FSMO (англ. Flexible single-master operations - «операции с одним исполнителем») - типы выполняемых контроллерами домена AD операций, требующие обязательной уникальности сервера, выполняющего данные операции (wiki). Это значит, что данные роли могут быть только на одном контроллере домена.
Хозяин схемы (Schema Master) – отвечает за возможность изменения существующей схемы AD (например добавление Exchange и тп.)
Хозяин именования доменов (Domain Naming Master) – добавляет/убавляет домены (если их несколько в одном лесу).
PDC (Primary Domain Controller Emulator) — эмулятор основного контроллера домена. Отвечает за смену паролей их репликацию, изменение групповой политики, синхронизацию время и совместимость с ранними версиями Windows.
Диспетчер пула RID (Relative ID Master) – создает ID для каждого объекта AD.
Хозяин инфраструктуры (Infrastructure Master) – передает информацию об объектах AD между другими контроллерами домена (например, когда пользователи из одного домена попали в соседний).
Есть еще одна очень важная роль – Global Catalog (GC) – хотя она не является FSMO т.к. её держателем могут быть несколько DC одновременно, без неё невозможно нормальное функционирование домена и его служб. GC хранит у себя копии всех объектов AD и частичные реплики других доменов леса. Он позволяет находить пользователям и приложениям объекты в любом домене существующего леса, отвечает за проверку подлинности имени пользователя, предоставляет сведения о членстве пользователя в универсальных группах, может общаться с другим доменным лесом.
Учетная запись должна как минимум входить в группы:
— администраторы домена;
— администраторы предприятия;
— администраторы схемы.
Передача ролей хозяина операций RID , PDC и Инфраструктуры.
Нажимаем правой кнопкой мыши на имя домена в каталоге и выбираем пункт – Хозяева операций…
В открывшемся окне видим, что хозяином во всех трех вкладках RID, PDC и Инфраструктура является Win-Srv-St.SCRB.local. Ниже написано: Чтоб передать роль хозяина операций следующему компьютеру, нажмите кнопку «Изменить». Убеждаемся что в самой нижней строчке имя сервера, которому мы хотим передать роль хозяина и жмем изменить. Делаем это же на всех трех вкладках.
В появившемся вопросе подтверждения жмем Да.
Роль хозяина успешно передана. ОК. Хозяином операций стал DCSERVER.SCRB.local.
Делаем то же самое на оставшихся двух вкладках PDC и Инфраструктура.
Передача роли «Хозяин именования доменов».
Выбираем в AD DS нашего сервера пункт Active Directory – домены и доверие.
Правой кнопкой мыши жмем по названию и выбираем, как и ранее, строчку Хозяин операций…
Проверяем имена серверов, нажимаем изменить.
Хозяином операций стал DCSERVER.
Передача роли «Хозяин схемы».
Первоначально зарегистрируем в системе библиотеку управления схемой AD с помощью команды regsvr32 schmmgmt.dll
Нажимаем WIN+R >> cmd
Вводим команду и получаем ошибку: Модуль «schmmgmt.dll загружен, но не удалось выполнить вызов DLLRegisterServer, код ошибки: 0x80040201.
Ошибка, потому что командную строку нужно запускать от имени администратора. Сделать это можно, например из меню Пуск. Выбираем командную строку и нажимаем запуск от имени администратора.
Еще раз вводим команду regsvr32 schmmgmt.dll. Теперь всё прошло как нужно.
Нажимаем WIN+R, пишем mmc
В открывшейся консоли выбираем Файл >> Добавить или удалить оснастку… (или жмем CTRL+M)
Среди доступных оснасток выбираем Схема Active Directory, нажимаем добавить. ОК.
В корне консоли выбираем добавленную оснастку, нажимаем на неё правой кнопкой мыши и выбираем строчку «Хозяин операций…»
Текущим хозяином схемы значится Win-Srv-St.SCRB.local. В нижней строчке тоже его имя.
При нажатии кнопки «Сменить» появляется сообщение: Текущий контроллер домена Active Directory является хозяином операций. Чтоб передать роль хозяина другому DC, нужно нацелить на этот DC схему Active Directory.
Возвращаемся к оснастке и выбираем ПКМ Сменить контроллер домена Active Directory.
В открывшемся окне выбираем нужный сервер. В нашем случае DCSERVER.SCRB.local. ОК.
Консоль выдаст сообщение: Оснастка схемы Active Directory не подключена к хозяину операций схемы. Выполнение изменений невозможно. Изменения схемы могут быть сделаны только в схеме владельца FSMO.
При этом в названии оснастки появился нужный нам сервер.
Снова жмем на неё правой кнопкой мыши и переходим к хозяину операций. Проверяем названия серверов, жмем кнопку «Сменить».
Роль хозяина операций успешно передана. ОК.
Для того, чтоб убедиться в передаче ролей, введем еще раз в командной строке netdom query fsmo
Хозяином ролей теперь является DCSERVER.SCRB.local.
Глобальный каталог.
Чтоб уточнить, где расположен GC нужно пройти по пути: AD – Сайты и службы >> Sites >>Default-First-Site-Name >> Servers >> DCSERVER
В появившейся службе NTDS Settings жмем ПКМ и выбираем – Свойства.
Если стоит галочка напротив надписи Глобальный каталог, то значит что он на этом сервере. А вообще, в нашем случае GC расположен на обоих DC.
Настройка DNS .
В настройке DNS нового основного DC пишем вот что:
В первой строчке IP адрес бывшего основного DC (Win-Srv-St), который теперь стал резервным 192.168.1.130.
Во второй строчке 127.0.0.1 т.е. самого себя (можно и свой IP написать, чтоб по конкретнее).
В том контроллере домена который у нас стал резервным записано так:
В первой строчке IP основного DC.
Во второй строчке свой IP. Все работает.
DHCP у нас в сети не работает по причине местных обстоятельств, по этому перенастраивать его не нужно. Зато нужно пройти 200 ПК и вручную прописать новый DNS. По этой причине решено пока что не демонтировать старый контроллер домена. За полгода планомерных обходов DNS у пользователей поменяются.
Структура организации следующая: есть домен для сотрудников под названием domain.int, есть также и его поддомен для других нужд – subdomain.domain.int. Возникла задача перевести существующий поддомен под управлением Windows Server 2003 R2 на Windows Server 2008 R2. Причем главный домен уже переведен.
Просто накатить сверху систему нельзя – 2003 R2 является 32-битной версией, а 2008 R2, соответственно, – 64-битная. А было бы здорово. Выбор невелик, поэтому решили сделать следующее:
- Устанавливаем дополнительный контроллер домена (КД) на Windows Server 2008 R2
- Новый контроллер должен иметь роли глобального каталога и DNS
- Проверяем работу и репликацию обоих контроллеров
- Указываем, что новый КД (2008) – хозяин операций
- Удаляем из схемы старый КД (2003)
- Проверяем работу и начинаем подготовку к настройке уже реально другого дополнительного КД, чтобы на выходе получить два КД под управлением 2008 R2
- Забываем, что когда-то у нас в сети был КД под управлением 2003 R2
Почему решили перевести КД на другую схему, думаю, всем ясно. На дворе уже 2013 год, 2014 не за горами. Почему бы не воспользоваться проверенными и более новыми технологиями? Windows Server 2012 на момент написания статьи пока не вышел в релизе R2. А исходя из многолетнего опыта использования Microsoft, не стоит что-то внедрять на том, что вышло совсем недавно. К тому же немного бесит, что статей в интернете по новым продуктам мало. Именно поэтому сделали выбор на системе Windows Server 2008 R2. В данной статье я буду описывать последовательные действия для 1 и 2 пункта моего плана.
Что подвигло написать статью? Ответ прост: в интернете мало статей по субдоменам. И пускай ничего супер-естественного в настройке нет. Зато наши читатели узнают, что все проходит достаточно просто и последовательно, как по аналогии при лесе с одним доменом. А наш сайт любит хоть и маленькие, но все же эксклюзивы. К тому же, излагаться все будет просто и на обычном языке, понятным даже для самых маленьких админов.
Для начала надо подготовить площадку для будущего дополнительного КД. Проверяем активацию, часовой пояс, брандмауер, сетевые интерфейсы, имя компьютера и другое:
Начинаем установку этой роли:
Заметили, что автоматом поставился компонент.Net Framework 3.5? Поэтому после всех установок сразу “подхватываются” обновления:
Ну вот и все установилось. Даже не пришлось перезагружаться. Я начинаю приятно удивляться Microsoft. Посудите сами – одна из самых серьезных ролей и компонент только что установились, да еще и обновления, а перезагрузка не требуется. Заметили самую первую ошибку? Причина ошибки написана выше, а именно то, что надо бы настроить наш будущий КД:
Поэтому прямо оттуда или из режима командной строки запускаем утилиту DCPROMO.EXE:
Не надо нажимать нам “расширенный режим”. Делаем все по стандартно. По-хорошему, в лучших традициях Microsoft все должно быть по сценарию Далее+Далее+Финиш=Все_работает. Посмотрим как это будет дальше. Соглашаемся с первым окном приветствия:
Затем подсказываем мастеру, что у нас будет добавочный КД:
Затем прописываем имя домена. Можно главный domain.int, а можно и поддомен – subdomain.domain.int. И учетную запись администратора домена само собой. Вы же под ней и делаете?
Теперь главное не перепутать и указать уже точно, в каком домене будем работать. Нам надо поддомен subdomain.domain.int:
Ну вот… начинаются приключения. Так и знал:
Сам виноват, не подготовил домен для перехода. Зато все теперь последовательно все исправим. Идем на главный КД под управлением Windows Server 2003 R2 и вставляем туда диск с нашей системой 2008 R2. Я скопировал все утилиты на диск С, но это необязательно. Запускаем утилиту adprep /domainprep:
Вот я снова невнимательный. Утилита-то 64-битной версии. Поэтому пробуем на 32-битной редакции. Кажется получилось, хотя могли бы и вывести сообщение об успехе:
Теперь запускаем снова утилиту DCPROMO и проделываем все тоже самое. Вместо ошибки получаем следующее окно мастера. Значит та утилита все-таки помогла подготовить домен. Мастер нас спрашивает, какой точно сайт нам нужен. У меня их 3, у вас может быть другое количество. Название не спутаешь, поэтому с уверенностью кликаем “далее”:
Затем мастер спрашивает, добавить ли из будущему КД роли DNS и Global Catalog. Это пригодится будущем, поэтому соглашаемся. Пугаться не надо: в сети может быть несколько DNS и глобальных каталогов. Это, кстати, очень хорошо с точки зрения отказоустойчивости:
Системные папки для хранения баз данных Active Directory и другого оставляем по-умолчанию:
Указываем пароль для восстановления каталогов. И хоть его надо в любом случае сохранить, я очень надеюсь, что он вам не пригодится:
Кажется на этом наши настройки закончились. Нажимаем далее и ждем, пока все сделается:
И на этом все. Репликация получилась, КД начал функционировать нормально. Еще совет для малоопытных админов – не торопитесь и делайте все последовательно. Могу также в качестве бонуса сообщить один нюанс. Загрузка КД и репликация с главным контроллером может происходить очень долго. Лично у нас все “поднялось” спустя несколько часов. Были моменты, когда казалось, что КД не работает как контроллер. Но мы набрались терпения и дождались результата. Все остальные действия моего плана выполнились практически без каких-либо происшествий. Их можно посмотреть в интернете, информации полно.
Друзья! Вступайте в нашу
