1. Аудит облікових записів, об'єктів групових політик і організаційних одиниць допоможе контролювати AD
2. Аудит управління обліковими записами
3. Аудит доступу до служби каталогу
4. Пошук в журналі безпеки

Аудит облікових записів, об'єктів групових політик і організаційних одиниць допоможе контролювати AD

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

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

Адміністратор може стежити за тим, що відбувається в AD і змінами, які вносять співробітники, за допомогою двох категорій аудиту: управління обліковими записами (account management) і доступу до служби каталогу (directory service access). Аудит управління обліковими записами забезпечує оповіщення про високорівневих якісні зміни (створення, видалення та інші зміни) облікових записів користувачів, комп'ютерів і груп. Крім того, за допомогою аудиту управління обліковими записами можна відстежувати деякі зміни, пов'язані з політиками.

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

Аудит управління обліковими записами

Щоб активізувати аудит управління обліковими записами, потрібно вибрати політику Domain Controller Security Policy в розділі Administrative Tools, перейти до Security Settings, Local Policies і Audit Policy і встановити режим Audit account management для успішних подій і помилок. У цьому режимі можна отримати ідентифікатори окремих подій створення, видалення і зміни облікових записів користувачів, комп'ютерів і груп. В табл. 1 перераховані ID подій управління обліковими записами.

За допомогою події створення облікових записів можна очистити AD від надлишкових і нестандартних облікових записів користувачів, комп'ютерів і груп. Видалити надлишкові і непотрібні об'єкти набагато легше незабаром після їх створення, ніж після значного часу, коли ніхто не пам'ятає, для чого призначався об'єкт або чому він був створений. Адміністратор може негайно перевірити події створення і визначити відповідність нових облікових записів користувачів, груп і комп'ютерів політикам і процедурам організації. Поява нового облікового запису комп'ютера означає, що хтось додав в домен робочу станцію або сервер. Порівнявши подія з ID 645 з планом розгортання нових комп'ютерів, можна перевірити, чи було додавання комп'ютера санкціонованим. Подія з ID 624 дозволяє відстежувати облікові записи нових користувачів домену, перевіряти коректність нових облікових записів користувачів і застосовувати будь-які політики для угод про іменування, документування інформації про співробітників / підрядників, загальних облікових записах або облікових записах додатків.

Спостереження за подіями з ID 631, 635 і 658 дозволяє чітко застосовувати до груп політики угоди про іменування і ясно позначити власника кожної групи, відповідального за додавання нових і видалення існуючих членів. Ім'я власника групи можна вказати на вкладці Managed By у вікні Properties. В результаті група виявляється пов'язаної з обліковим записом користувача в AD. Вкладка Managed By є і в діалогових вікнах Properties більшості інших об'єктів AD.

У великомасштабних реалізаціях AD важко відстежувати ресурси і права доступу конкретної групи, що надаються її членам. Цю інформацію можна документувати в поле Notes на вкладці General діалогового вікна Properties.

Видалення користувачів, груп і комп'ютерів рідко становить загрозу для безпеки, тому виконувати поточний моніторинг подій видалення, як правило, не потрібно. Однак це може бути корисним, якщо потрібно з'ясувати, хто випадково видалив важливу обліковий запис або групу, і якщо відбувається масове видалення безлічі користувачів і груп в ході атаки типу DoS (Denial of Service - відмова в обслуговуванні).

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

Як правило, при будь-якій зміні облікової записи користувача в результаті аудиту управління на вкладці Account діалогового вікна Properties об'єкта видається подія ID 642; текстовими поясненнями супроводжуються тільки важливі зміни в системі безпеки, такі як події активації або деактивації. Наприклад, якщо змінено опис користувача, то видається просто подія з ID 642 з текстом User Account Changed, але без будь-яких додаткових пояснень. Якщо активізувати або блокувати обліковий запис, то буде видано те ж саме подія з ID 642, але з додатковим повідомленням: User Account Changed: Account Disabled. Автоматизація моніторингу та підготовка вибіркових звітів не можуть через необхідність збирати додаткову інформацію про події; проте за допомогою таких інструментів, як GFI LANguard Security Event Log Monitor (SELM) фірми GFI Software, AppManager Suite компанії NetIQ і Microsoft Operations Manager (MOM), можна призначити правила і створити звіти на основі деталей події.

В результаті аудиту управління обліковими записами можна отримати ID конкретних подій, пов'язаних з деякими змінами в облікових записах користувачів. Якщо особа з відповідними правами змінює пароль користувача, то видається подія з ID 628 (встановлений пароль облікового запису користувача). Якщо хтось намагається змінити власний пароль, записується подія з ID 627 (спроба зміни пароля). При виявленні повторних спроб входу з невірним паролем Windows 2000 Server блокує обліковий запис (якщо в домені активізована політика блокування облікових записів) і генерує подію з ID 644 (обліковий запис user блокована).

Подія з ID 643 (Domain Policy Changed: Password Policy modified, зміна політики застосування пароля) трапляється часто, навіть якщо політика застосування паролів не змінювалася. Причиною тому - помилка в Windows 2000. При застосуванні групової політики Windows 2000 не перевіряє, чи існують відмінності між новими і старими політиками. Для настройки політики застосування паролів використовується об'єкт Default Domain Policy Group Policy Object (GPO); при цьому Windows 2000 генерує подію з ID 643. Звідси висновок - подія з ID 643 сміливо можна ігнорувати.

В табл. 2 перераховані ідентифікатори подій, що генеруються при додаванні і видаленні членів групи всіх типів. Якщо в організації доступ користувачів до папок і інших ресурсів дозволений виключно через групи, то події з ID 632, 636 і 660 надзвичайно корисні, так як з їх допомогою можна відстежувати всі випадки надання користувачеві або групі нового дозволу доступу. На екрані 1 показані подробиці події при додаванні члена в універсальну (universal) групу. В деталях вказується, яка група зазнала змін (Target Account Name), хто був доданий в групу (Member Name) і хто виконав операцію (Caller User Name). На підставі цієї інформації можна визначити власника групи або переконатися в законності зміни через систему контролю служби підтримки.

Аудит доступу до служби каталогу

Завдяки аудиту управління обліковими записами можна отримати корисну інформацію для спостереження за обліковими записами користувачів, комп'ютерами і групами, але як вести моніторинг інших елементів AD, таких як зміни GPO і організаційні одиниці (OU)? Ефективний засіб для цих цілей - аудит доступу до служби каталогу. Події аудиту доступу до служби каталогу менш відомі і важкі для розшифровки, але містять надзвичайно детальну інформацію про кожну подію, що відбувається в AD. В результаті аудиту доступу до служби каталогу генерується єдина подія з ID 565 (Object open - об'єкт відкритий). Вся корисна інформація міститься в деталях події. Для активізації аудиту доступу до служби каталогу слід вибрати політику Domain Controller Security Policy в розділі Administrative Tools, потім перейти до Security Settings, Local Policies, Audit Policy, двічі клацнути на Audit directory service access і вибрати як Success, так і Failure.

За допомогою аудиту доступу до служби каталогу можна відстежувати зміни, пов'язані з груповими політиками. Самі елементарні відомості про зміни Group Policy, які корисно отримати адміністратору, - своєчасне оповіщення про редагування однієї або декількох політик, визначених GPO. Для даної ситуації не існує події з особливим ID, але її можна визначити, знаючи характерні ознаки. У схемі AD об'єкти GPO мають тип groupPolicyContainer і версію versionNumber. Якщо хтось редагує GPO, то Windows 2000 збільшує номер версії. Заново застосовуючи Group Policy, комп'ютери домену порівнюють поточний номер версії кожного GPO з номером версії, який був у об'єкта під час попереднього застосування групової політики. Якщо номер версії не змінився, то комп'ютер не виконує GPO повторно, тим самим зберігаючи ресурси як локальних комп'ютерів, так і контролера домену. Зміни GPO можна виявити, відшукавши події з ID 565, у яких параметр Object Type має значення groupPolicyContainer, параметр Accesses - значення Write Property, а в Write Property вказано versionNumber, як показано на екрані 2.

Слід звернути увагу, що Windows 2000 не повідомляє описову назву GPO, як в оснащенні Active Directory Users and Computers консолі Microsoft Management Console (MMC). Замість цього подія повідомляє відмітна ім'я (distinguished name, DN) об'єкта в форматі X.500. Наприклад, на екрані 2 Object Name - CN = {6AC1786C-016F-11D2-945F-00C04fB984F9}, CN = Policies, CN = System, DC = ad, DC = local. Корисна інформація в DN об'єкта GPO міститься в довгій початкової послідовності символів - це глобально унікальний ідентифікатор (GUID) GPO. За допомогою оснащення Active Directory Users and Computers можна пов'язати описову назву GPO з його GUID. Наприклад, щоб отримати GUID для Default Domain Controllers Policy GPO, потрібно відкрити діалогове вікно Properties для Domain Controllers OU і вибрати вкладку Group Policy. У списку GPO потрібно вибрати політику Default Domain Controllers Policy і клацнути на Properties. GUID об'єкта GPO відображається на вкладці General в поле Unique name (екран 3).

Слід звернути увагу, що в розділі Disable (екран 3) можна блокувати одну або обидві політики Computer Configuration і User Configuration. Якщо встановити один або обидва прапорця, то Windows 2000 припиняє застосовувати всі асоційовані політики, що може мати важливі наслідки для всіх комп'ютерів і користувачів домену. Щоб виявити зміну одного або обох прапорців в будь-якому GPO, необхідно звернутися до події з ID 565, в якому параметр Object Type має значення groupPolicyContainer, а Properties - flags.

Останній тип зміни GPO, який можна відстежувати, - це зміна списку управління доступом (Access Control List, ACL) GPO. ACL визначає, хто з користувачів може редагувати GPO, і дозволяє обмежити число користувачів і комп'ютерів, до яких застосовується GPO всередині пов'язаної з об'єктом групової політики організаційної одиниці або домену. В цьому випадку слід, як зазвичай, звернути увагу на подію з ID 565 Object Type groupPolicyContainer, але поле Accesses повинно містити значення WRITE_DAC (дозвіл на запис до дискреційного ACL).

Якщо хтось видаляє GPO, то генерується подія з ID 565, параметр Object Type якого має значення groupPolicyContainer, Object Name починається з CN = Policies, CN = System, а Accesses має значення Delete Child. Подія з тим же ID, Object Type і початковою фразою Object Name, але значенням параметра Accesses - Create Child замість Delete Child вказує, що хтось створив новий GPO. На жаль, ні в одній події не вказується GUID або описову назву GPO.

Інша область змін, пов'язаних з Group Policy і вимагають моніторингу, - зміна визначених груповими політиками властивостей OU. Як показано на екрані 4, у кожної OU є список пов'язаних з нею GPO; кожен GPO з цього списку має два параметри - No Override і Disabled. Крім того, OU має успадковані прапорцем Block Policy, також пов'язаним з Group Policy. Якщо хтось встановлює або розриває зв'язок з GPO або встановлює або скидає будь-які інші параметри, ці зміни можуть мати важливі наслідки для комп'ютерів і користувачів в даній OU. Щоб виявити зміни в списку пов'язаних GPO, зміни параметрів No Override або Disabled або зміни успадкованого значення Block Policy, необхідно відшукати подію з ID 565 зі значенням organizationalUnit параметра Object Type і значеннями gPOptions і gPLink параметра Write Property (екран 5).

GPO можуть бути пов'язані з доменами і сайтами. Щоб виявити пов'язані з GPO зміни в домені або сайті, слід звернутися до події з ID 565, параметр Object Type якого має значення domainDNS або site, а значення параметра Write Property - gPLink і gPOptions.

Щоб контролювати зміни прав адміністраторів та інших повноважень в AD, можна стежити за змінами в ACL-списках OU. Заслуговують на увагу деталі подій подібні описаним вище для ACL-списків GPO. Виявивши подія з ID 565, Object Type organizationalUnit і Accesses WRITE_DAC, можна зробити висновок, що хтось змінив повноваження в даній OU. В поле Object Name явно зазначено DN організаційної одиниці.

