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

Это канонический вопрос об именах доменов в 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, установленные на каждом контроллере домена в организации, где работает веб-сайт, который выполняет перенаправление так, что кто-то, входящий foo.comв их браузер, будет перенаправлен на www.foo.comэти установки IIS. Совершенная глупость!

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

Использование такого субдомена не влияет на такие вещи, как доставка электронной почты Exchange или суффиксы имени участника-пользователя (BTN). (Я часто вижу, что оба приводятся в качестве оправдания для использования имени домена Интернет в качестве имени домена 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
этого действовали, но ошибались. Когда вы продвигаете первый контроллер домена в домене, вы можете установить для 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-адрес.