Планування та розгортання служби доступу до інформаційних ресурсів підприємства

РЕФЕРАТ Пояснювальна записка до курсової роботи містить 31 сторінку; 15 рисунків; 2 таблиці; 25 посилання.

Мета роботи — обґрунтувати розгортання «ActiveDirectory» в компанії «ANTLERS&HOOFS», як на поточний момент, так і з урахуванням входження в транснаціональний холдинг

Об'єкт дослідження — «ActiveDirectory» на прикладi"Windows Server 2008″.

Предмет дослідження — налаштування «ActiveDirectory».

У роботі проводиться аналіз питань, пов’язаних з розгортанням «ActiveDirectory» в компанії «ANTLERS&HOOFS». Опираючись на проаналізованій та обраній моделі інфраструктури, а також на вимогах до групах безпеки, реалізується модель доступу до інформаційних ресурсів компанії на віртуальній машині.

ACTIVE DIRECTORY, ДОМЕН, ЛIС, WINDOWS SERVER, КОНТРОЛЕР ДОМЕНУ, RAID, САЙТ, ЗВ’ЯЗКИ САЙТІВ, GPO, PSO, ADSI, ГРУПИ БЕЗПЕКИ, СЕРВЕР, СЕРВЕР-ПЛАЦДАРМ.

ПЕРЕЛІК СКОРОЧЕНЬ, УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, ОДИНИЦЬ І ТЕРМІНІВ

інформаційний ресурс доменний дані

AD — ActiveDirectory

ADDSActive Directory Domain Services

DNS — Domain Name System

WANWideAreaNetwork

IP — Internet Protocol

RAIDRedundantArrayofIndependentDisks

SIDSecurityIdentifier

ACL — Access ControlList

ADSIActiveDirectoryServiceInterfaces

PSOPasswordSettingsObject

PSC — PasswordSettingsContainer

SMTPSimpleMailTransferProtocol

ISTG — Inter-Site TopologyGenerator

ВСТУП З кожним роком для територіально-розподілених компаній все гостріше стає питання вибору координаційної технології, що дозволяє швидко і зі збереженням необхідного рівня безпеки здійснювати обмін інформацією між центральним офісом і філіями.

«ActiveDirectory» один із механізмів здійснення координаційних дій шляхом централізації управління і поділу ресурсів."ActiveDirectory" дозволяє адміністраторам використовувати групові політики для забезпечення однаковості налаштування користувацької робочого середовища, розгортати програмне забезпечення на різних комп’ютерах через групові політики. Дана служба каталогів зберігає дані і налаштування середовища в централізованій базі даних, а для аутентифікації користувачів використовується протокол «Kerberos».

У ході виконання даної роботи будуть розглянуті питання визначення необхідного кількість лісів для організації, порядку їх розбиття на домени, планування доменного простору імен організації та структури доменів, визначені механізми поділу ресурсів компанії з організаційних підрозділам, а також вироблено тестове розгортання розробленої моделі каталогу «ActiveDirectory» на базі серверної операційної системи «Windows Server 2008R2» стосовно до центрального офісу компанії.

РОЗГОРТАННЯ ACTIVE DIRECTORY В КОМПАНІЇ «ANTLERS&HOOFS»

Вибір концепції лісу для компанії «ANTLERS&HOOFS»

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

Модель єдиного лісу є найпростішою моделлю лісу і вважається низькорівневою, оскільки всі об'єкти каталогу належать одному лісу і всі мережеві ресурси контролює одна централізована ІТ-група. Такий проект вимагає мінімальних адміністративних витрат і вважається найбільш рентабельним серед усіх моделей. Модель єдиного лісу є вдалим вибором для малих і середніх організацій, де діє лише одна ІТ-група і всі її філії управляються цією групою з центрального офісу. Відрізняються три схеми побудови лісу[2]:

— єдиний ліс, кожен регіон — окреме дерево;

— єдиний ліс, кожен регіон — домен;

— єдиний ліс, кожен регіон є дочірнім доменом центрального домену.

У деяких випадках, модель побудови єдиного лісу не здатна задовольнити всіх запропонованих в організації вимог і необхідно використовувати схему побудови декількох лісів.

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

Для кожного лісу використовуються окремі контейнери конфігурації. Зміни в топології необхідно реплікувати в інші ліси. Будь-яку реплікацію інформації між лісами доводиться налаштовувати вручну.

У відповідність з даними завдання компанія «ANTLERS&HOOFS» здійснює свою діяльність на території України і має деревоподібну топологію об'єднуюча центральний офіс, що знаходиться у м Києві, з регіональними центрами: західний (Львів), східний (Харків), центральний (Чернігів), південний (Одеса), а регіональні центри — з обласними підрозділами. При цьому у відповідність з основними завданнями центрального підрозділу компанії головний офіс повинен забезпечувати і організовувати виробничу діяльність компанії, вести фінансово-комерційну діяльність і координувати та організовувати роботи регіональних центрів. Очевидно, що для виконання даних цільових завдань, структурна схема каталогу «ActiveDirectory» повинна надавати можливості централізованого управління всією діяльністю компанії, включаючи віддалені філії. Крім того, комерційна компанія «ANTLERS&HOOFS» має єдиний центр управління, а регіональні центри є підзвітними центральному офісу організації і не потребують адміністративної автономії або ізоляції. На основі аналізу наведених моделей побудови лісу для розглянутої компанії «ANTLERS&HOOFS» найбільш доцільною представляється модель єдиного лісу, в якому кожен регіон є дочірнім доменом центрального домену.

Порядок поділу лісів на домени та планування доменів Процес планування доменів[4], як і при плануванні лісу, починається так само з аналізу компанії і формулювання вимог доцільності побудови плану доменів.

Домен — єдина область, в межах якої забезпечується безпека даних в комп’ютерній мережі[2]. Це найважливіша частина в ієрархічній структурі корпоративної мережі. Їй підпорядковані абсолютно всі інші структурні одиниці, такі як сервери, додатки, призначені для користувача пристрої і навіть мережні принтери.

Найпростіша модель «ActiveDirectory» — єдиний домен[2]. У моделі з єдиним доменом всі об'єкти знаходяться в одній зоні безпеки, тому не доводиться займатися плануванням довірчих відносин з іншими доменами. Крім того, при використанні єдиного домену простіше забезпечити централізоване управління мережею. Модель з єдиним доменом спрощує управління користувачами і групами, а також реалізацію групових політик. Стає легше виконувати операції з управління мережею.

Хоча модель єдиного домену дає суттєву перевагу — простоту, іноді доводиться використовувати декілька доменів. Використання багатодоменної структури лісу є кращим у тих випадках, якщо:

1) Трафік реплікації повинен бути обмеженим.

2) Між офісами компанії існують повільні мережеві підключення або в офісах є багато користувачів.

3) Необхідність мати різну політику паролів, політику блокування облікових записів і політику квитків «Kerberos».

4) Необхідно обмежувати доступ до ресурсів і мати адміністративні дозволу.

Важливі характеристики домену яких слід враховувати при проектуванні і розгортанню «ActiveDirectory»:

Кордон реплікації[4]. У межах домену реплікується каталог домену, який хнаходиться в папці «Sysvol». Дані зберігаються в «Sysvol» це загальнодоступні файли, реплицируемой між усіма контролерами даного домена. Зокрема в ньому зберігаються сценарії реєстрації та деякі об'єкти групової політики.

Кордон доступу до ресурсів[4]. Саме кордону домену визначають межі доступу до ресурсів мережі. Межі домену є навіть межами для доступу до ресурсів. За замовчуванням користувачі одного домену не можуть звертатися до ресурсів, розташованим в іншому домені, якщо тільки їм не будуть явно дано відповідні дозволи.

Кордон політики безпеки[4]. Ці політики, такі як політика паролів, політика блокування облікових записів і політика квитків Kerberos, застосовуються до всіх облікових записів домену. Ці політики можуть бути змінні на трьох рівнях, а саме:

на рівні домену;

на рівні сайту;

на рівні підрозділів.

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

Оскільки виробничо-комерційна компанія «ANTLERS&HOOFS» має територіально-розподілену організаційну структуру кращою моделлю розбиття лісу представляється проектування декількох доменів у відповідність з територіальним ознакою.

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

Порядок призначення доменних імен Наступним етапом планування розгортання служби каталогів є проектування інфраструктури «DNS"[4].

Доменне ім'я — символьне ім'я[4], що служить для ідентифікації областей — одиниць адміністративної автономії в мережі Інтернет — у складі вищестоящої по ієрархії такої області.

«ActiveDirectory» підтримує кілька типів імен:

складені імена;

відносні складові імена;

основні імена користувачів;

канонічні імена.

Доменне ім'я складається з символьних полів, розділених крапками. Крайнє праве поле позначає домен верхнього рівня, далі, справа наліво, слідують піддомени в порядку ієрархічної вкладеності, крайнє ліве поле позначає ім'я хосту.

Однак, оскільки в службі «ActiveDirectory» всі домени мають DNS-імена, перш ніж використовувати дану службу в мережі, необхідно спланувати простір імен «DNS». Ключове рішення проекту полягає в тому, щоб визначити, де розташувати домени «ActiveDirectory» в межах цього простору імен. Проектування інфраструктури «DNS» складається з декількох етапів.

При налаштуванні DNS-серверів спочатку обирається і реєструється унікальне батьківське ім'я «DNS», яке буде представляти організацію в Інтернеті. Це ім'я є доменом другого рівня всередині одного з доменів верхнього рівня, використовуваних в Інтернеті. Батьківське ім'я «DNS» можна з'єднати з ім'ям розташування або підрозділи всередині організації для формування інших імен доменів наступних рівнів.

Для впровадження «ActiveDirectory» існують два види просторів імен (внутрішній та зовнішній), при цьому простір імен ActiveDirectory збігається із заданим зареєстрованим простором імен DNS або відрізняється від нього.

Внутрішній і зовнішній простори імен бувають наступних типів:

Співпадаючі внутрішній і зовнішній простори імен. Згідно з цим сценарієм, організація використовує одне і те ж ім'я для внутрішнього і зовнішнього просторів імен — ім'я компанії застосовується як всередині, так і поза організацією. При реалізації цього сценарію користувачі внутрішньої приватної мережі компанії повинні мати доступ як до внутрішніх, так і до зовнішніх серверів. Для захисту конфіденційної інформації клієнти, що здійснюють доступ зовні, не повинні мати доступ до внутрішніх ресурсів компанії або мати можливість вирішувати свої імена. Крім того, необхідні дві роздільні зони DNS, одна з яких, за межами брандмауера, забезпечує дозвіл імен для загальнодоступних ресурсів. Вона не налаштована для дозволу імен внутрішніх ресурсів, тому доступ до них ззовні отримати не можна.

Відмінні внутрішній і зовнішній простори імен. У цьому випадку компанія використовує різні внутрішнє і зовнішнє простору імен — спочатку в зонах по різні сторони брандмауера імена різняться. Для цього необхідно зареєструвати два простори імен в DNS Інтернету. Якщо ім'я не зарезервовано, внутрішні клієнти не зможуть відрізнити внутрішнє ім'я від імені, зареєстрованого в загальнодоступній мережі простору імен DNS. Таким чином, встановлюються дві зони: один відповідає за дозвіл імен у зовнішньому просторі, інша — у внутрішньому. Користувачам не складе труднощів розрізняти внутрішні і зовнішні ресурси.

Для розглянутої в даній роботі виробничої компанії «ANTLERS&HOOFS», основним завданням якої є здійснення виробничо-комерційної діяльності на території України, що автоматично передбачає надання авторизованим клієнтам доступу до певних виділеним ресурсів компанії було вирішенообрати модель співпадаючих внутрішнього і зовнішнього простору імен. Вибір даної моделі передбачається економічно більш доцільним, оскільки не вимагає додаткових витрат на реєстрацію іншого простору імен.

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

Облікові записи користувачів дозволяють ідентифікувати користувачів, що входять в мережу, задавати, до яких ресурсів вони вправі звертатися, і вказувати про них всіляку інформацію. Адміністратори також є користувачами, але з більш широкими правами доступу до ресурсів, пов’язаних з управлінням мережею. Облікові записи користувачів надають користувачам можливість входити в домен або на локальний комп’ютер і звертатися до ресурсів. Об'єкти облікових записів користувачів містять інформацію про користувачів і пов’язують з ними певні привілеї чи обмеження. Кожен об'єкт «ActiveDirectory» пов’язаний зі списком управління доступом, який являє собою список дозволів на доступ до об'єкта, заданих для користувачів і груп.

Ретельне планування схеми іменування облікових записів користувачів дозволяє стандартизувати ідентифікацію користувачів домену. Єдина угода також полегшує розпізнавання і запам’ятовування імен користувачів.

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

При плануванні стратегії аутентифікації з метою виключення вразливостей мережі, пов’язаних з політикою управління обліковими записами користувачів, необхідно дотримуватися ряд нижчевикладених правил:

політика блокування облікових записів;

обмеження часу, в який дозволено вхід;

політика закінчення термінів квитків;

не використовувати адміністративні облікові записи для звичайної роботи.

перейменувати або відключити вбудовані облікові записи.

Ще одним найважливішим аспектом, на якому будується мережева безпека є паролі, оскільки при аутентифікації користувач засвідчує свою особистість введенням свого логіна і пароля. У зв’язку з цим політику визначення паролів користувачів необхідно ретельно продумати і жорстко регламентувати, програмно обмеживши пересічному користувачеві будь-які можливості невідповідності пропонованим політикою паролів вимогам.

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

Конфігурація сайтів Сайт — це група контролерів домену, які розташовані в одній або декількох IP-підмереж, пов’язаних швидким і надійним мережевим з'єднанням[6]. Оскільки сайти засновані на IP-підмережах, вони зазвичай відповідають топології мережі, а значить відповідають і географічній структурі компанії. Сайти з'єднуються з іншими сайтами WAN-каналами. Якщо домени «ActiveDirectory» — основні елементи логічної структури Служби каталогів, то сайти є елементами фізичної структури.

Таким чином, структура сайту пов’язана з фізичним середовищем і підтримується окремо від логічної середовища і структури домену, дозволяючи відокремити логічну організацію структури каталогів від фізичної структури мережі. Варто відзначити, що оскільки сайти не залежать від структури доменів, в один домен може входити кілька сайтів, або, навпаки, один сайт може містити декілька доменів або частин кількох доменів. Сайти містять об'єкти тільки двох типів: контролери доменів, що входять в сайт, і зв’язку сайтів, настроюються для з'єднання з іншими сайтами. В цілому сайти служать для управління трафіком по WAN-каналах. Основне завдання сайту — забезпечувати гарне мережеве з'єднання.

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

Як тільки інформація про мережу компанії зібрана, можна приступати до проектування сайту. Після визначення кількості сайтів для «ActiveDirectory» здійснюється проектування кожного сайту. Кожен сайт в «ActiveDirectory» пов’язаний з однією або більше підмережами IP, тому потрібно визначити, які підмережі будуть включені в кожен сайт.

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

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

2) DNS-сервер також буде розташовуватися в кожному філіалі.

3) Оскільки всі домени планованого лісу працюватимуть на функціональному рівні «Windows 2008» від розміщення сервера глобального каталогу в кожному філіалі прийнято рішення відмовитися.

4) Сервери господарів операцій, що діють в межах лісу, пропонується встановити в центральному офісі компанії, відповідному центральному домену.

Далі буде здійснена настройка атрибутів зв’язків сайтів для даного підприємства на основі схеми зв’язків сайтів, що зображено на рис. 1.1.

Рисунок 1.1 — Схема зв’язків сайтів Вартість зв’язків, графік реплікації та інтервал реплікації для зв’язків сайтів зазначені в таблиці 1.1.

Таблиця 1.1 — Переваги використання одного і кількох доменів

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

Розробка системи зберігання даних на підприємстві

Невід'ємною частиною централізованої системи зберігання даних є технологія «RAID"[8] - це використання наборів (два і більше) жорстких дисків, доступних операційній системі як один том. На «RAID» покладається завдання забезпечення відмовостійкості і підвищення продуктивності. Відмовостійкість досягається за рахунок надмірності. Тобто частину ємності дискового простору відводиться для службових цілей, стаючи недоступною для користувача. Різні типи RAID-масивів мають різні типи доступу, які прийнято характеризувати рівнями «RAID».

Для центрального офісу, регіональних центрів та обласних підрозділів компанії «ANTLERS & HOOFS» було вирішено використовувати «RAID-5"[8]. Модель збереження даних з використанням «RAID-5» зазначено на рис. 1.1.

Рисунок1.1 — Модель збереження даних з використанням «RAID-5»

«RAID-5» — дисковий масив з чергуванням даних і обчисленням контрольних сум для записуваних даних. Масиви «RAID-5» орієнтовані на напружену роботу з дисками і добре підходять для багатокористувацьких систем. Основною перевагою даної технології є висока швидкість читання і запису даних, високий коефіцієнт використання дискового простору. До недоліків можна віднести високий вплив, який чиниться на продуктивність, виходу з ладу одного з дисків.

ГРУПИ БЕЗПЕКИ НА ПІДПРИЄМСТВІ

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

Групи безпеки — відносяться до принципалів безпеки з SID-ідентифікаторами[3]. У зв’язку з цим даний тип групи вважається найпоширенішим і групи такого типу можна використовувати для управління безпекою та призначення дозволів доступу до мережевих ресурсів в списках «ACL"[3]. У свою чергу, група поширення спочатку використовується додатками електронної пошти, і вона не може бути принципалом безпеки.

У «ActiveDirectory» існує три області дії груп[3]:

локальна група в доменіпризначена для управління дозволами доступу до ресурсів. Локальну групу в домені можна додавати в списки «ACL» будь-якого ресурсу на будь-якому звичайному комп’ютері домену. У локальну групу в домені можуть входити користувачі, комп’ютери, глобальні та локальні групи в поточному домені, будь-якому іншому домені лісу, а також універсальні групи в будь-якому домені лісу. У зв’язку з цим, локальні групи в домені зазвичай використовують для надання правил доступу у всьому домені, а також для членів довірчих доменів.

глобальна група — основною метою даної групи безпеки є визначення колекції об'єктів доменів на підставі бізнес-правил і управління об'єктами, які вимагають щоденного використання. Глобальна група може містити користувачів, комп’ютери та інші глобальні групи тільки з одного домену. Незважаючи на це, глобальні групи можуть бути членами будь-яких універсальних і локальних груп як у своєму домені, так і недовірливому домені. Крім цього, глобальні групи можна додавати в списки «ACL» в домені, лісі і в недовірливому домені, що робить управління групами більш простим і раціональним.

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

Групи безпеки спрощують надання дозволів користувачам, оскільки встановити дозволи групі і додати користувачів в цю групу набагато простіше, ніж окремо призначати дозволу численним користувачам і управляти цими дозволами, а коли користувачі входять в групу, для зміни того чи іншого дозволу всіх цих користувачів достатньо однієї операції. У зв’язку з цим для управління дозволами доступу до ресурсів виробничої компанії «ANTLERS&HOOFS» прийняті наступні рішення:

1) Оскільки верховний адміністративний менеджмент підприємства повинен мати необмежений доступ до інформаційних ресурсів підприємства від президента до начальників регіональних центрів компанії, до групи безпеки, до якої повинні входити облікові записи цих користувачів пред’являються наступні вимоги:

призначені дозволи повинні діяти при спробі доступу до ресурсів декількох доменів;

група повинна існувати поза меж доменів;

в групу можуть входити користувачів і інші групи в межах лісу.

Цим вимогам повною мірою відповідає універсальні група безпеки, у зв’язку з чим, для верховного адміністративного менеджменту підприємства пропонується створити в центральному домені універсальну групу «Президенти».

2) Оскільки вимоги до безпеки, а також дозволу доступу до ресурсів компанії для керівників відділів відрізняються від дозволів надаються верховному адміністративного менеджменту, але в той же час їм передбачається дозволений доступ до ряду конфіденційних даних, що функціонує в компанії для них пропонується створити окрему глобальну групу безпеки «Керівники відділів». Облікові записи користувачів, яким також дозволений доступ до конфіденційної інформації підприємства, які є співробітниками відділу інформаційної безпеки, також пропонується додати до групи, оскільки вони мають той же рівень доступу і, як наслідок до них висуваються ідентичні вимоги політики безпеки компанії .

3) Оскільки рядовий персонал центрального офісу і підрозділів не потрібно доступ до ресурсів компанії поза межами їх домена, для них пропонується створювати локальну групу безпеки «Робітники».

МОДЕЛЬ ДОСТУПУ ДО ІНФОРМАЦІЙНИХ РЕСУРСІВ КОМПАНІЇ

Для розгортання лісу і домену у відповідність із спланованою раніше структурою був запущений «Майстер установки доменних служб ActiveDirectory». Далі був створений новий домен в лісі, як ім'я кореневого домену лісу було вирішено використовувати «Glevsky.com». Як функціональний рівень було вирішено використовувати «Windows Server 2008», що означає, що всі домени в лісі будуть працювати на рівні Windows Server 2008. На сторінці «Розташування для бази даних, файлів журналу і папки «SYSVOL» дані були прийняті задані за замовчуванням. Далі був заданий пароль для запуску доменних служб «ActiveDirectory» в режимі відновлення служб каталогів для завдань, що виконуються в автономному режимі. Потім був запущений процес налаштування «AD DS», зображений на рис. 3.1, по закінченні якого необхідно перезавантажити сервер.

Рисунок3.1 — Процес налаштування «AD DS»

Як видно з рис. 3.2, після розгортання домену була перенесена організаційно-штатна структура компанії на прикладі головного офісу в Києві.

Рисунок3.2 — Організаційно-штатна структура центрального офісу підприємства Потім у кожному із сформованих підрозділів було створено по 3 робітника і по одному керівнику, що відносяться до різних груп безпеки.

Далі в організаційному підрозділі «Users» були створені групи безпеки у відповідності з обраними раніше вимогами. Для того щоб створити обліковий запис об'єкта групи було відкрите оснащення «ActiveDirectory користувачі і комп’ютери». Потім після запуски команди для створення групи з’явиться нове вікно з заголовком «Новий об'єкт — група».

Рисунок3.3 — Створення нового облікового запису групи У вікні в полі «Ім'я групи» було введено ім'я групи «Директор». Потім для даної групи був обраний тип «Група безпеки» і область дії «Універсальна». Після цього створений обліковий запис об'єкта група з’явиться в обраному раніше підрозділі «Users».

Аналогічним чином в тому ж підрозділі були створені групи безпеки «Керівники Підрозділів» (Глобальна) і «Робітники» (Локальна).

Далі в групи в якості членів були додані облікові записи користувачів, створені раніше. Для цього в оснащенні «ActiveDirectory користувачі і комп’ютери» були відкриті властивості облікового запису в підрозділі «Директор підрозділу». У вікні «Властивості: Артем Глевський» була відкрита вкладка «Член груп». Варто зазначити, що обраний обліковий запис вже входить до групи «Користувачі домену». Після натискання кнопки «Додати» відкриється нове діалогове вікно «Вибір групи», в якому було введено ім'я «Директор». Після цього користувач «Артем Глевський» став членом групи «Директор».

Далі у властивостях груп «Керівники Підрозділів» і «Робітники» на вкладці «Члени групи» після натискання кнопки «Додати» відкрилося нове діалогове вікно через яке були додані нові члени вищезазначених груп. Членство в різних підрозділах зображено на рис. 3.4.

Рисунок3.4 — Члени груп Потім для кожної з груп були сконфігуровані індивідуальні політики безпеки. У «Windows Server 2008» політику паролів і блокування в домені можна замінити новою гранульованої політикою паролів і блокування, яку називають просто гранульованою політикою паролів. Цю політику можна застосовувати до однієї або декількох груп користувачів в домені.

Для створення об'єкта «PSO"[3], що застосовує сувору гранульовану політику паролів до членів груп «Керівники підрозділів» було відкрите оснащення «Редагування ADSI"[3], потім у вікні оснащення на вузлі «Редагування ADSI» правою кнопкою було викликано контекстне меню в якому була обрана команда «Підключення до». Після цього в новому вікні з заголовком «Параметри підключення», зображено на рис. 3.5, в полі «Ім'я» було введено ім'я домену -«Glevsky.com».

Рисунок3.5 — Вікно «Параметри підключення»

В оновленому вікні «Редагування ADSI» були послідовно розгорнуті папки «DC=Glevsky, DC=com, CN=System» і відкритий елемент «CN=PasswordSettingsContainer». Всі об'єкти «PSO» створюються і зберігаються в контейнері параметрів паролів «PSC», проте спочатку даний контейнер порожній.

У контейнері «PSC» клацанням правої кнопки миші було викликано контекстне меню, в якому була запущена команда створення нового об'єкту.

Після цього на екран було виведено нове діалогове вікно з заголовком «Створення об'єкта», в якому необхідно було вибрати тип створюваного об'єкта. Тут представлений тільки один тип: «msDS-Password Settings», який є технічним ім'ям класу об'єкта «PSO».

Потім були вказані значення для наступних обов’язкових атрибутів:

Загальне ім'я: «Керівники Підрозділів». Це назва політики.

Параметр msDS-PasswordSettingsPrecedence: «1». Параметр, який використовується в якості вартості або пріоритету. Чим вище пріоритет у налаштування пароля PSO, тим менше значення цього параметра.

Параметр msDS-PasswordReversibleEncryptionEnabled: «False». Цей параметр визначає можливість оборотного шифрування пароля для облікових записів користувачів.

Параметр msDS-PasswordHistoryLength: «25». Цей параметр визначає кількість неповторним паролів для облікових записів користувачів.

Параметр msDS-PasswordComplexityEnabled: «True». Встановлений параметр «True», визначає включення вимоги дотримання складності паролів і є рекомендованим.

Параметр msDS-MinimumPasswordLength: «12». Встановлений параметр «12» визначає мінімальну довжину паролів облікових записів користувачів.

Параметр msDS-MinimumPasswordAge: «1: 00: 00: 00». Встановлений параметр в 1: 00: 00: 00 (1 день), визначає мінімальний термін дії паролів облікових записів користувачів.

Параметр msDS-MaximumPasswordAge: «25: 00: 00: 00». Встановлений параметр в 25: 00: 00: 00 (25 днів), визначає максимальний термін дії паролів облікових записів користувачів.

Параметр insDS-LockoutThreshold: «5». Встановлений параметр в 5, визначає поріг блокування облікових записів користувачів (після 5 невдалих спроб авторизації спрацьовує механізм блокування облікового запису).

Параметр msDS-LockoutObsewationWindow: «0: 01: 00: 00». Встановлений параметр в 0: 01: 00: 00 (1:00), визначає період скидання лічильника блокувань облікових записів користувачів.

Параметр msDS-LockoutDuration: «1: 00: 00: 00». Встановлений параметр в 1: 00: 00: 00 (1 день), визначає тривалість блокування заблокованих облікових записів користувачів.

Потім, на сторінці атрибуту msDS-LockoutDuration, були відкорегувати додаткові атрибути. У вікні, в полі «Змінити атрибут» були введені такі дані:

Рисунок3.6- Налаштування додаткового атрибута Аналогічні дії були пророблені для груп «Робітники» і «Директор». Дані які були введені при налаштуванні нових «PSO» зазначені у таблиці 3.1.

Таблиця 3.1 — Переваги використання одного і кількох доменів

Рисунок 3.7 — Створені об'єкти PSO

Оскільки компанія «ANTLERS HOOFS» має кілька філіалів, кожен з яких має своє територіальне розташування необхідно встановити в кожному філіалі по контролеру домену. Необхідно забезпечити виконання двох завдань:

1) Кожен клієнт при аутентифікації повинен звертатися до найближчого контролеру домену для отримання квитків «Kerberos». При цьому і групові політики також повинні застосовуватися з найближчого контролера.

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

Щоб ці завдання виконувалися ефективно необхідно конфігурувати сайти, які, по суті, є логічним угрупованням клієнтів і контролерів, пов’язаних швидкісними з'єднаннями.

Коли встановлюється «ActiveDirectory», створюється єдиний сайт з ім'ям «Default-First-Site-Name» (надалі сайт можна перейменувати). Якщо не створюються додаткові сайти, то всі наступні контролери домену будуть додаватися до цього сайту. Однак, якщо компанія розташована в декількох місцях з обмеженою пропускною здатністю між ними, то необхідно створити додаткові сайти. Додаткові сайти створюються за допомогою інструменту адміністрування «ActiveDirectory — сайти і служби"[3].

Для створення нових сайтів, на контейнері «Sites» було викликано контекстне меню і обрана команда «Створити сайт». Після введення імені сайту був вибраний зв’язок сайту, який буде використовуватися для з'єднання цього сайту з іншими сайтами. Кожен сайт пов’язаний з однією або більше підмережами IP в «ActiveDirectory». Далі була створена додаткова підмережа в контейнері «Subnets» в інструменті «ActiveDirectory — сайти і служби» і пов’язана з новим сайтом. Все це зображено на рис. 3.8.

а) б) Рисунок 3.8 — а) Створення нового сайту; б) Створення нової підмережі

Кожен сайт повинен мати, принаймні, один контролер домену. Щоб перемістити існуючий контролер домену в сайт, потрібно клацнути правою кнопкою миші на об'єкті контролера домену в його поточному контейнері «Servers» і вибрати «Перемістити». Потім буде запропонований вибір сайту, в який можна перемістити контролер домену. Якщо встановлюється новий контролер домену, то він буде автоматично розташований в тому сайті, в якому підмережа IP відповідає IP-адресою контролера домену.

З'єднання «ActiveDirectory», які пов’язують сайти разом, називаються «зв'язками сайту». При установці «ActiveDirectory» створюється єдиний зв’язок сайту з ім'ям «DEFAULTIPSITELINK"[3]. Якщо не будуть створені ніякі додаткові зв’язки сайту перш, ніж будуть створені додаткові сайти, то кожен сайт включається в цю задану за замовчуванням зв’язок сайту.

а) б) Рисунок 3.9 — а) Створення зв’язку сайтів; б) Налаштування зв’язку Рисунок 3.10 — Налаштування розкладу реплікації

Нижче наведені опції конфігурації для всіх зв’язків сайту.

вартість — це призначене адміністратором значення, яке визначає відносну вартість зв’язку сайту. вартість зазвичай відображає швидкість мережної передачі і витрати, пов’язані з її використанням.

графік реплікації - визначає, в який час протягом дня зв’язок сайту доступний для реплікації.

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

Мости зв’язків сайту можуть використовуватися для конфігурування реплікації в ситуаціях, коли компанія має кілька сайтів, пов’язаних з високошвидкісною базової мережею, і кілька менших сайтів, які з'єднуються з кожним великим центром через повільні з'єднання. У цих випадках мости зв’язків сайту можна використовувати для більш ефективного управління потоком трафіку реплікації. Створення мостів зв’язків сайту зображено на рис. 3.11.

Рисунок 3.11 — Створення мосту зв’язків сайтів При створенні моста зв’язків необхідно визначити, який зв’язок сайту є частиною мосту. Будь-які зв’язки сайту, які додаються до мосту зв’язків сайту, розглядаються по відношенню один до одного як транзитивні; зв’язку сайту, не включені в міст зв’язків сайту, транзитивними не є.

Реплікація між сайтами виконується через сервери-плацдарми. За замовчуванням генератор міжсайтової топології (ISTG)[6] автоматично ідентифікує сервер-плацдарм при обчисленні топології реплікації між сайтами.

У деяких випадках необхідно управляти тим, які контролери домену будуть використовуватися в якості серверів-плацдармів. Робота сервера-плацдарму може додавати істотне навантаження на контролер домену, якщо є багато змін інформації каталогу і встановлено часте проведення реплікації. Для конфігурування серверів-плацдармів потрібно отримати доступ до об'єктів в інструменті адміністрування «ActiveDirectory — сайти і служби», клацнувши правою кнопкою миші на імені сервера, а потім вибрати «Властивості». Таким чином отриманий доступ до опції конфігурування сервера як привілейованого сервера-плацдарму для передачі даних по SMTP або по IP, зображено на рис. 3.12.

Рисунок 3.12 — Налаштування серверу-плацдарму Перевага конфігурування привілейованих серверів-плацдармів полягає в гарантії того, що серверами-плацдармами будуть обрані контролери домену, зазначені адміністратором. Якщо адміністратор захоче контролювати те, які сервери використовуються в якості серверів-плацдармів, то можна конфігурувати привілейований сервер-плацдарм для кожного розділу, який потрібно реплікувати в сайт.

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

Рисунок 3.13 — Структура сайтів компанії «ANTLERS&HOOFS»

Таким чином після виконаннявищезазначених дійбуловироблено тестове розгортання розробленої моделі каталогу «ActiveDirectory» на базі серверної операційної системи «Windows Server 2008 R2» стосовно до центрального офісу компанії.

ВИСНОВКИ У цій роботі, ґрунтуючись на базі теоретичних відомостей, а також аналізі існуючої інфраструктури та бізнес-процесів виробничої компанії «ANTLERS&HOOFS» була розроблена і запропонована до впровадження модель розгортання служби каталогів ActiveDirectory.

Для розглянутої в роботі організації була обрана модель єдиного лісу з центральним доменом і чотирма регіональними доменами, які є дочірніми по відношенню до центрального. Порядок призначення доменних імен ґрунтувався на територіальному ознакою, що дозволяє відобразити географічну структуру компанії, а також є стійкість до реорганізації. Для поділу ресурсів між організаційними підрозділами для центрального домену була обрана модель на основі структури організації, оскільки вона дозволяє забезпечувати певний рівень автономії для кожного відділу і спрощене адміністрування. Була вироблена власна стратегія управління обліковими записами і групами безпеки підприємства, а також розглянуті питання конфігурації сайтів. Також було вироблено тестове розгортання розробленої моделі каталогу ActiveDirectory на база серверної операційної системи Windows Server 2008 стосовно до центрального офісу компанії «ANTLERS&HOOFS».

ПЕРЕЛІК ПОСИЛАНЬ Добринін І.С. «Методичні вказівки за курсом ЗСТКС» [Текст]/ Х.: Електронна документація, 2015.

Ден Холме, Нельсон Рест, Даніель Рест, «Налаштування ActiveDirectory. Windows Server 2008» [Текст]/Пер. з англ. — М.: Видатництво «Русскаяредакция», 2011. — 960 с.: ил.

Тоні Нортроп, Дж. КМакін., «Проектування мережевої інфраструктури Windows Server 2008». [Текст]/Пер. з англ. — М.: Видатництво «Русская редакция», 2011. — 590 с.: ил.

«ActiveDirectory» [Електронний ресурс] http://alterego.ucoz.org/ - Режим доступу: URL: http://alterego.ucoz.org/publ/active_directory/4−2 — Загл. з екранах.

«ActiveDirectory» — сайти і служби [Електронний ресурс] http://winintro.ru/ - Режим доступу: URL: http://winintro.ru/dssite.ru/ - Загл. з екранах.