Підняття домену ms windows 2018 server, фотоостров
Перш за все, не втримаюся від лінгвістичної єхидно - налаштувати домен, або підняти домен? Все ж таки настройка і підняття - створення з нуля - домену далеко не одне й те саме. Налаштування - доведення до розуму вже існуючого домену з метою змусити його відповідати потребам користувачів. А ось підняття домену - заняття особливе. Можна сказати - ціла пригода в дусі дослідників незвіданих світів ...
Щоб зрозуміти, як підняти домен, слід - що цілком очевидно - уявляти собі, що таке домен, з чим його їдять (і їдять) і чи потрібен він взагалі. Це банальне міркування бачиться актуальним з тієї простої причини, що найчастіше доводиться стикатися з ситуаціями, коли людина хоче зробити щось, про що не має уявлення, але про що знає, що це - штука крута і модна. Я особисто одного разу чув твердження в дусі: «У нас же серйозна компанія! Нам просто необхідний домен! ». А тим часом в цій компанії, в серйозності якій я ні миті не сумніваюся, було всього десять комп'ютерів і завдання на них покладені максимально примітивні - друкарська машинка і Інтернет. Для такої мережі домен - однозначно п'яте колесо. Але що ж таке домен?
Шляхом прочитання розумних книг1 з'ясовується, що домен - це не самостійне поняття. Домен - є одне з основних засобів формування простору імен каталогу Active Directory. Поряд з доменами такими засобами формування є адміністративна ієрархія і фізична структура мережі. Причому всі три засоби можуть використовуватися як в самостійному вигляді, так і в комплексі. У вже згаданій розумній книжці Новомосковськ, що операційні системи Windows традиційно використовували поняття «домену» для логічного об'єднання комп'ютерів, спільно використовують єдину політику безпеки. І далі по тексту - домен традиційно виступає в якості основного способу створення областей адміністративної відповідальності.
Щоб рухатися далі незайвим, я вважаю, буде привести і якесь визначення тієї самої Active Directory, в рамках якої живе поняття «домену». Каталог (він же - Active Directory на чужоземному мовою) є глобальне уніфіковане сховище інформації про елементи мережевої інфраструктури. Елементами ж мережевої інфраструктури є користувачі, ресурси (загальні папки, принтери і т.п.), мережеві служби (поштові сервіси, веб-сервіси, сервіси бази даних і т.п.), комп'ютери та інше. Власне, призначення каталогу - дати користувачеві можливість використовувати всі ці елементи мережевої інфраструктури без необхідності знати точне розташування кожного елемента і вибудовувати політику взаємодії з цим елементом індивідуально.
А тепер переведемо це все на українську мову.
Отже маємо мережу. Локальну, зрозуміло, хоча Інтернет в цьому випадку мало чим відрізняється від локалки. У ній є купа користувачів, якісь мережеві папки (в різному ступені закриті для доступу), принтери, факси, сканери, комп'ютери (різні по призначенню). У цій мережі крутиться пара баз даних різного призначення. Користувачі цієї мережі гуляють по Всесвітній Павутині (знову ж таки, з різним ступенем обмежень). Ну і ще купа всякого різного, що сприяє плідній роботі користувачів мережі і їх же не менше плідній відпочинку. Цілком очевидно, що все це мережеве різноманітність має бути приведене до спільного знаменника. Хоча б для зручності управління цим мережевим господарством. Зрештою, уявіть собі необхідність тримати на контролі взаємні зв'язки всього перерахованого з усім перерахованим ж. Представили? Ось і в мене не вийшло.
Але такі взаємні зв'язки і такий спільний знаменник забезпечується саме за допомогою Active Directory (будемо для стислості надалі її позначати буквами АТ). Вся структура всіх взаємних зв'язків між елементами нашої мережі і взагалі вся мережева інфраструктура та ієрархія зберігається і обліковується саме в АТ. Перед тим, як користувач (або сервіс мережі) звернеться до якогось ресурсу мережі він довідається в АТ, як саме йому з цим ресурсом належить взаємодіяти.
Скільки і яких доменів нам треба?
Припустимо, ми переконалися, що АТ нам потрібна. Стало бути, необхідно її розгорнути і налаштувати. Ось тут-то і приходить черга домена.Дело в тому, що АТ не тільки містить в собі інформацію про всі елементи мережевої інфраструктури, а й описує ієрархію цієї структури. Ось з цієї ієрархією нам і треба визначитися. Зрештою, щоб впоратися з мережею з трьохсот комп'ютерів і мільйони мережевих служб, її треба розбити на якісь логічно завершені частини і впоратися з цими частинами. Divida et impera! 2 Таким чином, нам треба вирішити, як ми будемо ділити нашу мережу і чи будемо ми її ділити взагалі.
Припустимо, в нашій фірмі є п'ять відділів, які працюють в тісному контакті і містять не більше чотирьох співробітників на відділ. Керівництво, зрозуміло, вважаємо особняком. Мережеві папки, 1С, Exchange для документообігу і в якості поштового сервісу, пара загальних баз даних на SQL. АТ потрібна, але як її впорядкувати? Цілком очевидно, що в даному випадку ділити співробітників (і мережеві ресурси) на групи всередині АТ нелогічно - їх небагато і вони занадто тісно між собою контактують.
Другий варіант - та ж сама компанія, але два з п'яти відділів розташовані в окремому офісі на іншому кінці міста. Мобільний зв'язок - через Інтернет (а як ще?). Все інше - те ж саме. Тут вже складніше - потрібно якось зробити так, щоб і сама АТ була поділена на дві частини (по одній в кожному офісі), але об'єднана воєдино.
Третій варіант - тридцять відділів у великій фірмі, кожен з яких в значній мірі незалежний від інших. Цілком очевидно, що в даному випадку кожному відділу компанії повинна відповідати своя АТ, повністю описує його мережеву інфраструктуру. Разом з тим, всі ці АТ повинні об'єднуватися воєдино в рамках підприємства.
Дані три приклади кілька академічні, але добре описують класичні способи побудови АТ і створення доменів. Вище ми вже писали, що домен є лише засіб формування простору імен АТ - засіб упорядкування АТ. Як правило, домени створюються виходячи з адміністративної моделі підприємства, яке обслуговується нашою мережею, або ж за територіальною ознакою - виходячи з територіального упорядкування мережі. І що ж ми бачимо?
У першому варіанті фірма представляє собою єдине ціле як з точки зору адміністративної, так і територіально. Крім того, вона не така вже й велика. Для системного адміністратора це означає, що в ході розгортання АТ буде створено один єдиний домен, який обслуговує всю мережу фірми в цілому. Ніякого поділу в даному випадку не буде - воно не потрібно.
У другому варіанті фірма представляє в адміністративному баченні єдине ціле, але рознесена в просторі географічно. Має сенс розділити ЛВС цієї фірми за територіальною ознакою - за кількістю офісів. В цьому випадку в рамах розгортання артеріальний тиск піднімається не один єдиний домен, а ліс доменів. По-перше, свій домен у головного офісу. По-друге, свій домен у філії. Ну і, нарешті, корінь лісу - головний домен, якому будуть належати домени кожного з офісів. Відповідно, логічно буде розташувати корінь лісу і домен головного офісу в самому головному офісі, а домен філії - у філії (масло масляне, чесне слово!). Відповідно, домен головного офісу буде узгоджуватися з коренем лісу (його ще прийнято називати Глобальним Каталогом - ГК скорочено) по лініях ЛВС головного офісу, а домен філії - через Інтернет. Якщо ж Інтернет з різних причин пропаде, то домен філії продовжить нормально функціонувати і дочекається відновлення зв'язку для узгодження з ЦК (таке узгодження часто називають реплікацією). Якби у нас в даному випадку був не ліс, а окремий домен (а така схема теж можлива), то обрив Інтернету паралізував би начисто роботу філії, що не є добре.
І, нарешті, третій варіант. В цьому випадку територіально фірма єдина, але адміністративно - досить жорстко розділена. І з цього ж самому ознакою має сенс поділити ЛВС. Тоді в рамках розгортання АТ кожному відділу фірми піднімається свій домен і, для об'єднання їх усіх в ліс, створюється ГК. В такому випадку роботи системного адміністратора над сегментом одного відділу фірми ніяк не позначаться на працездатності всіх інших відділів. Навпаки, якби у нас тут був один самостійний домен, то падіння якого-небудь важливого сервера могло паралізувати роботу всього підприємства, що навряд чи прийнятно.
Зрозуміло, всі описані вище моделі можуть бути скомбіновані в залежності від структури конкретного підприємства і вам, як системного адміністратора, треба буде розв'язати, яку саме схему АД будувати і з яких частин вона складатиметься. Проте, практика показує, що найчастіше ЛВС дрібного і середнього бізнесу побудована за моделлю АД з одним самостійним доменом. І саме про цю модель ми і будемо говорити в подальшому.
Етапи установки контролера домена
1. Створення нового лісу доменів;
2. Створення нового дерева доменів в рамках існуючого лісу доменів;
3. Створення нового домену в рамках існуючого дерева доменів;
4. Установка додаткового контролера домену в уже існуючому домені.
Друга і третя схеми використовуються у випадках, коли мережа організаційно має більше одного домену. Як ми домовилися вище, ми розглядаємо випадок установки самого першого домену і, тому, друга і третя схеми нам не підходять. Четверта схема застосовується при установці резервного контролера домену та про неї ми тут говорити не будемо. Таким чином, на цій стадії підняття домену слід вибирати перший сценарій. При цьому словосполучення «ліс доменів» не повинно нікого лякати. Зрештою, будь-який ліс починається з одного - самого першого - дерева, і тільки від нас залежить, розростеться це дерево до лісу, або ж так і залишиться стояти на самоті.
Отже, вибираємо перший сценарій установки. Після цього майстер зажадає від нас ввести доменне ім'я і NetBIOS-ім'я майбутнього контролера домену. Що це за імена?
Далі слід NetBIOS-ім'я майбутнього контролера домену. Це - те саме ім'я, яке виводиться в мережевому оточенні. Простіше кажучи, це - ім'я комп'ютера. Як назвати свій КД - справа кожного адміна. Можна обізвати його PDC (Primary Domain Cotroller - Перший Контролер Домена). Я, наприклад, свого часу чув таку схему: домен назвати universe.local (universe - всесвіт). Кожному сервера в цьому домені присвоїти ім'я якої-небудь зірки. Обізвати, наприклад, КД ім'ям sun (Сонце). А кожну клієнтську машину назвати ім'ям планети або її супутника - наприклад, Pluto (Плутон). Тут немає ніяких чітких рекомендацій крім правил для NetBIOS-імен. Більш того, якщо не полінуватися і прикласти до імені комп'ютера його короткий опис (для цього передбачено окремий рядок при іменуванні комп'ютера ще на стадії установки ОС), то користувач, який увійшов в Мережеве Оточення, і без необхідності запам'ятовувати імена комп'ютерів легко і миттєво в ньому зорієнтується .
Зауважимо в дужках, що крім NetBIOS-імені комп'ютера є і його повне ім'я. Воно складається з NetBIOS-імені комп'ютера та імені домена, якому цей комп'ютер належить. Наприклад якщо КД домену universe.local називається pluto, то повне ім'я цього КД буде pluto.univere.local. Якщо ж комп'ютер pluto ніякому домену не належить, то його повне ім'я буде виглядати як pluto. (Саме так, з точкою на кінці).
Таким чином, будемо вважати, що доменне ім'я і ім'я майбутнього КД обрані і введені.
Наступний етап підняття домену полягає в тому, що майстер запропонує вибрати місце під файли сховища АТ і журналів, так само як і місце системного томи. Простіше кажучи, вам запропонують вибрати папки, в які буде встановлена АТ. Як правило, чи має сенс міняти запропоновані майстром умовчання, але якщо на майбутньому КД є кілька локальних томів, у вас може виникнути бажання вибрати найбільш підходящий з них для цієї мети. Власне, вимог тут кілька:
1. Місце АТ, журнали і системний том (SYSVOL) можуть розташовуватися виключно на томах, відформатованих в файлову систему NTFS.4
2. Має сенс розмістити сховище АТ, журнали і системний тому на самому захищеному і надійному жорсткому диску або RAID, якщо в комп'ютері міститься кілька фізичних дисків.
3. Абсолютно само собою зрозуміло, що ні сховище АТ, ні журнали, ні системний тому не можуть розташовуватися на мережевих дисках. Зрештою, мережеві диски самі є елементами мережевої інфраструктури і навряд чи можуть містити в собі початок всієї цієї інфраструктури.
Наступний етап - спілкування з DNS-сервером. У мережевих налаштуваннях вашого майбутнього КД повинен бути прописаний бажаний DNS-сервер. Маючи цю інформацію, майстер установки АТ здатний послати цього сервера запит і протестувати його на предмет придатності для розгортання АТ. До цього сервера будуть пред'явлені наступні вимоги:
1. Наявність в мережі (реальне наявність і працездатність).
2. Підтримка ресурсних записів SRV-типу.
3. Можливість динамічної реєстрації імен.
Якщо сервер задовольняє цим вимогам, він буде використаний при побудові АТ. Інакше майстер запропонує на вибір кілька варіантів:
· Повторне тестування DNS-сервера. Передбачається, що системний адміністратор зрозумів натяк, втрутився і виправив всі проблеми з існуючим DNS-сервером. Він готовий протестувати його ще раз, щоб переконатися в його придатності.
· Встановлювати чи налаштовувати нового DNS-сервера на даному комп'ютері. Найзручніший варіант - Windows не стане розбиратися з наявними серверами і створить собі новий, повністю задовольняє її вимогам і налаштований належним чином, поєднавши його з майбутнім КД.5
· Налагодження DNS-сервера після установки АТ. Передбачається, що системний адміністратор врахував наявність проблеми з DNS-сервером і виправить її по завершенні установки АТ.
При виникненні помилки я раджу скористатися другим варіантом. Ну а якщо помилки не виникло, то можна залишити все, як є, і використовувати існуючий DNS-сервер.
І, нарешті, заключний етап - визначення рівня дозволів для системи безпеки. У вашій мережі можуть бути присутніми інші сервера під керуванням Windows, так само як і сервера під керуванням інших ОС. Можливі два варіанти:
Зауважимо в дужках, що установка рівня сумісності дозволів має відношення тільки до серверів. Іншими словами, наявність в домені клієнтських станцій під керуванням як завгодно древніх версій будь-яких ОС на вибір рівня сумісності не впливає. І навпаки - вибір рівня сумісності не впливає на поведінку клієнтських станцій з будь-якими версіями ОС в домені.
Етап вибору рівня сумісності був останнім. Після його завершення буде потрібно перезавантажити систему. В процесі подальшого завантаження в базі DNS буде зареєстровано доменне ім'я і на нашому КД буде створена обліковий запис адміністратора домену. Точніше, не створена.
Установку АТ і підняття КД слід виробляти від імені локального адміністратора нашого сервера - це очевидно. І саме його обліковий запис буде перетворена в обліковий запис Administrator і включена в такі групи:
· Administrators. Вбудована локальна група.
· Domain Admins. Група АТ, члени якої мають право керувати доменом.
· Domain Users. Група АТ, членами якої є всі створювані користувачі домену.
· Enterprise Admins. Група АТ, члени якої мають право керувати інфраструктурою каталогу.
· Group Policy Creator Owners. Група АТ, які мають право редагувати параметри групових політик в межах даного домену.
· Schema Admins. Група АТ, члени якої мають право змінювати схему каталогу.
Відповідно, після закінчення цього етапу вам залишиться вписати в ваш домен все комп'ютери вашої ЛВС і створити облікові записи для користувачів вашої ЛВС. І домен готовий.
Зрозуміло, простий установкою КД системний адміністратор не відбудеться. Адже в кожної компанії є своя політика використання ЛВС, її ресурсів. Як мінімум, свій набір цих самих ресурсів і свої права користувачів на ці ресурси. Відповідно, в коло обов'язків адміністратора входить створення в домені груп користувачів, розподіл ресурсів по цих групах. Внесення цих ресурсів в АТ, адже той же мережевий принтер сам від себе в пошукові роботи не з'являлися пропишеться. Але все це - тема окремої розмови.
2 Розділяй і володарюй! (Лат.)
3 Зрозуміло, існують випадки, коли веб-сайт розташований на серверах корпоративної ЛВС. Але все ж набагато частіше веб-сайт компанії розташовується на платному зовнішньому хостингу і ніякого відношення до корпоративної ЛВС не має.
4 Строго кажучи, ця вимога може здатися надмірною, бо ж серверні версії Windows за замовчуванням форматують свої томи в NTFS. Проте, різні причини можуть привести до того, що на сервері з'являться томи з файловою системою FAT32. Таким чином, відстежити дана вимога все ж треба, тому що АТ не може бути інстальована в відмінну від NTFS файлову систему.
5 Я настійно рекомендую починати установку АТ, не маючи в мережі готового DNS-сервера або ж не займаючись конфигурированием наявного. Що б не говорили про твори Microsoft, але нехай вже краще Windows налаштує необхідний їй DNS-сервер з нуля і автоматично. Вона зробить це швидше і краще людини, та й з меншими витратами.