Глава 12. Службы Active Directory - Часть 02

Я купил своей дочери на её день рождения велосипед. В Великобритании почти лето и погода налаживается. Итак, солнечным воскресным вечером мы хотели поехать в Ричмонд- парк чтобы она смогла покататься на своём новом велосипеде.

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

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

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

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

При натройке направления доверительного отношения Active Directory у нас есть три варианта для выбора:

Ключевым выводом из этого является то, что входящее доверие делает возможным исходящий доступ, а исходящее доверие разрешает входящий доступ. В приведённом выше примере домен Rebeladmin.com также может именоваться доверяющий доменом (trusting domain), поскольку он допускает доступ к своим ресурсам пользователям удалённого домена. Также мы называем этот удалённый домен доверенным доменом (trusted domain).

Лес Active Directory может содержать множество доменов. По умолчанию все домены в Лесу Active Directory доверяют друг другу. Давайте предположим что у нас имеется два Леса Active Directory с названиями rebeladmin.com и contoso.com. Лес rebeladmin.com обладает двумя дополнительными доменами toronto.rebeladmin.com и london.rebeladmin.com. Когда мы создаём создаём доверие Лесов, contoso.com также будет доверять доменам toronto.rebeladmin.com и london.rebeladmin.com. Это обусловлено тем, что доверительные отношения между Лесами также по умолчанию переходящими довериями (transitive trust). Некое переходящее доверительное отношение расширяет имеющееся доверие за пределы своего первоначального доверяющего домена. Доверительные отношения без передачи делают возможным доверие только между первоначальными доменами. Внешние доверительные отношения Active Directory по умолчанию не передаваемые (non-transitive).

Существует шесть различных типов доверительных отношений Active Directory. Некоторые из этих доверий создаются автоматически, а какие- то требуют минимального вмешательства.

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

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

Порты межсетевого экрана

Когда мы рассматриваем связь между двумя доменами или двумя Лесами, нам требуется убедиться что допустим через корпоративные межсетевые экраны соответствующий обмен. Ниже приводится перечень минимального числа портов, которые нам требуется открыть между двумя Лесами или двумя доменами. Такой обмен является двунаправленным, что означает, что обе сетевые среды должны допускать входящие и исходящие подключения по приводимым портам.

Таблица 12-1. Порты для установления доверительных отношений между доменами и Лесами

Служба	Порты
LDAP	TCP 389
LDAP (SSL)	TCP 636
RPC	TCP 153 TCP 1024-65535
SMB	TCP 445
KERBEROS	TCP/UDP 88
Global Catalog	TCP 3268
Global Catalog (SSL)	TCP 3269
LDAP (SSL)	TCP 636

Эти порты должны быть открыты между всеми Контроллерами домена. В межсетевом экране лучше вначале создать группу устройств, а затем применить к ней политики/ правила.

Условная ретрансляция

Когда мы создаём доверительные отношения Active Directory, всякий Лес или домен должен знать как разрешать необходимые записи имён DNS во всех прочих Лесах или доменах. Например, у меня имеются два домена в двух различных Лесах. Одним является rebeladmin.com, а другой - contoso.com. Для установления двустороннего доверия каждому домену требуется выполнять разрешение в правильные IP адреса. Чтобы обладать уверенностью что необходимые записи DNS разрешаются верно, мы можем установить условную ретрансляцию в каждом из DNS серверов домена. При настройке условной ретрансляции нам требуется определить какие серверы DNS требуются для обработки запросов DNS, относящихся к их домену. К примеру, применяя условный ретранслятор мы можем сказать, что когда некто пытается разрешать относящийся к contoso.com FQDN, такой запрос должен обрабатываться при помощи серверов DNS 10.10.10.1 и 10.10.10.2.

В моей демонстрационной среде у меня имеются два домена в двух лесах. Вот их конфигурация IP адресов:

Таблица 12-2. IP адреса демонстрационной среды

Домен	Контроллер домена	IP адрес
rebeladmin.com	DC01.rebeladmin.com	10.1.0.4/24
contoso.com	CON-DC01.contoso.com	10.1.5.4/24

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

Я зарегистрировался в DC01.rebeladmin.com и попытался выполнить ping к contoso.com. Как и ожидалось, это выдало мне неверный IP адрес.

Это должно разрешаться адресом 10.1.5.4. Для исправления данной ситуации давайте проследуем далее и настроим условный ретранслятор в DC01.rebeladmin.com для contoso.com и укажем ему на DNS сервер 10.1.5.4.

Add-DnsServerConditionalForwarderZone -Name "contoso.com" -ReplicationScope "Forest" -MasterServers 10.1.5.4
		

В своей предыдущей команде я создаю интегрированный условный ретранслятор Active Directory для своего домена contoso.com. Он будет ретранслирван во все Контроллеры домена в данном Лесу.

После установки необходимого условного ретранслятора я способен верно разрешать необходимый IP адрес.

Прежде чем мы настроим доверительное отношение Active Directory, нам также необходимо установить условный ретранслятор в CON-DC01.contoso.com для домена rebeladmin.com.

Add-DnsServerConditionalForwarderZone -Name "rebeladmin.com" -ReplicationScope "Forest" -MasterServers 10.1.0.4
		

Относительно приведённого выше снимка экрана, наш условный ретранслятор также работает в домене contoso.com.

Обратите внимание, что вместо зоны условной ретрансляции мы также можем настроить вторичную зону DNS в DNS серверах Contoso для своего домена rebeladmin.com. Тем не менее, в доверительных отношениях мы пользуемся лишь определёнными именами DNS - бесполезно реплицировать всю зону DNS целиком. Кроме того, мы выставили бы относительно инфраструктуры rebeladmin больше сведений чем необходимо. Дополнительные сведения относительно вторичных зон предоставляются в Главе 4, Active Directory DNS.

Настройка Доверительных отношений Леса AD

В своём предыдущем разделе мы создали относящиеся к делу условные ретрансляторы с обеих сторон. Наш следующий шаг состоит в становлении доверительного отношения Леса Active Directory:

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

Проверка

После размещения доверительных отношений мы должны иметь возможность запрашивать пользователей в своём удалённом домене. Для проверки этого я зарегистрируюсь в DC01.rebeladmin.com и я намерен запросить пользователей в одном из Организационных элементов (OU) своего домена contoso.com.

Get-ADUser -Server CON-DC01.contoso.com -Filter * -SearchBase "OU=Test,DC=CONTOSO,DC=COM"
		

В своей предыдущей команде я запрашиваю пользователя из Организационного элемента Test в домене contoso.com. Как и ожидалось, я оказался способным запрашивать пользователей из своего домена contoso.com.

Давайте испробуем то же саоме из домена contoso.com

Get-ADUser -Server DC01.rebeladmin.com -Filter * -SearchBase "OU=Sales,DC=rebeladmin,DC=com"
		

В приведённой выше команде я запросил пользователей из Организационного элемента Sales в своём домене rebeladmin.com. Как и ожидалось, у меня была возможность перечислить этих пользователей.

Я способен также запросить contoso.com из DC01.rebeladmin.com.

Get-ADDomain contoso.com
		

Как мы можем видеть, наши двусторонние доверительные отношения Леса Active Directory работают как ожидалось. В своём следующем разделе мы намерены рассмотреть другую форму Контроллера домена.

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

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

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

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

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

Для создания учётной записи компьютера RODC мы можем применить командлет 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 находятся следующие группы безопасности:

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

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

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

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

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

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

Для дальнейшего усиления уровня безопасности рекомендуется устанавливать RODC в операционной системе Windows Core.

Active Directory поддерживает базу данных со множеством хозяев для хранения сведений о схеме, конфигурации и домене. Обычно, когда мы произносим база данных, первое что приходит нам на ум это программное обеспечение такое, как Microsoft SQL, MySQL или Oracle. Но здесь всё совершенно по- другому. Базы данных Active Directory применяют 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 заключает в себе все сведения о пользователях, группах и прочих интегрированных с Active Directory данных. В этой таблице строки представляют соответствующие объекты, а колонки выступают как значения атрибутов.

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

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

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

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

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

Когда это необходимо, мы можем переместить имеющуюся базу данных Active Directory с её установленного по умолчанию местоположения. Для выполнения этого мы можем воспользоваться инструментом командной строки с названием 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
		

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

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

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

Когда эти службы остановлены (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.

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

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

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

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

Начиная с AD DS 2008, Microsoft ввёл некую небольшую, но важную функциональную возможность для предотвращения непредумышленного удаления объекта Active Directory. Это не некое решение для восстановления при происшествии, а только какое- то решение для предотвращения происшествий. В каждом объекте в закладке Object имеется маленький блок отметки для включения данного свойства. Его можно включить при создании объектов при помощи PowerShell.

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

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

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

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

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

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

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

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 ввёл функциональную возможность моментального снимка Active Directory, которая получает некий моментальный снимок какой- то базы данных Active Directory в заданный момент времени. Позднее его можно применять для сопоставления изменений значения объекта и экспорта и импорта объектов, которые были удалены или изменены. Не путайте его с обычным моментальным снимком. Всё это происходит внутри Active Directory и мы не можем применять его целиком для полного восстановления контроллера домена. Он позволяет нам монтировать некий моментальный снимок пока работает существующая конфигурация 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
		

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

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

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

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

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

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
		

Восстановление AD из резервной копии состояния системы

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

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

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

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

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

Когда вы применяете программное обеспечение резервного копирования Active Directory, отличное от Windows, ваши параметры восстановления могут отличаться от вышеупомянутых и вам следует руководствоваться указаниями их производителя.

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

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