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

1. Ситуация первая. Имя домена – domainname.local

Наверно самый распространенный вариант это использование окончания.local или любого другого домена первого уровня, не используемого IANA. (а-ля.msk или.test или.loc и.т.д) Откуда это пошло сейчас трудно сказать, есть несколько вариантов. Один говорит о том, что в 2000-м когда AD появилась на конференции в демонстрации докладчик сделал такой домен.
Ну и народ воспринял это как призыв к действию. Вторая гипотеза, впрочем не исключающая первую склоняется к тому, что скорее всего MSFT сама написала явно рекомендацию в литературе, после чего.local и ушел в народ. Чем же плох такой вариант?

Сценариев несколько, но я расскажу и наболевшем. Допустим вы устанавливаете внутри организации Exchange Server, которому необходим сертификат для шифрования клиентских подключений. Сертификат хочется от коммерческого центра, все как у людей. Естественно в сертификате должны быть указаны все имена сервера по которым сервер будет доступен. И если внешний домен принадлежит нам и легко пройдет валидацию, то внутренний домен а-ля super-firma.moscow не существует и при попытке объяснить центрам сертификации, что вам в SAN нужно запихнуть FQDN – exchange.super-firma.moscow получите ответ:

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

На текущий момент запихивать в SAN сертификата всякие неприличные слова разрешает Comodo Certificate Authority, что значительно сужает выбор поставщика сертификатов, да и гарантии, что они будут разрешать это и дальше нет.

2. Ситуация вторая. Имя домена AD совпадает с внешним интернет именем домена.

Тоже нередкий вариант, но при нем проблемы с сертификатами не будет. Зато возникают проблемы с разрешением имен. Получается ситуация, когда внешние и внутренние DNS сервера не связаны между собой, но при этом обслуживают несвязанные зоны с одинаковыми именами. В такой ситуации каждый внутренний сервер логично считает себя авторитативным для зоны и при незнании о каком либо хосте авторитетно заявляет – НЕТ! Поскольку вы имеете какие то внешние ресурсы, самое банальное веб-сайты, естественно записи типа А добавляются в зону на внешнем DNS сервере. Теперь когда внутренний клиент попытается разрешить имя внешнего ресурса, его запрос попадет на внутренний DNS сервер, (естественно, это же доменный клиент) а тот в ответ “не знаю, нет такого и можешь не искать”, т.к видит, что он авторитативный для этой зоны сервер.

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

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

3. Ситуация третья. Плоское имя домена состоящее из одного слова.

Если первые два варианта еще можно пережить, то за плоские имена доменов пора ввести административное наказание. Single-label domain (одноуровневый домен, SLD) – это домен, содержащий только одну именную составляющую. Откуда пошла мания их использовать, я не знаю, но уже давно официально признано, что SLD домены не должны использоваться при построении ИТ-инфраструктур.

При этом данная информация такой канадский баян, что остается только удивляться откуда SLD домены берутся. http://support.microsoft.com/kb/300684 .

Чем грозит? Отсутствием поддержки со стороны продуктов Microsoft такой конфигурации. Из свежего. Попытайтесь установить Exchange 2010 SP1 в домене с плоским именем, получите сообщение о том, что такая конфигурация больше не поддерживается.

Как же правильно именовать домен?

Ответ прост. Делать согласованное пространство имен. Т.е имея домен сайт в реальном мире, домен Active Directory делать суб-доменом типа corp.сайт. При таком раскладе все проблемы отпадают. И совсем не обязательно делать делегирование DNS суб-домена на внешнем DNS сервере. Хотя если вы это сделаете, можно добиться разрешения имен в обе стороны. (из внутренней сети внешних имен, из Internet внутренних имен)

Для тех, кто не подумал изначально есть “хорошая” ссылка: http://technet.microsoft.com/en-us/library/cc738208(v=ws.10).aspx Приятных Вам вечером за чтением данного произведения.

MCP/MCT Илья Рудь

Данная процедура гораздо сложнее, чем переименование рядового сервера, являющегося обычным членом домена. Для этой задачи нам понадобится утилита "NETDOM ", которая начиная с Windows 2008 входит в состав ОС , а для Windows 2003 понадобится установить "Support Tools ".

Для переименования контроллера домена действуем следующим образом:
1. Сначала убеждаемся в том, что функциональный уровень домена не ниже Windows 2003 и проверяем наличие прав "Domain Admins " ("Администраторы домена ").
2. Открываем командную строку с повышенными привилегиями и добавляем для контроллера дополнительное имя, в которое мы собираемся переименовать (в нашем примере SRV-DC1-OLD.TEST.LOCAL переименовываем в SRV-DC1.TEST.LOCAL ):

NETDOM computername SRV-DC1-OLD.TEST.LOCAL /add:SRV-DC1.TEST.LOCAL

3. С помощью редактора "ADSIEDIT.msc " убеждаемся, что имя добавлено корректно. В редакторе находим объект контроллера домена и проверяем значение свойства "msDS-AdditionalDnsHostName ", которое должно быть равно "SRV-DC1.TEST.LOCAL ".

4. Теперь необходимо убедиться, что обновленные SPN атрибуты успели полностью реплицироваться на остальные контроллеры домена в лесу. В этом нам поможет утилита "REPADMIN " или "REPLMON " для Windows 2003 .

Для ускорения процесса репликацию можно форсировать в оснастке "DSSITE.msc ". Просто кликните правой кнопкой мыши на подключении и выберите "Реплицировать сейчас ".

5. Теперь делаем первичным новое имя контроллера домена:

NETDOM computername SRV-DC1-OLD.TEST.LOCAL /makeprimary:SRV-DC1.TEST.LOCAL

6. Перегружаем сервер.
7. Снова проверяем, что обновлённые SPN атрибуты и записи в DNS успели полностью реплицироваться на остальные контроллеры домена и сервера DNS в лесу, а значение свойства "msDS-AdditionalDnsHostName " теперь равно старому имени сервера.

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

NETDOM computername SRV-DC1.TEST.LOCAL /remove:SRV-DC1-OLD.TEST.LOCAL

9. Форсируем или дожидаемся полной репликации, и в завершении перегружаем и проверяем прямые и обратные доменные зоны DNS на наличие записей со старым именем. Если находим таковые - удаляем или исправляем при необходимости на новое имя. Также стоит ещё раз проверить значение атрибута "msDS-AdditionalDnsHostName ", которое должно быть пустым.

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

Пришла весна, и с ней — обостренное желание родить фундаментальный материал, отвечающий на вопрос, который вроде бы очевиден, но при этом критически важен при проектировании: какое же имя дать домену 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. Пример:

DNS-имя	Во внутренней сети	В интернете
portal.lab.сайт	10.18.0.20	77.37.182.47
smtp.lab.сайт	10.18.0.40	78.107.236.18

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

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

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

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

DNS-имя	Во внутренней сети	В интернете
_sipinternaltls._tcp.lab.сайт	sip.lab.сайт	lync.argon.com.ru

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

В литературе можно встретить советы называть домены (особенно корневой) обобщенным словом, вроде 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 — похожая статья от зарубежного коллеги

Рубрика
Метки
Опубликовано

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

С удовольствием читаю ваш блог, много полезного для себя узнал, хотел узнать ваше мнение по поводу имени домена 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

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