Вопрос: Windows Active Directory называет лучшие практики?


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

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

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

Есть ли какие-либо рекомендации по тому, каким должно быть или не должно быть имя Active Directory?


78
2017-10-21 13:10


Источник




Ответы:


Это была интересная тема для обсуждения проблемы с сервером. По всей видимости, существуют различные «религиозные взгляды» по этой теме.

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

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

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

Использование доменного имени Интернета не дает вам никаких преимуществ, но создает «make work» каждый раз, когда вы изменяете IP-адреса, на которые ссылаются имена внешних хостов. (Попробуйте использовать географически сбалансированный по нагрузке DNS для внешних хостов и интегрировать это с такой ситуацией с «разделенным DNS» тоже! Gee - это было бы весело ...)

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

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


93
2017-10-21 13:16



Но тогда имя NetBIOS для домена не ... ну, довольно :) corp не так описательно, как foo, - Anton Gogolev
Однако вы можете назначить любое имя NetBIOS. Многие мои клиенты имеют имена типа «ad.example.com», но имя NetBIOS - «ПРИМЕР». DCPROMO предложит вам, во что вы хотите, имя NetBIOS во время создания домена. - Evan Anderson
если вы это сделаете, не забудьте о проблемах с доменами, у которых есть подстановочные знаки. Когда у вас есть * .foo.com, host.internal.foo.com будет соответствовать ему в некоторых ситуациях - JamesRyan
Я не знаю какого-либо почтового сервера, который требует, чтобы вы использовали доменное имя AD в качестве суффикса адреса электронной почты пользователей. Биржа никогда требуется любая корреляция между доменным именем AD и суффиксами адреса электронной почты. - Evan Anderson
Office365 требует, чтобы ваши пользователи вошли в свой UPN с суффиксом, соответствующим вашему домену-арендатору. Поскольку политика адресов почтовых ящиков по умолчанию может быть определена как что угодно, как и ваш суффикс UPN, это тривиально. У нас есть EXAMPLE.COM как имя нашей компании (и арендатор Office365), EXAMPLE.NET (также зарегистрированный) как лес, CORP.EXAMPLE.NET в качестве основного домена учетной записи (с другими региональными поддоменами, например EU.EXAMPLE. NET) с ПРИМЕРОМ как имя NetBIOS, все пользователи в лесу Exchange org используют Name@EXAMPLE.COM для UPN и для электронной почты. Office365 вполне доволен этим. - Ryan Fisher


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

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

Кроме того, предположим, что вы используете пространство имен DNS с разделенным горизонтом, что означает, что ваше имя AD совпадает с вашим общедоступным сайтом. Теперь ваши пользователи не могут добраться до example.com внутренне, если у вас нет префикса www. в браузере или вы запускаете IIS на всех контроллерах домена (это плохо). Вы также должны курировать два неидентичные DNS-зоны, которые разделяют непересекающееся пространство имен. Это действительно больше хлопот, чем того стоит. Теперь представьте, что у вас есть партнерство с другой компанией, и у них также есть конфигурация DNS с разделенным горизонтом с их AD и их внешним присутствием. У вас есть частная волоконная связь между ними, и вам нужно создать доверие. Теперь весь ваш трафик на любой из их публичных сайтов должен пересекать частную ссылку, а не просто выходить через Интернет. Он также создает всевозможные головные боли для сетевых администраторов с обеих сторон. Избегайте этого. Доверьтесь мне.

Но но НО...
Серьезно, нет причин не использовать одну из двух вещей, которые я предложил. У любого другого пути есть подводные камни. Я не говорю, что вы спешите менять свое доменное имя, если оно работает и на месте, но если вы создаете новый AD, сделайте одну из двух вещей, которые я рекомендовал выше.


87
2018-01-29 16:18



Небольшая точка - можно использовать что-то намного меньшее, быстрее и безопаснее, чем IIS для обслуживания перенаправления. Даже haproxy или nginx, вероятно, переполнены - не говоря уже о полнофункциональном сервере, таком как apache2. - OrangeDog
Это правда, но все из этого небрежного и ненужного. - MDMarra
Uuuuw да, было так больно, когда кто-то вдруг зарегистрировал домен local.net, и все принтеры, которые молча получили NXDOMAIN до этой даты, внезапно больше не отвечали. Это было какое-то смешное расследование ... - Johannes
Могу я просто отметить, что .local не «составлен», он фактически зарезервирован; просто не для этого типа использования: en.wikipedia.org/wiki/.local - mikebabcock
В то время, когда это было написано, оно не было зарезервировано. - MDMarra


Чтобы помочь МДМарре ответить:

Вам следует НИКОГДА не используйте одноименное DNS-имя для вашего доменного имени. Это было / доступно до Windows 2008 R2. Причины / объяснения можно найти здесь: Развертывание и управление доменами Active Directory, которые настроены с использованием имен имен с одной меткой | Поддержка Microsoft

Не забудьте НЕ использовать зарезервированные слова (таблица включена в ссылку «Соглашения об именах» внизу этой публикации), например SYSTEM или WORLD или RESTRICTED.

Я также согласен с Microsoft в том, что вы должны следовать двум дополнительным правилам (которые не установлены в каменном, но все же):

  1. Вы не должны указывать свой домен на основе того, что изменится или устареет. Примеры включают именование вашего домена после линейки продуктов, операционной системы или чего-либо еще, что со временем может измениться. Придерживайтесь чего-то географического или конкретного, чтобы иметь смысл 5 или даже 10 лет в будущем.
  2. Stick с короткими именами из 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) для имени домена корневого леса


33
2018-01-29 16:35





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

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

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

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

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

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

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


1
2017-10-27 15:33





я всегда делаю mydomain.local,

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

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


-13
2017-09-23 20:03



FWIW, .local запросы на молот на корневом L-сервере - ~ 800 / сек, когда я посмотрел. - jscott
dot.Local, AKA dot.Fail - PnP
Использование недопустимого TLD (или незарегистрированного домена) не является лучшей практикой, это худшая практика по всем причинам, упомянутым выше. Я признаю, что я использовал .local, но это было до того, как я понял лучше. - Jonathan J