Назва локального домену. Як не потрібно називати домени Active Directory. Останні штрихи на шляху до досконалості

Прийшла весна, і з нею - загострене бажання народити фундаментальний матеріал, який відповідає на питання, який начебто очевидна, але при цьому критично важливий при проектуванні: яке ж ім'я дати домену Active Directory, щоб потім не було нестерпно боляче?

У цій статті я постараюся провести вас від найгірших варіантів імені домена Active Directory до самого, на мою думку, кращого варіанта, попутно вказавши на подоланні граблі.

Домен з single-label ім'ям не придатний для використання у продуктивній середовищі, і єдиний правильний шлях - позбутися від нього якомога швидше.

Неприпустимі символи в імені домена

Наприклад, знак підкреслення. Хоча в попередніх версіях Windows Server цей знак допускався при виборі DNS-імені домена, він не відповідає стандарту RFC 1123 для DNS. Нові версії Windows Server вже не дозволяють називати домени наперекір стандарту. Якщо домен з ім'ям, що містить підкреслення, був успадкований, очікуються великі неприємності. Наприклад, не можна встановити Exchange 2007 і вище. Рішення одне - позбутися від неприпустимих символів в імені домена за допомогою міграції в інший домен (переважно), або процедури перейменування домену (небезпечно).

Disjoint namespace

Один з окремих випадків Disjoint namespace - це ситуація, коли Netbios-ім'я домену відрізняється від крайньої лівої частини DNS-імені домену.

Netbios Name \u003d TEST
DNS Name \u003d lab.сайт

З точки зору функціональності, така конфігурація повністю підтримується. Але я все ж рекомендую уникати її, щоб не вносити плутанини і неоднозначності.

.local або ICANN

У багатьох навчальних посібниках можна зустріти назви доменів виду company.local. Дійсно, немає ніякого криміналу в тому, щоб використовувати такі імена в навчальних і тестових цілях. Гірше, коли по тій же схемі називають реальні домени:

• Ім'я суперечить ідеології глобального DNS: не дає гарантії відсутності колізій з іншими такими ж доменами (коли прийде пора встановлювати довірчі відносини)
• Відсутня можливість використовувати дане ім'я для доступу з глобальної мережі (коли прийде пора публікації)
• На домен, володіння яким неможливо підтвердити, не можна отримати публічний SSL-сертифікат. Дане обмеження особливо актуально з розвитком хмарних сервісів, Когад розмиваються межі між on-premise і cloud сервісами. Просто приклад: для роботи Single Sign On зі службами Officе 365 потрібно AD Federation Services c публічним сертифікатом

Тому я рекомендую при іменуванні домену завжди використовувати офіційно зареєстроване глобальне ім'я в ієрархії ICANN (Internet Corporation for Assigned Names and Numbers), яка гарантовано позбавить від описаних вище недоліків.

сайт
argon.com.ru
irom.info

Виділити або поєднати

Уявімо, що ми проектуємо доменну структуру для компанії Argon, яка має сайт за адресою сайт, а також використовує адреси електропошти в цьому ж домені.? Але цього краще не робити з наступних причин:

• Якщо всередині мережі такої організації в браузері ввести адресу http: // сайт /, то потрапимо ми не на сайт компанії, а на перший-ліпший контролер домену.
• Адміністрування публічних і внутрішніх DNS-записів утруднено: всі публічні DNS-записи в зоні сайт, які використовуються з внутрішньої мережі повинні бути продубльовані на внутрішній зоні DNS. Також необхідно якось забезпечувати синхронізацію цих записів.

Наприклад, в інтернеті є сайт www.сайт. Щоб користувачі з внутрішньої мережі могли на нього потрапити, потрібно створити аналогічний запис і у внутрішній зоні DNS

• Є ймовірність виникнення колізій між внутрішніми і зовнішніми іменами ресурсів.

Наприклад, у внутрішній мережі широко використовується сервер ftp.сайт. Раптово виникла необхідність надавати користувачам інтернету файловий сервіс за тією ж адресою ftp.сайт. Що вийшло? Внутрішні користувачі не можуть підключитися до зовнішнього сервісу по зазначеному імені ...

Таким чином, для домену Active Directory краще мати виділений простір імен (namespace), відмінне від простору імен в інтернеті (сайту компанії тощо). І тут теж є вибір:

• Використовувати для AD повністю інше ім'я (сайт для сайту, argon.com.ru для AD)
• Використовувати для AD дочірнє ім'я (сайт для сайту, lab.сайт для AD)

Обидва варіанти задовольняють ідеології DNS і позбавлені перерахованих вище недоліків, але другий варіант з дочірнім доменом може бути зручніше з точок зору:

• підтримки зареєстрованих доменних імен (оплата реєстрації і DNS-хостингу тільки одного домену)
• доступності красивих імен для реєстрації (реєструвати не потрібно)
• отримання публічних SSL-сертифікатів (всього один wildcard-сертифікат можна використовувати як для сайту компанії, так і при публікації ресурсів внутрішньої мережі)

Отже, пропоную вибрати для AD виділений, але дочірній щодо сайту організації домен.

lab.сайт
corp.microsoft.com

Split-brain

Split-brain DNS означає використання одного доменного імені для публікації ресурсів як у внутрішній мережі, так і в інтернеті. При цьому DNS-сервера внутрішньої мережі дозволяють адреси виду portal.lab.сайт у внутрішні IP-адреси, а публічні DNS-сервера в інтернеті, відповідно, в зовнішні IP. приклад:

За рахунок split-brain досягаються такі корисні речі, як, єдині адреси для доступу до ресурсів як з внутрішньої мережі, так і з інтернету. Користувачеві досить знати одну адресу portal.lab.сайт, за яким він може дістатися до своїх документів, і не важливо, де він знаходиться: в офісі компанії або в готелі.

З точки зору інфраструктури, зручно мати один і той же адресу для СRL або OCSP в SSL-сертифікати, що випускаються внутрішніми CA.

При відсутності split-brain може виникнути необхідність створювати так звані pinpoint-зони на внутрішніх серверах DNS, такі «точкові» зони будуть містити тільки ті записи, для яких потрібно підмінити «публічні» значення, на «приватні», характерні для внутрішньої мережі (ситуація схожа з описаною під заголовком «Виділити або поєднати»).

Приклад pinpoint-зони:

Уточнити чи узагальнити

У літературі можна зустріти поради називати домени (особливо кореневої) узагальненим словом, на зразок Bank, Company або Corp. На те є причини, так як в наш час компанії можуть регулярно переживати злиття і поглинання, зміну торгової марки. А ім'я домену, як відомо, поміняти дуже складно.

З іншого боку, при тому ж злиття і поглинання компаній вельми вірогідна міграція користувачів з одного домену в інший. На практиці мені зустрічалася ситуація, коли потрібно було мігрувати користувачів з десятка доменів з одним і тим же ім'ям Bank. Як відомо, установка довірчих відносин між доменами з однаковими іменами (будь то DNS або Netbios) неможлива. Доведеться або перейменовувати ці домени, або мігрувати дані в два етапи, через третій домен.

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

Останні штрихи на шляху до досконалості

• глобально зареєстроване
• виділене (дочірнє від домену сайту компанії)
• специфічне
• використовуємо split-brain

lab.сайт
corp.microsoft.com

При цьому для адрес електропошти і SIP-адрес в Lync було б приємніше використовувати більш короткі адреси [Email protected]сайт. Ніщо не заважає нам зробити це, але виникнуть незручності.

Адреса електропошти у користувача \u003d [Email protected]сайт, логін входу \u003d lab \\ user, user principal name \u003d [Email protected]сайт. Тут легко заплутатися не тільки користувачеві, але і програмами на кшталт Outlook і Lync.

Після невеликих модифікацій облікових записів, користувачі матимуть user principal name рівним адресою електропошти. Плутанини стане менше, а такі програми, як Lync і Outlook припинять питати логін користувача, їм буде досить знати e-mail або SIP адреса.

Мої фундаментальні праці:

Статті на інших ресурсах:

• Active Directory Domain Naming Considerations - а ось і наспів сухий гайд від Microsoft
• Naming conventions in Active Directory for computers, domains, sites, and OUs - дивіться підрозділ Forests that are connected to the Internet
• Why you should not use .local in your Active Directory domain name - схожа стаття від закордонного колеги

На дворі 2015 рік, інтернет отримав масове поширення, у кожної поважаючої себе компанії давно є свій веб-сайт. Не потрібно далеко ходити - навіть у кожній міській лікарні є свої веб-ресурси. Але тим не менше все одно сисадміни не навчилися створювати нормальні імена для своїх доменів.

