Репликация контроллеров домена: Управление репликацией Active Directory

Содержание

Управление репликацией Active Directory | Windows для системных администраторов

Обеспечение корректной репликации в лесу Active Directory – это одна из главных задач администратора AD. В этой статье попытаемся понять базовые принципы репликации базы Active Directory и методики диагностики неисправности. Стоит отметить, что репликации — один из основополагающих принципов построения современной корпоративной сети на базе AD, так, например, мы уже говорили о репликации групповых политик в домене AD и репликации зон DNS.

Для мониторинга репликации Active Directory в корпоративной среде Microsoft рекомендует использовать продукт SCOM (либо другие продукты мониторинга с похожим функционалом). Кроме того, для мониторинга репликации AD можно использовать утилиту repadmin (repadmin /showrepl * /csv) совместно с самописными скриптами анализа вывода этой утилиты. Типичные проблемы, связанные с ошибками репликации Active Directory, — ситуации, когда объекты не появляются в одном или нескольких сайтах (например, только что созданный пользователь, группа или другой объект AD не доступны на контроллерах домена в других сайтах).

Хорошая отправная точка для поиска неисправности в механизме репликации Active Directory – анализ журнала «Directory Services» на контроллерах домена. Конкретные действия будут зависеть от того, какие ошибки будут обнаружены в журнале, однако для разрешения проблем нужно достаточно четко понимать процессы репликации Active Directory.

Одним из базовых элементов управлением трафиком репликации между контроллерами домена являются сайты Active Directory. Сайты связаны между собой особыми связями, называемыми «site link», которые определяют стоимость маршрутизации данных AD (элементы леса, домена, папка SYSVOL и т.д.) между различными сайтами. Расчет алгоритма управления и маршрутизации трафика репликации в лесу ведется службой KCC.

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

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

repadmin /showism

данная команда отобразит список сайтов в лесу Active Directory. Для каждого из сайтов указаны 3 значения: стоимость репликации между двумя сайтами, интервал репликации в минутах, а также дополнительные настроенные параметры межсайтовой связи. Вывод этой команды может выглядеть так:

C:\>repadmin /showism==== TRANSPORT CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=winitpro,DC=ru CONNECTIVITY INFORMATION FOR 3 SITES: ====0,    1,    2Site(0) CN=LAB-Site1,CN=Sites,CN=Configuration,DC=winitpro,DC=ru0:0:0, 10:15:0, 10:30:0All DSAs in site CN=ADP-ADSN,CN=Sites,CN=Configuration,DC=lab,DC=net (with trans& hosting NC) are bridgehead candidates.Site(1) CN=LAB-Site2,CN=Sites,CN=Configuration,DC=winitpro,DC=ru10:15:0, 0:0:0, 20:30:0All DSAs in site CN=ADP-Intranet,CN=Sites,CN=Configuration,DC=lab,DC=net (with trans & hosting NC) are bridgehead candidatesSite(2) CN=LAB-Site3,CN=Sites,CN=Configuration,DC=winitpro,DC=ru10:30:0, 20:30:0, 0:0:01 server(s) are defined as bridgeheads for transport CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=winitpro,DC=ru &site CN=LAB-Site3,CN=Sites,CN=Configuration,DC=winitpro,DC=ru:Server(0) CN=testlabdc2,CN=Servers,CN=LAB-Site3,CN=Sites,CN=Configuration,DC=winitpro,DC=ruC:\>

В вышеприведённом логе видно, что в домене winitpro.ru существует 3 сайта, которые называется соответственно Site(0), Site(1) иSite(2). Каждый из сайтов имеет 3 набора репликационной информации, по одной для каждого сайта в лесу. Например, настроена связь между Sites(2) (LAB-Site3) и Site(0) (LAB-Site1), параметры этой связи — 10:30:0, что означает: 10 – стоимость репликации, и интервал репликации 30 минут. Также обратите внимание, что для сайта Site(2) задан сервер-плацдарм (bridgehead) – это контроллер домена с именем testlabdc2.

Контроллеры домена, партнеры по репликации – могут быть идентифицированы при помощи графического Gui или при помощи утилит командной строки. Откройте консоль MMC «Active Directory Sites and Services», разверните узел Sites, в нем найдите интересующий ваш сайт. В этом узле будут содержатся контроллеры домена, относящиеся к этому сайту. Развернув контроллер домена и выбрав пункт NTDS Settings, вы увидите всех партнеров по репликации данного контроллера домена.

В командной строке при помощи команды nslookup можно получить список контроллеров домена, относящихся к нашему сайту (естественно для этого необходимо, чтобы все DC имели корректные записи SRV). Формат команды такой:

nslookup -type=srv _ldap._tcp.._sites.dc._

на выходе получаем примерно следующее:

C:\>_ldap._tcp.LAB-Site1._sites.dc._msdcs.winitpro.ru SRV service locationpriority       = 0weight         = 100port           = 389svr hostname   = testlabdc1.winitpro.ru_ldap._tcp.LAB-Site1._sites.dc._msdcs.winitpro.ru SRV service locationpriority       = 0weight         = 100port           = 389svr hostname   = testlabdc2.winitpro.rutestlabdc1.winitpro.ru       internet address = 172.21.23.13testlabdc2.winitpro.ru       internet address = 172.21.23.16

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

repadmin /showrepl

Стоит отметить, что служба DNS – это важный компонент службы репликации Active Directory. Контроллеры домена регистрируют свои SRV записи в DNS. Каждый контроллер домена в лесу регистрирует записи CNAME вида dsaGuid._msdcs.forestName, где dsaGuid –GUID видимый у объекта в пункте NTDS Settings в консоли «AD Sites and Services». Если в журнале Directory Services есть ошибки, связанные со службой DNS, для проверки корректных записей типа CNAME и A для контроллера домена.

dcdiag /test:connectivity

Если будут ошибки, перезапустите службу Netlogon, в результате чего произойдет перерегистрация отсутствующих dns записей. Если dcdiag все также будет выдавать ошибки, проверьте конфигурацию службы DNS и корректность DNS настроек на DC. Для более детального знакомства с темой тестирования служб dns, рекомендую обратиться к статье Диагностика проблем с поиском контроллера домена.

Команда repadmin имеет специальный параметр /replsummary, который позволяет быстро проверить состояние репликации на конкретном контроллере домена (указывается его имя) или на всех контроллерах (опция wildcard).

repadmin /replsummary [targetDC|wildcard]

В том случае, если ошибки репликации отсутствуют, в выводе этой команды будет видно, что ошибок – 0.:

C:\>repadmin /replsummary testlabdc2Replication Summary Start Time: 2010-01-24 15:56:03Beginning data collection for replication summary, this may take awhile:....Source DSA       largest delta    fails/total  %% errortestlabdc1           06m:27s       0 /   3    0testlabdc3           06m:27s       0 /   6    0testlabdc4           06m:27s       0 /   5    0Destination DSA  largest delta    fails/total  %% errortestlabdc3           06m:27s       0 /  14    0C:\>

В том случае, если ошибки все-таки будут, при помощи утилиты Repadmin можно получить более полную информацию. Каждый контроллер домена имеет собственный уникальный USN (Update Sequence Number), который инкрементируется каждый раз при успешном изменении обновлении объекта Active Directory. При инициализации репликации, партнеру передается USN, который сравнивается с USN, полученным в результате последней успешной репликации с данным партнером, тем самым определяя сколько изменений произошло в базе AD со времени последней репликации.

При помощи ключа /showutdvec, можно получить список текущих значений USN, хранящихся на указанном DC.

repadmin /showutdvec

например

C:\>repadmin /showutdvec  testlabdc4 DC=winitpro,DC=ruCaching GUIDs.....LAB-Site1\testlabdc1   @ USN  16608532 @ Time 2010-01-24 16:27:11LAB-Site1\testlabdc2   @ USN    307126 @ Time 2010-01-24 16:27:27LAB-Site2\testlabdc3   @ USN 297948217 @ Time 2010-01-24 16:19:34LAB-Site3\testlabdc4   @ USN 245646728 @ Time 2010-01-24 16:19:36C:\>

Запустив эту команду на контроллере домена, на котором наблюдаются проблемы с репликацией, можно понять насколько различаются базы AD, просто сравнив значения USN.

Тестирование репликации Active Directory при помощи утилиты repadmin можно осуществить несколькими способами:

replmon /replicate <targetDC> <sourceDC> <dirPartition> (позволяет запустить репликацию определенного раздела на указанный контроллер домена)
replmon /replsingleobj <targetDC> <sourceDC> <objPath> (репликация конкретного объекта между двумя DC)
replmon /syncall <targetDC> (синхронизация указанного контроллера домена со всем партнерами по репликации)

C:\>repadmin /replicate testlabdc1 testlabdc3 DC=winitpro,DC=ruSync from testlabdc3 to testlabdc1 completed successfully.C:\>repadmin /replsingleobj testlabdc1 testlabdc3 cn=stuart,ou=dsusers,DC=winitpro,DC=ruSuccessfully replicated object cn=stuart,ou=dsusers,DC=winitpro,DC=ruto testlabdc1 from .C:\>repadmin /replsingleobj testlabdc1 testlabdc3 ou=dsusers,dc=lab,dc=netSuccessfully replicated object ou=dsusers,DC=winitpro,DC=ru to testlabdc1 from .C:\>repadmin /replsingleobj testlabdc1 testlabdc3 DC=winitpro,DC=ruSuccessfully replicated object DC=winitpro,DC=ru to testlabdc1 from.C:\>repadmin /syncall testlabdc3CALLBACK MESSAGE: The following replication is in progress:From: 25fdc051-6ff6-4922-bc02-0b77a4652bfc._msdcs.winitpro.ruTo  : 99305007-2290-489b-9551-20827ba0664d._msdcs.winitpro.ruCALLBACK MESSAGE: The following replication completed successfullyFrom: 25fdc051-6ff6-4922-bc02-0b77a4652bfc._msdcs.winitpro.ruTo  : 99305007-2290-489b-9551-20827ba0664d._msdcs.winitpro.ruCALLBACK MESSAGE: The following replication is in progress:From: b0870af5-ab82-4372-9e39-0a9772a5e47c._msdcs.winitpro.ruTo  : 99305007-2290-489b-9551-20827ba0664d._msdcs.winitpro.ruCALLBACK MESSAGE: The following replication completed successfullyFrom: b0870af5-ab82-4372-9e39-0a9772a5e47c._msdcs.winitpro.ruTo  : 99305007-2290-489b-9551-20827ba0664d._msdcs.winitpro.ruCALLBACK MESSAGE: SyncAll Finished.SyncAll terminated with no errors.C:\>

При наличии проблем с механизмом репликации Active Directory, нужно знать и уметь пользоваться утилитами repadmin, nslookup, dcdiag, крайне полезен при анализе журнал событий Directory Services. В особо сложный и нестандартных ситуациях может помочь база знаний Microsoft KB, в которой описаны типовые проблемы и методики их решения. Поиск по базе KB обычно осуществляется по идентификаторам ошибок (Event ID), полученным из указанного журнала..

Repadmin и проверка репликации Active Directory

Добрый день! Уважаемые читатели и гости одного из лучших IT блогов Pyatilistnik.org. Не так давно я вам подробно рассказывал из каких компонентов и служб состоит Active Directory. Сегодня я хочу дополнить данную публикацию и подробно рассказать про утилиту командной строки Repadmin, благодаря ей я вас научу диагностировать репликацию между контроллерами домена, покажу как находить и решать проблемы в вашей доменной инфраструктуре. Каждый системный администратор, просто обязан ее знать и уметь ей пользоваться, если вы еще не из их числа, то давайте это исправлять.

Что такое Repadmin?

Если вы работаете с несколькими доменами Active Directory или сайтами AD, то вы обязательно столкнетесь с проблемами в какой-то момент, особенно в процессе репликации. Репликация, это самый важный жизненный цикл в доменных службах. Эта репликация важна, так как ее отсутствие может вызвать проблемы с аутентификацией. В свою очередь, это может создать проблемы с доступом к ресурсам в сети. Компания Microsoft это понимает, как никто другой и создала для этих задач отдельную утилиту Repadmin.

Repadmin — это инструмент командной строки, для диагностики и устранения проблем репликации Active Directory. Repadmin можно использовать для просмотра топологии репликации с точки зрения каждого контроллера домена. Кроме того, вы можете использовать Repadmin, чтобы вручную создать топологию репликации, инициировать события репликации между контроллерами домена и просматривать метаданные репликации и векторы актуальности (UTDVEC). Вы также можете использовать Repadmin.exe для мониторинга относительной работоспособности леса доменных служб Active Directory (AD DS).

Как установить Repadmin?

Repadmin.exe встроен в Windows Server 2008 и выше, вы легко найдете его и на Windows Server 2019. Он доступен, если у вас установлена роль AD DS или сервера AD LDS. Он также доступен в клиентских ОС, таких как Windows 10, если вы устанавливаете инструменты доменных служб Active Directory, которые являются частью средств удаленного администрирования сервера (RSAT).

Требования для использования Repadmin

использование Repadmin требует учетных данных администратора на каждом контроллере домена, на который нацелена команда. Члены группы «Администраторы домена» имеют достаточные разрешения для запуска repadmin на контроллерах домена в этом домене. Члены группы «Администраторы предприятия» по умолчанию имеют права в каждом домене леса. Если вы запустите утилиту без необходимых прав, то вы получите сообщение:

Ошибка функции DsBindWithCred для компьютера, состояние ошибки 1753 (0x6d9):
В системе отображения конечных точек не осталось доступных конечных точек.

Вы также можете делегировать конкретные разрешения, необходимые для просмотра и управления состоянием репликации.

Основные ключи Repadmin

Запустите командную строку от имени администратора или откройте PowerShell в режиме администратора и выполните команду:

В результате вы получите справку по утилите.

Теперь опишу вам за что отвечает каждый ключ:

/kcc — Принудительно проверяет согласованность (Knowledge Consistency Checker (KCC)) на целевых контроллерах домена, чтобы немедленно пересчитать топологию входящей репликации.
/prp — Можно просматривать и изменять политику репликации паролей (PRP) для контроллеров домена только для чтения (RODC).
/queue — Отображает запросы входящей репликации, которые необходимо обработать контроллеру домена, чтобы получить последние данные от партнеров по репликации, у которых более свежие данные.
/replicate — Запускает немедленную репликацию указанного раздела каталога на целевой контроллер домена с исходного контроллера домена.
/replsingleobj — Реплицирует один (отдельный) объект между любыми двумя контроллерами домена, которые имеют общие разделы каталога.
/replsummary — Операция replsummary быстро и кратко обобщает состояние репликации и относительную работоспособность леса. Определяет контроллеры домена, которые не выполняют входящую или исходящую репликацию, и суммирует результаты в отчете.
/rodcpwdrepl — Запускает репликацию паролей для заданных пользователей с источника (контроллера домена концентратора) на один или более доступных только для чтения контроллер домена.
/showattr — Отображает атрибуты объекта.
/showobjmeta — Отображает метаданные репликации для указанного объекта, хранящиеся в Active Directory, например, идентификатор атрибута, номер версии, исходящий и локальный USN, а также глобальный уникальный идентификатор GUID исходящего сервера (сервера-отправителя) и метку даты и времени.
/showrepl — Отображает состояние репликации, когда указанный контроллер домена последний раз пытался выполнить входящую репликацию разделов Active Directory.
/showutdvec — Отображает наибольший поддерживаемый последовательный номер обновления (USN), который в указанной копии контроллера домена Active Directory показан как поддерживаемый для этой копии и транзитивных партнеров.
/syncall Синхронизирует указанный контроллер домена со всеми партнерами репликации.

Дополнительные параметры

/u: — Указание домена и имени пользователя с обратной косой чертой в качестве разделителя {домен\пользователь}, у которого имеются разрешения на выполнение операций Active Directory. UPN-вход не поддерживается.
/pw:— Задание пароля для пользователя, указанного в параметре /u.
/retry — Этот параметр вызывает повтор попытки создать привязку к конечному контроллеру домена, когда при первой попытке произошел сбой с одним из следующих состояний ошибки ( 1722 0x6ba : «Сервер RPC недоступен» или 1753 / 0x6d9 : «Отсутствуют конечные точки, доступные из сопоставителя конечных точек»)
/csv — Применяется с параметром /showrepl для вывода результатов в формате значений, разделенных запятыми (CSV).

Просмотр общего состояния репликации

Эта команда быстро покажет вам общее состояние репликации.

В результате вы увидите присутствуют ли у вас сбои при репликации. временные дельты, количество ошибок. Вы можете заметите, что отчет разделен на два основных раздела — DSA-источник и DSA-адресат.

Обратите внимание, что одни и те же серверы перечислены в обоих разделах. Причина этого заключается в том, что Active Directory использует модель с несколькими основными доменами. Другими словами, обновления Active Directory могут быть записаны на любой контроллер домена (с заметными исключениями контроллеры домена только для чтения). Эти обновления затем реплицируются на другие контроллеры домена в домене. По этой причине вы видите одинаковые контроллеры домена в списке как DSA-источника, так и получателя. Если бы мой домен содержал какие-либо контроллеры домена только для чтения, они были бы перечислены только в разделе DSA назначения.

Сводный отчет о репликации не просто перечисляет контроллеры домена, в нем также перечислены самые большие дельты репликации. Вы также можете просмотреть общее количество попыток репликации, которые были недавно предприняты, а также количество неудачных попыток и увидеть процент попыток, которые привели к ошибке.

repadmin /replsummary /bysrc

Ключ /bysrc — Суммирует состояние репликации для всех контроллеров домена, на которые реплицирует данный исходный контроллер домена. В отчете вы получите данные только по исходному DSA.

repadmin /replsummary /bydest

Ключ /bydest — Суммирует состояние репликации для всех контроллеров домена, с которых реплицирует данный целевой контроллер домена. Отображает только конечный DSA.

Ключ /sort — Сортирует выходные данные по столбцам.

delta: сортирует результаты в соответствии с наименьшим значением дельта для каждого контроллера домена источника или назначения.
partners: сортирует список результатов по количеству партнеров по репликации для каждого контроллера домена.
failures: сортирует список результатов по количеству сбоев репликации партнеров для каждого контроллера домена.
error: сортирует список результатов по последнему результату репликации (коду ошибки), который блокирует репликацию для каждого контроллера домена. Это поможет вам устранить причину сбоя для контроллеров домена, которые выходят из строя с общими ошибками.
percent: сортирует список результатов по проценту ошибок репликации партнера для каждого контроллера домена. (Это рассчитывается путем деления количества отказов на общее количество попыток, а затем умножения на 100; то есть отказы/общее число попыток *100.) Это поможет вам расставить приоритеты в работе по устранению неполадок путем определения контроллеров домена, которые испытывают самую высокую частота ошибок репликации.
unresponsive: сортирует список результатов по именам партнеров, которые не отвечают на запросы репликации для каждого контроллера домена.

Пример применения дополнительных ключей

repadmin /replsummary /bysrc /bydest /sort:delta

Вы можете указать параметры /bysrc и /bydest одновременно. В этом случае Repadmin сначала отображает таблицу параметров /bysrc, а затем таблицу параметров /bydest. Если оба параметра / bysrc и /bydest отсутствуют, то Repadmin отображает параметр с наименьшим количеством ошибок партнеров.

Вот пример ошибки «1722: The RPC server is unavailable», которую может показать repadmin с ключом replsummary.

Просмотр топологии репликации и ошибки

Команда repadmin /showrepl помогает понять топологию и ошибки репликации. Он сообщает, о состоянии каждого исходного контроллера домена, с которого у получателя есть объект входящего соединения. Отчет о состоянии делится на разделы каталога.

Административная рабочая станция, на которой вы запускаете Repadmin, должна иметь сетевое подключение удаленного вызова процедур (RPC) ко всем контроллерам домена, на которые нацелен параметр DSA_LIST. Ошибки репликации могут быть вызваны исходным контроллером домена, контроллером домена назначения или любым компонентом процесса репликации, включая базовую сеть.

Команда отображает GUID каждого объекта, который был первоначально реплицирован, а также результат репликации. Это полезно, чтобы обнаружить возможные проблемы. Как видите в моем примере, все репликации успешно пройдены. Если хотите получить максимально подробную информацию, о топологии репликации, то добавьте ключ «*».

