Главная Windows, Новое Как не нужно называть домены Active Directory
  • Как не нужно называть домены 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 Илья Рудь

    • Рубрика: Windows,Новое
    • Автор: Илья Рудь
    • Дата: Воскресенье 13 Май 2012

Комментарии

  1. Split-brain DNS в первом и втором случае никто не отменял.

    Хотя проблемы с сертификатами в первом оно не решит.

  2. И кстати, совсем правильный вариант — когда для технических нужд изпользуется отдельный домен вообще, например itband.net. Это позволяет вообще не пересекаться с доменными именами сайта и снимает еще немного проблем.

  3. Да самая жуткая проблема. Особенно когда тебе в руки попадает уже существующая система, а у тебя проект связаный с внешними сервисами и сертификатами... И тут такое начинается. Жуть.

    Этот вопрос относится к теме «1000 раз подумай, потом НЕ вздумай резать, еще 1000 раз подумай и только тогда нажимай ОК».

  4. Хотел бы добавить что по выбору имени домена и планированию Active Directory в частности есть два довольно хороших документа.

    ActiveDirectoryDesignGuide — www.microsoft.com/en-us/d...ils.aspx?id=8133

    Infrastructure Planning and Design — technet.microsoft.com/en- ...ry/cc196387.aspx

    Что касается 3-го способа к сожалению он слабо применим в крупном окружении.

  5. Не так давно читал нечто подобное: argon.pro/blog/2012/03/choose-ad-domain-name/

    Выводы, похоже, те же...

  6. а вот у меня подкинули: есть много доменов вида a1.firma.ru a2.firma.ru итд всего 30 штук по числу отделов и все эти домены домены каждый со своим контроллерами и лесом про соседние и знать не знает, ну и как их слить в один лес,да вывести на сайты?!

  7. @6

    Неправильная поставновка вопроса.

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

  8. Спасибо за статью.

    При создании домена вида «corp.itband.ru», предлагает net-bios имя — CORP. Стоит выбрать это имя или сделать ITBAND?

  9. Гринго,

    У меня вопрос на засыпку. Каждый из доменов отдела поднят как полностью самостоятельный домен а не домен 3-го уровня?

    Если это так, то, на мой взгляд, все не очень красиво и красиво вряд ли получится. Между лесами можно настроить доверие, но это вас не спасет.

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

    В таком случаи могу еще предложить использовать центральную проксю. так как это убавит вам головную боль с доступом в инет.

  10. Антон, день добрый стоит выбрать netbios name ITBAND, в данном случае вы сможете авторизироваться как user@itband и user@corp.itband.ru (itband\user, corp.itband.ru\user) и вход на локальных машинах будет именно указано вход в домен ITBAND а не в CORP, из этого следует -приятней воспринять название фирмы чем corp.(Для пользователей)

  11. Статья полезная, но как уже здесь говорили в основном домен достается в наследство и тут приходится жить с тем что есть...

    У себя проблему с разрешением имен ДНС решал размешением внешней зоны на своих серверах ДНС, что конечно не решит проблему дублирования и не убирает неудобство с www, но позволяет решать некоторые вопросы оперативнее.

  12. google «.local» site: microsoft.com

    result technet.microsoft.com/en- ...59 (v=ws.10).aspx

    «Using the .local label for the full DNS name for the internal domain is a more secure configuration because the .local label is not registered for use on the Internet.»

    Вот какое время дикое было. Во времена 2003 сервера.

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

    Так что удивляться не стоит)

  14. непонятно, почему во втором варианте внешние и внутренние dns не связаны. что мешает это сделать?

    деплойте пару dns в dmz и пропишите их в NS-записях домена и пользуйтесь. либо арендуйте нормальные dns'ы. не вижу тут проблем.

    вариант с corp.itband.ru все-таки не очень аккуратен.

    самый идеальный — второй, крупнейшие компании мира им пользуются, да хоть тот же Microsoft.

  15. неудобство с оикрытием сайта по itband.ru без www состоит в том, что имя itband.ru ресолвится в адреса контроллеров домена, а там никакого сайта по 80му порту нет.

    есть пара способов эту проблему решить и оба они простые:

    либо пробрасываем порты на нужный хост, либо с помощью кодов http 3хх автоматически перенаправлять на www.

  16. В серверах семейства SBS автоматически дописывается окончание .local при создании домена.

  17. Да будет вам известно, Vladon, Microsoft имеет рутовый домен corp.microsoft.com, а далее идет разделение на континенты такие как Africa.corp.microsoft.com и так далее.

  18. А в чём проблема в первом варианте с сертификатами? У меня имя внутреннего домена contoso.local, exchange торчит наружу с именем owa.contosoext.ru, сертификат от коммерческого центра на имя owa.contosoext.ru, и всё работает, то же и с веб-серверами.

  19. Прочитайте пост, я написал в чем проблема.

  20. По поводу первого сценария: да действительно, 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.

  21. Похоже что в статье разобран случай с одним корневым доменом, но бывают случаи когда создаются деревья с различными пространствами имен, на то могут быть юридические причины или какие либо еще. Проще переименовать статью на: «Какие варианты именования в каких случаях удобней использовать», законов и теорем с доказательствами какие можно использовать варианты нет, все завасит от фантазии архитектора:)

  22. Виктор, проще не умничать и не выдумывать «какие либо» причины. Проблем с несколькими деревьями никаких, подход тот же что и в статье. А фантазии в ИТ у архитектора, вместо расчета обычно заканчиваются печально.

  23. Илья я сказал о том, что бывают разные ситуации, когда внешнее имя может абсолютно не совпадать с внутренним, когда используется не одна внешняя зона и что, всем нужно будет пользоваться переименованием леса чтобы себе жизнь облегчить и подогнать под ваш вариант который назван единственным правельным)? Не вижу проблем с первым вариантом в части разрешения имен, пожалуйста используйте Split-DNS что так много имен и они каждые два дня меняются во внешних зонах?..Навеняка,если бы был один реально верный вариант именования нам бы указали о нем в дизайн гайдах. Я только видел, описание не поддерживаемого варианта с плоскими именами.

    Кстате буквально месяца два назад видел рекомендации и сценарии DNS в статье по линку technet.microsoft.com/en- ...ry/gg398758.aspx, где так же были описаны всевозможные варианты, включая и схожесть имен внешних и внутренних зон и pin-point зоны.

  24. Отличная статья спасибо! Илья ваши статьи не только сами по себе интересны, они рождают за собой не только писькометрию, но и интересные комментарии! Ефимов Геннадий – любо дорого почитать и статьи и комментарии! Люблю ваш ресурс, он мне прибавляет знаний, а значит честно заработанных денег!

  25. Использую SBS 2011. Там домен сам называется .LOCAL С сертификатом проблем нет.

    Если называть использую реальные TLD, то можно в ДНС добавить запись SRV 80 порт указывающий на реальный адрес.

    Единственный случай, когда нежелатьельно использование .LOCAL — если в сети есть не виндовые ОС, например, MAC OS. Но у меня они так же есть в сети и всё прекрасно работает.

  26. «И совсем не обязательно делать делегирование DNS суб-домена на внешнем DNS сервере. Хотя если вы это сделаете, можно добиться разрешения имен в обе стороны. (из внутренней сети внешних имен, из Internet внутренних имен)»

    Подскажите, пожалуйста, или направьте в правильное русло (пока не очень понимаю, но очень интересно!):

    К чему приведет\для чего делают делегирование суб-домена на внешнем ДНС-"разрешения имен в обе стороны. (из внутренней сети внешних имен, из Internet внутренних имен)"" — как будет выполняться это разрешение имен, и зачем это может пригодиться?

    Как вариант я вижу использовать его так — например в corp.itband.ru можно будет добавить запись на суб-домене типа а «ithome», но не пойму, для чего может пригодиться «разрешения имен в обе стороны».

    Заранее благодарю за ответ

  27. [...] itband.ru/2012/05/name/ Поделиться ссылкой:Like this:Нравится Загрузка... This entry [...]

  28. Статья хороша. Однако я столкнулся с проблемой, перешел на новую работу. А там настроено так:

    1. Почтовый домен domain1.ru

    2. Домен AD domain2.ru

    Ситуация такая, после создания пользователя нового, и первом запуске Outlook он как правило подхватывает настройки username@domain1.ru далее он пытается по видимому подключитсья и авторизироваться и просит ввести пароль почему-то, и получается пройти этот этап только если вводишь логи вида domain2.ru\usrname

    т.е доменную учетную запись. Можно ли сделать чтобы это как-то автоматически было?

  29. Можно. Создайте UPN суффикс domain1. И поменяйте UPN у человека.

  30. Да вот на собеседовании так спросили, честно не сразу соориентировался, спасибо за полезную информацию

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

    Досталась компания с доменным именем «ИМЯ_КОМПАНИИ.OFFICE». Все было хорошо. Проблемы начались месяц назад.

    В реестре корневых доменных зон IANA для компании Microsoft Corporation 23 июня 2015 года делегирована и активирована новая доменная зона OFFICE. Зона находится в статусе ACTIVE.

    Подскажите как временно решить проблему?

  32. Здравствуйте, Илья.

    Присоединюсь к предыдущему комментарию. У меня к вам вопрос, а как тогда безболезненно перейти с домена domain.local (или domain.office) на domain.ru, учитывая тот факт, что в компании используется множество сервисов (почта, СА и т.д.)? Интуитивно я догадываюсь, что поднять новый домен, настроить доверительные отношения и перенести все туда, но хотелось бы получить от вас вектор направления. Я уверен, что вам приходилось решать подобные проблемы у заказчиков. Буду признателен за ответ, так как тема с доменами по сей день актуальна.

  33. Парни, безболезненно никак не перейти.

    Выход один cross-forest-migration. Есть еще вариант rename domain, но в нем столько «НО».

  34. Илья, я вас понял.

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

  35. Думаю что это путь тупиковый, насколько я знаю корневой домен удалить не получится после миграции. (а он у всех проблемных скорее всего корневой)

  36. Большое спасибо Илья, будем изучать cross-forest-migration.

  37. Спасибо, все круто)

  38. Спасибо! corp.name.com отличное решение.

Опубликовать

Я не робот.