Резервный контроллер домена. Резервное копирование контроллеров домена с помощью Veeam. Передача роли «Хозяин схемы»
Структура организации следующая: есть домен для сотрудников под названием 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 и другого оставляем по-умолчанию:
Указываем пароль для восстановления каталогов. И хоть его надо в любом случае сохранить, я очень надеюсь, что он вам не пригодится:
Кажется на этом наши настройки закончились. Нажимаем далее и ждем, пока все сделается:
И на этом все. Репликация получилась, КД начал функционировать нормально. Еще совет для малоопытных админов – не торопитесь и делайте все последовательно. Могу также в качестве бонуса сообщить один нюанс. Загрузка КД и репликация с главным контроллером может происходить очень долго. Лично у нас все “поднялось” спустя несколько часов. Были моменты, когда казалось, что КД не работает как контроллер. Но мы набрались терпения и дождались результата. Все остальные действия моего плана выполнились практически без каких-либо происшествий. Их можно посмотреть в интернете, информации полно.
Друзья! Вступайте в нашу
Задача состоит в передаче ролей 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 у пользователей поменяются.
Основной контроллер домена является самым важным компьютером домена. Он реализует политику безопасности домена и является основным местом хранения базы данных учетных записей. Он может также являться основным держателем совместно используемых ресурсов домена. Однако совсем необязательно, а иногда даже нежелательно, чтобы основной контроллер домена выполнял данную функцию.
Изменения в базе данных учетных записей пользователей делаются только на основном контроллере домена, а затем переносятся на резервные контроллеры домена, где хранятся копии базы данных, доступные только для чтения. Когда вы регистрируетесь в качестве администратора, все сделанные вами изменения производятся в базе данных на основном контроллере домена, даже если в действительности вы работаете на другом компьютере. Средство, с помощью которого осуществляется работа с учетными записями пользователей, называется User Manager for Domains (Диспетчер пользователей доменов). При запуске этой программы вы выбираете не сервер, на котором надо зарегистрироваться, а домен, который хотите администрировать,
Если основного контроллера домена в сети нет, пользователи все равно смогут регистрироваться и работать, если вы создали один или несколько резервных контроллеров домена и по крайней мере один из них доступен. Однако вы не сможете вносить какие-либо изменения в учетные записи пользователей или групп домена, добавлять в домен новых пользователей или новые группы, а также удалять их, пока основной контроллер домена не объявится снова или пока вы не сделаете один из резервных контроллеров основным.
Резервный контроллер домена
Домен Windows NT Server может, а в большинстве случаев должен включать в себя хотя бы один резервный контроллер домена. Каждый резервный контроллер домена содержит копию базы данных учетных записей и может обрабатывать вход (регистрацию) пользователей и подтверждать их права на доступ к ресурсам. Это позволяет довольно просто обеспечить резервирование критичных совместно используемых ресурсов системы на случай катастрофических неполадок на основном контроллере домена. Один из резервных контроллеров домена может быть переведен в режим основного контроллера, и сеть продолжит нормально функционировать (не будет лишь доступа к ресурсам, которые физически находились на основном контроллере домена). В небольшом домене с ограниченным числом пользователей наличие резервного контроллера домена не так уж и обязательно, но все же лишним это не будет. Если в сети имеется только основной контроллер домена, то вся сеть станет неработоспособна, когда (это обязательно случится, поэтому мы не употребляем здесь слово «если») этот сервер окажется недоступным.
Компьютер под управлением Windows NT Server может выполнять функцию основного контроллера домена, резервного контроллера домена или вообще не являться контроллером домена. Впрочем, на компьютере, который будет использоваться в качестве рабочей станции, лучше установить другую операционную систему. Рабочая станция будет работать быстрее, а обращаться с ней будет проще.
Рабочая станция
Рабочие станции могут работать под управлением MS-DOS, OS/2, Microsoft Windows 3.x, Windows для рабочих групп, Microsoft Windows 95, Microsoft Windows NT Workstation или Macintosh OS. Для MS-DOS, OS/2, Macintosh OS и Windows 3.x вам понадобятся клиентские лицензии (и сетевое программное обеспечение). В остальных операционных системах сетевое программное обеспечение входит в состав базовой поставки. будем далее считать, что в основном на рабочих станциях установлена Windows 95. Накладные расходы и требования к аппаратной части для Windows 95 значительно ниже, чем для Windows NT Workstation.
Исключением, когда не следует использовать Windows 95 на рабочей станции, будет случай использования станции для разработки программного обеспечения. На этих рабочих станциях выгоднее использовать Windows NT Workstation ввиду ее большей устойчивости и изоляции процессов. Windows NT Workstation обычно требует значительно больше памяти и вычислительной мощности, чем минимально необходимо для Windows 95. И хотя Windows 95 лучше предшествующих версий Windows защищена от некорректно ведущих себя процессов, вышедшая из-под контроля программа все еще может привести к завершению работы самой системы. Для Windows NT Workstation вероятность этого значительно ниже.
Некоторые рабочие станции могут входить в состав рабочей группы, не принадлежа при этом домену. Windows 95, Windows NT Workstation и Windows для рабочих групп предоставляют пользователю возможность работать в составе рабочей группы или домена. Но для того чтобы воспользоваться преимуществами доменной структуры, компьютеры должны быть настроены так, чтобы выполнялся вход в домен. Действуя в рамках рабочей группы, они не смогут использовать базу данных учетных записей пользователей Windows NT Server и пользоваться ресурсами, доступ к которым контролируется с помощью этой базы.
Доверительные отношения
В сети, состоящей из двух и более доменов, каждый домен действует как отдельная сеть со своей базой данных учетных записей. Однако даже в наиболее жестко структурированной организации некоторым пользователям из одного домена могут понадобиться какие-нибудь ресурсы из другого домена.
Для того, чтобы не заводить учетную информацию на одного и того же пользователя в разных доменах, между доменами можно установить доверительные отношения (trust relationship).
Доверяет свои ресурсы Имеет базу данных пользователей домен
и сведения о ресурсах другого домена и
правах доступа к ним своих пользователей
Доверяющий домен (trusting) предоставляет доступ к своим ресурсам пользователям из другого домена (доверяемого или trusted). Иногда доверяющий домен называется ресурсным, так как в нем находятся серверы, к ресурсам которых получают доступ пользователи, учетная информация которых находится в контроллерах доверяемого домена, который называется поэтому учетным
В Windows NT Server имеются все средства для настройки многодоменной сети с установлением между контроллерами доменов доверительных отношений, что позволяет защитить чувствительные области ресурсов, избавив при этом пользователей от излишних подробностей и множества паролей.
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.
