Active Directory

Active Directory(«Активні директорії», AD) - LDAP-сумісна реалізація служби каталогів корпорації Microsoftдля операційних систем сімейства Windows NT. Active Directoryдозволяє адміністраторам використовувати групові політики для забезпечення однаковості налаштування користувача робочого середовища, розгортати програмне забезпечення на безлічі комп'ютерів через групові політики або за допомогою System Center Configuration Manager(раніше Microsoft Systems Management Server), встановлювати оновлення операційної системи, прикладного та серверного програмного забезпечення на всіх комп'ютерах у мережі, використовуючи Службу оновлення Windows Server . Active Directoryзберігає дані та налаштування середовища в централізованій базі даних. Мережі Active Directoryможуть бути різного розміру: від кількох десятків до кількох мільйонів об'єктів.

Подання Active Directoryвідбулося в 1999 році, продукт був вперше випущений з Windows 2000 Server, а потім був модифікований та покращений при випуску Windows Server 2003. Згодом Active Directoryбув покращений у Windows Server 2003 R2, Windows Server 2008і Windows Server 2008 R2і перейменований на Active Directory Domain Services. Раніше служба каталогів називалася NT Directory Service (NTDS), цю назву досі можна зустріти в деяких файлах .

На відміну від версій Windowsдо Windows 2000, які використовували в основному протокол NetBIOSдля мережевої взаємодії, служба Active Directoryінтегрована з DNSі TCP/IP. Для стандартної аутентифікації використовується протокол Kerberos. Якщо клієнт або програма не підтримує автентифікацію Kerberos, використовується протокол NTLM .

Пристрій

Об'єкти

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

Об'єкти можуть бути вмістищами для інших об'єктів (групи безпеки та розповсюдження). Об'єкт унікально визначається своїм ім'ям та має набір атрибутів - характеристик та даних, які він може містити; останні, своєю чергою, залежить від типу об'єкта. Атрибути є складовою базою структури об'єкта та визначаються у схемі. Схема визначає, які типи об'єктів можуть існувати.

Сама схема складається із двох типів об'єктів: об'єкти класів схеми та об'єкти атрибутів схеми. Один об'єкт класу схеми визначає один тип об'єкта Active Directory(наприклад, об'єкт «Користувач»), а один об'єкт атрибуту схеми визначає атрибут, який може мати об'єкт.

Кожен об'єкт атрибута може бути використаний у різних об'єктах класів схеми. Ці об'єкти називаються об'єктами схеми (або метаданими) і дозволяють змінювати та доповнювати схему, коли це необхідно. Однак кожен об'єкт схеми є частиною визначень об'єктів Active Directoryтому відключення або зміна цих об'єктів можуть мати серйозні наслідки, оскільки в результаті цих дій буде змінена структура Active Directory. Зміна об'єкта схеми автоматично поширюється на Active Directory. Будучи одного разу створеним, об'єкт схеми не може бути вилучений, він може бути лише вимкнений. Зазвичай усі зміни схеми ретельно плануються.

Контейнераналогічний об'єктуу тому сенсі, що він також має атрибути і належить простору імен , але, на відміну об'єкта, контейнер не означає нічого конкретного: може містити групу об'єктів чи інші контейнери.

Структура

Верхнім рівнем структури є ліс - сукупність всіх об'єктів, атрибутів та правил (синтаксису атрибутів) у Active Directory. Ліс містить одне або кілька дерев, пов'язаних транзитивними відносинами довіри . Дерево містить один або кілька доменів, також пов'язаних з ієрархією транзитивними відносинами довіри. Домени ідентифікуються своїми структурами імен DNS – просторами імен.

Об'єкти в домені можуть бути згруповані у контейнери – підрозділи. Підрозділи дозволяють створювати ієрархію всередині домену, спрощують його адміністрування та дозволяють моделювати організаційну та/або географічну структури компанії в Active Directory. Підрозділи можуть утримувати інші підрозділи. Корпорація Microsoftрекомендує використовувати якнайменше доменів у Active Directory, а для структурування та політик використовувати підрозділи. Часто групові політики застосовують саме до підрозділів. Групові політики є об'єктами. Підрозділ є самим низьким рівнем, де можуть делегуватися адміністративні повноваження .

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

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

Фізична структура та реплікація

Фізично інформація зберігається на одному або кількох рівнозначних контролерах доменів, що замінили використовувані в Windows NTосновний та резервні контролери домену, хоча для виконання деяких операцій зберігається і так званий сервер «операцій з одним головним сервером», який може емулювати головний контролер домену. Кожен контролер домену зберігає копію даних, призначену для читання та запису. Зміни, зроблені однією контролері, синхронізуються попри всі контролери домену при реплікації . Сервери, на яких сама служба Active Directoryне встановлено, але які при цьому входять до домену Active Directory, Називаються рядовими серверами.

Реплікація Active Directoryвиконується на запит. Служба Knowledge Consistency Checkerстворює топологію реплікації, яка використовує сайти, визначені у системі, керувати трафіком. Внутрішньосайтова реплікація виконується часто та автоматично за допомогою засобу перевірки узгодженості (повідомленням партнерів щодо реплікації про зміни). Реплікація між сайтами може бути налаштована для кожного каналу сайту (залежно від якості каналу) - різна оцінка (або вартість) може бути призначена кожному каналу (наприклад DS3, , ISDNі т. д.), і трафік реплікації буде обмежений, передаватися за розкладом та маршрутизуватися відповідно до призначеної оцінки каналу. Дані реплікації можуть транзитивно передаватися через декілька сайтів через мости зв'язку сайтів, якщо «оцінка» низька, хоча AD автоматично призначає більше низьку оцінкудля зв'язків сайт-сайт, ніж для транзитивних з'єднань. Реплікація сайт-сайт виконується серверами-плацдармами на кожному сайті, які потім реплікують зміни на кожен контролер домену свого сайту. Внутрішньодоменна реплікація відбувається за протоколом RPCза протоколом IP, міждоменна - може використовувати також протокол SMTP.

Якщо структура Active Directoryмістить кілька доменів, для вирішення задачі пошуку об'єктів використовується глобальний каталог: контролер домену, що містить усі об'єкти лісу, але з обмеженим набором атрибутів (неповна репліка). Каталог зберігається на вказаних серверах глобального каталогу та обслуговує міждоменні запити.

Можливість операцій з одним комп'ютером дозволяє обробляти запити, коли реплікація з кількома комп'ютерами неприпустима. Є п'ять типів таких операцій: емуляція головного контролера домену (PDC-емулятор), головний комп'ютервідносного ідентифікатора (майстер відносних ідентифікаторів або RID-майстер), головний комп'ютер інфраструктури (майстер інфраструктури), головний комп'ютер схеми (майстер схеми) та головний комп'ютер найменування домену (майстер іменування доменів). Перші три ролі унікальні у межах домену, останні дві – унікальні у межах всього лісу.

Базу Active Directoryможна поділити на три логічні сховища або "розділу". Схема є шаблоном для Active Directoryі визначає всі типи об'єктів, їх класи та атрибути, синтаксис атрибутів (всі дерева знаходяться в одному лісі, тому що вони мають одну схему). Конфігурація є структурою лісу та дерев Active Directory. Домен зберігає всю інформацію про об'єкти, створені в цьому домені. Перші два сховища реплікуються на всі контролери доменів у лісі, третій розділ повністю реплікується між репліками контролерів у межах кожного домену та частково – на сервері глобального каталогу.

Найменування

Active Directoryпідтримує такі формати іменування об'єктів: універсальні імена типу UNC, URLі LDAP URL. Версія LDAPформату іменування X.500 використовується всередині Active Directory.

Кожен об'єкт має ім'я, що різниться (англ. distinguished name, DN). Наприклад, об'єкт принтера з ім'ям HPLaser3у підрозділі «Маркетинг» і в домені foo.org матиме наступне ім'я, що розрізняється: CN=HPLaser3,OU=Маркетинг,DC=foo,DC=org , де CN - це спільне ім'я, OU - розділ, DC - клас об'єкта домену. Різні імена можуть мати набагато більше частин, ніж чотири частини в цьому прикладі. Об'єкти також мають канонічні імена. Це різні імена, записані у зворотному порядку, без ідентифікаторів і з використанням косих характеристик як роздільників: foo.org/Маркетинг/HPLaser3 . Щоб визначити об'єкт усередині його контейнера, використовується відносне різне ім'я : CN = HPLaser3. Кожен об'єкт також має глобально унікальний ідентифікатор ( GUID) - унікальний і незмінний 128-бітний рядок, який використовується в Active Directoryдля пошуку та реплікації. Певні об'єкти також мають ім'я учасника-користувача ( UPN, відповідно до RFC 822) у форматі объект@домен.

Інтеграція з UNIX

Різні рівні взаємодії з Active Directoryможуть бути реалізовані в більшості UNIX-подібних операційних систем за допомогою відповідних стандартів LDAPклієнтів, але такі системи, як правило, не сприймають більшу частину атрибутів, асоційованих з компонентами Windows, наприклад групові політики та підтримку односторонніх довіреностей.

Сторонні постачальники пропонують інтеграцію Active Directoryна платформах UNIX, включаючи UNIX, Linux, Mac OS Xта ряд додатків на базі Java, з пакетом продуктів:

Додавання до схеми, що постачаються з Windows Server 2003 R2включають атрибути, які досить тісно пов'язані з RFC 2307 щоб використовуватися в загальному випадку. Базові реалізації RFC 2307, nss_ldap та pam_ldap, запропоновані PADL.comбезпосередньо підтримують ці атрибути. Стандартна схема для членства групи відповідає RFC 2307bis (пропонованого) . Windows Server 2003 R2включає Консоль керування Microsoft для створення та редагування атрибутів.

Альтернативним варіантом є використання іншої служби каталогів, наприклад 389 Directory Server(раніше Fedora Directory Server, FDS), eB2Bcom ViewDS v7.1 XML Enabled Directoryабо Sun Java System Directory Serverвід Sun Microsystems, що виконує двосторонню синхронізацію з Active Directoryреалізуючи таким чином «відбиту» інтеграцію, коли клієнти UNIXі Linuxаутентифікуються FDS, а клієнти Windowsаутентифікуються Active Directory. Іншим варіантом є використання OpenLDAPз можливістю напівпрозорого перекриття, що розширює елементи віддаленого сервера LDAPдодатковими атрибутами, що зберігаються в локальній базіданих.

Active Directoryавтоматизуються за допомогою Powershell .

Література

• Ренд Морімото, Кентон Гардіньєр, Майкл Ноел, Джо Кока Microsoft Exchange Server 2003. Повне керівництво = Microsoft Exchange Server 2003 Unleashed. – М.: «Вільямс», 2006. – С. 1024. – ISBN 0-672-32581-0

Див. також

Посилання

Примітки

Компоненти Microsoft Windows
Основні
Служби управління
Програми	Контакти DVD Maker Факси та сканування Internet ExplorerЖурнал Екранна лупа Media Center Медіапрогравач Windows Програма спільної роботи Центр пристроїв Windows Mobile Центр мобільності Екранний диктор Paint Редактор особистих символів Віддалений помічник Розпізнавання мови WordPad Блокнот Бічна панель ЗвукозаписКалендар Калькулятор Ножиці Пошта Таблиця символів Історичні: Movie Maker NetMeeting Outlook Express Диспетчер програм Диспетчер файлів Фотоальбом
Ігри
Ядро ОС
Служби
Файлові системи
Сервер	Active Directory Служби розгортання Служба реплікації файлів DNS Домени Перенаправлення папок Hyper-V IIS Media Services MSMQ Захист доступу до мережі (NAP) Служби друку для UNIX Віддалений різницевий стиск Служби віддаленої установки Служба управління правами Профілі користувачів, що переміщуються SharePoint Диспетчер системних ресурсів Видаленний робочий стіл WSUS Групова політика Координатор розподілених транзакцій
Архітектура
Безпека
Сумісність

