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

    logoОдна из главных рекомендаций 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 Хозяин Схемы, на все оставшиеся контроллеры домена. (Впоследствии оставшиеся контроллеры домена реплицируют информацию своим репликационным партнерам, но источником обновления в  этой цепочке репликации всегда будет Хозяин схемы)

    image

    Рис. 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.

    image

    Рис. 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 справится с задачей, существует способ ее поторопить.

    image

    Рис. 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 всегда пытается создать кольцо репликации, причем по мере добавления новых контроллеров кольцо будет расширяться. Расширение не бесконечно, при создании связей существует «правило трех прыжков». Это значит, что между двумя контроллерами домена при репликации не может быть больше трех посредников.

    image

    Рис. 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. В зависимости от режима работы леса список событий может меняться.

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

    image

    Рис. 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».

    image

    Рис. 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-Name\DC2 @ USN 16667 @ Time 2009-09-21 01:24:15

    Default-First-Site-Name\DC1 @ USN 20704 @ Time 2009-09-21 01:31:25

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

    image

    Рис. 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.

     

    image

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

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

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

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

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

    image

    Рис. 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 произведен на контроллере домена, который был автором изменений. Если выполнить тоже самое на втором контроллере, результат будет несколько другой.

    image

    Рис. 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 — пользователи и компьютеры» в расширенный режим.

    image

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

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

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

    image

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

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

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

     

    Илья Рудь

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

    http://kleontiv.spaces.live.com/

    Статья опубликована в журнале “Системный администратор” от 01.2010

    • Рубрика: Windows,Новое
    • Автор: Илья Рудь
    • Дата: Понедельник 25 Янв 2010

Комментарии

  1. Спасибо! Отличная статья, всплывают ньюансы, о которых мало что знал. С нетерпением жду продолжения 🙂

  2. Прочитав Марка Майнази и поэкспериментировав с repadmin, думал-тему знаю. Прочитав статью узнал много нового. Спасибо.

  3. А где продолжение цикла статей про установку контроллера домена?

  4. Еще раз повторюсь, то статьи Карманова и посему о их судьбе мне ничего не известно.

  5. Спасибо, интересная статья. Только вы пишете, что KCC не создает полносвязной топологии репликации, по меньшей мере, в рамках одного сайта. А на мой взгляд, как раз таки мы имеем дело с полносвязной топологией, т.е. каждый_с_каждым. Например, не так давно видел четыре DC в одном сайте, и каждый из них соединен с тремя другими автоматически созданными линками.

  6. P.Masalkin видеть вы это могли, но «by design» работает, так как описанно выше.

    P.S Спасибо, коллеги, вторая часть готова, но прочитаете вы ее на сайте через месяц.

  7. Может быть, мне не доводилось лично устанавливать более двух DC в одном сайте, хотя, имхо, KCC создаст именно полносвязную топологию. Вставлю еще свои пять копеек в пользу репликации на W2k8 и старше: репликацию выполняется служба DFSR, а не FSR

  8. Вы конечно можете остаться при своем мнении, но лучше установите более 2 DC и все сами увидите.

    Средствами DFSR и FSR реплицируется только папка SYSVOL, здесь разговор совершенной о другом.

  9. И еще немного, касаемо репликации членства в группах: в домене W2k минимальной единицей репликации являлся атрибут (то же «членство в группе», например), который при изменении реплицировался полностью. Соответственно, добавив 500-го пользователя в группу, администратор невольно генерировал значительный трафик репликации. В доменах W2k3 и старше реплицируются лишь отдельные изменения подобных атрибутов.

  10. Спасибо, Илья. Хорошая статья, особенно для новичков будет отличным пособием по AD.

    Добавлю от себя:

    «Некоторые изменения реплицируются без 15-секундной задержки. Такая репликация, называемая срочной (urgent replication). В события ее вызывающие входят блокировки учетных записей, изменение пароля учетной записи.»

    У кого-то может сложиться мнение, что если заблокировать пользователя, то изменения вступят немедленно. Так оно и есть, но это для DC. Если же пользователь уже получил свой билет у KDC для какой-то службы, то он сможет продолжить работу до тех пор, пока не истечет срок действия билета.

  11. Прошу заметить, что статья написанна в соавторстве, по этому спасибо можете задваивать)))) Я думаю Константин, рано или поздно закончит порабощение мира и почтит нас своим комментарием)))

  12. Константину тоже спасибо! 🙂

  13. Хорошая полезная статья, описывающая доступным человеческим языком нюансы. Огромное спасибо авторам. А Константина приятно не только читать, но и слушать (записи с платформы)

  14. Спасибо, хорошая статья.

  15. Спасибо авторам за отличную статью!

  16. Рад, что понравилась. Мы старались)

  17. Добрый день, коллеги!

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

    Теперь по комментариям:

    P.Masalkin, по поводу DFS-R Илья вам уже ответил и мы немного коснемся этой темы в будущих частях статьи. Но лишь поверхностно, т.к. работа DFS-R и DFS-N это отдельная большая тема и мешать ее с репликацией AD не совсем верное решение. Что касается топологии, Илья тут тоже прав, дело в том, что по алгоритму KCC строится ДВУСВЯЗНАЯ КОЛЬЦЕВАЯ топология с хордами через три прыжка. Однако надо не забывать, что вы устанавливаете контроллеры домена в сайте последовательно и нет ситуации когда топология сразу начинает строиться для скажем 7-10 контроллеров в сайте (где сразу будет видно логику работы KCC). Так вот уже созданные и работающие связи KCC не удаляет и не переделывает, а лишь дополняет. Только переставшие, по какой либо причине работать связи, KCC удаляет автоматически (но это можно отключить командой repadmin /siteoption). Поэтому может создастся впечатление, что строиться топология каждый с каждым. Попробуйте в сайте с 10 последовательно установленными контроллерами удалить ВСЕ связи репликации и запустить KCC — и вы убедитесь в верности того, о чем написано в нашей статье.

    По поводу членства в группах – да, для Windows 2000 верно, что атрибут членства в группах реплицируется как одно целое. Более того, действительно это может порождать большой объем трафика. Тут есть еще ряд интересных особенностей:

    1) Добавление/удаление одного члена в группе увеличивает признак версии атрибута Member на 1, это значит, что при разрешении конфликтов в первую очередь победит не самое последнее по времени изменение членства, а то, при котором было добавлено/удалено большее кол-во пользователей.

    2) Размер объекта в БД AD не может превышать одной страницы ESE, которая равна 8Kb с учетом служебных данных. Это означает, что в Windows 2000 членом одной группы не может быть более 5000 объектов (число дано примерно).

    3) При переходе/обновлении AD на уровень леса Windows Server 2003 членство в группах доставшихся от Windows 2000 по наследству сразу НЕ переходит на логику Linked Value Replication (LVR), а происходит в момент любого изменения членства в каждой конкретной группе. Это сделано для предотвращения лавинообразного трафика. Существует недокументированный способ, как произвести обновление всех достававшихся по наследству от Windows 2000 групп до функционала LVR.

    Баканов Д., замечание по поводу билета Kerberos верное, однако нужно его более четко ограничить. Действительно действующий билет TGS будет приниматься сервером до тех пор пока:

    1) Пользователь не разрушит свой действующий Access Token, в ассоциации с которым хранятся билеты TGS. Для этого достаточно сделать Log Off или командой klist.exe purge на рабочей станции пользователя удалить существующие билеты.

    2) Не поменять Long Term password того, сервера, куда пользователь уже получил билет TGS. Это можно сделать двумя способами: исключить и тут же включить компьютер в домен или сделать netdom reset.

    Так же надо помнить, что после блокировки учетной записи пользователя, новые билеты TGS контроллеры домена выдавать не будут. По умолчанию срок действия билета TGS 10 часов.

  18. «связанны» — айяйяй)

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

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

  21. Статья понравилась. Неясным мне остался момент описанный как Pull

    >процесс репликации ВСЕГДА происходит в режиме pull, т.е. «стягивания» >изменений и новых объектов, но не в режиме push.

    стягивание- имеется в виду скачивание (чтение)? Т.е. остальные контроллеры копируют изменения, а не контроллер где произошли изменения раздает их на остальные?

  22. volk1234, да именно так! Контроллер, на котором произошли изменения может только известить своих прартнеров по репликации (если посчитает необходимым), о том, что произошли изменения и на этом все — его миссия заканчивается... Партнеры уже сами решают, когда, что и как им «скачивать» с обновленного контроллера. Это так же значит, что все связи репликации (replication links или connection objects) однонаправленные и отвечают за передачу изменений в одну сторону. Т.е. для корректной взаимной (мульти-мастер) репликации нужны два «встречных» действующих connection object-а.

  23. А как происходит репликация м/у доменом и поддоменом? что м/у ними реплицруется?

  24. Между контроллерами разных доменов реплицируются разделы схема и конфигурация, т.к зона репликации этих разделов — Лес.

    + не стоит забывать о репликации GC. (т.е глобального каталога)

  25. azat, Илья Рудь, помимо Schema, Configuration, GC, есть еще контексты Application, которые реплицируются так как это задаст администратор, по умолчанию между доменами в лесу уровня 2003 и выше реплицируется контекст ForestDNSZones.

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

  26. Точно, про Application я запамятовал)

  27. Спасибо за интересную статью. После ее прочтения возник вопрос: можно ли получить с помощью repadmin или другой утилиты какие именно изменения произошли в AD в период роста highestcommittedusn с одного значения до другого?

  28. Константин подсказал, что можно сделать LDAP запрос по диапазону USNChanged.

  29. «Существует недокументированный способ, как произвести обновление всех достававшихся по наследству от Windows 2000 групп до функционала LVR.»

    Способ ф студию! 🙂

  30. Андрей, он же не документированный... Если я его в студию, он сразу станет документированным и будет неинтересно. 😉

  31. из всего выше сказанного я понял 5 — 10%...... и мне кажеться что вина тому — отсутствие практики в создании AD (личное ковыряние пыльцами, пробы, ошибки). За статью — спасибо! уверен, она поможет мне не спалить (разбомбить или выкинуть) мой компьютер... было бы здорово если бы вы написали на какой системе лучше создавать (держать, настраивать и обслуживать AD), уж очень хочеться разобраться...)) спасибо еще раз!

  32. Статья написана для тех, кто уже работал с AD DS. Вот поэтому и мало что поняли. Выберите ТЭГ — Active Directory, на сайте полно хороших статей по Active Directory начального уровня.

    >написали на какой системе лучше создавать

    ))) Что за вопрос ))) На Windows Server 2008 R2 )))

  33. Здравствуйте!

    А можно здесь задать личный вопрос?

    Начну из далека.

    Я не очень сильный специалист, поэтому сильно не пинайте если гдето чтото не правильно понимаю. Так вот:

    «перелопатил» я много информации, в голове каша и на основе этой каши сформировалось некое понятие о моей проблеме... наверное не очень правильное. Вобщем попорядку.

    Когдато был создан домен (ДМН) и в нем два контроллера домена (КД1 и КД2. Все Win 2000 server). КД1 был главным.

    В один прекрасный момент КД1 накрылся, кое-как его функции перетащили на КД2 и вот уже несколько лет это все работает без КД1 (Главный контроллер домена).

    Но настал день и захотелось всё обновить до WinServer2003.

    Был восстановслен КД1, даже не восстановлен, а просто переустановлена система на старом железе со старым именем и добавлен в домен как КД1. Вроде как все связи настроены... Изменения в Active Directory, сделанные на КД2 применяются на КД1 и наоборот, значит связь какая-то есть...

    при запуске: adprep /forestprep выдает следующее сообщение:

    Adprep was unable to extend the schema.

    [Status/Consequence]

    The schema master did not complete a replication cycle after the last reboot. The schema master must complete at least one replication cycle before the schema can be extended.

    [User Action]

    Verify that the schema master is connected to the network and can communicate with other domain controllers. Use the Sites and Services snap-in to replicate between the schema operations master and at least one replication partner. After replication has succeeded, run adprep again.

    Можно провести репликацию в ручную?

    Где-то прочитал, что «Схема» не реплицируется и отстается всегда на Хозяине, т.е. на старом КД1, который был убит, а на новом КД1 её уже не создать. Так ли это?

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

    Реально вообще такое?

    Вобщем заблудился я, в голове темный лес :о)

    P.S. В логах при перезагрузке есть сообщения:

    Event Viewer->File Replication Service:

    Event Type: Information

    Event Source: NtFrs

    Event Category: None

    Event ID: 13501

    Date: 26.03.2010

    Time: 13:46:51

    User: N/A

    Computer: SRV01

    Description:

    The File Replication Service is starting.

    =============================

    Event Type: Information

    Event Source: NtFrs

    Event Category: None

    Event ID: 13516

    Date: 26.03.2010

    Time: 13:47:20

    User: N/A

    Computer: SRV01

    Description:

    The File Replication Service is no longer preventing the computer SRV01 from becoming a domain controller. The system volume has been successfully initialized and the Netlogon service has been notified that the system volume is now ready to be shared as SYSVOL.

    Type «net share» to check for the SYSVOL share.

  34. Какой контроллер из действующих сейчас является схема мастером?

  35. Схема Мастер — КД1 (SRV01)

    Еще сделал dcdiag:

    все тесты нормальные кроме одного:

    Starting test: KnowsOfRoleHolders

    Warning: CN="NTDS Settings

    DEL:7ac63472-cb95-44f6-a10e-65256288fdae",CN=SRV01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=slantsy,DC=net is the Schema Owner, but is deleted.

    Warning: CN="NTDS Settings

    DEL:7ac63472-cb95-44f6-a10e-65256288fdae",CN=SRV01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=slantsy,DC=net is the Domain Owner, but is deleted.

    Видимо была удалена какая-то запись... мммда...

  36. Андрей (Шимкин), пауза по станиславскому выдержана.

    Вот собственно сам способ (описан косвено, но кто умеет читать между строк — поймет): blogs.dirteam.com/blogs/t... -membership.aspx

  37. Олег, вам вероятнее всего надо следать перехват роли схема-мастера (и судя по всему других ролей). Делается это командой netdom roles seize, однако одной из ошибок было поставить новый контроллер домена и назвать его КД1.

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

  38. >одной из ошибок было поставить новый контроллер домена и назвать его КД1.

    Как же надо было поступить?

    Я поначалу пробовал обновить на КД2, но он конечно тоже ругался.

    И в логах ошибки были на отсутствующий КД1...

    Ну я и решил, что запуск КД1 поможет, но увы...

    P.S. Захват роли — смысл понятен, но netdom roles seize такой команды не нашел.

    Извиняюсь за паузы...

  39. > Некоторые изменения реплицируются без 15-секундной задержки. Такая репликация, называемая срочной (urgent replication). В события ее вызывающие входят блокировки учетных записей, изменение пароля учетной записи

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

    technet.microsoft.com/en- ...r_repup_how_huzs

  40. Решил перечитать статьи по AD на ITband. Илья, Костя, спасибо, хорошая статья.

  41. Статья очень полезная огромное спасибо авторам! У меня возник такой вопрос: после команды Repadmin /syncall /AeS начнут звонить возмущенные пользователи и жаловаться на задержку связи, какой командой можно отложить или остановить репликацию. Заранее спасибо!

  42. repadmin /options +DISABLE_OUTBOUND_REPL

    Только не уверен, что повлияет на уже запущенную. Если будете проверять отпишитесь.

  43. Извините за поздний ответ но отписываться «нечем». Вопрос был продуман в результате освоения материала. Как появиться «возможность» обязательно проверю. 🙂

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

  45. Причина блокировки всегда одна — неправильный ввод пароля.

    Account Lockout Status — утилита для просмотра времени блокировки аккаунта и заблокировавшего контроллера. (goo.gl/riaMS)

  46. @45

    Просмотром Security Event Log на контроллере, выполняющем роль PDC Emulator.

  47. Спс. Классная статья. С вашего позволения, я ее у себя запостю (с линком на первоисточник, естественно).

    З.Ы. По поводу блокировки учетки я когда-то описал как в ивентах смотреть:

    www.rublin.org.ua/kido

  48. Добрый день, Илья.

    Прочитала вашу статью, и почерпнула массу новой информации. Но к сожалению не нашла ответа на свой главный вопрос. Если мы имеем дело со структурой, где в рамках одного сайта есть Центральный контроллер домена, он же глобальный каталог (global.com), и несколько териториально разнесенных контроллеров домена (filial1.global.com ... filialn.global.com) которые посредством vpn связаны с global.com но не связаны друг с другом. Служба KCC каким-то образом видит все эти филиалы и создает связи между некоторыми из них напрямую, но фактически репликация не происходит. В результате мы получаем массу ошибок репликации в журнал. Можно ли как-то решить этот вопрос не отключая службу KCC полностью?

  49. Можно. Прочитать вторую часть статьи itband.ru/2010/03/replication2/ и настроить сайты.

  50. Добрый день.

    Спасибо за статью! Как всегда достойно.

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

    Заранее спасибо за ответы!

  51. замечательная статья — спасибо автору

  52. Спасибо один раз прочитал и теперь частенько заглядываю сюда

  53. Спасибо. Отличная статья. Простая и понятная

  54. Да, статья весьма и весьма достойная. Авторам искреннее спасибо за труд! Изучаю статью и аккуратно применяю полученные знания на сервере.

  55. Автор...! Красавчик! 🙂 статья хороша.

  56. Отлично!!!

  57. Статья про так пользоваться repadmin, а в общем ни о чём. Можно было быть менее многословным.

  58. cat666, для баранов полно мануалов next-next-finish. Вы тут что забыли?)

Опубликовать

Я не робот.