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

  

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

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

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

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

78 голосов | спросил Anton Gogolev 21 +04002009-10-21T17:10:05+04:00312009bEurope/MoscowWed, 21 Oct 2009 17:10:05 +0400 2009, 17:10:05

5 ответов


93

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

согласен с рекомендацией 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 - это будет весело ...)

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

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

ответил Evan Anderson 21 +04002009-10-21T17:16:32+04:00312009bEurope/MoscowWed, 21 Oct 2009 17:16:32 +0400 2009, 17:16:32
87

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

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

  2. Неиспользуемый домен второго уровня , который у вас есть , и не используйте нигде. Например, если ваше публичное присутствие в Интернете example.com, ваш AD может быть назван example.net , если вы зарегистрировали example.net и не используйте его нигде!

Это ваши единственные два варианта. Если вы делаете что-то еще, вы оставляете себя открытым для многих страданий и страданий.


Но каждый использует .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, сделайте одну из двух вещей, которые я рекомендовал выше.

ответил MDMarra 29 Jpm1000000pmTue, 29 Jan 2013 20:18:00 +040013 2013, 20:18:00
33

Чтобы помочь 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

страница рекомендаций Microsoft (W2k12) для имени домена корневого леса

ответил TheCleaner 29 Jpm1000000pmTue, 29 Jan 2013 20:35:21 +040013 2013, 20:35:21
1

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

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

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

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

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

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

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

ответил MadBoy 27 +03002016-10-27T18:33:59+03:00312016bEurope/MoscowThu, 27 Oct 2016 18:33:59 +0300 2016, 18:33:59
-13

Я всегда делаю mydomain.local.

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

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

ответил Portman 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 24 Sep 2010 00:03:52 +0400 2010, 00:03:52

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132