Microsoft
ПЗ
Серверне ПЗ
Технології
Інтернет
Ігри
Апаратне забезпечення
Освіта
Ліцензування
Підрозділи

Групова політика - це ієрархічна інфраструктура, яка дозволяє мережному адміністратору, що відповідає за 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). Шаблон групової політики відповідає за збереження певних параметрів, створених в об'єкті групової політики, та має важливе значеннядля його успіху. Він зберігає ці налаштування у великій структурі папок та файлів. Щоб налаштування успішно застосовувалися до всіх об'єктів користувача та комп'ютера, 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 таким чином, щоб не доводилося заповнювати поле «Description». Наприклад, з назви групи GPCP_Restricted_Groups зрозуміло, що це група політики, яка застосовується для комп'ютерів і виконує роботу механізму Restricted Groups.
Ваш підхід до написання документації має бути дуже ґрунтовним, це дозволить заощадити велику кількість часу надалі.

Спрощуйте все, що можливо, намагайтеся досягти рівноваги
При побудові 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).

Поле Surname обох типів адміністративних облікових записів слід починати з літери I (Наприклад, iPetrov P Vasily)
Поясню, навіщо слід розділяти адміністративні облікові записи на адміністраторів серверів та адміністраторів клієнтських комп'ютерів. Робити це необхідно, з міркувань безпеки. Адміністратори клієнтських комп'ютерів матимуть право встановити софт на клієнтських комп'ютерах. Який і для чого софт встановлюватиметься, сказати ніколи точно не можна. Тому запускати інсталяцію програми з правами доменного адміністратора небезпечно, можна скомпрометувати весь домен. Необхідно адмініструвати клієнтські комп'ютери лише з правами локального адміністратора цього комп'ютера. Це унеможливить цілу низку атак на акаунти доменних адміністраторів, на кшталт «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

Аудит необхідно конфіругувати у розділі Advanced Audit Policy Configurationі обов'язково включити налаштування в розділі Local Policy/Security Options - Force audit policy subcategory settings ( Windows Vista or later) до override audit policy category settings, яка скасує налаштування верхнього рівня та застосує розширені.

Розширені налаштування аудиту

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

Скрипти адміністрування та прибирання
Усі однотипні та часто повторювані дії необхідно виконувати за допомогою скриптів адміністрування. Серед таких дій: створення облікових записів користувачів, створення облікових записів адміністраторів, створення груп, створення 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 (AD) - це службові програми, розроблені для операційної системи Microsoft Server. Спочатку створювалася як полегшений алгоритм доступу до каталогів користувачів. З версії Windows Server 2008 з'явилася інтеграція із сервісами авторизації.

Дозволяє дотримуватися групової політики, що застосовує однотипність параметрів та ПЗ на всіх підконтрольних ПК за допомогою System Center Configuration Manager.

Якщо простими словами для початківців – це роль сервера, яка дозволяє з одного місця керувати всіма доступами та дозволами у локальній мережі

Функції та призначення

Microsoft Active Directory - (так званий каталог) пакет засобів, що дозволяє проводити маніпуляції з користувачами та даними мережі. основна цільстворення – полегшення роботи системних адміністраторів у великих мережах.

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

Основні поняття, що зустрічаються під час роботи

Існує ряд спеціалізованих понять, які застосовуються під час роботи з AD:

1. Сервер – комп'ютер, що містить усі дані.
2. Контролер – сервер із участю AD, який обробляє запити від людей, які використовують домен.
3. Домен AD - сукупність пристроїв, об'єднаних під одним унікальним ім'ям, що одночасно використовують загальну базуданих каталогу.
4. Сховище даних — частина каталогу, що відповідає за зберігання та вилучення даних із будь-якого контролера домену.

Як працюють активні директорії

Основними принципами роботи є:

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

Об'єкти та атрибути

Об'єкт - сукупність атрибутів, об'єднаних під власною назвою, що є ресурсом мережі.

Атрибут - характеристики об'єкта в каталозі. Наприклад, до таких відносяться ПІБ користувача, його логін. А ось атрибутами облікового запису ПК можуть бути ім'я цього комп'ютера та його опис.

“Співробітник” – об'єкт, який має атрибути “ПІБ”, “Посада” та “ТабN”.

Контейнер та ім'я LDAP

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

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

Багато контейнерів відображають сукупність об'єктів, а ресурси відображаються унікальним об'єктом Active Directory. Один з головних видів контейнерів AD – модуль організації, або OU (organizational unit). Об'єкти, які містяться в контейнері, належать лише домену, в якому вони створені.

Полегшений протокол доступу до каталогів (Lightweight Directory Access Protocol, LDAP) – основний алгоритм підключень TCP/IP. Він створений з метою зниження кількості нюансів під час доступу до служб каталогу. Також, в LDAP встановлено дії, що використовуються для запиту та редагування даних каталогу.

Дерево та сайт

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

Ліс доменів – сукупність дерев, пов'язаних між собою.

Сайт - сукупність пристроїв в IP-підмережах, що представляє фізичну модельмережі, планування якої відбувається незалежно від логічного уявлення його побудови. Active Directory має можливість створення n-ної кількості сайтів або об'єднання n-ної кількості доменів під одним сайтом.

Встановлення та налаштування Active Directory

Тепер перейдемо безпосередньо до налаштування Active Directory на прикладі Windows Server 2008 (на інших версіях процедура ідентична):

Натиснути кнопку “ОК”. Варто зауважити, що подібні значенняне є обов'язковими. Можна використовувати IP-адресу та DNS зі своєї мережі.

• Далі потрібно зайти в меню "Пуск", вибрати "Адміністрування" та "".
  
• Перейти до пункту “Ролі”, вибрати поле “ Додати ролі”.
  
• Вибрати пункт “ Доменні служби Active Directory” двічі натиснути “Далі”, а потім “Встановити”.
  
• Дочекайтеся закінчення установки.
  
• Відкрити меню “Пуск”-“ Виконати”. У полі введіть dcpromo.exe.
  
• Натисніть "Далі".
  
• Вибрати пункт “ Створити новий домен у новому лісі” і знову натиснути “Далі”.
  
• У наступному вікні ввести назву, натиснути "Далі".
  
• Вибрати режим сумісності(Windows Server 2008).
  
• У наступному вікні залишити все за замовчуванням.
  
• Запуститься вікно конфігураціїDNS. Оскільки на сервері він не використовувався до цього, делегування не було створено.
  
• Вибрати директорію для встановлення.
  
• Після цього кроку потрібно задати пароль адміністрування.

Для надійності пароль повинен відповідати таким вимогам:

Після того, як AD завершить процес налаштування компонентів, необхідно перезавантажити сервер.

Налаштування завершено, оснащення та роль встановлені в систему. Встановити AD можна лише на Windows сімейства Server, звичайні версії, наприклад 7 або 10, можуть дозволити встановити лише консоль керування.

Адміністрація в Active Directory

За промовчанням у Windows Server консоль Active Directory Users and Computers працює з доменом, до якого належить комп'ютер. Можна отримати доступ до об'єктів комп'ютерів та користувачів у цьому домені через дерево консолі або підключитися до іншого контролера.

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

До речі, існує 2 типи групв Актив Директори – безпеки та розповсюдження. Групи безпеки відповідають за розмежування прав доступу до об'єктів, вони можуть використовуватися як групи розповсюдження.

Групи розповсюдження не можуть розмежовувати права, а використовуються переважно для розсилки повідомлень у мережі.

Що таке делегування AD

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

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

Встановлення довірчих відносин

У AD є два види довірчих відносин: «односпрямовані» та «двоспрямовані». У першому випадку один домен довіряє іншому, але з навпаки, відповідно перший має доступом до ресурсів другого, а другий немає доступу. У другому вигляді довіра "взаємна". Також існують «вихідні» та «вхідні» відносини. У вихідних – перший домен довіряє другому, дозволяючи користувачам другого використовувати ресурси першого.

Під час встановлення слід провести такі процедури:

• Перевіритимережеві зв'язки між котролерами.
• Перевірити налаштування.
• Налаштуватидозволу імен для зовнішніх доменів.
• Створити зв'язокз боку довіряючого домену.
• Створити зв'язок із боку контролера, якого адресовано довіру.
• Перевірити створені односторонні відносини.
• Якщо виникає потребау встановленні двосторонніх відносин – провести встановлення.

Глобальний каталог

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

Глобальний каталог (ГК) включає обмежений набір атрибутів для кожного об'єкта лісу в кожному домені. Дані він отримує з усіх розділів каталогу доменів у лісі, вони копіюються з використанням стандартного процесуреплікації служби Active Directory.

Схема визначає, чи буде скопійовано атрибут. Існує можливість конфігурування додаткових характеристик , які будуть створюватися повторно у глобальному каталозі за допомогою “Схеми Active Directory”. Щоб додати атрибут у глобальний каталог, потрібно вибрати атрибут реплікації та скористатися опцією "Копіювати". Після цього створиться реплікація атрибуту до глобального каталогу. Значення параметра атрибута isMemberOfPartialAttributeSetстане істиною.

Для того щоб дізнатися про місце розташуванняглобального каталогу, потрібно в командному рядку ввести:

Dsquery server –isgc

Реплікація даних у Active Directory

Реплікація — це процедура копіювання, яку проводять у разі необхідності зберігання однаково актуальних відомостей, що існують на будь-якому контролері.

Вона виробляється без участі оператора. Існують такі види вмісту реплік:

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

Основними типами реплік є внутрішньовузлова та міжвузлова.

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

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

Основним компонентом доменних служб у кожній організації є принципали безпеки (оригінальна назва - 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] [-AccountExpirationDate ] [-AccountNotDelegated ] [-AccountPassword ] [-AllowReversiblePasswordEncryption ] [-AuthType (Negotiate | Basic)] [-CannotChangePassword ] [-Certificates ] [-ChangePasswordAtLogon ] [-City ] [-Company ] [-Country ] [-Credential ] [-Department ] [-Description ] [-DisplayName ] [-Division ] [-EmailAddress ] [-EmployeeID ] [-EmployeeNumber ] [-Enabled ] [-Fax ] [-GivenName ] [-HomeDirectory ] [-HomeDrive ] [-HomePage ] [-HomePhone ] [-Initials ] [-Instance ] [-LogonWorkstations ] [-Manager ] [-MobilePhone ] [-Office ] [-OfficePhone ] [-Organization ] [-OtherAttributes ] [-OtherName ] [-PassThru ] [-PasswordNeverExpires ] [-PasswordNotRequired ] [-Path ] [-POBox ] [-PostalCode ] [-ProfilePath ] [-SamAccountName ] [-ScriptPath ] [-Server ] [-ServicePrincipalNames ] [-SmartcardLogonRequired ] [-State ] [-StreetAddress ] [-Surname ] [-Title ] [-TrustedForDelegation ] [-Type ] [-UserPrincipalName ] [-Confirm] [-WhatIf] [ ]

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

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.