1. Ситуація перша. Ім'я домену - domainname.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 збігається з зовнішнім інтернет ім'ям домену.
Для вирішення цієї проблеми вам доведеться прописувати зовнішні записи в двох зонах, а це неминуче приведений до плутанини і додаткової рутині. Якщо вас це не лякає, то спробуйте при такому сценарії дозволити внутрішнім користувачам відкривати корпоративний сайт без префікса www. Загалом поганий варіант і не треба його використовувати.
Особливий привіт тим адміністраторам, які назвали свої внутрішні домени іменами чужих знаменитих публічних доменів. Думаю який геморой в такому випадку вам забезпечений пояснювати не потрібно.
3. Ситуація третя. Плоске ім'я домену складається з одного слова.
Якщо перші два варіанти ще можна пережити, то за плоскі імена доменів пора ввести адміністративне покарання. Single-label domain (однорівневий домен, SLD) - це домен, що містить тільки одну іменну складову. Звідки пішла манія їх використовувати, я не знаю, але вже давно офіційно визнано, що SLD домени не повинні використовуватися при побудові ІТ-інфраструктур.
Як же правильно назвати домен?
Відповідь проста. Робити узгоджене простір імен. Тобто маючи домен itband.ru в реальному світі, домен Active Directory робити суб-доменом типу corp.itband.ru. При такому розкладі всі проблеми відпадають. І зовсім не обов'язково робити делегування DNS суб-домену на зовнішньому DNS сервері. Хоча якщо ви це зробите, можна домогтися дозволу імен в обидві сторони. (З внутрішньої мережі зовнішніх імен, з Internet внутрішніх імен)
Прочитайте пост, я написав в чому проблема.
З приводу першого сценарію: так дійсно, Microsoft не рекомендує використовувати незареєстровані в Інтернет dns-суфікси, але це не стільки проблема з сертифікатами (або чимось іншим), скільки неможливість забезпечити якусь унікальність імен, на випадок подальшого злиття. Знову ж таки, якщо у вас немає таких вимог, то можна про це і не замислюватися. Інша справа якщо є будь-які спеціальні вимоги або є якесь конкретне оточення.
По частині Exchange і сертифікатів для IIS: це не така вже й проблема і вона вирішувана. Так, і навіщо на зовнішньому сайті світити записи внутрішніх ресурсів?
Тому, на мій погляд, не можна в трьох рядках описувати, як можна робити, а як не можна. Потрібно або писати про конкретні випадки проблем або просто перевести те, що Microsoft вже написав по частині іменування.
Потрібно називати свої служби каталогів, враховуючи оточення і, найголовніше, відповідно до вимог!
З приводу того, що Microsoft пише, що домен є security-кордоном:
Це не зовсім так. Microsoft пише, що домен є якоюсь кордоном політик паролів (особливо Kerberos-конфігурації), але ні як не security-boundary. У документах можна побачити щось таке:
Because a domain is not a security boundary, it is possible for a malicious service administrator, such as a member of the Domain Admins group, to use nonstandard tools and procedures to gain full access to any domain in the forest or to any computer in the forest. For example, service administrators in a nonroot domain can make themselves members of the Enterprise Admins or Schema Admins group.
Схоже що в статті розібраний випадок з одним кореневим доменом, але бувають випадки коли створюються дерева з різними просторами імен, на те можуть бути юридичні причини або які небудь ще. Простіше перейменувати статтю на: "Які варіанти іменування в яких випадках зручніше використовувати", законів і теорем з доказами які можна використовувати варіанти немає, все завасіт від фантазії архітектора :)
Віктор, простіше не мудрувати і не вигадувати "будь-які" причини. Проблем з декількома деревами ніяких, підхід той же що і в статті. А фантазії в ІТ у архітектора, замість розрахунку зазвичай закінчуються сумно.
Ілля я сказав про те, що бувають різні ситуації, коли зовнішнє ім'я може абсолютно не збігатися з внутрішнім, коли використовується не одна зовнішня зона і що, всім потрібно буде користуватися перейменуванням лісу щоб собі життя полегшити і підігнати під ваш варіант який названий єдиним правельно) ? Не бачу проблем з першим варіантом в частині дозволу імен, будь ласка використовуйте Split-DNS що так багато імен і вони кожні два дні змінюються в зовнішніх зонах. Навеняка, якби був один реально вірний варіант іменування нам би вказали про нього в дизайн гайдах. Я тільки бачив, опис лише підтримуваного варіанти з плоскими іменами.
"І зовсім не обов'язково робити делегування DNS суб-домену на зовнішньому DNS сервері. Хоча якщо ви це зробите, можна домогтися дозволу імен в обидві сторони. (З внутрішньої мережі зовнішніх імен, з Internet внутрішніх імен) "
Підкажіть, будь ласка, чи направте в правильне русло (поки не дуже розумію, але дуже цікаво!):
До чого пріведетдля чого роблять делегування суб-домену на зовнішньому ДНС- "розпізнавання імен в обидві сторони. (З внутрішньої мережі зовнішніх імен, з Internet внутрішніх імен) "" - як буде виконуватися цей дозвіл імен, і навіщо це може стати в нагоді?
Як варіант я бачу використовувати його так - наприклад в corp.itband.ru можна буде додати запис на суб-домені типу а "ithome", але не зрозумію, для чого може стати в нагоді "розпізнавання імен в обидві сторони".
Завчасно дякую за відповідь
Питання з розділу "Особливий привіт тим адміністраторам, які назвали свої внутрішні домени іменами чужих знаменитих публічних доменів. Думаю який геморой в такому випадку вам забезпечений пояснювати не потрібно. "
Дісталася компанія з доменним ім'ям "ІМЯ_КОМПАНІІ.OFFICE". Все було добре. Проблеми почалися місяць тому.
Підкажіть як тимчасово вирішити проблему?
Хлопці, безболісно ніяк не перейти.
Вихід один cross-forest-migration. Є ще варіант rename domain, але в ньому стільки "АЛЕ".
Ілля, я вас зрозумів.
В такому випадку ще одне питання: чи обов'язково міграцію робити через ліс, або можна підняти другий домен в цьому ж лісі і мігрувати. Які при цьому можуть виникнути проблеми, якщо порівнювати з міграцією між лісами?
Думаю що це шлях тупиковий, наскільки я знаю кореневої домен видалити не вийде після міграції. (А він у всіх проблемних швидше за все кореневої)