Вартість домена другого рівня (наприклад, bissquit.com) становить трохи більше 500 рублів на рік. Це дуже мало навіть для звичайних громадян, як ми з вами, і це сущі копійки для компаній тим більше. Свій домен я придбав ще задовго до того, як з'явилася ідея «запив» цей бложік. Це просто зручно. Візьмемо навіть віддалене підключення по rdp - я вводжу ім'я свого домену, замість похмурого ip-адреси.

В інтернеті на запит «active directory domain best practices» майже на кожному сайті написані комплексні рекомендації щодо іменування доменів AD і дані пояснення чому потрібно зробити саме так. Давайте розглянемо докладніше про які рекомендації йдеться:

• Для іменування домену AD використовуйте піддомен вашого офіційно зареєстрованого домену організації.

Ви все зрозуміли правильно, тільки одна порада. Це все! Можна багато розмірковувати про деталі і дрібних нюансах, але 80-90% міркувань зводяться до одного єдиного раді, озвученого вище. Всі проблеми виходять з того, що людина знає, що так потрібно робити, але не розуміє чому не можна або вкрай не рекомендується робити по-іншому. З цього моменту докладніше.

1. Чому не можна використовувати внутрішні, Не дозволяється зовні імена тіпа.local, .corp, .lan?

Можна, можливо. Ще як можна. Більшість саме їх і використовують. У мене є приклади серед знайомих, у яких в організаціях 2000+ людина і використовується домен.local. Всі труднощі почнуться, якщо раптом стане потрібен реальний домен AD. Таке може статися при використанні гібридних хмарних розгортання (яскравий тому приклад Exchange + Office365). «Чому б просто не перейменувати домен, адже з певною версією AD це цілком можливо?» - запитаєте ви. Так в принципі можна, проте вам доведеться зіткнутися зі складнощами міграції доменнозавісімих сервісів. Серед них все той же Exchange та ін., Але тут і одного Exchange більш ніж достатньо.

2. «Ок, купуємо реальне зовнішнє ім'я - my-company.com, також назвемо і домен AD» - теж не варіант. Виникнуть проблеми з дозволом інших ресурсів, розташованих на адресу my-company.com, наприклад, веб-сайт компанії. Та й до того ж ваші DNS-сервери не будуть авторитативні для цього домену, хоча вважатимуть себе такими. Це теж викличе проблеми.

Є й інші міркування щодо іменувань доменів, серед них створення аналогічного реальному домену але в іншому TLD. Але мені здається великого сенсу так робити немає, адже частина проблем все одно залишається, а явних переваг в порівнянні з використанням домену corp.my-company.com (ім'я взято для прикладу) просто немає.

Для любителів зробити все по-своєму з недавнього часу додадуться ще й проблеми з сертифікатами, тому сенсу використовувати внутрішні імена зараз взагалі немає.

Питання вибору імені домена технічно впирається в рядок, в якій ви пропишіть ім'я при створенні домену AD і ні в що більше. Однак наслідки, які спричинить за собою неправильний вибір імені, в майбутньому принесуть вам чимало проблем і тому на етапі планування дуже важливо все зробити якісно. Зайвий раз непогано почитати статті бувалих адмінів

Вчора, до нас в студію, надійшов лист від нашого постійного читача Андрія, з питанням:

Із задоволенням читаю ваш блог, багато корисного для себе дізнався, хотів дізнатися вашу думку з приводу імені домена Active Directory, багато пишуть що називати варто його * організація * .local, а хтось пише що варто назвати так-же як і домен.

Давайте коротко розберемося яке ж краще використовувати ім'я при найменуванні домену всередині організації.

Як показує практика вибір імені домена може поставити в ступор навіть досвідченого системного адміністратора. При першому запуску утиліти dcpromo ім'я домену буде згенеровано автоматично і випадковим чином, якщо вже на цьому етапі не привести ім'я домену в відповідність необхідним правилам, то в майбутньому змінити ім'я домену буде складніше. Давайте розглянемо можливі варіанти в порядку їх популярності.

1. Домен з ім'ям example.local

Лідером нашого хіт-параду є іменування домену із закінченням на local. Існують і інші варіації на цю тему, наприклад test, firma, factory, nn, loc, і так далі. Зараз навіть уже й не згадаєш звідки пішла така любов, у всіх своїх книгах компанія Microsoft завжди використовує свої іменування виду contoso.com, Де ми чітко бачимо формат іменування домену. Однак протягом майже 10 років домен .local займав лідируючі позиції. Ситуація стала вирівнюватися з приходом сервісів використовують в своїй роботі SSL сертифікати. Де використання доменів «пофіг і так зійде» стає неможливим. Дивіться, припустимо, що ваша компанія використовує всередині організації Exchange server, Якому необхідний ssl сертифікат для шифрування клієнтських підключень. Згідно з вашим сценарієм для реалізації цього завдання вам потрібні сертифікати зовнішнього центру сертифікації, В якому необхідно вказати всі імена серверів використовуваних для зовнішнього підключення. Здавалося б що такого, записуємо все імена серверів і подаємо заявку на випуск сертифікатів, але є одне але. З ім'ям такого домену ви не зможете пройти валідацію, Так як домен «пофіг і так зійде» не існує і на спробу пояснити зовнішньому центру сертифікації, що вам в SAN потрібно засунути FQDN ім'я неіснуючого домену отримаєте м'який відмова:

It's not possible, we issue only certificates for real domain names.

Але існує ще одна неприємність. Використання доменного імені що не належить вам в імені домена може привести до плачевних наслідків. Уявіть ситуацію якщо зона local матиме статус публічної. як зона com або ru. Далі я думаю продовжувати не варто 🙂

2. Ім'я домену збігається з зовнішнім ім'ям домену

Друге місце нашого хіт-параду. Не дивлячись на те, що такий сценарій є менш популярним, він все ж має право на життя. Крім того, що в найближчому майбутньому ви все ж отримаєте деякі незручності при обслуговуванні мережі, більше вам нічого не загрожує. Основною проблемою в цьому сценарії є те, що вам доведеться підтримувати два DNS сервера: внутрішній і зовнішній. За такої умови комп'ютери знаходяться всередині мережі будуть використовувати для розпізнавання імен внутрішній DNS сервер, а комп'ютера за периметром компанії зовнішній. Припустимо ваш домен носить горду назву example.com. В DMZ зоні у вас знаходиться сайт компанії з ім'ям example.com. В описаному сценарії вище комп'ютери знаходяться всередині організації не зможуть отримати до нього доступ з огляду на те що для них example.com це ім'я домену і при введенні цієї адреси в браузері вони будуть потрапляти на контролер домену. Як я вже зазначив вище крім незручності це ні до чого не приведе. Ви завжди можете використовувати милиці, які будуть перекидати вас на зовнішній сайт, але погодьтеся це не потрібна подвійна робота, або всередині мережі використовувати ім'я сайту починається з www, Або зовні.

3. Ім'я домену з одного слова

Мабуть самий не правильний варіант з наведених вище. Однорівневі домени: Single-label domain - це домен, який містить тільки одну складову. По всій видимості їх почали використовувати за часів NT, коли компанія Microsoft перейняла вдалий досвід компанії Novell. Так склалося, що спочатку я був адміністратором FreeBSD і великого парку серверів NetWare починаючи з версії 4.11, так ось в ті стародавні часи NetWare використовувала в своїй роботі Bindery, яка як раз імена схему одноуровнего домену, Яку потім і перейняла компанія Microsoft.

Best practices

Пора підвести підсумок. Яке ж іменування домену використовувати? Тільки домен третього рівня в домені яким ви володієте. Не варто використовувати чужі красивіші доменні імена :-). Приклад такого домену ви можете побачити нижче.

Вибір імені домена завдання нескладне, але як показує життя досить часто після запуску dcpromo ім'я домену генерується випадковим чином. Начебто і нічого страшного, домен працює, принтери друкують, 1С відкривається. Але на жаль є ряд ситуацій, коли генерація випадковим чином імені, якщо не вийде вам боком, то клопоту однозначно додасть. У цій невеликій замітці я спробую розповісти про те, як не варто називати ваші домени і чому. Інформація хоч і відома, але реальне життя показує, що помилки в іменуванні просто повальні. А оскільки процедура перейменування домену це ит-шное садо-мазо, краще все робити спочатку правильно.

1. Ситуація перша. Ім'я домену - domainname.local

Напевно найпоширеніший варіант це використання окончанія.local або будь-якого іншого домену першого рівня, що не використовується IANA. (А-ля.msk ілі.test ілі.loc і.т.д) Звідки це пішло зараз важко сказати, є кілька варіантів. Один говорить про те, що в 2000-му коли AD з'явилася на конференції в демонстрації доповідач зробив такий домен.
Ну і народ сприйняв це як заклик до дії. Друга гіпотеза, хоч і не виключає першу схиляється до того, що швидше за все MSFT сама написала явно рекомендацію в літературі, після чего.local і пішов в народ. Чим же поганий такий варіант?

Сценаріїв декілька, але я розповім і наболіле. Припустимо ви встановлюєте всередині організації Exchange Server, якому потрібні сертифікати для шифрування клієнтських підключень. Сертифікат хочеться від комерційного центру, все як у людей. Природно в сертифікаті повинні бути вказані всі імена сервера за якими сервер буде доступний. І якщо зовнішній домен належить нам і легко пройде валідацію, то внутрішній домен а-ля super-firma.moscow не існує і при спробі пояснити центрам сертифікації, що вам в SAN потрібно запхати FQDN - exchange.super-firma.moscow отримаєте відповідь:

It's not possible, we issue only certificates for real domain names.

На поточний момент запихати в SAN сертифіката всякі непристойні слова дозволяє Comodo Certificate Authority, що значно звужує вибір постачальника сертифікатів, та й гарантії, що вони будуть вирішувати це і далі немає.

2. Ситуація друга. Ім'я домена AD збігається з зовнішнім інтернет ім'ям домену.

Теж частий варіант, але при ньому проблеми з сертифікатами не буде. Зате виникають проблеми з дозволом імен. Виходить ситуація, коли зовнішні і внутрішні DNS сервера не пов'язані між собою, але при цьому обслуговують незв'язані зони з однаковими іменами. У такій ситуації кожен внутрішній сервер логічно вважає себе авторитативним для зони і при незнанні про яке-небудь хості авторитетно заявляє - НІ! Оскільки ви маєте якісь зовнішні ресурси, саме банальне веб-сайти, природно записи типу А додаються в зону на зовнішньому DNS сервері. Тепер коли внутрішній клієнт спробує дозволити ім'я зовнішнього ресурсу, його запит потрапить на внутрішній DNS сервер, (природно, це ж доменний клієнт) а той у відповідь "не знаю, немає такого і можеш не шукати", т.к бачить, що він авторитативні для цієї зони сервер.

Для вирішення цієї проблеми вам доведеться прописувати зовнішні записи в двох зонах, а це неминуче приведений до плутанини і додаткової рутині. Якщо вас це не лякає, то спробуйте при такому сценарії дозволити внутрішнім користувачам відкривати корпоративний сайт без префікса www. Загалом поганий варіант і не треба його використовувати.

Особливий привіт тим адміністраторам, які назвали свої внутрішні домени іменами чужих знаменитих публічних доменів. Думаю який геморой в такому випадку вам забезпечений пояснювати не потрібно.

3. Ситуація третя. Плоске ім'я домену складається з одного слова.

Якщо перші два варіанти ще можна пережити, то за плоскі імена доменів пора ввести адміністративне покарання. Single-label domain (однорівневий домен, SLD) - це домен, що містить тільки одну іменну складову. Звідки пішла манія їх використовувати, я не знаю, але вже давно офіційно визнано, що SLD домени не повинні використовуватися при побудові ІТ-інфраструктур.

При цьому дана інформація такий канадський баян, що залишається тільки дивуватися звідки SLD домени беруться. http://support.microsoft.com/kb/300684.

Чим загрожує? Відсутністю підтримки з боку продуктів Microsoft такій конфігурації. Зі свіжого. Спробуйте встановити Exchange 2010 SP1 в домені з плоским ім'ям, отримаєте повідомлення про те, що така конфігурація більше не підтримується.

Як же правильно назвати домен?

Відповідь проста. Робити узгоджене простір імен. Тобто маючи домен сайт в реальному світі, домен Active Directory робити суб-доменом типу corp.сайт. При такому розкладі всі проблеми відпадають. І зовсім не обов'язково робити делегування DNS суб-домену на зовнішньому DNS сервері. Хоча якщо ви це зробите, можна домогтися дозволу імен в обидві сторони. (З внутрішньої мережі зовнішніх імен, з Internet внутрішніх імен)

Для тих, хто не подумав спочатку є "хороша" посилання: http://technet.microsoft.com/en-us/library/cc738208(v\u003dws.10).aspx Приємних Вам ввечері за читанням даного твору.

MCP / MCT Ілля Рудь

Добрий день шановні читачі і передплатники, що то я вам давно не розповідав про домени Windows, сьогодні я це виправлю і ми розберемо таку фундаментальну тему, як правильно назвати домен active directory, так як від цього буде подальше, правильне функціанірованіе ваших сервісів, і ви зменшите собі кількість проблем, які могли б виникнути при неправильному імені доменних служб.

Помилки у виборі імені Active Directory

Якщо ви давно читаєте мій блог або тільки приєдналися, то я вам нагадаю про вступну статтю введення в Active Directory, там я постарався розповісти, що таке AD і як вона працює, а головне з яких компонентів вона складається. Якщо ви уважно читали, то знаєте, що Active Directory не може працювати без DNS серверів.

• Я впевнений, що більшість з вас знають, що DNS імена в інтернеті будуються за певним принципом, воно складається лише з цифр, букв, крапок і тире (про різні види записів DNS я не кажу) .. com. Є стандарт з документа RFC тисячі сто двадцять три про іменування доменів, де чорним по білому прописано, що в назвах не повинні бути присутніми ось такі спецсимволи: знак собаки @, тильда ~, знак номера #, слеш / і \\, нижнє підкреслення, якщо ви за своїм незнанням в якості доменного імені вибрали, що то що містить нижнє підкреслення, то у вас наприклад будуть великі проблеми з поштовим сервером MS Exchange. Якби не було стандартів, був би хаос.
• Як локальних імен Active Directory, люди вибирають зовнішні адреси, точніше імена другого рівня. Простий приклад, у мене допустимо є підприємство Pyatilistnik.inc і адміністратор вирішив встановити контролер Active Directory і створити доменну структуру, але в якості локального імені для нього він узяв pyatilistnik .. Уявіть який хаос почнеться, коли людям потрібно буде до нього достукатися з локальної мережі , буде конфлікт з ім'ям AD, вам щоб вирішити проблему доведеться тримати і зовнішню зону DNS і внутрішню, що не зручно і призведе до помилок. Нижче я розповім як правильно назвати домен active directory
• Імена зон не входять в глобальний офіційно зареєстрований реєстр ICANN. Прикладами може служити зони.local або напрімер.nn, хоча я впевнений, що і до них дійде стандарт, так як даної організації вигідно робити гроші з повітря, продаючи імена, яких зараз доменів вже не зустрінеш, але мова сьогодні не про це. Ці імена не правильно використовувати в Activer Directory, так як їх не можна буде використовувати за межами вашої контори, не можна буде випустити ssl сертифікат на домен.

Хоча якщо ви робите це в тестовому середовищі, то можна

• Disjoint Namespace\u003e бувають ситуації, коли DNS ім'я контролера домену або комп'ютера не збігаються з його NETBIOS ім'ям, наприклад якби у мене контролер мав NETBIOS ім'я dc6, а доменне dc.сайт. Такі конструкції працездатні і можуть бути при злитті підприємств, але при Disjoint Namespace можуть бути і граблі з тим же MS Exchenge. Нижче приклад збігу і NETBIOS і DNS імені.

Як правильно назвати домен active directory

Як неправильно робити ми зрозуміли і знаємо, зробимо тепер все красиво, відразу повторюся, що якщо у вас тестового середовища називати AD ви можете як вам захочеться, хоч microsoft.com. А якщо по серйозному, то повернемося до нашої компанії Pyatilistnik.inc. Для доменної зони Active Directory я б вибрав зону третього рівня, ad.сайт. Веб сайт компанії повісив би на логічний сайт. Завдяки цьому не було б проблем з MS Exchange сервером. Якщо у вас кілька філій, то я раджу вам використовувати один ліс, приклад є Нижній Новгород і Москва, для Москви я вибираю ad..ad.сайт. Сподіваюся ви тепер зрозуміли як краще і правильніше називати домен Active Directory.