27 сентября 2014      1294    

Как не нужно называть домены Active Directory

Выбор имени домена задача несложная, но как показывает жизнь достаточно часто после запуска 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 в домене с плоским именем, получите сообщение о том, что такая конфигурация больше не поддерживается.

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

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

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

 

Оригинал — http://itband.ru/2012/05/name/

Популярные статьи
Свежие записи
Рубрики
Мета

© 2017 iTeron · Копирование материалов сайта без разрешения запрещено
Дизайн и поддержка: GoodwinPress.ru