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

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

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

В интернете на запрос “active directory domain best practices” почти на каждом сайте ^{1 2 3} написаны исчерпывающие рекомендации по именованию доменов AD и даны объяснения почему нужно сделать именно так. Давайте рассмотрим подробнее о каких рекомендациях идет речь:

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

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

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

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

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

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

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

Вопрос выбора имени домена технически упирается в строчку, в которой вы пропишите имя при создании домена AD и ни во что более. Однако последствия, которые повлечет за собой неправильный выбор имени, в будущем доставят вам немало проблем и потому на этапе планирования очень важно все сделать качественно. Лишний раз неплохо почитать статьи бывалых админов ^{9 10}, но если личным бложикам вы не доверяете (это, кстати, правильный подход) и считаете себя умнее (а вот это неочень), то постарайтесь хотя бы почитать официальные рекомендации Microsoft ¹¹.

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