Удосконалення Active Directory в Windows Server 2008

Розробники операційної системи Windows Server 2008 внесли в служби Active Directory (AD) різноманітні поліпшення. Найпомітніше зміна функціональності AD - новий контролер домену, доступний тільки для читання Read-Only Domain Controller (RODC). Як видно з назви, це нововведення полягає в появі у контролерів домену режиму тільки для читання, в якому на ньому не можна записати зміни в базу даних AD, а реплікація може бути тільки односторонній (з інших DC). Але, на відміну від резервних контролерів домену (BDC) Windows NT Windows Server 4.0, RODC можна налаштувати на зберігання тільки паролів певних користувачів і комп'ютерів. Завдяки цьому обмеження зменшується ризик для всієї мережі в разі успішної атаки проти RODC. Режим RODC операційної системи Windows Server 2008 помітно вплине на методи розгортання і управління DC в офісах філій та по периметру мережі (в демілітаризованій зоні, DMZ) завдяки потенційному скорочення площі атаки і, як наслідок, підвищенню фізичної безпеки.

Перш ніж розглянути RODC, познайомимося з іншими розширеннями функціональності AD в Windows 2008. У статті будуть представлені функціональні рівні AD: домену Domain Functional Level (DFL) і ліси Forest Functional Level (FFL). Знайомство з ними дозволить зрозуміти вимоги до розгортання RODC і інші нові можливості, такі як політики паролів Fine-Grained Password Policies (FGPP) і реплікація DFS для SYSVOL, також описані в статті. Крім того, будуть розглянуті зміни в DNS, завдяки яким служба DNS успішно працює з RODC.

У табл. 1 наведено список важливих удосконалень AD, в тому числі і RODC.

Функціональні рівні AD

Для RODC необхідний принаймні функціональний рівень FFL2 (всі контролери лісу на базі Windows 2003). Щоб зрозуміти сенс цієї вимоги, згадаємо походження функціональних рівнів AD. Функціональні рівні AD були введені в Windows Server 2003, щоб уникнути конфліктів між функціями AD, специфічними для різних версій операційної системи. Такі конфлікти можуть виникати, якщо на контролерах в домені або лісі AD розгорнуті різні версії операційної системи. Функціональні рівні особливо важливі, якщо потрібно внести зміни, які впливають на механізм реплікації AD або інші функції в масштабі домену або лісу, які не підтримуються низькорівневими версіями Windows Server.

Наприклад, якщо ліс Windows 2000 з функціональним рівнем 0 оновлюється до лісу Windows 2003, то після поновлення або заміни всіх доменів DC на контролери домену Windows 2003 функціональний рівень домену DFL можна підвищити до DFL2 (всі контролери домену Windows 2003). Рівень DFL2 дозволяє скористатися такими додатковими функціями, як перейменування DC і запис мітки часу останньої реєстрації користувача. Після того як всі домени лісу переведені на рівень DFL2, можна нарешті підвищити функціональний рівень всього лісу FFL до FFL2 (всі контролери лісу на базі Windows 2003). Серед додаткових можливостей FFL2 - транзитивне довір'я між лісами, перейменування доменів і реплікація пов'язаних значень Linked Value Replication (LVR). LVR - важливе поліпшення для реплікації великих багатозначних атрибутів, таких як членство в групах. Завдяки LVR при внесенні змін (наприклад, додавання або видалення члена групи) в довгий список значень, на інші DC реплицируются тільки ці зміни, а не весь список значень з усіма змінами списку, як на контролерах домену Windows 2000.

Зверніть увагу, що багато нові функції Windows Server 2008 AD не вимагають DFL або FFL, але рівень DFL2 і FFL2 бажаний. Компанія Microsoft постаралася забезпечити впровадження RODC в доменах, що містять контролери домену Windows 2003. В результаті компанії можуть впроваджувати RODC без попереднього оновлення всього домену або лісу. Але, швидше за все, для ефективної спільної роботи контролерів двох версій в одному домені потрібно застосувати програмні виправлення до Windows 2003. Додаткові матеріали про розгортання RODC в ліс, що містить контролери домену Windows Server 2003, перераховані в урізанні «Навчальна література».

При переході на рівень DFL3 (всі контролери домену Windows Server 2008) з'являється чотири нові можливості. Дві з них відображаються на структурі AD: можливість призначати різні політики паролів користувачам в одному домені і задіяти реплікацію DFS для SYSVOL. Жодна нова функція AD НЕ активується після переходу на FFL3 (всі контролери лісу Windows Server 2008), т. Е. Відразу після того, як всі DC лісу починають працювати на базі Windows Server 2008. Однак перехід на FFL3 означає, що всі домени лісу повинні працювати з контролерами Windows Server 2008 і в ліс не можна додати домени або DC зі старими версіями операційних систем. Список нових можливостей AD на різних функціональних рівнях наведено в табл. 2 .

Детальні політики паролів

Для версій операційної системи, що передують Windows Server 2008, в домені AD може існувати тільки одна політика паролів, що застосовується до облікових записів користувачів домену. Політика паролів визначає правила, що стосуються довжини пароля, терміну дії та складності, для кожного облікового запису домену. Ці параметри визначаються об'єктом групової політики (GPO, т. Е. Політикою домену за замовчуванням), тому багато адміністраторів вважали, що можна застосувати кілька політик паролів, просто додаючи об'єкти GPO в різних організаційних одиницях (OU) домену. Однак ці об'єкти GPO застосовні тільки до об'єктів комп'ютера, розміщеним у відповідних OU, і, таким чином, впливають тільки на локальні облікові записи цих комп'ютерів. У багатьох компаніях такий підхід вважають заплутаним і незадовільним.

Це обмеження змінилося з появою детальних політик паролів Fine Grained Password Policies (FGPP) в Windows Server 2008, але тільки якщо все DC в домені працюють з Windows Server 2008 і домен переключено на функціональний рівень DFL3 (всі контролери домену Windows Server 2008). На рівні DFL3 все ж не можна застосовувати різні політики паролів до різних OU, але можна застосувати різні політики паролів безпосередньо до облікового запису користувача або групі. Зверніть увагу, що ці політики також дозволяють встановити різні правила блокування. Наприклад, можна налаштувати особливо захищаються облікові записи на блокування після меншого числа невдалих спроб, ніж облікові записи звичайних користувачів. Щоб зменшити загальні трудовитрати на управління, рекомендується поставити політику на рівні групи, а не на рівні користувача.

Користувачі можуть бути членами багатьох груп, більш ніж однієї з яких може бути призначена політика пароля, тому в Windows Server 2008 AD з'явилася можливість визначити результуючу політику для будь-якого користувача. Якщо користувачеві або групам, членом яких він є, не призначено ніяких політик, застосовується політика домену за замовчуванням. В результаті компанії отримують можливість гнучко призначати політики паролів. Багато організацій пристосувалися до властивого операційним системам, що передує Windows Server 2008, обмеження «одна політика паролів для одного домену», але деяким компаніям доводилося розгортати кілька різних доменів тільки для того, щоб призначити різні політики. Власники Windows Server 2008 можуть вирішити цю проблему за допомогою FGPP. Компанії можуть консолідувати домени, в минулому організовані для різних політик паролів, і позбутися від витрат на обладнання та обслуговування, пов'язаних з додатковими доменами. Більшості компаній повинна сподобатися можливість застосувати більш суворі політики для особливих облікових записів у домені, зокрема адміністративних і використовуваних для обслуговування.

Управління новими політиками здійснюється через об'єкти параметрів пароля Password Settings Object (PSO), створених в контейнері параметрів пароля в системному контейнері домену AD. В даний час компанія Microsoft не надає спеціалізованого графічного інтерфейсу або коштів підготовки сценаріїв для управління об'єктами PSO. ADSI Edit - не найзручніший інструмент для цієї мети, але він встановлюється на кожному DC і з його допомогою не складає труднощів управляти об'єктами PSO. У майбутньому Microsoft може випустити інші інструменти для користувача і нові команди PowerShell, але вже зараз з Internet можна безкоштовно завантажити різні інструменти для управління об'єктами PSO. Додаткові відомості про ці інструменти містяться в матеріалах врізки «Навчальна література».

Створення PSO за допомогою ADSI Edit

За допомогою ADSI Edit можна створювати об'єкти PSO за п'ять кроків.

Переконайтеся, що всі DC в домені працюють з Windows Server 2008 і включений функціональний рівень домену Windows Server 2008 (наприклад, з оснащення AD Users and Computers консолі MMC).
Запустіть Adsiedit.msc і підключіться до контексту іменування за замовчуванням (DC =), потім перейдіть до контейнера CN = Password Settings Container, CN = System, DC =.
Клацніть правою кнопкою миші на об'єкті Password Settings Container і виберіть пункти New, Object.
Використовуйте майстер Create Object, щоб створити новий об'єкт msDS-PasswordSettings. Створіть об'єкт зі значеннями атрибутів, показаних в табл. 3 . Отриманий новий об'єкт параметрів пароля, My-Windows ServerAdmin-PSO (поряд з іншими параметрами), вимагає, щоб зазначені користувачі вводили 15-символьний пароль, який потрібно міняти через кожні 30 днів. Об'єкт PSO вступає в силу після того, як буде застосований до об'єктів користувачів і груп (на наступному етапі).
Застосуйте новостворений об'єкт PSO, переглядаючи властивості об'єкта My-Windows ServerAdmin-PSO в програмі ADSI Edit і змінюючи атрибут msDS-PSOAppliesTo. Введіть облікові записи користувачів або групи (членами яких повинні бути користувачі), щоб застосувати політику до цільових користувачам. Наприклад, я створив групу з ім'ям My-Windows ServerAdmins.

Застосування реплікації DFS для SYSVOL

Важливим поліпшенням Windows Server 2003 R2 була нова служба реплікації файлів. Служба реплікації під назвою DFS Replication (DFSR) більш вдало, ніж попередній варіант, інтегрована з DFS. Важливим нововведенням виявилася можливість обмежити трафік реплікації між двома копіями DFS тільки змінами файлів. Якщо у файлі розміром в декілька мегабайт змінилося лише кілька байтів, технологія DFSR забезпечує пересилку численним партнерам по реплікації лише змінених байтів. Раніше при використанні системи NT File Replication System (NTFRS) будь-які зміни в файлі (в тому числі зміна атрибутів, таких як дозволу NTFS) приводили до реплікації всього файлу. У Windows Server 2008 реплікація DFS стала ще більш масштабованої, зокрема збільшилася кількість паралельних потоків реплікації файлів і усунутий поріг 5000 цільових об'єктів DFS для кореневих елементів DFS, інтегрованих з AD. Відтепер кореневі елементи DFS можуть мати необмежену кількість цільових об'єктів DFS.

З моменту появи DFSR в Windows 2003 R2 адміністратори AD сподівалися використовувати нову службу для SYSVOL після оновлення всіх DC до Windows 2003 R2. Однак це було неможливо; доводилося як і раніше використовувати неефективний механізм NTFRS для реплікації змін групової політики і вмісту папки сценаріїв (загальний каталог NETLOGON). Неефективність NTFRS була однією з причин, за якими архітектори AD іноді проектують багатодоменному лісу, щоб скоротити трафік NTFRS, якщо у великій компанії багато повільних мережевих з'єднань, через які необхідно реплицировать дані з контролерів домену.

У Windows Server 2008 технологію DFSR нарешті можна застосувати для реплікації SYSVOL між контролерами домена. Все DC в домені повинні працювати з Windows Server 2008 і домен повинен бути переведений на функціональний рівень DFL3 (всі контролери домену Windows Server 2008). Однак, на відміну від деяких інших функцій, що відносяться до реплікації, при переході на DFL3 метод реплікації SYSVOL не змінюється автоматично з NTFRS на DFSR. В результаті досить громіздкої процедури, в якій використовується нова утиліта DfsrMig.exe, наявна на кожному DC, вдається створити новий кореневий елемент DFS для вмісту SYSVOL. Новий кореневої елемент задіє DFSR, а власне SYSVOL як і раніше використовує NTFRS. В ході міграції початкове вміст SYSVOL копіюється в нову папку SYSVOL, іменовану за замовчуванням SYSVOL_DFSR.

Після перемикання на рівень DFL3 і переходу на технологію DFSR для SYSVOL загальний каталог SYSVOL буде використовувати нову папку SYSVOL_DFSR. З цього моменту вміст загального каталогу SYSVOL буде реплицироваться набагато ефективніше. Якщо планується новий ліс AD, то неефективна реплікація більше не буде причиною для проектування лісу з декількома доменами.

зміни DNS

В одній статті важко охопити всі зміни DNS в Windows Server 2008. Взагалі потрібно знати, що в оновленій службі DNS допускаються зони тільки для читання, необхідні для служби DNS з роллю RODC. Нові зони тільки для читання аналогічні вторинним зонам DNS, але зони тільки для читання інтегровані в AD і можуть розміщуватися на RODC. Як можна здогадатися, зона DNS тільки для читання не приймає динамічних оновлень від клієнтів. Тому спеціальний механізм для контролерів RODC направляє клієнтів на найближчий сервер DNS з можливістю запису для динамічної реєстрації в DNS і запитів поновлення. Через п'ять хвилин після того, як клієнт отримає повідомлення, на якому сервері належить оновити інформацію DNS, служба DNS контролера RODC спробує підключитися до цього сервера DNS для миттєвої реплікації змін DNS у власну базу даних.

Завдяки іншому нововведенню DNS, які можуть застосовуватися до AD, клієнти можуть виявляти контролери домену на найближчому сайті, якщо не вдається підключитися до DC у власному сайті. Це дозволяє уникнути з'єднань з віддаленими DC по потенційно повільним лініях під час аварійного перемикання. Нова можливість клієнтів DNS в операційних системах Windows Vista і Windows Server 2008 грунтується на інформації про топології сайтів і вартості зв'язків між сайтами, що зберігається в AD для визначення найближчого сайту перед направленням в DNS запиту про надання адреси DC у відповідному сайті. Ця функція була внесена в новітній пакет поновлення для Windows XP. Її можна активувати через об'єкт групової політики GPO.

Шлях до нього: Computer Configuration Administrative Templates SystemNet LogonDC LocatorDNS Records

Включити параметри Try next closest site

Основні переваги RODC

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

За винятком спеціальних ролей господарів операцій, таких як Schema Master і PDC-емулятора, все контролери домену, що передують Windows Server 2008, в основному рівноцінні. Адміністратори будь-якого DC Windows 2000 або Windows 2003 можуть записати зміни в базу даних AD і реплицировать ці зміни в інші DC того ж домена або лісу AD. Тому зміни, внесені в один DC, можуть впливати на весь домен або навіть цілий ліс. Зловмисник з фізичним доступом до DC, наприклад в офісі філії, може без праці зробити атаку з підвищенням прав, змінивши або навіть знищивши весь ліс AD і залежні служби.

Малюнок 1. Контролери домену офісу філії Windows 2000/2003 можуть завдати шкоди всьому лісі AD

Як показано на Мал. 1 , Виконане зловмисником зміна крайнього правого DC офісу філії реплицируется на центральний DC, а потім на всі інші DC підприємства. Більш того, оскільки всі DC завжди копіюють повний розділ домену AD, в тому числі паролі всіх користувачів і адміністраторів в цьому домені, наявність ураженого DC дозволяє зловмисникові провести атаку з відгадуванням пароля на базу даних AD контролера домену та створює умови для додаткових віддалених атак.

Windows Server 2008 RODC спроектований спеціально для того, щоб знизити ризик «викрадення» DC. RODC можна використовувати в місцях, які фізично захищені не так добре, як інформаційний центр компанії, але вимагають швидкої і надійної перевірки автентичності, навіть якщо відсутня мережеве з'єднання з інформаційним центром. Компаніям, яким необхідна перевірка справжності такої якості в офісі філії, більше не була необхідною розгортати звичайні DC з можливістю запису в таких місцях. Тепер у компаній є можливість розгорнути контролери RODC, які за умовчанням не реплікують локальні зміни на всі інші DC. У контролерів RODC є угода про односторонню реплікації з партнерським DC. Різні зміни в базовій архітектурі реплікації Windows Server 2008 забезпечують незмінність цієї угоди. Наприклад, контролери RODC не є членами групи безпеки Enterprise Domain Controllers, яка дає DC з можливістю запису різні дозволи на запис в базу даних AD.

Політики паролів реплікації Password Replication Policies (PRP) визначаються, Які паролі реплицируются в RODC. Ключовий проблема управління RODC - візначіті, як налаштуваті політики PRP. Управління політікамі PRP віконується окремо для кожного RODC; PRP містить список облікових записів груп, користувачів або комп'ютерів, яким надано право (або відмовлено в дозволі) кешувати паролі на RODC. Політики PRP зберігаються в об'єкті облікового запису комп'ютера відповідного RODC в AD, як показано на екрані 1.

Розгортання контролерів RODC - надзвичайно зручний спосіб підвищити безпеку в офісах філій та демілітаризованій зоні (DMZ). Як показано на Мал. 2 , В інфраструктурі Windows Server 2008 AD контролери домену з можливістю запису розміщуються тільки в повністю довірених мережах (центрах обробки даних). RODC можна безпечно розміщувати в периферійних мережах. В результаті атака на інфраструктуру AD, показана на рис. 1, обмежена RODC в офісі філії. А оскільки RODC за замовчуванням не зберігає ніяких секретних даних адміністратора (паролів) і зазвичай кешируєт тільки паролі користувачів сайту RODC, компанія піддається меншій небезпеці при ураженні RODC, ніж повноцінного записуючого DC.

Малюнок 2. Використання Windows Server 2008 AD для розміщення DC з можливістю запису тільки в довіреної мережі

RODC також може бути глобальним каталогом тільки для читання Read-Only Global Catalog (ROGC). Але, хоча каталоги ROGC можна використовувати в якості серверів з адресними списками GAL для клієнтів Outlook, вони не можуть бути глобальними каталогами для серверів Exchange. Це не пройде без наслідків для адміністраторів, які бажають розгорнути RODC в офісі філії і зберегти локальний сервер Exchange.

З точки зору функціональності RODC можна порівняти з сервером-посередником. Якщо користувач пройшов перевірку автентичності в сайті з RODC, то клієнтська система користувача виявить цей RODC, як будь-який інший DC, і спробує пройти перевірку справжності в RODC. Клієнтським системам зазвичай невідомо, чи мають вони справу з записуючим DC або з RODC, так як RODC отримує всі необхідні дані від імені клієнта. Коли клієнт вперше проходить перевірку автентичності на даному RODC, останній повинен зв'язатися з DC з можливістю запису (зазвичай по каналу WAN з DC центрального сайту) і перевірити користувача на цьому DC. Якщо контролера RODC дозволено кешувати хеш пароля користувача, як визначено в політиках PRP контролера RODC, то наступного разу RODC зможе повністю аутентифицировать користувача, не звертаючись до DC з можливістю запису.

У RODC є й інші переваги, які відрізняють його від DC з можливістю запису: наприклад, можна делегувати права (або інші ролі) локального адміністратора користувачам або групам домену конкретного RODC, котрі дають користувачам спеціальних прав у власному домені AD. Це досягається за допомогою атрибута managedBy об'єкта комп'ютера RODC або призначенням локальних ролей за допомогою утиліти NTDSUTIL. В результаті не потрібно використовувати доменну обліковий запис адміністратора для задач обслуговування DC в офісі філії, які можуть бути виконані користувачами з низькими правами. До них відноситься і задача підвищення рівня нових DC. Ця можливість обмежена контролерами RODC.

подальше вивчення

В даному огляді представлено декілька важливих поліпшень AD, які з'явилися в Windows Server 2008. Очевидно, що програмісти Microsoft витратили багато зусиль на проектування RODC. У цьому можна переконатися, поглянувши на зміни в базовій архітектурі реплікації, які довелося зробити для RODC. У матеріалах врізки «Навчальна література» міститься додаткова інформація про поліпшення в AD і RODC.

