Восстановление контроллера домена в режиме «non-authoritative»
Собираясь восстанавливать контроллер домена, необходимо сначала определить, будет ли достаточен режим «non-authoritative» или потребуется воспользоваться режимом «authoritative». Разница между этими двумя режимами заключается в том, что при режиме восстановлении «non-authoritative» контроллер домена понимает, что он был в течение некоторого времени отключен. Поэтому он позволяет другим контроллерам домена обновить его базу данных, внеся в нее последние изменения, произошедшие во время его отсутствия. При «authoritative» восстановлении контроллер считает, что только на нем имеется истинно верная база данных, поэтому именно он получает полномочия на обновление баз данных других контроллеров домена на основе своих данных.
В большинстве сценариев восстановления вам потребуется режим «non-authoritative», поскольку в среде имеется несколько контроллеров домена. Кроме того, «authoritative» восстановление контроллера домена может привести к новым проблемам. Именно на этом основана логика Veeam Backup & Replication: по умолчанию выполняется «non-authoritative» восстановление DC, поскольку считается, что инфраструктура выстроена с избыточностью и включает в себя несколько контроллеров домена. Чтобы выполнить «authoritative» восстановление с помощью Veeam, необходимо осуществить некоторые дополнительные действия, которые описаны ниже.
ПРИМЕЧАНИЕ. Еще один распространенный вариант действий при отказе контроллера домена — распределить его роли между другими контроллерами и очистить метаданные, если восстановление маловероятно. В этом случае вы поручаете другим DC выполнять функции отказавшего, и вам не нужно его восстанавливать.
Давайте вернемся к файлам резервных копий, которые были описаны в предыдущей статье. Восстановить контроллер домена из резервной копии Veeam Backup & Replication очень легко. Для этого нужно:
- Выбрать мастер восстановления в пользовательском интерфейсе
- Найти нужный контроллер домена
- Выбрать в меню восстановления вариант восстановления ВМ целиком (Restore Entire VM)
- Затем указать точку восстановления
- Выбрать исходное или новое место восстановления
- Завершить процедуру
Самое замечательное здесь, что благодаря обработке данных с учетом состояния приложений при создании резервной копии, вам больше ничего не потребуется делать. Veeam распознает контроллер домена в указанной ВМ и аккуратно восстановит его, используя особый алгоритм:
- Восстановление файлов и жестких дисков ВМ
- Загрузка ОС в специальном режиме восстановления доменных сервисов (DSRM mode)
- Применение настроек
- Перезапуск в обычном режиме
Контроллер домена будет знать о восстановлении из резервной копии и предпримет соответствующие действия: существующая база данных будет объявлена недействительной, и партнеры репликации смогут обновить ее, внеся наиболее свежую информацию.
Рис. 1. Veeam Backup & Replication: Восстановление ВМ целиком
Здесь можно прочитать о восстановлении «на голое железо» резервной копии с помощью Veeam Endpoint Backup. Вам потребуется заранее подготовленный аварийный загрузочный диск Veeam и доступ к самой резервной копии (на USB-носителе или сетевом диске). Помните, что в данном случае особая логика Veeam Backup & Replication использоваться не будет. После восстановления с помощью Veeam Endpoint Backup ваш контроллер домена загрузится в режиме восстановления. Вам нужно будет решить, хотите ли вы менять ключи реестра или сразу перезапустите ВМ в обычном режиме. Возможно, эта статья базы знаний будет полезна.
Рис. 2. Veeam Endpoint Backup: восстановление «на голое железо»
Procedure
The summary of the migration is this..Your Domain is currently using FRS to replicate the SYSVOL and NETLOGON folders between DCs. Your 2016 Domain Controller doesn’t like this. You are going to need to migrate the rest of the Domain Controllers to use the DFSR replication protocol. This is done in 4 stages:
Start State (0): This is most likely the state your environment is in. The domain is only replicating SYSVOL using FRS. Nothing to do here.
Prepared State (1): FRS continues to replicate SYSVOL, The environment prepares a temp SYSVOL folder to be used for DFSR replication. This temp SYSVOL folder is not used by any services.
Redirected State (2): DFSR and FRS are replicating SYSVOL in parallel. Both net shareable folder are capable of being used by services.
Eliminated State (3): Your environment is now solely using DFSR for replicating SYSVOL and FRS and its associated folder are removed.
Check Prerequisites
- Ensure your Domain is on a 2008 Domain Functional Level
- On a writeable domain controller in the domain that you want to migrate, open a command prompt window and type repadmin /ReplSum. The output should indicate no errors for all of the domain controllers in the domain.
- Use Registry Editor on each domain controller in the domain to navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters and verify that the value of the SysVol registry entry is Windows_folder\SYSVOL\sysvol, and that the value of the SysvolReady registry entry is 1.
- On each domain controller, click Start, point to Administrative Tools, and then click Services. In the Services window, on the Extended tab, verify that the DFS Replication service is listed with the values of Started in the Status column and Automatic in the Startup Type column.
Восстановление дерева SYSVOL
Иногда при восстановлении службы FRS может понадобиться восстановление дерева SYSVOL.
Данная процедура описана в документе Майкрософт Q315457
Но еще раз по пунктам весь процесс и с картинками:
1.Останавливаем службу ntfrs НА ВСЕХ КОНТРОЛЛЕРАХ ДОМЕНА командой net stop ntfrs;
2.Переписываем все файлы из c:\WINDOWS\SYSVOL\domain в какую-либо папку на том же самом диске. Данную процедуру я обычно делаю с помощью Total Commander, так как в нем есть возможность явно указать сохранение существующих прав при копировании или перемещении(«Копировать права доступа NTFS…»). Если будете пользоваться проводником, то копируйте только в пределах тома. По умолчанию в проводнике при копировании в пределах тома права сохраняются.
3.Из папок c:\WINDOWS\SYSVOL\domain\Policies и c:\WINDOWS\SYSVOL\domain\scripts очищаем все содержимое. В самом конце процесса в эти папки нужно будет вернуть содержимое из бэкапа.
Проверяем структуру всех папок. Должно быть вот так:
c:\WINDOWS\SYSVOL\domain\
c:\WINDOWS\SYSVOL\domain\Policies\
c:\WINDOWS\SYSVOL\domain\scripts\
c:\WINDOWS\SYSVOL\staging\
c:\WINDOWS\SYSVOL\staging\domain\
c:\WINDOWS\SYSVOL\staging areas\
c:\WINDOWS\SYSVOL\staging areas\test.com\
c:\WINDOWS\SYSVOL\sysvol\
c:\WINDOWS\SYSVOL\sysvol\test.com\
4.Проверяем junction points в папках :
- c:\WINDOWS\SYSVOL\staging areas
- c:\WINDOWS\SYSVOL\sysvol
Если их нет, восстанавливаем утилитой linkd.
Для папки c:\WINDOWS\SYSVOL\sysvol команда выглядит вот так:linkd C:\WINDOWS\sysvol\sysvol\test.com C:\WINDOWS\sysvol\sysvol
Для папкиC:\WINDOWS\sysvol\staging areas команда выглядит вот так: linkd «C:\WINDOWS\sysvol\staging areas\test.com» c:\windows\sysvol\staging\domain Кавычки в команде обязательны, так как в пути есть пробелы
5.Правим реестр. Выбираем самый «хороший» контроллер, который будет главным(авторитетным) при восстановлении. На авторитетном контроллере устанавливаем значение параметра BurFlags в значение D4 на остальных контроллерах D2. Параметр BurFlags есть во всех репликах, которые находятся в реестре в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets В моем случае реплики две.
Количество реплик в реестре зависит от того учувствует ли контроллер в репликации корня DFS(ссылок) или нет. На остальных контроллерах ставим D2.
6.Запускаем службу ntfrs командой net start ntfrs на главном(авторитетном) контроллере. Потом запускаем на всех остальных.
При успешном старте службы ntfrs на контроллере в системных событиях должна появиться событие 13516.
7.На главном(авторитетном) контроллере возвращаем содержимое папок c:\WINDOWS\SYSVOL\domain\Policies и c:\WINDOWS\SYSVOL\domain\scripts из бэкапа. Оно должно тут же реплицироваться на все остальные конроллеры. При копировании не забываем про права.
Для посетителей из РБ: оплата через ЕРИП: «Банковские, финансовые услуги»-«Банки, НКФО»-«Альфа-Банк»-«Пополнение счета | код услуги 4485471» На счет: BY05ALFA30147131190010270000
Configuring the DFS Replication
You’ve just completed a milestone of creating one shared folder (Public) under the Remote.local namespace and adding multiple folders. But now, if you try adding contents to the namespace, those contents will remain on the same server.
As a solution, you’ll configure the DFS Replication to ensure the added content gets replicated to all other servers for high availability.
To configure the DFS Replication:
1. On the DFS Management in the DCR1 server, right-click on Replication, and select New Replication Group to initiate adding a new replication group.
Initiating adding a new replication group
2. Next, choose a replication type that fits your need; there are two replication types as follows:
Multipurpose replication group – Provides replication between two servers or more, usually used for file sharing.
Replication group for data collection– Provides replication between two servers in different locations, usually for backup purposes between a branch office and the main office. This way, the backup software performs a backup of the replicated data instead of running the backup over the WAN.
For this tutorial, select the Multipurpose replication group option and click Next since you share folders between two servers.
Selecting the multiple replication group for replication type
3. Input a unique name for the replication group (Public Replication), and click Next.
Setting the replication group name
4. Now, on the Replication Group Members page, click on Add to locate the servers to add as members in the replication group, and click Next.
Adding servers as replication group members
5. Choose a topology to set how servers replicate the contents from one server to another.
There are three topology options as follows:
Hub and Spoke – This option requires at least three servers. One is the initial master Hub, and the other servers are the Spoke. This option is handy when the data originates from the Hub and should be replicated in multiple locations.
Each replica is a two-way replication with the Hub but spoke servers don’t replicate content between each other. But with this option, all replication stops until the Hub is up again when the Hub is down.
For this tutorial, select the Full Mesh topology, and click Next. This topology works well regardless if you have ten or fewer replication group members,
Selecting the full mesh topology
6. Next, select the Replicate continuously using specified bandwidth option to perform replications continuously. Keep the Bandwidth at default (Full), and click Next to create a bandwidth throttle.
But if you prefer a specific schedule for replications to execute, choose the Replicate during the specified days and times option instead.
Setting a replication schedule and bandwidth
7. Select the primary member (DCR), and click Next. The immediate member is the server that initializes the replication and sends the content to all other members.
Ensure the destination folder on different nodes is empty as the content from the primary member is authoritative during the initial replication.
Setting the primary replication group member
8. On the Folder to Replicate page, click on Add, and a pop-up window appears where you can select a folder to replicate.
Initiating adding a folder to replicate
9. Click on Browse to locate the folder to add for replication, which is the primary source of the content to replicate to other nodes, and click OK.
Note that you can only add a folder from the primary member you selected in step seven.
Locating a folder to add for replication
10. After adding the folder to replicate, click on Next.
Verifying the folder to replicate
11. Now, click on Edit, which opens a window where you can specify the location to store the replicated content in the other member server.
Editing the local replication path
12. Edit the replication settings with the following:
Select the Enable option to enable the replication for this server
Click on Browse and locate the local path to store the replicated data.
Click on OK to save the modified settings.
Click on OK to save the modified settings.
13. After setting the local path, click Next to confirm the modified settings.
Confirming modified local path settings
14. Review the selected settings, and click on Create to finalize creating the new replication group.
Creating the new replication group
15. Finally, click on Close once the replication group is created to close the wizard.
Congratulation! You’ve successfully created your DFS Replication.
Closing the replication group wizard
Процедура устранения проблем FRS
-
Проверьте свободное пространство диска на компьютере A (исходный каталог, каталог постановок и раздел базы данных) и компьютере B (раздел назначения, раздел preinstall и раздел базы данных). Посмотрите на следующие события в viewer событий:
-
ID события: 13511
База данных находится вне дискового пространства.
-
ID события: 13522
Каталог постановок заполнен. Это может вызвать исходящие партнеры, которые не подключены некоторое время. Удалите подключение и остановите и перезапустите FRS, чтобы принудительно удалить файлы постановок.
-
-
Создайте тестовый файл на компьютере B и проверьте его репликацию на компьютер A.
-
Убедитесь, что компьютер A и компьютер B доступны в сети. Так как FRS использует полностью квалифицированное доменное имя (FQDN) членов реплики, необходимо сначала проверить использование команды ping, указывав полное имя реплик проблемы.
С компьютера A отправьте команду ping с FQDN компьютера B. С компьютера B отправьте команду ping в FQDN компьютера A. Убедитесь, что адреса, возвращенные командой ping, такие же, как и адреса, возвращенные командой с помощью командной строки конечного компьютера.
-
Доступ к консоли администрирования Services, следуя следующим шагам:
-
Нажмите кнопку Пуск и выберите пункт Выполнить.
-
В поле Open введите services.msc.
Подтверди, что FRS работает на обоих компьютерах. Если служба не запущена, просмотрите контейнер FRS для просмотра событий (расположенный в файле Eventvwr.msc) на компьютере с проблемой.
-
-
Проверка подключения удаленного вызова процедуры (RPC) между компьютером A и компьютером B. Подходящим тестом может быть открытие просмотра событий на компьютере B с компьютера A (который использует RPC). Проверьте журналы событий FRS на обоих компьютерах. Если ID события 13508 присутствует, может возникнуть проблема со службой RPC на компьютере или с созданием безопасного подключения между компьютером A и компьютером B.
-
Чтобы проверить расписание репликации объекта Подключения, используйте консоль Active Directory Sites and Services. Убедитесь, что репликация включена между компьютером A и компьютером B и включено подключение. Объект Connection — это входящий объект под объектом NTFRS_MEMBER компьютера B. Для объема системы (SYSVOL) объект Connection находится в папке Sites\Site_name\Servers\Server_name\Ntds Параметры\Connection_name.
-
Для Dfs см. ссылки на подключение пользователей и компьютеров Active Directory (AD). Откройте пользователей ИД и компьютер, щелкните Просмотр из меню и убедитесь, что Параметры расширенный доступ. Перейдите к контейнеру System. Расположение объектов Подключения находится в папке System\File Replication Service\DFS Volumes.
-
Проверьте, заблокирован ли файл на сервере происхождения (доступ к нему невозможно получить) на любом компьютере. Если файл заблокирован на компьютере B, чтобы frS не считыла файл, FRS не может создать файл постановки, что задерживает репликацию. Если файл заблокирован на компьютере A, чтобы FRS не обновлял файл, FRS продолжает повторное обновление до тех пор, пока оно не будет успешно. Интервал повторного отрезка составляет от 30 до 60 секунд.
-
Проверьте, был ли исходный файл исключен из репликации. Подтвердим, что файл не шифрует файловую систему (EFS), соединение файловой системы NTFS (NTFS) или исключается фильтром файла или папки на исходивом члене реплики. Если какие-либо из этих ситуаций верны, FRS не реплицирует файл или каталог.
-
Если все предыдущие условия выполнены, возможно, вам придется изучить файлы журналов, созданные для FRS. Файлы журнала находятся в папке %Systemroot%\Debug. Имена файлов перечислены из NtFrs_001.log в NtFrs_005.log.
Как настроить параметры групповой политики LAPS?
Затем вам нужно создать новый объект GPO и сделать его сопряжение с OU, содержащим компьютеры, на которых вы хотите управлять паролями локальных администраторов.
Для упрощения управления GPO вы можете скопировать файлы административных шаблонов LAPS. (%WINDIR%\PolicyDefinitions\AdmPwd.admx and %WINDIR%\PolicyDefinitions\en-US\AdmPwd.adml) в центральное хранилище групповой политики – \\ДОМЕН\Sysvol\Policies\PolicyDefinition.
Создайте политику с именем Password_Administrador_Local, используя следующую команду:
Register-AdmPwdWithGPO -GpoIdentity: Password_Administrador_Local
Откройте эту политику в консоли управления политикой домена (gpmc.msc) и перейдите в следующий раздел GPO: Computer Configuration → Policies → Administrative Templates → LAPS (в русскоязычной версии это «Конфигурация компьютера → Политики → Административные шаблоны → LAPS».
Как видим, есть 4 настраиваемых параметра. Настройте их, как показано ниже:
- Enable local admin password management: Enabled (Включить управление паролями локального администратора: Включено) (включает политику управления паролями LAPS);
- Password Settings: Enabled (Настройки пароля: Включено) – политика устанавливает сложность, длину и возраст пароля (аналогично требованиям политики паролей пользователей Active Directory);
- Сложность: большие буквы, маленькие буквы, цифры, специальные символы
- Длина: 12 символов
- Возраст: 30 дней
- Name of administrator account to manage: Not Configured (Имя учетной записи администратора для управления: Не настроена) (здесь вы можете указать имя учётной записи администратора для изменения пароля. По умолчанию меняется пароль встроенных учётных записей администратора с SID-500);
- Do not allow password expiration time longer than required by policy: Enabled (Не допускать истечения срока действия пароля дольше, чем требуется политикой: Включено)
Назначьте политику Password_Administrador_Local для подразделения Desktops OU.
Рекомендуемое максимальное количество контроллеров домена в домене
Чтобы обеспечить надежное восстановление SYSVOL, мы рекомендуем ограничить 1200 контроллеров домена на домен. Если ожидается, что какой-либо домен Active Directory в вашей сети превысит 800 контроллеров домена, и на этих контроллерах доменов размещены зоны, интегрированные в Active Directory (DNS), то нужно будет вносить некоторые изменения в DNS. В зоне DNS, интегрированной в Active Directory, имена DNS представлены объектами dnsNode, а записи DNS хранятся в виде значений в многозначном атрибуте dnsRecord объектов dnsNode, что приводит к появлению сообщений об ошибках.
Полезно будет посмотреть статью https://support.microsoft.com/en-us/help/267855/problems-with-many-domain-controllers-with-active-directory-integrated
Типичные ошибки DFS_FILE_SYSTEM
Проблемы DFS_FILE_SYSTEM также известны как ошибки синего экрана смерти (BSOD):
- «Ошибка DFS_FILE_SYSTEM привела к завершении работы Windows, чтобы предотвратить повреждение компьютера. «
- «: (Ошибка из DFS_FILE_SYSTEM вызвала проблему, и ваш компьютер должен перезагрузиться. «
- «0x0A: IRQL_NOT_LESS_EQUAL — DFS_FILE_SYSTEM»
- 0x0000001E: КМОДЕ_ИСКЛЮЧЕНИЕ_НЕТ_ОБРАБАТЫВАЕТСЯ — DFS_FILE_SYSTEM
- 0×00000050: СТРАНИЦА_FAULT_IN_NONPAGED_AREA — DFS_FILE_SYSTEM
Ошибки DFS_FILE_SYSTEM, которые вызывают синий экран смерти, часто следуют за новой установкой программного обеспечения ( Windows ) или связанного с ним оборудования. Обычно ошибки синего экрана, связанные с DFS_FILE_SYSTEM, возникают при загрузке драйвера устройства, связанного с Microsoft Corporation, во время установки Windows или связанной программы или во время запуска или завершения работы Windows. При появлении ошибки BSOD DFS_FILE_SYSTEM запишите все вхождения для устранения неполадок Windows и помогите найти причину.
29 Cài đặt và cấu hình DFS Distributed File System
Доменные пространства имен в режиме Windows Server 2008
Система Windows Server 2008 поддерживает создание доменных пространств имен в режиме Windows Server 2008. При этом включается поддержка перечисления на основе доступа и обеспечивается повышенная масштабируемость. Доменное пространство имен, появившееся в Windows 2000 Server, теперь называется «доменное пространство имен (режим Windows 2000 Server)».
Чтобы можно было использовать режим Windows Server 2008, домен и доменное пространство имен должны удовлетворять следующим минимальным требованиям:
- домен должен использовать режим работы домена Windows Server 2008;
- все серверы пространства имен должны работать под управлением Windows Server 2008.
Если среда поддерживает режим Windows Server 2008, выбирайте его при создании доменных пространств имен. Этот режим обеспечивает дополнительные возможности и повышенную масштабируемость, а также исключает необходимость миграции пространства имен из режима Windows 2000 Server.
Актуальность содержимого
Репликация DFS в Windows Server 2008 включает новую функцию «Актуальность содержимого», не позволяющую серверу, который длительное время не был подключен к сети, переписать при возврате в оперативный режим работы актуальные данные устаревшими.
Усовершенствования обработки непредвиденных отключений
В Windows Server 2008 репликация DFS теперь обеспечивает более быстрое восстановление работоспособности системы после непредвиденных отключений. Непредвиденное отключение может произойти по причинам, указанным ниже.
- Непредвиденное отключение репликации DFS может произойти при аварийном завершении процесса репликации DFS или его остановке из-за недостатка ресурсов.
- Непредвиденное отключение компьютера может произойти при сбое в работе компьютера или нарушении его энергоснабжения во время выполнения репликации DFS.
- Непредвиденное отключение тома может произойти при нарушении энергоснабжения тома с содержимым репликации DFS, при его отключении или отсоединении.
Непредвиденное отключение компьютера или тома может привести к потере изменений файловой системы NTFS, которые не были скопированы на диск. В результате может нарушиться согласование базы данных репликации DFS с файловой системой на диске.
В системе Windows Server 2003 R2 непредвиденное отключение может вынудить механизм репликации DFS полностью воссоздать базу данных, на что может потребоваться длительное время. В Windows Server 2008 воссоздавать базу данных после непредвиденных отключений обычно не требуется, благодаря чему работоспособность восстанавливается гораздо быстрее.
Все просто
Microsoft, видимо не захотев заморачиваться, предпочли использовать один и тот же ключ. То есть он зашит в каждой ОС, и он не уникален! Уффф, ты наверняка представил, что мы сейчас откроем IDA Pro и будем следить за процессом gpupdate и всеми его дочерними процессами до момента создания пользователя? Я тоже так думал до того момента, пока не залез в документацию MSDN касательно групповых политик и не наткнулся там на подраздел Password Encryption.
«Приватный» ключ для декрипта cpassword
Представь мое удивление, когда я обнаружил в публично доступной документации 256-битный ключ в открытом виде. Вероятно, разработчики верят в наши силы и способности, ребята позаботились об экономии твоего времени и нервов, за что им огромное спасибо. Дело за малым — давай разберемся, как можно получить исходное значение cpassword.
Создание локального пользователя через GP
Репликация Active Directory средствами Windows PowerShell
В Windows Server 2012 добавлены дополнительные командлеты для репликации Active Directory в модуль Active Directory для Windows PowerShell. Они позволяют настраивать новые и существующие сайты, подсети, подключения, связи сайтов и мосты. Они также возвращают метаданные репликации Active Directory, состояние репликации, а также актуальные данные об очередях и векторе синхронизации версий. Командлеты репликации в сочетании с другими командлетами модуля Active Directory позволяют администрировать весь лес, используя только Windows PowerShell. Все это дает новые возможности администраторам, желающим предоставлять ресурсы и управлять системой Windows Server 2012 без использования графического интерфейса, что сокращает уязвимость операционной системы к атакам и требования к обслуживанию. Это приобретает особое значение, если серверы необходимо развернуть в сетях с высоким уровнем защиты, таких как сети SIPR и корпоративные сети периметра.
Подробнее о топологии сайтов и репликации доменных служб Active Directory см. в разделе Технический справочник по Windows Server.
Почему GP?
Групповые политики — это самый простой и удобный способ настройки компьютера и параметров пользователей в сетях на основе доменных служб Active Directory. Это действительно так, они используются повсеместно.
Многие администраторы в далеком 2008 году получили возможность использовать групповые политики для управления локальными привилегированными пользователями хостов на базе ОС Windows. Проще говоря, Microsoft добавила функционал для модификации локальных учетных записей ОС, в том числе изменение паролей — зачастую это необходимо для работы с ОС, когда она по каким-либо причинам не может получить доступ к каталогу AD и проверить корректность введенных на терминале учетных данных. Надеюсь, не стоит объяснять, что пароли привилегированных пользователей — полезная штука в работе хакера. Поэтому реализация именно этого функционала нас интересует на данный момент больше всего. Давай разберемся с этим процессом от лица администратора домена.