J3qx

information archive

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

Posted by j3qx на Январь 8, 2013

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

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

 

MCP/MCT Илья Рудь

© http://itband.ru/2012/05/name/

Комментарии Ефимов Геннадий

о поводу первого сценария: да действительно, Microsoft не рекомендует использовать незарегистрированные в Интернет dns-суффиксы, но это не столько проблема с сертификатами (или чем-то другим), сколько невозможность обеспечить некую уникальность имен, на случай дальнейшего слияния. Опять же, если у вас нет таких требований, то можно об этом и не задумываться. Другое дело если есть какие-либо специальные требования или есть какое-то конкретное окружение.

По части Exchange и сертификатов для IIS: это не такая уж проблема и она решаема. Да, и зачем на внешнем сайте светить записи внутренних ресурсов?

По поводу второго сценария: здесь можно получить траблы и с поддоменами. Например, у нас внешний сайт хостится на имени Microsoft.com, а внутреннее пространство corp.microsoft.com. Мы хотим использовать единое имя для доступа к сайту как изнутри, так и снаружи. Клиенты будут ломиться на внешние ip-адреса, а в этом могут крыться и другие проблемы, например, связанные с маршрутизацией и со stateful-filrewallами. Что делать? Split-DNS? Или Pin-Point зоны использовать? Или решить проблемы на сетевом уровне? (решается, и не трудно).

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

Нужно называть свои службы каталогов, учитывая окружение и, самое главное, в соответствии с требованиями!

По поводу того, что Microsoft пишет, что домен является security-границей:

Это не совсем так. Microsoft пишет, что домен является некой границей политик паролей (особенно Kerberos-конфигурации), но ни как ни security-boundary. В документах можно увидеть нечто следующее:

Because a domain is not a security boundary, it is possible for a malicious service administrator, such as a member of the Domain Admins group, to use nonstandard tools and procedures to gain full access to any domain in the forest or to any computer in the forest. For example, service administrators in a nonroot domain can make themselves members of the Enterprise Admins or Schema Admins group.

Реклама

Добавить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s

 
%d такие блоггеры, как: