Windows Active Directory називає кращі практики?

Це канонічне запитання щодо імені домену Active Directory.

Експериментувавши з доменами Windows та контролерами домену у віртуальному середовищі, я зрозумів, що мати активний домен каталогів, названий ідентично домену 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-адреси, на які посилаються зовнішні імена хостів. (Спробуйте використовувати DNS з географічним навантаженням для зовнішніх хостів і інтегруючи це з такою ситуацією "розділеного DNS"! Так, це було б весело ...)

Використання такого піддомену не впливає на такі речі, як суфікси доставки електронної пошти або суфікси основного імені користувача (UPN), BTW. (Я часто бачу тих, хто цитується як виправдання для використання доменного імені Internet як доменного імені AD.)

Я також бачу виправдання "багато великих компаній роблять це". Великі компанії можуть приймати рішення без зусиль так само легко (якщо не більше), ніж невеликі. Я не купую це лише тому, що велика компанія приймає неправильне рішення, яке чомусь спричиняє це хороше рішення.

На це питання є лише дві правильні відповіді.

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
цього були справжніми, але помилковими проблемами. Просуваючи перший DC в домені, ви можете встановити ім'я домену NetBIOS таким, яким ви хочете. Якщо ви будете дотримуватися моїх порад і налаштувати свій домен таким чином ad.example.com, ви можете налаштувати ім'я NetBIOS домену exampleтаким чином, щоб ваші користувачі входили як example\user.

У Active Forests and Forests ви також можете створювати додаткові суфікси UPN. Ніщо не заважає створити та налаштувати @ example.com як основний суфікс UPN для всіх облікових записів у вашому домені. Якщо поєднувати це з попередньою рекомендацією NetBIOS, жоден кінцевий користувач ніколи не побачить, що FQDN вашого домену є ad.example.com. Все, що вони побачать, буде example\або @example.com. Єдині люди, яким потрібно буде працювати з FQDN, - це адміністратори систем, які працюють з Active Directory.

Крім того, припустимо, що ви використовуєте простір імен DNS з розділеним горизонтом, це означає, що ваше ім’я AD таке ж, як і ваш загальнодоступний веб-сайт. Тепер ваші користувачі не можуть потрапити на example.comвнутрішню службу, якщо ви не встановите їх префікс www.у своєму браузері або не запустите IIS на всіх своїх контролерах домену (це погано). Вам також доведеться лікувати двохнеідентичні зони DNS, які мають спільний простір імен. Це справді більше клопоту, ніж варто. Тепер уявіть, що у вас є партнерство з іншою компанією, і вони також мають DNS-конфігурацію з розділеним горизонтом, а також їх AD та зовнішню присутність. У вас є приватний зв'язок між ними і вам потрібно створити трест. Тепер увесь ваш трафік на будь-який їх публічний веб-сайт повинен проходити через приватне посилання, а не просто виходити через Інтернет. Це також створює всілякі головні болі для адміністраторів мережі з обох сторін. Уникайте цього. Довірся мені.

Але, але ...
Серйозно, немає причин не використовувати одну з двох речей, які я запропонував. Будь-який інший спосіб має підводні камені. Я не кажу вам поспішати змінювати своє доменне ім’я, якщо воно функціонує і на місці, але якщо ви створюєте нову рекламу, зробіть одну з двох речей, які я рекомендував вище.

Щоб допомогти MDMarra у відповідь:

Ви повинні НІКОЛИ не використовувати ім'я DNS з однієї мітки для вашого доменного імені або. Це було / було доступне до Windows 2008 R2. Причини / пояснення можна знайти тут: Розгортання та експлуатація доменів Active Directory, які налаштовані за допомогою однозначних імен DNS | Підтримка Microsoft

Не забудьте НЕ використовувати зарезервовані слова (таблиця міститься у посиланні "Конвенції про іменування" внизу цієї публікації), таких як СИСТЕМА або СВІТ або ОБМЕЖЕНО.

Я також погоджуюся з Microsoft, що вам слід дотримуватися двох додаткових правил (які не встановлені в камені, але все ж):

1. НЕ слід називати свій домен на основі того, що зміниться або застаріє. Приклади включають в себе іменування вашого домену за продуктовою лінією, операційною системою чи будь-яким іншим, що може змінитися з часом. Дотримуйтесь географічного чи конкретного чимось, щоб мати сенс 5, а то й 10 років в дорозі.
2. Дотримуйтесь коротких імен 15 символів або менше, це дозволить імені NETBIOS легко бути таким же, як ім'я домену.

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