Адміністраторам Windows-мереж не уникнути знайомства з . Ця оглядова стаття буде присвячена тому, що таке Active Directory і з чим їх їдять.
Отже, Active Directory – це реалізація служби каталогів від компанії Microsoft. Під службою каталогів у даному випадкумається на увазі програмний комплекс, що допомагає системному адміністратору працювати з такими мережевими ресурсами, як спільні папки, сервери, робочі станції, принтери, користувачі та групи.
Active Directory має ієрархічну структуру, що складається з об'єктів. Усі об'єкти поділяються на три основні категорії.
- Облікові записи користувачів та комп'ютерів;
- ресурси (наприклад, принтери);
- Служби (наприклад, електронна пошта).
Кожен об'єкт має унікальне ім'я і має низку характеристик. Об'єкти можна групувати.
Властивості користувача Active Directory має лісоподібну структуру. Ліс має кілька дерев, які містять домени. Домени, у свою чергу, містять вищезазначені об'єкти.
Структура Active Directory Зазвичай об'єкти в домені групуються до підрозділів. Підрозділи служать для будівництва ієрархії всередині домену (організації, територіальні підрозділи, відділи і т.д.). Це особливо важливо для організацій, що розкидані за географічною ознакою. При вибудовуванні структуру рекомендується створювати якнайменше доменів, створюючи, за потреби, окремі підрозділи. Саме на них і є сенс застосовувати групові політики.
Властивості робочої станції Іншим способом структурування Active Directory є сайти. Сайти є способом фізичного, а чи не логічного угруповання з урахуванням сегментів мережі.
Як було зазначено, кожен об'єкт у Active Directory має унікальне ім'я. Наприклад, принтер HPLaserJet4350dtn, що знаходиться в підрозділі Юристиі в домені primer.ruматиме ім'я CN=HPLaserJet4350dtn,OU=Юристи,DC=primer,DC=ua. CN- це спільне ім'я, OU- підрозділ, DC- Клас об'єкта домену. Ім'я об'єкта може мати набагато більше частин, ніж у цьому прикладі.
Інша форма запису імені об'єкта виглядає так: primer.ru/Юристи/HPLaserJet4350dtn. Також кожен об'єкт має глобальний унікальний ідентифікатор ( GUID) - унікальний і незмінний 128-бітовий рядок, який використовується в Active Directory для пошуку та реплікації. Деякі об'єкти також мають ім'я користувача-учасника ( UPN) у форматі об'єкт@домен.
Ось загальні відомостіпро те, що ж таке Active Directory і для чого вони необхідні в локальних мережах на базі Windows. Насамкінець має сенс сказати, що адміністратор має можливість працювати з Active Directory віддалено за допомогою Засоби віддаленого адміністрування сервера для Windows 7 (KB958830)(завантажити) та Засоби віддаленого адміністрування сервера для Windows 8.1 (KB2693643) (завантажити).
Групова політика - це ієрархічна інфраструктура, яка дозволяє мережному адміністратору, що відповідає за Active Directory Microsoft, реалізовувати певні конфігурації для користувачів та комп'ютерів. Групова політика також може використовуватися для визначення політик користувача, безпеки та мережі на рівні машини.
Визначення
Групи Active Directory допомагають адміністраторам визначати параметри того, що користувачі можуть робити в мережі, включаючи файли, папки та програми, до яких вони отримають доступ. Колекції настройок користувача і комп'ютера називаються об'єктами групової політики, які адмініструються з центрального інтерфейсу, званого консоллю управління. Групова політика також може керуватися за допомогою командного рядка, таких як gpresult і gpupdate.
Служба Active Directory стала новинкою для Windows 2000 Server і була вдосконалена у версії 2003, що робить її ще більш важливою частиною ОС. Windows Server 2003 AD надає єдине посилання, яке називається службою каталогів для всіх об'єктів у мережі, включаючи користувачів, групи, комп'ютери, принтери, політики та дозволи.
Для користувача або адміністратора налаштування Active Directory надає єдиний ієрархічний вигляд, з якого можна керувати всіма ресурсами мережі.
Навіщо впроваджувати Active Directory
Існує безліч причин для впровадження цієї системи. Перш за все, Microsoft Active Directory зазвичай вважається значним покращенням порівняно з доменами Windows NT Server 4.0 або навіть автономними мережами серверів. AD має централізований механізм адміністрування по всій мережі. Він також забезпечує надмірність і стійкість до відмови при розгортанні в домені двох або більше контролерів домену.
Служба автоматично управляє обміном даними між контролерами домену, щоб мережа залишалася життєздатною. Користувачі отримують доступ до всіх ресурсів мережі, для яких вони авторизовані за допомогою єдиного входу. Всі ресурси в мережі захищені надійним механізмом безпеки, який перевіряє ідентифікацію користувачів та повноваження ресурсів на кожен доступ.
Навіть завдяки покращеній безпеці та контролю Active Directory більшість його функцій невидимі для кінцевих користувачів. У зв'язку з цим міграція користувачів до мережі AD вимагає невеликої перепідготовки. Служба пропонує засоби для швидкого просування та зниження рейтингу контролерів домену та серверів-членів. Системою можна керувати та захищати за допомогою групових політик Active Directory. Це гнучка ієрархічна організаційна модель, яка дозволяє легко керувати та деталізувати конкретне делегування адміністративних обов'язків. AD здатний керувати мільйонами об'єктів у межах одного домену.
Основні розділи
Книги групових політик Active Directory організовані з чотирьох типів розділів чи контейнерних структур. Ці чотири підрозділи - ліси (forests), домени, організаційні підрозділи та сайти:
Ліс - колекція кожного об'єкта, його атрибути та синтаксис.
Домен — це набір комп'ютерів, на яких використовується загальний набір політик, ім'я та база даних їхніх членів.
Організаційні одиниці – контейнери, в яких домени можуть бути згруповані. Вони створюють ієрархію для домену та створюють структуру компанії у географічних чи організаційних умовах.
Сайти - фізичні угруповання, що не залежать від галузі та структури організаційних одиниць. Сайти розрізняють розташування, підключені низько- та високошвидкісними з'єднаннями, та визначаються однією або декількома підмережами IP.
Ліси не обмежені географією чи топологією мережі. Один ліс може містити численні домени, кожен із яких має загальну схему. Для членів домену того ж лісу не потрібно навіть виділене з'єднання LAN або WAN. Єдина мережа може бути батьківщиною кількох незалежних лісів. Загалом, для кожного юридичного лицямає використовуватися один ліс. Проте додаткові ліси можуть бути бажаними для випробувань і досліджень за межами виробничого лісу.
Домени
Домени Active Directory служать як контейнери для політик безпеки та адміністративних призначень. За замовчуванням усі об'єкти у яких підпорядковуються груповим політикам. Аналогічно будь-який адміністратор може керувати всіма об'єктами всередині домену. Крім того, кожен домен має власну унікальну базу даних. Таким чином, автентифікація складає основі домену. Після аутентифікації облікового запису користувача цей обліковий запис отримує доступ до ресурсів.
Для налаштування групових політик у Active Directory потрібно один або кілька доменів. Як згадувалося раніше, домен AD є набір комп'ютерів, на яких використовується загальний набір політик, ім'я та база даних їх членів. Домен повинен мати один або кілька серверів, які служать контролерами домену (DC) та зберігають базу даних, підтримують політики та надають автентифікацію для входу.
Контролери домену
У Windows NT базовим контролером домену (PDC) та контролером домену резервного копіювання (BDC) були ролі, які можуть бути призначені серверу в мережі комп'ютерів, які використовують операційну систему Windows. Windows використовувала ідею домену для керування доступом до набору мережних ресурсів (додатків, принтерів тощо) для групи користувачів. Користувачеві необхідно лише увійти в домен, щоб отримати доступ до ресурсів, які можуть бути розташовані на декількох серверах в мережі.
Один сервер, відомий як основний контролер домену, керував основною базою даних користувача для домену. Один або кілька серверів було визначено як резервні контролери домену. Первинний контролер періодично надсилав копії бази даних контролерам резервних доменів. Резервний контролер домену може увійти як основний контролера домену, якщо PDC-сервер зазнав невдачі, а також може допомогти збалансувати робоче навантаження, якщо мережа досить зайнята.
Делегування та налаштування Active Directory
У Windows 2000 Server, коли контролери домену були збережені, ролі сервера PDC і BDC були в основному замінені Active Directory. Більше немає потреби створювати окремі домени для поділу адміністративних привілеїв. Усередині AD можна делегувати адміністративні привілеї з урахуванням організаційних одиниць. Домени більше не обмежені лімітом 40 000 користувачів. Домени AD можуть управляти мільйонами об'єктів. Оскільки більше немає PDC і BDC, налаштування групових політик Active Directory застосовує реплікацію з кількома провідними, і всі контролери домену однорангові.
Оргструктура
Організаційні підрозділи набагато гнучкіші та простіші в управлінні, ніж у доменах. Оргединиці надають вам майже необмежену гнучкість, оскільки ви можете переміщати їх, видаляти та створювати нові підрозділи в міру потреби. Однак домени набагато жорсткіші у своїх налаштуваннях структури. Домени можуть видалятися і створюватись заново, але цей процес дестабілізує середовище і його слід уникати, коли це можливо.
Сайти є колекціями IP-підмереж, які мають швидкий і надійний зв'язок між усіма хостами. Іншим способом створення сайту є підключення до локальної мережі, але не з'єднання WAN, оскільки з'єднання WANзначно повільніше та менш надійні, ніж з'єднання LAN. Використовуючи сайти, ви можете контролювати та зменшувати обсяг трафіку, який проходить повільними каналами глобальної мережі. Це може призвести до ефективнішого потоку трафіку для завдань продуктивності. Він також може зменшити витрати на WAN-зв'язок для послуг з оплатою за біт.
Майстер інфраструктури та глобальний каталог
Серед інших ключових компонентів Windows Server Active Directory є майстер інфраструктури (IM), який є повнофункціональною службою FSMO (гнучкий одиночний майстер операцій), що відповідає за автоматичний процес, який фіксує застарілі посилання, відомі як фантоми, в базі даних Active Directory.
Фантоми створюються на DC, які вимагають перехресного посилання між об'єктом у межах власної бази даних та об'єктом з іншого домену в лісі. Це відбувається, наприклад, коли ви додаєте користувача з одного домену до групи в іншому домені у тому ж лісі. Фантоми вважаються застарілими, коли вони більше не містять оновлених даних, які виникають через зміни, внесені до стороннього об'єкта, що представляється фантомом. Наприклад, коли цільовий об'єкт перейменовується, переміщається, переноситься між доменами або видаляється. Майстер інфраструктури несе виняткову відповідальність за пошук та виправлення застарілих фантомів. Будь-які зміни, внесені в результаті процесу виправлення, потім повинні бути репліковані на інші контролери домену.
Майстер інфраструктури іноді плутають із глобальним каталогом (GC), який підтримує часткову, доступну тільки для читання копію кожного домену в лісі і, крім іншого, використовується для універсального зберігання груп та обробки входу до системи. Оскільки GC зберігають часткову копію всіх об'єктів, вони можуть створювати міждоменні посилання без необхідності фантомів.
Active Directory та LDAP
Microsoft включає LDAP (протокол полегшеного доступу до каталогів) як складовий компонент Active Directory. LDAP — це програмний протокол, що дозволяє будь-якому користувачеві знаходити організації, окремих осіб та інші ресурси, такі як файли та пристрої в мережі, чи то в загальнодоступному інтернеті, чи в корпоративній інтрамережі.
У мережах TCP/IP (включно з Інтернетом) система доменних імен (DNS) — це система каталогів, яка використовується для прив'язки імені домену до певної мережевої адреси (унікального розташування в мережі). Однак, ви можете не знати доменне ім'я. LDAP дозволяє вам шукати людей, не знаючи, де вони знаходяться (хоча додаткова інформаціядопоможе у пошуку).
Каталог LDAP організований у простій ієрархічній ієрархії, що складається з наступних рівнів:
Організації.
Організаційні одиниці (відділи).
Окремі особи (включаючи людей, файли та спільні ресурси, такі як принтери).
Кореневий каталог (початкове місце чи джерело дерева).
Каталог LDAP можна розповсюджувати серед багатьох серверів. Кожен сервер може мати репліковану версію загального каталогу, який періодично синхронізується.
Для кожного адміністратора важливо розуміти, що таке LDAP. Оскільки пошук інформації в Active Directory та можливість створення запитів LDAP особливо корисний при пошуку інформації, що зберігається в базі даних AD. З цієї причини багато адміністраторів приділяють велика увагаосвоєння фільтра пошуку LDAP.
Керування груповою політикою та Active Directory
Важко обговорювати AD без згадки про групову політику. Адміністратори можуть використовувати групові політики в Microsoft Active Directory для визначення параметрів користувачів та комп'ютерів у мережі. Ці параметри налаштовуються та зберігаються у так званих об'єктах групової політики (GPO), які потім зв'язуються з об'єктами Active Directory, включаючи домени та сайти. Це основний механізм застосування змін до комп'ютерів користувача серед Windows.
Завдяки управлінню груповою політикоюадміністратори можуть глобально налаштовувати параметри робочого столу на комп'ютерах користувача, обмежувати/дозволяти доступ до певним файламта папок у мережі.
Застосування групових політик
Важливо розуміти, як використовуються та застосовуються об'єкти групової політики. Для них прийнятний такий порядок: спочатку застосовуються політики локальних машин, потім політики сайту, потім політики домену, а потім політики, які застосовуються до окремих організаційних одиниць. Користувальницький або комп'ютерний об'єкт може належати лише одному сайту та одному домену в будь-який момент часу, тому вони отримуватимуть лише об'єкти групової політики, пов'язані з цим сайтом або доменом.
Структура об'єктів
Об'єкти GPO розбиваються на дві окремі частини: шаблон групової політики (GPT) та контейнер групової політики (GPC). p align="justify"> Шаблон групової політики відповідає за збереження певних параметрів, створених в об'єкті групової політики, і має важливе значення для його успіху. Він зберігає ці налаштування у великій структурі папок та файлів. Щоб налаштування успішно застосовувалися до всіх об'єктів користувача та комп'ютера, GPT має бути реплікований для всіх контролерів у домені.
Контейнер групової політики — це частина об'єкта групової політики, який зберігається в Active Directory, який знаходиться на кожному контролері домену в домені. GPC відповідає за ведення посилань на розширення клієнтів (CSE), шлях до GPT, шляхи до пакетів установки програмного забезпечення та інші посилальні аспекти об'єкта групової політики. GPC не містить великої кількості інформації, що стосується відповідного об'єкта групової політики, але він необхідний для функціональності GPO. Коли налаштовані політики інсталяції програмного забезпечення, GPC допомагає підтримувати посилання, пов'язані з об'єктом групової політики і зберігає інші реляційні посилання та шляхи, що зберігаються в атрибутах об'єкта. Знання структури GPC та способу доступу до прихованої інформації, що зберігається в атрибутах, окупиться, коли вам потрібно буде виявити проблему, пов'язану з груповою політикою.
У Windows Server 2003 Microsoft випустила рішення для управління груповими політиками як засіб об'єднання даних у вигляді оснастки, відомої як консоль управління груповими політиками (GPMC). GPMC надає інтерфейс керування, орієнтований на GPO, що значно спрощує адміністрування, керування та розташування об'єктів групової політики. Через GPMC ви можете створювати нові об'єкти групової політики, змінювати та редагувати об'єкти, вирізати/копіювати/вставляти об'єкти групової політики, створювати резервні копії об'єктів та виконувати результуючий набір політик.
Оптимізація
У міру збільшення кількості керованих об'єктів групової політики продуктивність впливає на машини в мережі. Порада: при зниженні продуктивності обмежте мережеві параметриоб'єкт. Час обробки збільшується прямо пропорційно до кількості індивідуальних налаштувань. Відносно прості конфігурації, такі як налаштування робочого стола або політики Internet Explorer, можуть не зайняти багато часу, в той час як переадресація папок програмного забезпечення може серйозно навантажити мережу, особливо в періоди піки.
Розділіть об'єкти групової політики користувача, а потім вимкніть частину, що не використовується. Одна з найкращих практик як для підвищення продуктивності, так і для зниження управлінської плутанини полягає у створенні окремих об'єктів для параметрів, які будуть застосовуватися до комп'ютерів та окремих користувачів.
2002 року, прогулюючись коридором кафедри інформатики свого улюбленого університету, я побачив на дверях кабінету «Системи NT» свіжий плакат. На плакаті були зображені іконки облікових записів, об'єднані в групи, від яких у свою чергу відходили стрілки до інших іконок. Все це схематично об'єднувалося в якусь структуру, було написано щось про єдину систему входу, авторизацію тощо. Наскільки зараз розумію на тому плакаті, була зображена архітектура систем Windows NT 4.0 Domains і Windows 2000 Active Directory. З цього моменту почалося і відразу ж закінчилося моє перше знайомство з Active Directory, тому що потім була важка сесія, веселі канікули, після яких друг поділився FreeBSD 4 і Red Hat Linux, і на найближчі кілька років я поринув у світ Unix-подібних систем, але вміст плакату я так і не забув.
До систем на платформі Windows Server мені довелося повернутися і більш тісно з ними познайомитись, коли я перейшов працювати в компанію, де керування всією ІТ-інфраструктурою було засноване на Active Directory. Пам'ятаю, що головний адмін тієї компанії на кожній нараді постійно щось твердив про якісь Active Directory Best Practices. Тепер, після 8 років періодичного спілкування з Active Directory, я добре розумію, як працює дана система і що таке Active Directory Best Practices.
Як ви вже, напевно, здогадалися, йтиметься про Active Directory.
Всім, кому цікава дана тема, ласкаво просимо до кат.
Дані рекомендації справедливі для клієнтських систем, починаючи з Windows 7 і вище, для доменів та лісів рівня Windows Server 2008/R2 та вище.
Стандартизація
Планування Active Directory слід розпочати з розробки своїх стандартів призначення імен об'єктів та їх розташування у каталозі. Необхідно створити документ, де визначити всі необхідні стандарти. Звичайно, це досить часто рекомендація для ІТ фахівців. Принцип «спочатку пишемо документацію, та був у цій документації будуємо систему» є дуже хорошим, але рідко реалізуємо практично з багатьох причин. Серед цих причин - проста людська лінь чи відсутність відповідної компетенції, решта причин є похідними від перших двох.
Рекомендую - спочатку напишіть документацію, все обдумайте і потім приступайте до інсталяції першого контролера домену.
Наприклад, наведу розділ документа за стандартами назви об'єктів Active Directory.
Найменування об'єктів.
- Назва користувальницьких групмає починатися з префіксу GRUS_ (GR - Group, US - Users)
- Назва комп'ютерних груп має починатися з префікса GRCP_ (GR - Group, CP - Computers)
- Назва груп делегування повноважень має починатися з префіксу GRDL_ (GR – Group, DL – Delegation)
- Назва груп доступу до ресурсів має починатися з префіксу GRRS_ (GR - Group, RS - resources)
- Назва груп для політик має починатися з префіксів GPUS_, GPCP_ (GP – Group policy, US – Users, CP – Computers)
- Назва клієнтських комп'ютерів має складатися з двох, трьох літер від назви організації, за якими через дефіс повинен йти номер, наприклад, nnt-01.
- Назва серверів повинна починатися лише з двох літер, за якими через дефіс має йти роль сервера та його номер, наприклад, nn-dc01.
Ваш підхід до написання документації має бути дуже ґрунтовним, це дозволить заощадити велику кількість часу надалі.
Спрощуйте все, що можливо, намагайтеся досягти рівноваги
При побудові Active Directory необхідно дотримуватися принципу досягнення рівноваги, роблячи вибір на користь простих та зрозумілих механізмів.
Принцип рівноваги полягає в тому, щоб досягти необхідного функціоналу та безпеки за максимальної простоти рішення.
Необхідно намагатися побудувати систему так, щоб її пристрій був зрозумілий самому не досвідченому адміністратору або навіть користувачеві. Наприклад, свого часу була рекомендація створювати структуру лісу з кількох доменів. Понад те рекомендувалося розгортати як мультидоменные структури, а й структури з кількох лісів. Можливо, така рекомендація існувала через принцип «розділяй і владарюй», або тому Microsoft усім твердила, що домен - це межа безпеки і розділивши організацію на домени, ми отримаємо окремі структури, які простіше контролювати окремо. Але як показала практика, що більш просто обслуговувати та контролювати однодоменні системи, де межами безпеки є організаційні одиниці (OU), а не домени. Тому уникайте створення складних мультидоменних структур, краще групуйте об'єкти за OU.
Звичайно, слід діяти без фанатизму, якщо неможливо обійтися без декількох доменів, то потрібно створювати кілька доменів, також і з лісами. Головне, щоб ви розуміли, що робите, і до чого це може спричинити.
Важливо розуміти, що просту інфраструктуру Active Directory легше адмініструвати та контролювати. Я навіть сказав би, що чим простіше, тим безпечніше.
Застосовуйте принцип спрощення. Намагайтеся досягти рівноваги.
Дотримуйтесь принципу - «об'єкт - група»
Починайте створення об'єктів Active Directory із створення групи для даного об'єкта, і вже групі призначайте необхідні права. Розглянемо з прикладу. Вам необхідно створити обліковий запис головного адміністратора. Створіть спочатку групу Head Admins і лише потім створіть сам обліковий запис і додайте його до цієї групи. Групі Head Admins призначте права головного адміністратора, наприклад, додавши до групи Domain Admins. Майже завжди виходить так, що через деякий час приходить на роботу ще один співробітник, якому потрібні аналогічні права, і замість того, щоб займатися делегуванням прав на різні розділи Active Directory, можна буде просто додати його до необхідної групи, для якої в системі вже визначено роль та делеговані необхідні повноваження.
Ще один приклад. Вам необхідно делегувати права на OU з користувачами груп системних адміністраторів. Не делегуйте права безпосередньо групі адміністраторів, а створіть спеціальну групу на кшталт GRDL_OUName_Operator_Accounts, якій призначте права. Потім просто додайте групу відповідальних адміністраторів до групи GRDL_OUName_Operator_Accounts. Обов'язково вийти так, що незабаром вам знадобиться делегувати іншій групі адміністраторів права на цю OU. І в цьому випадку ви просто додасте групу даних адміністраторів до групи делегування GRDL_OUName_Operator_Accounts.
Пропоную наступну структуругруп.
- Групи користувачів (GRUS_)
- Групи адміністраторів (GRAD_)
- Групи делегування (GRDL_)
- Групи політик (GRGP_)
- Групи серверів (GRSR_)
- Групи клієнтських комп'ютерів (GRCP_)
- Групи доступу до загальних ресурсів (GRRS_)
- Групи доступу до принтерів (GRPR_)
Дотримуйтесь принципу рівноваги, обмежте кількість ролей для груп і пам'ятайте, що назва групи повинна в ідеалі повністю описувати її роль.
Архітектура OU.
Архітектуру OU в першу чергу слід продумувати з погляду безпеки та делегування прав на цю OU системним адміністраторам. Не рекомендую планувати архітектуру OU з погляду прив'язки до них групових політик (хоча так найчастіше роблять). Для деяких здається трохи дивною моя рекомендація, але я не рекомендую взагалі прив'язувати групові політики до OU. Подробиці читайте у секції Групові політики.
OU Admins
Рекомендую виділити для адміністративних акаунтів та груп окрему OU, куди помістити акаунти та групи всіх адміністраторів та інженерів технічної підтримки. До цієї OU слід обмежити доступ звичайних користувачів, а управління об'єктами з цієї OU делегувати лише головним адміністраторам.
OU Computers
OU для комп'ютерів найкраще планувати з погляду географічної приналежності комп'ютерів та типів комп'ютерів. Розподіліть комп'ютери з різних географічних локацій за різними OU, а їх у свою чергу розділіть на клієнтські комп'ютери та сервери. Сервери можна поділити на Exchange, SQL та інші.
Користувачі, права в Active Directory
Користувальницьким обліковим записам Active Directory слід приділяти особливу увагу. Як було сказано в секції про OU, користувацькі облікові записислід групувати, виходячи з принципу делегування повноважень на дані акаунти. Також важливо дотримуватися принципу мінімальних привілеїв - чим менше у користувача прав у системі, тим краще. Рекомендую відразу закладати рівень привілеїв користувача у назву його облікового запису. Обліковий запис для повсякденної роботи повинен складатися з Прізвища користувача та ініціалів на латиниці (Наприклад, IvanovIV або IVIvanov). Обов'язковими полями є First Name, Initials, Last Name, Display Name (російською), email, mobile, Job Title, Manager.
Аккаунти адміністраторів мають бути наступних типів:
- З правами адміністратора на комп'ютери, але не сервери. Повинні складатися з ініціалів власника та приставки local (Наприклад, iivlocal)
- З правами на адміністрування серверів та Active Directory. Повинні складатися лише з ініціалів (наприклад, iiv).
Поясню, навіщо слід розділяти адміністративні облікові записи на адміністраторів серверів та адміністраторів клієнтських комп'ютерів. Робити це необхідно, з міркувань безпеки. Адміністратори клієнтських комп'ютерів матимуть право встановити софт на клієнтських комп'ютерах. Який і для чого софт встановлюватиметься, сказати ніколи точно не можна. Тому запускати інсталяцію програми з правами доменного адміністратора небезпечно, можна скомпрометувати весь домен. Необхідно адмініструвати клієнтські комп'ютери лише з правами локального адміністратора цього комп'ютера. Це унеможливить цілу низку атак на акаунти доменних адміністраторів, на кшталт «Pass The Hash». Додатково адміністраторам клієнтських комп'ютерів необхідно закрити підключення через службу терміналів та підключення до мережі до комп'ютера. Комп'ютери технічної підтримки та адміністраторів слід помістити в окремий VLAN, щоб обмежити доступ до них з мережі клієнтських комп'ютерів.
Виділення прав адміністратора користувачам
Якщо вам необхідно надати права адміністратора користувачу, у жодному разі не поміщайте його обліковий запис для повсякденної роботи до групи локальних адміністраторівкомп'ютера. Обліковий запис для повсякденної роботи має бути завжди обмежений у правах. Створіть для нього окремий адміністративний обліковий запис виду namelocal і додайте цей обліковий запис до групи локальних адміністраторів за допомогою політики, обмеживши її застосування лише на комп'ютері користувача за допомогою item-level targeting. Цей обліковий запис користувач зможе користуватися, використовуючи механізм Run AS.
Політики паролів
Створіть окремі політики паролів для користувачів та адміністраторів за допомогою fine-grained password policy. Бажано, щоб пароль користувача складався мінімум з 8 символів і змінювався хоча б раз на квартал. Адміністраторам бажано змінювати пароль кожні два місяці, і він має бути мінімум із 10-15 символів та відповідати вимогам складності.
Склад доменних та локальних груп. Механізм Restricted Groups
Склад доменних та локальних груп комп'ютерів домену повинен контролюватись лише в автоматичному режимі, за допомогою механізму Restricted Groups. Чому це необхідно робити тільки в такий спосіб, поясню на наступному прикладі. Зазвичай після того, як розірвуть домен Active Directory, адміністратори додають себе доменні групи на кшталт Domain admins, Enterprise admins, додають у необхідні групи інженерів технічної підтримки та інших користувачів теж розподіляють по групам. У процесі адміністрування даного домену процес видачі прав повторюється багаторазово і буде дуже складно згадати, що ти вчора тимчасово додавав бухгалтера Ніну Петрівну до групи адміністраторів 1С і що сьогодні необхідно її з цієї групи прибрати. Ситуація погіршиться, якщо в компанії працює кілька адміністраторів і щоразу видає права користувачам у подібному стилі. Вже за рік майже неможливо розібратися в тому, які кому права призначені. Тому склад груп має контролюватись лише груповими політиками, які при кожному застосуванні будуть наводити все в лад.
Склад вбудованих груп
Варто сказати, що вбудовані групи на кшталт Account Operators, Backup operators, Crypt Operators, Guests, Print Operators, Server Operators повинні бути порожніми як у домені, так і на клієнтських комп'ютерах. Ці групи передусім необхідні забезпечення зворотної сумісностізі старими системами, і користувачі цих груп наділяються надто великими правами у системі, і стають можливі атаки підвищення привілеїв.
Облікові записи локальних адміністраторів
За допомогою механізму Restricted Groups необхідно блокувати облікові записи локальних адміністраторів на локальних комп'ютерахблокувати гостьові облікові записи та очищати групу локальних адміністраторів на локальних комп'ютерах. У жодному разі не використовуйте групові політики для встановлення паролів на облікові записи локальних адміністраторів. Цей механізм не безпечний, пароль можна отримати прямо з політики. Але, якщо ви вирішили не блокувати облікові записи локальних адміністраторів, то для коректної установки паролів та їхньої ротації використовуйте механізм LAPS. На жаль, налаштування LAPS не до кінця автоматизовано, і тому потрібно буде вручну додавати атрибути до схеми Active Directory, видавати на них права, призначати групи і так далі. Тому простіше заблокувати облікові записи локальних адміністраторів.
Облікові записи.
Для запуску сервісів використовуйте сервісні облікові записи та механізм gMSA (доступний у системах Windows 2012 та вище)
Групові політики
Документуйте політики перед створенням/зміною.
Під час створення політики використовуйте принцип «Політика – група». Тобто перед створенням політики створіть спочатку групу для цієї політики, приберіть із сфери застосування політики групу Authenticated users і додайте створену групу. Прив'яжіть політику не до OU, а до кореня домену і регулюйте область її застосування за допомогою додавання об'єктів до групи політики. Такий механізм я вважаю більш гнучким та зрозумілим, ніж лінковку політики до OU. (Саме про це я писав у секції про Архітектуру OU).
Завжди регулюйте сферу застосування політики. Якщо ви створили політику лише для користувачів, то відключайте структуру комп'ютера і навпаки, відключайте структуру користувача, якщо створили політику лише для комп'ютерів. Завдяки цим налаштуванням політики будуть швидше застосовуватися.
Налаштуйте щоденне резервне копіюванняполітик при допомоги Power Shell, щоб у разі помилок конфігурування можна завжди повернути налаштування до вихідних.
Центральне сховище шаблонів (Central Store)
Починаючи з Windows 2008 стало можливим зберігати ADMX-шаблони групових політик у центральному сховищі, у SYSVOL. До цього за умовчанням усі шаблони політик зберігалися локально на клієнтах. Щоб розмістити шаблони ADMX у центральному сховищі, необхідно скопіювати вміст папки %SystemDrive%\Windows\PolicyDefinitions разом із підпапками з клієнтських систем (Windows 7/8/8.1) до директорії контролера домену %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions із злиттям вмісту, але без заміни. Далі слід зробити таке ж копіювання з серверних систем, починаючи з найстаріших. В останню чергу, при копіюванні папок і файлів з останньої версії сервера, зробіть копіювання зі злиттям та ЗАМІНОЮ.
Копіювання ADMX-шаблонів
Додатково в центральному сховищі можна розміщувати ADMX-шаблони для будь-яких програмних продуктів, таких як Microsoft Office, продукти Adobe, Google та інших. Зайдіть на сайт постачальника програмного продукту, скачайте ADMX-шаблон групової політики та розпакуйте його в папку %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions на будь-якому з контролерів домену. Тепер ви зможете керувати потрібним програмним продуктом через групові політики.
Фільтри WMI
Фільтри WMI не дуже швидко працюють, тому краще використовувати механізм item-level targeting. Але якщо item-level targeting використовувати неможливо, і ви вирішили використовувати WMI, то рекомендую відразу створити для себе кілька найпоширеніших фільтрів: фільтр «Тільки клієнтські операційні системи», «Тільки серверні операційні системи», фільтри «Windows 7», фільтри «Windows 8, Windows 8.1, Windows 10. Якщо у вас будуть готові набори WMI фільтрів, потім буде простіше застосувати потрібний фільтр до потрібної політики.
Аудит подій Active Directory
Обов'язково увімкніть аудит подій на контролерах домену та інших серверах. Рекомендую включити аудит наступних об'єктів:
- Audit Computer Account Management - Success, Failure
- Audit Other Account Management Events - Success, Failure
- Audit Security Group Management - Success, Failure
- Audit User Account Management - Success, Failure
- Audit Kerberos Authentication Service - Failure
- Audit Other Account Logon Events - Failure
- Audit Audit Policy Change - Success, Failure
Розширені налаштування аудиту
Детально зупинятися на налаштуваннях аудиту не буду, оскільки в Мережі є достатньо статей, присвячених даній темі. Доповню тільки, що окрім включення аудиту, слід налаштувати оповіщення електронною поштою про критичні події безпеки. Варто також врахувати те, що в системах з великою кількістю подій варто виділити окремі сервери для збирання та аналізу файлів журналу.
Скрипти адміністрування та прибирання
Усі однотипні та часто повторювані дії необхідно виконувати за допомогою скриптів адміністрування. Серед таких дій: створення облікових записів користувачів, створення облікових записів адміністраторів, створення груп, створення OU і так далі. Створення об'єктів за допомогою скриптів дозволить дотримуватися вашої логіки назви об'єктів Active Directory, вбудувавши перевірки синтаксису прямо в скрипти.
Також варто написати скрипти прибирання, які в автоматичному режимі контролюватимуть склади груп, виявлятимуть користувачів та комп'ютери, які давно не підключалися до домену, виявлятимуть порушення інших ваших стандартів тощо.
Я не зустрічав як явну офіційну рекомендацію використання скриптів адміністрування для контролю дотримання стандартів та виконання фонових операцій. Але сам віддаю перевагу перевіркам і процедурам в автоматичному режимі за допомогою скриптів, так як це дуже сильно економить час і позбавляє великої кількості помилок і, звичайно, тут позначається мій трохи юніксовий підхід до адміністрування, коли простіше набрати пару команд, ніж клацати мишкою по вікнах .
Ручне адміністрування
Частину операцій з адміністрування вам та вашим колегам буде необхідно робити у ручному режимі. Для цього рекомендую використовувати консоль mmc з доданими до неї оснастками.
Як буде сказано далі, контролери домену у вас мають функціонувати в режимі Server Core, тобто адміністрування всього оточення AD слід виконувати лише зі свого комп'ютера за допомогою консолей. Для адміністрування Active Directory необхідно на свій комп'ютер поставити Remote Server Administration Tools. Консолі слід запускати на комп'ютері з-під користувача з правами адміністратора Active Directory, якому делеговано керування.
Мистецтво керування Active Directory за допомогою консолей вимагає окремої статті, а може бути навіть окремого навчального відео, тому тут тільки говорю про сам принцип.
Контролери домену
У будь-якому домені, контролерів має бути, як мінімум два. На контролерах домену має бути якнайменше служб. Не варто робити з контролера домену файловий сервер або, боронь вас бог, підняти на ньому роль сервера терміналів. Використовуйте на контролерах домену операційні системи в режимі Server Core, повністю видаляючи підтримку WoW64, це значно зменшить кількість необхідних оновленьі збільшить їхню безпеку.
Microsoft раніше не рекомендувала віртуалізувати контролери домену через те, що при відновленні з моментальних знімків були можливі конфлікти реплікації. Можливо, були ще причини, точно сказати не можу. Зараз гіпервізори навчилися повідомляти контролерів про відновлення їх із моментальних знімків, і ця проблема зникла. Я ж весь час віртуалізував контролери, не роблячи жодних миттєвих знімків, тому що не розумію, навіщо взагалі може знадобитися робити такі на контролерах домену. На мою думку, простіше зробити резервну копіюконтролера домену стандартними засобами. Тому рекомендую віртуалізувати всі контролери домену, які тільки можливо. Така конфігурація буде гнучкішою. При віртуалізації контролерів домену розташовуйте їх у різних фізичних хостах.
Якщо вам необхідно розмістити контролер домену у незахищеному фізичному середовищі або у філії вашої організації, то для цих цілей використовуйте RODC.
Ролі FSMO, первинні та вторинні контролери
Ролі FSMO контролерів домену продовжують породжувати страх у головах адміністраторів-початківців. Часто новачки вивчають Active Directory зі застарілої документації або слухають розповіді інших адміністраторів, які десь колись читали.
За всіма п'ятьма + 1 ролями коротко слід сказати таке. Починаючи з Windows Server 2008, більше не існує первинних і вторинних контролерів домену. Всі п'ять ролей контролерів домену переносяться, але не можуть розміщуватися одночасно більш ніж на одному контролері. Якщо ми візьмемо один із контролерів, який, наприклад, був господарем 4 ролей і видалимо його, то всі ці ролі ми без проблем зможемо перенести на інші контролери, і в домені нічого страшного не станеться, нічого не зламається. Це можливо тому, що всю інформацію про роботу, пов'язану з тією чи іншою роллю, її господар зберігає прямо в Active Directory. І якщо ми передаємо роль іншому контролеру, то він насамперед звертається за збереженою інформацією Active Directory і приступає до несення служби. Домен може досить довго існувати без господарів ролей. Єдина роль, яка повинна бути завжди в Active Directory і без якої буде все дуже погано, це роль глобального каталогу(GC) її можуть нести на собі всі контролери в домені. Рекомендую призначати роль GC кожному контролеру в домені, чим більше, тим краще. Звичайно, ви зможете знайти випадки, коли на контролер домену не варто встановлювати роль GC. Що ж, як не треба, то не треба. Дотримуйтесь рекомендацій без фанатизму.
Служба DNS
Служба DNS є критичною для роботи Active Directory і працювати повинна без збоїв. Службу DNS найкраще ставити на кожен контролер домену та зберігати DNS зониу самій Active Directory. Якщо ви будете використовувати Active Directory для зберігання зон DNS, то вам слід налаштовувати властивості TCP/IP з'єднання на контролерах домену, таким чином, щоб на кожному контролері як первинний DNS-сервер був будь-який інший DNS-сервер, а як вторинний можна поставити адреса 127.0.0.1. Таке налаштування робити необхідно тому, що для нормального старту служби Active Directory потрібен працюючий DNS, а для старту DNS повинна бути запущена служба Active Directory, оскільки в ній лежить сама зона DNS.
Обов'язково налаштуйте зони зворотного переглядудля всіх своїх мереж та увімкніть автоматичне безпечне оновленнязаписів PTR.
Рекомендую додатково увімкнути автоматичне прибирання зони від застарілих записів DNS (dns scavenging).
Як DNS-Forwarders рекомендую вказати захищені сервери Яндекс, якщо немає інших швидших у вашій географічній локації.
Сайти та реплікація
Багато адміністраторів звикли вважати, що сайти – це географічне об'єднання комп'ютерів. Наприклад, сайт Москва, сайт Петербург. Таке уявлення з'явилося через те, що спочатку поділ Active Directory на сайти було зроблено з метою балансування та поділу мережевого трафікуреплікації. Контролерам домену у Москві необов'язково знати, що у Петербурзі було створено десять облікових записів комп'ютерів. І тому подібну інформацію про зміни можна передавати раз на годину за розкладом. Або взагалі проводити реплікацію змін один раз на добу і лише вночі, для економії смуги пропускання.
Про сайти я сказав би так: сайти - це логічні групи комп'ютерів. Комп'ютери, які з'єднані між собою гарним мережевим з'єднанням. А самі сайти з'єднані між собою з'єднанням з малою пропускною здатністю, що в наш час велика рідкість. Тому я поділяю Active Directory на сайти не для балансування трафіку реплікації, а для балансування мережного навантаження взагалі і для більш швидкої обробки клієнтських запитів комп'ютерів сайту. Поясню з прикладу. Є 100-мегабітна локальна мережа організації, яку обслуговують два контролери домену і є хмара, де розміщуються сервери додатків цієї організації з двома іншими хмарними контролерами. Таку мережу я поділю на два сайти для того, щоб контролери в локальній мережі обробляли запити клієнтів з локальної мережі, а контролери в хмарі - запити від серверів додатків. Додатково це дозволить розділити запити до службам DFSта Exchange. І так як зараз я рідко де зустрічаю канал в Інтернеті менше 10 мегабіт в секунду, то я включу Notify Based Replication, це коли реплікація даних відбувається відразу, як тільки з'явилися зміни в Active Directory.
Висновок
Сьогодні вранці я думав, чому людський егоїзм не вітається в суспільстві і десь на глибинному рівні сприйняття викликає вкрай негативні емоції. І єдина відповідь, яка спала мені на думку, це те, що людська раса не вижила б на цій планеті, якби не навчилася спільному використаннюфізичних та інтелектуальних ресурсів. Саме тому я і ділюся цією статтею з вами і, сподіваюся, що мої рекомендації допоможуть вам покращити свої системи, і ви станете значно менше витрачати час на пошук та усунення несправностей. Все це призведе до звільнення більшої кількостічасу та енергії для творчості. Набагато приємніше жити у світі творчих та вільних людей.
Добре, якщо в коментарях ви по можливості поділитеся своїми знаннями та практиками побудови Active Directory.
Усім миру та добра!
Ви можете допомогти і переказати трохи коштів на розвиток сайту
Active Directory – служба каталогів корпорації Microsoft для ОС сімейства Windows NT.
Дана служба дозволяє адміністраторам використання групових політик для забезпечення однаковості налаштувань користувача робочого середовища, установки ПЗ, оновлень та ін.
У чому полягає суть роботи Active Directory і які завдання вона вирішує? Читайте далі.
Принципи організації однорангових та багаторангових мереж
Але виникає інша проблема, що якщо користувач user2 на PC2 вирішить змінити свій пароль? Тоді, якщо користувач user1 змінить пароль облікового запису, доступ user2 на РС1 до ресурсу буде неможливим.
Ще один приклад: у нас є 20 робочих станцій з 20 обліковими записами, яким ми хочемо надати доступ до якогось , для цього ми повинні створити 20 облікових записів на файловому сервері і надати доступ до необхідного ресурсу.
А якщо їх буде не 20, а 200?
Як ви розумієте адміністрування мережі при такому підході перетворюється на відмінне пекло.
Тому підхід з використанням робочих груп підходить для невеликих офісних мережз кількістю ПК трохи більше 10 одиниць.
За наявності в сітці більше 10 робочих станцій раціонально виправданим стає підхід, при якому одному вузлу мережі делегують права виконання аутентифікації та авторизації.
Цим вузлом і виступає контролер домену Active Directory.
Контролер домену
Контролер зберігає базу даних облікових записів, тобто. він зберігає облік і для РС1 і для РС2.
Тепер усі облікові записи прописуються один раз на контролері, а потреба в локальних облікових записах втрачає сенс.
Тепер, коли користувач заходить на ПК, вводячи свій логін і пароль, ці дані передаються в закритому вигляді на контролер домену, який виконує процедури автентифікації та авторизації.
Після цього контролер видає користувачеві, що здійснив вхід, щось на кшталт паспорта, з яким він надалі працює в мережі і який він пред'являє на запит інших комп'ютерів сітки, серверів до ресурсів яких він хоче підключитися.
Важливо! Контролер домену - це комп'ютер із піднятою службою Active Directory, який керує доступом користувачів до ресурсів мережі. Він зберігає ресурси (наприклад, принтери, папки з спільним доступом), служби (наприклад, електронна пошта), людей (облікові записи користувачів та груп користувачів), комп'ютери (облікові записи комп'ютерів).
Число таких збережених ресурсів може досягати мільйонів об'єктів.
Як контролер домену можуть виступати такі версії MS Windows: Windows Server 2000/2003/2008/2012 крім редакцій Web-Edition.
Контролер домену, крім того, що є центром автентифікації мережі, також є центром керування всіма комп'ютерами.
Відразу після увімкнення комп'ютер починає звертатися до контролера домену, задовго до появи вікна автентифікації.
Таким чином, виконується аутентифікація не тільки користувача, що вводить логін та пароль, а й аутентифікація клієнтського комп'ютера.
Встановлення Active Directory
Розглянемо приклад інсталяції Active Directory на Windows Server 2008 R2. Отже для встановлення ролі Active Directory, заходимо до « Server Manager»:
Додаємо роль "Add Roles":
Вибираємо роль Active Directory Domain Services:
І приступаємо до встановлення:
Після чого отримуємо вікно повідомлення про встановлену роль:
Після встановлення ролі контролера домену, приступимо до встановлення самого контролера.
Натискаємо «Пуск» у полі пошуку програм вводимо назву майстра DCPromo, запускаємо його та ставимо галочку для розширених налаштувань установки:
Тиснемо «Next» із запропонованих варіантів вибираємо створення нового домену та лісу.
Вводимо ім'я домену, наприклад example.net.
Пишемо NetBIOS ім'я домену, без зони:
Вибираємо функціональний рівень нашого домену:
Зважаючи на особливості функціонування контролера домену, встановлюємо також DNS-сервер .
Основним компонентом доменних служб у кожній організації є принципали безпеки (оригінальна назва - Security Principal), які надають користувачам, групам або комп'ютерам, яким потрібний доступ до певних ресурсів у мережі. Саме таким об'єктам як принципалам безпеки можна надавати дозволи доступу до ресурсів у мережі, причому кожному принципалу під час створення об'єкта надається унікальний ідентифікатор безпеки (SID), який складається з двох частин. Ідентифікатор безпеки SIDназивається числове уявлення, що унікально ідентифікує принципал безпеки. Перша частина такого ідентифікатора є ідентифікатор домену. Зважаючи на те, що принципали безпеки розташовані в одному домені, всім таким об'єктам присвоюється той самий ідентифікатор домену. Другою частиною SID є відносний ідентифікатор (RID), який використовується для унікальної ідентифікації принципала безпеки стосовно відомства, яке видає SID.
Незважаючи на те, що планування та розгортання інфраструктури доменних служб у більшості організацій виконується лише один раз і більшість об'єктів зміни вносяться дуже рідко, до важливого виключення з цього правила можна віднести принципали безпеки, які необхідно періодично додавати, змінювати, а також видаляти. Одним із основних компонента ідентифікації є облікові записи користувачів. По суті, облікові записи користувачів є фізичними об'єктами, в основному людьми, які є співробітниками вашої організації, але бувають винятки, коли облікові записи користувачів створюються для деяких додатків як служби. Облікові записи користувачів грають найважливішу рольв адмініструванні підприємства. До таких ролей можна віднести:
- Посвідчення особи користувачів, оскільки створений обліковий запис дозволяє входити на комп'ютери та домени саме з тими даними, справжність яких перевіряє домен;
- Дозвіл доступу до ресурсів домену, які призначаються користувачеві надання доступу до доменним ресурсам виходячи з явних дозволів.
Об'єкти облікових записів користувачів можна віднести до найпоширеніших об'єктів у Active Directory. Саме обліковим записам користувача адміністратори зобов'язані приділяти особливу увагу, оскільки користувачам властиво приходити працювати в організацію, переміщатися між відділами та офісами, одружуватися, виходити заміж, розлучатися і навіть звільнятися з компанії. Такі об'єкти являють собою набір атрибутів, причому тільки один обліковий запис може містити понад 250 різних атрибутів, що в кілька разів перевищує кількість атрибутів на робочих станціях і комп'ютерів, що працюють під операційною системою Linux. Під час створення облікового запису користувача створюється обмежений набір атрибутів, а вже потім ви можете додавати такі облікові дані користувача, як організаційні відомості, адреси проживання користувачів, телефонні номери та багато іншого. Тому важливо звернути увагу на те, що одні атрибути є. обов'язковими, а решта - опціональними. У цій статті я розповім про ключових методахстворення облікових записів користувача, про деякі опціональні атрибути, а також будуть описані засоби, що дозволяють автоматизувати рутинні дії, пов'язані зі створенням облікових записів користувачів.
Створення користувачів за допомогою оснащення «Active Directory – користувачі та комп'ютери»
У переважній більшості випадків системні адміністраторидля створення основних принципалів безпеки воліють використовувати оснастку, яка додається до папки «Адміністрація»відразу після встановлення ролі «Домові служби Active Directory»та підвищення сервера до контролера домену. Цей метод є найбільш зручним, оскільки для створення принципалів безпеки використовується графічний інтерфейс користувача і майстер створення облікових записів користувача дуже простий у застосуванні. До нестачі цього методу можна віднести той момент, що при створенні облікового запису користувача ви не можете відразу задати більшість атрибутів, і вам доведеться додавати необхідні атрибути шляхом редагування облікового запису. Щоб створити обліковий запис користувача, виконайте такі дії:
- В полі «Ім'я»Введіть ім'я користувача;
- В полі «Ініціали»введіть його ініціали (найчастіше ініціали не використовуються);
- В полі «Прізвище»введіть прізвище користувача, що створюється;
- Поле "Повне ім'я"використовується для створення таких атрибутів об'єкта, що створюється, як основне ім'я (Common Name) CNта відображення властивостей імені. Це поле має бути унікальним у всьому домені, і заповнюється автоматично, а змінювати його варто лише у разі потреби;
- Поле Ім'я входу користувачає обов'язковим і призначений для імені входу користувача до домену. Тут вам потрібно ввести ім'я користувача і з списку вибрати суфікс UPN, який буде розташований після символу @;
- Поле "Ім'я входу користувача (Пред-Windows 2000)"призначено для імені входу для систем, що передують операційній системі Windows 2000. В останні роки в організаціях все рідше зустрічаються власники таких систем, але поле обов'язкове, оскільки деяке програмне забезпечення для ідентифікації користувачів використовує саме цей атрибут;
Після заповнення всіх потрібних полів натисніть на кнопку «Далі»:
Мал. 2. Діалогове вікно створення облікового запису користувача
Мал. 3. Створення пароля для створюваного облікового запису
Створення користувачів на основі шаблонів
Зазвичай, в організаціях існує безліч підрозділів або відділів, до яких входять ваші користувачі. У цих підрозділах користувачі мають схожі властивості (наприклад, назва відділу, посади, номер кабінету тощо). Для найбільш ефективного управлінняобліковими записами користувачів з одного підрозділу, наприклад, використовуючи групові політики, доцільно їх створювати всередині домену у спеціальних підрозділах (інакше кажучи, контейнерах) на основі шаблонів. Шаблоном облікового записуназивається обліковий запис, що вперше з'явився ще за часів операційних систем Windows NT, в якому заздалегідь заповнені загальні для всіх користувачів атрибути. Щоб створити шаблон облікового запису користувача, виконайте такі дії:
- Загальні. Ця вкладка призначена для заповнення індивідуальних атрибутів користувача. До цих атрибутів належать ім'я користувача та його прізвище, короткий опис для облікового запису, контактний телефон користувача, номер кімнати, його електронна скринька, а також веб-сайт. Зважаючи на те, що ця інформація є індивідуальною для кожного окремого користувача, дані заповнені на цій вкладці не копіюються;
- Адреса. На поточній вкладці можна заповнити поштову скриньку, місто, область, поштовий індекста країну, де мешкають користувачі, які будуть створені на підставі цього шаблону. Так як у кожного користувача назви вулиць зазвичай не збігаються, дані з цього поля не копіюються;
- Обліковий запис. У цій вкладці ви можете вказати час входу користувача, комп'ютери, на які зможуть входити користувачі, такі параметри облікових записів як зберігання паролів, типи шифрування тощо, а також термін дії облікового запису;
- Профіль. Поточна вкладка дозволяє вказати шлях до профілю, сценарій входу, локальний шлях до домашньої папки, а також мережні диски, на яких буде розміщено домашню папку облікового запису;
- Організація. На цій вкладці ви можете вказати посаду співробітників, відділ, де вони працюють, назву організації, а також ім'я керівника відділу;
- Члени груп. Тут вказується основна група та членство у групах.
Це основні вкладки, які заповнюються під час створення шаблонів облікового запису. Крім цих шести вкладок, ви можете заповнювати інформацію в 13 вкладках. Більшість із цих вкладок будуть розглянуті в наступних статтях цього циклу.
Мал. 5. Діалогове вікно копіювання облікового запису користувача
Створення користувачів засобами командного рядка
Як і в більшості випадків, в операційній системі Windows є утиліти командного рядка з аналогічними функціями графічного інтерфейсу користувачаоснащення «Active Directory – користувачі та комп'ютери». Такі команди називаються командами DS, оскільки вони починаються з літер DS. Для створення принципів безпеки використовується команда Dsadd. Після команди вказуються модифікатори, які визначають тип і ім'я DN об'єкта. У разі створення облікових записів користувачів вам потрібно вказати модифікатор userщо є типом об'єкта. Після типу об'єкта необхідно ввести ім'я DN самого об'єкта. DN (Distinguished Name) об'єкта є результуючим набором, що містить відмінне ім'я. За DN зазвичай вказують ім'я користувача UPN або ім'я входу попередніх версій Windows. Якщо в імені DN є пробіли, то таке ім'я потрібно укласти в лапки. Синтаксис команди наступний:
Dsadd user DN_ім'я –samid ім'я_облікового_запису –UPN_ім'я –pwd пароль –додаткові параметри
З цією командою можна використовувати 41 параметр. Розглянемо найпоширеніші їх:
-samid- Ім'я облікового запису користувача;
-upn- Ім'я входу користувача перед-Windows 2000;
-fn– ім'я користувача, яке у графічний інтерфейсзаповнюється у полі «Ім'я»;
-mi- Ініціал користувача;
-ln– прізвище користувача, що вказується в полі «Прізвище» майстра створення облікового запису користувача;
-Display– вказує повне ім'я користувача, яке автоматично генерується в інтерфейсі користувача;
-empid– код працівника, який створюється для користувача;
-pwd- Параметр, що визначає пароль користувача. У разі, якщо ви вкажете символ зірочки (*), вам буде запропоновано ввести пароль користувача у захищеному від перегляду режимі;
-desc– короткий опис для облікового запису користувача;
-memberof- Параметр, що визначає членство користувача в одній або декількох групах;
-office- місцезнаходження офісу, де працює користувач. У властивостях облікового запису цей параметр можна знайти у вкладці «Організація»;
-tel- Номер контактного телефону поточного користувача;
-email– адреса електронної поштикористувача, який можна знайти у вкладці «Загальні»;
-hometel– параметр, який вказує номер домашнього телефону користувача;
-mobile – номер телефонумобільного користувача;
-fax- Номер факсимільного апарату, який використовує поточний користувач;
-title- Посада користувача в даній організації;
-dept– цей параметр дозволяє вказати найменування відділу, у якому працює цей користувач;
-company- Назва компанії, в якій працює користувач, що створюється;
-hmdir– основний каталог користувача, в якому будуть розміщені його документи;
-hmdrv– шлях до мережного диска, на якому буде розміщено домашню папку облікового запису
-profile- Шлях профілю користувача;
-mustchpwd- даний параметр вказує на те, що при наступному вході до системи користувач має змінити свій пароль;
-canchpwd– параметр, який визначає, чи користувач повинен змінювати свій пароль. Якщо значення параметра вказано "yes", У користувача буде можливість зміни пароля;
-reversiblepwd– поточний параметр визначає зберігання пароля користувача із застосуванням зворотного шифрування;
-pwdneverexpires– параметр, що вказує на те, що термін дії пароля ніколи не закінчиться. У всіх цих чотирьох параметрах значеннями можуть виступати тільки "yes"або "no";
-acctexpires– параметр, який визначає, через скільки днів термін дії облікового запису закінчиться. Позитивне значення є кількість днів, через яке обліковий запис закінчиться, а негативне означає, що термін дії вже закінчено;
-disabled– вказує, що обліковий запис вже вимкнено. Значеннями для цього параметра також є "yes"або "no";
-q- Вказівка тихого режиму для обробки команди.
Приклад використання:
Dsadd user “cn=Олексій Смирнов,OU=Маркетинг,OU=Користувачі,DC=testdomain,DC=com” -samid Alexey.Smirnov -upn Alexey.Smirnov -pwd * -fn Олексій -ln Смирнов -display “Олексій Смирнов” - tel "743-49-62" -email [email protected]-dept Маркетинг -company TestDomain -title Маркетолог -hmdir \dc\profiles\Alexey.Smirnov -hmdrv X -mustchpwd yes -disabled no
Мал. 6. Створення облікового запису користувача засобами утиліти Dsadd
Створення користувачів за допомогою CSVDE
Ще одна утиліта командного рядка CSVDE дозволяє імпортувати або експортувати об'єкти Active Direcoty, представлені у вигляді cvd-файлу – текстового файлу з роздільними комами, які можна створювати за допомогою табличного процесора Microsoft Excelабо найпростішого текстового редактора Блокнот. У цьому файлі кожен об'єкт є одним рядком і повинен містити атрибути, які перераховані в першому рядку. Варто звернути увагу на те, що за допомогою цієї команди ви не можете імпортувати паролі користувача, тобто, відразу після завершення операції імпорту облікові записи користувача будуть відключені. Приклад такого файлу наступний:
Мал. 7. Подання CSV-файлу
Синтаксис команди наступний:
Csvde -i -f filename.csv -k
- -i. Параметр, який відповідає режиму імпорту. Якщо ви не вкажіть цей параметр, ця команда буде використовувати за промовчанням режим експорту;
- -f
- -k
- -v
- -j
- -u. Параметр, який дозволяє використовувати режим Юнікод.
Приклад використання команди:
Csvde -i -f d:\testdomainusers.csv -k
Мал. 8. Імпорт облікових записів користувачів із файлу CSV
Імпорт користувачів засобами LDIFDE
Утиліта командного рядка Ldifde також дозволяє імпортувати або експортувати об'єкти Active Directory, використовуючи файловий формат LDIF (Lightweight Directory Access Protocol Data Interchange File). Цей файловий формат складається з блоку рядків, які утворюють конкретну операцію. На відміну від файлів CSV, у даному файловому форматі кожен окремий рядок являє собою набір атрибутів, після якого слідує двокрапка і саме значення поточного атрибута. Так само як і в CSV файлі, Першим рядком може бути атрибут DN. За ним слідує рядок changeType, який вказує тип операції (add, change або delete). Для того щоб навчитися розбиратися в цьому файловому форматі, вам потрібно вивчити Крайній міріключові атрибути принципів безпеки. Приклад надано нижче:
Мал. 9. Приклад LDF файлу
Синтаксис команди наступний:
Ldifde -i -f filename.csv -k
- -i. Параметр, який відповідає режиму імпорту. Якщо ви не вкажете цей параметр, ця команда буде використовувати за промовчанням режим експорту;
- -f. Параметр, що ідентифікує ім'я файлу, призначене для імпорту чи експорту;
- -k. Параметр, призначений для продовження імпорту, пропускаючи всі можливі помилки;
- -v. Параметр, за допомогою якого ви можете вивести докладну інформацію;
- -j. Параметр, відповідальний розташування файлу журналу;
- -d. Параметр, що вказує на корінь пошуку LDAP;
- -f. Параметр для фільтра пошуку LDAP;
- -p. Є область або глибину пошуку;
- -l. Призначений для вказівки списку атрибутів із роздільними комами, який буде включений в експорт результуючих об'єктів;
Створення користувачів за допомогою VBScript
VBScript є одним із найпотужніших інструментів, призначених для автоматизації адміністративних завдань. Цей інструментдозволяє створювати сценарії, призначені для автоматизування більшості дій, які можуть виконуватися за допомогою інтерфейсу користувача. Сценарії VBScript є текстовими файлами, які зазвичай користувачі можуть редагувати за допомогою звичайних текстових редакторів(наприклад, Блокнот). А для виконання сценаріїв потрібно двічі клацнути мишею по значку самого сценарію, який відкриється із застосуванням команди Wscript. Для того, щоб створити обліковий запис користувача в VBScript не існує певної команди, тому вам спочатку потрібно підключитися до контейнера, потім використовувати бібліотеку адаптерів Active Directory Services Interface (ADSI) за допомогою інструкції Get-Object, де виконується рядок запиту LDAP, що надає собою монікер протоколу LDAP:// з DN ім'ям об'єкта. Наприклад, Set objOU=GetObject(“LDAP://OU=Маркетинг,OU=Користувачі,dc=testdomain,dc=com”). Другий рядок коду активує метод Create підрозділу для створення об'єкта конкретного класу з конкретним іменем, наприклад, Set objUser=objOU.Create(“user”,”CN= Юрій Соловйов”). Як третій рядок вказується метод Put, де потрібно вказати найменування атрибута та його значення. Останній рядок сценарію підтверджує зроблені зміни, тобто objUser.SetInfo().
Приклад використання:
Set objOU=GetObject(“LDAP://OU=Маркетинг,OU=Користувачі,dc=testdomain,dc=com” Set objUser=objOU.Create(“user”,”CN= Юрій Соловйов”) objUser.Put “sAMAccountName” ,”Yuriy.Soloviev” objUser.Put “UserPrincipalName” [email protected]” objUser.Put “givenName”,”Юрій” objUser.Put “sn”Соловйов” objUser.SetInfo()
Створення користувачів за допомогою PowerShell
У Windows Server 2008 R2 з'явилася можливість керувати об'єктами Active Directory засобами Windows PowerShell. Середовище PowerShell вважається найпотужнішою оболонкою командного рядка, розробленої на основі. PowerShell включає понад 150 інструментів командного рядка, званих командлетами, які надають можливість управління комп'ютерами підприємства з командного рядка. Ця оболонка є компонентом операційної системи.
Для створення нового користувача в домені Active Directory використовується командлет New-ADUser, більшість значень властивостей якого можна додавати за допомогою параметрів командлету. Для відображення імені LDAP використовується параметр Path. Цей параметр визначає контейнер або підрозділ (OU) для нового користувача. Якщо параметр Path не заданий, командлет створює об'єкт користувача в контейнері за промовчанням для об'єктів користувача в цьому домені, тобто в контейнері Users. Щоб вказати пароль, використовується параметр –AccountPassword зі значенням (Read-Host -AsSecureString "Пароль для вашого облікового запису"). Також варто обов'язково звернути увагу на те, що значенням параметра – Country є саме код країни або регіону обраної користувачем мови. Синтаксис командлета наступний:
New-ADUser [-Name]
Як видно з даного синтаксису, немає сенсу описувати всі параметри, оскільки вони ідентичні атрибутам принципала безпеки і не потребують пояснення. Подивимося на приклад використання:
New-ADUser -SamAccountName "Evgeniy.Romanov" -Name "Євген Романов" -GivenName "Євген" -Surname "Романов" -DisplayName "Євген Романов" -Path "OU=Маркетинг,OU=Користувачі,DC=testdomain,DC=com -CannotChangePassword $false -ChangePasswordAtLogon $true -City "Херсон" -State "Херсон" -Country UA -Department "Маркетинг" -Title "Маркетолог" -UserPrincipalName "!} [email protected]"-EmailAddress" [email protected]-Enabled $true -AccountPassword (Read-Host -AsSecureString "AccountPassword")
Мал. 10. Створення облікового запису користувача засобами Windows PowerShell
Висновок
У цій статті ви дізналися про принцип безпеки і про те, яку роль відіграють облікові записи користувачів в доменному середовищі. Докладно було розглянуто основні сценарії створення облікових записів користувача в домені Active Directory. Ви навчилися створювати облікові записи користувача за допомогою оснащення «Active Directory – користувачі та комп'ютери», використовуючи шаблони, утиліти командного рядка Dsadd, CSVDE та LDIFDE. Також ви дізналися про метод створення облікових записів користувача за допомогою мови сценаріїв VBScript і оболонки командного рядка Windows PowerShell.
