Настройка dns в лесу доменов
В своё время открыл для себя простую истину: хочешь запомнить что-то — веди конспект (даже при чтении книги), а хочешь закрепить и систематизировать — донеси до людей (напиши статью). Поэтому, после двух лет работы в системной интеграции (сфере, которую я в бытность свою системным администратором, считал просто рогом изобилия для жаждущих прокачки специалистов), когда я понял, что знания постепенно вытесняются навыками правки документации и конфигурированию по мануалам и инструкциям, для поддержания формы я начал писать статьи о базовых вещах. Например вот — о DNS. Делал тогда я это больше для себя, но подумал — вдруг кому пригодится.
Сервис в современных сетях если не ключевой, то один из таковых. Те, для кого служба DNS — не нова, первую часть могут спокойно пропустить.
Содержание:
(анкеров нет, поэтому содержание без ссылок)
1. Основные сведения
DNS — это база данных, содержащая, в основном, информацию о сопоставлении имён сетевых объектов их IP-адресам. «В основном» — потому что там и ещё кое-какая информация хранится. А точнее, ресурсные записи (Resource Records — RR) следующих типов:
А — то самое сопоставление символьного имени домена его IP адресу.
АААА — то же что А, но для адресов IPv6.
CNAME — Canonical NAME — псевдоним. Если надо чтобы сервер с неудобочитаемым именем, типа nsk-dc2-0704-ibm, на котором вертится корпоративный портал, откликался также на имя portal, можно создать для него ещё одну запись типа А, с именем portal и таким же IP-адресом. Но тогда, в случае смены IP адреса (всякое бывает), нужно будет пересоздавать все подобные записи заново. А если сделать CNAME с именем portal, указывающий на nsk-dc2-0704-ibm, то ничего менять не придётся.
MX — Mail eXchanger — указатель на почтовый обменник. Как и CNAME, представляет собой символьный указатель на уже имеющуюся запись типа A, но кроме имени содержит также приоритет. MX-записей может быть несколько для одного почтового домена, но в первую очередь почта будет отправляться на тот сервер, для которого указано меньшее значение в поле приоритета. В случае его недоступности — на следующий сервер и т.д.
NS — Name Server — содержит имя DNS-сервера, ответственного за данный домен. Естественно для каждой записи типа NS должна быть соответствующая запись типа А.
SOA — Start of Authority — указывает на каком из NS-серверов хранится эталонная информация о данном домене, контактную информацию лица, ответственного за зону, тайминги хранения информации в кэше.
SRV — указатель на сервер, держатель какого-либо сервиса (используется для сервисов AD и, например, для Jabber). Помимо имени сервера содержит такие поля как Priority (приоритет) — аналогичен такому же у MX, Weight (вес) — используется для балансировки нагрузки между серверами с одинаковым приоритетом — клиенты выбирают сервер случайным образом с вероятностью на основе веса и Port Number — номер порта, на котором сервис «слушает» запросы.
Все вышеперечисленные типы записей встречаются в зоне прямого просмотра (forward lookup zone) DNS. Есть ещё зона обратного просмотра (reverse lookup zone) — там хранятся записи типа PTR — PoinTeR — запись противоположная типу A. Хранит сопоставление IP-адреса его символьному имени. Нужна для обработки обратных запросов — определении имени хоста по его IP-адресу. Не требуется для функционирования DNS, но нужна для различных диагностических утилит, а также для некоторых видов антиспам-защиты в почтовых сервисах.
Кроме того, сами зоны, хранящие в себе информацию о домене, бывают двух типов (классически):
Основная (primary) — представляет собой текстовый файл, содержащий информацию о хостах и сервисах домена. Файл можно редактировать.
Дополнительная (secondary) — тоже текстовый файл, но, в отличие от основной, редактированию не подлежит. Стягивается автоматически с сервера, хранящего основную зону. Увеличивает доступность и надёжность.
Для регистрации домена в интернет, надо чтоб информацию о нём хранили, минимум, два DNS-сервера.
В Windows 2000 появился такой тип зоны как интегрированная в AD — зона хранится не в текстовом файле, а в базе данных AD, что позволяет ей реплицироваться на другие контроллеры доменов вместе с AD, используя её механизмы репликации. Основным плюсом данного варианта является возможность реализации безопасной динамической регистрации в DNS. То есть записи о себе могут создать только компьютеры — члены домена.
В Windows 2003 появилась также stub-зона — зона-заглушка. Она хранит информацию только о DNS-серверах, являющихся полномочными для данного домена. То есть, NS-записи. Что похоже по смыслу на условную пересылку (conditional forwarding), которая появилась в этой же версии Windows Server, но список серверов, на который пересылаются запросы, обновляется автоматически.
Итеративный и рекурсивный запросы.
DNS-сервер обращается к одному из корневых серверов интернета, которые хранят информацию о полномочных держателях доменов первого уровня или зон (ru, org, com и т.д.). Полученный адрес полномочного сервера он сообщает клиенту.
Клиент обращается к держателю зоны ru с тем же запросом.
DNS яндекса возвращает нужный адрес.
Такая последовательность событий редко встречается в наше время. Потому что есть такое понятие, как рекурсивный запрос — это когда DNS-сервер, к которому клиент изначально обратился, выполняет все итерации от имени клиента и потом возвращает клиенту уже готовый ответ, а также сохраняет у себя в кэше полученную информацию. Поддержку рекурсивных запросов можно отключить на сервере, но большинство серверов её поддерживают.
Клиент, как правило, обращается с запросом, имеющим флаг «требуется рекурсия».
Заголовок состоит из следующих полей:
Идентификация — в это поле клиентом генерируется некий идентификатор, который потом копируется в соответствующее поле ответа сервера, чтобы можно было понять на какой запрос пришёл ответ.
Флаги — 16-битовое поле, поделенное на 8 частей:
Вторая строка — ответ сервера: на указанный исходный порт с указанным идентификатором запроса. Ответ содержит одну RR (ресурсную запись DNS), являющуюся ответом на запрос, 2 записи полномочий и 5 каких-то дополнительных записей. Общая длина ответа — 196 байт.
3. TCP и UDP
Также передача зон от основных серверов к дополнительным осуществляется по TCP, поскольку в этом случае передаётся куда больше 512 байт.
4. DNS в Windows Server 2008 и 2012
В Windows 2008 появились следующие возможности:
Фоновая загрузка зон
- определяются все зоны, которые должны быть загружены;
- из файлов или хранилища доменных служб Active Directory загружаются корневые ссылки;
- загружаются все зоны с файловой поддержкой, то есть зоны, хранящиеся в файлах, а не в доменных службах Active Directory;
- начинается обработка запросов и удаленных вызовов процедур (RPC);
- создаются один или несколько потоков для загрузки зон, хранящихся в доменных службах Active Directory.
Поскольку задача загрузки зон выполняется отдельными потоками, DNS-сервер может обрабатывать запросы во время загрузки зоны. Если DNS-клиент запрашивает данные для узла в зоне, который уже загружен, DNS-сервер отправляет в ответ данные (или, если это уместно, отрицательный ответ). Если запрос выполняется для узла, который еще не загружен в память, DNS-сервер считывает данные узла из доменных служб Active Directory и обновляет соответствующим образом список записей узла.
Поддержка IPv6-адресов
Протокол Интернета версии 6 (IPv6) определяет адреса, длина которых составляет 128 бит, в отличие от адресов IP версии 4 (IPv4), длина которых составляет 32 бита.
DNS-серверы с ОС Windows Server 2008 теперь полностью поддерживают как IPv4-адреса, так и IPv6-адреса. Средство командной строки dnscmd также принимает адреса в обоих форматах. Cписок серверов пересылки может содержать и IPv4-адреса, и IPv6-адреса. DHCP-клиенты также могут регистрировать IPv6-адреса наряду с IPv4-адресами (или вместо них). Наконец, DNS-серверы теперь поддерживают пространство имен домена ip6.arpa для обратного сопоставления.
Изменения DNS-клиента
Разрешение имен LLMNR
Клиентские компьютеры DNS могут использовать разрешение имен LLMNR (Link-local Multicast Name Resolution), которое также называют многоадресной системой DNS или mDNS, для разрешения имен в сегменте локальной сети, где недоступен DNS-сервер. Например, при изоляции подсети от всех DNS-серверов в сети из-за сбоя в работе маршрутизатора клиенты в этой подсети, поддерживающие разрешение имен LLMNR, по-прежнему могут разрешать имена с помощью одноранговой схемы до восстановления соединения с сетью.
Кроме разрешения имен в случае сбоя в работе сети функция LLMNR может также оказаться полезной при развертывании одноранговых сетей, например, в залах ожидания аэропортов.
Изменения Windows 2012 в части DNS коснулись, преимущественно, технологии DNSSEC (обеспечение безопасности DNS за счет добавления цифровых подписей к записям DNS), в частности — обеспечение динамических обновлений, которые были недоступны, при включении DNSSEC в Windows Server 2008.
5. DNS и Active directory
Active Directory очень сильно опирается в своей деятельности на DNS. С его помощью контроллеры домена ищут друг друга для репликации. С его помощью (и службы Netlogon) клиенты определяют контроллеры домена для авторизации.
Для обеспечения поиска, в процессе поднятия на сервере роли контроллера домена, его служба Netlogon регистрирует в DNS соответствующие A и SRV записи.
SRV записи регистрируемые службой Net Logon:
_ldap._tcp.DnsDomainName
_ldap._tcp.SiteName._sites.DnsDomainName
_ldap._tcp.dc._msdcs.DnsDomainName
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName
_ldap._tcp.pdc._msdcs.DnsDomainName
_ldap._tcp.gc._msdcs.DnsForestName
_ldap._tcp.SiteName._sites.gc._msdcs. DnsForestName
_gc._tcp.DnsForestName
_gc._tcp.SiteName._sites.DnsForestName
_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName
_kerberos._tcp.DnsDomainName.
_kerberos._udp.DnsDomainName
_kerberos._tcp.SiteName._sites.DnsDomainName
_kerberos._tcp.dc._msdcs.DnsDomainName
_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName
_kpasswd._tcp.DnsDomainName
_kpasswd._udp.DnsDomainName
Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV. Существуют следующие службы:
_ldap — Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2000+ или другими LDAP-серверами;
_kerberos — SRV-записи _kerberos идентифицируют все ключевые центры распределения (KDC — Key Distribution Centers) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;
_kpassword — идентифицирует серверы изменения паролей kerberos в сети;
_gc — запись, относящаяся к функции глобального каталога в Active Directory.
В поддомене _mcdcs регистрируются только контроллеры домена Microsoft Windows Server. Они делают и основные записи и записи в данном поддомене. Не-Microsoft-службы делают только основные записи.
Записи, содержащие идентификатор сайта SiteName, нужны для того чтобы клиент мог найти контроллер домена для авторизации в своём сайте, а не лез авторизовываться в другой город через медленные каналы.
DomainGuid — глобальный идентификатор домена. Запись, содержащщая его, нужна на случай переименования домена.
Как происходит процесс поиска DC
Во время входа пользователя, клиент инициирует DNS-локатор, при помощи удалённого вызова процедуры (Remote Procedure Call — RPC) службой NetLogon. В качестве исходных данных в процедуру передаются имя компьютера, название домена и сайта.
Служба посылает один или несколько запросов с помощью API функции DsGetDcName()
DNS сервер возвращает запрошенный список серверов, рассортированный согласно приоритету и весу. Затем клиент посылает LDAP запрос, используя UDP-порт 389 по каждому из адресов записи в том порядке, как они были возвращены.
Все доступные контроллеры доменов отвечают на этот запрос, сообщая о своей работоспособности.
После обнаружения контроллера домена, клиент устанавливает с ним соединение по LDAP для получения доступа к Active Directory. Как часть их диалога, контроллер домена определяет к в каком сайте размещается клиент, на основе его IP адреса. И если выясняется, что клиент обратился не к ближайшему DC, а, например, переехал недавно в другой сайт и по привычке запросил DC из старого (информация о сайте кэшируется на клиенте по результатам последнего успешного входа), контроллер высылает ему название его (клиента) нового сайта. Если клиент уже пытался найти контроллер в этом сайте, но безуспешно, он продолжает использовать найденный. Если нет, то инициируется новый DNS-запрос с указанием нового сайта.
Служба Netlogon кэширует информацию о местонахождении контроллера домена, чтобы не инициировать всю процедуру при каждой необходимости обращения к DC. Однако, если используется «неоптимальный» DC (расположенный в другом сайте), клиент очищает этот кэш через 15 минут и инициирует поиски заново (в попытке найти свой оптимальный контроллер).
Если у комьютера отсутствует в кэше информация о его сайте, он будет обращаться к любому контроллеру домена. Для того чтобы пресечь такое поведение, на DNS можно настроить NetMask Ordering. Тогда DNS выдаст список DC в таком порядке, чтобы контроллеры, расположенные в той же сети, что и клиент, были первыми.
Пример: Dnscmd /Config /LocalNetPriorityNetMask 0x0000003F укажет маску подсети 255.255.255.192 для приоритетных DC. По умолчанию используется маска 255.255.255.0 (0x000000FF)
Для возможности аутентификации с использованием учетных записей из нескольких доменов, необходимо, чтобы были доверительные отношения между последними. При создании домена в структуре леса, доверие выстраивается автоматически. Но если мы хотим объединить два домена разных организаций или которые раньше работали независимо друг от друга, то необходимо настроить доверительные отношения.
Мы будем рассматривать процесс настройки на примере двустороннего транзитивного доверия между доменами primary.local (192.168.0.15) и secondary.local (192.168.0.16). Саму настройку разделим на 2 этапа — конфигурирование DNS и создания доверий. В качестве операционной системы по данной инструкции можно настроить Windows Server 2008 / 2012 / 2016 / 2019.
Предварительные требования
Для работы с этим учебником требуются следующие ресурсы и разрешения:
Связанный с вашей подпиской клиент Azure Active Directory, синхронизированный с локальным или облачным каталогом.
Управляемый домен Azure AD DS, созданный с использованием леса ресурсов и настроенный в клиенте Azure AD.
Управляемый домен нужно обязательно создавать с использованием леса ресурсов. Параметр по умолчанию создает лес пользователя. Только леса ресурсов могут создавать отношения доверия к локальным средам AD DS.
Для управляемого домена также необходимо использовать как минимум SKU уровня Корпоративный. При необходимости измените номер SKU для управляемого домена.
В этом учебнике вы создадите и настроите исходящее доверие леса из Azure AD DS с помощью портала Azure. Чтобы начать работу, войдите на портал Azure. Для изменения экземпляра Azure AD DS необходимы роли Администратор приложений и Администратор групп Azure AD в клиенте.
Создание исходящего доверия леса в Azure AD DS
Теперь, когда в локальном домене AD DS настроено разрешение управляемого домена и создано входящее доверие леса, создайте исходящее доверие леса. Это последний шаг для создания отношения доверия между локальным доменом AD DS и управляемым доменом.
Чтобы создать исходящее доверие для управляемого домена на портале Azure, выполните следующие действия.
В меню в левой части управляемого домена выберите Отношения доверия, а затем нажмите кнопку + Добавить, чтобы добавить доверие.
Если пункт меню Отношения доверия не отображается, найдите в разделе Свойства элемент Тип леса. Создавать доверия можно только для лесов ресурсов. Если тип леса — Пользователь, создание доверий невозможно. Сейчас нет возможности изменять тип леса управляемого домена. Необходимо удалить и повторно создать управляемый домен в качестве леса ресурсов.
Укажите тот же пароль отношения доверия, который использовался для настройки входящего доверия леса для локального домена AD DS в предыдущем разделе.
Укажите по крайней мере два DNS-сервера для локального домена AD DS, например 10.1.1.4 и 10.1.1.5.
Сохраните исходящее доверие леса, когда оно будет готово, нажав кнопку Сохранить.
Если доверие леса больше не требуется для среды, выполните следующие действия, чтобы удалить его из Azure AD DS.
Создание входящего доверия леса в локальном домене
Для локального домена AD DS требуется входящее доверие леса для управляемого домена. Это доверие необходимо настроить вручную в локальном домене AD DS. Его нельзя создать на портале Azure.
Чтобы настроить входящее доверие в локальном домене AD DS, выполните на рабочей станции управления следующие действия с локальным доменом AD DS:
Если доверие леса больше не требуется для среды, выполните следующие действия, чтобы удалить его из локального домена.
- Выберите Пуск>Средства администрирования>Active Directory — домены и доверие.
- Нажмите правой кнопкой мыши домен, например onprem.contoso.com, и выберите Свойства.
- Выберите вкладку Доверия, затем Domains that trust this domain (incoming trusts) (Домены, которые доверяют этому домену (входящие отношения доверия)), щелкните доверие, которое нужно удалить, а затем нажмите Удалить.
- На вкладке "Доверия" в разделе Domains trusted by this domain (outgoing trusts) (Домены, которым доверяет этот домен (исходящие отношения доверия)) щелкните доверие, которое нужно удалить, а затем нажмите "Удалить".
- Щелкните Нет, удалить отношение доверия только в локальном домене.
Внешнее или доверие леса
Внешнее или нетранзитивное отношение устанавливается между двумя доменами напрямую вне леса.
Доверие леса или транзитивное отношение связывает леса и все их домены.
Проверка подлинности ресурсов
Следующие распространенные сценарии позволяют убедиться, что доверие леса правильно проверяет подлинность пользователей и доступ к ресурсам:
Настройка доверительных отношений
После настройки DNS можно переходить к созданию доверительных отношений.
В домене primary.local открываем Диспетчер серверов - кликаем по Средства - Active Directory - домены и доверие:
В открывшемся окне кликаем правой кнопкой по нашему домену - Свойства:
Переходим на вкладку Отношения доверия - кликаем по Создать отношение доверия. :
Нажимаем Далее - вводим имя для второго домена (secondary.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, прежде чем начинать работу.
Определяемся с типом доверительных отношений
Доверительные отношению могут быть разных типов. Перед тем, как их настроить, нужно понять, какие нам требуются.
Одностороннее или двустороннее
Определяют направление доверия одного домена к другому.
В односторонних отношениях, только один домен доверяет другому. В результате, на компьютерах одного из доменов можно будет авторизоваться с использованием пользователей другого. При создании такого доверия нужно указать также направление (входящее или исходящее) — оно определяет чьи пользователи смогут проходить аутентификацию на чьем домене.
В двусторонних отношениях домены доверяют друг другу. Таким образом, аутентификация выполняется на всех компьютерах под пользователями любого из доменов.
Настройка службы DNS-сервера
Откройте диспетчер сервера, щелкните Сервис и выберите DNS.
Настройте данные DNS в том виде, в котором они существовали до критического сбоя. Пример:
После настройки DNS можно ускорить регистрацию записей NETLOGON.
Безопасные динамические обновления работают только при наличии сервера глобального каталога.
В данной заметке, подробно рассмотрим процесс внедрения первого контроллера домена на предприятии. А всего их будет три:
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 в локальной среде AD DS для поддержки возможности подключения Azure AD DS;
- создание одностороннего входящего доверия леса в локальной среде AD DS;
- создание одностороннего исходящего доверия леса в Azure AD DS;
- тестирование и проверка отношения доверия для проверки подлинности и доступа к ресурсам.
Дополнительные сведения о типах лесов в Azure AD DS см. в статьях о лесах ресурсов и о том, как работают доверия леса в Azure AD DS.
Если роль DNS-сервера не установлена на контроллере домена, который восстанавливается из резервной копии, необходимо установить и настроить DNS-сервер.
На DNS домена primary.local
Открываем Диспетчер серверов - кликаем по Средства - DNS:
В открывшемся окне выбираем нужный сервер, если их несколько - раскрываем его - кликаем правой кнопкой мыши по Серверы условной пересылки - Создать сервер условной пересылки:
В «DNS-домен» пишем второй домен (в нашем случае, secondary.local), затем задаем его IP-адрес, ставим галочку Сохранять условный сервер пересылки в Active Directory и реплицировать ее следующим образом - выбираем Все DNS-серверы в этом домене:
Открываем командную строку и вводим команду:
Мы должны получить ответ на подобие:
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
Name: secondary.local
Address: 192.168.0.16
Настройка DNS в локальном домене
Чтобы правильно разрешить управляемый домен из локальной среды, может потребоваться добавить серверы пересылки к существующим DNS-серверам. Если в локальной среде не настроено взаимодействие с управляемым доменом, выполните следующие действия на рабочей станции управления для локального домена AD DS.
Выберите Пуск>Администрирование>DNS.
Выберите Серверы условной пересылки, щелкните правой кнопкой мыши и нажмите Создать сервер условной пересылки.
Установите флажок Сохранять условную пересылку в Active Directory и реплицировать ее следующим образом: , а затем выберите параметр Все DNS-серверы в этом домене, как показано в следующем примере:
Если сервер условной пересылки хранится в лесу, а не в домене, его работа будет завершаться ошибкой.
Чтобы создать сервер условной пересылки, нажмите кнопку ОК.
Установка и Настройка службы DNS-сервера
Выполните этот шаг для каждого восстановленного контроллера домена, который не работает в качестве DNS-сервера после завершения восстановления.
если контроллер домена, восстановленный из резервной копии, работает Windows Server 2008 R2, необходимо подключить контроллер домена к изолированной сети, чтобы установить DNS-сервер. Затем подключите каждый восстановленный DNS-сервер к взаимно общей изолированной сети. Выполните команду repadmin/реплсум, чтобы убедиться, что репликация между восстановленными DNS-серверами функционирует. После проверки репликации можно подключить восстановленные контроллеры домена к рабочей сети, если роль DNS-сервера уже установлена, можно применить исправление, которое позволит запустить DNS-сервер, когда сервер не подключен к сети. Необходимо встроить исправление в образ установки операционной системы во время процессов автоматической сборки. Дополнительные сведения об этом исправлении см. в статье 975654 базы знаний Майкрософт ( ).
Выполните следующие действия по установке и настройке.
Настройка DNS
Для построения доверия необходимо, чтобы контроллеры домена видели друг друга. Все запросы на поиск узлов в AD выполняются через службы доменных имен. Таким образом, в нашем примере, мы должны сконфигурировать условную пересылку на DNS обоих доменов. Также важно, чтобы между контроллерами была сетевая доступность — по сети они должны видеть друг друга.
На DNS домена secondary.local
Действия, которые делаем на втором сервере DNS, во многом, аналогичны.
Открываем Диспетчер серверов - Средства - DNS:
Раскрываем сервер - Серверы условной пересылки - Создать сервер условной пересылки:
На данном шаге небольшие изменения. В «DNS-домен» пишем первый домен (primary.local), затем задаем его IP-адрес (192.168.0.15), ставим галочку Сохранять условный сервер пересылки в Active Directory и реплицивовать ее следующим образом - выбираем Все DNS-серверы в этом домене:
В командной строке второго сервера проверяем настройку:
Мы должны получить ответ на подобие:
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
Name: primary.local
Address: 192.168.0.15
Рекомендации по работе с сетями
Для виртуальной сети, в которой размещен лес ресурсов 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.
Доступ локального пользователя к ресурсам в лесу ресурсов 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-сервера с помощью диспетчер сервера
- Откройте диспетчер сервера и щелкните Добавить роли и компоненты.
- В мастере добавления ролей, если появится страница Начало, нажмите кнопку Далее.
- На экране тип установки выберите Установка на основе ролей или компонентов и нажмите кнопку Далее.
- На экране выбора сервера выберите сервер и нажмите кнопку Далее.
- На экране роли сервера выберите DNS-сервер, при появлении запроса щелкните Добавить компоненты и нажмите кнопку Далее.
- На экране компонентов нажмите кнопку Далее.
- Прочтите сведения на странице DNS-сервер и нажмите кнопку Далее.
- На странице Подтверждение убедитесь, что роль DNS-сервера будет установлена, и нажмите кнопку установить.
Локальная проверка подлинности пользователя в лесу ресурсов Azure AD DS
У вас должна быть виртуальная машина Windows Server, присоединенная к управляемому домену. Используйте эту виртуальную машину для тестирования того, что локальный пользователь может пройти проверку подлинности на виртуальной машине. При необходимости создайте виртуальную машину Windows и присоедините ее к управляемому домену.
Подключитесь к виртуальной машине Windows Server, присоединенной к лесу ресурсов Azure AD DS, используя Бастион Azure и учетные данные администратора Azure AD DS.
Откройте командную строку и выполните команду whoami , чтобы просмотреть различающееся имя пользователя, проходящего проверку подлинности:
Используйте whoami /fqdn в новой командной строке, чтобы просмотреть различающееся имя пользователя, прошедшего проверку подлинности из локальной службы Active Directory.
Читайте также: