Это Канонический вопрос об именах доменов Active Directory.
После экспериментов с доменами Windows и контроллерами домена в виртуальной среде я понял, что иметь домен активного каталога, идентичный домену DNS, - плохая идея (это означает, что example.com
поскольку имя Active Directory бесполезно, когда у нас есть example.com
доменное имя, зарегистрированное для использования в качестве нашего веб-сайта).
Этот связанный вопрос, кажется, поддерживает этот вывод., но я все еще не уверен, какие еще правила существуют для именования доменов Active Directory.
Есть ли какие-нибудь передовые практики относительно того, каким должно быть имя Active Directory, а каким не должно быть?
Это была интересная тема для обсуждения сбоя сервера. Похоже, что существуют разные «религиозные взгляды» на эту тему.
Я согласен с рекомендацией Microsoft: Используйте поддомен уже зарегистрированного доменного имени компании в Интернете.
Итак, если у вас есть foo.com
, используйте ad.foo.com
или что-то в этом роде.
Самая мерзкая вещь, как мне кажется, - это дословное использование зарегистрированного доменного имени в Интернете для имени домена Active Directory. Это заставляет вас вручную копировать записи из Интернет-DNS (например, www
) в зону DNS Active Directory, чтобы разрешить «внешние» имена. Я видел совершенно глупые вещи, такие как IIS, установленный на каждом DC в организации, имеющей веб-сайт, который выполняет перенаправление таким образом, что кто-то вводит foo.com
в их браузер будет перенаправлен на www.foo.com
этими установками IIS. Абсолютная глупость!
Использование доменного имени в Интернете не дает вам никаких преимуществ, но создает "работу" каждый раз, когда вы меняете IP-адреса, на которые ссылаются имена внешних хостов. (Попробуйте использовать DNS с географической балансировкой нагрузки для внешних хостов и интегрировать это с такой ситуацией с «разделенным DNS»! Гы - это было бы весело ...)
Использование такого поддомена не влияет на такие вещи, как доставка электронной почты Exchange или суффиксы имени участника-пользователя (UPN), BTW. (Я часто вижу и то, и другое в качестве оправдания использования доменного имени в Интернете в качестве доменного имени AD.)
Я также вижу отговорку «так поступают многие крупные компании». Крупные компании могут принимать глупые решения так же легко (если не в большей степени), чем небольшие компании. Я не покупаю это только потому, что крупная компания принимает плохое решение, которое каким-то образом превращает его в хорошее.
На этот вопрос есть только два правильных ответа.
Неиспользуемый субдомен домена, который вы используете публично. Например, если ваше публичное присутствие в Интернете example.com
ваш внутренний AD может называться примерно так ad.example.com
или internal.example.com
.
Неиспользуемый домен второго уровня что у тебя есть и больше нигде не использовать. Например, если ваше публичное присутствие в Интернете example.com
ваш AD может быть назван example.net
пока вы зарегистрировались example.net
и больше нигде не используйте!
Это ваши единственные два варианта. Если вы делаете что-то еще, вы подвергаетесь сильной боли и страданиям.
Но все используют .local!
Неважно. Вы не должны. Я писал об использовании .local и других составных TLD, таких как .lan и .corp.. Ни при каких обстоятельствах вы не должны этого делать.
Это не более безопасно. Это не «лучшие практики», как утверждают некоторые. И у него нет любой преимущество перед двумя вариантами, которые я предложил.
Но я хочу назвать его так же, как URL-адрес моего общедоступного веб-сайта, чтобы мои пользователи example\user
вместо того ad\user
Это обоснованная, но ошибочная проблема. Когда вы продвигаете первый DC в домене, вы можете установить NetBIOS-имя домена любым, каким хотите. Если вы последуете моему совету и сделаете свой домен ad.example.com
, вы можете настроить NetBIOS-имя домена как example
так что ваши пользователи будут входить в систему как example\user
.
В Active Directory Forests and Trusts вы также можете создавать дополнительные суффиксы UPN. Вам ничего не мешает создать и установить @ example.com в качестве основного суффикса UPN для всех учетных записей в вашем домене. Когда вы объедините это с предыдущей рекомендацией NetBIOS, ни один конечный пользователь никогда не увидит, что полное доменное имя вашего домена ad.example.com
. Все, что они видят, будет example\
или @example.com
. Единственные люди, которые должны будут работать с FQDN, - это системные администраторы, работающие с Active Directory.
Кроме того, предположим, что вы используете пространство имен DNS с разделенным горизонтом, что означает, что ваше имя AD совпадает с именем вашего общедоступного веб-сайта. Теперь ваши пользователи не могут добраться до example.com
внутренне, если у вас нет префикса www.
в их браузере или вы запускаете IIS на всех своих контроллерах домена (это плохо). Вы также должны курировать два неидентичные зоны DNS, которые совместно используют непересекающееся пространство имен. Это действительно больше хлопот, чем того стоит. Теперь представьте, что у вас есть партнерство с другой компанией, и у нее также есть конфигурация DNS с разделенным горизонтом с их AD и своим внешним присутствием. У вас есть частное оптоволоконное соединение между ними, и вам нужно создать доверительные отношения. Теперь весь ваш трафик на любой из их общедоступных сайтов должен проходить по частной ссылке, а не просто выходить через Интернет. Это также создает множество проблем для сетевых администраторов с обеих сторон. Избегайте этого. Доверьтесь мне.
Но но НО...
Серьезно, нет причин не использовать одну из двух вещей, которые я предложил. У любого другого пути есть подводные камни. Я не говорю вам спешить с изменением вашего доменного имени, если оно функционирует и существует, но если вы создаете новую AD, выполните одно из двух действий, которые я рекомендовал выше.
Чтобы помочь ответу MDMarra:
Вам следует НИКОГДА не используйте однозначное DNS-имя для вашего доменного имени. Это было / доступно до Windows 2008 R2. Причины / объяснения можно найти здесь: Развертывание и работа доменов Active Directory, настроенных с использованием однокомпонентных DNS-имен | Служба поддержки Microsoft
Не забывайте НЕ использовать зарезервированные слова (таблица включена в ссылку «Соглашения об именах» внизу этого сообщения), например, SYSTEM, WORLD или RESTRICTED.
Я также согласен с Microsoft в том, что вы должны следовать двум дополнительным правилам (которые не высечены, но все же):
Наконец, я бы порекомендовал вам как можно больше думать о долгосрочной перспективе. Компании действительно проходят через слияния и поглощения, даже небольшие компании. Также подумайте о получении внешней помощи / консультации. Используйте доменные имена, структуру AD и т. Д., Которые можно без особых усилий объяснить консультантам или людям здесь, в SF.
Ссылки на знания:
http://technet.microsoft.com/en-us/library/cc731265%28v=ws.10%29.aspx
http://support.microsoft.com/kb/909264
http://support.microsoft.com/kb/300684/en-us
Текущая страница рекомендаций Microsoft (W2k12) для имени домена корневого леса
Я не согласен с использованием:
Я мог бы согласиться с использованием:
Но я бы сам этого не делал и не рекомендовал бы. Во время поглощения компании ребрендинг вырывается наружу, особенно когда руководство хочет, чтобы все сразу изменилось. Переименование миграций, изменений очень сложно или дорого.
Лучший способ, который я бы порекомендовал, - это купить домен, не имеющий отношения к названию компании, а также к бренду компании. ПРОСТО.ОБЛАК или подобное должно подойти до тех пор, пока вы можете им владеть.
Я видел большие компании с 150 тыс. Пользователей, использующих AD, которые все еще ссылаются на старую компанию, которую они купили много лет назад, или компании, которые меняли имена, и даже если в долгосрочной перспективе не имеет значения, что вы используете \ login (если вы не можете используйте UPN) это все еще выглядит плохо для руководства, которое не понимает, почему его нетривиально изменить.
я всегда делаю mydomain.local
.
local
не является действительным TLD, поэтому он никогда не конкурирует с фактической публичной записью DNS.
Например, мне нравится знать, что web1.mydomain.local
разрешится на внутренний IP-адрес веб-сервера, а web1.mydomain.com
разрешится на внешний IP.