Назва локального домену. Правильно називаємо домен Active Directory. Можливі проблеми з динамічною реєстрацією записів DNS у зонах прямого перегляду з однокомпонентними іменами
Вибір імені домену завдання нескладне, але як показує життя досить часто після запуску 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 тільки 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=ws.10).aspx Приємних Вам увечері за читанням цього твору.
MCP/MCT Ілля Рудь
На подвір'ї 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. Виконувати завдання із перейменування доменів можна лише в тому випадку, якщо всі домени в лісі оснащені як мінімум операційною системою Windows Server 2003 (у цьому випадку за редакціями немає жодних обмежень). Більше того, функціональний рівень повинен бути підвищений щонайменше до рівня Windows Server 2003. Тобто, якщо у вас у лісі обраний функціональний рівень Windows Server 2000, то виконання наступної операції стане неможливим;
- Розміщення домену. У лісі Active Directory може бути різний рівень доменів. Тобто, можуть бути окремий домен, або ліс може включати дочірні домени. Якщо ви будете змінювати розташування контролера домену всередині лісу, вам доведеться створити довірчі відносини;
- Зона DNS. Ще до виконання операції перейменування домену необхідно створити нову зону DNS;
- Адміністративні облікові дані. Для виконання операції перейменування домену ви повинні виконати вхід до системи під адміністративним обліковим записом, який є членом групи адміністраторів підприємства (Enterprise Admins);
- Сервери розподіленої файлової системи (DFS). Якщо у вашому корпоративному середовищі розгорнуті служби DFS або налаштовані профілі, що переміщуються, то зверніть увагу на те, що кореневі DFS-сервери повинні працювати, як мінімум, під керуванням операційної системи Windows Server 2000 з пакетом оновлень 3 або під більш сучасними версіями операційних систем;
- Несумісність із серверами Microsoft Exchange. Найнеприємніший момент полягає в тому, що якщо у вашому лісі Active Directory розгорнуть поштовий сервер Microsoft Exchange Server 2003 Service Pack 1, то перейменування домену буде виконано без будь-яких проблем, але обліковий запис користувача, під яким буде виконуватись процес перейменування домену бути членом групи Full Exchange Administrator. Все більш сучасні поштові сервери (включно з Exchange Server 2016) несумісні з операціями перейменування доменів.
Також зверніть увагу на те, що на час перейменування домену ви повинні заморозити всі майбутні операції з конфігурації лісу Active Directory. Іншими словами, ви повинні переконатися, що конфігурація вашого лісу не зміниться доти, доки операція з перейменування домену не буде повністю завершена (докладну інформацію про виконання цієї дії ви побачите нижче). До таких операцій можна віднести: створення або видалення доменів всередині вашого лісу Active Directory, створення або видалення розділів каталогу додатків, додавання або видалення контролерів домену в лісі, створення або видалення встановленої безпосередньої довіри, а також додавання або видалення атрибутів, які будуть репліковані в глобальний каталог.
Про всяк випадок я ще вам порадив би зробити повну резервну копію стану системи на кожному контролері домену в лісі Active Directory. У разі виконання цього завдання, ця обережність точно не буде зайвою.
У тому випадку, якщо ваша інфраструктура відповідає вищезазначеним вимогам і зроблено всі необхідні резервні копії, ви можете розпочати процес перейменування домену.
Процес перейменування домену Active Directory
Для початку, щоб перевірити початкове ім'я вашого домену, ви можете відкрити вікно властивостей системи. Як видно з відповідної ілюстрації, мій домен називається «Biopharmaceutic.local»:
Рис. 1. Перевірка початкового імені домену Active Directory
Тепер слід створити нову зону DNS «biopharm.local» для того, щоб після успішного виконання перейменування домену ваші рядові сервери та клієнти могли без проблем приєднатися до нового доменного імені. Для цього відкрийте Диспетчер DNS» ( DNS Manager) і перебуваючи в « Зоні прямого перегляду» ( Forward Lookup Zone) виберіть опцію оп створення нової зони. По суті, зона створюється як завжди: на першій сторінці майстра створення нової зони слід прочитати вступну інформацію та перейти до другої сторінки. На сторінці типу зони виберіть основну зону ( Primary Zone) і зверніть увагу на те, щоб було активовано опцію збереження зони в Active Directory. На сторінці області реплікації зони слід залишити опцію, вибрану за замовчуванням – « Для всіх серверів DNS, що працюють на контролерах домену в цьому домені: Biopharmaceutic.local» ( На всіх DNS серверах керування домашніми контролерами в цьому будинку: Biopharmaceutic.local). На сторінці імені зони слід вказати нове ім'я домену (biopharm.local), а на сторінці динамічного оновлення також залиште опцію « Дозволити лише безпечні динамічні оновлення (рекомендації для Active Directory)» ( Allow only secure dynamic updates (recommended for Active Directory)), яка обрана за замовчуванням. Декілька етапів створення нової зони ви можете побачити нижче:
Рис. 2. Створення нової зони DNS
Наступним етапом перейменування домену буде створення опису поточного стану лісу. По суті, це перша операція з перейменування домену, в якій використовуватиметься утиліта командного рядка Rendom. За допомогою цієї утиліти буде згенеровано текстове опис вашої поточної структури лісу у вигляді XML-файлу з ім'ям Domainlist.xml. Цей файл містить список усіх розділів каталогу домену, а також розділів каталогу програм, які знаходяться у вашому лісі Active Directory. Кожен запис для кожного розділу каталогу домену та програми обмежений тегами XML
Для створення такого файлу слід під відповідним обліковим записом відкрити командний рядок і в ньому виконати команду « random /list». Згенерований файл буде збережено в кореневому каталозі облікового запису користувача. Далі вам потрібно буде відкрити цей файл за допомогою будь-якого текстового редактора.
Всередині цього файлу потрібно змінити ім'я домену всередині секції, яка обмежена тегами
На наступній ілюстрації ви побачите процес виконання вищезгаданої команди, розташування файлу Domainlist.xml та зміни для першої секції цього файлу. У моєму випадку ім'я домену в цьому конфігураційному буде змінено 4 рази:
Рис. 3. Генерація та зміна файлу Domainlist.xml
Для того щоб переконатися, що ви внесли у відповідний файл необхідні зміни, ви можете виконати команду « rendom / showforest». Як бачите на наступній ілюстрації, у мене всі записи змінилися на Bopharm:
Рис. 4. Перегляд потенційних змін
При виконанні наступної команди ( rendom /upload) утиліта Rendom переводить нову структуру лісу, вказану у відредагованому файлі, в послідовність інструкцій з оновлення каталогу, які запускатимуться локально та віддалено на кожному контролері домену в лісі. Якщо говорити загалом, то на цьому етапі в розділі каталогу конфігурації майстра іменування доменів будуть внесені зміни для перейменування домену Active Directory. Крім цього, буде створено файл Dclist.xml, який використовується для відстеження прогресу та стану кожного контролера домену в лісі для операції перейменування домену. Між іншим, у цей момент утиліта Rendom заморожує ваш ліс Active Directory від внесення змін до його конфігурації. Процес виконання цієї команди видно нижче:
Рис. 5. Виконання команди rendom/upload
Наступна команда виконується для перевірки готовності контролерів домену перед операцією перейменування домену. Під час виконання цього етапу ви повинні запустити команду підготовчої перевірки кожному контролері домену в лісі. Це необхідно для того, щоб бути впевненим, що база даних Active Directory на кожному контролері домену в лісі знаходиться в правильному стані і готова виконати зміни, які дозволять перейменувати ваш домен. Отже, виконайте команду rendom /prepare», як це зроблено на наступній ілюстрації:
Рис. 6. Підготовка домену до перейменування
Найвідповідальніший момент. Виконання команди « rendom /execute». Під час виконання цієї команди на домені виконуються інструкції щодо перейменування домену. По суті, в цей момент виконується звернення до кожного контролера домену в лісі індивідуально, що змушує кожен контролер домену виконувати інструкції з перейменування домену. Після виконання цієї операції кожен контролер домену буде перезавантажено. Процес виконання перейменування домену дивіться на наступній ілюстрації:
Рис. 7. Процес перейменування домену
Але це ще не все. Незважаючи на те, що ваш домен, по суті, вже перейменований, ви ще маєте завдання з виправлення об'єктів групової політики та їх посилань після завершення операції перейменування домену. Для відновлення об'єктів групової політики, а також посилань GPO у кожному перейменованому домені використовується утиліта командного рядка Gpfixup.exe. Не можна нехтувати цією процедурою через те, що без її використання, після завершення операції перейменування домену в новому лісі, групові політики просто не правильно функціонуватиму. Зверніть увагу, що ця команда має бути запущена один раз у кожному перейменованому домені. Отже, один раз виконайте команду gpfixupз параметрами /olddns:Biopharmaceutic.local(старе ім'я перейменованого вами домену) та /newdns:Biopharm.local(нове ім'я перейменованого домену), а потім команду gpfixupз параметрами /oldnb:Biopharmaceuticі /newnb:Biopharm(відповідно, старе та нове NETBIOS-ім'я вашого домену). Ця процедура видно нижче:
Рис. 8. Виправлення об'єктів групової політики
Залишилося виконати лише дві команди: команду rendom/clean», яка дозволяє видалити всі посилання на старі імена домену всередині вашої Active Directory, а також команду « rendom/end», що, по суті, розморожує ліс Active Directory від внесення змін до його конфігурації. Процес виконання цих команд можна побачити на наступній ілюстрації:
Рис. 9. Завершення перейменування домену Active Directory
Щоб зміни застосовувалися на рядові сервери та кінцевих клієнтів, вам доведеться двічі перезавантажити їх комп'ютери. Однак контролери домену вам доведеться перейменувати вручну. Як видно з наступної ілюстрації, ім'я мого контролера домену залишилося старим.
Що таке контролер домену
Контролер домену забезпечує централізоване управління мережевими пристроями, тобто доменами. У контролері зберігається вся інформація з облікових записів та параметрів користувачів мережі. Це параметри безпеки, локальної політики та багато інших. Це, свого роду, сервер, який повністю контролює певну мережу чи мережеву групу. Контролер домену - це свого роду набір спеціального програмного забезпечення, яке здійснює запуск різних служб Active Directory. Контролери працюють під керуванням певних операційних систем, таких як Windows Server 2003. Майстер установки Active Drive дозволяє створювати контролери доменів.
В операційній системі Windows NT як основний сервер використовується основний контролер домену. Інші сервери використовуються як резервні контролери. Основні контролери PDС можуть вирішувати різні завдання, пов'язані з членством користувачів у групах, створення та зміна паролів, додавання користувачів та багато інших. Після цього дані передаються на додаткові контролери BDC.
Як контролер домену може використовуватися програмне забезпечення Samba 4, якщо встановлена операційна система Unix. Це ПЗ також підтримує інші операційні системи, такі як windows 2003, 2008, 2003 R2 і 2008 R2. Кожна з операційних систем може розширюватися в залежності від конкретних вимог і параметрів.
Застосування контролерів домену
Використовуються контролери доменів багатьма організаціями, в яких розташовані комп'ютери, підключені між собою та мережу. У контролерах зберігаються дані каталогів та здійснюється контроль входу та виходу користувачів у систему, а також управління взаємодією між ними.
Організаціям, які використовують контролер домену, необхідно вирішити те, скільки їх буде використовуватися, розпланувати архівування даних, фізичну безпеку, оновлення сервера та інші необхідні завдання.
Якщо компанія або організація невелика і в ній використовується лише одна доменна мережа, достатньо використовувати два контролери, які здатні забезпечити високу стабільність, відмовостійкість і високий рівень доступності мережі. У мережах, які поділяються на певну кількість сайтів, на кожному з них встановлюється по одному контролеру, що дозволяє досягти необхідної працездатності та надійності. Завдяки використанню контролерів на кожному сайті, можна значно спростити вхід користувачів до системи та зробити його швидшим.
Мережевий трафік можна оптимізувати, щоб це зробити, необхідно встановити час оновлення реплікації тоді, коли навантаження на мережу буде мінімальним. Налаштування реплікації дозволить значно спростити роботу та зробити її продуктивнішою.
Досягти максимальної продуктивності в роботі контролера можна в тому випадку, якщо домен буде глобальним каталогом, що дозволить запитувати будь-які об'єкти за конкретною вагою. При цьому важливо пам'ятати, що включення глобального каталогу спричиняє значне збільшення трафіку реплікації.
Контролер домену господаря краще не включати, якщо використовується більше одного контролера домену. При використанні контролера домену дуже важливо дбати про безпеку, тому що він стає достатньо доступним для зловмисників, які бажають заволодіти необхідними для обману даними.
Особливості встановлення додаткових контролерів домену
Для того, щоб досягти більш високої надійності в роботі необхідних мережевих служб, необхідне встановлення додаткових контролерів домену. В результаті, можна досягти значно більш високої стабільності, надійності та безпеки в роботі. Швидкодія мережі в такому разі стане значно вищою, що є дуже важливим параметром для організацій, які використовують контролер домену.
Щоб контролер домену працював правильно, необхідно зробити деякі підготовчі роботи. Перше, що потрібно зробити, це перевірити параметри TCP/IP, вони мають бути правильно встановлені для сервера. Найважливіше перевірити DNS імена на зіставлення.
Для безпечної роботи контролера домену необхідно використовувати файлову систему NTFS, що забезпечує більш високу безпеку в порівнянні з файловими системами FAT 32. Для встановлення на сервері потрібно створити один розділ у файловій системі NTFS, на якому буде знаходитись системний том. Також обов'язково потрібен доступ до сервера DNS з сервера. Служба DNS встановлюється на цьому або додатковому сервері, який має підтримувати ресурсні записи.
Для того, щоб правильно настроїти контролер домену, можна використовувати Майстер налаштувань, за допомогою якого можна додавати виконання певних ролей. Для цього потрібно буде зайти до розділу адміністрування через панель керування. Як роль сервера необхідно вказати контролер домену.
Контролер доменів на сьогоднішній день є незамінним для мереж та сайтів, якими користуються різні організації, установи та компанії у всіх сферах діяльності. Завдяки йому забезпечується висока продуктивність у роботі та безпека, яка в комп'ютерних мережах має особливе значення. Роль контролера домену дуже важлива, оскільки дозволяє здійснювати управління областями домену, побудованими на комп'ютерних мережах. У кожній операційній системі є певні нюанси, пов'язані з роботою контролерів домену, але принцип і його призначення скрізь однакове, тому розібратися з налаштуваннями не так складно, як здається на початку. Тим не менш, дуже важливо, щоб налаштуванням контролерів домену займалися фахівці, щоб зрештою отримати високу продуктивність та безпеку під час роботи.
