Dcpromo не удалось удалить dns делегирование из родительской зоны
В этой статье решается проблема, из-за которой не удается Windows сервера, на котором размещены службы домена Active Directory (AD DS) или роль сервера контроллера домена.
Применяется к: Windows Server 2012 R2
Исходный номер КБ: 2694933
Симптомы
Изящное понижение Windows Сервера, на который размещена роль AD DS или сервера контроллера домена. Вы видите следующую ошибку на экране:
Соответствующая часть DCPROMO. Файл LOG содержит следующий текст:
Обзор объекта инфраструктуры и атрибутов раздела приложений DNS, на который ссылается ошибка DCPROMO на экране и DCPROMO. ЖУРНАЛ:
Атрибут содержит строку 0ADEL, указывающую, что роль, владеющий объектом fSMORoleOwner NTDS dc Параметры, удалена.
Атрибут содержит 32-символ альфа-числимый GUID владеют объектом DCs NTDS Параметры в формате fSMORoleOwner xxxx-xxxx-xxxx-xxxx-xxxx.
Имя раздела приложения DNS по умолчанию, для которого атрибут назначен dc с удаленным объектом fSMORoleOwner NTDS Параметры. В этом случае ошибка ссылается на DomainDNSZones. Эта же ошибка может возникнуть и в разделе приложений ForestDNSZones.
Причина
Ошибка возникает, когда пониженный контроллер домена не может воспроизводить исходящие изменения в DC, который владеет инфраструктурой FSMO или операционной ролью раздела, на который ссылается ошибка DCPROMO [журнал].
В частности, попытка понижения прерывается для защиты от потери данных. В случае разделов приложений DNS понижение блокируется, чтобы обеспечить репликацию следующих данных:
- живые и удаленные записи DNS
- ACLS записей DNS
- метаданные, такие как даты регистрации и удаления
Пути DN для разделов, в которых может возникнуть ошибка в разделе Симптомы, включают следующие:
- CN=Infrastructures,DC=DomainDNSZones.
- CN=Infrastructures,DC=ForestDNSZones.
Решение
Если мастеру инфраструктуры назначен удаленный NTDSA в разделе приложений DNS, например DomainDNSZones, его также может не оказаться в разделе ForestDNSZones или наоборот. Рекомендуется убедиться, что разделы DomainDNSZones и ForestDNSZones назначены для живых Windows Server 2003 или более поздних контроллеров домена, на которые размещена роль и раздел DNS Server.
Для решения этой проблемы воспользуйтесь одним из указанных ниже способов.
Используйте для назначения пути DN для атрибута к живому DC, который был прямым партнером репликации исходного ADSIEDIT.MSC fsMORoleOwner владельца роли FSMO. Затем подождите, пока это изменение будет входящий репликации в dc, который будет понижен.
Запустите сценарий в разделе Разрешение KB949257 для раздела, о чем идет речь.
Если пониженный dc не может воспроизводить входящие изменения для раздела каталога, запустите команду, чтобы принудительно понизить контроллер DCPROMO /FORCEREMOVAL домена.
Дополнительная информация
DCPromo пытается реплицировать изменения на каждом локально удерживаемом NC, чтобы уникальные изменения не были потеряны. Если данные хранятся в зонах DNS, DCPROMO пытается реплицировать содержимое зон DNS в мастер инфраструктуры для раздела DNS, о чем идет речь.
KB949257 описывает проблему, при которой команда не удается, когда мастер инфраструктуры для одного или более разделов приложений DNS назначен удаленным ADPREP /RODCPREP NTDSA.
This is the error that I got during domain controller removal on windows server 2008. It says the zone is a period (.)? The domain controller demoted successfully with the dcpromo wizard. I checked the other dcs in the domain and everything looked fine except for DNS. I just had to delete DNS references to the demoted server in DNS.
This is the error that I got during domain controller demotion. Is it safe to ignore?
---------------------------
Active Directory Domain Services Installation Wizard
---------------------------
DCPromo was unable to remove DNS delegations from the parent zone: .. This could be because you do not have permissions to do so, or because the zone is hosted by a server that does not run Windows. You should delete DNS delegations in the parent zone for this domain. To do so, contact an administrator who is responsible for the DNS zone: ..
The error was:
Ответы
If this is a single domain in a forest, then just demoting should be good.Do you have other zones that were delegated to this domain/zone?If you want to manually remove this zone, you should just be able to go to the parent zone and delete the NS and A records for this zone.
Just make sure none of your other DNS servers are using this demoted server as a forwarder or secondary server,maybe cause of this.
Все ответы
If this is a single domain in a forest, then just demoting should be good.Do you have other zones that were delegated to this domain/zone?If you want to manually remove this zone, you should just be able to go to the parent zone and delete the NS and A records for this zone.
"DCPromo was unable to remove DNS delegations from the parent zone: .."
This is a single domain in a forest. I have deleted the NS and A records in the parent zone and AD is working fine.
Just make sure none of your other DNS servers are using this demoted server as a forwarder or secondary server,maybe cause of this.
Can you check the entry on below location if any kindly delete the same.
· Dssite.msc [Sites and Services]
A.Expand the [Sites\Sitename\Servers] – delete incorrect server’s
B.Delete incorrect subnet configurations [Sites\Subnets]
C.Delete incorrect site links [Sites\IP]
· Make sure the domain controllers are pointing to the correct dns servers in tcp\ip settings.
· Force replication – ‘repadmin /syncall’
Иногда при установке служб Microsoft Active Directory Domain Services (AD DS) в среде Windows Server 2008 или Server 2008 R2 возникают две проблемы. Одна из них относится к процессу установки; другая связана с рекомендациями компании Microsoft по запуску контроллеров домена (DC) на виртуальных машинах. Эти проблемы известны опытным администраторам. Но начинающим специалистам, которым необходимо заменить операционную систему контроллера домена с Windows Server 2003 на Server 2008 R2, будет очень полезна эта статья, в которой я планирую рассмотреть все возможные трудности и пути их преодоления
Иногда при установке служб Microsoft Active Directory Domain Services (AD DS) в среде Windows Server 2008 или Server 2008 R2 возникают две проблемы. Одна из них относится к процессу установки; другая связана с рекомендациями компании Microsoft по запуску контроллеров домена (DC) на виртуальных машинах.
Эти проблемы известны опытным администраторам. Но начинающим специалистам, которым необходимо заменить операционную систему контроллера домена с 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.
Листинг 1. Текст ошибки в файле dcpromoui.log
Листинг 2. Поиск имени вспомогательного DC в файле dcpromoui.log
Значительная доля обращений к AD связана с поиском определенных серверов: контроллеров домена (DC), серверов глобального каталога (Global Catalog — GC), а также, если репликация выполняется через SMTP, - почтовых серверов. Если найти один из таких серверов невозможно, не удастся «довести до сведения» AD, что именно нужно сделать. AD ищет все перечисленные серверы, опрашивая серверы DNS, поэтому в большинстве случаев сбои AD связаны с проблемами в работе DNS. По крайней мере, так показывает мой опыт работы. А большинство проблем DNS произрастают из ошибок в настройке, о которых пойдет речь в настоящей статье. Начнем с самых общих проблем, свойственных многодоменному лесу.
На внутреннем сервере DNS отсутствуют копии со всех доменов леса
AD нужны сведения об инфраструктуре DNS, т. е. данные о серверах DNS в корпоративной сети. На этих серверах содержатся записи, содержащие (как минимум) местоположение серверов DC и серверов — членов домена — и, возможно, рабочих станций. Вычислительные сети используют DNS вот уже два десятка лет, т. е. гораздо дольше, чем существует AD, поэтому построение DNS для AD не должно быть очень сложной задачей. Однако большинство инфраструктур DNS проектировались с расчетом на видимость в общедоступной сети Internet, а все, естественно, хотят, чтобы настройки DNS для корпоративной AD не были видны кому бы то ни было в Internet. Следовательно, практически все структуры DNS, отображающие конкретные реализации AD, должны быть изолированы от Internet. Для этого используется техника настройки DNS, известная под названием разделение (split-brain) DNS. В результате получается конфигурация, которая соответствует требованиям, отсутствующим при несложной унифицированной установке DNS.
Сначала я создаю домен root.local, поскольку это корневой домен леса. Для этого я устанавливаю DNS на станции Windows Server 2003 или Windows 2000 и создаю зону root.local на соответствующем сервере. Поскольку домен root.local имеет ограниченное число станций и учетных записей, вполне логично, если один и тот же сервер будет сервером DNS и контроллером домена (DC). Я установил этот самый первый сервер как основной DNS-сервер для динамической зоны root.local, сообщив системе об использовании самой себя в качестве предпочтительного сервера DNS, а затем запустил Dcpromo для создания домена AD с именем root.local.
Теперь я устанавливаю второй сервер как вспомогательный DNS-сервер для root.local и снова сообщаю системе об использовании самой себя в качестве предпочтительного сервера DNS. С помощью настроек вспомогательному серверу сообщается о необходимости забрать обновленные данные о зоне root.local с основного сервера DNS. Затем с помощью Dcpromo системе предписывается сделать то же самое для второго DC. Поскольку иметь только один DC для домена - неважно, каких он размеров, - большая ошибка.
Имея два сервера DNS/DC для root.local, я настроил корневой домен леса. Однако я не считаю, что все контроллеры домена должны быть серверами DNS. В домене, где имеется более двух серверов, часть серверов делают серверами DC, часть - серверами DNS, на усмотрение администратора. Предположим, что вместо этого я решил создать огромный домен root.local в однодоменном лесу. В этом случае мне понадобится только настроить все последующие серверы DNS как вспомогательные для домена root.local и извлечь их копии зоны root.local из root.local самого первого сервера DNS, который работает как основной DNS-сервер root.local. Кроме того, необходимо убедиться, что все компьютеры, которые я собираюсь сделать членами домена root.local, ссылаются на сервер DNS, который является или основным, или одним из вспомогательных для root.local.
Вывод: каждый сервер DNS в сети компании должен быть или основным, или вспомогательным сервером DNS для каждого домена леса.
О предположении, что все автоматически заработает, если зоны DNS интегрировать в AD
Разговоры об основных и вспомогательных зонах DNS относятся к эпохе до появления Windows 2000, не так ли? Мне могут возразить, что более эффективно интегрировать зоны DNS в Active Directory. И это справедливо, ведь интеграция в Active Directory часто используется для получения сведений об инфраструктуре DNS.
По умолчанию интегрированные зоны AD Windows 2003 точно так же реплицируют свою DNS-информацию, только на DC своего домена. Однако DNS Windows 2003 предоставляет возможность настроить репликацию интегрированных зон AD на все серверы DNS в лесу.
Вывод: даже если в лесу есть несколько доменов с интегрированными в AD зонами, все равно необходимо убедиться, что DNS-серверы произвольно выбранного домена являются также вспомогательными серверами DNS для интегрированных зон всех остальных доменов, если речь идет о Windows 2000. Или, если используется Windows 2003, требуется настроить реплицирование содержимого зон по всему лесу.
Рабочие станции и серверы ссылаются на сервер DNS вне корпоративной сети
При настройке TCP/IP можно сообщить системе об IP-адресах двух серверов DNS: о предпочтительном сервере (preferred DNS server) и альтернативном сервере (alternate DNS server). Когда клиентская система инициирует DNS-запросы, сначала предпринимается попытка послать запрос по предпочтительному IP-адресу; если ответа нет, клиент пытается опросить альтернативный адрес. Через реестр или службу Microsoft DHCP Server можно настроить до шести альтернативных адресов. Предпочтительный, основной альтернативный и все остальные альтернативные серверы DNS должны быть в той же корпоративной сети, что и станция — инициатор запроса, и так для каждого компьютера в корпоративной сети.
К каким неполадкам могут привести ошибки в настройке DNS в этом месте? Когда настраиваются предпочтительные и альтернативные серверы DNS, кто-то может настроить свои системы так, что предпочтительный сервер DNS действительно будет корпоративным сервером, но для альтернативного сервера будет указан адрес IP сервера DNS в Internet - часто это бывает DNS-сервер Internet-провайдера компании. Такой сценарий порождает трудноразрешимую проблему: когда предпочтительный сервер DNS отвечает на запрос клиента о данных AD, клиент ответ получает, но когда клиент опрашивает альтернативный сервер, тот ничем не может помочь. И получается, что в один момент клиент может получить данные AD, а в другой - нет. Такая ошибка периодически возникает.
Что еще хуже, многие испытывают затруднения при назначении предпочтительного и альтернативного серверов DNS. Какой сервер DNS должен отвечать на данный запрос? Опять-таки, поскольку серверу DNS необходимо отыскать системы в AD, предпочтительный и альтернативный серверы DNS (и все дополнительные альтернативные) всегда должны быть DNS-серверами в корпоративной сети. На самом деле, настраивая внутрикорпоративные серверы DNS на самих себя в качестве предпочтительных серверов, вы поступаете правильно, и обычно я не задаю альтернативный сервер для сервера DNS. Если на сервере DNS происходит сбой, практически всегда возникает проблема, и этот сервер не должен участвовать в процедуре разрешения имен до тех пор, пока работоспособность службы DNS не будет восстановлена.
Вывод: независимо от того, сколько серверов DNS прописано в системе, все они должны находиться в корпоративной сети. И когда настраиваются корпоративные DNS-серверы, ссылаться они должны на самих себя.
Система Windows 2000 DNS/DC ссылается сама на себя
Только что я рассказывал о том, что надо настраивать серверы DNS со ссылкой на самих себя, но можно столкнуться с ситуацией, когда Active Directory реализована на базе Windows 2000, а корневой домен леса сконфигурирован как интегрированный в AD. Чтобы сервер DNS стал хостом интегрированной зоны AD для корневого домена леса, этот сервер DNS обязательно должен быть сервером DNS и DC корневого домена. Далее, если настроить все системы DNS/DC со ссылкой на самих себя в качестве предпочтительных серверов DNS, возникнет проблема, известная под названием островная DNS (island DNS): каждый из таких серверов DNS утратит всю информацию обо всех остальных серверах DNS, кроме самого себя.
Для решения проблемы нужно или обновить DC до Windows 2003, на которых такая проблема уже отсутствует, или отказаться от использования интегрированных зон AD в корневом домене. И еще раз подчеркну, что описанная проблема присуща только корневому домену.
А вот как еще можно выйти из затруднительного положения: решите для себя, какой сервер DNS будет для вас мастер-сервером DNS. Затем укажите на мастер-сервере, что предпочтительным сервером DNS для него будет он сам. И наконец, установите на всех остальных серверах DNS ссылки на мастер-сервер DNS как предпочтительный сервер. Также можно настроить альтернативные серверы DNS для всех остальных серверов DNS, кроме мастера, но никогда не следует задавать ссылки на самих себя на серверах DNS/DC.
Вывод: если в корневом домене леса используются интегрированные зоны Active Directory, не стоит устанавливать ссылки на серверах DNS на самих себя. В системах на базе Windows 2003 эта проблема отсутствует.
Устаревший файл HOSTS не позволяет отыскать сервер
Не так давно один читатель обратился ко мне с просьбой помочь разрешить весьма странную проблему, связанную с DNS. Один компьютер - только один! - в корпоративной сети не мог подключиться к конкретному DC. По отношению к другим контроллерам домена в сети у этого компьютера никаких проблем не возникало, все остальные станции к указанному DC тоже подключались нормально. В чем же дело?
Я проанализировал целый список возможных причин и решений, но все безрезультатно. И к сожалению, вынужден был признать, что больше никаких идей нет. Несколько недель спустя читатель прислал мне письмо с решением своей задачи: файл HOSTS!
Вывод: даже когда одна станция дает сбой при поиске определенного сервера, а все остальные - нет, следует просмотреть содержимое файла HOSTS на неисправной станции.
Dcpromo не работает
Вот типичная ситуация: читатель создал AD с одним DC, этот DC прекрасно работает, но читатель не может ни включить в домен AD хотя бы одну рабочую станцию, ни запустить Dcpromo на другом сервере для добавления второго DC. Очевидно, что проблема в Dcpromo.
Dcpromo проверяет, существует ли в сети достаточная для нормальной работы AD инфраструктура DNS, т. е. выполняется поиск зоны, чье имя соответствует имени созданной AD, проверяется способность зоны выполнять динамическую DNS-регистрацию и выясняется, были ли соблюдены все перечисленные условия до установки DNS.
Это хороший ход, и я очень доволен, что разработчики Microsoft при написании Dcpromo предусмотрели эту проверку. Но, к сожалению, Microsoft «улучшила» свое детище и пошла еще дальше - позволила Dcpromo установить DNS самостоятельно. Никогда не позволяйте Dcpromo устанавливать DNS! Dcpromo не устанавливает для самого первого DC ссылку на самого себя, не сообщает пользователю о необходимости установить ссылки на серверы DNS в корпоративной сети для всех систем во внутренней сети и вообще не пытается как-то сообщить о проблемах, озвученных в данной статье.
Вывод: если Dcpromo сообщает, что DNS установлена некорректно, самое лучшее - остановить Dcpromo и еще раз проверить всю инфраструктуру DNS. Нельзя создавать AD поверх неверно развернутой DNS.
Избавим AD от ненужных проблем
DNS обеспечивает выполнение простой задачи: связывает имена станций с их IP-адресами. AD накладывает на DNS дополнительную обязанность - хранение списка контроллеров домена и серверов глобального каталога. Но за обманчивой простотой формулировки этих задач скрывается их огромная важность. Без DNS Active Directory просто не будет работать. Следует постоянно помнить о наиболее общих причинах неправильной настройки DNS, и можно будет создать инфраструктуру DNS, свободную от ошибок.
Неразбериха с DNS: история со счастливым концом
Я занимаюсь технологическим консалтингом в Сан-Франциско. Однажды я получил вызов с просьбой о помощи: мой клиент столкнулся с периодически возникающей проблемой при определении местонахождения локальных ресурсов. Он полагал, что его проблема кроется в сети, однако не был в этом уверен. Клиент был в панике. Речь шла не о рядовой юридической конторе - это была высокотехнологичная фирма, с гордостью заявлявшая, что в ней число поверенных больше, чем общее число сотрудников во многих компаниях. Я взялся помочь.
Диспозиция
Компания использовала BIND 9.2.3 Linux в качестве основного сервера DNS. Фирма относительно недавно развернула Active Directory (AD) на Windows Server 2003 и потихоньку добавляла в каталог пользователей и принтеры. Мне рассказали, что некоторые пользователи внезапно обнаружили, что не могут печатать. Другие пользователи просто жаловались на медленную работу сети.
Когда я приехал, сотрудник ИT-службы встретил меня и проводил в конференц-зал, где тут же началось обсуждение проблемы. На вопросы о производившихся изменениях, добавлении нового оборудования и программного обеспечения мне ответили отрицательно: «Нет, ничего не менялось». Единственной крупицей информации, которую мне удалось добыть, были сведения о том, что в процессе миграции пользователей и принтеров в AD были дополнительно усилены некоторые меры безопасности. Но, как меня заверили, это не могло оказать какого-либо влияния на возможность печатать документы.
Диагностика
Я начал с того, что стал тестировать с помощью ping некоторые из имеющихся принтеров по известным IP-адресам. Ничего. Тогда с помощью полностью определенных имен Fully Qualified Domain Names (FQDN) я попытался проверить те же самые принтеры через Linux DNS, затем через DNS/AD Windows 2003. Результат получился интересным: в зависимости от того, какой использовался сервер DNS, некоторые из IP-адресов принтеров не удавалось разрешить. Быстрый анализ файлов журналов DNS на станциях Linux выявил сотни ежедневных ошибок, которые на выходных сходили на нет. Ага! Это уже кое-что!
Я мог бы воспользоваться и другими утилитами для проведения дополнительных тестов, но то, что мне действительно было нужно, — это инструмент, который позволил бы заглянуть в содержимое сетевых пакетов. Большинство диагностических программ не предоставляло необходимой информации и могло только завести меня в тупик. Чтобы быстро обнаружить причину происходящего, мне нужен был анализаторов сетевых протоколов с возможностями лингвистического анализа содержимого передаваемых пакетов, что дало бы возможность добраться до самой сути проблемы.
Сетевое расследование
Я настроил анализатор для перехвата пакетов между сервером Linux DNS, прописанным как Start of Authority (SOA), и сервером Windows 2003 DNS, также прописанным как SOA. Я хотел посмотреть результаты проведения двух тестов: передачу данных между зонами (трансфер зоны) с Linux на Windows и трансфер зоны в обратную сторону - с Windows на Linux. Сначала я выполнил кросс-пересылку на хосты Linux, потом выдержал паузу и инициировал трансфер зоны на системы Windows, а затем приступил к анализу результатов.
В результате тщательной проверки файла трассировки обнаружилось, что хост Linux, успешно установив соединение с системой Windows, выдавал ошибку при выполнении трансфера зоны и со временем отключался от системы. Просмотрев пакеты при трансфере зоны от Windows к Linux, я увидел те же самые результаты.
Серверы успешно устанавливали соединение через TCP-порт 53 при трансфере зоны TCP/IP, но не могли передать DNS-данные и в конце концов отключались друг от друга. При инспектировании пакетов обнаружилась проблема аутентификации: иногда возникал неправильный отклик на пакет. Но ведь передача данных DNS не требует аутентификации, правда?
Как уже отмечалось ранее, сотрудники ИT внесли в свое время некоторые изменения в настройки безопасности. В конце концов, я получил более подробную информацию: чтобы воспрепятствовать фальшивому трансферу зоны, администратор Linux активизировал DNS Security extensions protocol (DNSSEC) на серверах Linux DNS. DNSSEC, описание которого приведено в Internet Engineering Task Force (IETF) Request for Comments (RFC) 2535, использует открытый и закрытый ключи. Windows 2003 DNS не в полном объеме поддерживает DNSSEC, поэтому мы решили удалить внесенные изменения и снова попытались поработать. Проблема была решена! Компания находилась в процессе миграции на Windows 2003 и AD, поэтому было предложено полностью поменять платформы и сделать сервер Windows 2003 основным сервером DNS.
Объяснение решения
Мой клиент был очень доволен, что проблему удалось решить за полдня. В конце концов, для этой высококлассной юридической фирмы время означало деньги: час работы фирмы стоил около 25 тыс. долл., ее конечный продукт воплощался на бумаге. Своим решением я сэкономил клиенту 100 тыс. долл. И несомненно, ИT-персонал фирмы получил более ясное представление о том, как работает схема безопасности Windows DNS, и особенно DNSSEC.
В данной статье предпринята попытка выйти за пределы структуры единственного леса/единственного домена AD, в которой конфигурация DNS сравнительно проста, и исследовать работу DNS в более сложной архитектуре AD. Одновременно рассматривается несколько новых концепций DNS, реализованных в Windows Server 2008 R2
Служба DNS, обеспечивающая преобразование доменных имен в IP-адреса, — не просто система распознавания имен для всего Интернета. Это критически важный компонент Active Directory (AD), необходимый для обнаружения сетевых ресурсов. Но несмотря на повсеместный переход с системы WINS на DNS в сетях Windows в последнее десятилетие, начинающим администраторам все так же трудно разобраться в сложной иерархической организации DNS.
Интеграция Active Directory и DNS
Чтобы понять, как DNS сочетается с AD, подготовим типовую структуру AD для средних и крупных компаний. Построим один лес с двумя доменами (рисунок 1). Первый домен часто именуется пустым корневым (empty root) или просто корневым доменом. Пустой корневой домен находится на верхнем уровне иерархии AD и, как видно из имени, не содержит никаких ресурсов. Благодаря доменам такого типа компании получают более гибкие и лучше разделенные роли безопасности, нежели в единственном лесе/единственном домене. Второй домен расположен ниже пустого корневого и потому является дочерним; он функционирует как основной домен компании, в котором расположены ресурсы (например, группы, учетные записи пользователей и компьютеров).
Рисунок 1. Один лес с двумя доменами |
Начнем с запуска утилиты Dcpromo на первом сервере, чтобы создать лес и пустой корневой домен. Зарегистрируйтесь на сервере Server 2008 R2 в качестве администратора. Убедитесь, что серверу назначено подходящее имя, такое как DC1, и задайте IP-адрес, маску подсети и шлюз по умолчанию на сетевом адаптере сервера. Настройки DNS для сетевого адаптера можно оставить пустыми и предоставить Windows ввести локальный адрес.
В зоне DNS содержатся все записи ресурсов для одной части пространства имен, такой как ADCOMPANY или COM. Это внутренний корневой домен AD, поэтому запись делегирования в общедоступной зоне COM необязательна, и предупреждение можно игнорировать. Значение делегирования прояснится после создания дочернего домена.
Тестирование с использованием Dcdiag
После завершения работы Dcpromo перезагрузите сервер. Чтобы убедиться, что с новым сервером все в порядке, откройте командную строку и запустите утилиту Dcdiag. Если DNS и другие важные компоненты AD настроены верно, последовательность тестов будет выполнена успешно.
Тест должен завершиться успешно.
Корневые ссылки
Если AD DNS функционирует, а DC подключен к Интернету, установленный сервер DNS должен преобразовывать имена доменов Интернета, хотя серверы пересылки не настроены и не указан IP-адрес сервера DNS провайдера Интернета в настройках сетевого адаптера DC. Сервер DNS содержит корневые ссылки, указывающие на серверы DNS верхнего уровня в Интернете. Таким образом можно обслуживать запросы относительно имен, которых он не имеет в своем кэше.
Чтобы увидеть корневые ссылки, загруженные из файла cache.dns, откройте оснастку DNS из раздела Administrative Tools в меню Start. В консоли DNS щелкните правой кнопкой мыши на сервере DNS в левой области и выберите пункт Properties. В диалоговом окне свойств сервера перейдите на вкладку Root Hints (экран 1).
Экран 1. Просмотр корневых ссылок |
Иногда возникают ситуации (например, если требуется использовать службу OpenDNS для фильтрации веб-контента), в которых вместо корневых ссылок для преобразования имен Интернета применяется сервер пересылки. Проектируя инфраструктуру DNS, помните, что, если на сервере DNS заданы серверы пересылки, они используются для преобразования имен прежде корневых ссылок.
Итеративные и рекурсивные запросы
Настройка конфигурации дочернего домена
Прежде чем начать, выполните команду
чтобы убедиться в правильности настроек, необходимых для назначения сервера контроллером домена, указанного с использованием ключа /dnsdomain.
Экран 2. Создание нового домена в существующем лесу |
Экран 3. Назначение имени новому домену |
В ответ на приглашение перезагрузите сервер и запустите Dcdiag на контроллере домена HR, чтобы убедиться в правильности функционирования всех компонентов. При запуске Dcdiag соблюдайте рекомендации, приведенные выше.
Откройте командную строку и выполните
Обратите внимание, что основной сервер DNS сетевого адаптера сервера настроен на локальный адрес сервера, а IP-адрес сервера DNS корневого домена смещен для использования в качестве дополнительного сервера DNS.
Делегирование и пересылка
Рисунок 2. Делегирование и пересылка |
Регрессирование DNS
Порядок просмотра суффиксов DNS
Если использовать Nslookup для тестирования разрешения DNS, выясняется, что без просмотра суффиксов DNS необходимо ввести полное имя ресурса, расположенного в домене HR, поскольку Nslookup, как инструмент для тестирования преобразования имен DNS, использует исключительно DNS. Чтобы протестировать DNS с помощью Nslookup, откройте командную строку из меню Start и введите nslookup.
В ответ на приглашение введите полное или однокомпонентное имя, которое нужно преобразовать, и нажмите клавишу Enter. Nslookup выдаст IP-адрес или сообщит о неудачном завершении поиска.
Как правило, IP-адреса компьютеров серверов не изменяются, поэтому защищенными зонами можно управлять вручную.
Условная пересылка
Рисунок 3. Условная пересылка |
В одной статье невозможно всесторонне рассмотреть проблему. Например, существуют два типа зон, дополнительные и зоны-заглушки, с помощью которых можно повысить производительность, а также новая функция Server 2008 R2, такая как DNSSEC. Но понимание основ совместной работы DNS и AD в интегрированном решении поможет более успешно развертывать AD и выполнять диагностику. Главное, в ходе тестирования новой или существующей инфраструктуры AD убедитесь, что каждый домен может обращаться к ресурсам во всех доверенных доменах. Кроме того, организуйте делегирование и условную пересылку для разрешения между пространствами имен. Соблюдение этих основных правил поможет более эффективно использовать DNS в сложной среде AD.
Читайте также: