На данный момент нам известны необходимые логические и физические компоненты, вовлекаемые в обсуждаемый процесс репликации AD. Теперь настало время собрать всё воедино и в точности разобраться как происходят репликации AD.

В среде AD существует два основных типа репликаций:

Как и предполагает их название, они охватывают те репликации, которые происходят внутри своей площадки AD. По умолчанию, (согласно Microsoft) все контроллеры домена будут знать о любом обновлении любого каталога в пределах 15 секунд. В рамках своей площадки, вне зависимости от общего числа контроллеров домена, любое обновление каталога будет реплицировано менее чем за минуту:

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

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

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

Когда рассматриваемая инфраструктура AD содержит более одной площадки, некое изменение в одной площадке требуется реплицировать во все прочие площадки. Это именуется Репликациями между площадками (inter-site replication), причём их топология отличается от репликаций внутри площадки. Репликации внутри самой площадки всегда имеют преимущества высокоскоростных подключений. Однако когда дело касается подключений между площадками оказывают воздействие все такие факторы как полоса пропускания, задержки и устойчивость.

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

Когда речь заходит о репликациях между площадками, они происходят через подключения площадок. Сами репликации внутри каждой площадки всё ещё применяют свою кольцевую топологию. В нашем приведённом выше примере давайте допустим, что некий объект был добавлен к REBEL-DC-02 на Площадке Лондона. Теперь, основываясь на своей топологии она будет также представлена также и для REBEL-DC-03. Однако помимо того что он выступает контроллером своего домена, этот конкретный контроллер домена также является и сервером плацдарма. Поэтому, именно этот сервер отвечает за представление соответствующих получаемых им обновлений в свой сервер моста на Площадке Канады, которым является REBEL-DC-04. после получения последним необходимых обновлений, он представит их прочим контроллерам на своей площадке. Такая репликация между площадками всё ещё вынуждена следовать установленным расписаниям репликаций.

AD DS автоматически выбирает свой сервер плацдарма для площадки. Однако существуют случаи, когда инженеры желают выбирать предпочитаемый ими сервер на роль своего сервера плацдарма. В своём предыдущем разделе мы уже рассмотрели как мы можем принуждать некий контроллер домена становиться таким предпочитаемым сервером плацдарма.

Когда я обсуждал Репликацию Active Directory, я упоминал, что AD выполняет такие функции, как автоматическое создание подключений репликации и выбор серверов плацдарма. Но как это осуществляется на практике? Именно KCC отвечает за всё это.

KCC является некой встроенной в контроллеры домена AD службой и именно она ответственна за выработку и сопровождение топологии для репликаций внутри- и между- площадками. Каждые 15 минут такая KCC будет удостоверять свою установленную топологию репликации и в случае необходимости изменять эту топологию. Это снабжает контроллеры домена достаточным сроком для репликации необходимых изменений когда имеющаяся топология репликации допустима.

Что касается репликации между площадками, определённая KCC выбирает единственного держателя KCC в некой удалённой площадке для его работы в качестве ISTG (Intersite Topology Generator, Генератора топологии между площадками) и ответственность такого ISTG заключается в выборе для репликаций необходимых серверов плацдарма. Этот ISTG создаёт необходимое представление топологии репликации для всех тех площадок, к которым он подключён. Такой ISTG отвечает за принятие решений по установке топологии своей площадки, а индивидуальные контроллеры домена (такие как KCC) ответственны за локальное принятие решений по созданию топологии.

Для понимания подобной KCC лучшим способом является его сопоставление с неким протоколом сетевой маршрутизации. Протокол сетевой маршрутизации отвечает за поддержание какого- то пути маршрутизации для соединённых сетевых сред. Когда сетевой среде A требуется взаимодействие с сетевой средой B, имеющаяся таблица маршрутизации сообщит ему каким именно путём воспользоваться. Точно так же, создаваемая KCC топология сообщает нам как контроллер домена A может выполнять репликацию необходимых изменений в контроллер домена B. При работе над проектами AD я был свидетелем того, как инженеры создавали вручную подключения репликаций между контроллерами домена. Но я действительно сомневаюсь в том, что кто- то способен оказаться умнее имеющейся KCC когда речь заходит о выработке решения для топологии репликаций.

На данный момент мы знаем как работает топология репликации, но как именно контроллер домена узнаёт что некое обновление произошло? И как такие присоединённые контроллеры домена узнают когда включать репликации? Давайте проследуем вперёд и изучим стоящие за этим технологии более глубоко.

USN (Последовательный номер обновления)

Такой USN является неким 64- битым числом, которое выделено его контроллеру домена на протяжении процесса DCPromo. Когда имеется некий объект для обновления, значение выделенного для этого контроллера домена USN будет увеличено. Например, допустим, контроллер домена A имел некой начальное значение USN равным 2 000. Когда мы добавляем 5 объектов пользователей, новым значением USN становится 2 005. Это число может только увеличиваться. Технически невозможно для двух контроллеров домена в одной и той же площадке иметь назначенным одно и то же значение USN.

DSA GUID и идентификатор вызова

Вовлечённые в обсуждаемый процесс репликации контроллеры домена идентифицируются при помощи двух уникальных идентификаторов. Первым из них является DSA GUID. Он вырабатывается на протяжении процесса DCPromo и он никогда не изменяется на протяжении времени своей жизни в качестве данного контроллера домена. Следующим выступает идентификатор вызова (invocation ID). При неком процессе восстановления он будет изменён, в противном случае имеющиеся контроллеры домена будут идентифицировать его как уже имеющийся контроллер домена и не будут реплицировать данные в него.

Таблица HWMV

Данная таблица High Watermark Vector (HWMV, Вектора верхних водяных знаков) поддерживается локально в каждом контроллере домена для отслеживания самого последнего изменения от своего партнёра по репликации для заданного NC (naming context, контекста именования). Как вы уже знаете, контроллеры домена имеют три NC: NC схемы, NC конфигурации и NC домена. Имеется некая таблица HWMN для каждого из NC. Такая таблица содержит значение того последнего USN, которое она получила от своего партнёра по репликации для данного NC. Основываясь на этом, данный контроллер домена принимает решение когда начинать необходимый процесс репликации.

Таблица UTDV

Таблица UTDV (Up-To-Dateness Vector, Вектора новизны) локально поддерживается всеми контроллерами домена во избежание ненужных репликаций. UTDV также - для каждого NC и контроллера домена - обладает как минимум тремя таблицами UTDV. Такая таблица UTDV содержит наивысшее значение UPN, которое она узнала от каждого подключённого контроллера домена на основе всех NC. Это предотвращает репликацию контроллером домена одних и тех же изменений снова и снова. Например, когда контроллер домена A получает некий NC домена от контроллера домена B, он обновит свою таблицу UTDV и обновит в ней соответствующее значение UPN. На основании этого он не будет выбирать те же самые обновления из всех прочих подключённых контроллеров домена. По причине UTDV контроллеры домена не будут отправлять какие бы то ни было сведения своим партнёрам по репликации если они уже получали их от кого- то ещё. Это имеет название смягчения распространения (propagation dampening):

Чтобы суммировать обсуждаемую репликацию, давайте прибегнем к некому сценарию. В своём предыдущем примере мы имели три подключённых контроллера домена. Каждый имел назначенным некое начальное значение UPN. Теперь, предположим, что был добавлен некий новый объект с помощью REBEL-DC-01. Итак, теперь его UPN увеличен до 1 001. В данный момент этот контроллер домена знает о подключённых партнёрах по репликации на основании DSA GUID и идентификатора вызова. REBEL-DC-02 уже знает самое последнее значение UPN, которое он получил от REBEL-DC-01 как хранимое в его таблице HWMV. Прежде чем его обновлять, он проверяет значение таблицы UTDV чтобы убедиться, что он не получал те же самые обновления через REBEL-DC-03, раз это не так, он выполняет репликацию и увеличивает свой UPN и соответствующие значения в таблицах HWMV и UTDV. Я надеюсь, что это в точности поясняет то что происходит при определённой репликации AD.

RODC является отличной ролью, введённой Windows Server 2008, которая может применяться для поддержки контроллера домена в местах, которые не способны гарантировать физическую безопасность и регулярное сопровождение. На протяжении этой главы мы обсуждали возможные сценарии, при которых нам требовался некий контроллер домена в какой- то удалённой площадке. При рассмотрении контроллера домена на удалённой площадке, само подключение между площадками не является единственным подлежащим рассмотрению моментом. Контроллер домена, по умолчанию, будет осведомлён о любых изменениях в имеющейся структуре AD. Когда включается некое обновление, оно модифицирует свою собственную копию имеющейся базы данных AD. Этот файл ntds.dit содержит всё относительно общей инфраструктуры AD, включая сами сведения идентичности имеющихся объектов пользователей. Когда этот файл попадает в злые руки, они способны выудить относящиеся к идентичности сведения и скомпрометировать эту инфраструктуру идентичности.

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

Другим преимуществом RODC является то, что они выполняют репликации лишь в одном направлении. При рассмотрении удалённых площадок вам также необходимо учитывать то как будут сопровождаться системы. Не все организации способны поддерживать команды ИТ для удалённых офисов. Большинство задач сопровождения всё ещё могут обслуживаться удалённо, однако имеются определённые случаи, при которых вам требуется делегировать некие полномочия персоналу на удалённых площадках. В большинстве случаев этот персонал менее искушён в ИТ, а потому любые совершаемые им простейшие ошибки способны реплицироваться в прочие контроллеры домена и приводить к беспорядку. Односторонние репликации RODC прекратят это и никакие изменения не будут реплицироваться в прочие контроллеры домена. Отлично, не так ли?

По умолчанию, RODC не сохраняют никакие пароли (за исключением объектов RODC) для объектов AD. Всякий раз когда происходит некая аутентификация, RODC нуждается в выборке необходимых сведений из ближайшего контроллера домена. Применяя PRP (Password Replication Policy, Политику реплицирования паролей), мы можем допускать кэширвоание определённых паролей для объектов. Если прерывается установленное соединение между какой- то удалённой площадкой и ближайшим контроллером домена, наш RODC будет способен обрабатывать имеющиеся запросы. Один из моментов, о котором не следует забывать это то, что для обработки запроса Kerberos, RODC требуется кэшировать значение пароля для самого объекта пользователя, а также для объекта компьютера.

Процесс развёртывания RODC включает в себя приводимые ниже этапы. При этом процессе мы можем применять некую предварительно выбранную учётную запись и продвигать RODC, применяя её вместо использования некой учётной записи Администратора домена или Администратора Компании:

Для создания учётной записи компьютера RODC мы можем применить cmdlet Add-ADDSReadOnlyDomainControllerAccount:

Add-ADDSReadOnlyDomainControllerAccount -DomainControllerAccountName REBEL-RODC-01 -DomainName rebeladmin.com -DelegatedAdministratorAccountName "rebeladmindfrancis" -SiteName LondonSite
		

Наша предыдущая команда создаст необходимую учётную запись контроллера домена RODC для REBEL-RODC-01. Необходимое имя домена определяется при помощи -DomainName, а -DelegatedAdministratorAccountName задаёт какую учётную запись делегировать данной установке RODC. Этот новый RODC будет помещён в LondonSite.

Теперь мы способны видеть только что добавленный объект в наших контроллерах домена AD:

Сейчас у нас всё готово для нашего нового RODC и наш следующий шаг состоит в установке относящейся к делу службы роли:

Install-WindowsFeature –Name AD-Domain-Services -IncludeManagementTools
		

Приведённая выше команда устанавливает необходимую роль AD DS в RODC. По завершению мы можем продвинуть её при помощи такой команды:

Import-Module ADDSDeployment
Install-ADDSDomainController `
-Credential (Get-Credential) `
-CriticalReplicationOnly:$false `
-DatabasePath "C:WindowsNTDS" `
-DomainName "rebeladmin.com" `
-LogPath "C:WindowsNTDS" `
-ReplicationSourceDC "REBEL-PDC-01.rebeladmin.com" `
-SYSVOLPath "C:WindowsSYSVOL" `
-UseExistingAccount:$true `
-Norebootoncompletion:$false
-Force:$true
		

После её завершения, мы получаем приглашение дл необходимой учётной записи пользователя и нам требуется ввести соответствующие сведения учётной записи пользователя, которые были делегированы для развёртывания RODC. Эта команда очень схожа с продвижением обычного домена.

Теперь, когда у нас имеется необходимый RODC, нашим следующим этапом является просмотр PRP.

Необходимая устанавливаемая по умолчанию политика уже на своём месте и мы можем просматривать списки Allowed и Denied при помощи такой команды:

Get-ADDomainControllerPasswordReplicationPolicy -Identity REBEL-RODC-01 -Allowed
		

наша приведённая выше команда перечислит все объекты Allowed для кэширования пароля. По умолчанию некая группа безопасности с названием Allowed RODC Password Replication Group разрешена для такой репликации. В установках по умолчанию она не содержит никаких участников. Если нам необходимо кэширование, мы можем добавлять объект в ту же самую группу:

Get-ADDomainControllerPasswordReplicationPolicy -Identity REBEL-RODC-01 -Denied
		

предыдущая команда перечислит все Denied объекты для кэширования паролей. По умолчанию в списке Denied находятся следующие группы безопасности:

Это учётные записи с высокими привилегиями в имеющейся инфраструктуре AD; они не должны кэшироваться вовсе. Добавляя объекты в Denied RODC Password Replication Group мы просто можем блокировать такую репликацию.

Помимо применения предварительно заданных групп безопасности, мы можем добавлять объекты в списки Allowed и Denied при помощи cmdlet Add-ADDomainControllerPasswordReplicationPolicy:

Add-ADDomainControllerPasswordReplicationPolicy -Identity REBEL-RODC-01 -AllowedList "user1"
		

Предыдущая команда добавит объект пользователя с именем =user1 в список Allowed.

Следующая команда добавит объект пользователя с именем user2 в список Denied:

Add-ADDomainControllerPasswordReplicationPolicy -Identity REBEL-RODC-01 -DeniedList "user2"
		

AD поддерживает базу данных со множеством хозяев для хранения сведений о схеме, конфигурации и домене. Обычно, когда мы произносим база данных, первое что приходит нам на ум это программное обеспечение такое, как Microsoft SQL, MySQL или Oracle. Но здесь всё совершенно по- другому. Базы данных AD применяют ESE (Extensible Storage Engine, Расширяемый механизм хранения), который относится к технологии ISAM (Indexed and Sequential Access Method, Индексно- последовательного метода доступа).

Здесь некая отдельная система работает как клиент и сервер. Она применяет архитектуры базы данных, ориентированную на записи,которые предоставляют чрезвычайно быстрый доступ к записям. Сама ESE индексирует имеющиеся сведения в своём файле базы данных, который способен достигать 16 Терабайт и содержать более 2 миллиардов записей. Обычно ESE применяется для приложений, которым требуется быстрое и структурированное хранение данных. Данный ESE используется многими прочими приложениями Microsoft? включая Microsoft Exchange, DHCP и FRS.

Поскольку процесс создания такой базы данных является частью общего процесса установки контроллера домена, он создаёт соответствующую базу данных в C:\Windows\NTDS если только мы не выбираем некий индивидуальный путь. Рекомендуется применять отдельный раздел/ диск с наивысшей скоростью для увеличения производительности базы данных, а также для защиты этих данных:

В этой папке мы можем наблюдать несколько разных файлов. Из всех них важными являются следующие.

Именно это реальный файл базы данных. Эта база данных содержит три основных таблицы. Таблица schema содержит сведения, относящиеся к имеющимся классам, атрибутам объектов и взаимодействии между ними. Таблица link включает в себя данные о значениях, ссылающихся на другой объект. Подробности участия в группах это хороший пример для неё. Таблица data заключает в себе все сведения о пользователях, группах и прочих интегрированных с AD данных. В этой таблице строки представляют соответствующие объекты, а колонки выступают как значения атрибутов.

Здесь мы можем видеть что несколько файлов начинаются с edb*, причём все они имеют в размере 10 МБ или меньше. Это поддерживаемый самой системой журнал транзакций для хранения транзакций своего каталога до его записи в сам файл базы данных.

Этот файл отвечает за отслеживание фиксации данных определённой транзакции в самой базе данных из файлов журналов (edb*.log).

Данный файл используется на протяжении сопровождения базы данных AD для удержания данных, а также для хранения сведений относительно находящихся в процессе транзакции данных AD.

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

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

Когда это необходимо, мы можем переместить имеющуюся базу данных AD с её установленного по умолчанию местоположения. Для выполнения этого мы можем воспользоваться инструментом командной строки с названием ntdsutil. при перемещении имеющихся файлов базы данных также рекомендуется перемещать и файлы журнала с тем, чтобы этим файлам журнала не приходилось ссылаться на два разных диска. Минимальное требуемое значение пространства для базы данных составляет 500 МБ или значение размера файла базы данных с дополнительными 20% от размера этого файла базы данных (в зависимости от того что больше). Требования для размера файла журнала такие же.

Имеющиеся файлы базы данных и журнала не могут быть перемещены пока запущена AD DS. Следовательно, первым этапом в общем действии является останов данной службы:

net stop ntds
		

Это также вызовет останов и связанных с нею служб, включая KDC, DNS и DFS.

Имеющиеся файлы базы данных и журнала AD не могут быть перемещены в несуществующую папку. Поэтому, прежде чем мы переместим эти файлы, необходимо создать такую папку.

В своей демонстрации я перемещу их в папку с названием ADDB в другом разделе:

ntdsutil
activate instance ntds
files
move db to E:\ADDB
move logs to E:\ADDB
integrityquit
quit
		

В нашей предыдущем наборе команд ntdsutil инициирует необходимую утилиту, move db to E:ADDB перемещает в новое местоположение существующий файлы базы данных, а move logs to E:ADDB перемещает файлы журнала в этот новый каталог. Имеющаяся часть integrity удостоверяет целостность полученных файлов базы данных и журналов в их новом местоположении:

После выполнения этого нам требуется запустить AD DS при помощи такой команды:

net start ntds
		

Как только данный процесс будет осуществлён, рекомендуется чтобы вы выполнили полное резервное копирование AD как часть данных изменений. Полученная ранее резервная копия в любом случае больше не будет действительной.

В любой базе данных по мере её действия сами данный будут добавляться, изменяться и удаляться. При добавлении данных требуется новое пространство внутри этой базы данных. Когда данные уничтожаются, это высвобождает пространство в эту базу данных. При изменении базы данных она требует либо нового пространства, либо его высвобождения. В имеющейся базе данных AD при удалении некого объекта это высвобождает то пространство, которое он использовал в саму базу данных, а не в её файловую систему. Следовательно, данное свободное пространство будет применяться для новых объектов. Данный процесс имеет название дефрагментации в рабочем состоянии (online defragmentation), так как это не требует останова самих служб AD. По умолчанию она запускается каждые 12 часов.

Однако при уничтожении большого числа объектов или некого сервера глобального каталога будет неплохо высвободить такое свободное пространство в саму файловую систему. Для этого нам требуется выполнить название дефрагментации в выключенном состоянии (offline defragmentation). Для выполнения этого требуется чтобы мы остановили службы данного AD.

Когда эти службы остановлены (net stop ntds), мы можем запустить процесс дефрагментации при помощи таких команд:

ntdsutil
activate instance ntds
files
compact to E:\CompactDB
quit
quit
		

В нашем предыдущем процессе нам потребуется некая временная папка в которой сохраняется наш компактный файл ntds.dit. В своей демонстрации я создал для этого некую папку с названием E:\CompactDB:

По окончанию этого наша уплотнённая база данных должна быть скопирована в своё первоначальное местоположение ntds.dit. Это можно выполнить следующей командой:

copy "E:\CompactDB\ntds.dit" "E:\ADDB\ntds.dit"
		

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

del E:\ADDB\*.log
		

А после этого мы можем запустить AD DS при помощи net start ntds.

Это завершает два наших сценария (изменение пути базы данных и дефрагментацию), при которых нам потребуется воспользоваться ручным вмешательством в сопровождение базы данных AD.

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

Первый вид происшествий это когда имеется некое полное крушение системы по причине отказа оборудования. Помимо имеющейся резервной копии AD, поддержка множества контроллеров домена помогает организациям в быстром восстановлении в подобных случаях без восстановления некой резервной копии. Когда это не держатель роли FSMO (flexible single master operation, Гибких операций с единственным хозяином), мы можем принудительно удалить записи, относящиеся к такому разрушенному контроллеру домена и ввести некий новый контроллер домена. Когда это наш держатель роли FSMO, мы можем завладеть (seize) этими ролями FSMO и сделать их доступными с прочих живых контроллеров домена. С другой стороны, в наши дни большая часть рабочих нагрузок выполняется в некой виртуальной среде, включая и контроллеры домена. Такие виртуальные среды обычно имеют решения в месте для восстановления после отказов. Например, виртуальное решение может применять некую кластерную среду или дополнительное решение восстановления, такое как восстановление площадки Azure. Следовательно, в современных инфраструктурах я редко наблюдаю кого- то, кому приходится восстанавливать некий контроллер домена из резервной копии.

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

Начиная с AD DS 2008, Microsoft ввёл некую небольшую, но важную функциональную возможность для предотвращения непредумышленного удаления объекта AD. Это не некое решение для восстановления при происшествии, а только какое- то решение для предотвращения происшествий. В каждом объекте в закладке Object имеется маленький блок отметки для включения данного свойства. Его можно включить при создании объектов при помощи PowerShell. Даже когда мы не применяем PowerShell, это всё ещё доступно в любой момент времени через окно свойств Object. При создании некого OU (Organizational Unit, Организационного элемента) при помощи GUI, нам также дозволено включать эту опцию, причём это единственный объект, который допускает это в процессе его установки:

E:\CompactDB:

Когда этот параметр разрешён, он не позволит нам удалять свой объект пока мы не запретим его действие:

E:\CompactDB:

Из PowerShell это можно осуществлять при помощи соответствующего параметра -ProtectedFromAccidentalDeletion $true.

Наиболее распространённые относящиеся к AD происшествия обусловлены непредумышленным удалением объектов. Когда некий объект удалён из AD, он не удаляется окончательно. Как только некий объект удалён, ему устанавливается значение атрибута isDeleted в True, а сам этот объект перемещается в CN=Deleted Objects:

Далее он продолжает оставаться там пока данная система не достигнет своего значения высеченного на камне времени жизни (tombstone lifetime). В установках по умолчанию оно составляет 180 дней, а в случае такой необходимости, его можно изменить. Как только данный объект преодолевает своё значение надгробия времени жизни, он становится доступным для окончательного удаления. Когда мы обсуждали базу данных AD в разделе Сопровождение базы данных AD, мы рассмотрели дефрагментацию в рабочем состоянии. Данный процесс применяет службу сборки мусора для удаления всех удалённых из базы данных AD объектов и высвобождает такое пространство в свою базу данных. данная служба исполняется каждые 12 часов. После того как наш удалённый объект достиг высеченного на его надгробии времени жизни, он будет окончательно удалён в следующем цикле службы сборки мусора. основная проблема состоит в том, что на протяжении самого процесса истечения срока действия надгробия, большинство значений объектов извлекаются. Поэтому, даже если вы имеете возможность восстановления объектов, значения потребуется вводить заново.

Начиная с Windows Server 2008 R2, Microsoft ввёл функциональную возможность Мусорной корзины AD. Когда данное свойство включено, после удаления определённого объекта он всё ещё обладает установленным в значение True атрибута объекта isDeleted и перемещает такой объект в CN=Deleted Object. Но вместо значения на надгробии времени жизни он теперь управляется значениями DOL (Deleted Object Lifetime, Времени жизни удалённых объектов). На данном этапе атрибуты объекта остаются теми же самыми и они запросто поддаются восстановлению. В установках по умолчанию величина значения DOL эквивалентна времени жизни на надгробии. Это значение может быть изменено путём можификации значения атрибута msDS-deletedObjectLifetime. По истечению значения DOL, он перемещается в состояние Recycled, а его значение атрибута isRecycled устанавливается равным True. В данном состоянии он не может быть восстановлен и он будет пребывать в этом состоянии вплоть до истечения времени жизни на его надгробии. По его достижению он навсегда удаляется из AD.

Даннаое свойство включается при помощи следующей команды:

Enable-ADOptionalFeature 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target rebeladmin.com
		

В нашей предыдущей команде -Target может быть заменён именем вашего обмена.

После того как Recycle Bin Feature включено, мы имеем возможность выемки удалённых объектов с помощью следующей команды:

Get-ADObject -filter 'isdeleted -eq $true' -includeDeletedObjects
		

предыдущая команда отыскивает те объекты, у которых атрибуты isdeleted установлены в true.

Теперь мы определили удалённые объекты и их можно восстановить такой командой:

Get-ADObject -Filter 'samaccountname -eq "dfrancis"' -IncludeDeletedObjects | Restore-ADObject
		

Приведённая выше команда восстанавливает объект пользователя, dfrancis.

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

Начиная с Windows Server 2008, Microsoft ввёл функциональную возможность моментального снимка AD, которая получает некий моментальный снимок какой- то базы данных AD в заданный момент времени. Позднее его можно применять для сопоставления изменений значения объекта и экспорта и импорта объектов, которые были удалены или изменены. Не путайте его с обычным моментальным снимком. Всё это происходит внутри AD и мы не можем применять его целиком для полного восстановления контроллера домена. Он позволяет нам монтировать некий моментальный снимок пока работает существующая конфигурация AD DS. Тем не менее, он не позволяет нам перемещать или копировать объекты между моментальными объектами и неким работающим экземпляром AD DS.

Мы можем создавать необходимый моментальный снимок AD DS при помощи ntdsutil. Для его запуска нам необходимо обладать полномочиями Администратора домена:

ntdsutil
snapshot
activate instance ntds
create
quit
quit
		

Теперь у нас имеется некий моментальный снимок, а впоследствии он может быть смонтирован. Для его монтирования нам потребуется применить такие команды:

ntdsutil
snapshot
activate instance ntds
list all
mount 1
quit
quit
		

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

Наш следующий этап состоит в монтировании этого моментального снимка, что можно осуществить такой командой:

dsamain –dbpath C:$SNAP_201703152333_VOLUMEE$ADDBntds.dit –ldapport 10000
		

В нашей предыдущей команде -dbpath задаёт значение пути базы данных AD DS, а -ldapport определяет значение порта, используемого для этого моментального снимка. им может быть любой доступный порт TCP/IP.

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

По завершению работы его также требуется размонтировать. Для этого мы можем применить следующие команды:

ntdsutil
snapshot
activate instance ntds
list all
unmount 1
quit
quit
		

Некая резервная копия состояния системы AD требуется для восстановления при чрезвычайном событии, когда ваша база данных не может быть восстановлена при помощи ранее пояснённых вариантов восстановления уровня объекта. Для выполнения резервного копирования состояния системы поддерживается резервное копирование Windows. Кроме того, имеется множество инструментов резервного копирования сторонних разработчиков, которые применяют аналогичные технологии для производства резервной копии соответствующего состояния системы AD.

В состав резервной копии состояния системы входят следующие файлы:

Начиная с Windows Server 2008, создаваемая резервная копия состояния системы также содержит системные файлы Windows, поэтому размер резервной копии состояния системы больше размера резервной копии состояния Windows Server 2003. Рекомендуется чтобы вы делали резервную копию состояния системы для всех контроллеров домена.

Самый первый этап для выполнения настройки состоит в установке функциональных возможностей резервного копирования Windows в сервере AD:

nstall-WindowsFeature -Name Windows-Server-Backup –IncludeAllSubFeature
		

Далее давайте создадим некую политику резервного копирования при помощи такой команды:

BKPolicy = New-WBPolicy
		

Затем проследуем далее и добавим в эту политику состояние системы:

$Bkpath = New-WBBackupTarget -VolumePath "F:"
		

Теперь нам требуется установить соответствие этой политики со значением пути:

Add-WBBackupTarget -Policy $BKPolicy -Target $Bkpath
		

Наконец, мы можем запустить своё резервное копирование такой командой:

Start-WBBackup -Policy $BKPolicy
		

Когда вашей системе требуется восстановление из имеющейся резервной копии состояния системы, это требуется выполнять через DSRM (Directory Services Restore Mode, Режим восстановления служь каталога).

Во- первых, система должна быть перезагружена; нажмите клавишу F8 и выберите Directory Services Restore Mode.

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

$ADBackup = Get-WBBackupSet | select -Last 1
Start-WBSystemStateRecovery -BackupSet $ADBackup
		

Это выполнит восстановление наиболее последней взятой резервной копии данной системы.

Мы начали эту главу с рассмотрения AD LDS и его возможностей. Затем мы перешли к репликации AD. В этом разделе мы сосредоточились на вовлекаемых в репликации AD физических и логических компонентах, а также как их можно применять для оптимизации сложных требований репликации. Что ещё более важно, мы рассмотрели что происходит позади сцены действия репликации AD. Далее мы переместились к RODC и рассмотрели его функциональные возможности и сценарии развёртывания. Позднее мы рассмотрели сопровождение базы данных AD, которое содержит различные инструменты и технологии, применяемые для оптимизации производительности AD. И последнее, но не в отношении важности, мы рассмотрели варианты восстановления AD.

В своей следующей главе мы намерены рассмотреть другую важную службу роли AD: AD CS.