Как удалить dns делегирования

Обновлено: 22.01.2025

Иногда при установке служб Microsoft Active Directory Domain Services (AD DS) в среде Windows Server 2008 или Server 2008 R2 возникают две проблемы. Одна из них относится к процессу установки; другая связана с рекомендациями компании Microsoft по запуску контроллеров домена (DC) на виртуальных машинах. Эти проблемы известны опытным администраторам. Но начинающим специалистам, которым необходимо заменить операционную систему контроллера домена с Windows Server 2003 на Server 2008 R2, будет очень полезна эта статья, в которой я планирую рассмотреть все возможные трудности и пути их преодоления

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

Ошибки, связанные с Adprep

Adprep — утилита для подготовки существующей среды Active Directory (AD) для первого DC, функционирующего с новой операционной системой, например Server 2008 R2. Если все контроллеры домена в среде AD работают с Server 2008 или Windows 2003 и требуется добавить первый DC с операционной системой Server 2008 R2, необходимо выполнить определенные команды Adprep.

Выполните adprep/forestprep на хозяине схемы.
Выполните adprep/domainprep на каждом хозяине инфраструктуры домена.
Если предполагается установить доступный только для чтения DC (RODC — новшество Server 2008), следует также выполнить adprep/rodcprep для каждого домена с RODC.

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

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

При запуске Adprep необходимо учитывать следующие важные факторы.

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

Ошибка делегирования DNS

Экран 1. Ошибка делегирования DNS

До появления Server 2008 многие проблемы с AD были вызваны внутренними неполадками в инфраструктуре DNS, в частности отсутствующими или неправильными записями делегирования DNS. Одной из целей специалистов Microsoft при совершенствовании установки служб AD DS в Server 2008 было помочь потребителям в начальной настройке правильной инфраструктуры DNS, а затем облегчить обслуживание данной конфигурации.

утилита Dcpromo настроена для установки роли DNS-сервера;
слишком мало отношений делегирования существует между DNS-серверами и непосредственной родительской зоной DNS и поддоменом, в котором устанавливается новый DC;
устанавливаемый DC не может создать делегирование поддомену DNS на DNS-сервере для родительской зоны.

Dcpromo пытается создать делегирование, чтобы компьютеры в других доменах могли распознавать запросы DNS для узлов, в том числе контроллеров домена и компьютеров — членов домена, в поддомене DNS. Dcpromo может автоматически создавать такие отношения делегирования только на DNS-серверах Microsoft; попытка завершится неудачей, если родительская зона домена DNS находится на сторонних DNS-серверах, таких как BIND.

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

На родительском DNS-сервере должна функционировать служба Microsoft DNS Server.
DNS-сервер Microsoft в родительском домене должен быть подключен к сети и доступен с устанавливаемого контроллера домена.
Пользователь, запускающий утилиту Dcpromo на устанавливаемом контроллере домена, должен иметь учетные данные Domain Admins, Enterprise Admins или DNS Admin в родительской зоне DNS.

Виртуальные DC и возврат USN

Только поддерживаемые решения резервного копирования, такие как Windows Server Backup, могут быть использованы для восстановления контроллера домена. Недавно компания Microsoft пересмотрела рекомендации по запуску контроллеров домена на виртуальных машинах, в частности объяснено функционирование USN и способы предотвращения возврата USN. Благодаря этим изменениям информация представлена в более краткой и ясной форме, и администраторам будет проще избежать проблем.

Ошибка The Specified User Already Exists

Чаще всего эта ошибка указывает на то, что имя узла повышаемого сервера — такое же, как у другого контроллера домена. Для устранения этой проблемы выполните следующие шаги.

Если выполняется замена ранее пониженного DC новым контроллером домена с тем же именем, обязательно удалите метаданные старого DC. В Server 2008 и более новых версиях самый простой способ удаления метаданных — через оснастки AD. При необходимости можно воспользоваться и старым методом — Ntdsutil.
Если по-прежнему происходят сбои Dcpromo с этой ошибкой, выясните в файле dcpromoui.log имя исходного DC (он же вспомогательный DC), используемого новым DC для репликации. Найдите в файле раздел, который начинается с метки A в листинге 2. Имя исходного DC показано во фрагменте с меткой B.
Убедитесь, что исходный DC выполнил входящую репликацию удаления метаданных DC (то есть конфликтующих учетной записи компьютера DC и объектов параметров NTDS). Если учетная запись контроллера домена все еще существует, определите причину:

простая задержка репликации; например, DC находится на расстоянии нескольких переходов от DC, запустившего операцию очистки метаданных;
сбой входящей репликации на вспомогательном DC или на исходном DC, с которого вспомогательный DC получает изменения;
вспомогательный DC в «сайте задержки» преднамеренно настроен на входящую репликацию изменений в AD с задержкой.

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

Таблица 1. Возможные строки расширения ошибок

Еще одна распространенная причина сбоя установки AD заключается в том, что группе Administrators не назначено право Enable computer and user accounts to be trusted for delegation («Разрешение доверия к учетным записям компьютеров и пользователей при делегировании»). Это право — параметр групповой политики, включенный для группы Administrators по умолчанию в политике контроллеров домена. Если DC выбран в качестве партнера репликации в ходе повышения уровня реплицируемого DC, выбранному DC требуется доступ к ресурсам повышаемого компьютера. Если право Enable computer and user accounts to be trusted for delegation не назначено группе безопасности Administrators, то каждый запрос доступа к ресурсу завершается неудачей с пояснением «отказано в доступе», как показано на экране 2.

Экран 2. Ошибка «отказано в доступе»

Чтобы устранить ошибку, используйте консоль управления групповой политики (GPMC) и инструмент Group Policy Results (Gpresult) для проверки, назначено ли группе Administrators право Enable computer and user accounts to be trusted for delegation в политике Default Domain Controllers Policy. Путь в редакторе групповой политики — \Computer Configuration\Policies\Windows Settings\SecuritySettings\Local Policies\UserRights Assignment\Enable computer and user accounts to be trusted for delegation.

После того как DC начинает работать с 2008 R2, можно запустить анализатор AD DS Best Practices Analyzer (BPA) для обнаружения любых ошибок в настройках политики. Соответствующее правило BPA не входит в изначальный набор правил, но имеется в дополнительном наборе правил, поставляемом через службу Windows Update. Это правило применяется к DC, работающему с Server 2008 R2.

При запуске AD DS BPA другое правило из того же дополнительного набора поможет предотвратить две типичные ошибки в настройках групповой политики, которые являются коренными причинами отказа репликации DC: непредоставление права Access this computer from the network («Доступ к компьютеру из сети») группам безопасности Administrators, Enterprise Domain Controllers или Authenticated Users либо назначение группам безопасности Enterprise Domain Controllers, Everyone, Administrators или Authenticated Users права Deny access to this computer from network («Запрет доступа к компьютеру из сети»). Отказ может случиться на любом DC, пытающемся выполнить репликацию из DC с одной из упомянутых выше настроек. Пользователи и компьютеры также могут столкнуться с отказами при применении объектов групповой политики (GPO).

Чтобы устранить эту ошибку, убедитесь в анализаторе BPA, что контроллеры домена назначили это право соответствующему участнику безопасности. Используйте настройки GPMC и Gpresult из таблицы 2, чтобы проверить правильность параметров групповой политики.

Таблица 2. Параметры GPMC и Gpresult

Особенности Adprep

Когда в Windows Server 2003 впервые появилось требование выполнения команды adprep/forestprep, компания Microsoft и некоторые партнеры рекомендовали в целях предосторожности изолировать хозяина схемы (например, временно поместить его в отдельную сеть) для лучшего управления процессом обновления схемы. С тех пор специалисты службы поддержки пользователей Microsoft пришли к выводу, что в большинстве компаний такой подход скорее вызывает проблемы, чем устраняет. Поэтому специалисты Microsoft больше не рекомендуют отключать от сети хозяина схемы перед запуском adprep/forestprep.

Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.

Основные понятия Domain Name System

Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:

Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов, о которых ниже пойдет речь. «Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечающих за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Настройки корневой зоны всегда доступны тут. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.

Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:

Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.

Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.

FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:

Различие между FQDN и обычным доменным (неFQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.

Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.

Ресурсные записи

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

Запись ресурса состоит из следующих полей:

Для бОльшего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name. содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.

Т.о. после делегирования ответственности, информация хранимая делегирующей зоной уже не включает информацию по делегированному поддомену и его ресурсным записям хостов, а хранит информацию о серверах имен, являющихся для делегируемого поддомена авторитативными. Это и есть «склеивающие» записи, о чем я выше уже говорил. В таком случае, если у DNS-сервера родительского домена запрашиваются данные об адресе, принадлежащем делегированному поддомену, в ответ предоставляется список DNS-серверов, которые обладают соответствующей информацией.

Серверы DNS

Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.

Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.

Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).

Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.

Возможно так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.

Клиенты DNS (resolver)

Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS? Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется библиотека Resolver. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают системные вызовы gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то файл /etc/hosts или DNS) и в каком порядке использовать. В ранних версиях библиотеки Linux — libc, использовался файл /etc/host.conf. Вот фрагмент файла, который нас интересует:

Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка hosts: files dns) сначала из файла hosts, затем силами DNS, а так же преобразование имен сетей в IP (строка networks: files) с помощью файла /etc/network.Возможны так же параметры nis или nisplu, определяющие использовать Network Information System (NIS) чтобы найти адрес. Порядок, в котором перечислены сервисы, определяет последовательность их опроса.
Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяет какие серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:

Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. В данном файле указано использовать север имен сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х параметров nameserver. Если опция nameserver не задана, то резолвер попытается соединиться с сервером на локальном хосте. Параметр domain определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует так же опция search, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.

Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:

Запросы DNS

В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.

Итеративный (он же прямой, он же нерекурсивный) запрос посылает доменное имя DNS серверу и просит вернуть либо IP адрес этого домена, либо имя DNS сервера, авторитативного для этого домена. При этом, сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые и TLD серверы.

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

Обратный запрос посылает IP и просит вернуть доменное имя.

Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.

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

Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.

До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.

Ответы DNS сервера

Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).

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

Обратное преобразование имен

DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат IP-адреса, в поле Type — PTR, а в поле Data — FQDN-имя соответствующее данному IP.

На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет 2 поддомена in-addr и ip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.

В целях уменьшения объёма нежелательной корреспонденции (спама) многие почтовые серверы могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.

Наглядно приведенную схему можно представить командами:

Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно "www.ru". Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:

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

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

В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.

Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.

Резюме

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

Что еще почитать:

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

Всем привет сегодня хочется поделиться опытом как удалить домен Active Directory Windows Server 2008 R2. Под удалением домена подразумевается удаление последнего контроллера доме в домене. Я такое делал только в тестовых вещах, в жизни не приходилось так убивать Active Directory. Но такую практику я думаю нужно уметь делать, так как никогда неизвестно, что от вас потребуется.

Как удалить домен Active Directory Windows

Открываем пуск на последнем домене контроллере и вводим dcpromo, у вас должны быть права учетной записи которая входить в группу Администраторы предприятия в лесу. Если контроллер домена содержит DNS-зоны, интегрированные в Active Directory, то мастер удалит эти зоны. Кроме того, по умолчанию, он удалит DNS-делегирование для зон, которые указывают на контроллер домена

Как переименовать контроллер домена в Windows Server 2008 R2-3 часть через понижение контроллера домена-027

Запуститься мастер установки и удаления доменных служб Active Directory.

Как переименовать контроллер домена в Windows Server 2008 R2-3 часть через понижение контроллера домена-029

Жмем далее, попадаем на окно в котором нужно поставить галку Удалить этот домен, поскольку данный сервер является в нем последним контроллером домена.

Как удалить домен Active Directory Windows Server 2008 R2-031

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

Как удалить домен Active Directory Windows Server 2008 R2-032

Начнется проверка удаления делегирования DNS

Как удалить домен Active Directory Windows Server 2008 R2-033

Далее вас попросят ввести пароль для новой учетной записи администратора на данном сервере, вводим два раза.

Как удалить домен Active Directory Windows Server 2008 R2-034

Все жмем далее и начнется процесс удаления домена AD,

Как удалить домен Active Directory Windows Server 2008 R2-035

Если все же DC не последний то вы получите ошибку при попытке удалить AD.

Операция не выполнена по следующей причине.
Контроллер домена Active Directory не является последним в этом домене.

Ну тут и без объяснений все понятно, из за чего она.

Как удалить домен Active Directory Windows Server 2008 R2-036

Учетные записи администратора

Для выполнения этой процедуры необходимо быть членом группы "Администраторы домена" в родительском домене или членом группы "Администраторы предприятия" в лесу.

Password=<пароль учетной записи UserName или *, чтобы запрашивать пароль>

AdministratorPassword=<пароль локального администратора сервера>

RemoveApplicationPartitions=<yes, если нужно удалить разделы. Если нужно сохранить их, эта запись не нужна.>

DNSDelegationUserName=<административная учетная запись DNS-сервера для зоны DNS, которая содержит DNS-делегирование>

Вот так вот просто удалить домен Active Directory Windows Server 2008 R2.

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

Настройка dns windows server 2012 r2

Как настроить DNS сервер в windows server 2012R2-2 часть--08

Для этого идем на ваш Контроллер домена, у меня это dc. Выбираем свойства нужной зоны

Как настроить DNS сервер в windows server 2012R2-2 часть--09

Идем на вкладку сервера имен. Нажимаем Добавить

Как настроить DNS сервер в windows server 2012R2-2 часть--11

пишем имя нужного сервера, у меня это sccm

Как настроить DNS сервер в windows server 2012R2-2 часть--12

В итоге у меня получился вот такой список.

Как настроить DNS сервер в windows server 2012R2-2 часть--13

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

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

Передача зон, по сути, представляет собой извлечение данных, инициируемое в дополнительных зонах, копирование данных главной зоны, которая сама по себе может быть основной или еще одной дополнительной зоной. Главной зоне необязательно даже быть стандартной по отношению к дополнительной зоне — вы можете отконфигурировать дополнительную зону для основной зоны, интегрированной в Active Directory. К примеру, у вас есть два сайта - один в Нью-Йорке, другой в Лос-Анджелесе, причем каждый сайт принадлежит отдельному домену Active Directory. В каждом домене можно обеспечить разрешение имен для противоположного домена, не устанавливая новый контроллер домена и не управляя трафиком репликации между двумя сайтами.

Включение передачи зон

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

■ По истечении интервала обновления начальной записи SOA основной зоны.

■ При загрузке дополнительной зоны сервером.

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

По умолчанию передача для всех зон отключена. Ее нужно включить на вкладке Передача зон (Zone Transfers) окна свойств зоны. Установив флажок разрешения передачи зон, можно выбрать одни из трех параметров передачи.

■ На любой сервер (To Any Server) Этот параметр обеспечивает минимальную безопасность. Поскольку передача зоны представляет собой копирование данных зоны, этот параметр позволяет кому угодно с сетевым доступом к DNS-серверу просмотреть содержимое зоны, включая имена всех серверов и компьютеров с их IP-адресами. Поэтому данный параметр следует использовать только в частных сетях с высоким уровнем безопасности.

■ Только на серверы, перечисленные на странице серверов зон (Only To ServersListed On The Name Servers Tab) Этот параметр позволяет выполнять передачу зон с записью NS только на те дополнительные DNS-серверы, которые полномочны для данных зон.

■ Только на серверы из этого списка (Only To The Following Servers) Этот параметр позволяет указать список дополнительных серверов, на которые будет выполняться передача зон. Для этих дополнительных серверов не требуется идентификация с помощью записи NS в зоне.

Настройка уведомлений

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

Для настройки уведомлений на вкладке Передача зон (Zone Transfers) щелкните кнопку Уведомить (Notify). Откроется диалоговое окно Уведомление (Notify), где можно указать дополнительные серверы, которые будут оповещаться при обновлении зоны на локальном главном сервере.

По умолчанию при включении передачи зон все серверы, перечисленные на вкладке Серверы имен (Name Servers), автоматически уведомляются об обновлениях зоны.

Обновление дополнительной зоны вручную

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

Перезагружается дополнительная зона из локального хранилища.

■ Передать зону с основного сервера (Transfer From Master)

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

■ Перезагрузить повторно зону с основного сервера (Reload From Master)

Выполняется передача зоны с главного сервера дополнительной зоны независимо от серийного номера в записи SOA дополнительной зоны.

Выбираем Передать зону с основного сервера

Как настроить DNS сервер в windows server 2012R2-2 часть--14

Как видим если нажать F5 зона передалась

Как настроить DNS сервер в windows server 2012R2-2 часть--15

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

Как настроить DNS сервер в windows server 2012R2-2 часть--16

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

Зона-заглушка

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

Зоны-заглушки можно использовать в следующих целях:

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

Существует два списка DNS-серверов, участвующих в загрузке и поддержке зоны-заглушки:

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

Создадим зону заглушку или как еще ее называют stub zone.

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