В моем примере вы можете увидеть ошибку:

Repadmin: выполнение команды /Showrepl контроллере домена dc03.child.root.pyatilistnik.org с полным доступом
Ошибка LDAP: 82 (Локальная ошибка) ошибка Win32: 8341. (The target principal name is incorrect)

В приведенном выше примере решение проблемы заключается в остановке службы «Центр распространения ключей Kerberos (Kerberos key distribution center)«. Запустите ее. В редких случаях может потребоваться перезапустить службу «Доменные службы Active Directory«. Затем перезапустите процесс репликации через сайты и службы Active Directory. Проверьте свои журналы, и репликация должна быть успешной. Так же вы можете использовать и дополнительные ключи:

DSA_LIST — Задает имя хоста контроллера домена или списка контроллеров домена, разделенных в списке одним пробелом.
Source DSA object GUID — GUID исходного объекта DSA. Указывает уникальное шестнадцатеричное число, которое идентифицирует объект, чьи события репликации перечислены.
Naming Context (Контекст именования) — Определяет отличительное имя раздела каталога для репликации.
/verbose — Отображает дополнительную информацию об исходных партнерах, от которых контроллер домена назначения выполняет входящую репликацию. Информация включает в себя полностью уточненное CNAME, идентификатор вызова, флаги репликации и значения порядкового номера обновления (USN) для исходных обновлений и реплицированных обновлений.
/NoCache — Указывает, что глобально уникальные идентификаторы (GUID) остаются в шестнадцатеричной форме. По умолчанию GUID переводятся в строки.
/repsto — Перечисляет контроллеры домена-партнера, с которыми целевые контроллеры домена используют уведомление об изменении для выполнения исходящей репликации. (Контроллеры домена-партнера в этом случае являются контроллерами домена на том же сайте Active Directory, что и исходный контроллер домена, и контроллеры домена, которые находятся на удаленных сайтах, на которых включено уведомление об изменениях.) Этот список добавляется в разделе СОБСТВЕННЫЕ СОСЕДИ ДЛЯ УВЕДОМЛЕНИЙ ОБ ИЗМЕНЕНИЯХ (OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ).
/conn — Добавляет раздел KCC CONNECTION OBJECTS в Repadmin, в котором перечислены все соединения и причины их создания.
/all — Запускается как /repsto и Conn параметры.
/errorsonly — Отображает состояние репликации только для исходных контроллеров домена, с которыми конечный контроллер домена сталкивается с ошибками репликации.

/intersite — Отображает состояние репликации для подключений от контроллеров домена на удаленных сайтах, с которых контроллер домена, указан в параметре DSA_LIST, выполняет входящую репликацию.
/CSV — Экспорт или вывод результатов в формате с разделителями-запятыми (CSV).

Просмотр очереди репликации

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

Слишком много одновременных партнеров по репликации
Высокая скорость изменения объектов в доменных службах Active Directory (AD DS), предположим что у вас одновременно с помощью скрипта было сформировано 1000 новых групп или создано 1000 пользователей.
Недостаточная пропускная способность CPU или сети, которые реплицирует контроллер домена

Чтобы посмотреть очередь репликации на контроллере домена, вам нужно воспользоваться ключом /Queue:

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

Repadmin: выполнение команды /queue контроллере домена localhost с полным доступом
Очередь содержит 1 элементов.
Текущая задача начала выполняться в 2020-02-18 11:41:07.
Задача выполняется 0 мин 0 сек.
[[412] Поставлено в очередь 2020-02-18 11:41:07 с приоритетом 250
SYNC FROM SOURCE
NC DC=root,DC=pyatilistnik,DC=org
DSA Default-First-Site-Name\DC01
GUID объекта DSA 92925497-671b-44f0-8d13-420fc4d5bbd1
адр. транспорта DSA 92925497-671b-44f0-8d13-420fc4d5bbd1._msdcs.root.pyatilistnik.org
ASYNCHRONOUS_OPERATION WRITEABLE NOTIFICATION

Принудительная проверка топологии репликации

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

По умолчанию каждый контроллер домена выполняет этот пересчет каждые 15 минут и если есть проблемы вы можете видеть в логах Windows событие с кодом 1311.

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

так же можно запустить для определенного сайта для этого используется параметр site:

Repadmin: выполнение команды /kcc контроллере домена dc01.root.pyatilistnik.org с полным доступом
Root
Текущий Параметры сайта: (none)
Проверка согласованности на dc01.root.pyatilistnik.org выполнена успешно.

Repadmin: выполнение команды /kcc контроллере домена dc03.child.root.pyatilistnik.org с полным доступом
Default-First-Site-Name
Текущий Параметры сайта: (none)
Проверка согласованности на dc03.child.root.pyatilistnik.org выполнена успешно.

Repadmin: выполнение команды /kcc контроллере домена dc02.root.pyatilistnik.org с полным доступом
Root
Текущий Параметры сайта: (none)
Проверка согласованности на dc02.root.pyatilistnik.org выполнена успешно.

Repadmin: выполнение команды /kcc контроллере домена dc04.child.root.pyatilistnik.org с полным доступом
Default-First-Site-Name
Текущий Параметры сайта: (none)
Проверка согласованности на dc04.child.root.pyatilistnik.org выполнена успешно.

У /kcc есть дополнительный ключ /async — Указывает, что репликация является асинхронной. То есть Repadmin запускает событие репликации, но не ожидает немедленного ответа от контроллера домена назначения. Используйте этот параметр для запуска KCC, если вы не хотите ждать окончания работы KCC. Repadmin /kcc обычно запускается без параметра /async.

Как принудительно запустить репликацию Active Directory

Бывают ситуации, когда вам необходимо произвести форсированное обновление на контроллере домена. Для этого есть специальный ключ /syncall. Для того, чтобы выполнить синхронизацию нужного контроллера домена со всеми его партнерами по репликации, вам необходимо на нем выполнить команду:

На выходе вы получите статус репликации и количество ошибок, выглядит это вот так:

СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Сейчас выполняется следующая репликация:
От: 007a5ee4-a454-4029-bc9b-0c4a8b4efbd1._msdcs.root.pyatilistnik.org
Кому: 5fc9cc16-b994-426d-81c8-c9ff27f29976._msdcs.root.pyatilistnik.org
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Следующая репликация успешно завершена:
От: 007a5ee4-a454-4029-bc9b-0c4a8b4efbd1._msdcs.root.pyatilistnik.org
Кому: 5fc9cc16-b994-426d-81c8-c9ff27f29976._msdcs.root.pyatilistnik.org
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Сейчас выполняется следующая репликация:
От: a76336ac-2fe6-4dc8-b9d3-23a5b0d22b77._msdcs.root.pyatilistnik.org
Кому: 92925497-671b-44f0-8d13-420fc4d5bbd1._msdcs.root.pyatilistnik.org
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Следующая репликация успешно завершена:
От: a76336ac-2fe6-4dc8-b9d3-23a5b0d22b77._msdcs.root.pyatilistnik.org
Кому: 92925497-671b-44f0-8d13-420fc4d5bbd1._msdcs.root.pyatilistnik.org
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Сейчас выполняется следующая репликация:
От: 5fc9cc16-b994-426d-81c8-c9ff27f29976._msdcs.root.pyatilistnik.org
Кому: 92925497-671b-44f0-8d13-420fc4d5bbd1._msdcs.root.pyatilistnik.org
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Следующая репликация успешно завершена:
От: 5fc9cc16-b994-426d-81c8-c9ff27f29976._msdcs.root.pyatilistnik.org
Кому: 92925497-671b-44f0-8d13-420fc4d5bbd1._msdcs.root.pyatilistnik.org
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Завершена операция SyncAll.
Команда SyncAll завершена без ошибок.

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

Функция SyncAll сообщает о следующих ошибках:
Ошибка обращения к серверу 5fc9cc16-b994-426d-81c8-c9ff27f29976._msdcs.root.pyatilistnik.org (сетевая ошибка): 17
ba):
Сервер RPC недоступен.

так же repadmin /syncall имеет ряд флагов:

/a — прерывается, если какой-либо сервер недоступен.
/A — Синхронизирует все контексты именования, хранящиеся на домашнем сервере
/d — Идентифицирует серверы по отличительным именам в сообщениях.

/e — Синхронизирует контроллеры домена на всех сайтах предприятия. По умолчанию эта команда не синхронизирует контроллеры домена на других сайтах.
/h — Отображение справки.
/i — запускает бесконечный цикл синхронизации
/I — Запускает команду repadmin /showrepl на каждой паре серверов вместо синхронизации.
/j — Синхронизирует только соседние серверы.
/p — Пауза после каждого сообщения, чтобы пользователь мог прервать выполнение команды.
/P — Выдвигает изменения наружу от указанного контроллера домена.
/q — Работает в тихом режиме, который подавляет сообщения обратного вызова.
/Q — Работает в очень тихом режиме, который сообщает только о фатальных ошибках.

/s — не синхронизируется.
/S — Пропускает начальную проверку ответа сервера.

Экспорт результатов в текстовый файл

Иногда Repadmin отображает много информации. Вы можете экспортировать любой из приведенных выше примеров в текстовый файл, это немного упрощает последующее рассмотрение или сохранение для документации. Для этого используется инструкция «> путь до файла». Вот пример команд:

@echo off
chcp 855
repadmin /replsummary > c:\temp\replsummary.log
repadmin /syncall > c:\temp\syncall.txt
repadmin /Queue > c:\temp\Queue.txt
repadmin /istg * /verbose > c:\temp\istg.txt
repadmin /bridgeheads * /verbose > c:\temp\bridgeheads.txt

chcp 855 используется, чтобы у вас не было кракозябр вместо русского текста.

Как посмотреть количество изменений атрибутов

Хотя команда repadmin /showobjmeta отображает количество изменений атрибутов объекта и контроллер домена, которые вносили эти изменения, команда repadmin /showattr отображает фактические значения для объекта. Команда repadmin /showattr также может отображать значения для объектов, которые возвращаются запросом LDAP-протокола.

На объект может ссылаться его distinguished name или глобальный уникальный идентификатор объекта (GUID).

По умолчанию repadmin /showattr использует порт 389 LDAP для запроса доступных для записи разделов каталога. Однако repadmin /showattr может дополнительно использовать порт 3268 LDAP для запроса разделов, доступных только для чтения, на сервере глобального каталога. (Советую освежить в памяти какие порты использует Active Directory).

Основные параметры команды:

<DSA_LIST> — Задает имя хоста контроллера домена или списка контроллеров домена, разделенных в списке одним пробелом.
<OBJ_LIST> — Определяет различающееся имя или GUID объекта для объекта, атрибуты которого вы хотите перечислить. Когда вы выполняете запрос LDAP из командной строки, этот параметр формирует базовый путь различаемого имени для поиска. Заключите в кавычки отличительные имена, содержащие пробелы.
/atts — Возвращает значения только для указанных атрибутов. Вы можете отображать значения для нескольких атрибутов, разделяя их запятыми.
/allvalues — Отображает все значения атрибутов. По умолчанию этот параметр отображает только 20 значений атрибута для атрибута.
/gc — Указывает использование TCP-порта 3268 для запроса разделов глобального каталога только для чтения.
/long — Отображает одну строку для каждого значения атрибута.
/dumpallblob — Отображает все двоичные значения атрибута. Эта команда похожа на /allvalues, но отображает двоичные значения атрибутов.

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

repadmin /showattr dc01 «dc=root,dc=pyatilistnik,dc=org»

В следующем примере запрашиваются все контроллеры домена, имена компьютеров которых начинаются с dc, и показывает значение для определенного атрибута msDS-Behavior-Version, который обозначает функциональный уровень домена.

Repadmin /showattr dc* «dc=root,dc=pyatilistnik,dc=org» /atts:msDS-Behavior-Version

В следующем примере запрашивается один контроллер домена с именем dc01 и возвращается версия операционной системы и версия пакета обновления для всех компьютеров с целевым идентификатором основной группы = 516.

repadmin /showattr dc01 ncobj:domain: /filter:»(&(objectCategory=computer)(primaryGroupID=516))» /subtree /atts:
operatingSystem,operatingSystemVersion,operatingSystemServicePack

Как посмотреть время последней резервной копирования Active Directory

Как посмотреть RPC-вызовы, на которые еще не ответили

Как посмотреть топологию репликации

repadmin /bridgeheads * /verbose

Если есть проблемы с репликацией, то можете получать ошибку «The remote system is not available. For information about network troubleshooting, see Windows Help.»

Как сгенерировать топологию сайтов Active Directory

repadmin /istg * /verbose

Если есть проблемы с репликацией, то тут вы можете видеть ошибки: LDAP error 81 (Server Down) Win32 Err 58.

На этом у меня все, мы с вами разобрали очень полезную утилиту, которая позволит вам быть в курсе статуса репликации вашей Active Directory. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Репликация Active Directory. Часть 2

Продолжение разговора об репликации Active Directory. Первая часть доступна по ссылке.

Репликация Active Directory: Разговор на «Ты» (Продолжение)

Продолжаем разговор о репликации, начатый ссылке. Усложним задачу и внесем территориальное разделение сегментов вашей сети.

Межсайтовая репликация

И вот ваша фирма обзавелась несколькими филиалами, каждый из которых имеет свое территориальное местоположение. Естественно эти офисы выделены в отдельные подсети, которые соединены WAN каналами и произведена настройка маршрутизации. Как быть в такой ситуации? Можно оставить все контроллеры в одном офисе и тогда клиентам не останется ничего кроме общения с контроллерами доменов по WAN-каналам. Конечно, данный трафик можно шифровать, используя IPsec, но как быть в случае падения WAN канала. Ведь при недоступности контроллера домена клиенты не смогут войти в сеть и начать работу в домене.

Примечание: Надо заметить, что трафик Kerberos шифровать не обязательно, т.к. он уже имеет защиту от man-in-the-middle, что касается RPC то он более уязвим, но только в ситуации «по умолчанию», когда разрешено незащищенное RPC взаимодействие. Однако можно включить жесткое требование в групповой политике домена для шифрования и подписывания RPC и SMB.

Вывод напрашивается сам собой – установить в каждом филиале по контроллеру домена.

Просто раскидав по офисам контроллеры домена проблемы не решить. Необходимо обеспечить выполнения двух задач:

1. Каждый клиент при аутентификации должен обращаться к ближайшему контроллеру домена для получения билетов Kerberos. При этом и групповые политики также должны применяться с ближайшего контроллера (эти взаимодействия называются трафиком регистрации компьютеров и пользователей).

2. Репликация изменений внутри сайта (например одного офиса) осуществляется согласно схеме уведомлений с расписанием, описанной в первой части статьи. Репликация же между контроллерами, находящимися в разных сайтах (например в разных филиалах) происходит только по расписанию. Хотя при желании систему уведомлений для межсайтовой репликации можно включить, воспользовавшись repadmin-ом.

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

Создание сайта производится через оснастку «Active Direcory Сайты и службы». Если до этого сайты не конфигурировались, то все контроллеры домена будут принадлежать к сайту с именем «Default-First-Site-Namе».

При создании нового сайта, вы обязаны указать какой «SiteLink» будет использоваться для соединения. SiteLink или Связь сайтов это логическая цепочка связывающая два и более сайтов , если будет проще для восприятия можно ассоциировать ее с физическим каналом, соединяющим сайты. Для чего же нужна эта цепочка – ее задача управлять межсайтовой репликацией. Одна Связь сайтов уже создана по-умолчанию, в ней задано использование IP протокола для репликации с запуском ее раз в 180 минут.

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

Рис. 13 Схема сайтов и их связей.

Действия администратора в такой ситуации довольно просты, первым делом он создает сами сайты, эта процедура предельно проста и требует ввода только имени сайта и используемой связи. Настоятельно рекомендуется при этом сразу назначить на вновь созданные сайты соответствующие им IP-подсети. Первоначально для связи сайтов можно использовать созданную автоматически при инсталляции службы каталогов связь «DEFAULTIPSITELINK».

После этого администратор создает две «Связи сайтов», одну для стыковки сайтов Москва и Ростов, вторую для Ростов-Сальск. После создания необходимо сконфигурировать расписание открытия окна репликации, доступ к настройкам которого легко получить в свойствах нужной связи.

Получив нужную структуру сайтов, следует задать какие контроллеры в каком сайте должны обсуживать клиентов, сделать это можно обычным перетаскиванием объектов контроллеров домена между папками «Servers» в разных сайтах. Однако более правильным и рекомендуемым компанией Microsoft способом распределения между сайтами считается инсталляция контроллера домена с таким IP-адресом, который попадает в заданную вами подсеть, принадлежащую нужному вам сайту. Внимательные администраторы заметили, что при создании Связей кроме расписания задается их стоимость. Это неспроста, возможны ситуации когда сайты связанны сразу с несколькими другими и возникает ситуация когда у репликационного трафика есть несколько возможных путей. Именно тогда и начинают учитываться стоимости, чем меньше стоимость связи, тем приоритетней путь для репликации.

Правил несколько:

1. Межсайтовая репликация идет по самому «дешевому» маршруту.

2. Если между двумя сайтами есть несколько маршрутов и они одинаковы по стоимости, то будет выбран тот маршрут, который использует меньше «прыжков» или «SiteLink-ов»

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

Рис. 14 Схема сайтов и их связей со стоимостью.

Зная это можно точно сказать, что при репликации с контроллеров домена Москвы в Сальск информация будет реплицирована используя Связь 3, так как при одинаковой цене (100=50+50) этот вариант предполагает единственный прыжок.

Пока мы не ответили на один очень важный вопрос, как клиент Москвы поймет, что ему нужно обращаться в первую очередь к контроллерам B1, B2 или B3. И только если они недоступны, пытаться аутентифицироваться на каком-либо другом контроллере. В той же оснастке в папке «Subnets» администратором создаются объекты подсеть, которые в последствии закрепляются за нужным сайтом . Т.е если вы создали сайт “Ростов-на-Дону” и закрепили за ним подсеть “192.168.5.0/24”, все клиенты имеющие IP-адрес в данной подсети будут считать себя членами данного сайта. За одним сайтом может быть закреплено сразу несколько подсетей. Более того, если получиться так, что у сайта «А» подсеть будет скажем 192.168.0.0/16, а у сайта «Б» подсеть будет 192.168.1.0/24, то для рабочей станции или сервера скажем с IP адресом 192.168.1.15 будет выбран сайт «Б». Отсюда вывод, что выбор сайта при совпадении назначенных подсетей с разными масками производиться в пользу сайта с наиболее «узкой маской» подсети. То есть с маской с большим числом единиц в двоичной нотации.

Чтобы убедиться в том, что клиенты начали обращаться к «правильному» контроллеру домена, можно использовать команду set logonserver, которая вернет вам, имя контроллера, аутентифицировавшего клиента: LOGONSERVER=\B1, однако в Windows 2000 и XP эта переменная далеко не всегда оперативно обновляется. Поэтому можно воспользоваться еще одной командой:

nltest /DSGETDC:<имя домена> /KDC /GC.

В случае если контроллер, который был выбран рабочей станцией в качестве Logon Server-а окажется недоступен, примерно через 15 минут это будет обнаружено и будет выбран другой доступный контроллер домена. Этот процесс называется DC Locator и имеет первостепенное значение в части отказоустойчивости работы AD. Так же этот процесс можно запустить принудительно командой nltest /DSGETDC:<имя домена> /force.

В межсайтовой репликации есть одна особенность, связанная с наличием Сервера Платцдарма (Bridgehead Server) в задачу которого входит обеспечение межсайтовой репликации, т.е. если контроллер домена B3 создаст новый обьект в базе то он должен его реплицировать на сервер плацдарм сайта Москва, а тот в свою очередь реплицирует на плацдарм Ростовского сайта, где последующее распространение будет идти по стандартной внутрисайтовой схеме.

Bridgehead сервера для каждого сайта выбираются автоматически с помощью службы KCC, но при желании администратор может самостоятельно задать один или более Bridgehead-ов для сайта. Данная манипуляция производится в свойствах нужного сервера оснастки «Active Direcory Сайты и службы» где указывается для каких протоколов данный сервер будет плацдармом. Поскольку в большинстве ситуаций это протокол IP, то его и нужно добавить на выбранном сервере.

Рис. 15 Ручное указание Bridgehead сервера.

При ручном назначении Серверов Плацдармов следует учитывать, что в случае недоступности выбранных серверов межсайтовая репликация работать перестанет, плюсом же выбора через KCC является автоматическое переназначение данной задачи другому контроллеру в случае недоступности ранее выбранного Bridgehead-сервера .

Посмотреть, кто является текущим сервером плацдармом можно через: repadmin /bridgeheads

Важно отметить, что при ручном указании сервера Bridgehead для сайта он будет один выполнять эту функцию. Если же сервер Bridgehead не задан и выбор делает KCC автоматически то для Windows Server 2003 KCC осуществляет балансировку количества линков репликации между несколькими контроллерами в сайте. Кроме того, такую балансировку можно выполнить и в ручном режиме утилитой adlb.exe.

Поговорим о межсайтовых мостах.

Посмотрим на рисунок 16. На нем изображена схема сети, состоящей из 3-х сайтов, каждый из которых находится в своей подсети и своем городе. Связи сайтов настроены так, что Белград имеет SiteLink соединяющий его с Москвой и SiteLink, соединяющий его с Токио. Москва и Токио между собой напрямую не связаны.

Рис. 16. Идеология Site Link Bridge

А теперь давайте попробуем ответить на вопрос: Каким путем будут реплицироваться изменения с контроллера домена А1 на контроллер домена С1, Те, кто внимательно читали статью скажут, что контроллер домена А1 передаст изменения серверу плацдарму в своем сайте. Тот в свою очередь согласно расписанию «Связи» передаст их на сервер плацдарм сайта Белград. И только потом плацдарм Белграда опять же по расписанию передаст их на Токийский плацдарм. И уже с него они будут реплицированы на контроллер С1. Те, кто так скажут, будут правы.

Что же произойдет, если Белградские контроллеры станут недоступны или просто этот сегмент сети окажется отключен? Остановится ли репликация между сайтами Москва и Токио?

По умолчанию Active Directory пытается решить данную проблему. Она (AD DS) видит, что Москва связана с Белградом, Белград с Токио, а сайт Белграда пропал с радаров и репликация остановилась. Видит и допускает, что мы имеем полностью маршрутизируемую сеть. А если сеть полностью маршрутизируемая, то почему не передать напрямую? (с контроллера А1 на С1 сразу)

Такая транзитивность называется «Site Link Bridging». Служба KCC начинает создавать репликационные связи между контроллерами из несвязанных SiteLink-ми сайтов и реплицировать данные напрямую. Естественно, если вы не имеете полностью маршрутизируемой сети, то такая дефолтная логика вас не устроит. Поэтому вам может потребоваться отключить автоматический «Site Link Bridging». Делается это довольно просто и уже после отключения логика репликации будет идти по классической схеме. А при падении канала с центральным сайтом, в моем случае Белград, репликация между сайтами попросту остановится.

Рис. 17 Включение и отключение функции автоматического “Site Link Bridging” (опция Установить мост для всех связей сайтов )

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

В сети, где сеть не полностью маршрутизируемая автоматическое создание мостов (Site Link Bridging) следует отключать. Но как быть, если сеть довольно крупная и в ней присутствуют как группы сегментов с полной маршрутизацией, так и с частичной. Отключение Site Link Bridging лишит нас резервного механизма репликации для всех сегментов сети.

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

Рис. 18 Создание моста между сайтами.

Создавай мост, вы можете быть уверены, что контроллеры в сайтах сайт-линки которых соединены мостом в штатном режиме будет реплицировать изменения согласно топологии межсайтовой репликации (используя контроллеры доменов в других сайтах как посредников). И только если передать данные по этой логике не получится (обратите внимание, что для передачи данных через мост необходимо несколько сбойных попыток репликации) будут созданы прямые репликационные связи и начнут передаваться данные.

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

По-умолчанию при репликации контроллеры домена устанавливают соденение по 135/tcp, 135/udp портам (так называемый RPC endpoint mapper), после чего согласовывают порты, которые будут использоваться при репликации данных. Тут то и появляется проблема, диапазон портов, которые могут быть задействованы очень велик 1024-65535/tcp. Открытие этих портов полностью нивелирует файрвол, превращая его в головку швейцарского сыра.

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

Для жесткой привязки порта репликации Active Directory используется ключ:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters

Registry value: TCP/IP Port

Value type: REG_DWORD

Еще один очень полезный ключ для фиксации RPC-трафика регистрации пользователей и компьютеров в процессе NetLogon-а и DC Locator-а: (трафика от клиентов к контроллерам домена при установлении SChannel и при поиске «родных» сайтов)

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters

Registry value: DCTcpipPort

Value type: REG_DWORD

Вот здесь не стоит забывать, что групповая политика важная часть доменной структуры Active Directory, а каждый контроллер домена хранит свою копию политик. Групповая политика состоит из двух частей связывающего объекта GPO (в нем название политики, ее идентификатор («GUID»), дата создания, дата изменения, версия) который хранится в Active Directory и реплицируется ее средствами и собственно настроек политики, а так же ее шаблонов (параметры политики, передаваемые клиентам как двоичные файлы и файлы adm, admx, adml) находящегося в папке SYSVOL.

Папка SYSVOL не реплицируется средствами AD, ее синхронизация обеспечивается технологией NtFRS или DFS-R.

Расписание межсайтововй репликации SYSVOL соответствует расписанию AD, но не допускает межсайтовой нотификации. Внутрисайтовая репликация тоже осуществляется по расписанию NTFRS/DFS-R задаваемые в реестре. Репликация является мульти-мастерной, т.е источником изменений может быть любой контроллер. Если изменения произошли на нескольких контроллерах, приоритет будет иметь изменение сделанное последним. Более подробно мы не будем рассматривать репликацию NTFRS или DFS-R в этой статье, т.к. это совершенно другая тема.

Когда вы добавляете в ваш домен Active Directory, построенный на базе Windows Server 2003 новый контроллер Windows Server 2008, он по прежнему использует для репликации групповой политики «File Replication service» (NtFRS).

Для фиксации порта NtFRS используется ключ:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNtFrsParameters

Registry Value: RPC TCP/IP Port Assignment

Value type: REG_DWORD

При создании нового домена Active Directory на базе Windows Server 2008 (режим работы домена Windows Server 2008 и новее), для репликации « групповой политики» используется «Distributed File System («DFS») Replication». Если вы обновили ваш домен с Windows Server 2003 до уровня 2008, то «DFS Replication» этот функционал нужно активировать дополнительно утилитой DFSRMIG.exe.

Distributed File System (DFS) Replication это сервис, реплицирующий папку SYSVOL на всех контроллерах домена, работающего в функциональном режиме Windows Server 2008. Впервые DFS Replication появилась в Windows Server 2003 R2, но для репликации SYSVOL ее можно использовать только в Windows Server 2008.

Какие преимущества имеет «DFS Replication»?

• В Windows Server 2003 при изменении файла в SYSVOL служба «FRS» реплицировала весь файл целиком. При использовании «DFS Replication» измененный файл больше 64 KB реплицируется частично, т.е только блоки размером 64KB с изменениями.

При передачи данных DFS-R эффективно сжимает их алгоритмом схожим с ZIP.

• Масштабируемое решение. Размер папки SYSVOL может достигать нескольких терабайт.

• Новая графическая оснастка «Управление DFS» для более удобного администрирования.

• Улучшенная поддержка Read Only Domain Controllers.

• Наличие встроенных средств мониторинга и утилиты для развертывания.

• Технология, требующая минимального контроля и администрирования со стороны системного администратора.

Тем, кого заинтересовал процесс перехода, необходимо познакомиться с утилитой dfsrmig, которая позволяет произвести процесс миграции с FRS на DFS. Основными ключами для работы будут /GetMigrationState и /SetGlobalState. Подробней о процессе миграции можно прочитать в статье ссылке .

Если вы идете в ногу с прогресом и ваша папка SYSVOL реплицируется средствами DFS-R, вам так же ничто не мешает статически закрепить порты, которые будут использоваться при DFS-репликации.

Делается это следующим образом:

1. Вводим команду «dfsrdiag dumpmachinecfg». Если команда возвращает 0, значит у вас используется динамическое назначение портов для DFS-репликации.

2. Указываем статический порт «dfsrdiag StaticRPC /port:nnnnn /Member:dc.itband.ru».

Информация о порте репликации будет храниться в XML-файле по следующему пути %SYSTEMDRIVE%System Volume InformationDFSRConfigDfsrMachineConfig.XML.

Вдобавок к теме используемых портов, остается добавить ссылку на статью базы знаний Microsoft “Службы и сетевые порты в серверных системах Microsoft Windows” (http://support.microsoft.com/kb/832017). В ней приведен список портов, которые могу понадобиться для работы различных сервисов Microsoft Windows и в частности Active Directory.

Утилита repadmin

Для управления репликацией существует две утилиты repadmin (консольная) и replmon (графическая). С выходом Windows Server 2008 продолжение развития получила только утилита repadmin, ее функционала вполне достаточно, чтобы дополнить оснастку «Active Directory – сайты и службы» и дать администраторам возможность гибко управлять репликацией.

Рассмотрим несколько примеров ее использования:

repadmin /syncall DC1 dc=itband,dc=ru
repadmin /syncall DC1 cn=configuration,dc=itband,dc=ru
repadmin /syncall DC1 cn=schema,cn=configuration,dc=itband,dc=ru

Три приведенных варианта repadmin запускают репликацию различных разделов каталога контроллера DC1 с его репликационными партнерами в сайте Active Directory.

repadmin /replsummary

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

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

repadmin /showchanges dc1 7b2b9e16-895f-414d-a7b0-5e48f502935c dc=lab,dc=itband,dc=ru

В данном примере указан контроллер с которым нужно произвести сравнение (DC1) и invocationID (уникальный идентификатор экземпляра базы Active Directory ) контроллера с которого производится запуск. InvocationID в свою очередь можно узнать командой:

repadmin /showsig dc2

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

Рис. 16. Не реплицированное изменение.

Несмотря на предупреждение о том, что данные команды должны использоваться только под присмотром premier support microsoft некоторые из них стоит взять на вооружение.

repadmin /options DC1 +DISABLE_OUTBOUND_REPL +DISABLE_INBOUND_REPL

Эта команда отключает входящую и исходящую репликацию на контроллере DC1, очень удобное средство, в случае если необходимо срочно остановить распространение изменений. Обратно включение производится аналогично только перед параметром необходимо установить минус. (-DISABLE_INBOUND_REPL)

Заключение

Информация полученная после вдумчивого прочтения двух частей данной статьи должна сформировать понимание у специалиста идеологии репликации и построения многосайтовых систем. Но все же очень много осталось за кадром. А именно: задачи и сценарии SMTP-репликации, объемы трафика репликации для разных типов объектов, влияние на репликацию таких вещей как захоронение и восстановление объектов, ну и конечно USN rollback. И пусть не в каждой организации вам понадобится знание вышеперечисленного, но для реализации крупных решений эти нюансы в голове должны быть проработаны.

Илья Рудь

Константин Леонтьев

Оринигал статьи взят с ресурса itband.ru

О некоторых нюансах настройки межсайтовой репликации AD или «Не все статьи от Microsoft одинаково полезны»

Одним прекрасным весенним утром, когда свежая почта уже была прочитана, а чашка с чаем еще не закончилась, я наткнулся на статью в блоге «Ask the Directory Services Team» под названием Configuring Change Notification on a MANUALLY created Replication partner. В ней сотрудник Microsoft Джонатан Стивенс описывает способ научить ваши контроллеры домена побыстрее реплицировать изменения в AD между сайтами (в определенных условиях).
«Клево! — подумал я тогда — надо попробовать.»

В сертификационных курсах по AD и в многочисленных статьях нам сообщают, что существует два вида репликации: внутрисайтовая (intrasite) и межсайтовая (intersite).

N.B. Надеюсь все понимают что мы говорим о репликации каталога AD, которая не имеет никакого отношения к репликации папки Sysvol. И еще, если вы никогда не слышали об USN, KCC, Up-to-dateness Vector и прочих ~~гадостях~~ терминах, то дальше можете не читать, будет непонятно.

Внутрисайтовая репликация происходит «почти мгновенно» (на самом деле 5 секунд), межсайтовая — «по расписанию», которое обычно задается в свойствах SiteLink. Недостаток расписания в том, что минимальный период межсайтовой репликации составляет 15 минут (четыре раза в час) и не может быть уменьшен стандартными средствами.

«А нестандартными может?» — сразу спросите вы. «Может» — отвечает нам Microsoft в статье Advanced Replication Management, опубликованной на technet.microsoft.com. Оказывается, что изменение определенного бита в атрибуте Options соответствующего SiteLink позволяет включить режим уведомления о появившихся изменениях (Notification) при межсайтовой репликации AD. А режим уведомления и определяет разницу между двумя видами репликации. Замечательно, у нас будет «мгновенная» репликация для всех контроллеров!

~~А вот и нифига!~~ К сожалению, в описанном на Technet способе есть одно существенное ограничение: уведомления об изменениях начинают работать только если AD DS connection был создан автоматически, посредством KCC. Такие AD DS connections имеют имя &ltautomatically generated&gt, это если вы вдруг не знали :). Если же в вашей организации KCC по какой-то причине не доверяют и создают соединения вручную, то увы и ах, в той статье нам предлагали довольствоваться 15-минутным интервалом репликации.

Теперь вернемся к статье Джонатана Стивенса. В ней он описывает причину такого ограничения и способ его обойти. Дублировать информацию здесь не буду, если интересно, то ссылку на статью я привел в самом начале.

Итак, у нас есть инструкция, ~~шаловливые ручки~~ энтузиазм и немного свободного времени. Давайте пробовать!

Собираем полигон из двух виртуальных контроллеров домена под управлением Windows Server 2012 Datacenter Edition.

Уровень леса и домена Windows Server 2012. Оба контроллера являются серверами DNS и серверами глобального каталога, находятся в одном сетевом сегменте.

Разносим контроллеры по разным сайтам:

После этого вручную создаем дублирующие AD DS Connections, подталкиваем репликацию и затем удаляем автоматически сгенерированные соединения.

Note! Настоятельно рекомендую заменять соединения в указанном порядке, чтобы в любой момент времени между контроллерами существовала как минимум одна пара AD DS Connections, иначе может порушиться репликация, во всяком случае на некоторое время. Для надежности после каждого изменения вручную подталкивайте репликацию.

На контроллере ReplTest-DC2 в окне PowerShell запускаем скрипт:

while ($true) {repadmin /showutdvec ReplTest-DC2 "DC=Repltest,DC=local" | ?{$_ -match "ReplTest-DC1"};sleep 1}

Он позволит нам в реальном времени (раз в секунду) отслеживать изменение Up-To-Dateness vector контроллера ReplTest-DC2, выделяя из него строку, относящуюся к партнеру репликации с именем ReplTest-DC1.

Обратите внимание, в выделенной строке USN изменился с 12575 на 12605. Это произошло после того, как на ReplTest-DC1 был создан тестовый юзер и репликация была инициирована вручную.

Итак, мы убедились что репликация работает. Переходим непосредственно к проверке статьи Джонатана.

Устанавливаем четвертый бит атрибута Options в единицу для вручную созданного AD DS Connection (для верности я сделал это для обоих соединений: от ReplTest-DC1 и от ReplTest-DC2).

Не забываем подтолкнуть репликацию.

После этого редактируем произвольный атрибут произвольного объекта на ReplTest-DC1. Я, например, поменял поле Description у недавно созданного юзера.

Смотрим на состояние репликации на ReplTest-DC2:

Ноль реакции! USN не меняется!

Ждем пять секунд… ничего не меняется, ждем пять минут… опять не меняется!

Пытаемся проделать зеркальную операцию: вносим изменения в AD на ReplTest-DC2 и отлеживаем изменения на ReplTest-DC1. Тот же результат.

Несколько часов разнообразных тестов не изменили картины.

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

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

«Приведенный в статье Джонатана Стивенса метод включения уведомлений для созданных вручную AD DS Connections не работает»

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

Если у уважаемых коллег есть замечания к проведенному тесту или их результаты отличаются от моих, то прошу указать в комментариях ~~кто редиска~~ ошибся ли я и если да, то в каком месте.

Надеюсь что сообща мы докопаемся до истины.

Репликация Active Directory. Часть 1

Еще в 2014 году я начал писать статью о репликации Active Directory, так как тема важная и требует обязательного понимания для работы со службами каталогов. Увы, тогда работа не была завершена. Сегодня же увидел две статьи по данной тематике на ресурсе itband.ru и, с разрешения автора, делаю репост первой статьи.

Репликация Active Directory: Разговор на «Ты»

Одна из главных рекомендаций Microsoft касательно Active Directory Domain Services (ADDS) говорит о необходимости развертывания в производственной среде минимум двух контроллеров домена. Реальная же жизнь показывает, что в средних и крупных компаниях количество контроллеров может достигать нескольких десятков и даже сотен. Когда системный администратор начинает работать в крупной сети на базе ADDS одной из самых важных забот становится репликация Active Directory.

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

Впервые появившись в Windows Server 2000 технология Active Directory (это прежде всего транзакционная база данных содержащая информацию об объектах вашей сети и глубоко интегрированная с системой безопасности Windows) более чем за 9 лет претерпела некоторые изменения, но даже в Windows Server 2008 R2 работает на хорошо зарекомендовавшем себя движке Extensible Storage Engine ( ESE ). Если верить расчетам масштабируемости, данного решения должно хватить даже сетям с несколькими миллионами объектов, а вырасти база, может до 16 террабайт. Сердцем Active Directory является файл NTDS.DIT в котором, собственно говоря, вся информация и хранится. При добавлении второго и последующих контроллеров домена происходит создание копии данного файла, и размещение ее на введенном в строй новом контроллере. Т.е можно сделать четкий вывод: каждый контроллер домена хранит свою версию файла NTDS.DIT.

Важно понимать, что при открытии оснастки для работы с Active Directory, а это может быть Active Directory Пользователи и Компьютеры или как вариант Active Directory Сайты и Сервисы, вы всегда подключаетесь к конкретному контроллеру домена и при желании можете выбрать с каким контроллером работать – это означает, что выработаете с конкретной версией базы данных, которая в данный момент может отличаться от других копий. Естественно создавая учетную запись либо меняя конфигурацию, изменения вносятся только в один файл NTDS.DIT, который находится на контроллере, куда подключена оснастка (или любой другой инструмент управления). После внесения изменений критически важно оповестить другие контроллеры об изменениях и новых данных и как можно скорее произвести синхронизацию. В Active Directory этот процесс синхронизации называется репликацией и в дальнейшем я буду использовать именно этот термин. Особенно важно помнить эти факты, когда вы занимаетесь решением проблем с репликацией Active Directory и вносите изменения в контекст конфигурации AD. Это происходит тоже на конкретном контроллере и с конкретным файлом NTDS.DIT.

Физически NTDS.DIT это просто один файл, но логически он состоит из нескольких разделов (иногда их называют контекстами именования или контекстами репликации), каждый из которых содержит определенную информацию и реплицируется по-своему.

Раздел «Schema» – хранит в себе схему ActiveDirectory, которая описывает, какие объекты могут быть созданы, и что они из себя будут представлять. Меняется реже всего, как правило, при переходе контроллеров на новую операционную систему либо при установке в организации почтовой системы Exchange. Процесс изменения базы данных в контексте схемы чаще всего называют расширением схемы и это не случайно, т.к. отменить эти изменения (например, удалить созданные в этом контексте объекты) невозможно. Репликация раздела осуществляется на все контроллеры домена в лесу Active Directory. Единственный раздел, чья репликация не является мультимастерной. Репликация раздела «Schema» всегда односторонняя и выполняется от контроллера домена, владеющего ролью FSMO Хозяин Схемы, на все оставшиеся контроллеры домена. (Впоследствии оставшиеся контроллеры домена реплицируют информацию своим репликационным партнерам, но источником обновления в этой цепочке репликации всегда будет Хозяин схемы)

Рис. 1 Разделы базы Active Directory

Раздел «Configuration» – содержит информацию о конфигурации Active Directory, в частности описывает, какие и сколько доменов создано, как они между собой связанны, сколько существует сайтов, какие сервисы доступны в организации и просто системные настройки службы каталогов такие как квоты, политики LDAP-запросов, правила неточного поиска, разрешения имен объектов и т.п.. Раздел реплицируется между всеми контроллерами доменов в лесу и может быть изменен на любом контроллере домена. Изменения данного раздела связаны с конфигурированием и настройкой самой Active Directory.

Раздел «Domain» – или доменный. Все учетные записи пользователей, группы безопасности, организационные подразделения, объекты компьютеров и принтеров создаются и хранятся в данном разделе. Реплицируется раздел только между контролерами домена в том домене к которому принадлежит контроллер. Получается, что в организациях, имеющих несколько доменов, в каждом домене будет свой раздел «Domain».

Разделы «Application» – опциональные разделы. Зона репликации зависит от настройки. Как правило, создается два Application раздела, это ForestDNSZones и DomainDNSZones.

· ForestDNSZones – хранит SRV и CNAME записи для Леса AD и реплицируется на все контроллеры домена в лесу, являющиеся DNS серверами.

· DomainDNSZones – содержит DNS записи для зоны домена. Реплицируется на все контроллеры домена с установленным на них DNS сервером.

Посмотреть на каждый раздел каталога и данные в нем хранящиеся можно через утилиты ADSI Edit AdExplorer и LDP.exe. Утилиту (AdExplorer) можно скачать с сайта Microsoft, она входит в комплект утилит Sysinternals. А LDP.exe становится доступна после установки на контроллер домена Windows Support Tools. Следует отметить, что данный комплект не потерял своей актуальности и после выхода Windows Server 2008.

Рис. 2 Выбор раздела для подключения в утилите LDP.exe

Теперь важно уяснить следующее, когда клиент аутентифицируется на контроллере домена, и применяются групповые политики, образуется трафик (85 Кб на вход станции в домен (с Default Domain Policy) и 75Кб на вход пользователя (тоже с Default Domain Policy)). Более того репликация изменений между контроллерами доменов порождает свой репликационный трафик. Этим трафиком нужно управлять, представьте себе, что организация и естественно ваш домен Active Directory располагается в двух городах связанных WAN каналом и однажды все пользователи филиала в Ростове-на-Дону начнут обращаться к контроллеру, расположенному в центральном Московском офисе. А контроллеры домена начнут реплицировать информацию в любое время и по первому желанию. Минимум с чем Вам придется столкнуться это высокая утилизация WAN канала и медленный вход пользователей в домен.

Поэтому в Active Directory введено понятие Сайтов. Сайт это логическое объединение контроллеров домена и клиентов для управления служебным трафиком службы каталогов. Если ваш Лес Active Directory не распространяется за пределы одного сегмента локальной сети, следовательно, вы работаете с односайтовой структурой. Именно она является дефолтной и именно с неё мы начнем разговор.

При создании Active Directory и поднятии (имеется ввиду процедура dcpromo) первого контроллера домена формируется сайт по-умолчанию с именем «Default-First-Site-Namе». Если не создавать дополнительных сайтов и придерживаться односайтовой структуры, все новые контроллеры будут попадать в данных сайт. После появления второго и последующих контроллеров должны образоваться Репликационные связи (connection objects), указывающие на то какой контроллер и откуда должен реплицировать изменения. Посмотреть эти связи можно через оснастку «Active Directory Сайты и Службы».

На Рис.3 открыта оснастка «ActiveDirectoryСайты и Службы» и по имеющейся информации можно сказать, что в данном примере имеется единственный сайт по-умолчанию, в котором находится два контроллера домена Server1 и Server2. А так же, что Server1 имеет партнера по репликации Server2 и реплицирует с него изменения. Без наличия данных связей репликации между контроллерами работать не будет.

Нередки случаи когда системные администраторы, установив новый контроллер домена, не находят у него данных связей и начинают создавать их руками. Это распространенная ошибка. За создание связей, базируясь на определенной логике, отвечает служба KCC (Knowledge Consistency Checker). Созданию связей самостоятельно чревато возникновением ошибок и дальнейшей путаницей. Для тех же, кто не хочет ждать, пока KCC справится с задачей, существует способ ее поторопить.

Рис. 3 Свойства Репликационной связи.

Для этого необходимо использовать утилиту Repadmin с ключом kcc. Синтаксис будет выглядеть следующим образом:

repadmin /kcc server1.itband.ru (Вместо server1.itband.ru вы укажете FQDN вашего сервера)

Если нужно запустить генерацию связей на всех контроллерах домена в сайте, то команда Repadmin принимает вид:

repadmin /kccsite: «Default-First-Site-Name» (Если имя сайта было изменено «Default-First-Site-Name» заменяется реальны именем)

Можно так же запустить процесс генерации топологии на всех контроллерах леса командой repadmin /kcc *. Большинство опций команды repadmin поддерживают ключ /async, который дает задание контроллеру домена и при этом не ожидает его завершения.

Без административного вмешательства служба KCC стартует на каждом контроллере домена раз в 15 минут и в случае необходимости добавляет или удаляет лишние репликационные связи (учтите, что связи, созданные вручную, не управляются KCC). Логика создания связей в рамках одного сайта кажется довольно простой, каждый контроллер не реплицируется с каждым, служба KCC всегда пытается создать кольцо репликации, причем по мере добавления новых контроллеров кольцо будет расширяться. Расширение не бесконечно, при создании связей существует «правило трех прыжков». Это значит, что между двумя контроллерами домена при репликации не может быть больше трех посредников.

Рис. 4 Принцип создание связей репликации службой KCC

Как только число контроллеров достигнет 8 штук, правило «трех прыжков» приведет к тому, что служба KCC выполнит «ход конем» и добавит дополнительные прямые связи, тем самым сокращая расстояние между двумя любыми контроллерами до допустимого значения «максимум в три прыжка». Данная ситуация хорошо проиллюстрирована на рисунке 4. Создание связей между контроллерами расположенными в разных сайтах выполняется с учетом топологии сайтов, сайт-линков и мостов между сайт-линками. Подробнее о построении межсайтовой репликации читайте в разделе «межсайтовая репликация». Следует отметить, что кольцо при построении топологии репликации строиться независимо для каждого контекста репликации (раздела Active Directory) далее эти кольца накладываются друг на друга и выясняется, где можно вместо нескольких репликационных связей – обойтись одной.

Внутрисайтовая репликация начинается, когда в Active Directory происходит изменение, это может быть изменение атрибута или создание учетной записи. Контроллер домена, в базе которого произошли изменения, ожидает 15 секунд, а затем отправляет ближайшему партнеру репликации уведомление о том, что на нем произошло какое-то обновление. При наличии двух и более партнеров по репликации, последующие уведомления отправляются каждому партнеру с 3-секундной задержкой (Верно для уровня леса Windows 2003 и выше, для Windows 2000 первичная задержка составляет 300 секунд, а последующие 45 секунд). После получения уведомления об изменении партнер репликации проверяет возможность репликации и список обновлений и выполняет процесс репликации с тем контроллером, который прислал уведомление. Трех секундная задержка предотвращает чрезмерную загрузку из-за одновременных запросов обновлений от множества партнеров по репликации. Периоды нотификаций можно настроить командой repadmin /notifyopt.

Следует обратить особое внимание читателей, что процесс репликации ВСЕГДА происходит в режиме pull, т.е. «стягивания» изменений и новых объектов, но не в режиме push. Это связано с тем, что только контроллер хозяин файла NTDS.DIT имеет право в нем что-то изменять и отвечает за целостность своей БД. Из этого так же следует, что ВСЕ линки репликации которые, создаются в ручную или службой KCC имеют однонаправленную природу, т.е. логически обозначают входящий поток репликационной информации.

Некоторые изменения реплицируются без 15-секундной задержки. Такая репликация, называемая срочной (urgent replication). В события ее вызывающие входят блокировки учетных записей, изменение пароля учетной записи. В официальных документах присутствует путаница. По сути это не репликация вовсе и механизм передачи этих изменений в коре отличается от процесса репликации. Хотя в качестве транспорта используется тоже протокол RPC. Такая репликация выполняется не обычным механизмом репликации, а специальными вызовами RPC. По сути это запросы аналогичные изменению объектов через ADSI. В зависимости от режима работы леса список событий может меняться.

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

Рис. 5 Расписание репликации

Данное расписание является основным и обязательным способом репликации. Несмотря на то, что система уведомлений, описанная выше, в большинстве случаев обеспечивает синхронизацию до запуска этого расписания, она не гарантирует успех. Возможна ситуация когда контроллер домена будет занят online дефрагментацией базы, пересчетом связей службой KCC и просто проигнорирует необходимость обработать пришедшие к нему уведомления об изменениях на партнерах по репликации. В такой ситуации изменения будут прореплицированы в течении часа.

При возникновении трудностей с репликацией можно используя утилиту replmon вручную запустить процесс репликации не дожидаясь расписания:

repadmin /replicate server2.itband.ru server1. itband.ru dc=itband,dc=ru

С ключем /replicate необходимо задать куда (server2.itband.ru ) и с какого контроллера (server1.itband.ru ) должны реплицироваться данные, а также какой раздел каталога нужно реплицировать (dc=itband,dc=ru).

Запустить репликацию всех разделов Active Directory в рамках всего леса (в рамках существующей топологии) довольно легко, для это следует выполнить: Repadmin /syncall /AeS. Учтите, что в крупных сетях такой запуск репликации может вызвать серьезный поток трафика, который пойдет не только по скоростным каналам.

Алгоритм распространения изменений

Теперь необходимо разобраться, как после получения репликационного уведомления от партнера контроллер домена решит: Есть или нет изменения необходимые для репликации ? Если есть то, какие объекты или их отдельные атрибуты должны быть прореплицированы. Алгоритм выглядит следующим образом.

Любой контроллер домена ведет некий счетчик называемый «highestCommittedUSN», который увеличивается на единицу при любом атомарном изменении базы Active Directory. При этом у каждого контроллера домена этот счетчик свой и между контроллерами его значения не совпадают. Например, в 9 утра значение «highestCommittedUSN» у контроллера DC1 было равно 14879, а в 6 вечера 14896. Это значит, что за прошедшее время в базе этого контроллера произошло 17 изменений. Посмотреть значение «highestCommittedUSN» можно с помощью утилиты ldp просто подключившись к нужному контроллеру домена. При подключении выводиться состояние динамического системного объекта RootDSE, среди атрибутов которого как раз и присутствует «highestCommittedUSN».

Рис. 6 Просмотр значения «highestCommittedUSN» на контроллере домена.

После проведенной репликации каждый контроллер домена кэширует значения «highestCommittedUSN» своих репликационных партнеров. И когда в последствии контроллер домена DC1 получит уведомление от контроллера DC2 в нем будет информация о текущем «highestCommittedUSN» DC2. Контроллеру DC1 останется только сравнить текущий «highestCommittedUSN» с тем, который он закэшировал во время прошлой репликации. Если он вырос : значит в базе DC2 произошли изменения и необходимо произвести репликацию. Если остался прежним, то в ней нет необходимости.

Таблица, в которой хранится информация о «highestCommittedUSN» репликационных партнеров называется вектором обновления или «up-to-date vector». Посмотреть ее можно с помощью утилиты repadmin.

repadmin /showutdvec dc1 dc=lab,dc=itband,dc=ru

Default-First-Site-NameDC2 @ USN 16667 @ Time 2009-09-21 01:24:15

Default-First-Site-NameDC1 @ USN 20704 @ Time 2009-09-21 01:31:25

В данном примере результатом будет вывод значений «highestCommittedUSN» репликационных партнеров DC1 (а также актуальный USN его самого), при этом это будут значения, о которых DC1 знает, в действительности уже они могли вырасти по причине внесения изменения в базу на тех контроллерах. Следует помнить, что «highestCommittedUSN» увеличивается как после изменений внесенных в базу непосредственно на контроллере, так и после изменений прореплицированных с других контроллеров.

Рис. 7 Просмотр вектора обновлений на контроллере DC1.

Есть одно но, сам по себе «up-to-date vector» отвечает на вопрос «Были ли изменения?». Этого недостаточно, необходимо вычислить что изменилось. Давайте рассмотрим данный механизм на примере.

В нашей сети находится два синхронизированных контроллера домена (DC1и DC2 ). До изменений «highestCommittedUSN» у DC1 равен 20902, а у DC2 16940. На контроллере DC1 создается учетная запись пользователя Федя Рашпин. После создания учетной записи «highestCommittedUSN» на DC1 стал показывать 20909. Это говорит о том, что было произведено 7 изменений. Напоминаю, что считаются атомарные изменения, т.е создание учетной записи можно разложить на само создание плюс изменение ряда атрибутов, которые выполняет оснастка Active Directory Users and Computers.

Если подключиться через LDP.exe к нашему объекту пользователь, то можно увидеть два атрибута uSNCreated и uSNChanged.

Рис. 8 Просмотр атрибутов uSNCreated и uSNChanged для учетной записи.

uSNCreated будет говорить, какой «highestCommittedUSN» был в момент создания объекта на данном контроллере, а uSNChanged в момент последнего изменения. Получается, что первый показатель (uSNCreated) будет оставаться неизменным, а второй в свою очередь (uSNChanged) по мере обновлений объекта будет расти. Важно понимать, что uSNCreated и uSNChanged на каждом контроллере домена у объекта будут свои.

Посмотрим на пользователя Федя через утилиту repadmin. Для получения служебной информации, используемой при репликации задействуем ключ /showmeta.

repadmin /showmeta “CN=Федя Рашпин,OU=testou,DC=lab,DC=itband,DC=ru”

При этом нас интересует информация с каждого контроллера. Но начнем с DC1.

Рис. 9 Вывод метаданных о созданном пользователе на DC1.

Какую же информацию нам дает repadmin (Рис. 9). Данный список не что иное, как объект пользователя, разложенный по атрибутам.

По каждому атрибуту можно увидеть:

· Loc.USN это «highestCommittedUSN» контроллера DC1 в момент внесения последних изменений.

· Originating DC говорит о том, на каком контроллере были произведены последние действия с этим атрибутом, т.е откуда пошло распространение.

· Org.Usn это «highestCommittedUSN» контроллера автора изменений в момент внесения последних.

· Ver – версия атрибута, растет на единицу при каждом его изменении (локально или в результате репликации).

· Attribute – непосредственно название самого атрибута.

Взглянув на эту таблицу можно сделать вывод, что пользователь «Федя Рашпин» был создан (или изменен) на контроллере домена DC1, при этом увидеть, что «highestCommittedUSN» DC1 в процессе создания учетной записи рос от 20904 до 20909. (Org.USN)

Совпадение колонок Loc.USN и Org.USN говорит о том, что запуск repadmin /showmeta произведен на контроллере домена, который был автором изменений. Если выполнить тоже самое на втором контроллере, результат будет несколько другой.

Рис. 10 Вывод метаданных о созданном пользователе на DC2.

На DC2 четко просматривается, что автором всех изменений (кроме одного) был DC1 и его «highestCommittedUSN» (Org.Usn) в момент изменения каждого атрибута. А также «highestCommittedUSN» в момент внесения обновлений в базу контроллера DC2. (Loc.USN)

А вот теперь пора сделать небольшой вывод:

Когда контроллер домена рассылает репликационным партнерам уведомления об обновлении базы, он сообщает свой текущий «highestCommittedUSN». Партнер, получивший это уведомление, сравнивает этот «highestCommittedUSN» с тем, что он запомнил с прошлой процедуры репликации. Если он вырос, значит необходимо запускать репликацию. Например: DC2 получил от DC1 уведомление и текущий «highestCommittedUSN» равный 20912, он сравнивает с известным ему значением 20850. Делает вывод о необходимости репликации и запрашивает изменения, произошедшие в период роста «highestCommittedUSN» с 20850 до 20912.

DC1 осуществляет выборку из своей базы. Для этого просматривается Loc.USN и те атрибуты, которые менялись в заданном диапазоне «highestCommittedUSN» реплицируются на DC2.

Решение конфликтов

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

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

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

В такой ситуации будет задействован скрытый контейнер LostAndFound, получить доступ, к которому можно только переключив оснастку «Active Directory – пользователи и компьютеры» в расширенный режим.

Рис. 11 Контейнер LostAndFound.

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

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

Рис. 12 Автоматическое разрешение конфликта

Большим преимуществом с точки зрения репликации является переход на режим работы домена Windows Server 2003 и более поздние. В них изменилась процедура репликации атрибутов типа «linked-valued» (пример «Членство в группах»). При добавлении разных пользователей на разных контроллерах в одну и туже группу результатом будет членство всхе добавленных пользователей в составе этой группы. В случае с Windows 2000 состав группы при таком конфликте определялся бы по ее членству на том контроллере, на котором изменения в группе были бы сделаны позже по времени.

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

Илья Рудь

Константин Леонтьев

Оринигал статьи взят с ресурса itband.ru

Диагностика репликации AD | Windows IT Pro/RE

Репликация Active Directory (AD) — метод, посредством которого изменения в базе службы каталогов на одном контроллере домена (DC) передаются другим контроллерам. AD — очень надежная и отказоустойчивая служба. Поскольку AD распределена по многим контроллерам домена, потеря части целого не нарушит работу всей службы каталогов. В лесу AD необходимо контролировать не только основные параметры DC, но и репликацию между контроллерами домена. Если не вести мониторинг, то со временем репликация в лесу нарушается, даже если администратор тщательно настроил контроллеры домена. Отслеживать и устранять неполадки репликации по мере возникновения значительно проще, чем восстанавливать лес с накопившимися проблемами. Но потребность в диагностике неизбежно возникает даже при мониторинге репликации AD. В данной статье объясняются основные принципы репликации и приводится простая методика диагностики неисправностей в репликации AD. Порой диагностика репликации AD представляет собой запутанный процесс. Следование описанному в статье порядку действий поможет упростить эту задачу.

Основы

Иногда бывает сложно найти оптимальный подход к диагностике репликации. Конечно, предпочтителен самый быстрый метод, однако пропуск одного этапа может в конечном итоге нарушить весь процесс диагностики. Логичный, исчерпывающий подход — самый эффективный. Желание немедленно применить мощные инструменты диагностики естественно, но разумнее сначала выполнить элементарные проверки. После того как будет приобретен опыт диагностики проблем репликации, многие операции покажутся очень простыми. Однако сперва требуется приобрести навыки, тщательно выполняя каждое действие, чтобы не сделать поспешных выводов и избежать необходимости повторять ранее совершенные действия. Начните с проверки состояния операционной системы на самом DC, затем проверьте состояние службы каталогов. После этого проверьте основные соединения между DC и другими контроллерами. И, наконец, проверьте протокол, используемый службой каталогов, и убедитесь, что контроллеры домена корректно выполняют взаимную проверку подлинности. Следование этой процедуре поможет обнаружить 90 процентов неисправностей репликации.

Тестирование фундамента

Первый шаг — проверить операционную систему DC. Ошибки репликации могут быть вызваны разнообразными локальными ошибками DC, поэтому необходимо проверить состояние фундамента — сервера. Если это еще не сделано, установите новейшие инструменты Windows Server Support Tools на всех производственных компьютерах. Все описанные утилиты входят в набор инструментов Windows Server Support Tools. Их можно загрузить из Microsoft Download Center (http://www.microsoft.com/downloads). Выполните поиск с ключевыми словами support tools для конкретной версии операционной системы и пакета обновления. Список полезных инструментов опубликован во врезке «Набор инструментов для диагностики репликации». Вряд ли удастся сразу решить все проблемы крупной компании; однако поисковый механизм Internet и база знаний Microsoft Knowledge Base (http://support.microsoft.com/search/?adv=1) помогут устранить самые заметные неполадки.

После установки пакета Windows Server Support Tools обследуйте журналы событий. Во-первых, следует провести поиск предупреждений и ошибок в системном журнале. Если в системном журнале есть сведения об ошибках, попробуйте запустить NetDiag. Даже без параметров командной строки NetDiag выполняет 23 проверки сетевой конфигурации компьютера. Среди выполняемых утилитой полезных проверок — членство в домене, DNS, конфигурация клиентов, доверительные отношения, Kerberos и функциональность LDAP. Если обнаружены неполадки, перезапустите NetDiag с ключом /test:testname и параметром /v, чтобы произвести тщательный анализ проблемной области. Важный параметр NetDiag, который будет рассмотрен далее в статье — ключ /fix, который перерегистрирует DNS-записи сервера.

Если сведения об ошибках содержатся в службе каталогов, запустите DCDiag, исчерпывающую тестовую утилиту для контроллеров домена. Даже без параметров командной строки DCDiag выполняет 25 тестов DC. Как и в случае с NetDiag, при обнаружении неполадок нужно перезапустить DCDiag с ключом /test:testname и параметром /v, чтобы выполнить тест проблемной области. Не следует придавать чрезмерное значение ошибкам в системном журнале; достаточно любого недавнего сбоя, чтобы тест завершился неудачей.

Если с помощью NetDiag и DCDiag не удалось обнаружить ошибок в операционной системе и службах каталогов, значит, пришло время заняться репликацией. Лучшая отправная точка — анализ результатов тестов DCDiag, так как DCDiag выполняет многочисленные тесты репликации.

Рассмотрим процесс диагностики типичной ошибки на примере домена, изображенного на Рис. 1. В домене, именуемом Deuby.net, имеется три DC. Контроллеры с именами Godan и Kohai находятся в сайте Hub. DC с именем Sandan расположен в сайте Branch, связанном с сайтом Hub через канал репликации, проводимой с интервалом 15 минут. Предположим, что обновления из Kohai в Godan не реплицируются.

Рис. 1. Пример домена с тремя DC

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

Рис. 2. Результаты работы DCDiag

На Рис. 2 показаны некоторые результаты запуска DCDiag на Godan. Обратите внимание, что тест Replications завершился неудачей из-за ошибки «[KOHAI] DsBindWith-SpnEx() failed with error 1722, The RPC server is unavailable». Несмотря на краткость сообщения, по нему можно составить хорошее представление о проблеме. Очевидно, отказ связан с контроллером домена Kohai. Но что означает «DsBind-WithSpnEx()»? «BindWithSpn» свидетельствует, что ошибка произошла при попытке привязки (подключения или проверки подлинности) Godan к Kohai. Поэтому источник неполадки — в неудачной организации связи Godan с Kohai.

Необходимо выяснить, может ли Godan обнаружить своего партнера по репликации, Kohai. Одна из первых проверок — ping-тестирование IP-адреса Kohai, это позволит убедиться в наличии элементарной сетевой связи. Если тест выполнен успешно, можно обратиться к Kohai по имени (по записи DNS типа A). Однако этот метод — не исчерпывающий тест репликации, так как DC ищет партнеров по репликации не с помощью A-записей (например, dc1.mycompany.com), но путем преобразования общего имени Canonical Name (CNAME) DNS, уникального внутри леса.

Каждый DC в лесу должен зарегистрировать запись CNAME для имени DsaGuid._msdcs.ForestName; по этой записи система репликации идентифицирует компьютер как DC. Запись CNAME ставит эту строку в соответствие записи A контроллера домена, в которой содержится его IP-адрес. Например, DNS CNAME узла dc1.mycompany.com может быть d40c01da-23fa-46e6-8bf3-798503e2590f._msdcs.mycompany.com. Запись CNAME будет иметь вид d40c01da-23fa-46e6-8bf3-798503e2590f._msdcs.mycompany.com CNAME dc1.mycompany.com. Следует отметить, что глобальный уникальный идентификатор (GUID) агента службы каталогов (directory service agent — DSA), который составляет первую часть записи CNAME контроллера домена — не GUID (конкретно, атрибут GUID объекта) объекта computer контроллера домена, как можно было бы ожидать. В действительности, это GUID объекта NTDS Settings в разделе DC в контейнере Sites. Например, если бы DC1 был в сайте Hub, то его отличительное имя (DN) было бы CN=NTDS Settings,CN=DC1,CN=Servers,CN=Hub,CN=sites,CN=configuration,DC=mycompany,DC=com.

Рис. 3. Просмотр записи CNAME контроллера домена Kohai

Если проблемный DC не может преобразовать запись CNAME партнера по репликации, то он не получает обновлений. Поэтому сначала необходимо определить DNS CNAME на основе GUID контроллера Kohai; затем нужно проверить, может ли Godan преобразовать CNAME. Вероятно, самый простой способ это сделать — запустить Active Directory Sites and Services (dssite.msc), перейти к сайту Godan (то есть Hub, контейнер Servers, компьютерный объект KOHAI), а затем щелкнуть правой кнопкой мыши на контейнере NTDS Settings и выбрать пункт Properties. Запись CNAME для Kohai находится в поле DNS Alias (Экран 3). Эту строку следует скопировать и вставить в команду Ping в командной строке в компьютере Godan (Экран 4), чтобы выяснить, может ли механизм репликации распознать Kohai. Поскольку DNS не может распознать Kohai через запись CNAME, репликации не произойдет. Особо отметим, что аналогичный запрос с использованием записи CNAME контроллера Godan обработан корректно.

Рис. 4. Эхо-тестирование CNAME Kohai

Выяснилось, что проблема — в отсутствии записи CNAME DNS контроллера Kohai. Существует два метода для ее перерегистрации. Простое решение — остановить и запустить службу Netlogon; однако при этом будет временно нарушена связь между Kohai и его активными пользователями. Из наличия неполадок в репликации не следует, что DC не обслуживает пользователей. Менее разрушительное решение — запустить NetDiag /fix. Параметр /fix предназначен специально для перерегистрации всех необходимых записей DNS для DC. После того, как будет выполнена эта операция, NetDiag функционирует корректно, но с предупреждением, что потребуется некоторое время для репликации добавленной записи CNAME на DNS-сервер, указанный как вторичный в конфигурации DNS сетевой платы.

Ошибки в настройке DNS

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

Убедитесь в корректности IP-адресов в клиентских настройках DC (свойства TCP/IP локального соединения). Если DC также играет роль DNS-сервера, то рекомендуется, чтобы первичная запись DNS указывала на себя. (Longhorn Server автоматически настраивает запись DNS на замыкание на себя — 127.0.0.1 — если работает мастер Dcpromo.) Вторичный DNS-сервер должен указывать на другой DC в том же домене. Дополнительные сведения о преимуществах и недостатках различных типов конфигурации DNS-клиента для контроллеров домена приведены в статье Microsoft «Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003».

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

Убедитесь, что DC уже зарегистрировал необходимые для функционирования записи ресурсов. К репликации относятся три записи. Две из них — CNAME (о которой шла речь выше) и A-запись (имя узла для преобразования IP-адреса). С помощью команды DCDiag /test:connectivity можно проверить, зарегистрированы ли эти записи в первичном DNS-сервере контроллера домена, и при необходимости использовать команду NetDiag для перерегистрации записей. Если записи все же не регистрируются, следует запустить DCDiag /test:Registerindomain /DnsDomain:dnsdomainname, чтобы проверить корректность настройки DC для регистрации. A-запись также должна соответствовать корректному IP-адресу. Кроме того, эти регистрации должны быть реплицированы на DNS-серверы, используемые партнерами, прежде чем те смогут обнаружить их. (Учтите, что команда IPConfig /RegisterDNS не регистрирует всех DNS-записей, необходимых контроллеру домена.)

Для дочерних контроллеров в древовидной структуре домена необходимо проверить третью, связующую (glue) запись. Связующие записи представляют собой A-записи DNS-серверов (иными словами, контроллеров домена) для дочерних доменов леса и хранятся в зоне прямого просмотра корневого домена. С помощью связующих записей удается решить проблему циклических ссылок: чтобы найти узел в дочернем домене вне этого домена, необходимо связаться с доверенным DNS-сервером данного домена. Но преобразовать имя доверенного сервера невозможно, так как его A-запись находится в том самом домене, о котором требуется получить DNS-информацию. Поместив второй набор A-записей для DNS-серверов дочернего домена в корневой каталог, удается решить проблему ссылок и «привязать» дочерние домены к корневому. Тестирование DNS с помощью команды DCDiag с параметром /DnsDelegation (DCDiag /test:DNS /DnsDelegation) проверяет корректность регистрации записей о связях в DC.

Отказ в доступе

Вторая наиболее распространенная группа ошибок относится к отказу в доступе DC к партнеру по репликации. В обычных условиях проблемы доступа отсутствуют, так как все учетные записи компьютеров DC являются членами встроенной группы Enterprise Domain Controllers. Таким образом, отказ в доступе означает, что результате какого-то события нарушены условия безопасности между партнерами по репликации. Одна из наиболее распространенных коренных причин — неверное время синхронизации одного из DC. Собственно репликация не зависит от времени, но Kerberos учитывает время. Kerberos требует точной временной синхронизации между контроллерами домена; если их внутренние часы отличаются более чем на пять минут (по умолчанию), то проверка Kerberos заканчивается неудачей и выдается сообщение об отказе в доступе к исходному DC. В системный журнал заносятся ошибки Kerberos и, возможно, W32Time.

С помощью команды Net Time /QuerySNTP можно выяснить, какие серверы времени назначены для данного DC. DC — член домена по определению; если DC — не эмулятор главного контроллера (PDC) корневого домена, то его указатель сервера времени должен быть пустым, потому что NTP-сервер (Network Time Protocol — сетевой протокол службы времени) для DC, отличного от главного контроллера домена — это PDC домена. Если данный DC расположен в дочернем домене, то PDC ищет DC в корневом домене в качестве источника времени, а эти контроллеры в свою очередь ищут PDC родительского домена (обычно корневого) в качестве доверенного источника времени для всего леса. Удалить ссылки на конкретный сервер времени можно с помощью команды Net Time /SetSNTP:. Затем можно использовать удобную команду W32tm, чтобы управлять NTP-параметрами DC. Чтобы настроить DC на обнаружение и синхронизацию с источником времени, запустите команду W32tm /Resync /Rediscover. Можно также применить команду W32tm /Config /Syncfromflags:DOMHIER для синхронизации с DC в соответствии с иерархией домена. Команда W32tm /Monitor позволяет проверить NTP-параметры всех DC в домене. Изменения времени отображаются на часах на панели задач. Дополнительные сведения о функционировании службы Windows Time приведены в статьях Microsoft «How Windows Time Service Works» и «How to configure an authoritative time server in Windows Server 2003».

Если из-за долгого отсутствия временной синхронизации истекли собственные билеты Kerberos контроллера домена, то необходимо отключить центр рассылки ключей Key Distribution Center (KDC) на DC и перезагрузиться. Чтобы отключить KDC, остановите его с помощью утилиты Control Panel Services и установите режим запуска в Disabled. В результате билеты Kerberos отменяются, и DC должен получить новые билеты с одного из оставшихся функциональных DC.

Другие рекомендации

Во-первых, запаситесь терпением. Для завершения репликации на предприятии требуется время, как и для устранения возникающих неполадок. Например, если DC не отвечает, то служба контроля целостности Knowledge Consistency Checker (KCC) ожидает 90 минут, прежде чем выполнить перерасчет объектов связи вокруг DC.

Особое значение придается безопасности, поэтому необходимо учитывать, что репликация могла быть блокирована в результате изменений в настройках брандмауэра. Обратите внимание на исправные серверы, которые не отвечают на эхо-тестирование по ping, и на серверы, которые отвечают на сигналы, посылаемые по одним протоколам, но не реагируют на другие. Подробные сведения о требованиях к портам DC приведены в статье Microsoft «Active Directory Replication over Firewalls».

Если данные в журнале службы каталогов недостаточно подробны, следует включить протоколирование NTDS в разделе реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNtdsDiagnostics. Выбор параметра зависит от области, которую нужно проанализировать (например, контроль целостности, преобразование имен, события репликации). Значение по умолчанию — 0, максимальное значение — 5. Обычно применять значения выше 3 не требуется. Исследуйте эффект изменения параметра на детальность сведений в журнале службы каталогов и отключите протоколирование, когда потребность в нем исчезнет.

Доверяйте KCC. Не поддавайтесь искушению поправить KCC, обнаружив отличия между созданной инструментом и плановой топологией. Если поведение KCC не такое, как ожидалось, то, вероятно, действительные настройки топологии сайта иные, чем предполагал администратор. Например, необходимо убедиться, что IP-адрес контроллера домена соответствует подсетям, связанным с сайтом, к которому относится DC.

И, наконец, если получены ошибки, указывающие, что DC не реплицировался в течение более длительного периода, чем время жизни объектов, помеченных на удаление, то рекомендуется отказаться от попыток диагностики. Необходимо перестроить DC, удалить метаданные из AD и заново назначить DC. Как сказал однажды коллега, обладатель сертификата MVP: «Контроллеры домена — как оловянные солдатики; всегда можно убрать DC и заменить его другим, точно таким же».

Волшебная палочка не нужна

Репликация — ключевая функция AD, но к диагностике репликации почему-то часто относятся как к колдовству. Чтобы снять мистический покров, используйте логический подход к основным проверкам; затем убедитесь, что операционная система DC функционирует корректно, проверьте конфигурацию DNS, связи между DC, Kerberos и его взаимозависимости (например, службу Windows Time), а также настройки брандмауэра. Следование рекомендациям данной статьи поможет вернуть диагностику репликации AD из области черной магии в сферу обычных технических процедур.

Шон Дьюби ([email protected]) — редактор Windows IT Pro и член группы службы каталогов в компании Intel. В течение четырех лет получал звание MVP; является автором книги «Windows 2000 Server: Planning and Migration» (издательство Macmillan).

Моментальный снимок решения:

Проблема:
Диагностика репликации Active Directory (AD).

Решение:
Проверить основные характеристики и использовать инструменты Windows Server Support Tools для мониторинга и восстановления процесса репликации AD.

Требуемые ресурсы:
Windows Server 2003 или Windows 2000, Windows Server Support Tools

Уровень сложности: 3 из 5

Убедитесь, что операционная система и служба каталогов целевого DC функционируют нормально.
Убедитесь, что DNS работает исправно как на целевом, так и на исходном контроллерах домена.
Убедитесь, что целевой DC распознает исходный DC.
Проверьте Kerberos и службы, от которых зависит его функционирование.
Проверьте настройки брандмауэра.

«Набор инструментов для диагностики репликации»

Шон Дьюби

Нельзя переоценить значение набора для диагностики репликации Active Directory (AD). Я рекомендую обратиться на Web-узел Windows Server 2003 Service Pack 1 32-bit Support Tools и составить базовый набор из следующих вспомогательных инструментов Windows Server. Независимые поставщики, такие как NetPro Computing и Quest Software, также выпускают утилиты, с помощью которых проще выполнить диагностику AD, в том числе и процесса репликации.

* Event Viewer. На первый взгляд, необходимость в этом инструменте очевидна, но мне приходилось встречать администраторов, которые игнорировали журнал, пытаясь разобраться в проблемах репликации. Используйте журнал службы каталогов, системный журнал и журнал DNS, если DNS установлена на контроллере домена (DC). Сообщения о событиях Windows Server 2003 гораздо более информативны, чем в предшествующих операционных системах, хотя встроенные ссылки на справочную систему Microsoft оказываются полезными далеко не всегда.

* DCDiag. Часто этот мощный инструмент можно применять вообще без параметров. Чтобы назначить отдельные тесты, используйте ключ /test:testname. Рекомендуется прочитать обо всех имеющихся тестах и разобраться в них. Ниже приведены некоторые важные параметры и тесты.

/S:server — указывает удаленный DC для тестирования.

/A — тестирует все контроллеры домена сайта.

/E — тестирует все контроллеры домена леса.

/test:DNS — исчерпывающий набор из семи тестов DNS, новшество Windows 2003 SP1. Дополнительные сведения приведены по адресу.

/CheckSecurityError — обнаруживает параметры безопасности, которые могут стать причиной отказа репликации.

* Repadmin. Repadmin — универсальная утилита репликации. Как только появляется новый способ управления или диагностики репликации, компания Microsoft обычно добавляет соответствующую функцию в этот инструмент. Параметр /experthelp выводит на экран две страницы с информацией о синтаксисе. Инструмент можно немедленно применять для устранения неполадок репликации, но чтобы освоить его, требуется время и глубокое понимание процесса репликации. Ниже перечислены важные команды Repadmin, знать которые полезно каждому администратору.

/Showrepl — показывает входящих партнеров по репликации DC для всех разделов каталога. Параметр /RepsTo показывает исходящих соседей DC.

/ReplSummary — показывает состояние репликации всего леса.

/KCC — задает пересчет топологии репликации с использованием инструмента проверки согласованности знаний (KCC). Это полезно, если требуется быстрее, чем обычно, учесть в KCC изменения, внесенные в контроллер домена.

/Queue — показывает задачи, ожидающие в очереди репликации.

/ShowObjMeta — показывает, какой DC инициировал обновление атрибутов указанного объекта.

/Replicate — принудительная репликация контекста именования (раздел каталога).

/OldHelp — перечисляет устаревшие команды.

/ExpertHelp — перечисляет дополнительные команды.

* Replmon. Хороший графический инструмент для анализа состояния различных разделов каталога, задействованных в репликации. Несмотря на отсутствие некоторых команд, имеющихся в Repadmin, это отличный выбор для администраторов, которым неудобно работать с Repadmin.

Поделитесь материалом с коллегами и друзьями

Диагностика состояния контроллера домена и репликаций Active Directory – gotoADM.ru

Диагностика состояния контроллера домена и репликаций Active Directory

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

Итак, для диагностики работы контроллера домена используется специализированная утилита — DCDIAG

Лучше всего выполнять проверку локально, т.е. на самом контроллере домена от учетной записи с правами администратора. Если же существует несколько DC, то на помощь придет команда автоматической проверки нескольких серверов (для удобства данные выводятся в текстовые файлы):

dcdiag /n:local /e /v /f:c:\logs\adtest.log /ferr:c:\logs\aderrors.log /u:local\user19 /p:Password

где:

/n:local — имя домена
/e автоматическая проверка всех серверов с ролью DC
/v расширенная проверка
/f — записать лог файл
/ferr — записать лог файл ошибок (актуально для WinSRV2003, в новых версиях — неактуально)
/u имя домена и пользователя

Теперь перейдем к анализу и проверки репликаций Active Directory. Межсайтовая топология отслеживается так:

repadmin /showism

Данную информацию можно просмотреть и через графическую оснастку, открыв «Active Directory Sites and Services».

Отображение партнеров по репликации и времени последней репликации выполняется следующей командой:

repadmin /showrepl

Следующей командой можно проверить

repadmin /replsummary [nameDC|wildcard]

При этом ключ /replsummary используется для быстрой проверки репликации на конкретном сервере, а ключ wildcard — для всех серверов.

Проверка USN записей:

repadmin /showutdvec

Синхронизация конкретного контроллера домена с участниками репликации:

replmon /syncall <nameDC>

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

Нашли ошибку в тексте? Выделите фрагмент текста и нажмите Ctrl+Enter

Как работает репликация Active Directory — статьи TechNet — США (английский)

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

Примечание В Windows 2000 Server и Windows Server 2003 служба каталогов называется

Active Directory.Начиная с Windows Server 2008, служба каталогов называется доменными службами Active Directory (AD DS).

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

AD DS состоит из одного или нескольких контекстов именования (NC) или разделов. Контекст именования — это непрерывное поддерево каталога (например,
схему каталога), которая является единицей репликации. В Active Directory каждый контроллер домена всегда содержит не менее трех реплик NC:

Схема
Конфигурация (топология репликации и связанные метаданные)
Контекст именования домена (содержит фактические объекты в каталоге)

Схема NC определяет типы объектов (например, пользователей) и атрибуты этих объектов (например, номера телефонов), которые могут быть созданы.
хранятся в AD DS, а также правила для их создания и управления ими.Информация о схеме (какие атрибуты являются обязательными для создания объекта, какие дополнительные атрибуты могут быть установлены и какие типы данных атрибутов используются) реплицируется на весь домен.
контроллеры в лесу. В отличие от других NC, NC схемы доступен для записи только на контроллере домена, выполняющем роль FSMO мастера схемы.

NC конфигурации включает информацию о AD DS в целом — какие домены существуют, какие сайты доступны, какие контроллеры домена
работают на определенных сайтах и доменах, а также информацию о конфигурации для дополнительных служб, таких как службы сертификации Active Directory (AD CS) и Microsoft Exchange.Все контроллеры домена предприятия нуждаются в этой информации, чтобы
решения (например, выбор партнеров по репликации), чтобы он реплицировался на каждый контроллер домена в лесу.

Контекст именования домена содержит такие объекты, как пользователи, группы, компьютеры и организационные единицы. Полная реплика контекста именования домена содержит доступную для записи реплику всей информации в домене, включая все объекты и их атрибуты. Контроллер домена
(DC) содержит полную копию своего контекста именования домена.Частичная реплика контекста именования домена содержит доступную только для чтения подмножество информации в домене — все объекты, но только выбранные атрибуты. Эти атрибуты вместе известны как частичный атрибут.
Установить (PAS). Контроллер домена, который является глобальным
Сервер каталога (GC) содержит частичную реплику каждого другого домена в лесу (и полную реплику своего собственного домена).

Серверы

GC ускоряют поиск в каталоге всего предприятия, выступая в качестве индексаторов для предприятия, храня в своей базе данных копию выбранных атрибутов для всех корпоративных объектов — небольшой набор общих атрибутов объектов, обычно значимых при поиске:
имя и фамилия для пользовательских объектов, расположение принтеров и т. д.Даже если конкретный атрибут не найден в базе данных GC, пользователь или приложение могут, по крайней мере, узнать, с какими контроллерами домена следует связаться для получения дополнительной информации.

Кроме того, глобальные каталоги также необходимы для операций входа в систему. Серверы GC сопоставляют основные имена пользователей ( [email protected] ) учетным записям ( HQ.Acme.com \ FredG ). Только серверы GC знают все членство пользователей в универсальных группах, поэтому процесс входа в систему
должен связаться с GC для добавления идентификаторов безопасности (SID) универсальных групп к токену доступа пользователя, если пользователь является членом универсального
группа.

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

Объектная модель

Объекты в Active Directory определяются типами и значениями их атрибутов.Объект получает свою идентичность от своего глобального уникального идентификатора (GUID —
единственный атрибут, который нельзя изменить). Он отслеживает системный объект в Active Directory даже после того, как перемещение между доменами меняет его отличительные особенности.
имя (DN).

Как уже отмечалось, схема определяет, какие атрибуты могут использоваться для объектов. Модуль расширяемого хранилища AD DS (в произношении используются буквы ESE или слова «легко») резервирует место только для атрибутов с установленными на них фактическими значениями (атрибуты, содержащие
ценности).Это помогает сэкономить место в базе данных, поскольку пользовательские объекты имеют более 100 определенных атрибутов, но обычно используются только 20–30. Используя эту модель, механизм репликации минимизирует трафик, реплицируя только атрибуты объекта, которым присвоены значения,
и только атрибуты со значениями, которые изменились с момента последней репликации.

Репликация с несколькими мастерами

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

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

номер версии атрибута
отметка времени изменения атрибута
GUID контроллеров домена, выполнивших операцию записи

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

Эффективность репликации повышается за счет гибкой топологии репликации, которая может отражать структуру существующей сети. Генератор топологии репликации Active Directory работает как часть средства проверки согласованности знаний (KCC).
Вы передаете в KCC информацию о стоимости отправки данных из одного места в другое и о том, какие контроллеры домена работают в том же месте. Используя это, KCC строит топологию межсайтовой репликации, которая представляет собой связующее дерево на основе недорогой маршрутизации.
решения между удаленными точками и более тесно связанная внутрисайтовая топология.Вы можете отключить генератор топологии KCC и вручную создать объекты подключения, необходимые для репликации. Во время этого процесса механизм ведения журнала Active Directory
определяет контроллеры домена, которые кажутся изолированными от репликации в масштабе предприятия.
Примечание Настоятельно рекомендуется использовать генератор топологии репликации: он упрощает сложную задачу, имеет гибкую архитектуру, которая реагирует на сбои и изменения, которые вы вносите позже в топологии сети, и помогает вычислить топологию с наименьшими затратами.

Объекты подключения

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

Сайтов

Используется в Active Directory для обозначения близости сетевого подключения,
сайт определяется как IP
подсеть — концепция, используемая во всех сетевых средах с маршрутизацией TCP / IP. Юридическое определение сайта может быть 177.177.177.0/24, где
177.177.177.0 описывает подсеть IP, а 24 сообщает, сколько битов используется для ее определения. Остальные биты IP-адреса (32 — 24 = 8 бит в этом примере) могут использоваться для определения хостов.

Сайт состоит из одной или нескольких подсетей (уникальных сегментов сети). Например, в сети с тремя подсетями в Редмонде и двумя в Париже администратор может создать два сайта: один в Редмонде и один в Париже, и добавить подсети к локальным сайтам.

Служба каталогов Active Directory использует информацию о сайте следующим образом:

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

Внутрисайтовая репликация

Внутрисайтовая репликация (между контроллерами домена на одном сайте) пытается завершиться за минимально возможное количество циклов ЦП. Поскольку контроллеры домена должны иметь возможность быстро обслуживать клиентов для входа в систему, поиска и т. Д., Сетевое соединение между ними
предполагается наличие большой доступной полосы пропускания и надежного соединения.

Репликация

— это компромисс: данные должны быть максимально точными на всех контроллерах домена, а это означает, что задержка должна быть как можно меньше, что означает быстрые обновления, что означает частую репликацию.С другой стороны, частота не всегда
равная эффективность. Например, при массовом импорте объектов каталога изменения в базе данных контроллера домена станут устаревшими через 10 секунд, но нет смысла реплицировать изменения, пока база данных не станет стабильной (массовый импорт
полная).

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

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

Топология внутрисайтовой репликации — это двунаправленное кольцо, построенное с использованием идентификаторов GUID контроллера домена. Если кольцо содержит семь или более контроллеров домена, добавляются двунаправленные соединения, чтобы длина пути между любой парой составляла менее трех переходов. Новые контроллеры домена настроены в
сайта включены в кольцо. Для каждого контекста именования, доступного на сайте, создается одно двунаправленное кольцо. Информация о схеме и конфигурации имеет одну и ту же топологию, и для них построено только одно двунаправленное кольцо, потому что они должны быть реплицированы на
все контроллеры домена.

Если все контроллеры домена сайта находятся в одном домене, два кольца одинаковы — кольцо, включающее все контроллеры домена сайта, эквивалентно кольцу, которое включает все контроллеры домена в этом домене. У вас несколько разных колец
только если ваш сайт содержит более одного домена: 2 домена = 3 кольца, 3 домена = 4 кольца и т. д. Чтобы узнать, какие кольца существуют на сайте, используйте оснастку Active Directory Sites and Services Manager для проверки объектов подключения и просмотра входящих
репликационные соединения, которые они представляют.

Межсайтовая репликация

Межсайтовая репликация основана на предположении, что глобальная сеть подключена по более медленным каналам, поэтому она предназначена для минимизации трафика.
а не циклы процессора. Перед отправкой данные сжимаются примерно до 10–15% от исходного объема.

Топология межсайтовой репликации — это связующее дерево. Пока можно построить маршрут репликации между всеми сайтами на предприятии, топология репликации работает. Нет необходимости создавать дополнительные ссылки.Администратор решает, какие
сайты связаны и могут создавать ссылку сайтов, которая позволяет контроллерам домена с любого сайта взаимодействовать с контроллерами домена на любом другом сайте. Ссылки на сайты основаны на стоимости репликации (которая отражает скорость и надежность базовой сети)
и его расписание (которое определяет окно, когда разрешена репликация по ссылке).

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

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

Транспорты репликации

В то время как внутрисайтовая репликация поддерживает только репликацию на основе удаленных вызовов процедур (RPC), первоначальный выпуск Windows 2000
предлагает два транспорта для межсайтовой репликации:

Синхронный (по расписанию) через RPC через TCP / IP
Асинхронный через простой протокол передачи почты (SMTP) с использованием интерфейса Collaborative Data Objects (CDO v2) и компонента SMTP
в IIS 5, который включен в Windows 2000.

Внутрисайтовый транспорт RPC не поддерживает сжатие данных; межсайтовый транспорт, как RPC, так и SMTP, делает. Репликация на основе RPC может использоваться для любого вида репликации — внутридоменной репликации, информации о конфигурации или информации глобального каталога.

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

Трафик репликации Active Directory (http://technet.microsoft.com/library/bb742457.aspx)
Технологии репликации Active Directory (http://technet.microsoft.com/library/cc776877.aspx)

Принудительная репликация всех контроллеров домена на всех сайтах одновременно — SID-500.COM

PowerShell

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

Если вы хотите реплицировать все Контроллеры домена, то вам нужно запустить репликацию на каждом из них отдельно. Это может занять некоторое время.Чтобы сэкономить время, я собираюсь показать вам PowerShell One-Liner для принудительной репликации на всех контроллерах домена всех сайтов Active Directory. Давайте теперь взглянем на этот One-Liner.

Принудительная репликация всех контроллеров домена на всех сайтах

Предположим, у вас есть один домен с несколькими сайтами. (Один лес и один корневой домен леса).

Войдите в систему на одном из контроллеров домена. Запустите Windows PowerShell с правами администратора. Имя домена и раздел домена указывать не нужно.Они будут автоматически заполнены Get-ADDomain. 😉

function Replicate-AllDomainController {
(Get-ADDomainController -Filter *). Имя | Foreach-Object {repadmin / syncall $ _ (Get-ADDomain) .DistinguishedName / e / A | Out-Null}; Start-Sleep 10; Get-ADReplicationPartnerMetadata -Target "$ env: userdnsdomain" -Scope Domain | Сервер Select-Object, LastReplicationSuccess
}

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

Вот и все.

Удачи, копируя свой DC! Подробнее о repadmin здесь:

https://technet.microsoft.com/en-us/library/cc835086(v=ws.11).aspx

См. Также

PowerShell: добавление пользователей Active Directory из текстовых файлов (массовое)

Windows Server 2016: настройка членства в группах по времени с помощью PowerShell

PowerShell: изменение имен пользователей для входа в Active Directory (массовое)

Опубликовано Патрик Грюнауэр

Microsoft MVP по PowerShell [2018-2021], ИТ-тренер, ИТ-консультант, MCSE: облачная платформа и инфраструктура, сертифицированный инструктор Академии Cisco, маршрутизация и коммутация CCNA, безопасность CCNA
Просмотреть все сообщения Патрика Грюнауэра

Как проверить репликацию Active Directory

В этом руководстве вы узнаете, как использовать инструмент repadmin для проверки репликации Active Directory.

Repadmin — это совершенный инструмент диагностики репликации.

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

Репликация

Active Directory — это важная служба, которая поддерживает синхронизацию изменений с другими контроллерами домена в лесу.

Проблемы с репликацией могут вызвать сбои аутентификации и проблемы с доступом к сетевым ресурсам (файлам, принтерам, приложениям).

Ниже я покажу вам пошаговый процесс с множеством примеров и результатов.

Давай сделаем это.

Как установить Repadmin

Repadmin был представлен в 2003 году вместе со средствами поддержки Windows Server 2003.

Microsoft начала включать команду repadmin в Windows Server 2008 и новее. Он также присутствует на любом компьютере, на котором установлены средства удаленного администрирования сервера (RSAT).

Примеры Repadmin

Чтобы использовать repadmin, вам необходимо запустить командную строку от имени администратора. Просто щелкните правой кнопкой мыши cmd и выберите запуск от имени администратора

Пример 1: Отображение меню справки repadmin

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

 repadmin /?

Отображаемые результаты

 C: \ Users \ rallen> repadmin /?
Использование: repadmin [/ u: {домен \ пользователь}] [/ pw: {пароль | *}]
                             [/ retry [:] [:]]
                             [/ csv]

Используйте эти команды для просмотра справки:

/? Отображает список команд, доступных для использования в repadmin, и их
            описание.
/ help То же, что /?
/ ?: Отображает список возможных аргументов, соответствующих
            синтаксисы и примеры для указанной команды./ help: То же, что / ?:
/ experthelp Отображает список команд для использования только опытными пользователями.
/ listhelp Отображает варианты синтаксиса, доступные для DSA_NAME,
            Строки DSA_LIST, NCNAME и OBJ_LIST.
/ oldhelp Отображает список устаревших команд, которые все еще работают, но
            больше не поддерживаются Microsoft.


Поддерживаемые команды (используйте /? Для получения подробной справки):
     / kcc Заставляет KCC на целевом контроллере домена немедленно
             пересчитать топологию входящей репликации./ prp Эта команда позволяет администратору просматривать или изменять
             политика репликации паролей для контроллеров домена только для чтения.

     / queue Отображает входящие запросы репликации, которые должен выдать контроллер домена.
             для согласования с исходными партнерами по репликации.

     / replicate Запускает немедленную репликацию указанного каталога.
             раздел на конечный контроллер домена от исходного контроллера домена.

     / replsingleobj Реплицирует один объект между любыми двумя доменами.
             контроллеры, у которых есть общие разделы каталога./ replsummary Операция replsummary быстро и кратко резюмирует
             состояние репликации и относительное состояние леса.

     / rodcpwdrepl Запускает репликацию паролей для указанных пользователей.
             от источника (Hub DC) к одному или нескольким DC только для чтения.

     / showattr Отображает атрибуты объекта.

     / showobjmeta Отображает метаданные репликации для указанного объекта.
             хранится в Active Directory, например ID атрибута, версия
             номер, исходный и местный порядковый номер обновления (USN) и
             GUID исходного сервера и отметка даты и времени./ showrepl Отображает состояние репликации при указанном контроллере домена
             последняя попытка входящей репликации разделов Active Directory.

     / showutdvec отображает наивысший зафиксированный порядковый номер обновления (USN)
             что копия Active Directory целевого контроллера домена отображается как
             взяла на себя обязательства перед собой и своими переходными партнерами.

     / syncall Синхронизирует указанный контроллер домена со всей репликацией.
              партнеры.Поддерживаемые дополнительные параметры:

     / u: указывает домен и имя пользователя, разделенные обратной косой чертой.
            {домен \ пользователь}, у которого есть разрешения на выполнение операций в
            Active Directory. Вход в систему UPN не поддерживается.

     / pw: указывает пароль для имени пользователя, введенного с / u.
            параметр.

     / retry Этот параметр заставит repadmin повторить попытку привязки
            к целевому постоянному току, если первая попытка не удалась с одним из
            следующий статус ошибки:

            1722 / 0x6ba: «Сервер RPC недоступен»
            1753 / 0x6d9: "Больше нет доступных конечных точек из
                            сопоставитель конечных точек "

     / csv Используется с / showrepl для вывода результатов через запятую
            формат значения.См. / Csvhelp

Пример 2: Суммируйте состояние репликации и просмотрите общее состояние

Первая команда, которую вы должны использовать, — это replsummary. Эта команда быстро покажет вам общее состояние репликации. Эта команда покажет вам процент неудачных попыток репликации, а также самые большие дельты репликации.

 repadmin / replsummary

Отображаемые результаты

: \ WINDOWS \ system32> repadmin / replsummary
Время начала сводки репликации: 2018-03-13 04:44:54

Начало сбора данных для сводки репликации, это может занять некоторое время:
  .....


Сбой наибольшей разницы в исходном DSA / общая ошибка %%
 DC1 52 м: 48 с 0/5 0
 DC2 52 м: 46 с 0/5 0


Наибольшая дельта ошибок целевого DSA / общая ошибка %%
 DC1 52 м: 46 с 0/5 0
 DC2 52 м: 48 с 0/5 0

Пример 3: Показать партнера репликации и статус

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

Кроме того, эта команда отображает GUID каждого реплицированного объекта и его результат. Это помогает определить, какие объекты не могут реплицироваться.

 repadmin / showrepl

Отображаемые результаты

 C: \ Пользователи \ rallen> repadmin / showrepl

Repadmin: запуск команды / showrepl для полного DC dc1.ad.activedirectorypro.com
Default-First-Site-Name \ DC1
Параметры DSA: IS_GC
Параметры сайта: (нет)
GUID объекта DSA: a4d22a63-1918-492a-bcd6-7fe286941e72
ID вызова DSA: a4d22a63-1918-492a-bcd6-7fe286941e72

==== ПРИБЫЛЬНЫЕ СОСЕДИ ======================================

DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC2 через RPC
        GUID объекта DSA: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408
        Последняя попытка @ 13.03.2018 03:52:08 удалась.CN = Конфигурация, DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC2 через RPC
        GUID объекта DSA: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408
        Последняя попытка @ 13.03.2018 03:52:08 удалась.

CN = Схема, CN = Конфигурация, DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC2 через RPC
        GUID объекта DSA: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408
        Последняя попытка @ 13.03.2018 03:52:08 удалась.

DC = DomainDnsZones, DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC2 через RPC
        GUID объекта DSA: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408
        Последняя попытка @ 13.03.2018 03:52:08 удалась.DC = ForestDnsZones, DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC2 через RPC
        GUID объекта DSA: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408
        Последняя попытка @ 13.03.2018 03:52:08 удалась.

Пример 4: Показать партнера репликации для определенного контроллера домена

Если вы хотите увидеть статус репликации для определенного контроллера домена, используйте эту команду.

замените именем вашего контроллера домена.

 repadmin / showrepl <имя сервера>

Отображаемые результаты

 C: \ WINDOWS \ system32> repadmin / showrepl dc2
Default-First-Site-Name \ DC2
Параметры DSA: IS_GC
Параметры сайта: (нет)
GUID объекта DSA: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408
ИД вызова DSA: 2eb95693-bfa7-4f3f-b52c-139737aa883f

==== ПРИБЫЛЬНЫЕ СОСЕДИ ======================================

DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC1 через RPC
        GUID объекта DSA: a4d22a63-1918-492a-bcd6-7fe286941e72
        Последняя попытка @ 14.03.2018 04:21:02 удалась.CN = Конфигурация, DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC1 через RPC
        GUID объекта DSA: a4d22a63-1918-492a-bcd6-7fe286941e72
        Последняя попытка @ 14.03.2018 03:52:07 удалась.

CN = Схема, CN = Конфигурация, DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC1 через RPC
        GUID объекта DSA: a4d22a63-1918-492a-bcd6-7fe286941e72
        Последняя попытка @ 14.03.2018 03:52:07 удалась.

DC = DomainDnsZones, DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC1 через RPC
        GUID объекта DSA: a4d22a63-1918-492a-bcd6-7fe286941e72
        Последняя попытка @ 14.03.2018 03:52:07 удалась.DC = ForestDnsZones, DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC1 через RPC
        GUID объекта DSA: a4d22a63-1918-492a-bcd6-7fe286941e72
        Последняя попытка @ 14.03.2018 03:52:07 удалась.

Пример 5: Показать только ошибки репликации

Команда showrepl может выводить большой объем информации. Если вы хотите видеть только ошибки, используйте эту команду. В этом примере DC2 не работает, вы можете видеть, что все результаты — это ошибки DC2.

 C: \ WINDOWS \ system32> только repadmin / showrepl / errors

Repadmin: запуск команды / showrepl для полного DC dc1.ad.activedirectorypro.com
Default-First-Site-Name \ DC1
Параметры DSA: IS_GC
Параметры сайта: (нет)
GUID объекта DSA: a4d22a63-1918-492a-bcd6-7fe286941e72
ID вызова DSA: a4d22a63-1918-492a-bcd6-7fe286941e72

==== ПРИБЫЛЬНЫЕ СОСЕДИ ======================================

DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC2 через RPC
        GUID объекта DSA: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408
        Последняя попытка @ 15.03.2018 04:19:38 не удалась, результат 8524 (0x214c):
            Операция DSA не может быть продолжена из-за сбоя поиска DNS.1 сбой подряд.
        Последний успех @ 14.03.2018 07:52:08.

CN = Конфигурация, DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC2 через RPC
        GUID объекта DSA: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408
        Последняя попытка @ 15.03.2018 04:19:38 не удалась, результат 8524 (0x214c):
            Операция DSA не может быть продолжена из-за сбоя поиска DNS.
        1 сбой подряд.
        Последний успех @ 14.03.2018 07:52:08.CN = Схема, CN = Конфигурация, DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC2 через RPC
        GUID объекта DSA: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408
        Последняя попытка @ 15.03.2018 04:19:38 не удалась, результат 8524 (0x214c):
            Операция DSA не может быть продолжена из-за сбоя поиска DNS.
        1 сбой подряд.
        Последний успех @ 14.03.2018 07:52:08.

DC = DomainDnsZones, DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC2 через RPC
        GUID объекта DSA: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408
        Последняя попытка @ 15.03.2018 04:19:38 не удалась, результат 8524 (0x214c):
            Операция DSA не может быть продолжена из-за сбоя поиска DNS.1 сбой подряд.
        Последний успех @ 14.03.2018 07:52:08.

DC = ForestDnsZones, DC = ad, DC = activedirectorypro, DC = com
    Default-First-Site-Name \ DC2 через RPC
        GUID объекта DSA: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408
        Последняя попытка @ 15.03.2018 04:19:38 не удалась, результат 8524 (0x214c):
            Операция DSA не может быть продолжена из-за сбоя поиска DNS.
        1 сбой подряд.
        Последний успех @ 14.03.2018 07:52:08.Источник: Default-First-Site-Name \ DC2
******* 1 ПОСЛЕДОВАТЕЛЬНАЯ НЕИСПРАВНОСТЬ с 14.03.2018 07:52:08
Последняя ошибка: 8524 (0x214c):
            Операция DSA не может быть продолжена из-за сбоя поиска DNS.

Пример 6: Показать очередь репликации

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

Используйте эту команду для просмотра очереди репликации

 Repadmin / Очередь

Отображаемые результаты

 C: \ Users \ rallen> repadmin / очередь

Repadmin: выполнение команды / очереди для полного DC dc1.ad.activedirectorypro.com
Очередь содержит 0 элементов.

, пример 7: принудительная репликация Active Directory

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

Будет выполнена репликация по запросу, что означает получение обновлений с DC2 до DC1.

 repadmin / syncall dc1 / AeD

Если вы хотите запустить репликацию, воспользуйтесь переключателем / P. Например, если вы вносите изменения на DC1 и хотите реплицировать их на другие DC, используйте эту команду.

 repadmin / syncall dc1 / APeD

Отображаемые результаты

 C: \ WINDOWS \ system32> repadmin / syncall dc1 / AeD
Синхронизация всех NC на dc1.Раздел синхронизации: DC = ForestDnsZones, DC = ad, DC = activedirectorypro, DC = com
ОБРАТНОЕ СООБЩЕНИЕ: Выполняется следующая репликация:
    От: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408._msdcs.ad.activedirectorypro.com
    Кому: a4d22a63-1918-492a-bcd6-7fe286941e72._msdcs.ad.activedirectorypro.com
СООБЩЕНИЕ ОБ ОТВЕТЕ: Следующая репликация успешно завершена:
    От: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408._msdcs.ad.activedirectorypro.com
    Кому: a4d22a63-1918-492a-bcd6-7fe286941e72._msdcs.ad.activedirectorypro.com
ОБРАТНОЕ СООБЩЕНИЕ: SyncAll Finished.
SyncAll завершился без ошибок.

Раздел синхронизации: DC = DomainDnsZones, DC = ad, DC = activedirectorypro, DC = com
ОБРАТНОЕ СООБЩЕНИЕ: Выполняется следующая репликация:
    От: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408._msdcs.ad.activedirectorypro.com
    Кому: a4d22a63-1918-492a-bcd6-7fe286941e72._msdcs.ad.activedirectorypro.com
СООБЩЕНИЕ ОБ ОТВЕТЕ: Следующая репликация успешно завершена:
    Откуда: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408._msdcs.ad.activedirectorypro.com
    Кому: a4d22a63-1918-492a-bcd6-7fe286941e72._msdcs.ad.activedirectorypro.com
ОБРАТНОЕ СООБЩЕНИЕ: SyncAll Finished.
SyncAll завершился без ошибок.

Раздел синхронизации: CN = Схема, CN = Конфигурация, DC = ad, DC = activedirectorypro, DC = com
ОБРАТНОЕ СООБЩЕНИЕ: Выполняется следующая репликация:
    От: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408._msdcs.ad.activedirectorypro.com
    Кому: a4d22a63-1918-492a-bcd6-7fe286941e72._msdcs.ad.activedirectorypro.com
СООБЩЕНИЕ ОБ ОТВЕТЕ: Следующая репликация успешно завершена:
    От: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408._msdcs.ad.activedirectorypro.com
    Кому: a4d22a63-1918-492a-bcd6-7fe286941e72._msdcs.ad.activedirectorypro.com
ОБРАТНОЕ СООБЩЕНИЕ: SyncAll Finished.
SyncAll завершился без ошибок.

Раздел синхронизации: CN = Configuration, DC = ad, DC = activedirectorypro, DC = com
ОБРАТНОЕ СООБЩЕНИЕ: Выполняется следующая репликация:
    Откуда: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408._msdcs.ad.activedirectorypro.com
    Кому: a4d22a63-1918-492a-bcd6-7fe286941e72._msdcs.ad.activedirectorypro.com
СООБЩЕНИЕ ОБ ОТВЕТЕ: Следующая репликация успешно завершена:
    От: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408._msdcs.ad.activedirectorypro.com
    Кому: a4d22a63-1918-492a-bcd6-7fe286941e72._msdcs.ad.activedirectorypro.com
ОБРАТНОЕ СООБЩЕНИЕ: SyncAll Finished.
SyncAll завершился без ошибок.

Раздел синхронизации: DC = ad, DC = activedirectorypro, DC = com
ОБРАТНОЕ СООБЩЕНИЕ: Выполняется следующая репликация:
    Откуда: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408._msdcs.ad.activedirectorypro.com
    Кому: a4d22a63-1918-492a-bcd6-7fe286941e72._msdcs.ad.activedirectorypro.com
СООБЩЕНИЕ ОБ ОТВЕТЕ: Следующая репликация успешно завершена:
    От: 57a1cfbc-88bb-41da-a1a6-f14f5c9df408._msdcs.ad.activedirectorypro.com
    Кому: a4d22a63-1918-492a-bcd6-7fe286941e72._msdcs.ad.activedirectorypro.com
ОБРАТНОЕ СООБЩЕНИЕ: SyncAll Finished.
SyncAll завершился без ошибок.

Пример 8: Экспорт результатов в текстовый файл

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

просто добавьте> c: \ destination folder \ filename.txt в конец любой из команд

Вот несколько примеров

 repadmin / replsummary> c: \ it \ replsummary.txt

 repadmin / showrepl> c: \ it \ showrepl.txt

Другие примеры

Найдите время последнего резервного копирования вашего DC

 Repadmin / showbackup *

Отображает вызовы, на которые еще не ответили

 repadmin / showoutcalls *

Список информации о топологии

 repadmin / плацдармы * / подробный

Отчет генератора межсайтовой топологии

 repadmin / istg * / подробный

Заключение

Системному администратору важно знать, как устранять неполадки и проверять правильность работы репликации.Repadmin — это простой, но мощный инструмент, которым вы должны уметь пользоваться.

Надеюсь, это руководство было для вас полезным. Если у вас есть вопросы, оставьте комментарий ниже.

См. Также:

Как быстро проверить роли FSMO
Использование NSLookup для проверки записей DNS

Рекомендуемый инструмент: SolarWinds Server & Application Monitor

Эта утилита была разработана для мониторинга Active Directory и других важных служб, таких как DNS и DHCP.Он быстро обнаруживает проблемы с контроллером домена, предотвращает сбои репликации, отслеживает неудачные попытки входа в систему и многое другое.

Что мне больше всего нравится в SAM, так это простая в использовании панель управления и функции предупреждений. Он также имеет возможность контролировать виртуальные машины и хранилище.

Загрузите бесплатную пробную версию здесь

Репликация Active Directory через брандмауэры — статьи TechNet — США (английский)

Эта статья основана на статье из библиотеки Microsoft TechNet и представлена здесь, чтобы дать возможность тем сторонним сотрудникам Microsoft, которые заинтересованы и хорошо осведомлены в этой теме, улучшить ее.

Более свежие рекомендации по репликации Active Directory в Windows Server 2008 находятся в статье

Доменные службы Active Directory в сети периметра (Windows Server 2008).

Более свежие рекомендации о границах поддержки Microsoft для использования Active Directory с преобразованием сетевых адресов см. По адресу
http://support.microsoft.com/default.aspx?scid=kb;EN-US;978772.

Более свежая информация о требованиях к сетевому порту для системы Windows Server находится по адресу
http://support.microsoft.com/kb/832017

Брандмауэры

представляют две трудности при развертывании распределенной архитектуры службы каталогов Active Directory (AD):

Первоначальное повышение уровня сервера до контроллера домена.
Репликация трафика между контроллерами домена.

Active Directory полагается на удаленный вызов процедур (RPC) для репликации между контроллерами домена. (Простой протокол передачи почты [SMTP] может использоваться в определенных ситуациях — схема, конфигурация и репликация глобального каталога, но не контекст именования домена — ограничение
его полезность.) Обеспечение правильного функционирования репликации в средах, где лес каталогов распределен между внутренними сетями периметра и внешними (то есть выходящими в Интернет) сетями, может оказаться сложной задачей.Есть три возможных подхода:

Откройте брандмауэр, чтобы разрешить динамическое поведение RPC.
Ограничьте использование RPC портов TCP и немного откройте брандмауэр.
Инкапсулируйте трафик контроллера домена (DC-to-DC) в протокол IP-безопасности (IPSec) и откройте для этого брандмауэр.

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

Верх страницы

Плюсы	Минусы
Нет специальной конфигурации сервера	Превращает межсетевой экран в «швейцарский сыр»
	Случайные входящие высокоскоростные соединения
	Небезопасная конфигурация межсетевого экрана

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

Чтобы включить репликацию через динамический RPC, настройте брандмауэр, чтобы разрешить следующее:

Сервис	Порт / протокол
Устройство сопоставления конечных точек RPC	135 / TCP, 135 / UDP
Служба имен базовой системы ввода / вывода сети (NetBIOS)	137 / tcp, 137 / udp
Служба дейтаграмм NetBIOS	138 / UDP
Служба сеансов NetBIOS	139 / tcp
Динамическое назначение RPC	Win 2k / 2003: 1024-65535 / TCP Win 2008+: 49152-65535 / TCP
Блок сообщений сервера (SMB) по IP (Microsoft-DS)	445 / TCP, 445 / UDP
Облегченный протокол доступа к каталогам (LDAP)	389 / tcp
Пинг LDAP	389 / UDP
LDAP через SSL	636 / tcp
Глобальный каталог LDAP	3268 / TCP
Глобальный каталог LDAP через SSL	3269 / TCP
Kerberos	88 / TCP, 88 / UDP
Служба доменных имен (DNS)	53 / TCP1, 53 / UDP

1	TCP используется для передачи зон и когда ответы на вопросы превышают 512 байт.

Информацию о требованиях к портам Windows см .:

832017 Обзор службы и требования к сетевому порту для системы Windows Server (http://support.microsoft.com/default.aspx?scid=kb;EN-US;832017)

Это правило «динамического назначения RPC» делает этот сценарий небезопасным. Иногда это правило называется «TCP high ports». Правило должно разрешать входящий трафик на любой порт выше 1024 в 2000–2003 годах и порты выше 49152 в 2008 году и новее.Если ваш брандмауэр
позволяет это, то есть очень мало причин даже для установки межсетевого экрана.

Если вы не хотите разрешать DNS или WINS, вы можете использовать HOSTS (для DNS) и
LMHOSTS (для WINS) файлов для разрешения имен. Эти файлы хранятся в
% SystemRoot% \ system32 \ drivers \ etc . Загляните в файлы, чтобы узнать, как их использовать.

Верх страницы

Служба RPC настраивается в реестре с использованием универсального уникального идентификатора (UUID) (аналогично глобальному уникальному идентификатору [GUID]).UUID — это хорошо известные идентификаторы, уникальные для каждой службы и общие для всех платформ.
Когда служба RPC запускается и не запрашивает конкретный порт у среды выполнения, она получает свободный высокий порт и регистрирует этот порт с помощью UUID. Назначение порта является статическим в течение всего срока службы службы.

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

Таким образом, он устанавливает соединение с серверной службой portmapper (на 135) и запрашивает нужную службу, используя UUID службы. Portmapper возвращает клиенту соответствующий номер порта и закрывает соединение.
Наконец, клиент устанавливает новое соединение с сервером, используя номер порта, полученный от portmapper.

Поскольку невозможно заранее узнать, какой порт будет использовать служба RPC, брандмауэр должен разрешить прохождение всех портов с высоким уровнем.

Верх страницы

Плюсы	Минусы
Более безопасный, чем динамический RPC — только один открытый высокий порт	Изменение реестра для всех серверов
	Злоумышленники могут использовать открытый порт после его идентификации

Этот сценарий обеспечивает большую безопасность, но требует внесения изменений в реестр всех контроллеров домена.Изменения реестра могут быть написаны с помощью таких инструментов, как REG.EXE, что помогает устранить ошибки конфигурации.

Вы должны выбрать фиксированные номера портов для репликации AD и службы репликации файлов SYSVOL (FRS или DFSR). Управление по присвоению номеров в Интернете (IANA) выделило диапазон от 49152 до 65535 для использования частными и динамическими назначениями.

Используя редактор реестра, перейдите к этому разделу реестра:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ NTDS \ Parameters \

Добавьте новое значение DWORD с именем TCP / IP Port (включая пробел).Установите данные значения на номер порта, который вы хотите использовать (не забудьте изменить отображаемое основание на десятичное, прежде чем вводить данные). Установите исправление, доступное в MSKB 2827870
если вы реализуете этот параметр реестра на контроллерах домена Windows Server 2008 R2.

Для службы репликации файлов перейдите к этому разделу реестра:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ NTFRS \ Parameters \

Добавьте новое значение DWORD с именем RPC TCP / IP Port Assignment (включая пробелы).Установите данные значения на номер порта, который вы хотите использовать (не забудьте изменить отображаемое основание на десятичное, прежде чем вводить данные).

Служба репликации распределенных файловых служб включает средство командной строки Dfsrdiag.exe. Dfsrdiag.exe может установить порт RPC сервера, который используется для администрирования и репликации. Чтобы использовать Dfsrdiag.exe для установки порта RPC сервера, выполните следующие действия.
этот пример:

dfsrdiag StaticRPC / порт: nnnnn / участник: Branch01.sales.contoso.com

В этом примере nnnnn представляет один статический порт RPC, который DFSR будет использовать для репликации.
Branch01.sales.contoso.com представляет DNS или NetBIOS-имя целевого компьютера-члена. Если участник не указан, Dfsrdiag.exe использует локальный компьютер.

Сделайте это на всех своих серверах Active Directory. В Windows 2000 и 2003 вам необходимо перезагрузить сервер, чтобы активировать настройку NTDS. В Windows 2008 и новее достаточно перезапустить «Доменные службы Active Directory».Это также перезапустит NTFRS
используется для SYSVOL. Вам по-прежнему необходимо вручную перезапустить службу «Репликация DFS».

Теперь настройте брандмауэр, чтобы разрешить следующее:

Сервис	Порт / протокол
Устройство сопоставления конечных точек RPC	135 / TCP, 135 / UDP
Служба имен NetBIOS	137 / tcp, 137 / udp
Служба дейтаграмм NetBIOS	138 / UDP
Служба сеансов NetBIOS	139 / tcp
Статический порт RPC для репликации AD	<фиксированный порт AD> / TCP
Статический порт RPC для FRS или	<фиксированный порт FRS> / TCP
Статический порт RPC для репликации DFS	<фиксированный-порт DFSR> / TCP
SMB через IP (Microsoft-DS)	445 / TCP, 445 / UDP
LDAP	389 / tcp
Пинг LDAP	389 / UDP
LDAP через SSL	636 / tcp
Глобальный каталог LDAP	3268 / TCP
Глобальный каталог LDAP через SSL	3269 / TCP
Kerberos	88 / TCP, 88 / UDP
DNS	53 / TCP, 53 / UDP

Замените , и / TCP на номера портов, которые вы использовали в значениях реестра.

Как и раньше, если вы не хотите разрешать DNS или WINS, вы можете использовать HOSTS (для DNS) и
LMHOSTS (для WINS) файлов для разрешения имен. Эти файлы хранятся в
% SystemRoot% \ system32 \ drivers \ etc . Загляните в файлы, чтобы узнать, как их использовать.

Вам все еще нужен сопоставитель конечных точек, потому что клиенты не будут знать, что вы исправили порты. Средство сопоставления конечных точек всегда возвращает фиксированные порты, когда клиенты запрашивают номера портов, связанные с UUID RPC AD и FRS.

Вы должны выбрать порт для служб RPC AD и FRS, в котором нет стандартного распределения портов стеком TCP / IP и который не является обычно используемым портом. Для Windows 2008 и новее выберите диапазон ниже 49152 и создайте список, содержащий порты и службу.
они назначаются (порт сервера AD, порт FRS, порт DFS-R, порт X службы приложений,…). У ваших специалистов по сетевой безопасности может уже быть такой список, поэтому попросите их внести в него нужные вам порты. Например, они дают вам порты 34223, 34224 и 34225.
(в шестнадцатеричном формате 85AF, 85B0 и 85B1).Затем создайте reg-файл из этого текста:

 Редактор реестра Windows версии 5.00

 [HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ NTDS \ Parameters]

 «Порт TCP / IP» = dword: 000085AF

 [HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ NTFRS \ Parameters]

 «Назначение порта RPC TCP / IP» = двойное слово: 000085B0

————————

И используйте: «dfsrdiag StaticRPC / port: 34225 / Member: Branch01.sales.contoso.com Начало страницы

Плюсы	Минусы
Более безопасный, чем динамический RPC — только один открытый высокий порт	Время запроса клиента может вызывать спорадические ошибки
Только интерфейсы, разрешенные администратором межсетевого экрана, проходят через межсетевой экран

Доступен новый класс межсетевых экранов, в которых администраторы могут указать интерфейсы RPC, разрешенные в сети.Брандмауэр будет отслеживать запросы и ответы сопоставителя конечных точек RPC. Когда запрос успешен и интерфейс разрешен,
он создаст запись в таблице известных серверов RPC и разрешит сеанс RPC и запросы привязки, которые должны выполняться за доли секунды.

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

Вам все еще нужно открыть несколько известных портов:

Сервис	Порт / протокол
Устройство сопоставления конечных точек RPC	135 / TCP, 135 / UDP
Служба имен NetBIOS	137 / tcp, 137 / udp
Служба дейтаграмм NetBIOS	138 / UDP
Служба сеансов NetBIOS	139 / tcp
SMB через IP (Microsoft-DS)	445 / TCP, 445 / UDP
LDAP	389 / tcp
Пинг LDAP	389 / UDP
LDAP через SSL	636 / tcp
Глобальный каталог LDAP	3268 / TCP
Глобальный каталог LDAP через SSL	3269 / TCP
Kerberos	88 / TCP, 88 / UDP
DNS	53 / TCP, 53 / UDP

Список интерфейсов RPC, используемых Active Directory:

Имя	UUID	Общее название
MS NT Directory Интерфейс DRS	e3514235-4b06-11d1-ab04-00c04fc2dcd2	Репликация AD
MS NT Directory Интерфейс NSP	f5cc5a18-4264-101a-8c59-08002b2f8426	Адресная книга Outlook, дополнительно
LSA RPC	12345778-1234-abcd-ef00-0123456789ab	Местная служба безопасности
Вход в сеть	12345678-1234-abcd-ef00-01234567cffb	Удаленный вход
ЗУР RPC	12345778-1234-abcd-ef00-0123456789ac	Менеджер учетных записей безопасности
Интерфейс резервного копирования NTDS	ecec0d70-a603-11d0-96b1-00a0c91ece30	Резервное копирование AD, дополнительно
Интерфейс восстановления NTDS	16e0cf3a-a604-11d0-96b1-00a0c91ece30	AD Restore, опционально
Служба репликации файлов	f5cc59b4-4264-101a-8c59-08002b2f8426	Репликация FRS
API репликации файлов	d049b186-814f-11d1-9a3c-00c04fc9b232	Администрация ФРС
Служба репликации DFS	897e2e5f-93f3-4376-9c9c-fd2277495c27	Интерфейс DFS-R

Вы можете комбинировать этот подход с «Ограниченным RPC».С помощью этой комбинации вы можете регулярно менять порт сервера для дополнительной защиты без необходимости перенастраивать брандмауэры.

Начало страницы

Плюсы	Минусы
Обеспечивает лучшую безопасность межсетевого экрана	Настройка политики IPSec на всех серверах
Индивидуальные полисы, при необходимости	Ваша группа администраторов брандмауэра может не очень любить туннели
Хорошая причина для начала развертывания инфраструктуры открытого ключа (PKI), при желании

IPSec позволяет легко инкапсулировать и передавать RPC-трафик через межсетевой экран.Помимо упрощения транспорта RPC, IPSec также повышает безопасность между контроллерами домена благодаря функции взаимной аутентификации IPSec: с помощью Kerberos или компьютера.
сертификаты, DC будут «знать», с кем они общаются, прежде чем произойдет какой-либо фактический обмен информацией.

В этом документе показано, как создать соответствующую политику IPSec с помощью интерфейса консоли управления Microsoft (MMC). Вы можете создать сценарий создания политики с помощью
IPSECPOL.EXE , инструмент, доступный в Windows 2000 Resource Kit.Обязательно внимательно прочтите и поймите
IPSECPOL.EXE документация перед тем, как вы попытаетесь использовать его — в отличие от графического интерфейса, инструмент командной строки имеет очень мало встроенной проверки согласованности.

Перед тем как начать, вы должны принять одно решение — использовать ли сертификаты для проверки подлинности IPSec или встроенный Kerberos для Windows 2000. Проверка подлинности Kerberos требует, чтобы оба компьютера уже находились в одном домене, поэтому, если вы предпочитаете Kerberos,
тогда вы должны использовать что-то отличное от IPSec для этапа повышения уровня контроллера домена (DCPROMO) (поскольку целевой сервер еще не является членом домена).Туннели двухточечного туннельного протокола (PPTP) хорошо подходят для этого и описаны здесь. Если
вместо этого вы хотите использовать сертификаты для аутентификации, вы должны получить сертификат для каждого DC, который будет участвовать в репликации IPSec. Посмотри пожалуйста

http://www.microsoft.com/windows2000/library/ для документов, описывающих, как создать центр сертификации Windows 2000 и как настроить свой домен для автоматической регистрации сертификатов компьютеров.

Для репликации IPSec и продвижения IPSec или PPTP настройте брандмауэр, чтобы разрешить следующее:

Сервис	Порт / протокол
DNS	53 / TCP, 53 / UDP
Установление PPTP (при использовании PPTP)	1723 / tcp
GRE, инкапсуляция общей маршрутизации (при использовании PPTP)	IP-протокол 47
Kerberos	88 / TCP, 88 / UDP
IKE, обмен ключами в Интернете	500 / UDP
IPSec ESP, инкапсулированная полезная нагрузка безопасности	IP протокол 50
IPSec AH, аутентифицированный заголовок	IP-протокол 51

1	Если вы решите использовать сертификаты для аутентификации IPSec вместо Kerberos, вы можете настроить серверы для передачи трафика Kerberos внутри IPSec.Это будет рассмотрено более подробно позже. Независимо от режима проверки подлинности Kerberos между контроллерами домена по-прежнему требуется.

Обратите внимание, что IPSec не будет работать через устройства преобразования сетевых адресов (NAT). Поскольку IPSec использует IP-адреса при вычислении контрольных сумм пакетов, пакеты IPSec, адреса источника которых были изменены NAT, отбрасываются, когда они прибывают в пункт назначения.
В Windows XP и Windows 2003 поддерживается NAT-T. Ссылаться на
KB885348 за важное примечание по использованию.

Верх страницы

Если вы решили использовать туннели PPTP для фазы продвижения, вы должны настроить маршрутизацию и удаленный доступ (RRAS) во внутренней сети. RRAS может работать как на внутреннем контроллере домена, так и на отдельном сервере. Для простоты лучше, чтобы RRAS
Сервер находится в той же подсети, что и корневой контроллер домена, поэтому обслуживание статического маршрута не требуется.

Для настройки RRAS:

Выбрать Пуск | Программы | Инструменты администрирования | Маршрутизация и удаленный доступ .
Щелкните правой кнопкой мыши свой сервер на левой панели и выберите Настроить и включить маршрутизацию и удаленный доступ . Запустится мастер установки RRAS.
Щелкните Сервер, настроенный вручную .
Рисунок 1: Мастер маршрутизации и удаленного доступа
Завершите работу мастера и запустите службу при появлении соответствующего запроса.

Теперь MMC должна выглядеть следующим образом после нажатия на + рядом с именем сервера.

Рисунок 2: RRAS после настройки и включения

После настройки и включения RRAS внесите следующие изменения:

Щелкните сервер правой кнопкой мыши и выберите Свойства . Щелкните значок
IP табл. Щелкните Пул статических адресов . Введите диапазон IP-адресов в той же подсети, что и ваш внутренний контроллер домена. Требуется всего несколько — возможно, 9 — адресов. Закройте все диалоговые окна.
Рисунок 3: Свойства сервера , назначение IP-адреса
Щелкните правой кнопкой мыши Порты (на левой панели MMC), а затем щелкните
Недвижимость .Настройте Direct parallel так, чтобы не разрешались ни удаленный доступ, ни соединения по требованию; если у вас есть модемы на сервере (как в примере ниже), настройте их аналогичным образом. Настроить
Набор номера по требованию (L2TP) , чтобы не было портов и не было разрешено ни удаленного доступа, ни подключения вызова по требованию. Вам не нужно вносить никаких изменений в
Набор номера по требованию (PPTP) , если вам не нужно более пяти портов. Закройте все диалоговые окна.
Рисунок 4: Свойства портов

RRAS теперь готов принимать входящие PPTP-соединения для повышения уровня контроллера домена.

Перед повышением уровня сети периметра или внешнего сервера до контроллера домена, установите туннель PPTP к внутреннему серверу RRAS. Открыть
Properties page из My Network Places и щелкните
Установить новое соединение . В мастере:

Щелкните Подключитесь к частной сети через Интернет .
Не набирать начальное соединение.
Введите IP-адрес внутреннего сервера RRAS в качестве места назначения.
Установите доступность подключения на Для всех пользователей .
Не делить соединение.
Назовите соединение как хотите.

Затем открывается соединение. Перед подключением нажмите кнопку Properties . Щелкните значок
Вкладка «Параметры » и нажмите « Включить домен входа в Windows ». Закройте диалоговое окно.

Теперь войдите на сервер RRAS, используя учетные данные администратора предприятия (администратора корневого домена).После того, как сервер завершит соединение, вы можете запустить DCPROMO. DCPROMO требует перезагрузки в конце процесса; это также отключит
туннель PPTP. Поскольку вам больше не нужен туннель, вы можете удалить соединение.

Верх страницы

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

Вы не хотите использовать PPTP для продвижения.
Вы предпочитаете не разрешать Kerberos через брандмауэр.
Вы ищете причину для начала развертывания PKI.

Вы должны установить сертификаты на контроллеры домена, чтобы они могли выполнять аутентификацию IPSec. Все сертификаты требуют подписей из одного центра сертификации. Windows 2000 включает сертификат запроса комментариев (совместимый с RFC).
авторитет (CA), который очень хорошо работает в этом случае. С помощью групповых политик вы можете настроить свой домен для автоматической регистрации рядовых компьютеров с сертификатами компьютеров. Хотя IPSec будет работать с сертификатами от любого центра сертификации, для автоматической регистрации требуется
2000 г.Если у вас уже есть PKI, Windows 2000 CA может быть настроен как подчиненный, выдав CA. Пожалуйста, смотрите документацию, включая пошаговые руководства, упомянутые ранее, для получения более подробной информации.

Если вы решите пойти по этому маршруту, у вас также есть возможность включить трафик Kerberos в IPSec. Обычно определенные виды трафика не обрабатываются в транспортном режиме IPSec:

Широковещательная рассылка — не может быть классифицирована фильтрами IPSec, поскольку отправитель не знает всех получателей.
Многоадресная передача — то же, что и широковещательная рассылка.
Протокол резервирования ресурсов (RSVP), IP-протокол 46 — должен быть исключен, чтобы иметь место маркировка качества обслуживания; однако пакеты IPSec могут передаваться внутри пакетов RSVP.
Обмен ключами в Интернете (IKE) — IPSec использует IKE для установки параметров безопасности и выполнения обмена ключами. При необходимости согласования IKE уже зашифрованы.
Kerberos — собственный протокол аутентификации Windows 2000, который также используется IPSec для аутентификации компьютера.Сам Kerberos уже защищен.

Несмотря на то, что фильтр IPSec может указывать, что весь трафик от одного компьютера к другому должен быть инкапсулирован, предыдущие виды трафика не обрабатываются IPSec.

Windows 2000 Service Pack 1 содержит раздел реестра, который несколько изменяет это поведение. Используя редактор реестра, перейдите к:

HKEY_LOCAL_MACHINE

СИСТЕМА \

CurrentControlSet \

Услуги \

IPSEC \

Добавьте новое двойное слово (DWORD) с именем NoDefaultExempt и установите значение 1.Допускаются следующие значения:

0: применяются исключения по умолчанию

1: Kerberos и RSVP включены в обработку IPSec

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

Вот текст, который вы можете импортировать в реестр. Он установит
NoDefaultExempt значение 1. Скопируйте его в буфер обмена, вставьте в пустой экран Блокнота, сохраните файл с
.REG , а затем дважды щелкните этот файл в проводнике Windows.

 Редактор реестра Windows версии 5.00
[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ IPSEC]
"NoDefaultExempt" = двойное слово: 00000001

Прежде чем продолжить, убедитесь в этом.I Если вы решите следовать этому подходу, вы также должны выполнить все шаги, описанные в следующем разделе «Настройка транспортного режима IPSec для связи DC-to-DC»,
С до вы запускаете DCPROMO. Вот заказ:

Если вы хотите включить Kerberos в обработку IPSec, добавьте предыдущий раздел реестра.
Установите центр сертификации.
Получите сертификаты компьютеров для всех существующих контроллеров домена и всех возможных контроллеров домена.
Выполните действия, описанные в разделе «Настройка транспортного режима IPSec для связи DC-to-DC».
Запустите DCPROMO на возможных контроллерах домена.
Все готово — оставьте все на месте; текущая репликация происходит поверх существующей конфигурации IPSec.

К началу страницы

Вот различия между двумя методами, представленными ранее.

Туннели PPTP

Просто и быстро.
Требуется межсетевой экран для разрешения Kerberos.
Требуется межсетевой экран для разрешения PPTP.
Разделяет функции продвижения и репликации — настройте PPTP для продвижения, а затем настройте IPSec для текущей репликации.

IPSec с сертификатами машины

Предоставляет веские основания для развертывания PKI.
Позволяет включить Kerberos в обработку IPSec.
Меньше протоколов через брандмауэр — без PPTP, возможно, без Kerberos.
Один шаг для продвижения и непрерывной репликации.

Хотя ни один из методов не является предпочтительным по сравнению с другим, использование IPSec с сертификатами машины, вероятно, является более «дальновидным» подходом, особенно потому, что большинство организаций планируют развертывать какие-либо PKI.

Верх страницы

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

На каждом контроллере домена необходимо создать политику IPSec для репликации, а также соответствующий список фильтров IP и действие фильтра. Выбрать
Старт | Программы | Инструменты администрирования | Локальная политика безопасности .

Рисунок 5: Локальные настройки безопасности

Затем щелкните IP Security Policies on Local Machine (на левой панели MMC).Это отображает политики по умолчанию, в которые вы добавите новую для репликации. Однако сначала вы должны создать список фильтров и действие.

Список фильтров указывает, какие IP-адреса, порты и протоколы запускают применение IPSec. Вы хотите защитить весь трафик только между контроллерами домена, а не трафик между контроллером домена и каким-либо другим компьютером. Щелкните правой кнопкой мыши
в правой панели MMC и щелкните Управление списками IP-фильтров и действиями фильтров .Вы будете на
Управление списками IP-фильтров Вкладка . Список фильтров — это просто список фильтров;
вы создадите фильтр для каждого сервера, с которым он реплицируется. То есть требуется только один список фильтров, и этот список содержит фильтры для всех контроллеров домена.

Рисунок 6: Списки IP-фильтров и действия фильтров, вкладка «Списки фильтров»

Нажмите кнопку Добавить , чтобы создать новый список фильтров. Назовите список фильтров
Репликация DC .Нажмите кнопку Добавить , чтобы создать новый фильтр; выполните следующие действия, чтобы завершить работу мастера:

Выберите Мой IP-адрес в качестве адреса источника.
Выберите Определенный IP-адрес в качестве адреса назначения, а затем введите IP-адрес другого сервера.
Выберите Any в качестве типа протокола. Это настраивает фильтр так, что весь трафик между двумя компьютерами будет проходить внутри IPSec2.

Рисунок 7: Список фильтров репликации контроллера домена

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

Затем вы хотите определить действие фильтра. Щелкните вкладку Управление действиями фильтра , а затем щелкните значок
Добавьте кнопку , чтобы создать новое действие. В мастере:

Назовите действие Репликация контроллера домена .
Щелкните Согласовать безопасность .
Щелкните Не взаимодействуйте с компьютерами, которые не поддерживают IPSec .
Щелкните High (Encapsulated Secure Payload) .
Установите флажок Редактировать свойства (вам потребуется внести изменения позже).
Нажмите кнопку Готово .

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

Рисунок 8: Действие фильтра репликации контроллера домена

Теперь вы готовы создать политику IPSec. Щелкните правой кнопкой мыши на правой панели MMC и выберите
Создать политику IP-безопасности . В мастере:

Назовите политику Репликация контроллера домена .
Очистить Активировать правило ответа по умолчанию .
Убедитесь, что установлен флажок Изменить свойства и закройте мастер.

Политика существует, но не содержит правил.

Рисунок 9: Политика IPSec репликации контроллера домена

Вы создаете правило, связывая список фильтров и действие фильтра, которое вы создали ранее. Щелкните значок
Добавьте кнопку , чтобы определить новое правило. В мастере:

Ваша политика теперь будет выглядеть следующим образом (в столбце аутентификации будет указано «Сертификат», если вы выбрали этот метод).

Рисунок 10: Завершенная политика репликации контроллера домена

Наконец, вам нужно включить, то есть назначить политику.

Щелкните правой кнопкой мыши политику репликации контроллера домена .
Щелкните Назначить .

Рисунок 11: Назначение политики контроллера домена

Обработка IPSec происходит немедленно. Перезагружать сервер не нужно.

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

Тестирование политики IPSec. Обязательно протестируйте созданные вами политики. После того, как вы создали и назначили политику как минимум на двух машинах, вы можете использовать утилиту IPSECMON.EXE, чтобы наблюдать, когда машины устанавливают безопасность IPSec.
ассоциация:

Открыть командное окно.
Введите команду ipsecmon . Запустится графическая утилита, в которой будут перечислены текущие сопоставления безопасности и сколько аутентифицированного и / или зашифрованного трафика прошло через сервер. (Если DC не начали обмениваться информацией, там
вероятно, сейчас не будет никаких системных администраторов.)
Нажмите кнопку Options и измените частоту обновления на одну секунду.
Вернитесь в командную строку и проверьте связь с другим контроллером домена, который также имеет политику IPSec.Использовать
-t — флаг для непрерывного пинга до остановки ( ping -t
ip-адрес ).
Найдите несколько ответов «Согласование безопасности IP» — машины обмениваются криптографическими ключами и создают свои ассоциации безопасности. Наконец, вы увидите нормальные ответы. Установление сопоставлений безопасности в обоих устройствах может занять от 10 до 12 секунд.
направления.
Нажмите CTRL + C, чтобы остановить.

К началу страницы

Для сетей, поддерживающих электронную торговлю и подключения к экстранетам, может потребоваться контроллер домена в сети периметра.Хотя сначала может показаться, что это создает проблемы с безопасностью, IPSec здесь тоже может помочь. Возможно создание мелкозернистого пакета
фильтрует с помощью функций разрешения / блокировки правил IPSec. См. Документ «Использование IPSec для блокировки сервера» по адресу

http://www.microsoft.com/technet/itsolutions/network/security/ipsecld.mspx. Вы можете объединить этот подход с приведенной здесь информацией, чтобы создать политику IPSec, которая разрешает только безопасную связь DC-to-DC и блокирует доступ всего остального трафика
DC в сети периметра.

Верх страницы

Хотя, вероятно, это и не предполагалось разработчиками IPSec, этот протокол стал отличным методом инкапсуляции сложного трафика, чтобы его можно было безопасно передавать между сетями. Механизм политики IPSec Windows 2000 может использоваться для создания очень детализированных
правила, определяющие разрешенный, заблокированный или защищенный трафик между узлами. В представленном здесь сценарии мы используем его для защиты всего трафика между известными узлами — конкретными контроллерами домена — при разрешении другого трафика к этим узлам и от них.

Для получения дополнительной информации о Windows 2000 IPSec и других функциях безопасности Windows 2000, пожалуйста, начните свое приключение на

http://www.microsoft.com/technet/security/default.mspx.

Верх страницы


1	В этом документе не обсуждается использование предварительных ключей. Аутентификация с предварительным общим ключом включена в Windows 2000 только для совместимости с другими реализациями IPSec и соответствия RFC IPSec.Ни в коем случае мы не поощряем использование предварительных ключей в производственной среде из-за неотъемлемых рисков безопасности, связанных с аутентификацией в стиле общего секрета.
2	То есть весь трафик, кроме того, который освобожден от обработки IPSec, как обсуждалось ранее.

Эта статья также доступна на следующих языках:

Апрель 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Репликация контроллеров домена: Управление репликацией Active Directory | Windows для системных администраторов

Управление репликацией Active Directory | Windows для системных администраторов

Repadmin и проверка репликации Active Directory

Что такое Repadmin?

Как установить Repadmin?

Требования для использования Repadmin

Основные ключи Repadmin

Дополнительные параметры

Просмотр общего состояния репликации

Просмотр топологии репликации и ошибки

Просмотр очереди репликации

Принудительная проверка топологии репликации

Как принудительно запустить репликацию Active Directory

Экспорт результатов в текстовый файл

Как посмотреть количество изменений атрибутов

Как посмотреть время последней резервной копирования Active Directory

Как посмотреть RPC-вызовы, на которые еще не ответили

Как посмотреть топологию репликации

Как сгенерировать топологию сайтов Active Directory

Репликация Active Directory. Часть 2

Репликация Active Directory: Разговор на «Ты» (Продолжение)

О некоторых нюансах настройки межсайтовой репликации AD или «Не все статьи от Microsoft одинаково полезны»

Репликация Active Directory. Часть 1

Репликация Active Directory: Разговор на «Ты»

Диагностика репликации AD | Windows IT Pro/RE

Диагностика состояния контроллера домена и репликаций Active Directory – gotoADM.ru

Как работает репликация Active Directory — статьи TechNet — США (английский)

Объектная модель

Репликация с несколькими мастерами

Объекты подключения

Сайтов

Внутрисайтовая репликация

Межсайтовая репликация

Транспорты репликации

Принудительная репликация всех контроллеров домена на всех сайтах одновременно — SID-500.COM

Принудительная репликация всех контроллеров домена на всех сайтах

См. Также

Опубликовано Патрик Грюнауэр

Как проверить репликацию Active Directory

Как установить Repadmin

Примеры Repadmin

Пример 1: Отображение меню справки repadmin

Пример 2: Суммируйте состояние репликации и просмотрите общее состояние

Пример 3: Показать партнера репликации и статус

Пример 4: Показать партнера репликации для определенного контроллера домена

Пример 5: Показать только ошибки репликации

Пример 6: Показать очередь репликации

, пример 7: принудительная репликация Active Directory

Пример 8: Экспорт результатов в текстовый файл

Другие примеры

Найдите время последнего резервного копирования вашего DC

Отображает вызовы, на которые еще не ответили

Список информации о топологии

Отчет генератора межсайтовой топологии

Заключение

Репликация Active Directory через брандмауэры — статьи TechNet — США (английский)

Туннели PPTP

IPSec с сертификатами машины

Добавить комментарий Отменить ответ