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

Когда мы обсуждаем AD, мы ссылаемся на него как на какую- то отдельную службу; тем не менее, AD DS это некий набор из множества прочих компонентов, таких как DNS, Групповые политики, репликация папки SYSVOL и тому подобного. Каждый из этих компонентов требует надлежащей работы для жизнеспособного функционирования среды AD. Управление этими компонентами не является простым; оно требует вложений в ресурсы, время и навыки. И это касается не только безостановочной работы и производительности службы; критически важную роль играет безопасность. Конкретный отказ или компрометация таких компонентов/ служб может иметь потенциальное воздействие на всю инфраструктуру Active Directory в целом.

К операционным системам также причисляются и Microsoft Windows Core. Она не обладает фантазией графического интерфейса или множеством запущенных приложений, но всё ещё выполняет необходимое задание Операционной системы. Это позволяет пользователям строить системы с нуля в соответствии с их требованиями. Это также увеличивают бесперебойное время работы системы (меньше обновлений), надёжность, производительность и безопасность. Вскоре после того как Microsoft выпустила самую первую версию Active Directory, инженеры ИТ, разработчики приложений и профессионалы ИТ начали запрашивать некую усечённую версию AD DS с чистыми возможностями LDAP.

Они жаждали прекратить все эти зависимости и требования управления с тем, чтобы иметь возможность сосредоточиться на разработке приложения поверх функций ядра Active Directory. Вслед за Windows Server 2003, Microsoft выпустила Active Directory Application Mode (ADAM), который позволил администраторам запускать усечённую версию Active Directory без таких моментов как Групповые политики и репликация файлов. Её можно было запускать на настольном компьютере или неком сервере участнике аналогично любой прочей службе Windows. Начиная с Windows Server 2008, Microsoft переименовала её в AD LDS (Active Directory Lightweight Directory Services) и разрешила пользователям устанавливать данную роль при помощи Диспетчера сервера. Данная версия предоставила администраторам дополнительный контроль и визуализацию для развёртывания экземпляров LDS и и управления ими. Это продолжилось во всех последующих выпусках AD DS после данной версии и входит также в состав Windows Server 2022.

Если вы уже применяете AD DS, тогда основным вопросом будет зачем нам нужны AD LDS (Active Directory Lightweight Directory Services). В своём следующем разделе мы рассмотрим некоторые ситуации, в которых мы можем воспользоваться LDS.

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

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

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

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

В большинстве случаев такие обращённые интерфейсом через Интернет приложения развёртываются развёртываются в установленном периметре или в некой общедоступной сетевой среде. Такие приложения также могут обладать требованиями аутентификации, однако в имеющемся периметре или общедоступной сетевой среде не рекомендуется устанавливать AD DS. В подобном случае наиболее распространённым для предоставления федеративного доступа методом является развёртывание AD FS; однако когда для подобного приложения требуется полная изоляция, мы можем внутри своей сетевой среды периметра или общедоступной сети установить необходимый экземпляр AD LDS и предоставить приложениям службу аутентификации с включённым в неё каталогом. Это гарантирует что данному приложению не придётся иметь никакого подключения к локальной сети или прочим экземплярам LDS в данной сетевой среде периметра. Данное решение архитектурно предоставляет некую безопасную среду.

Большинство интегрированных с Active Directory приложений также требуют изменений схемы. При видоизменениях схемы такое приложение сохраняет определённые наборы данных в имеющейся базе данных Active Directory. При большом числе приложений схема Active Directory и данные также продолжат расти. В результате это приведёт к значительному воздействию на репликацию Active Directory, в особенности когда она происходит по медленным подключениям. Вместо хранения данных в самой базе данных Active Directory, дополнительные наборы данных приложений могут храниться в соответствующем экземпляре LDS. Экземпляр LDS всё ещё применяет для аутентификации AD DS. Хранящиеся в таком экземпляре LDS дополнительные наборы данных не будут реплицироваться ни в какие прочие Контроллеры домена.

Существуют среды и приложения, которые применяют наследуемые службы каталога на основе X500, которые хотелось бы перенести в AD DS. В таком случае в качестве посредника можно воспользоваться AD LDS, которая также способна сопровождать приложения на основе X500. Она также будет очищать рухлядь и перемещать в AD DS только отфильтрованные сведения. AD LDS сделает возможным запуск необходимого экземпляра в стороне от AD DS, а привилегированные решения идентификации, такие как MIM смогут, когда это необходимо, выполнять синхронизацию данных между экземплярами LDS и AD DS.

Azure AD Connect является инструментом Microsoft, который позволяет нам осуществлять синхронизацию идентификации пользователей из локального Active Directory в AD Azure. Даже хотя AD LDS и обладает возможностями службы каталога, Azure AD Connect не поддерживает синхронизацию из экземпляров AD LDS в Azure AD.

В Операционной системе Windows Server 2022 LDS может быть установлен при помощи Диспетчера сервера. Для установки LDS пользователю требуется зарегистрироваться в выбранных системах с полномочиями локального администратора.

После входа в систему, запустите Server Manager (Диспетчер сервера) и кликните по Add Roles and Features. После этого, следуя указаниям мастера, под Server Roles выберите Active Directory Lightweight Directory Services и продолжите включив данную роль:

После установки этой роли кликните в Server Manager по мастеру Post-Deployment Configuration. LDS может быть настроен двумя способами: один заключается в применении A unique instance, а другой состоит в использовании A replica of an existing instance. Вариант с репликой аналогичен клонированию копии некого имеющегося экземпляра.

Это в особенности полезно для некой среды разработки приложения, в которой инженерами необходимо поддерживать какое- то число версий приложения:

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

В появляющемся следом окне мы можем задать значение порта LDS. По умолчанию значение порта LDS устанавливается в 389, а портом SSL назначается 636. Когда вы запускаете множество экземпляров, их следует изменять соответствующим образом.

После этого мы можем создать раздел каталога данного приложения. Это позволит приложениям использовать данный раздел в качестве некого репозитория данных для хранения связанных с таким приложением сведений. Когда само приложение способно создавать некий раздел, это шаг не является необходимым и мы можем создать относящийся к делу каталог в процессе развёртывания самого приложения. При задании Partition name данного приложения, нам требуется предоставить его в неком формате отличительных имён (DN, Distinguished Name):

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

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

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

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

Этот шаг завершает нашу установку AD LDS и по её завершению мы можем создавать относящиеся к делу объекты и управлять ими. Для соединения с ними мы можем пользоваться двумя методами. Один способ состоит в применении инструмента ADSI Edit:

Другой метод заключается в применении командлета PowerShell. Это те же самые команды, которые мы применяем для управления объектами пользователя AD DS с тем единственным отличием, что нам требуется задавать необходимое DN (Distinguished Name, отличительное имя) и сервер:

New-ADUser -name "tidris" -Displayname "Talib Idris" -server 'localhost:389' -path "CN=webapp01,DC=rebeladmin,DC=com"
		

Наша предыдущая команда создаёт некую учётную запись пользователя с именем tidris в данном локальном экземпляре LDS, который запущен по порту 389. Его путём DNS является CN=webapp01,DC=rebeladmin,DC=com.

Get-ADUser -Filter * -SearchBase "CN=webapp01,DC=rebeladmin,DC=com" -server 'localhost:389'
		

Приведённая выше команда перечисляет все учётные записи пользователей, имеющиеся в заданном экземпляре LDS, CN=webapp01,DC=rebeladmin,DC=com. Если вы желаете узнать дополнительно о командах, обратитесь, пожалуйста, к Главе 7, Управление объектами Active Directory.

AD LDS может устанавливаться в некой настольной Операционной системе при помощи свойств Windows из Program and Features. Сами шаги установки аналогичны версии сервера. После того как AD LDS включена, мастер его настройки можно будет найти в Administrative Tools:

Этот вариант доступен во всех настольных ОС начиная с Windows Vista. Если это Windows 7, потребуется выгрузка с сайта Microsoft. Для управления объектами вам потребуется установить RSAT (Remote Server Administration Tools) или применять PowerShell.

Для среды Active Directory требуется жизнеспособная репликация. Active Directory применяет базу данных со множеством хозяев, поэтому все Контроллеры домена в его среде должны знать обо всех изменениях в базе данных Active Directory. Помимо этого, они также должны быть осведомлены об изменениях в Групповых политиках, сценариях запуска, настройках предпочтений и прочем. Когда речь заходит о репликациях, за них отвечает не только сама служба репликаций. Между Контроллерами домена также должно иметься стабильное подключение. Такой средой взаимодействия могут быть медные кабели, оптические кабели или даже SDN (Software- Defined Network, Программно- определяемая сетевая среда). В этом разделе мы намерены рассмотреть как мы можем применять интегрированные с Active Directory функциональные возможности для сопровождения жизнеспособных репликаций.

Для реплицирования содержимого папки SYSVOL Windows Server 2000 и 2003 применяют FRS. Начиная с Windows Server 2008, FRS был признан устаревшим и для репликаций папки SYSVOL ввёл DFSR:

Таблица 11-1. Сравнение FRS и DFSR

FRS	DFSR
FRS это некий устаревший протокол и начиная с Windows Server 2003 R2 в нём не было никаких разработок и вложений. Не выпускались никакие исправления ошибок и обновления. Устаревшие протоколы способны приводить к уязвимостям в безопасности систем, поскольку они могли не проверяться на современные уязвимости безопасности.	В протокол DFSR продолжают вноситься улучшения и инвестиции и он непрерывно тестируется на предмет угроз.
FRS применял алгоритм выигрыша для последней записи. Когда ваша система обнаруживает некое изменение файла в одной из папок SYSVOL, она становится авторизованным сервером и будет реплицировать весь этот файл в прочие контроллеры домена. При этом на объединяются изменения, весь файл копируется целиком, что может вызывать проблемы с производительностью, в особенности когда контроллеры домена соединены медленными подключениями.	DFSR позволяет вам реплицировать частичные изменения файла применяя репликации на уровне блоков. Она также поддерживает асинхронную репликацию файлов поверх медленных соединений. Когда вы запускаете Корпоративную редакцию (Enterprise Edition), для создания файлов на стороне клиента при использовании общих блоков, применяемых схожими файлами, могут применяться межфайловые RDC (Remote Differential Compression, Сжатия удалённых различий). Это снизит объём данных, которые требуется передавать по имеющимся подключениям.
FRS применяет файловое сжатие NTFS в промежуточной папке.	Сжатие файлов может контролироваться на основе типа файла.
Нет никакого интерфейса для мониторинга (API или WMI), а имеющиеся инструменты графического интерфейса для управления службами крайне ограничены. Эти инструменты графического интерфейса более не доступны после Windows Server 2003. Они не поддерживают мониторинг с применением Диспетчера System Center Operation.	Имеется современный инструментарий графический интерфейс для управления относящимися к теме службами, к тому же, этот графический интерфейс может применять WMI для отслеживания жизнеспособности данной службы. Также она имеет пакеты управления, разработанные для управления через имеющийся Диспетчер System Center Operation.
FRS не имеет системы составления отчётов для выработки диагностических отчётов когда они потребуются. Диагностика основывается лишь на событиях. Она к тому же ограничена счётчиками для просмотра производительности через PerfMon.	DFSR предоставляет поддержку выработки отчётов о жизнеспособности в формате XML или HTML Она также содержит множество счётчиков для просмотра состояний производительности при помощи PerfMon.
FRS не обладает системой самостоятельного восстановления в случае разрушения файла.	DFSR в случае выявления разрушений в данных способен самостоятельно восстанавливаться.
FRS не имеет полной поддержки среды RODC и она может обладать проблемами с синхронизацией данных.	DFSR целиком поддерживает репликации RODC.
FRS не обладает современными возможностями аудита, так как содержит лишь ограниченные записи в журналы событий и отладки.	DFSR вырабатывает богатые сведения о событиях и журналирование, которые могут применяться для аудита, поиска неисправностей и отладки отказов службы.

Даже хотя FRS и признана устаревшей начиная с Windows Server 2008, она всё ещё может применяться для репликаций когда вы мигрируете с Windows Server 2000 или 2003. В большинстве случаев инженеры забывают мигрировать к DFSR в рамках своих проектов обновления. Миграция с FRS в DFSR не может выполняться автоматически и включает несколько этапов, осуществляемых вручную. Это можно сделать при помощи утилиты Dfsrmig.exe. Для выполнения миграции с FSR в DFSR уровни функциональности ваших домена и леса должны быть как минимум Windows Server 2008.