Створення нової OU можна виявити, глянувши на подію з ID 565, де параметр Object Type має значення organizationalUnit, а Accesses - Create Child. В такій події Object Name вказує батьківську OU, а не ім'я нової OU. Деталі подій видалення - ті ж, за винятком того, що параметр Accesses має значення Delete Child замість Create Child.

Зміни в сайтах можна виявити, вивчивши подія з ID 565, параметр Object Type якого має значення site, siteLink, siteLinkBridge, subnet, nTDSSiteSettings або serversContainer. Зміни в реплікації між контролерами домену представлені подією з ID 565 зі значеннями nTDSConnection або nTDSSiteSettings параметра Object Type. Для моніторингу змін в довірчих відносинах слід звернути увагу на подію з ID 565 з параметром Object Type, які мають значення trustedDomain, який використовується Windows 2000 як для довірених, так і для не пов'язаних довірчими стосунками доменів. При наявності в домені одного або декількох корпоративних сертифікатів Certificate Authorities (CA) можна контролювати зміни в шаблонах сертифікатів, самих CA і списках відкликання сертифікатів (Certificate Revocation Lists, CRL), відшукавши параметр Object Type зі значенням Type pKICertificateTemplate, pKIEnrollmentService, certificationAuthority або cRLDistributionPoint.

Пошук в журналі безпеки

Аудит управління обліковими записами і доступом до служби каталогу забезпечує цінну інформацію, необхідну для контролю змін в AD. Докладні відомості містяться в журналі безпеки, але як знайти їх? Очевидно, що переглядати кожну подію вручну неможливо. Для спеціалізованого пошуку можна використовувати функцію утиліти Event Viewer. Слід відкрити Event Viewer, натиснути правою кнопкою миші на журналі Security і вибрати пункт View / Find. Як показано на екрані 6, можна вказати ID події і ввести в поле Description текст, який утиліта повинна відшукати в деталях виявлених подій.

Для регулярного моніторингу необхідні більш ефективні інструменти. Наприклад, можна скористатися утилітою dumpel.exe з комплекту Microsoft Windows 2000, Resource Kit, яка також надається за адресою: http://www.microsoft.com/windows2000/techinfo/reskit/ tools / existing / dumpel-o.asp . Dumpel фільтрує події за номером, але не по деталях подій, які він сприймає як рядки. Для подальшої фільтрації подій, наприклад з ID 565, по вмісту рядків можна використовувати команду Findstr.

На жаль, Windows 2000 реєструє в журналі Security не буде описову назву, а GUID атрибутів схеми, і Dumpel НЕ перетворює GUID в ім'я. Тому дамп події з ID 565 виглядає так, як показано на екрані 7 . Розшифрувати його можна за допомогою документації схеми Windows 2000 AD, наведеної за адресою asp?url=/library/en-us/adschema/adschema/windows_2000_schema.asp> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/windows_2000_schema.asp . Переглянувши даний сайт, можна переконатися, що bf967aa5-0de6-11d0-a285-00aa003049e2 - схема GUID для organizational-Unit, а f30e3bbe-9ff0-11d1-b603-0000f80367c1 і f30e3bbf-9ff0-11d1-b603-0000f80367c1 - ідентифікатори GUID для gPLink і gPOptions. Маючи в своєму розпорядженні цією інформацією, можна використовувати команди

щоб отримати список всіх подій з ID 565, в яких тип об'єкта має значення organizationalUnit.

Таким чином, знаючи, де знайти необхідні відомості, можна отримати точну інформацію про події в AD, або принаймні виявити причини неполадок. Необхідно активізувати режими Audit account management і Audit directory service access в Default Domain Controllers Policy GPO, а для того, щоб отримати повну картину активності в домені, потрібно перевірити кожен домен. Удачі в аналізі журналу Security!

Ренді Франклін Сміт - редактор Windows & .NET Magazine і президент компанії Monterey Technology Group, яка займається навчанням і консалтингом в області захисту Windows NT. Зв'язатися з ним можна за адресою: [email protected]