Гвідо Грілленмейер ( [email protected] ) - головний спеціаліст з технологій в підрозділі Advanced Technology Group компанії Hewlett-Packard. MVP по Microsoft Directory Services і Microsoft Certified Architect

Редакції Windows Server 2008 для RODC

Режим RODC передбачений у всіх версіях x86 (32-розрядна) і x64 Windows Server 2008 (Standard, Enterprise і Datacenter). Але, оскільки версія Windows Server 2008 Itanium не підтримує служби AD Domain Services, в ній немає і RODC. У всіх версіях Windows Server 2008 можна розгорнути RODC в режимі Windows Server Core.

Таблиця 2. Нові функції AD по функціональним рівням

Таблиця 3. Значення атрибутів параметрів паролів

Зміна імен служб AD в Windows Server 2008

Буде потрібно час, щоб звикнути до одного невеликого, але важливого зміни Active Directory (AD) в Windows Server 2008. Щоб краще розрізняти версії AD, в Windows Server 2008 введені нові імена для основних служб. Ці імена наведені в таблиці.

Навчальна література

ресурси MICROSOFT

AD DS: Read-Only Domain Controllers
technet2.microsoft.com/windowsWindowsServer2008/en/ library / ce82863f-9303-444f-9bb3-ecaf649bd3dd1033.mspx? mfr = true

Domain Controllers Running Windows Server 2003 Perform Automatic Site Coverage for Sites with RODCs
technet2.microsoft.com/windowsWindowsServer2008/en/ library / c0ec828b-7da2-4627-91a8-2a5312a3ceaa1033.mspx? mfr = true

Identity and Access in Windows Server 2008
microsoft.com/windowsWindowsServer2008/ida-mw.mspx

Manage Windows Server 2008 DNS role
forums.microsoft.com/TechNet/ ShowPost.aspx? PostID = 1916586 & SiteID = 17 & pageid = 0

RODC Features
technet2.microsoft.com/windowsWindowsServer2008/en/ library / 0e8e874f-3ef4-43e6-b496-302a47101e611033.mspx? mfr = true

RODC Frequently Asked Questions
technet2.microsoft.com/windowsWindowsServer2008/en/ library / e41e0d2f-9527-4eaf-b933-84f7d3b2c94a1033.mspx? mfr = true

Інструменти для управління PSO

ADSIedit Overview
technet2.microsoft.com/WindowsWindowsServer/en/ library / ebca3324-5427-471a-bc19-9aa1decd3d401033.mspx? mfr = true

PSOMgr
joeware.net/freetools/tools/psomgr/

View a Resultant PSO for a User or a Global Security Group (команда desget з ключем pso)
technet2.microsoft.com/windowsWindowsServer2008/en/ library / 21a35cbb-398d-4ab4-a6f8-39b76fb0323b1033.mspx? mfr = true

Таблиця 1. Удосконалення в AD Windows Server 2008

Можливості Windows Server 2008 для AD

описи

вимоги

RODC

DC, яка не реплицирует зміни на інші DC, за замовчуванням не зберігає ніяких паролів і не допускає змін в локальній базі даних AD

Функціональний рівень лісу FFL2 (Windows Server 2003) і господар операцій PDC з операційною системою Windows 2003 SP2 і більш пізньої. Господар операцій головного DC повинен працювати на Windows Server 2008 або Windows 2003 SP2 для перекладу на новий RODC

Відділення ролі адміністратора

Дозволено надати користувачам, які не є адміністраторами домену, ролі локального адміністратора на конкретному RODC

Операційна система DC повинна бути Windows Server 2008. Працює тільки з RODC, але не з DC з можливістю запису

Перезапускати служба AD DS

Служба AD Domain Services може бути зупинена при працюючому DC без необхідності завантажувати сервер в режимі Directory Services (DS) Restore Mode. Зокрема, це дозволяє виконати автономну дефрагментацію бази даних AD без перезапуску сервера. Не дозволяє відновити базу даних AD