Windows Server 2022 не способен поддерживаться в качестве Контроллера домена когда имеющийся домен всё ещё пользуется репликацией FRS для SYSVOL. Если мы попытаемся настроить Windows Server 2022 в качестве некого дополнительного Контроллера домена, мы получим следующую ошибку: The specified domain %1 is still using the File Replication Service (FRS) to replicate the SYSVOL share. FRS is deprecated. The server being promoted does not support FRS and cannot be promoted as a replica into the specified domain. You MUST migrate the specified domain to use DFS Replication using the DFSRMIG command before continuing. For more information, see https://bit.ly/30WjqPl.

Единственным обходным манёвром для этого выступает миграция имеющегося домена с FRS в DFSR.

Пошаговое руководство для миграции FRS в DFSR доступно в https://bit.ly/2Zj1huT.

Компоненты Active Directory представляют физическую и логическую структуры компании. Леса, домены и Организационные единицы Active Directory, а также объекты Active Directory, такие как компьютеры и пользователи, представляют логическую структуру компании. Роли и свойства Active Directory, такие как AD CS, AD RMS и AD FS, могут применяться для представления операций и требований безопасности организации. В некой инфраструктуре все эти компоненты соединены воедино при помощи физических соединений, таких как медь или оптика. Основываясь на имеющихся требованиях бизнеса, Active Directory может нуждаться в расширении на удалённые географически места. Они могут разниться начиная с прочих корпусов в том же самом месте, до расположения на разных континентах. Такие удалённые сетевые среды могут использовать для поддержки соединений друг с другом могут использовать различные соединения. Это могут быть VPN, выделенные медные линии, оптические подключения или даже соединения через спутник. По умолчанию Active Directory не разбирается с лежащей в его основе топологией. Если мы придерживаемся модели OSI (Open Systems Interconnection), Active Directory работает на уровне Приложений (Application level), а физические соединения представлены на Сетевом уровне. Имеются три основные причины зачем Active Directory должен также иметь сведения об этой физической топологии, и они таковы:

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

Репликация

Собственно успех имеющейся инфраструктуры по большей степени зависит от жизнеспособности репликации. Каждый Контроллер домена в вашей сетевой среде должен знать обо всех изменениях в конфигурации. Когда некий Контроллер домена включает синхронизацию, он передаёт данные через установленную физическую сетевую среду своему получателю. Он потребляет определённую часть полосы пропускания для этих данных. В зависимости от применяемого носителя и доступной полосы пропускания, такое воздействие от выполняемого обмена данными репликации будет различаться. Когда имеются высокоскоростные соединения, такие как 40 Gbps, 10 Gbps, 1 Gbps или 100 Mbps, тогда создаваемое обменом репликации воздействие будет очень низким. Однако для медленных соединений, таких как 128 Kbps или 256 Kbps, это воздействие будет значительно выше.

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

Аутентификация

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

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

Местоположения службы

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

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

Итак, давайте двинемся далее и рассмотрим далее площадки Active Directory и связанные с ними компоненты.

Площадки можно рассматривать как некие физические местоположения, которые содержат различные объекты Active Directory. Мы должны иметь возможность описания этих объектов при помощи их границ. Как пример, пользователи, компьютеры и сетевые устройства, расположенные в каком- то офисе в Лондоне могут рассматриваться как некая площадка, причём они должны идентифицироваться как уникальные, в отличии от аналогичных объектов, расположенных в офисе Сиэтла. Общая топология площадки Active Directory может быть разделена на четыре основные конструкции:

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

Подсети представляют ассоциированные с диапазонами адреса IP в каждой площадке. Они эквивалентны значениям подсетей, расположенных в сетевых устройствах, но не обязательно должны быть в точности теми же самыми. Например, когда некая площадка применяет 10-20 подсетей класса C, тогда вместо добавления их всех в общую подсеть Active Directory данной площадки мы можем суммировать их в некую подсеть класса B и пользоваться ею. На основании таких сведений подсети Active Directory делает возможным для объектов определять местоположение ближайшего Контроллера домена. При добавлении или удалении физических подсетей они должны обновляться также и в общей настройке площадки Active Directory, в противном случае они будут передаваться неуправляемым образом обменом по медленным подключениям.

Подключения площадки представляют собой физические соединения между площадками; они однако не контролируют определённый сетевой уровень маршрутизации или соединениями между площадками. Это всё ещё будет обрабатываться лежащими в основе подключениями WAN и сетевыми устройствами. Подключения площадок делают возможным планирование заданий репликаций и контроль над полосой пропускания (стоимость подключения).

Мосты подключений площадок содержат множество подключений площадок. Это делает возможным прозрачное взаимодействие между всеми подключениями площадки под таким мостом. По умолчанию, все подключения площадок рассматриваются в качестве мостов. В некоторых случаях не всем площадкам требуется общаться друг с другом. Это контролируется установленными в их сетевых устройствах правилами маршрутизации; когда они настроены таким образом, устанавливаемое по умолчанию поведение подобных мостов подключений следует изменить и убедиться что Bridge all site links отключено:

Лучше всего пояснить мосты подключений площадок применяя этот простой пример. Согласно приведённой схеме, для достижения Площадкой Лондона Площадки Канады существует два пути: один применяет A, а другой пользуется B и C. Таким образом, на Площадке Сиэтла мы можем создать некий мост подключения площадки, который содержит подключения площадок B и C и представить его как некий альтернативный путь достижения Площадки Канады.

Существует два способа управления площадками AD и связанными с ними компонентами. Один вариант состоит в применении Консоли управления (MMC) Площадки и службы Active Directory (AD Sites and Services), а другой заключается в использовании командлетов PowerShell. Чтобы добавлять/ изменять/ удалять площадки и связанные с ними настройки, нам требуется обладать полномочиями Администратора домена/ Администратора предприятия.

MMC Площадки и службы Active Directory будет доступна в любом сервере, который имеет включённой службу AD DS или в любом сервере/ компьютере с установленным RSAT.

Модуль Active Directory PowerShell также будет доступен в любом сервере, который имеет включённой роль AD DS или имеет установленным инструменты RSAT.

Когда в устанавливаемую инфраструктуру вводится самый первый Контроллер домена, данная система создаёт свою самую первую площадку с названием Default-First-Site-Name. Это можно изменить на основании задаваемых требований. Мы можем просмотреть настройки имеющихся площадок при помощи следующего командлета PowerShell:

Get-ADReplicationSite -Filter *
		

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

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

Rename-ADObject -Identity "CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=rebeladmin,DC=com" -NewName "LondonSite"
				

Наша предыдущая команда переименовывает название площадки Default-First-Site-Name на LondonSite. В своей имеющейся площадке мы способны изменять значения при помощи командлета Set-ADReplicationSite:

Get-ADReplicationSite -Identity LondonSite | Set-ADReplicationSite -Description "UK AD Site"
		

Приведённая выше команда изменила описание площадки на UK AD Site.

Новую площадку Active Directory мы можем создать при помощи командлета New-ADReplicationSite. Полное описание данной команды можно просмотреть воспользовавшись Get-Command NewADReplicationSite -Syntax.

New-ADReplicationSite -Name "CanadaSite" -Description "Canada AD Site"
		

Данная команда создала некую новую площадку с названием CanadaSite.

После того как необходимые площадки созданы, нам требуется переместить требующиеся Контроллеры домена в соответствующие площадки. По умолчанию все контроллеры домена помещаются в устанавливаемую по умолчанию же площадку, Default-First-Site-Name.

В своей следующей команде мы перечисляем все имеющиеся в текущей инфраструктуре Active Directory Контроллеры домена с фильтрацией сведений для отображения значений атрибутов Name, ComputerObjectDN, Site:

Get-ADDomainController -Filter * | select Name,ComputerObjectDN,Site | fl
		

Теперь у нас имеется полный список Контроллеров домена; на своём следующем шаге мы можем переместить соответствующий контроллер домена на подходящую ему площадку:

Move-ADDirectoryServer -Identity "REBEL-SDC-02" -Site "CanadaSite"
		

Предыдущая команда переместит указанный Контроллер домена REBEL-SDC-02 на CanadaSite.

Совет

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

Управление подключениями площадки

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

Стоимость подключения площадки

Стоимость подключения площадки определяет ближайшие ресурсы когда недоступны локальные ресурсы. В имеющейся сетевой топологии конкретные подключения площадок в основном базируются на значении полосы пропускания подключения. Но здесь стоимость подключения площадки основывается на значениях полосы пропускания, задержек и устойчивости. Например, допустим, площадки A и B соединяются через некое подключение 100 Mbps. Площадки A и C соединены подключением 512 kbps. Когда мы рассматриваем лишь значение полосы пропускания, площадка A предпочтёт в качестве ближайшей площадку B. Однако, в последние месяцы это подключение имело ряд отказов, а потому соединение в 512 kbps более устойчивое. Изменяя значение стоимости подключения я способен заставить площадку A применять площадку C как более предпочтительную ближайшую площадку ресурсов.

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

 

Рисунок 11-10

Образец стоиомсти соединения площадки

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

Первым предпочтением будет выступать то подключение площадки, которое содержит наименьшую стоимость. Когда система определяет значение кода получателя, она не принимает во внимание имеющиеся прямые подключения. Аналогично, некая сетевая топология обнаружит наилучший маршрут. В нашем предыдущем примере, когда Площадка Лондона желает достичь Площадку Канады, имеются два пути: один это прямой путь, а второй пролегает через Площадку Сиэтла. Поэтому, когда мы ищем наилучший путь, будет вычислена стоимость прямого подключения и оно сопоставится со значением стоимостиПлощадка Лондона | Площадка Сиэтла | Площадка Канады.

Приводимый ниже перечень содержит значения предпочтительных стоимостей площадок на основании величины полосы пропускания. Это значение стоимости вычисляется делением 1 024 на значение логарифма доступной полосы пропускания (кбит/с).

Например, значение логарифма 512 это 2.09. При делении 1 024 на 2.09 мы получаем 377.999. Таким образом, значение стоимости линии 512 Kbps составляет 378:

Таблица 11-2. Предпочтительные значения стоимости для величин полосы пропускания

Доступная полоса пропускания	Стоимость
9.6 kbps	1 042
19.2 kbps	798
38.4 kbps	644
56 kbps	586
64 kbps	567
128 kbps	486
256 kbps	425
512 kbps	378
1 024 kbps	340
2 048 kbps	309
4 096 kbps	283
10 Mbps	257
100 Mbps	205
1 000 Mbps	171

Протоколы обмена между площадками

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

Интервалы репликаций

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

Расписания репликаций

По умолчанию, репликации площадки происходят 24/ 7. На основании анализа имеющейся полосы пропускания площадки это может быть изменено. Например, когда имеется медленное подключение, лучше устанавливать репликации после часов работы и на протяжении часов перерывов. Это будет контролировать воздействие текущего обмена репликациями в медленных подключениях и позволять организациям применять всю полосу пропускания для прочего критически важного обмена. Важно оценивать все последствия изменения своего расписания репликаций. Когда вы добавляете/ изменяете объекты и политики, они не будут реплицированы между площадками пока не наступит их очередь по расписанию.

Для настройки необходимого подключения площадки мы можем воспользоваться командлетом New-ADReplicationSiteLink:

New-ADReplicationSiteLink -Name "London-Canada" -SitesIncluded LondonSite,CanadaSite -Cost 205 -ReplicationFrequencyInMinutes 30 -InterSiteTransportProtocol IP
		

Приводимая выше команда создаёт некое новое подключение площадки с названием London-Canada, которая включает в себя LondonSite и CanadaSite. Общая стоимость подключения устанавливается в 205, а интервал данной репликации устанавливается на каждые 30 минут. Его транспортным протоколом устанавливается IP.

Мы можем сделать ту же самую конфигурацию применяя MMC Active Directory Sites and Services:

 

Рисунок 11-11

Соединение площадки

Мы можем изменять установленное расписание репликаций при помощи параметра -ReplicationSchedule или через GUI. Чтобы изменять это при помощи GUI кликните по кнопке Change Schedule.... Далее в этом окне вы можете изменять установленное расписание репликаций.

В этой демонстрации я меняю те репликации, которые происходят с понедельника по пятницу с 6:00 до 10:00 в первой половине дня:

 

Рисунок 11-12

Расписание репликации соединения площадки

Мост подключений площадки

Мы можем создать необходимое подключение площадки применив командлет New-ADReplicationSiteLinkBridge:

New-ADReplicationSiteLinkBridge -Name "London-Canada-Bridge" -SiteLinksIncluded "London-Canada","London-CanadaDRLink"
		

Наша предыдущая команда создаёт некий мост подключения площадки с названием London-Canada-Bridge при помощи двух подключений площадок: London-Canada и London-CanadaDRLink.

При помощи командлета Set-ADReplicationSiteLinkBridge уже имеющийся мост подключения площадки можно изменить:

Set-ADReplicationSiteLinkBridge -Identity "London-Canada-Bridge" -SiteLinksIncluded @{Remove='London-CanadaDRLink'}
		

Приведённая выше команда переместит установленное подключение площадки London-CanadaDRLink с имеющегося моста подключения площадки, London-Canada-Bridge:

Set-ADReplicationSiteLinkBridge -Identity "London-Canada-Bridge" -SiteLinksIncluded @{Add='London-CanadaDRLink'}
		

Наша последняя команда добавила заданное подключение площадки к имеющемуся мосту подключения площадки.

Серверы- плацдармы

В установленной инфраструктуре AD, KCC (Knowledge Consistency Checker, Проверка состоятельности знаний) это некий встроенный процесс, который запускается в Контроллерах домена и отвечает за выработку топологии репликации. Он будет настраивать необходимое соединение репликации между Контроллерами домена. Когда наступает время репликации между площадками, KCC выбирает некий Контроллер домена в качестве сервера плацдарма (bridgehead server), который отправляет и принимает обмен для своей площадки. Когда у вас имеется множество доменов во множестве площадок, все домены обязаны обладать своим собственным сервером плацдарма. Некая площадка может иметь множество серверов плацдарма для того же самого домена, однако в некий заданный момент времени активен лишь один. Это решается на основании наименьшего значения GUID контроллеров домена. В определённой среде Active Directory, когда Active Directory содержит репликации между площадками, Active Directory автоматически выбирает необходимые серверы плацдарма. Тем не менее, встречаются ситуации при которых вы можете предпочесть в качестве действующего сервера плацдарма некий определённый сервер.

Открыв установленный свойства для необходимого Контроллера домена вы можете выбрать кого именно вы желаете назначать сервером плацдарма. В качестве такого сервера плацдарма рекомендуется назначать наиболее устойчивый Контроллер домена:

 

Рисунок 11-13

Выбор сервера плацдарма

Управляемые подсети

Теперь когда у нас имеются подходящие площадки и установлены подключения площадок, нашим следующим шагом является назначение подсетей каждой присутствующей площадке. Это можно настраивать при помощи командлета New-ADReplicationSubnet:

New-ADReplicationSubnet -Name "192.168.0.0/24" -Site LondonSite
		

Наша предыдущая команда PowerShell создаёт некую новую подсеть, 192.168.0.0/24, и назначает её для LondonSite.

при помощи Set-ADReplicationSubnet мы можем изменять значение имеющейся подсети:

Set-ADReplicationSubnet -Identity "192.168.0.0/24" -Site CanadaSite
		

Приведённая выше команда изменила значение площадки для подсети 192.168.0.0/24 на CanadaSite.

Для поиска значения сведений о подсети мы можем применять командлет Get-ADReplicationSubnet:

Get-ADReplicationSubnet -Filter {Site -Eq "CanadaSite"}
		

Предыдущая команда перечисляет все имеющиеся подсети в CanadaSite.

Как работают репликации?

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

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

• Репликации внутри площадок

• Репликации между площадками

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

Репликации внутри площадки

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

 

Рисунок 11-14

Репликация внутри площадки

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

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

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

Репликации между площадками

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

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

 

Рисунок 11-15

Репликация между площадками

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

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

KCC

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

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

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

Для понимания подобной KCC лучшим способом является его сопоставление с неким протоколом сетевой маршрутизации. Протокол сетевой маршрутизации отвечает за поддержание какого- то пути маршрутизации для соединённых сетевых сред. Когда сетевой среде A требуется взаимодействие с сетевой средой B, имеющаяся таблица маршрутизации сообщит ему каким именно путём воспользоваться. Точно так же, создаваемая KCC топология сообщает нам как контроллер домена A может выполнять репликацию необходимых изменений в контроллер домена B. При работе над проектами Active Directory я был свидетелем того, как инженеры создавали вручную подключения репликаций между контроллерами домена. Но я действительно сомневаюсь в том, что кто- то способен оказаться умнее имеющейся 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):

 

Рисунок 11-16

Значение UPN

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