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

Обновлено: 07.07.2024

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

Когда необходимо создавать доверительные отношения? Первым ответом будет являться необходимость использовать пользователями одного предприятия (домена в одном лесу) ресурсов из другого предприятия (другого домена иного леса) или наоборот, затем доверительные отношения требуются при выполнении миграции объектов безопасности из одного домена в другой (например при использовании инструмента ADMT v2 от Microsoft) и во многих других жизненных условиях работы.

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

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

Определившись с понятиями, приступим к установлению внешних односторонних отношений доверия домена D01 к домену D04.

DNS имя домена

d01.local

d04.local

Контроллеры домена ( IP)

Server01 (192 .168.1.1)

Server02 (192 .168.1.2)

Server04 (192 .168.1.4)

Server08 (192 .168.1.8)

Обычно, оба домена развернуты в различных сетях и связь между ними производится через шлюзы. Иногда, для этих целей добавляют вторую сетевую карту на контроллеры домена, устанавливая соединение с внешними сетями именно через них. В этом примере я использовал самый простой случай, когда оба домена расположены в одной подсети. При этом возможно установить доверительные отношения просто указывая NETBIOS имена доменов и указанные выкладки излишни, однако при усложнении сетевой структуры (разные подсети доменов, связь через шлюзы и виртуальные частные сети) так просто уже доверия не настроить. Тогда следует реализовывать дополнительные настройки в сети, приведённые ниже.

Составим план действий для создания доверительных отношений:

проверка соединений между двумя серверами
проверка настроек каждого домена
настройка разрешения имен для внешних доменов
создание связи со стороны домена-доверителя
создание связи со стороны доверяемого домена
проверка установленных односторонних отношений
создание двустороннего доверия (если необходимо)

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

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

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

С сервера Server01 убедимся в доступности с сервером Server04 (192.168.1.4)
Важно устанавливать связи по IP адресу, чтобы исключить ошибки связанные с разрешением имен.
В командной строке введем: ping 192.168.1.4
Должны получать ответы от удаленного адреса. Если ответа нет, проанализируйте вашу сетевую инфраструктуру и решите проблемы.

С сервера Server04 убедимся в доступности с сервером Server01 (192.168.1.1)
В командной строке введем: ping 192.168.1.1
Должны получать ответы от удаленного адреса сервера Server01.

Если все в порядке, переходим к следующему пункту, проверке настроек доменов.

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

Выполним на каждом сервере команды ipconfig. exe / all и nslookup. exe (экран 1 и 2).

Ipconfig выводит конфигурацию протокола TCP/ IP – IP адреса, адреса шлюзов и серверов DNS для контролера. Если инфраструктура DNS настроена верно, nslookup выводит список IP адресов контроллеров домена на запрос по DNS имени локального домена. Если адреса контроллеров для локального домена получить не возможно, проверьте настройку первичного сервера DNS и содержание зоны прямого просмотра сервера DNS (экран 3).

Теперь приступим к разрешению этой ситуации. Выполним настройку разрешения имен DNS для внешних доменов на каждом сервере.

Что необходимо сделать? Нужно добиться разрешения имен и получения ресурсных записей для внешнего домена. Все это возможно если установить для локального сервера возможность доступа к зоне DNS, поддерживающей внешний домен и способной разрешать требуемые запросы. Сразу замечу, что попытка решить эту проблему - просто добавив IP адрес внешнего сервера DNS в качестве альтернативного в настройках TCP/ IP, обречена на неудачу. Сделаем правильные, для этой ситуации, шаги.

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

Приведу пример создания дополнительной зоны для сервера Server01, на Server04 последовательность действий аналогична.

Изменим параметры передач первичной зоны DNS на удаленном сервере.

На ( Server04) откройте окно оснастки DNS (через меню Пуск, далее Программы и Администрирование).

Щелкните правой кнопкой мыши зону DNS и выберите команду Свойства.

На вкладке Передачи зон установите флажок Разрешить передачи зон.

Разрешите передачи зон только на определенные DNS-серверы и выберите вариант только на серверы из этого списка, и затем укажите IP-адреса DNS-серверов первого домена (в нашем случае это будет IP Server01 - 192.168.1.1 экран 5).

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

Включим уведомления для дополнительных зон на других серверах DNS

Проверьте, что установлен флажок Автоматически уведомлять.

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

Для этого в список уведомления, введите IP-адрес сервера из предыдущего пункта (192.168.1.1) в поле IP-адрес и нажмите кнопку Добавить (экран 6).

Создадим Дополнительную зону DNS на локальном сервере.

На ( Server01) откройте окно DNS.

В дереве консоли щелкните правой кнопкой мыши DNS-сервер и выберите команду Создать зону, чтобы открыть мастер создания зоны (экран 7).

Выберите тип зоны Дополнительная, введите ее имя ( D04. local) и IP адрес основного сервера ( IP 192.168.1.4) в поле IP-адрес и нажмите кнопку Добавить.

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

Выполним проверку новой конфигурации DNS сервера.

На ( Server01) откройте окно командной строки, выполните команду nslookup. exe и введите запрос на DNS имя внешнего домена D04. local – и результат IP адреса контроллеров этого домена (экран 9).

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

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

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

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

Создадим связь со стороны домена-доверителя ( d01. local)

На контроллере ( Server01) откройте оснастку «Active Directory - домены и доверие» (через меню Пуск, далее Программы и Администрирование).

В дереве консоли щелкните правой кнопкой узел домена, которым требуется управлять ( D01. local), и выберите команду Свойства (экран 11).

Выберите вкладку Доверия.

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

Введите полное DNS-имя домена, т.е. D04. local (для домена Windows NT, просто имя - экран 12).

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

Находясь в этом режиме можно просмотреть свойства созданной исходящей связи (экран 14).

Повторим эту процедуру для домена, составляющего другую часть прямого доверительного отношения.

Создадим связь со стороны доверяемого домена ( d04. local)

На контроллере ( Server04) откройте оснастку «Active Directory - домены и доверие».

В дереве консоли щелкните правой кнопкой узел домена, которым требуется управлять ( D04. local), и выберите команду Свойства.

Выберите вкладку Доверия (экран 15).

Выберите Домены, которые доверяют этому домену, а затем нажмите кнопку Добавить.

Введите полное DNS-имя домена - D01. local.

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

Для этого следует указать учётную запись пользователя, имеющего право на изменения отношений доверия из противоположного домена D01. local, те запись Администратора домена d01 (экран 18).

Если регистрационные данные верны, выполняется проверка связи этого отношения и доверие становится установленным (экран 19).

Теперь посмотрим, как выполнять проверку внешних доверительных отношений. Например, проверим отношение из домена-доверителя ( D01.local)

Чтобы проверить отношение доверия:

Откройте оснастку «Active Directory - домены и доверие».

В дереве консоли щелкните правой кнопкой домен, участвующий в отношении доверия, которое требуется проверить ( D01. local), и выберите команду Свойства.

Выберите вкладку Доверия.

В списке Домены, которым доверяет этот домен выберите отношение доверия, которое требуется проверить ( D04. local), и нажмите кнопку Изменить (экран 20).

В появившемся диалоговом окне следует ввести учётные данные пользователя, имеющего право на изменение отношений доверия, те запись Администратора внешнего домена d04 и его пароль (экран 21).

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

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

Убедимся, что мы можем в домене-доверителе использовать объекты участники безопасности из доверенного домена (учётные записи из домена D04. local). Для этого создадим в домене D01 общий ресурс и предоставим доступ к нему глобальной группе «Пользователи домена» из доверенного домена D04.

Создайте в домене D01. local общую папку на контроллере домена Server01.

В окне выбора пользователей из списка «Искать в» открыть ниспадающий список и убедиться, что теперь новый доверяемый домен D04. local стал доступен для выбора объектов (экран 24).

Выберите группу из внешнего домена:
В списке объектов безопасности внешнего домена D04. local выберите группу «Пользователи домена» и добавьте ее список безопасности общего ресурса с разрешением Чтение (экран 26).

Таким образом, из доверенного домена D04 мы получили доступ к ресурсу в домене доверителе D01, что нам и требовалось.

Если необходимо, то возможно настроить отношения доверия в обратном направлении, от домена D04 к D01. Т.е доменом-доверителем станет домен D04. local, а доверенным доменом уже будет D01. local.

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

В этом руководстве описано следующее:

настройка DNS в локальной среде AD DS для поддержки возможности подключения Azure AD DS;
создание одностороннего входящего доверия леса в локальной среде AD DS;
создание одностороннего исходящего доверия леса в Azure AD DS;
тестирование и проверка отношения доверия для проверки подлинности и доступа к ресурсам.

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

Предварительные требования

Для работы с этим учебником требуются следующие ресурсы и разрешения:

Связанный с вашей подпиской клиент Azure Active Directory, синхронизированный с локальным или облачным каталогом.

Управляемый домен Azure AD DS, созданный с использованием леса ресурсов и настроенный в клиенте Azure AD.

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

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

В этом учебнике вы создадите и настроите исходящее доверие леса из Azure AD DS с помощью портала Azure. Чтобы начать работу, войдите на портал Azure. Для изменения экземпляра Azure AD DS требуются разрешения глобального администратора.

Рекомендации по работе с сетями

Для виртуальной сети, в которой размещен лес ресурсов Azure AD DS, требуется сетевое подключение к локальным доменным службам Active Directory. Для приложений и служб также требуется подключение к виртуальной сети, в которой размещается лес ресурсов Azure AD DS. Сетевое подключение к лесу ресурсов Azure AD DS должно быть непрерывным и работать стабильно. В противном случае пользователи могут не пройти проверку подлинности или не получить доступ к ресурсам.

Перед настройкой доверия леса в Azure AD DS убедитесь, что сеть между Azure и локальной средой соответствует следующим требованиям:

Используйте частные IP-адреса. Не полагайтесь на DHCP с динамическим назначением IP-адресов.
Избегайте перекрытия диапазонов IP-адресов, чтобы обеспечить возможность пиринга между виртуальными сетями, а также маршрутизации для связи между Azure и локальной средой.
Для виртуальной сети Azure требуется подсеть шлюза, чтобы настроить подключение Azure VPN типа "сеть — сеть" или ExpressRoute.
Создайте подсети с достаточным количеством IP-адресов для поддержки вашего сценария.
Убедитесь, что Azure AD DS имеет собственную подсеть. Не предоставляйте общий доступ к этой подсети виртуальной сети виртуальным машинам и службам приложений.
Одноранговые виртуальные сети НЕ являются транзитивными.
- Пиринг между виртуальными сетями Azure должен быть создан между всеми виртуальными сетями, которые должны использовать доверие леса ресурсов Azure AD DS к локальной среде AD DS.
Настройка DNS в локальном домене

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

Выберите Пуск > Администрирование > DNS.

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

Установите флажок Сохранять условную пересылку в Active Directory и реплицировать ее следующим образом: , а затем выберите параметр Все DNS-серверы в этом домене, как показано в следующем примере:

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

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

Создание входящего доверия леса в локальном домене

Для локального домена AD DS требуется входящее доверие леса для управляемого домена. Это доверие необходимо настроить вручную в локальном домене AD DS. Его нельзя создать на портале Azure.

Чтобы настроить входящее доверие в локальном домене AD DS, выполните на рабочей станции управления следующие действия с локальным доменом AD DS:

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

Создание исходящего доверия леса в Azure AD DS

Теперь, когда в локальном домене AD DS настроено разрешение управляемого домена и создано входящее доверие леса, создайте исходящее доверие леса. Это последний шаг для создания отношения доверия между локальным доменом AD DS и управляемым доменом.

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

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

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

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

Укажите по крайней мере два DNS-сервера для локального домена AD DS, например 10.1.1.4 и 10.1.1.5.

Сохраните исходящее доверие леса, когда оно будет готово, нажав кнопку Сохранить.

Если доверие леса больше не требуется для среды, выполните следующие действия, чтобы удалить его из Azure AD DS.

Проверка подлинности ресурсов

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

Локальная проверка подлинности пользователя в лесу ресурсов Azure AD DS

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

Подключитесь к виртуальной машине Windows Server, присоединенной к лесу ресурсов Azure AD DS, используя Бастион Azure и учетные данные администратора Azure AD DS.

Откройте командную строку и выполните команду whoami , чтобы просмотреть различающееся имя пользователя, проходящего проверку подлинности:

Используйте whoami /fqdn в новой командной строке, чтобы просмотреть различающееся имя пользователя, прошедшего проверку подлинности из локальной службы Active Directory.

Доступ локального пользователя к ресурсам в лесу ресурсов Azure AD DS

Используя виртуальную машину Windows Server, присоединенную к лесу ресурсов Azure AD DS, можно протестировать сценарий, в котором пользователи могут получать доступ к ресурсам, размещенным в лесу ресурсов, при проверке подлинности на компьютерах в локальном домене с использованием данных пользователей из локального домена. В следующих примерах показано, как создавать и тестировать различные распространенные сценарии.

Предоставление совместного доступа к файлам и принтерам

Подключитесь к виртуальной машине Windows Server, присоединенной к лесу ресурсов Azure AD DS, используя Бастион Azure и учетные данные администратора Azure AD DS.

Откройте Параметры Windows, затем найдите и откройте страницу Центр управления сетями и общим доступом.

Щелкните Изменить дополнительные параметры общего доступа.

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

Закройте Центр управления сетями и общим доступом.

Создание группы безопасности и добавление участников

Откройте оснастку Пользователи и компьютеры Active Directory.

Щелкните правой кнопкой мыши имя домена, выберите команду Создать, а затем — пункт Organizational Unit (Подразделение).

В поле имени введите LocalObjects, а затем нажмите кнопку ОК.

Выберите и щелкните правой кнопкой мыши LocalObjects в области навигации. Выберите команду Создать, а затем — пункт Группа.

Введите FileServerAccess в поле Имя группы. Для параметра Области действия группы выберите значение Локальная в домене, а затем нажмите кнопку ОК.

В области содержимого дважды щелкните FileServerAccess. Выберите Члены, Добавить, а затем — Расположения.

Выберите локальные доменные службы Active Directory в представлении Расположение, а затем нажмите кнопку ОК.

Введите Пользователи домена в поле Enter the object names to select (Введите имена объектов для выбора). Щелкните Проверить имена, укажите учетные данные для локальных пользователей Active Directory, а затем нажмите кнопку ОК.

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

Создание общей папки для доступа между лесами

Проверка аутентификации между лесами для ресурса

Войдите в систему на компьютере Windows, присоединенном к локальному домену Active Directory, используя учетную запись пользователя из локальной среды Active Directory.

Чтобы проверить разрешение на запись, щелкните правой кнопкой мыши в папке, выберите команду Создать, а затем — пункт Текстовый документ. Используйте имя по умолчанию Новый текстовый документ.

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

Чтобы проверить разрешение на чтение, откройте Новый текстовый документ.

Чтобы проверить разрешение на изменение, добавьте текст в файл и закройте Блокнот. При появлении запроса на сохранение изменений нажмите кнопку Сохранить.

Дальнейшие действия

В этом руководстве вы узнали, как выполнять следующие задачи:
- настройка DNS в локальной среде AD DS для поддержки возможности подключения Azure AD DS;
- создание одностороннего входящего доверия леса в локальной среде AD DS;
- создание одностороннего исходящего доверия леса в Azure AD DS;
- тестирование и проверка отношения доверия для проверки подлинности и доступа к ресурсам.
Дополнительные сведения о типах лесов в Azure AD DS см. в статьях о лесах ресурсов и о том, как работают доверия леса в Azure AD DS.

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

1) Основной контроллер домена, ОС - Windows Server 2012 R2 with GUI, сетевое имя: dc1.

2) Дополнительный контроллер домена (на случай выхода из строя основного), ОС - Windows Server 2012 R2 Core, сетевое имя: dc2.

3) Контроллер домена только для чтения ( RODC ), находящийся в филиале компании за vpn-каналом, ОС - Windows Server 2012 R2 Core, сетевое имя: dc3.

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

Шаг 1: Установка первого контроллера домена. Подготовка.

Перед запуском мастера ролей, серверу необходимо задать сетевое имя и настроить ip-адрес. Сетевое имя - dc1. Настройки TCP/IP укажем как на скриншоте ниже.

Запускаем диспетчер сервера - Server Manager -> Dashboard -> Configure this local server -> Add Role and Features Wizard. На первом экране мастер нам сообщает, что перед тем как продолжить, должен быть установлен сложный пароль администратора, в настройках сети указан статический ip-адрес, установлены последние обновления. Если все это сделано, то нажимаем Next.

На следующем экране, выбираем первый пункт Role-based or feature-based installation (Базовая установка ролей и компонентов). Второй пункт Remote Desktop Service installtion предназначен исключительно для установки роли удаленных рабочих столов.

На экране Select Destination server диспетчер предлагает нам, выбрать сервер из пула или расположенный на VHD-диске. Поскольку у нас пока только один локальный сервер, то нажимаем Next.

Выбираем Active Directory Domain Services (Доменные службы Active Directory), после чего появится окно с предложением добавить роли и компоненты, необходимые для установки роли AD. Нажимаем кнопку Add Features и затем Next.

Обычно, на серверах с AD DS имеет смысл, параллельно разворачивать DHCP Server, поэтому отмечаем его для установки так же. Соглашаемся с установкой компонент. Нажимаем Next.

На экране Features предлагается выбрать дополнительные компоненты. На контроллере домена ничего экстраординарного обычно не требуется, поэтому нажимаем Next.

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

Службы Active Directory Domain Services требуют установленного в сети DNS-сервера. В случае если он не установлен, то роль DNS Server будет предложена для установки.

Так же, службы Active Directory Domain Services требуют установки дополнительных служб пространства имен, файловой и DFS репликации (DFS Namespace, DFS Replication, File Replication). Нажимаем Next.

На последнем экране Confirm installation selection (Подтверждение устанавливаемых компонентов), можно экспортировать конфигурацию в xml-фаил, который поможет быстро установить еще один сервер с идентичными настройками. Для этого потребуется на новом сервере, используя PowerShell, ввести следующую команду:

или если требуется задать новое имя серверу, набираем:

В конце нажимаем Install. Дожидаемся окончания процесса установки.

Шаг 2: Установка первого контроллера домена. Настройка служб Active Directory, DNS, DHCP.

Теперь нажимаем на значок треугольника с восклицательным знаком и выбираем сначала Promote this server to domain controller (Повысить этот сервер до контроллера домена). Позже запустим процесс развертывания DHCP-сервера.

Запустится мастер Active Directory Domain Services Configuration Wizard (Мастер конфигурации доменных служб Active Directory). Доступно, три варианта развертывания, если:

Add a domain controller to an existing domain - добавить дополнительный контроллер домена в существующем домене, используется для резервного или филиального домена.

Выбираем вариант Add New Forest, задаем корневое имя домена, нажимаем Next.

На следующей вкладке можно задать функциональный уровень домена и леса (по умолчанию 2012R2), снять или отметить для установки DNS Server, и задать пароль для режима восстановления службы каталогов (DSRM). Укажем только пароль для DSRM и нажмем Далее.

На следующем шаге DNS Options мастер ругнется, на то, что делегирование для этого DNS-сервера создано не было, потому что не найдена дочерняя зона или запущенный DNS-сервер. Что не удивительно, т.к. роль DNS Server у нас создается в процессе. Нажимаем Next.

Далее в Addional Optional соглашаемся с NetBIOS именем, которое предлагает нам система, жмем Next.

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

На следующем этапе Review Options отображается сводная информация по настройке. Кнопка View Script, позволяет посмотреть Powershell скрипт, при помощи которого, в будущем можно будет произвести настройку доменных служб Active Directory. Нажимаем Next.

После перезагрузки, снова заходим в Server Manager -> Dashboard и запускаем пиктограмму треугольника с восклицательным знаком и выбираем там Complete DHCP Configuration (Завершение конфигурации DHCP).

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

На следующем экране нажимаем Commit что бы завершить процесс авторизации в Active Directory.

Если видим, что Create Security Group - Done и Authorizing DHCP Server - Done, то процесс завершился успешно, нажимаем Close.

Теперь создадим обратную зону в DNS. Обратная зона, позволяет выполнить разрешение FQDN-имен хостов по их IP-адресам. В процессе добавления ролей AD и DNS по умолчанию не создаются, поскольку предполагается, что в сети может существовать другой DNS-сервер, контролирующий обратную зону. Поэтому создадим ее сами, для этого переходим в диспетчер DNS (DNS Manager), на вкладку Reverse Lookup Zones, кликаем правой кнопкой и выбираем New Zone.

Запустится мастер DNS-зоны. Соглашаемся с параметрами по умолчанию, а именно нам предлагается создать основную зону которая будет хранится на этом сервере (Primary Zone) и будет интегрирована в Active Directory (Store the zone in Active Directory..). Нажимаем Next.

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

Для всех DNS-серверов расположенных на контроллере домена в этом лесу (То all DNS servers running on domain controllers in this forest). Репликации во всем лесу Active Directory включая все деревья доменов.

Для всех DNS-серверов расположенных на контроллере домена в этом домене (То all DNS servers running on domain controllers in this domain). Репликация внутри текущего домена и его дочерних доменов.

Для всех контроллеров домена в этом домене (То all domain controllers in this domain). Репликация на все контроллеры домена внутри текущего домена и его дочерних доменов.

На все контроллеры домена в указанном разделе каталога приложений (To all domain controllers specified in the scope of this directory partition). Репликация на все контроллеры домена, но DNS-зона располагается в специальном каталоге приложений. Поле будет доступно для выбора, после создания каталога. Подробнее.

Выбираем вариант по умолчанию, нажимаем Next. Затем выбираем протокол по умолчанию IPv4 и снова жмем Next.

На следующем экране зададим идентификатор сети (Network ID). В нашем случае 192.168.0. В поле Reverse Lookup Zone Name увидим как автоматически подставится адрес зоны обратного просмотра. Нажимаем Next.

На экране Dynamic Update (динамические обновления), выберем один из трех возможных вариантов динамического обновления.

Разрешить только безопасные динамические обновления (Allow Only Secure Dynamic Updates). Это опция доступна, только если зона интегрирована в Active Directory.

Разрешить любые, безопасные и не безопасные динамические обновления (Allow Both Nonsecure And Secure Dynamic Updates). Данный переключатель, позволяет любому клиенту обновлять его записи ресурса в DNS при наличии изменений.

Запретить динамические обновления (Do Not Allow Dynamic Updates). Это опция отключает динамические обновления DNS. Ее следует использовать только при отсутствии интеграции зоны с Active Directory.

Выбираем первый вариант, нажимаем Next и завершаем настройку нажатием Finish.

Еще одна полезная опция, которая обычно настраивается в DNS - это серверы пересылки или Forwarders, основное предназначение которых кэшировать и перенаправлять DNS-запросы с локального DNS-сервера на внешний DNS-сервер в сети интернет, например тот что находится у провайдера. Например мы хотим, что бы локальные компьютеры в нашей доменной сети, в сетевых настройках у которых прописан DNS-сервер (192.168.0.3) смогли получить доступ в интернет, необходимо что бы наш локальный dns-сервер был настроен на разрешение dns-запросов вышестоящего сервера. Для настройки серверов пересылки (Forwarders) переходим в консоль менеджера DNS. Затем в свойствах сервера переходим на вкладку Forwarders и нажимаем там Edit.

Укажем как минимум один IP-адрес. Желательно несколько. Нажимаем ОК.

Теперь настроим службу DHCP. Запускаем оснастку.

Сперва зададим полный рабочий диапазон адресов из которого будут браться адреса для выдачи клиентам. Выбираем Action\New Scope. Запустится мастер добавления области. Зададим имя области.

Далее укажем начальный и конечный адрес диапазона сети.

Далее добавим адреса которые мы хотим исключить из выдачи клиентам. Жмем Далее.

На экране Lease Duration укажем отличное от по умолчанию время аренды, если требуется. Жмем Далее.

Затем согласимся, что хотим настроить опции DHCP: Yes, I want to configure these option now.

Последовательно укажем шлюз, доменное имя, адреса DNS, WINS пропускаем и в конце соглашаемся с активацией области нажатием: Yes, I want to activate this scope now. Finish.

Для безопасной работы службы DHCP, требуется настроить специальную учетную запись для динамического обновления записей DNS. Это необходимо сделать, с одной стороны для того что бы предотвратить динамическую регистрацию клиентов в DNS при помощи административной учетной записи домена и возможного злоупотребления ею, с другой стороны в случае резервирования службы DHCP и сбоя основного сервера, можно будет перенести резервную копию зоны на второй сервер, а для этого потребуется учетная запись первого сервера. Для выполнения этих условий, в оснастке Active Directory Users and Computers создадим учетную запись с именем dhcp и назначим бессрочный пароль, выбрав параметр: Password Never Expires.

Назначим пользователю надежный пароль и добавим в группу DnsUpdateProxy. Затем удалим пользователя из группы Domain Users, предварительно назначив пользователю primary группу "DnsUpdateProxy". Данная учетная запись будет отвечать исключительно за динамическое обновление записей и не иметь доступа не каким другим ресурсам где достаточно базовых доменных прав.

Нажимаем Apply и затем ОК. Открываем снова консоль DHCP. Переходим в свойства протокола IPv4 на вкладку Advanced.

Нажимаем Credentials и указываем там нашего пользователя DHCP.

Нажимаем ОК, перезапускаем службу.

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

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

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

Примечание: Не забывайте что первый созданный домен есть и корневой домен и дерево и лес. То есть первый созданный домен в нашей сети по умолчанию нужно рассматривать и как корневой домен, и как лес и как дерево (три в одном стакане. простите флаконе)

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

Почему так важно что бы DNS службы этих доменов видели друг друга? А потому что в основе Windows Server нахождение (распознавание) контролеров домена происходит с помощью DNS службы. То есть если служба DNS в каком либо домене настроена неверно, то и нахождение данного контролера домена или контроллеров доменов (если их много) будет невозможно. То есть если сказать просто - контроллеры домена видят друг друга с помощью службы DNS. Думаю позже я опишу в отдельной статье процесс нахождения контролеров домена, а пока просто запомните что контроллеры домена "слепы" (ничего не видят в сети) без правильно настроенной службы DNS.

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

Как говорилось уже - доверительные отношения выступают в качестве связывающего звена между лесами, деревьями, доменами. Для администрирования доверительными отношениями используется оснастка Active Directory - домены и доверие, смотрите рисунок 1.

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

Для того что бы настроить пересылку мы заходим в оснастку DNS контроллера домена что расположен на компе под именем server1, становимся на него, правой кнопкой мыши открываем контекстное меню, в контекстном меню выбираем свойства и кликаем на нем. Открывается окно показанное на рисунке 4 и выбираем вкладку "Пересылка".

На этой вкладке нажимаем кнопку "Создать" и пишем имя домена куда мы хотим сделать пересылку. В нашем случае это корневой домен леса xu.com. Тут же на вкладке, чуть ниже в поле "Список IP - серверов пересылки для выбранного домена" - добавляем его IP адрес. В нашем примере это 192.168.0.5.

Итак после того как разобрались с DNS серверами и убедились что они видят друг друга переходим к созданию доверительных отношений и переходим к оснастке "Домены и доверие" показанное на рисунке1.

Далее если мы хотим что бы эти два леса (rk.com и xu.com) были соединены с друг другом посредством транзитивных доверительных отношений то нам необходимо установить режим функционирования леса на уровень "Windows Server 2003" (о режимах функционирования леса и домена смотри здесь). Поэтому мы в оснастке "Домены и доверие" становимся на верхнюю надпись "Active Directory - домены и доверие" и открываем правой кнопкой контекстное меню, смотрите рисунок 5.

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

После того как повысили режим работы леса до максимально возможного а именно до "Windows Server 2003", в познавательных целях повысим и режим работы домена до уровня "Windows Server 2003". Для этого становимся на корневой домен и открываем контекстное меню, смотрите рисунок 7.

Когда мы убедились что у нас леса (rk.com and xu.com)и домены работают в функциональном режиме "Windows Server 2003", приступаем к созданию транзитивных доверительных отношений между лесами.

Внимание! Если бы хоть один из лесов доменов находится на функциональном уровне "Windows 2000", то леса доменов могут быть соединены только внешними доверительными отношениями.

В оснастке "Домены и доверие" становимся на имени корневого домена, в нашем случае это rk.com и открываем контекстное меню правой клавишей мыши. Откроется окно показанное не рисунке 8. переходим на вкладку "Доверия".

На данной вкладке нажимаем клавишу "Создать доверие". После того как нажали на данную клавишу открывается "Мастер создания отношений доверия", смотрите рисунок 9.

Нажимаем далее. Открывается окно показанное на рисунке 10.

Открывается окно с предложениями о выборе типа доверия, смотрите рисунок 11.

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

Открывается следующее окно с предложениями о выборе направления доверия, смотрите рисунок 12.

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

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

Открывается окно в котором проверяет нас на наличие прав в другом домене, смотрите рисунок 14.

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

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

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

Открывается окно показанное на рисунке 17, в котором описываются все "проделки", что были нами сделаны и что из этого получилось.

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

Открывается еще одно окно показанное на рисунке 18.

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

Жмем далее. Открывается окно показанное на рисунке 20, аналогичное рисунку 19, только связанное с входящим доверием.

Жмем далее. Открывается окно завершения мастера создания отношений доверия, рисунок 21.

Читайте также: