Выбор имени домена Active Directory
2012-03-30, 01:00 / ArgonБолее полугода прошло с выпуска моей последней серьёзной статьи О пустых корневых доменах в Active Directory. Пришла весна, и с ней — обостренное желание родить фундаментальный материал, отвечающий на вопрос, который вроде бы очевиден, но при этом критически важен при проектировании: какое же имя дать домену Active Directory, чтобы потом не было мучительно больно?
В этой статье я постараюсь провести вас от самых худших вариантов имени домена Active Directory к самому, по моему мнению, лучшему варианту, попутно указав на преодолеваемые грабли.
Содержание:
- Epic fails
- .local или ICANN
- Выделить или совместить
- Split-brain
- Уточнить или обобщить
- Последние штрихи на пути к совершенству
- Рекомендую к прочтению
Epic fails
Single-label
Вырожденный случай, когда домену Active Directory было дано DNS-имя типа company (без точек), называется single-label. Такое имя полностью противоречит идеологии DNS и не поддерживается большинством серьезных приложений, работающих с AD. С подробностями можно ознакомиться в статье Information about configuring Active Directory domains by using single-label DNS names.
Домен с single-label именем не пригоден для использования в продуктивной среде, и единственный правильный путь — избавиться от него как можно скорее.
Недопустимые символы в имени домена
Например, знак подчеркивания. Хотя в предыдущих версиях Windows Server этот знак допускался при выборе DNS-имени домена, он не соответствует стандарту RFC 1123 для DNS. Новые версии Windows Server уже не позволяют называть домены наперекор стандарту. Если домен с именем, содержащим подчеркивание, был унаследован, ожидаются большие неприятности. Например, нельзя установить Exchange 2007 и выше. Решение одно — избавиться от недопустимых символов в имени домена с помощью миграции в другой домен (предпочтительно), либо процедуры переименования домена (небезопасно).
Подробности — в статье Naming conventions in Active Directory for computers, domains, sites, and OUs.
Disjoint namespace
Один из частных случаев Disjoint namespace — это ситуация, когда Netbios-имя домена отличается от крайней левой части DNS-имени домена.
Пример:
Netbios Name = TEST
DNS Name = lab.argon.pro
С точки зрения функциональности, такая конфигурация полностью поддерживается. Но я всё же рекомендую избегать её, чтобы не вносить путаницы и неоднозначности.
Подробнее — в статье Understanding Disjoint Namespace Scenarios.
.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.pro
argon.com.ru
irom.info
Выделить или совместить
Представим, что мы проектируем доменную структуру для компании Argon, которая имеет сайт по адресу argon.pro, а также использует адреса электропочты в этом же домене. Велик соблазн назвать домен Active Directory как argon.pro, не правда ли? Но этого лучше не делать по следующим причинам:
- Если внутри сети такой организации в браузере ввести адрес http://argon.pro/, то попадём мы не на сайт компании, а на первый попавшийся контроллер домена.
- Администрирование публичных и внутренних DNS-записей затруднено: все публичные DNS-записи в зоне argon.pro, которые используются из внутренней сети должны быть продублированы на внутренней зоне DNS. Также необходимо как-то обеспечивать синхронизацию этих записей.
Например, в интернете есть сайт www.argon.pro. Чтобы пользователи из внутренней сети могли на него попасть, требуется создать аналогичную запись и во внутренней зоне DNS
- Есть вероятность возникновения коллизий между внутренними и внешними именами ресурсов.
Например, во внутренней сети широко используется сервер ftp.argon.pro. Внезапно возникла необходимость предоставлять пользователям интернета файловый сервис по тому же адресу ftp.argon.pro. Что получилось? Внутренние пользователи не могут подключиться к внешнему сервису по указанному имени…
Таким образом, для домена Active Directory лучше иметь выделенное пространство имён (namespace), отличное от пространства имён в интернете (сайта компании и тому подобное). И здесь тоже есть выбор:
- Использовать для AD полностью другое имя (argon.pro для сайта, argon.com.ru для AD)
- Использовать для AD дочернее имя (argon.pro для сайта, lab.argon.pro для AD)
Оба варианта удовлетворяют идеологии DNS и избавлены от перечисленных выше недостатков, но второй вариант с дочерним доменом может быть удобнее с точек зрения:
- поддержки зарегистрированных доменных имен (оплата регистрации и DNS-хостинга только одного домена)
- доступности красивых имён для регистрации (регистрировать не нужно)
- получения публичных SSL-сертификатов (всего один wildcard-сертификат можно использовать как для сайта компании, так и при публикации ресурсов внутренней сети)
Итак, предлагаю выбрать для AD выделенный, но дочерний относительно сайта организации домен.
Примеры:
lab.argon.pro
corp.microsoft.com
Split-brain
Split-brain DNS означает использование одного доменного имени для публикации ресурсов как во внутренней сети, так и в интернете. При этом DNS-сервера внутренней сети разрешают адреса вида portal.lab.argon.pro во внутренние IP-адреса, а публичные DNS-сервера в интернете, соответственно, во внешние IP. Пример:
| DNS-имя | Во внутренней сети | В интернете |
|---|---|---|
| portal.lab.argon.pro | 10.18.0.20 | 77.37.182.47 |
| smtp.lab.argon.pro | 10.18.0.40 | 78.107.236.18 |
За счет split-brain достигаются такие полезные вещи, как, единые адреса для доступа к ресурсам как из внутренней сети, так и из интернета. Пользователю достаточно знать один адрес portal.lab.argon.pro, по которому он может добраться до своих документов, и не важно, где он находится: в офисе компании или в гостинице.
Естественно, при к опубликованным наружу ресурсам должны применяться шифрование трафика и более строгие политики безопасности.
С точки зрения инфраструктуры, удобно иметь один и тот же адрес для СRL или OCSP в SSL-сертификатах, выпускаемых внутренними CA.
При отсутствии split-brain может возникнуть необходимость создавать так называемые pinpoint-зоны на внутренних серверах DNS, такие «точечные» зоны будут содержать только те записи, для которых нужно подменить «публичные» значения, на «приватные», характерные для внутренней сети (ситуация схожа с описанной под заголовком «Выделить или совместить»).
Пример pinpoint-зоны:
| DNS-имя | Во внутренней сети | В интернете |
|---|---|---|
| _sipinternaltls._tcp.lab.argon.pro | sip.lab.argon.pro | lync.argon.com.ru |
Уточнить или обобщить
В литературе можно встретить советы называть домены (особенно корневой) обобщенным словом, вроде Bank, Company или Corp. На то есть причины, так как в наше время компании могут регулярно переживать слияния и поглощения, смену торговой марки. А имя домена, как известно, поменять очень сложно.
С другой стороны, при том же слиянии и поглощении компаний весьма вероятна миграция пользователей из одного домена в другой. На практике мне встречалась ситуация, когда нужно было мигрировать пользователей из десятка доменов с одним и тем же именем Bank. Как известно, установка доверительных отношений между доменами с одинаковыми именами (будь то DNS или Netbios) не возможна. Придется либо переименовывать эти домены, либо мигрировать данные в два этапа, через третий домен.
Я склоняюсь к мнению, что лучше назвать домен специфично и терпеть старое имя после переименования компании, чем назвать обобщенно и получить серьезные технические проблемы при необходимости миграции или установления доверительных отношений.
Последние штрихи на пути к совершенству
Итак, если следовать моим рекомендациям, для домена AD мы выбираем имя:
- глобально зарегистрированное
- выделенное (дочернее от домена сайта компании)
- специфичное
- используем split-brain
Примеры:
lab.argon.pro
corp.microsoft.com
При этом для адресов электропочты и SIP-адресов в Lync было бы приятнее использовать более короткие адреса user@argon.pro. Ничто не мешает нам сделать это, но возникнут неудобства.
Адрес электропочты у пользователя = user@argon.pro, логин входа = lab\user, user principal name = user@lab.argon.pro. Здесь легко запутаться не только пользователю, но и программам вроде Outlook и Lync.
Чтобы избежать путаницы, я рекомендую в качестве user principal name задать наиболее знакомый пользователю адрес — электропочты. Для этого нужно в свойствах AD-домена lab.argon.pro добавить почтовый домен (в нашем случае — родительский) argon.pro в список поддерживаемых UPN-суффиксов.
После небольших модификаций учетных записей, пользователи будут иметь 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 — похожая статья от зарубежного коллеги
| Рубрика | Core Infrastructure |
|---|---|
| Метки | active directory, ad |
| Опубликовано | 2012-03-30, 1:00; обновлено 2016-07-31, 16:04 |
| Комментарии | 22 комментария » | Лента комментариев RSS |
| Ссылки | Постоянная ссылка | Обратная ссылка |
22 комментария
«Отсутствует возможность использовать данное имя для доступа из глобальной сети (когда придет пора публикации)»
А зачем использовать это имя, когда можно сразу «заложиться» на внешний домен?
«На домен, владение которым невозможно подтвердить, нельзя получить публичный SSL-сертификат»
Вы, видимо, не часто покупаете публичные сертификаты :) . Имена в таких зонах, как «.local», совершенно не требуют проверки ;) . Хотя, всё, как всегда, зависит от конкретного поставщика.
«Администрирование публичных и внутренних DNS-записей затруднено: все публичные DNS-записи в зоне argon.pro, которые используются из внутренней сети должны быть продублированы на внутренней зоне DNS. Также необходимо как-то обеспечивать синхронизацию этих записей.»
На счёт «должны быть продублированы» согласен, а вот «обеспечивать синхронизацию» — совершенно не проблема. Я решаю это банальным делегированием, как описано здесь.
«Внезапно возникла необходимость предоставлять пользователям интернета файловый сервис по тому же адресу http://ftp.argon.pro. Что получилось? Внутренние пользователи не могут подключиться к внешнему сервису по указанному имени…»
А что мешает иметь два разных ресурса? Внутри сети имя разрешается во внутренний IP-адрес и пользователи продолжают им пользоваться, а снаружи имя разрешается во внешний. Но, если честно — ситуация какая-то «надуманная» :) .
«получения публичных SSL-сертификатов (всего один wildcard-сертификат можно использовать как для сайта компании, так и при публикации ресурсов внутренней сети)»
Если вы имеете в виду, что одним Wildcard-сертификатом вы покроете имена из доменов «argon.pro» и «lab.argon.pro», то вы сильно заблуждаетесь. Если вы попробуете открыть сайт по имени «mail.lab.argon.pro», когда на нём весит сертификат «*.argon.pro», то вы получите ошибку — имя в сертификате, в данном случае, должно быть «*.lab.argon.pro» ;) .
И в заключение — я, наоборот, сторонник соответствия внутреннего домена внешнему :) .
Stanky, спасибо за комменты.
А что мешает иметь два разных ресурса? Внутри сети имя разрешается во внутренний IP-адрес и пользователи продолжают им пользоваться, а снаружи имя разрешается во внешний. Но, если честно — ситуация какая-то «надуманная» :) .
Я не очень понятно выразился. Имел в виду ситуацию, когда внутри http://ftp.argon.pro ведет на внутренний сервер компании, а снаружи http://ftp.argon.pro — на внешний сервер, который, хостится, например, где-то у провайдера. На своей практике таких коллизий я встречал немало, поэтому для меня этот пример совсем не «надуман».
Если вы имеете в виду, что одним Wildcard-сертификатом вы покроете имена из доменов «argon.pro» и «lab.argon.pro», то вы сильно заблуждаетесь.
Согласен, нужно учитывать, что этот сценарий не работает.
И в заключение — я, наоборот, сторонник соответствия внутреннего домена внешнему :) .
Мне будет очень интересно почитать твою статью с твоими аргументами!
Я не очень понятно выразился
Если честно, мне и сейчас ни чуть понятней не стало :) . Ну есть у вас два разных ресурса с одинаковым именем и что? Если нужно обеспечить, чтоб обращение происходило на соответствующие сервера, в зависимости от сети, указываете во внешней DNS-зоне свой адрес, во внутренней «внешней зоне» свой. Если нужно, чтоб на одном и том же работали, указываете везде одинаковый — в чём проблема-то?
К сожалению, до своих статей я ещё не дорос — так, в камментах «погадить», да на форумах пообщаться :) .
отлично, но все же как поступать при совпадении имени домена и внешнего сайта компании?
Как дать доступ изнутри всем пользователям на сайт компании? сейчас они все как и положено отправляются на адрес контроллера домена
Евгений, можно установить на все глобально опубликованные в DNS контроллеры домена службу DNS, и там настроить редирект.
О том, как ограничить глобальную публикацию всех контроллеров в DNS до нескольких выделенных, читайте здесь.
Про выбор имени домена:
> Если внутри сети такой организации в браузере ввести адрес
> http://argon.pro/, то попадём мы не на сайт компании, а на
> первый попавшийся контроллер домена.
Легко решается правилами в IIS на контроллерах домена.
> Администрирование публичных и внутренних DNS-записей
> затруднено: все публичные DNS-записи в зоне argon.pro,
> которые используются из внутренней сети должны быть
> продублированы на внутренней зоне DNS. Также необходимо
> как-то обеспечивать синхронизацию этих записей.
Это мелочи.
> Например, в интернете есть сайт http://www.argon.pro. Чтобы
> пользователи из внутренней сети могли на него попасть,
> требуется создать аналогичную запись и во внутренней зоне
> DNS. Есть вероятность возникновения коллизий между
> внутренними и внешними именами ресурсов.
Вероятности такой нет при правильно настроенных DNS. Прописать один раз ручками нужную запись — не такая уж и трудность.
> Например, во внутренней сети широко используется сервер
> http://ftp.argon.pro. Внезапно возникла необходимость предоставлять
> пользователям интернета файловый сервис по тому же адресу
> http://ftp.argon.pro. Что получилось? Внутренние пользователи не
> могут подключиться к внешнему сервису по указанному имени…
Почему не могут? Добавляем снаружи у держателя зоны в интернете A-запись ftp, указывающую на внешний IP-адрес, а на своих DNS указывающую на внутренний IP-адрес. Никаких проблем.
Эти три пункта — такие мелочи, УДОБСТВО использования имени argon.pro в качестве Active Directory перечёркивает их влёгкую.
vladon,
Легко решается правилами в IIS на контроллерах домена.
Держать на контроллерах домена IIS, да еще и следить за единообразем настроек — не энтерпрайс подход. Особенно если подумать о работе AD на уровне сервиса.
Вероятности такой нет при правильно настроенных DNS. Прописать один раз ручками нужную запись — не такая уж и трудность.
То, что нетрудно сделать в рамках небольшой компании с парой админов не всегда применимо для архитектуры больших организаций.
Почему не могут? Добавляем снаружи у держателя зоны в интернете A-запись ftp, указывающую на внешний IP-адрес, а на своих DNS указывающую на внутренний IP-адрес. Никаких проблем.
Не могут по тому, что по одному и тому же доменному имени снаружи и изнутри могут отзываться разные серверы, с разным назначением, контентом и настройками безопасности.
Эти три пункта — такие мелочи, УДОБСТВО использования имени argon.pro в качестве Active Directory перечёркивает их влёгкую.
Я считаю, что если смотреть шире и стратегически, то эти мелочи очень важны.
Вопрос новичка: Создал контроллер , юзеров еще не заводил
т.к увидел в что у юзера будет ящик вида @corp.domain.ru
а мне нужно @domain.ru
не могли бы дотошно пояснить где создать UPN суффикс на почтовый сервер или что-то в этом роде.
юзаю win Serv 2012 чет даже гугл не помогает.
хех разобрался — искал дольше
http://i028.radikal.ru/1307/0f/b6d7df5afcabt.jpg
Спасибо за развернутую (хотя и спорную) статью.
Остался вопрос. Что бы Вы порекомендовали в качестве имени SIP-домена при установке сервера Lync, если внешнее имя, скажем, mycompany.ru, а имя домена АД = ad.mycompany.ru
Доброго времени суток.
А не могли бы вы подробнее рассказать о настройке split-brain DNS?
HarusKG, почитай эту статью, раздел «Configuring Split-Brain DNS with Lync Server».
Добрый день! Интересная статья! Но у меня тут же возникла запарка с настройкой) Могли бы вы подсказать как выйти из такой ситуации!
Есть внутренний домен corp.domain.ru (domain.ru) зарегестрирован и на хостинге. Потребовался внутренний почтовый сервак, но вот с настройкой ДНС у меня проблемы. требуется что бы внутри сети он резолвился как mail.domain.ru, и в инете так же. На своем днс сервера я создал копию зоны domain.ru в ней создал «А» запись (mail) указывающую на внтуртенний IP почтовика. Но теперь в браузере из офиса заходит на потчу (веб морду) но вот засада в том что перестал открываться корпоративный сайт из офиса так как теперь domain.ru у нас стал определятся на внутреннем интерфейсе. Можно как то решить это?
Artem, правильнее будет внутри создать зону mail.domain.ru (так называемая pinpoint), содержащую всего одну A запись. Также можно в уже созданной зоне domain.ru прописать все внешние имена, что ресолвятся из интернета, но мне этот вариант меньше нравится.
Argon, в том то и дело что я создал внутри сети на днс сервере зону и в ней уже А запись. Или я что то не понял Вас)))
Я предлагаю удалить внутри зону domain.ru и создать mail.domain.ru.
Почитал про пинпоинт, буду пробывать. Кажется начал вникать в суть. Спасибо за подсказку =)! Если что то не получится могу я Вас еще побеспокоить?)
К абзацу
Чтобы избежать путаницы, я рекомендую в качестве user principal name задать наиболее знакомый пользователю адрес — электропочты. Для этого нужно в свойствах AD-домена lab.argon.pro добавить почтовый домен (в нашем случае — родительский) argon.pro в список поддерживаемых UPN-суффиксов.
Можите уточнить на пальцах, где создать новый UPN суфикс. Не могу понять в каких свойствах домена это сделать.
Спасибо
Спасибо, накопал, в Доменах и довериях, в свойствах на AD, не на названии домена.
Да вот на собеседовании так спросили, честно не сразу соориентировался, спасибо за полезную информацию
Если вы имеете в виду, что одним Wildcard-сертификатом вы покроете имена из доменов «argon.pro» и «lab.argon.pro», то вы сильно заблуждаетесь.
для этого есть SAN
Igor, согласен, что в общем случае это не работает.
Однако, на практике все провайдеры, у которых я запрашивал сертификаты вида *.argon.pro также прописывали в SAN родительский домен вида argon.pro.