Лучшие практики именования в Windows Active Directory?

Это канонический вопрос о наименовании домена Active Directory.

После экспериментов с доменами Windows и контроллерами доменов в виртуальной среде, я осознал, что иметь домен Active Directory, названный идентично домену DNS, — плохая идея (это означает, что использование example.com в качестве имени Active Directory не подходит, когда у нас зарегистрировано имя домена example.com для использования в качестве нашего веб-сайта).

Этот связанный вопрос, кажется, поддерживает этот вывод, но я все еще не уверен, какие существуют другие правила относительно наименования доменов Active Directory.

Существуют ли лучшие практики по тому, каким должно быть имя Active Directory?

Это была интересная тема для обсуждения на Server Fault. Кажется, есть разные “религиозные взгляды” на эту тему.

Я согласен с рекомендацией Microsoft: используйте подсеть зарегистрированного доменного имени вашей компании.

Итак, если вы владеете foo.com, используйте ad.foo.com или подобное.

Самое отвратительное, как я вижу, это использовать зарегистрированное доменное имя в интернете, слово в слово, в качестве имени домена Active Directory. Это заставляет вас вручную копировать записи из интернет DNS (например, www) в зону DNS Active Directory, чтобы позволить разрешать “внешние” имена. Я видел совершенно глупые вещи, такие как IIS, установленный на каждом DC в организации, который ведет веб-сайт с перенаправлением, так что кто-то, вводящий foo.com в свой браузер, перенаправляется на www.foo.com этими установками IIS. Абсолютная глупость!

Использование имени домена в интернете не дает вам никаких преимуществ, но создает “дополнительную работу” каждый раз, когда вы меняете IP-адреса, на которые ссылаются внешние имена. (Попробуйте использовать geographically load-balanced DNS для внешних хостов и интегрировать это с такой “раздельной DNS” ситуацией! О, это будет весело…)

Использование такой подсети не влияет на такие вещи, как доставка электронной почты Exchange или суффиксы имен пользователей (UPN), кстати. (Я часто вижу, что оба эти пункта приводятся в качестве оправдания для использования доменного имени в интернете в качестве имени домена AD.)

Я также вижу оправдание “многие большие компании так делают”. Крупные компании могут принимать глупые решения так же легко (если не легче), чем малые компании. Я не верю в то, что, если большая компания принимает плохое решение, это каким-то образом делает его хорошим решением.

На этот вопрос есть только два правильных ответа.

1. Неиспользуемая подсеть домена, который вы используете публично. Например, если ваше публичное веб-присутствие — это example.com, ваш внутренний AD может быть назван как-то вроде ad.example.com или internal.example.com.

2. Неиспользуемый домен второго уровня, который вы владеете и не используете нигде больше. Например, если ваше публичное веб-присутствие — это 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 вы также можете создать дополнительные суффиксы UPN. Ничто не мешает вам создать и установить @example.com в качестве основного суффикса UPN для всех учетных записей в вашем домене. Когда вы комбинируете это с предыдущей рекомендацией по NetBIOS, ни один конечный пользователь никогда не увидит, что полное доменное имя вашего домена — это ad.example.com. Все, что они увидят, будет example\ или @example.com. Единственные люди, которым потребуется работать с полным доменным именем, это системные администраторы, которые работают с 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 в том, что вы должны следовать двум дополнительным правилам (которые не являются строгими, но все же):

1. Вы не должны называть свой домен на основе чего-то, что изменится или устареет. Примеры включают наименование вашего домена по названию продуктовой линейки, операционной системе или что-либо еще, что вероятно изменится со временем. Стремитесь выбрать что-то либо географическое, либо достаточно конкретное, чтобы имело смысл через 5 или даже 10 лет.
2. Оставайтесь с короткими именами длиной 15 символов или меньше, это позволит NETBIOS имени легко совпадать с именем домена.

Наконец, я бы рекомендовал вам думать на долгосрочную перспективу насколько это возможно. Компании проходят через слияния и поглощения, даже малые компании. Также подумайте о привлечении внешней помощи/консультаций. Используйте доменные имена, структуру 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) для имени корневого лесного домена

Я не согласен с использованием:

• example.com – по причинам, уже изложенным в других ответах

Я мог бы принять использование:

• ad.example.com – по причинам, уже изложенным в других ответах

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

Лучший способ, который я рекомендую, — это купить домен, который не имеет отношения к названию компании и также не имеет отношения к бренду компании. SIMPLE.CLOUD или подобное должно подойти при условии, что вы сможете им владеть.

Я видел большие компании с 150 000 пользователей, использующие AD, который все еще ссылается на старую компанию, которую они купили много лет назад, или компании, которые поменяли название, и хотя это не имеет значения в долгосрочной перспективе, что вы используете \логин (если не можете использовать UPN), это все равно выглядит плохо перед руководством, которое не понимает, почему это не тривиально изменить.

Example.com — это псевдоним хоста DNS, который обслуживает зону домена с тем же именем. Использование его для других целей, таких как https://example.com, неверно: веб-хост должен иметь подходящее имя, такое как www.example.com, как и любой другой ресурс, кроме хоста DNS. Представьте, что вам нужно переместить сайт https://example.com на другой хост, чем хост службы DNS. Единственный вариант — запуск веб-сервиса на хосте DNS с перенаправлением (независимо от того, есть ли AD или нет), что многие люди делают, чтобы отловить плохие веб-запросы. ВЫВОДЫ. Сервисы, кроме DNS, не должны использовать имя зоны в качестве своего имени.
Что касается службы AD. Службы AD построены на основе сервера DNS, и их имя буквально означает ИМЯ ЗОНЫ ДОМЕНА, в котором будут зарегистрированы объекты AD, и не имеет значения, является ли это основной зоной или дочерней зоной.
Если все ресурсы зоны домена имеют свои собственные имена, то нет необходимости выделять дочернюю зону для DNS AD (AD сам создает несколько дочерних зон, где это необходимо).
Если AD (с названием основной зоны домена) находится в локальной сети, то возникает “проблема” стратификации зоны DNS; это не совсем проблема — это механизм, обеспечивающий использование одних и тех же имен (но разных IP-адресов) как в локальной, так и в глобальной сети. Этот механизм приведет к дополнительной неприятной работе для администратора. Альтернатива — дочерняя зона, освобождает администратора от этой нагрузки, но одновременно создает скучную работу для пользователей и разработчиков, поскольку полные названия одних и тех же ресурсов различаются в локальных и глобальных сетях.

Я всегда использую mydomain.local.

local — недопустимый TLD, поэтому он никогда не конкурирует с фактической публичной записью DNS.

Например, мне нравится знать, что web1.mydomain.local будет разрешаться в внутренний IP-адрес веб-сервера, тогда как web1.mydomain.com будет разрешаться в внешний IP.