Первичная синхронизация каталога active directory как сделать
Перейти к содержимому

Первичная синхронизация каталога active directory как сделать

  • автор:

Первичная синхронизация каталога active directory как сделать

Спасибо за быстрый ответ.

Так же скрин ipconfig.

Сообщение об ошибки появляется при загрузки сервера.

Сейчас попробую перезагрузить DNS и посмотреть, будет ошибка или нет.

Сервер DNS перезагружал, данная ошибка не появляется.

Она появляется только после перезагрузки сервера.

Зато появилась еще одна ошибка.

Не удалось установить связь DCOM с компьютером 195.54.192.39 через какой-либо из настроенных протоколов; запрос от PID 1bf8 (C:\Windows\system32\dcdiag.exe).

Не уверен есть связь или нет?

  • Изменено akamsp 1 декабря 2017 г. 8:54

Сервер DNS перезагружал, данная ошибка не появляется.

Она появляется только после перезагрузки сервера.

Зато появилась еще одна ошибка.

Не удалось установить связь DCOM с компьютером 195.54.192.39 через какой-либо из настроенных протоколов; запрос от PID 1bf8 (C:\Windows\system32\dcdiag.exe).

Не уверен есть связь или нет?

Спасибо.

Значит, ошибка у вас возникает вследствие каких-то временных сбоев при перезагрузке (к примеру, коммутатор Ethernet (управляемый физический или виртуальный), если на его порту не отключен STP, будет блокировать трафик 50 секунд после запуска драйвера сетевой карты). Если сервер DNS сам восстанавливает работоспособность по прошествии некоторого времени после перезагрузки (а на моей практике так бывало всегда в случае подобных ошибок, хотя и не сразу — с задержкой до получаса), то можно считать эту ошибку некритичной.

В противном случае (кроме, естественно, нахождения и устранения источника проблемы) можно, например, добавить задание, запускаемое при старте системы, которое после задержки перезапускает службу сервера DNS. Или же — изменить тип запуска службы сервера DNS на "Автоматически (отложенный запуск)".

Ошибка DCOM — это результат работы команды dcdiag /test:DNS: в процессе тестов она попыталась обратиться к некоему стороннему серверу (например, серверу пересылки) по RPC в предположении, что он — сервер, работающий под управлением MS Windows. Игнорируйте её.

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

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

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

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

Dns сервер ожидает от доменных служб active directory сигнала о том что первичная синхронизация

Dns сервер ожидает от доменных служб active directory сигнала о том что первичная синхронизация

Спасибо за быстрый ответ.

Так же скрин ipconfig.

Сообщение об ошибки появляется при загрузки сервера.

Сейчас попробую перезагрузить DNS и посмотреть, будет ошибка или нет.

Сервер DNS перезагружал, данная ошибка не появляется.

Она появляется только после перезагрузки сервера.

Зато появилась еще одна ошибка.

Не удалось установить связь DCOM с компьютером 195.54.192.39 через какой-либо из настроенных протоколов; запрос от PID 1bf8 (C:\Windows\system32\dcdiag.exe).

Не уверен есть связь или нет?

  • Изменено akamsp 1 декабря 2017 г. 8:54

Сервер DNS перезагружал, данная ошибка не появляется.

Она появляется только после перезагрузки сервера.

Зато появилась еще одна ошибка.

Не удалось установить связь DCOM с компьютером 195.54.192.39 через какой-либо из настроенных протоколов; запрос от PID 1bf8 (C:\Windows\system32\dcdiag.exe).

Не уверен есть связь или нет?

Спасибо.

Значит, ошибка у вас возникает вследствие каких-то временных сбоев при перезагрузке (к примеру, коммутатор Ethernet (управляемый физический или виртуальный), если на его порту не отключен STP, будет блокировать трафик 50 секунд после запуска драйвера сетевой карты). Если сервер DNS сам восстанавливает работоспособность по прошествии некоторого времени после перезагрузки (а на моей практике так бывало всегда в случае подобных ошибок, хотя и не сразу — с задержкой до получаса), то можно считать эту ошибку некритичной.

В противном случае (кроме, естественно, нахождения и устранения источника проблемы) можно, например, добавить задание, запускаемое при старте системы, которое после задержки перезапускает службу сервера DNS. Или же — изменить тип запуска службы сервера DNS на "Автоматически (отложенный запуск)".

Ошибка DCOM — это результат работы команды dcdiag /test:DNS: в процессе тестов она попыталась обратиться к некоему стороннему серверу (например, серверу пересылки) по RPC в предположении, что он — сервер, работающий под управлением MS Windows. Игнорируйте её.

Устранение неполадок DNS Event ID 4013 (DNS-сервер не мог загружать зоны DNS, интегрированные с AD)

В этой статье устраняется ИД события 4013, войдите в журнал событий DNS контроллеров доменов, которые после Windows будут размещены роли сервера DNS.

Применяется к: Windows Server 2012 R2
Исходный номер КБ: 2001093

Симптомы

На компьютере Windows, на который размещены контроллеры домена Active Directory, роли сервера DNS перестают отвечать на 15-25 минут. Эта проблема возникает после отображения сообщения о подготовке сетевых подключений и перед отображением Windows логотипа (Ctrl+Alt+Del).

Следующий DNS Event ID 4013 входит в журнал событий DNS контроллеров доменов, которые после начала Windows сервера DNS:

В этой записи журнала значения <%status% > не могут быть зарегистрированы. Или они включают, но не ограничиваются следующими значениями:

Примеры сценариев клиентов

Несколько контроллеров домена на сайте Active Directory, которые одновременно перезагружаются.

  • В том же центре обработки данных развернут домен контроллера с двумя доменами.
  • Роль сервера DNS установлена на обоих контроллерах домена, и в ней размещены встроенные в AD копии _msdcs.<forest root domain> и доменные зоны Active Directory.
  • DC1 настроен для использования DC2 для предпочтительной DNS и для альтернативной DNS.
  • DC2 настроена на использование DC1 для предпочтительной DNS и себя для альтернативной DNS.
  • Все контроллеры домена имеют бесперебойное питание (UPS) и резервные копии электрогенератора.
  • Центр обработки данных испытывает частые отключения электроэнергии от 2 до 10 часов. Устройства UPS держат контроллеры домена в работе до тех пор, пока генераторы не поставляют питание, но не могут запустить систему HVAC. Защита от температуры, встроенная в компьютеры класса сервера, закрывает контроллеры домена, когда внутренние температуры достигают пределов производителя.
  • Когда питание в конечном итоге восстановлено, контроллеры домена висят в течение 20 минут. Эта проблема возникает после отображения сетевых подключений и перед отображением запроса logon.
  • DNS Event ID 4013 входит в журнал событий DNS.

Открытие консоли управления DNS (DNSMGMT. MSC) сбой и создает следующее сообщение об ошибке:

Связаться с <computername> сервером не удалось. Ошибка была: сервер недоступен. Хотите добавить его в любом случае?

Открытие оснастки пользователей и компьютеров Active Directory (DSA). MSC) создает следующее сообщение об ошибке:

Сведения о именова-именах не могут быть расположены

Единые контроллеры домена на сайте Active Directory

Один контроллер домена развернут на сайте.

Установлена роль DNS Server, в ней размещены встроенные в AD копии _msdcs.<forest root domain> и доменные зоны Active Directory.

Контроллер домена указывает на себя для предпочтительного DNS.

Контроллер домена не имеет альтернативного DNS-сервера, указанного или указывает на контроллер домена по ссылке широкой сети (WAN).

Контроллер домена перезапущен из-за отключения электроэнергии.

Во время перезапуска может не работать ссылка WAN.

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

DNS Event ID 4013 входит в журнал событий DNS.

Открытие консоли управления DNS (DNSMGMT. MSC) сбой и создает следующее сообщение об ошибке:

Связаться с <computername> сервером не удалось. Ошибка была: сервер недоступен. Хотите добавить его в любом случае?

Открытие оснастки пользователей и компьютеров Active Directory (DSA). MSC) создает следующее сообщение об ошибке:

Сведения о именова-именах не могут быть расположены.

Причина

Копия Active Directory в некоторых контроллерах домена содержит ссылки на другие контроллеры домена в лесу. Эти контроллеры домена пытаются реплицировать все локальные разделы каталогов во время Windows запуска в рамках начальной синхронизации или синхронизации init.

В попытке загрузки с последним содержимым зоны DNS серверы Microsoft DNS, на которые встроены AD-копии зон DNS, задерживают запуск службы DNS на несколько минут после Windows запуска. Задержка не произойдет, если Active Directory выполнил первую синхронизацию во время Windows запуска. Тем временем Active Directory задерживается из-за входящие разделы репликации каталогов. Репликация отложена до тех пор, пока она не сможет разрешить GUID CNAME своего контроллера исходных доменов на IP-адрес на DNS-серверах, используемых контроллером домена назначения для разрешения имен. Длительность зависания при подготовке сетевых подключений зависит от количества локальных разделов каталогов, проживающих в копии Active Directory контроллера домена. Большинство контроллеров домена имеют по крайней мере следующие пять разделов:

  • схема
  • configuration
  • domain
  • раздел приложения DNS в лесу
  • раздел приложения DNS для всей области домена

И эти контроллеры домена могут испытывать задержку запуска на 15-20 минут. Наличие дополнительных разделов увеличивает задержку запуска.

DNS Event ID 4013 в журнале событий DNS указывает на задержку запуска службы DNS. Это происходит из-за того, что входящие репликации разделов Active Directory не происходили.

Несколько условий могут усугубить следующие проблемы:

  • медленное Windows запуска
  • ведение журнала событий DNS 4013 на DNS-серверах, настроенных для зоны, интегрированной с AD, которые неявно находятся на компьютерах, действующих в качестве контроллеров домена.

К этим условиям относятся следующие условия:

  • Настройка DNS-сервера, на который размещены зоны DNS, интегрированные с AD. Его копия Active Directory содержит знания других контроллеров домена в лесу, чтобы указать на себя исключительно для разрешения имен DNS.
  • Настройка DNS-сервера, на который размещены зоны DNS, интегрированные с AD. Его копия Active Directory содержит знания о других контроллерах домена в лесу, чтобы указать DNS-серверы, которые либо не существуют, в настоящее время находятся в автономном режиме, не доступны в сети, либо не содержат необходимые зоны и записи, необходимые для входящие репликации Active Directory. Примеры включают запись GUID контроллера домена CNAME и соответствующую запись A или AAAA потенциальных контроллеров домена источника.
  • Загрузка контроллера домена и DNS-сервера с зонами DNS, интегрированными с AD. Его копия Active Directory содержит знания других контроллеров домена о том, что является эффективной изолированной сетью, так как:
    • Сетевой адаптер или сетевой стек на вызываемом или целевом компьютере отключен или нефункционарен.
    • Контроллер домена загружается в изолированную сеть.
    • Копия Active Directory локального контроллера домена содержит ссылки на устаревшие контроллеры домена, которые больше не существуют в сети.
    • Копия Active Directory локального контроллера домена содержит ссылки на другие контроллеры домена, которые в настоящее время отключены.
    • Существует проблема в контроллере домена источника, контроллере домена назначения или DNS или сетевой инфраструктуре. Таким образом, копия Active Directory контроллера домена локального домена содержит ссылки на другие контроллеры домена, которые находятся в Интернете и доступны, но не могут быть успешно реплицированы из.

    В Windows Server 2003 и Windows 2000 Server SP3 или более поздней модели контроллеры домена, которые исполняют главные роли в операциях, также должны успешно реплицировать входящие изменения в раздел каталога, который поддерживает состояние роли магистрали операций. Перед выполнением операций, зависящих от FSMO, необходимо выполнить успешную репликацию. Такие начальные синхронизации были добавлены, чтобы убедиться, что контроллеры домена были в согласии с владением ролью FSMO и состоянием ролей. Начальные требования к синхронизации, необходимые для работы ролей FSMO, отличаются от начальной синхронизации, о которой говорится в этой статье, когда Active Directory должен входящие репликации, чтобы немедленно запустить службу DNS Server.

    Решение

    Некоторые microsoft и внешний контент рекомендовали Repl Perform Initial Synchronizations установить значение реестра до 0 , чтобы обойти начальные требования к синхронизации в Active Directory. Подкайка конкретного реестра и значения для этого параметра являются следующими:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
    Имя значения: Repl Perform Initial Synchronizations
    Тип значения: REG_DWORD
    Данные значения: 0

    Это изменение конфигурации не рекомендуется использовать в производственных средах или в любой среде на постоянной основе. Использование следует использовать Repl Perform Initial Synchronizations только в критических ситуациях для решения временных и конкретных проблем. Параметр по умолчанию должен быть восстановлен после решения таких проблем.

    Другие возможные варианты:

    Удалите ссылки на устаревшие контроллеры домена.

    Сделайте автономные или не функционируют контроллеры домена рабочими.

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

    Регистрация имен dNS и разрешение имен для контроллеров домена — это относительно легкая операция, которая очень кэшется клиентами и серверами DNS.

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

    Контроллеры домена hub-site должны указать на DNS-серверы на том же сайте, что и для предпочитаемого и альтернативного DNS-сервера, а затем в качестве другого альтернативного DNS-сервера.

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

    Указать на серверы DNS-узлового узла уменьшает количество переходов, необходимых для полной регистрации критически важных записей контроллера домена SRV и HOST. Контроллеры домена на сайте концентратора, как правило, получают наибольшее административное внимание, как правило, имеют самую большую коллекцию контроллеров домена на том же сайте. Поскольку они на одном сайте, происходят изменения репликации между собой:

    • каждые 15 секунд в Windows Server 2003 или более поздней
    • каждые пять минут в Windows 2000 Server

    Такое поведение делает такие записи DNS хорошо известными.

    Динамический контроллер домена SRV и регистрации записей A и AAAA не могут сделать его отключенным, если регистрируемый контроллер домена на сайте филиала не сможет реплицировать исходящий.

    Компьютеры и серверы-члены должны по-прежнему указать на оптимальные для сайта DNS-серверы в качестве предпочтительных DNS. Кроме того, они могут указать на серверы DNS вне сайта для дополнительной допуска неисправности.

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

    • Задержки репликации и сбои репликации
    • сбои оборудования, сбои программного обеспечения
    • операционные практики
    • кратковременные и долгосрочные отключения электроэнергии
    • пожар, кража, наводнение и землетрясения
    • террористические события

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

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

    Контроллеры домена должны указать на DNS-серверы, которые:

    • Доступны в Windows запуске.
    • Хост, вперед или делегирование _msdcs.<forest root domain> и основные зоны Суффикса DNS для текущих и потенциальных контроллеров домена.
    • Можно разрешить текущие записи GUID CNAME (например, dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com ) и хост-записи текущих и потенциальных контроллеров домена источника.

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

    Оптимизация контроллеров домена для отката разрешения имен.

    Неумело настраивать DNS правильно, чтобы контроллеры домена могли разрешать записи GUID домена CNAME для хозяйских записей в DNS. Для обеспечения конечной репликации разделов Active Directory Windows Server 2003 SP1 и более поздние контроллеры домена были изменены для выполнения отката разрешения имен:

    • от контроллера домена CNAME GUID до полноквалифицированного имени хост-кодов.
    • от полностью квалифицированного имени хост-имени до имени компьютера NetBIOS.

    В журналах событий службы каталогов репликация событий NTDS 2087 и 2088 указывают на то, что:

    • контроллер домена назначения не смог разрешить запись GUID GUID контроллера домена CNAME в хост-запись.
    • Происходит откат разрешения имен.

    Можно настроить файлы WINS, HOST и LMHOST. Так контроллеры домена назначения могут разрешить имена текущих и потенциальных контроллеров домена источника. Из трех решений использование WINS более масштабируемо, так как WINS поддерживает динамические обновления.

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

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

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

    1. Установите значение запуска службы DNS Server вручную.
    2. Перезагружайся, подождите, пока контроллер домена будет рекламироваться.
    3. Перезапустите службу DNS Server.

    Если значение запуска службы для службы DNS Server установлено вручную, Active Directory не ждет запуска службы DNS Server.

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

    Избегайте единичек сбоя.

    Примеры одиночных точек сбоя:

    • Настройка доменного тока для указать на IP-адрес сервера с одним DNS-сервером.
    • Размещение всех DNS-серверов на гостевом виртуальном компьютере на одном физическом хост-компьютере
    • Размещение всех DNS-серверов на одном физическом сайте
    • Ограничение сетевых подключений таким образом, что контроллеры домена назначения имеют только один сетевой путь для доступа к KDC или DNS Server

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

    Каждый сервер Microsoft DNS, работающий на современном оборудовании, может удовлетворять 10 000-20 000 клиентов на каждый сервер. Установка роли DNS на каждом контроллере домена может привести к чрезмерному числу DNS-серверов в вашем предприятии. И это увеличит затраты.

    Ошеломляйте перезагрузку DNS-серверов в вашем предприятии, когда это возможно.

    • Для установки некоторых хотфиксов, пакетов служб и приложений может потребоваться перезагрузка.
    • Некоторые клиенты перезагружают контроллеры домена по расписанию (каждые семь дней, каждые 30 дней).
    • Запланировать перезагрузку и установку программного обеспечения, требуемого для перезагрузки, с умом. Это необходимо для предотвращения одновременной перезагрузки только DNS-сервера или потенциального партнера репликации источника, на который указывает контроллер домена назначения для разрешения имен.

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

    Установка устройств UPS в стратегически важных местах для обеспечения доступности DNS во время кратковременных отключений электроэнергии.

    Уполномойте серверы DNS на основе UPS с помощью генераторов на месте.

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

    Дополнительные сведения

    Тестирование 10 мая 2010 г. командой разработчиков Active Directory:

    DNS ждет NTDS, и он не может начаться до завершения начальной репликации каталога. Это потому, что последние данные DNS еще не могут быть реплицированы на контроллер домена. С другой стороны, NTDS необходимо DNS для решения IP-адреса контроллера домена источника для репликации. Предположим, что DC1 указывает на DC2 в качестве DNS-сервера, а DC2 — на DC1 в качестве DNS-сервера. При одновременной перезагрузке DC1 и DC2 запуск будет медленным из-за этой взаимной зависимости. Основной причиной этого медленного запуска является DNSQueryTimeouts.

    Если служба DNS Server работает хорошо при запуске NTDS, NTDS принимает только два запроса DNS для решения IP-адреса контроллера домена источника:

    • один для IPv4
    • другой для IPv6

    И эти DNS-запросы возвращаются практически мгновенно.

    Если служба DNS Server недоступна при старте NTDS, NTDS необходимо отправить 10 запросов DNS для решения IP-адреса:

    • четыре для имени на основе GUID
    • четыре для полноквалифицированного имени
    • два для однометного имени

    Задержка для каждого запроса DNS контролируется DNSQueryTimeouts. По умолчанию для DNSQueryTimeouts установлено значение 1 1 2 4 4. Это означает, что клиент DNS будет ждать 12 (1 + 1 + 2 + 4 + 4) секунд для ответа сервера DNS. Каждый источник контекста именования занимает 120 секунд для решения IP-адреса. Предположим, что существует пять контекстов именования (Конфигурация, Схема, домен, ForestDnsZones, DomainDnsZones) и один источник репликации. В этом сценарии для завершения начальной репликации NTDS требуется 850 (170 X 5) секунд или более 14 минут.

    Для проверки вышеуказанного поведения было сделано несколько тестов.

    Перезагрузка контроллера домена, когда DNS-сервер является третьим контроллером домена, который находится в Интернете. Для каждого контекста именования каждого источника у нас есть два запроса DNS, и они завершались практически мгновенно:

    Перезагрузка DC1 и DC2 одновременно. DC1 использует DC2 для DNS DC2, а DC1 — для DNS. Для каждого контекста именования каждого источника у нас есть 10 запросов DNS и каждый запрос занимает около 12 секунд:

    Чтобы дополнительно изучить связь между DNSQueryTimeouts и медленным запуском, DNSQueryTimeouts были назначены 1 1 2 4 4 , чтобы клиент DNS ждал 31 (1 + 1 + 2 + 4 + 4) секунды. В этом тесте 31 секунда была потрачена на ожидание:

    Dns сервер ожидает от доменных служб active directory сигнала о том что первичная синхронизация

    Вопросом задался после попытки проверить:

    C:\>nslookup adr
    ╤хЁтхЁ: dc1.krcc.local
    Address: 10.24.30.51

    ╚ь*: adr.krcc.local
    Address: 10.24.30.101

    C:\>nslookup 10.24.30.101
    ╤хЁтхЁ: dc1.krcc.local
    Address: 10.24.30.51

    *** dc1.krcc.local не удалось найти 10.24.30.101: Non-existent domain

    При перезагрузке сервер 2008 R2 (AD+DNS+DHCP+WINS) выдает следующее в жуpнале DNS (других ошибок нет):

    Тип события: Предупреждение
    Источник события: DNS
    Категория события: Отсутствует
    Код события: 4013
    Дата: 29.09.2014
    Время: 18:27:52
    Пользователь: Н/Д
    Компьютер: dc1.krcc.local

    Описание:
    DNS-сервер ожидает от доменных служб Active Directory (AD DS) сигнала о том, что первичная синхронизация каталога завершена. Службу DNS-сервера невозможно запустить до завершения первичной синхронизации, так как критические данные DNS могут быть еще не реплицированными на этот контроллер домена. Если журнал событий AD DS показывает, что имеются проблемы с разрешением DNS-имен в адреса, рассмотрите возможность добавления IP-адреса другого DNS-сервера для этого домена в список DNS-серверов в свойствах протокола IP этого компьютера. Такое событие будет записываться в журнал каждые две минуты, пока служба AD DS не сообщит об успешном завершении первичной синхронизации.

    dcdiag /fix — проверки проходят по всем разделам (ошибок нет, кроме SystemLog — не критично ИМХО)

    Запуск проверки: SystemLog
    Возникло предупреждение. Код события (EventID): 0x800110F7
    Время создания: 09/30/2014 09:11:08
    Строка события: WINS-сервер обнаружил возможность повторной регистрации имени по адресу 10.24.30.121 для узла WK ( 10.24.30.24 ).
    Возникло предупреждение. Код события (EventID): 0x800110F7
    Время создания: 09/30/2014 09:34:26
    Строка события: WINS-сервер обнаружил возможность повторной регистрации имени по адресу 10.24.30.24 для узла WK ( 10.24.30.121 ).
    Возникло предупреждение. Код события (EventID): 0x800110F7
    Время создания: 09/30/2014 09:51:06
    Строка события: WINS-сервер обнаружил возможность повторной регистрации имени по адресу 10.24.30.121 для узла WK ( 10.24.30.24 ).
    . DC1 — не пройдена проверка SystemLog

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

    Мысль уже третий день ходит по-кругу — и выхода не видит. Подскажите как лечить или какие идеи будут?

    Первичная синхронизация каталога active directory как сделать

    Настройка синхронизации пользователей с Active Directory

    Настройки синхронизации пользователей с Active Directory в веб-интерфейсе представлены в разделе: «Настройки»/«Администрирование»/«Синхронизация пользователей».

    Раздел по умолчанию не содержит настроенных синхронизаций.

    При наличии настроенных синхронизаций они отображаются во вкладке Синхронизации в алфавитном порядке: сначала A-Z, потом А-Я. Пользователь может сортировать значения по названию синхронизации.

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

    Вкладка «Основное»

    На вкладке «Основное» представлены следующие параметры:

    1. Название;
    2. Протокол: при выборе LDAPS в интерфейсе появляется пункт Сертификаты;
    3. Сертификаты:
      • интеграция системы с AD поддерживает работу с хранилищем сертификатов ОС Windows. При наличии необходимых сертификатов в хранилище компьютера, где установлена система, загрузка файла сертификата на странице настройки не потребуется;
      • в ином случае загрузите на странице файл сертификата промежуточного или корневого удостоверяющего центра (CA), которым подписаны сертификаты, используемые контроллерами домена для LDAPS.
    4. Адрес домен контроллера (или имя домена);
    5. Логин (пользователя AD c правами на чтение каталога);
    6. Пароль (если пароль ранее не был задан);
    7. Кнопка Изменить пароль (если пароль ранее уже был задан);
    8. Тестировать подключение (выполняется пробное подключение к домену после сохранения изменений).

    Вкладка «Синхронизация»

    На странице представлены следующие параметры:

    • Автоматическая синхронизация (включение/отключение периодической синхронизации данных из AD. Периодичность – 15 минут);
    • Синхронизировать по полю в системе;
    • Синхронизировать по атрибуту в AD;
    • Отключать при отключении в AD (позволяет автоматически выключать пользователя в системе);
    • Включать при включении в AD (позволяет автоматически включать пользователя при включении его в AD. Данная опция работает только при включенной опции «Отключать при отключении в AD»); (включение данной опции позволяет обезличить данные пользователей, учетные записи которых были удалены из Active Directory);
    • Время синхронизации (скрыто, если синхронизация данных из AD не осуществлялась);
    • Синхронизировать сейчас (отправка запроса на моментальную синхронизацию данных).
    Первичное сопоставление атрибута

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

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

    Например: Пользователь синхронизировался из «Босс-кадровика», где в поле Табельный номер в профиле пользователя указано значение 1001. Функционалом первичной синхронизации сопоставляется значение атрибута из AD со значением поля в профиле пользователя. Если значения совпадают, в данном примере равны 1001, то новый пользователь не создаётся.

    Вкладка «Доменные объекты»

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

    Доменный объект вводится в формате Distinguished Name (пример: OU=UnitName,OU=Users,OU=Root,DC=some,DC=domain,DC=com). В качестве объекта синхронизации могут быть использованы OU или Universal Security Group.

    Запрос синхронизации осуществляется в том случае, если присутствуют синхронизируемые объекты.

    Вкладка «Синхронизируемые атрибуты»

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

    На странице представлены следующие параметры:

    • атрибут в AD;
    • поле в системе.
    Добавление нового атрибута

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

    Первичная синхронизация каталога active directory как сделать

    Спасибо за быстрый ответ.

    Так же скрин ipconfig.

    Сообщение об ошибки появляется при загрузки сервера.

    Сейчас попробую перезагрузить DNS и посмотреть, будет ошибка или нет.

    Сервер DNS перезагружал, данная ошибка не появляется.

    Она появляется только после перезагрузки сервера.

    Зато появилась еще одна ошибка.

    Не удалось установить связь DCOM с компьютером 195.54.192.39 через какой-либо из настроенных протоколов; запрос от PID 1bf8 (C:\Windows\system32\dcdiag.exe).

    Не уверен есть связь или нет?

    • Изменено akamsp 1 декабря 2017 г. 8:54

    Сервер DNS перезагружал, данная ошибка не появляется.

    Она появляется только после перезагрузки сервера.

    Зато появилась еще одна ошибка.

    Не удалось установить связь DCOM с компьютером 195.54.192.39 через какой-либо из настроенных протоколов; запрос от PID 1bf8 (C:\Windows\system32\dcdiag.exe).

    Не уверен есть связь или нет?

    Спасибо.

    Значит, ошибка у вас возникает вследствие каких-то временных сбоев при перезагрузке (к примеру, коммутатор Ethernet (управляемый физический или виртуальный), если на его порту не отключен STP, будет блокировать трафик 50 секунд после запуска драйвера сетевой карты). Если сервер DNS сам восстанавливает работоспособность по прошествии некоторого времени после перезагрузки (а на моей практике так бывало всегда в случае подобных ошибок, хотя и не сразу — с задержкой до получаса), то можно считать эту ошибку некритичной.

    В противном случае (кроме, естественно, нахождения и устранения источника проблемы) можно, например, добавить задание, запускаемое при старте системы, которое после задержки перезапускает службу сервера DNS. Или же — изменить тип запуска службы сервера DNS на "Автоматически (отложенный запуск)".

    Ошибка DCOM — это результат работы команды dcdiag /test:DNS: в процессе тестов она попыталась обратиться к некоему стороннему серверу (например, серверу пересылки) по RPC в предположении, что он — сервер, работающий под управлением MS Windows. Игнорируйте её.

    Первичная синхронизация каталога active directory как сделать

    Данная глава руководства администратора рассказывает о возможности импорта объектов ARTA Synergy из сторонних каталогов посредством Active Directory . В ней детально описано как настроить и эксплуатировать LDAP а рамках ARTA Synergy .

    Что такое LDAP

    LDAP — это аббревиатура от Lightweight Directory Access Protocol . Как следует из названия, это облегчённый протокол доступа к службам каталогов, предназначенный для доступа к службам каталогов на основе X.500 . LDAP работает поверх TCP/IP или других ориентированных на соединение сетевых протоколов. LDAP стандартизирован в качестве протокола IETF .

    Информационная модель LDAP основана на записях ( entry ). Запись — это коллекция атрибутов ( attribute ), обладающая уникальным именем ( Distinguished Name, DN ). DN глобально-уникально для всего каталога и служит для однозначного указания на запись. Каждый атрибут записи имеет свой тип ( type ) и одно или несколько значений ( value ). Обычно типы — это мнемонические строки, в которых отражено назначение атрибута, например cn — для общепринятого имени ( common name ), или mail — для адреса электронной почты. Синтаксис значений зависит от типа атрибута.

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

    Кроме того, LDAP , посредством специального атрибута objectClass , позволяет контролировать, какие атрибуты обязательны и какие допустимы в той или иной записи. Значения атрибута objectClass определяются правилами схемы ( schema ), которым должны подчиняться записи.

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

    LDAP и Arta Synergy

    При синхронизации LDAP и Arta Synergy можно выделить некоторые особенности:

    Синхронизация LDAP и Arta Synergy осуществима из LDAP каталога в ARTA Synergy , причем за тот период, который указан в конфигурационном файле.

    Синхронизация возможна сразу с несколькими каталогами.

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

    Ключ соответствия (поле, по которому будет определяться связка « Объект каталога LDAP <-> Пользователь Synergy » ) настраиваемый, например, можно использовать для этого ИИН.

    Пароли пользователей не синхронизируются, авторизация происходит непосредственно на LDAP каталоге посредством Simple Bind .

    Помимо стандартных полей карточки пользователя (ФИО, доступ в систему и т.п.) можно синхронизировать произвольные поля — с добавлением в карточку пользователя на формах.

    Установка и настройка Active Directory

    Active Directory — LDAP-совместимая реализация службы каталогов корпорации Microsoft для операционных систем семейства Windows Server. Позволяет администраторам использовать групповые политики для обеспечения единообразия настройки пользовательской рабочей среды, разворачивать программное обеспечение на множестве компьютеров через групповые политики или посредством System Center Configuration Manager, устанавливать обновления операционной системы, прикладного и серверного программного обеспечения на всех компьютерах в сети, используя Службу обновления Windows Server.

    Подробно рассмотрим установку и настройку Active Directory в ОС Windows Server 2012 R2.

    Перейдите в Server Manager и нажмите на Add roles and features .

    Откроется мастер установки ролей и компонентов.

    В шаге Installation Type выберите пункт Role-based of feature-based installation .

    В шаге Server Selection выберите пункт сервер, для которого будет установлена роль.

    В шаге Server Roles выберите пункт Active Directory Domain Services .

    Подтвердите добавление компонентов роли, нажав на кнопку Add Features .

    Пропустите шаг Features и подтвердите установку роли Active Directory.

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

    После успешной установки необходимо настроить Active Directory. Откройте Server Manager и нажмите на пиктограмму флага. В открывшемся выпадающем списке нажмите на Promote this server to a domain controller .

    В открывшемся мастере настройки Active Directory добавьте новый лес. Для этого в шаге Deployment Configuration выберите пункт Add a new forest и укажите название корневого домена.

    В шаге Domain Controller Service задайте пароль для режима восстановления служб каталогов.

    В шаге Additional Options измените имя домена NetBIOS.

    В шаге Paths укажите папки базы данных, файлов журнала и SVSVOL.

    В шаге Review Options отобразится список всех настраиваемых опций.

    В шаге Prerequisites Check подтвердите настройку выбранных опций.

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

    Создание пользователей в Active Directory

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

    Откройте Active Directory Users and Computers .

    Выделите ноду Вашего домена (в примере synergy.tm ) и нажмите кнопку добавления подразделения.

    Введите название будущего подразделения.

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

    Укажите имя, фамилию и логин будущего пользователя.

    Задайте пароль и включите флаг, отвечающий за устаревание пароля (если включен — пароль никогда не устаревает).

    Подтвердите создание нового пользователя.

    Повторив пп. 4-7 создайте требуемых пользователей.

    Теперь необходимо выдать этим пользователям доступ в систему ARTA Synergy. Для этого нажмите на кнопку создания новых групп.

    Укажите название будущей группы. В данную группу будет входить Администратор Active Directory.

    Нажмите на кнопку Add .

    Введите имя пользователя и нажмите на кнопку Check Names .

    Мастер автоматически дополнит значение учетной записи соответствующего пользователя.

    Создайте еще одну группу для доступа всех пользователей к системе ARTA Synergy.

    Повторив пп. 11-13 добавьте всех пользователей в группу доступа.

    Работа с LDAP-каталогами

    Для работы с LDAP -каталогами возможно использовать любой клиент с поддержкой LDAP -протокола. Одним их таких клиентов является JXplorer .

    JXplorer — кроссплатформенный LDAP браузер и редактор с поддержкой безопасности (в том числе SSL , SASL и GSSAPI ), перевода на многие языки, онлайн-помощью, коммерческой поддержкой, пользовательскими формами и многими другими возможностями.

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

    Рассмотрим его функциональность на примере поиска пользователя в одном из каталогов.

    Подключимся к серверу с данными Администратора:

    Рисунок 7.17. Рисунок 1

    Рисунок 1

    В открывшейся закладке Explore отобразилось дерево со всеми объектами каталога, доступные авторизованному Администратору. При выборе объекта из навигатора в основной рабочей области отобразились все атрибуты данного объекта, а также их значения:

    Рисунок 7.18. Рисунок 2

    Рисунок 2

    Примечание

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

    Вызовем окно поиска по каталогу — Search -> Search Dialog . В открывшемся диалоге укажем базовый узел поиска, от которого он будет осуществляться, и сам фильтр:

    Рисунок 7.19. Рисунок 3

    Рисунок 3

    Клиент автоматически перешел на вкладку Results с найденными результатами запроса:

    Первичная синхронизация каталога active directory как сделать

    Синхронизация локального каталога Active Directory с Office 365 ( Azure AD Connect )

    Предыдущая статья про синхронизацию с помощью устаревшего коннектора Azure Active Directory Sync tool — в Архиве.

    Новый коннетор Azure AD Connector вовсе не новый. Он уже используется с лета 2015 года. Однако, когда я вперый раз настраивал синхронизацию локального каталога AD с облаком Office 365 его ещё не было и я использовал коннектор Azure Active Directory Sync Tool. Примерно через год MS уведомил, что старый коннектор через год-другой поддерживаться не будет. С одной стороны, можно подумать, что этот-другой год можно будет работать с устаревшим коннектором, как MS взяла и. «отключила» его. Однажды, зайдя в Панель Управления Office 365, я увидел, что синхронизация не работает, а в логах написано — несоответствие версии коннектора. Пришлось устанавливать Azure AD Connector.

    Изначально мне не понравился Azure AD Connector из-за того, что не было ясно где теперь управлять фильтрами синхронизации. С помощью ТП выяснилось, что фильтры управляются в отдельном приложении «Synchronization Rules Editor». Но настроив его однажды я просто перестал париться из-за какого-то «нового» коннектора.

    На днях руководство поставило задачу — резервное копирование Exchange Online, One Drive for business, SharePoint Online в локальное хранилище. С одной стороны, облачные сервисы подразумевают собственное резервное копирование. Для Exchange по умолчанию это 14 дней хранения удалённых писем, для SharePoint и OneDrive это до 500 копий, сделанных перед изменением файлов. Но есть одно «но» — пользователь может зайти в средства восстановления и удалить всё безвозвратно. По этому была поставлена задача реализовать резервное копирование в локальное хранилище. Погуглив, был найдет Layer2 Cloud Connector, который синхронизирует как в обе стороны, так и в одну. Естественно, я не стал бы тестировать его с рабочей инфраструктурой, а в тестовой среде. Так мы подошли к моменту, как создать тестовую среду локального AD и синхронизировать её в облако Office 365. Данной статье будет рассмотрена только подробная синхронизация каталога в облако. Настройка контроллера домена на базе Windows Server 2016 описана в этой статье. Необходимо добавить дополнительный суффикс UPN (такой же как и почтовый домен) в оснастке «Active Directory Domain and Trusts». Для сервера синхронизации будет использоваться отдельный сервер. Для начала надо зарегистрировать пробную версию Office 365. Подключаем домен:

    aadc00.png

    Во время добавления домена exonix.ru выяснилось, что мой домен уже привязан к другой моей тестовой учётной записи Office 365, которую я использовал для первой статьи про синхронизацию каталога. Данную учётную запись, я не использовал уже больше года.

    aadc01.png

    Для того, чтобы отключить домен от этой учётной записи Office 365, необходимо выполнить следующие действия (в веб-админке этого не получится, т.к. у меня остались там синхронизированные пользователи). Пропустите данный шаг , если выполняете настройку синхронизации впервые:
    — установить Sing-In assistant.
    — установить Windows Azure PowerShell cmdlets. x64. x32.
    — подключится через PowerShell и выполнить следующие команды:

    Поиск всего, связанного с моим доменом:

    В текстовых файлах я нашёл своих двух пользователей, которых я не мог удалить в веб-интерфейсе (и не мог поменять им адрес электронной почты):

    aadc02.png

    Удаляем пользователя и домен:

    Возвращаемся к настройке Office 365. Добавление пользователей можно пропустить:

    aadc2.png

    Если домен уже имеет свои ДНС сервера, то стоит переключиться на самостоятельное управление. В противном случае, можно делегировать домен ДНС серверам от MS (у регистратора прописать предложенные MS сервера).

    aadc3.png

    В ДНС зону домена необходимо добавить все следующие записи. У каждого клиента MS записи будут одинаковыми, кроме MX записи.

    aadc4.png

    aadc5.png

    aadc6.png

    Далее, я переключаюсь в браузер IE, т.к. Chrome не захотел запускать утилиту проверки локальной инфраструктуры:

    aadc8.png

    Возвращаемся в Chrome.

    aadc9.png

    Никакая очистка среды не нужна (если не будет настоятельно требоваться):

    aadc10.png

    Скачиваем Azure AD Connect :

    aadc11.png

    Запускаем, выбираем Настроить (Customize):

    aadc12.png

    И начинается самое интересное. Azure AD Connect в настоящее время предлагает больше способов синхронизации. Если в первый раз я использовал синхронизацию паролей в облако, то сейчас я решил попробовать «сквозную аутентификацию» (Pass-through authentication). В этом случае пользователь, который пробует войти в Office 365, авторизуется не Office 365, а локальным сервером через установленный агент. А это значит, что теперь не нужно запускать синхронизацию, после смены пароля (или ждать до 30 минут). К сожалению, пока не удалось найти хоть какие-то логи на локальных серверах об авторизации пользователей.

    aadc14.png

    Вводим учётные данные от Office 365:

    aadc15.png

    Вводим учётные данные от локального AD:

    aadc16.png

    Если нужного домена нет, значит его не добавили как дополнительный UPN.

    aadc17.png

    Выбираем только те организационные еденицы, ресурсы которых будут синхронизироваться с Office 365. Это второй большой плюс Azure AD Connect (после сквозной авторизации).

    aadc18.png

    Оставляем по умолчнию (для одного домена):

    aadc19.png

    Самый главный плюс (на мой взгляд) — синхронизация на основе членства у Группе! Просто напишите имя группы и нажмите Resolve:

    aadc20.png

    Выставляем нужные опции (хотя я не уверен, что синхронизация паролей теперь нужна). Запись пароля из Облака в локальную AD возможна только в том случае, если имеется подписка Azure AD.

    aadc21.png

    Собственно, итоговый лог и скажет о невозможности настроить обратную запись паролей (из Office 365 в локальный AD):

    aadc22.png

    У меня был один тестовый пользователь, который входит в группу для синхронизации AADC. Т.к. больше никаких настроек с ним не производилось, то он «синхронизировался» в таком виде (домен входа exonixgmbh.onmicrosoft.com). Такой пользователь не сможет войти в Office 365, т.к. его «не существует» в локальном AD.

    aadc23.png

    Для того, чтобы пользователь смог пользоваться Office 365, надо синхронизировать его правильный UPN и почту:

    aadc26.png

    Включаем циклическую синхронизацию (каждые 30 минут):

    А вот так можно запускать синхронизацию вручную:

    Если нужно добавить ещё несколько OU для синхронизации, то это можно сделать в Synchronization Service. Фильтры синхронизации правятся в Synchronization Rules Editor. Оба приложения запускаются с повышенными правами!

    aadc27.png

    aadc24.png

    Ещё нужно добавить, что если пользователь имеет несколько почтовых псевдонимов (Alias), то он должен быть записан в атрибут proxyAddresses, где заглавные буквы SMTP означают главный почтовый адрес, от которого будет уходить почта:

    aadc28.png

    На этом настройка синхронизации локальный учётных записей пользователей завершена. Если сравнивать её с предыдущим коннектором, то это как настраивать DirectAccess на 2012 и 2012 R2 серверах. Т.к. в предыдущем коннекторе нужно было сделать много чего вручную, а в Azure AD Connect — практически всё делается автоматом + синхронизация на основе членства в группе. Мне определённо нравится этот коннектор )

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *