Название локального домена. Правильно называем домен Active Directory

Вчера, к нам в студию, поступило письмо от нашего постоянного читателя Андрея, с вопросом:

С удовольствием читаю ваш блог, много полезного для себя узнал, хотел узнать ваше мнение по поводу имени домена Active Directory, многие пишут что называть стоит его *организация*.local, а кто-то пишет что стоит назвать так-же как и домен.

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

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

1. Домен с именем example.local

Лидером нашего хит-парада является именование домена с окончанием на local. Существуют и другие вариации на эту тему, например test , firma , factory , nn , loc , и так далее. Сейчас даже уже и не вспомнишь откуда пошла такая любовь, во всех своих книгах компания Microsoft всегда использует свои именование вида contoso.com , где мы четко видим формат именования домена . Однако на протяжении почти 10 лет домен .local занимал лидирующие позиции. Ситуация стала выравниваться с приходом сервисов использующих в своей работе SSL сертификаты . Где использование доменов «пофиг и так сойдет» становится не возможным. Смотрите, предположим, что ваша компания использует внутри организации Exchange server , которому необходим ssl сертификат для шифрования клиентских подключений. Согласно вашему сценарию для реализации этой задачи вам необходим сертификат внешнего центра сертификации , в котором необходимо указать все имена серверов используемых для внешнего подключения. Казалось бы что такого, записываем все имена серверов и подаем заявку на выпуск сертификатов, но есть одно но. С именем такого домена вы не сможете пройти валидацию , так как домен «пофиг и так сойдет» не существует и на попытку объяснить внешнему центру сертификации, что вам в SAN нужно засунуть FQDN имя не существующего домена получите мягкий отказ:

It’s not possible, we issue only certificates for real domain names.

Но существует еще одна неприятность. Использование доменного имени не принадлежащего вам в имени домена может привести к плачевным последствиям. Представьте ситуацию если зона local будет иметь статус публичной. Как зона com или ru . Дальше я думаю продолжать не стоит 🙂

2. Имя домена совпадает с внешним именем домена

Второе место нашего хит-парада. Не смотря на то, что такой сценарий является менее популярным, он все же имеет право на жизнь. Кроме того, что в ближайшем будущем вы все же получите некоторые неудобства при обслуживании сети, больше вам ничего не угрожает. Основной проблемой в этом сценарии будет то, что вам придется поддерживать два DNS сервера: внутренний и внешний . При таком условии компьютеры находящиеся внутри сети будут использовать для разрешения имен внутренний DNS сервер, а компьютера за периметром компании внешний. Предположим ваш домен носит гордое название example.com . В DMZ зоне у вас находится сайт компании с именем example.com . В описанном сценарии выше компьютеры находящиеся внутри организации не смогут получить к нему доступ ввиду того что для них example.com это имя домена и при вводе этого адреса в браузере они будут попадать на контроллер домена . Как я уже отметил выше кроме неудобства это ни к чему не приведет. Вы всегда можете использовать костыли, которые будут перебрасывать вас на внешний сайт, но согласитесь это не нужная двойная работа, либо внутри сети использовать имя сайта начинающееся с www , либо снаружи.

3. Имя домена из одного слова

Пожалуй самый не правильный вариант из приведенных выше. Одноуровневые домены: Single-label domain — это домен, который содержит только одну составляющую . По всей видимости их начали использовать во времена NT, когда компания Microsoft переняла удачный опыт компании Novell. Так сложилось, что изначально я был администратором FreeBSD и большого парка серверов NetWare начиная с версии 4.11, так вот в те стародавние времена NetWare использовала в своей работе Bindery, которая как раз имена схему одноуровнего домена , которую потом и переняла компания Microsoft.

Best practices

Пора подвести итог. Какое же именование домена использовать? Только домен третьего уровня в домене которым вы владеете . Не стоит использовать чужие более красивые доменные имена:-). Пример такого домена вы можете увидеть ниже.

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

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

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

• Функциональный уровень леса Active Directory . Выполнять задачи по переименованию доменов можно лишь в том случае, если все домены в лесу оснащены как минимум операционной системой Windows Server 2003 (в этом случае по редакциям нет никаких ограничений). Более того, функциональный уровень должен быть повышен по меньшей мере до уровня Windows Server 2003. То есть, если у вас в лесу выбран функциональный уровень Windows Server 2000, то выполнение следующей операции попросту станет невозможным;
• Расположение домена . В лесу Active Directory может быть разный уровень доменов. То есть, могут быть либо отдельный домен, либо лес может включать дочерние домены. В том случае если вы будете менять расположение контроллера домена внутри леса, вам придется создать доверительные отношения;
• Зона DNS . Еще до выполнения операции переименования домена вам необходимо создать новую зону DNS;
• Административные учетные данные . Для выполнения операции переименования домена вы должны выполнить вход в систему под административной учетной записью, которая является членом группы администраторов предприятия (Enterprise Admins);
• Серверы распределенной файловой системы (DFS) . Если в вашей корпоративной среде развернуты службы DFS или настроены перемещаемые профили, то обратите внимание на то, что корневые DFS-серверы должны работать, как минимум, под управлением операционной системы Windows Server 2000 с пакетом обновления 3 или под более современными версиями операционных системам;
• Несовместимость с серверами Microsoft Exchange . Самый неприятный момент заключается в том, что если в вашем лесу Active Directory развернут почтовый сервер Microsoft Exchange Server 2003 Service Pack 1, то переименование домена будет выполнено без каких-либо проблем, но учетная запись пользователя, под которой будет выполняться сам процесс переименование домена должна быть членом группы Full Exchange Administrator. Все более современные почтовые серверы (включая Exchange Server 2016) несовместимы с операциями переименования доменов.

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

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

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

Процесс переименования домена Active Directory

Для начала, для того чтобы проверить первоначальное имя вашего домена, вы можете открыть окно свойств системы. Как видно на соответствующей иллюстрации, мой домен называется «Biopharmaceutic.local»:

Рис. 1. Проверка изначального имени домена Active Directory

Теперь следует создать новую зону DNS «biopharm.local» для того чтобы после успешного выполнения переименования домена ваши рядовые серверы и клиенты могли без проблем присоединиться к новому доменному имени. Для этого откройте «Диспетчер DNS » (DNS Manager ) и находясь в «Зоне прямого просмотра » (Forward Lookup Zone ) выберите опцию оп созданию новой зоны. По сути, зона создается как обычно: на первой странице мастера создания новой зоны следует прочитать вступительную информацию и перейти ко второй странице. На странице типа зоны выберите основную зону (Primary Zone ) и обратите внимание на то, чтобы была активирована опция сохранения зоны в Active Directory. На странице области репликации зоны следует оставить опцию, выбранную по умолчанию – «Для всех DNS-серверов, работающих на контроллерах домена в этом домене: Biopharmaceutic.local » (To all DNS servers running on domain controllers in this domain: Biopharmaceutic.local ). На странице имени зоны следует указать новое имя домена (biopharm.local), а на странице динамического обновления также оставьте опцию «Разрешить только безопасные динамические обновления (рекоменд. для Active Directory) » (Allow only secure dynamic updates (recommended for Active Directory) ), которая выбрана по умолчанию. Несколько этапов создания новой зоны вы можете увидеть ниже:

Рис. 2. Создание новой зоны DNS

Следующим этапом переименования домена будет генерация описания текущего состояния леса. По сути, это первая операция по переименованию домена, в которой будет использоваться утилита командной строки Rendom . При помощи этой утилиты будет сгенерировано текстовое описания вашей текущей структуры леса в виде XML-файла с именем Domainlist.xml. Этот файл содержит список всех разделов каталога домена, а также разделов каталога приложений, которые находятся в вашем лесу Active Directory. Каждая запись для каждого раздела каталога домена и приложения ограничена тегами XML и . Более того, каждая запись содержит данные, включающие глобальный уникальный идентификатор объекта (GUID) корневого объекта раздела, имя DNS домена или каталога приложений, а также имя NetBIOS для домена.

Для создания такого файла следует под соответствующей учетной записью открыть командную строку и в ней выполнить команду «random /list ». Сгенерированный файл будет сохранен в корневом каталоге учетной записи вашего пользователя. Далее вам нужно будет открыть этот файл при помощи любого текстового редактора.

Внутри этого файла вам нужно изменить имя домена внутри секции, которая ограничена тегами и и имя NetBIOS внутри тегов и ). Обязательно обратите внимание на то, что вы не должны менять идентификатор GUID внутри соответствующих тегов.

На следующей иллюстрации вы увидите процесс выполнения вышеупомянутой команды, расположение файла Domainlist.xml и изменения для первой секции этого файла. В моем случае имя домена в этом конфигурационном будет изменено 4 раза:

Рис. 3. Генерация и изменение файла Domainlist.xml

Для того чтобы удостовериться в том, что вы внесли в соответствующий файл требуемые изменения, вы можете выполнить команду «rendom /showforest ». Как видите на следующей иллюстрации, у меня все записи изменились на «Bopharm»:

Рис. 4. Просмотр потенциальных изменений

При выполнении следующей команды (rendom /upload ) утилита Rendom переводит новую структуру леса, указанную в отредактированном файле, в последовательность инструкций по обновлению каталога, которые будут запускаться локально и удаленно на каждом контроллере домена в лесу. Если говорить в общих чертах, то на этом этапе в разделе каталога конфигурации мастера именования доменов будут внесены изменения для переименования домена Active Directory. Помимо этого, будет создан файл Dclist.xml, который используется для отслеживания прогресса и состояния каждого контроллера домена в лесу для операции переименования домена. Между прочим, в этот момент утилита Rendom замораживает ваш лес Active Directory от внесения любых изменений в его конфигурацию. Процесс выполнения этой команды виден ниже:

Рис. 5. Выполнение команды rendom /upload

Следующая команда выполняется для проверки готовности контроллеров домена перед операцией по переименованию домена. Во время выполнения этого этапа вы должны запустить команду подготовительной проверки на каждом контроллере домена в лесу . Это необходимо для того, чтобы быть уверенным, что база данных Active Directory на каждом контроллере домена в лесу находится в правильном состоянии и готова выполнить изменения, которые позволят переименовать ваш домен. Следовательно, выполните команду «rendom /prepare », как это сделано на следующей иллюстрации:

Рис. 6. Подготовка домена к переименованию

Самый ответственный момент. Выполнение команды «rendom /execute ». Во время выполнения этой команды на домене выполняются инструкции по переименованию домена. По сути, в этот самый момент выполняется обращение к каждому контроллеру домена в лесу индивидуально, что заставляет каждый контроллер домена выполнять инструкции по переименованию домена. По выполнению этой операции каждый контроллер домена будет перезагружен. Процесс выполнения переименования домена смотрите на следующей иллюстрации:

Рис. 7. Процесс переименования домена

Но это еще не все. Несмотря на то, что ваш домен, по сути, уже переименован, вам еще предстоит задача по исправлению объектов групповой политики и их ссылок после завершения операции переименования домена. Для восстановления объектов групповой политики, а также ссылок GPO в каждом переименованном домене используется утилита командной строки Gpfixup.exe . Нельзя пренебрегать этой процедурой ввиду того, что без ее использования, после завершения операции переименования домена в новом лесу, групповые политики попросту не буду правильно функционировать. Учтите, что эта команда должна быть запущена единожды в каждом переименованном домене. Следовательно, один раз выполните команду gpfixup с параметрами /olddns:Biopharmaceutic.local (старое имя переименованного вами домена) и /newdns:Biopharm.local (новое имя переименованного домена), а затем команду gpfixup с параметрами /oldnb:Biopharmaceutic и /newnb:Biopharm (соответственно, старое и новое NETBIOS-имя вашего домена). Эта процедура видна ниже:

Рис. 8. Исправление объектов групповой политики

Осталось выполнить лишь две команды: команду «rendom /clean », которая позволяет удалить все ссылки на старые имена домена внутри вашей Active Directory, а также команду «rendom /end », по сути, размораживающую лес Active Directory от внесения изменений в его конфигурацию. Процесс выполнения этих команд вы можете увидеть на следующей иллюстрации:

Рис. 9. Завершение переименования домена Active Directory

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

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

Стоимость домена второго уровня (например, bissquit.com) составляет чуть больше 500 рублей в год. Это очень мало даже для обычных граждан, как мы с вами, и это сущие копейки для компаний тем более. Свой домен я приобрел ещё задолго до того, как появилась идея «запилить» этот бложик. Это просто удобно. Возьмем даже удаленное подключение по rdp — я ввожу имя своего домена, вместо унылого ip-адреса.

В интернете на запрос «active directory domain best practices» почти на каждом сайте написаны исчерпывающие рекомендации по именованию доменов AD и даны объяснения почему нужно сделать именно так. Давайте рассмотрим подробнее о каких рекомендациях идет речь:

• Для именования домена AD используйте поддомен вашего официально зарегистрированного домена организации.

Вы все поняли правильно, только один совет. Это все! Можно много рассуждать о деталях и мелких нюансах, но 80-90% рассуждений сводятся к одному единственному совету, озвученному выше. Все проблемы исходят из того, что человек знает, что так нужно делать, но не понимает почему нельзя или крайне не рекомендуется делать по-другому. С этого момента подробнее.

1. Почему нельзя использовать внутренние, неразрешаемые снаружи имена типа.local, .corp, .lan?

Можно. Ещё как можно. Большинство именно их и используют. У меня есть примеры среди знакомых, у которых в организациях 2000+ человек и используется домен.local. Все трудности начнутся, если вдруг станет нужен реальный домен AD. Такое может случиться при использовании гибридных облачных развертываний (яркий тому пример Exchange + Office365). «Почему бы просто не переименовать домен, ведь с определенной версии AD это вполне возможно?» — спросите вы. Да в принципе можно, однако вам предстоит столкнуться со сложностями миграции доменнозависимых сервисов. Среди них все тот же Exchange и др., но тут и одного Exchange более чем достаточно.

2. «Ок, покупаем реальное внешнее имя — my-company.com, также назовем и домен AD» — тоже не вариант. Возникнут проблемы с разрешением других ресурсов, расположенных на адресе my-company.com, например, веб-сайт компании. Да и к тому же ваши DNS-серверы не будут являться авторитативными для этого домена, хотя будут считать себя таковыми. Это тоже вызовет проблемы.

Есть и другие соображения касательно именований доменов, среди них создание аналогичного реальному домена но в другом TLD. Но мне кажется большого смысла так делать нет, ведь часть проблем все равно остается, а явных преимуществ в сравнении с использованием домена corp.my-company.com (имя взято для примера) просто нет.

Для любителей сделать все по-своему с недавнего времени добавятся ещё и проблемы с сертификатами, поэтому смысла использовать внутренние имена сейчас вообще нет.

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

Что такое контроллер домена

Контроллер домена обеспечивает централизованное управление сетевыми устройствами, то есть доменами. В контроллере хранится вся информация с учетных записей и параметров пользователей сети. Это параметры безопасности, локальной политики и многие другие. Это, своего рода, сервер, который полностью контролирует определенную сеть или сетевую группу. Контроллер домена - это, своего рода, набор специального программного обеспечения, которое осуществляет запуск различных служб Active Directory. Контроллеры работают под управлением определенных операционных систем, таких как Windows server 2003. Мастер установки Active Drive позволяет создавать контроллеры доменов.

В операционной системе Windows NT, как основной сервер, используется основной контроллер домена. Другие используемые серверы используются как резервные контроллеры. Основные контроллеры PDС могут решать различные задачи, связанные с членством пользователей в группах, создание и изменение паролей, добавление пользователей и многие другие. После чего данные передаются на дополнительные контроллеры BDC.

В качестве контроллера домена может использоваться программное обеспечение Samba 4, если установлена операционная система Unix. Это ПО также поддерживает и другие операционные системы, такие как windows 2003, 2008, 2003 R2 и 2008 R2. Каждая из операционных систем при необходимости может расширяться в зависимости от конкретных требований и параметров.

Применение контроллеров домена

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

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

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

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

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

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

Особенности установки дополнительных контроллеров домена

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

Для того чтобы контроллер домена работал правильно, необходимо произвести некоторые подготовительные работы. Первое, что нужно сделать, это проверить параметры TCP/IP, они должны быть правильно установлены для сервера. Важнее всего проверить DNS имена на сопоставления.

Для безопасной работы контроллера домена необходимо использовать файловую систему NTFS, обеспечивающую более высокую безопасность в сравнении с файловыми системами FAT 32. Для установки на сервере нужно создать один раздел в файловой системе NTFS, на котором будет находиться системный том. Также обязательно необходим доступ к DNS серверу с сервера. Служба DNS устанавливается на этом или дополнительном сервере, который должен поддерживать ресурсные записи.

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

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

Пришла весна, и с ней — обостренное желание родить фундаментальный материал, отвечающий на вопрос, который вроде бы очевиден, но при этом критически важен при проектировании: какое же имя дать домену Active Directory, чтобы потом не было мучительно больно?

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

Домен с single-label именем не пригоден для использования в продуктивной среде, и единственный правильный путь — избавиться от него как можно скорее.

Недопустимые символы в имени домена

Например, знак подчеркивания. Хотя в предыдущих версиях Windows Server этот знак допускался при выборе DNS-имени домена, он не соответствует стандарту RFC 1123 для DNS. Новые версии Windows Server уже не позволяют называть домены наперекор стандарту. Если домен с именем, содержащим подчеркивание, был унаследован, ожидаются большие неприятности. Например, нельзя установить Exchange 2007 и выше. Решение одно — избавиться от недопустимых символов в имени домена с помощью миграции в другой домен (предпочтительно), либо процедуры переименования домена (небезопасно).

Disjoint namespace

Один из частных случаев Disjoint namespace — это ситуация, когда Netbios-имя домена отличается от крайней левой части DNS-имени домена.

Netbios Name = TEST
DNS Name = lab.сайт

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

.local или ICANN

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

• Имя противоречит идеологии глобального DNS: не даёт гарантии отсутствия коллизий с другими такими же доменами (когда придет пора устанавливать доверительные отношения)
• Отсутствует возможность использовать данное имя для доступа из глобальной сети (когда придет пора публикации)
• На домен, владение которым невозможно подтвердить, нельзя получить публичный SSL-сертификат. Данное ограничение особенно актуально с развитием облачных сервисов, когад размываются границы между on-premise и cloud сервисами. Просто пример: для работы Single Sign On со службами Officе 365 требуется AD Federation Services c публичным сертификатом

Поэтому я рекомендую при именовании домена всегда использовать официально зарегистрированное глобальное имя в иерархии ICANN (Internet Corporation for Assigned Names and Numbers), которое гарантированно избавит от описанных выше недостатков.

сайт
argon.com.ru
irom.info

Выделить или совместить

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

• Если внутри сети такой организации в браузере ввести адрес http://сайт/ , то попадём мы не на сайт компании, а на первый попавшийся контроллер домена.
• Администрирование публичных и внутренних DNS-записей затруднено: все публичные DNS-записи в зоне сайт , которые используются из внутренней сети должны быть продублированы на внутренней зоне DNS. Также необходимо как-то обеспечивать синхронизацию этих записей.

Например, в интернете есть сайт www.сайт . Чтобы пользователи из внутренней сети могли на него попасть, требуется создать аналогичную запись и во внутренней зоне DNS

• Есть вероятность возникновения коллизий между внутренними и внешними именами ресурсов.

Например, во внутренней сети широко используется сервер ftp.сайт . Внезапно возникла необходимость предоставлять пользователям интернета файловый сервис по тому же адресу ftp.сайт . Что получилось? Внутренние пользователи не могут подключиться к внешнему сервису по указанному имени…

Таким образом, для домена Active Directory лучше иметь выделенное пространство имён (namespace), отличное от пространства имён в интернете (сайта компании и тому подобное). И здесь тоже есть выбор:

• Использовать для AD полностью другое имя (сайт для сайта, argon.com.ru для AD)
• Использовать для AD дочернее имя (сайт для сайта, lab.сайт для AD)

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

• поддержки зарегистрированных доменных имен (оплата регистрации и DNS-хостинга только одного домена)
• доступности красивых имён для регистрации (регистрировать не нужно)
• получения публичных SSL-сертификатов (всего один wildcard-сертификат можно использовать как для сайта компании, так и при публикации ресурсов внутренней сети)

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

lab.сайт
corp.microsoft.com

Split-brain

Split-brain DNS означает использование одного доменного имени для публикации ресурсов как во внутренней сети, так и в интернете. При этом DNS-сервера внутренней сети разрешают адреса вида portal.lab.сайт во внутренние IP-адреса, а публичные DNS-сервера в интернете, соответственно, во внешние IP. Пример:

За счет split-brain достигаются такие полезные вещи, как, единые адреса для доступа к ресурсам как из внутренней сети, так и из интернета. Пользователю достаточно знать один адрес portal.lab.сайт , по которому он может добраться до своих документов, и не важно, где он находится: в офисе компании или в гостинице.

С точки зрения инфраструктуры, удобно иметь один и тот же адрес для СRL или OCSP в SSL-сертификатах, выпускаемых внутренними CA.

При отсутствии split-brain может возникнуть необходимость создавать так называемые pinpoint-зоны на внутренних серверах DNS, такие «точечные» зоны будут содержать только те записи, для которых нужно подменить «публичные» значения, на «приватные», характерные для внутренней сети (ситуация схожа с описанной под заголовком «Выделить или совместить»).

Пример pinpoint-зоны:

Уточнить или обобщить

В литературе можно встретить советы называть домены (особенно корневой) обобщенным словом, вроде Bank , Company или Corp . На то есть причины, так как в наше время компании могут регулярно переживать слияния и поглощения, смену торговой марки. А имя домена, как известно, поменять очень сложно.

С другой стороны, при том же слиянии и поглощении компаний весьма вероятна миграция пользователей из одного домена в другой. На практике мне встречалась ситуация, когда нужно было мигрировать пользователей из десятка доменов с одним и тем же именем Bank . Как известно, установка доверительных отношений между доменами с одинаковыми именами (будь то DNS или Netbios) не возможна. Придется либо переименовывать эти домены, либо мигрировать данные в два этапа, через третий домен.

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

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

• глобально зарегистрированное
• выделенное (дочернее от домена сайта компании)
• специфичное
• используем split-brain

lab.сайт
corp.microsoft.com

При этом для адресов электропочты и SIP-адресов в Lync было бы приятнее использовать более короткие адреса user@сайт . Ничто не мешает нам сделать это, но возникнут неудобства.

Адрес электропочты у пользователя = user@сайт , логин входа = lab\user , user principal name = user@lab.сайт . Здесь легко запутаться не только пользователю, но и программам вроде Outlook и Lync.

После небольших модификаций учетных записей, пользователи будут иметь user principal name равным адресу электропочты. Путаницы станет меньше, а такие программы, как Lync и Outlook прекратят спрашивать логин пользователя, им будет достаточно знать e-mail или SIP адрес.

Мои фундаментальные труды:

Статьи на других ресурсах:

• Active Directory Domain Naming Considerations — а вот и подоспел сухой гайд от Microsoft
• Naming conventions in Active Directory for computers, domains, sites, and OUs — смотрите подраздел Forests that are connected to the Internet
• Why you shouldn’t use .local in your Active Directory domain name — похожая статья от зарубежного коллеги