Рекомендации по именованию в Windows Active Directory?

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

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

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

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

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

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

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

There are only two correct answers to this question.

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

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

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

Но все используют.local!
Не имеет значения Ты не должен. Я писал в блоге об использовании.local и других вымышленных TLD, таких как.lan и.corp. Ни при каких обстоятельствах вы никогда не должны делать это.

Это не более безопасно. Это не "лучшие практики", как утверждают некоторые люди. И это не имеет никакой выгоды по сравнению с двумя вариантами, которые я предложил.

Но я хочу назвать его так же, как URL моего общедоступного веб-сайта, чтобы мои пользователи example\user вместо ad\user
Это действительная, но ошибочная задача. Когда вы продвигаете первый контроллер домена в домене, вы можете установить для 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 тыс. Пользователей, использующих AD, которые все еще ссылаются на старую компанию, которую они купили много лет назад, или компании, которые сменили имена, и хотя в долгосрочной перспективе не имеет значения, что вы используете \login (если вы не можете используйте UPN) это все еще выглядит плохо перед руководством, которое не понимает, почему это не тривиально изменить это.

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

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

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