І. Б. Трегубенко О. В. Коваль безпека корпоративних мереж. Служба каталогу active directory
| Вид материала | Документы |
- На правах рукописи, 1970.76kb.
- Телефон: +7-902-991-3258 (сотовый), 18.27kb.
- 003 и желающих получить аналогичные знания и навыки для администрирования серверов, 106.39kb.
- Active Directory Rights Management Services ad rms в составе ос windows Server® 2008., 872.38kb.
- Active Channel Узел Web, автоматически поставляемый на рабочий стол пользователя. , 316.14kb.
- План Основні поняття > Іntranet корпоративна мережа Вимоги до корпоративних мереж, 17.4kb.
- Список литературы на тему воспитание и образование детей в Древней Руси. Коваль Т.,, 14.67kb.
- Действительный залог(the Active Voice) и страдательный залог (the passive voice), 38.59kb.
- Перелік виставкових заходів нк «Експоцентр України», які потребують державної підтримки, 94.99kb.
- Безпека, 3519.8kb.
Стратегія A G DL P Цю стратегію можна позначити як AGDLР. Це означає, що облікові записи користувачів є членами глобальної групи, а для локальної доменної групи настроєні права доступу до ресурсу (наприклад, до папки з файлами). Щоб користувачі одержали доступ до цього ресурсу, залишається зробити тільки одне - включити глобальну групу в локальну доменну групу. Порядок дій при створенні такої стратегії буде таким: 1. Створення глобальної групи безпеки. 2. Включення необхідних облікових записів в цю групу. 3. Створення локальної доменної групи безпеки. 4. Настроювання дозволів на доступ до ресурсу (наприклад до папки) для цієї локальної доменної групи. 5. Включення глобальної групи в локальну доменну групу. Кількість глобальних груп залежить від кількості груп користувачів, яким надаються однакові права на ресурс. Кількість локальних доменних груп залежить від кількості загальних папок, принтерів і вимог до розмежування доступу. Стратегія A G P Ця стратегія позначається як АGР і припускає, що облікові записи користувачів входять у глобальну групу, для якої настроєні права доступу до ресурсу. Стратегію АGР рекомендується використовувати тільки в невеликих мережах і тільки виходячи з того, що в Active Directory ніколи не буде більше одного домена. Стратегія A G U DL Р В стратегії AGUDLР вперше буде застосована універсальна група. Тут облікові записи користувачів входять в глобальну групу, глобальна група, у свою чергу входить в універсальну групу, універсальна група включена в локальну доменну групу, а для останньої настроєні права доступу до ресурсу. В мережі з одним доменом Active Directory, як правило, не використовується така стратегія. Універсальні групи встановлюються там, де доменів декілька. У порівнянні з доменною та глобальною групою універсальні групи відрізняються одним важливим параметром, а саме - місцем, у якому зосереджена вся інформація про те, хто є членом даної групи. В двох попередніх типах груп відомості про членство зберігаються на всіх контролерах домена, у якому створені групи, а членство в універсальній групі зареєстровано на серверах глобального каталогу лісу Active Directory. Якщо зміниться склад, скажімо, локальної доменної групи, відомості про зміну будуть скопійовані на всі контролери домена. Якщо ж відбудеться зміна складу універсальної групи, відомості про зміну будуть поширюватися серед серверів глобального каталогу, які можуть знаходитися (як рекомендується) в кожному домені. Таким чином, локальна мережа буде перевантажена передачею даних між серверами глобального каталогу, що негативно позначиться на роботі всіх клієнтів мережі. Універсальні групи саме тому використовуються нечасто. В стратегії AGUDLР включення глобальних груп в універсальні відбувається з метою зменшити трафік реплікації, оскільки якщо додати користувачів в універсальну групу, відбудеться реплікація між серверами глобального каталогу, тому що зміниться склад універсальної групи, а якщо включити користувача в глобальну групу, то універсальна не зміниться, у цьому випадку копіювання інформації між серверами глобального каталогу відбуватися не буде. Стратегія A G L Р В стратегії AGLP L - це локальна група, а не локальна доменна. Ця стратегія рекомендується для доменів із системою Windows NT 4.0 Server, у яких локальних доменних груп не існує. Недоліками цієї стратегії є те, що локальними групами не можна управляти централізовано та неможливість одержати через членство в них доступ до ресурсів на віддаленому комп'ютері. 2.14. Об'єкт Комп'ютер Ще один тип об'єктів Active Directory – це об'єкт сomputer (компьютер). В Active Directory є два типи таких об'єктів. Перший - це об'єкт domain controller (контроллер домена), що створюється при призначенні сервера контролером домена. За замовчуванням об'єкти domain controller розміщені в організаційному підрозділі Domain Controllers, в якому сконфігуровані параметри настроювання безпеки контролера домена, і переміщення контролера домена із цього контейнера може серйозно змінити настроювання безпеки. Другий тип об'єктів computer - це об'єкти, що представляють всі інші комп'ютери, які є членами домена. Облікові записи цих комп'ютерів створюються в Active Directory у заданому за замовчуванням контейнері Computers. Об'єкти computer із цього контейнера можуть бути переміщені в певні організаційні підрозділи для надання можливості управляти комп'ютерами різними способами. Наприклад, керування серверами та робочими станціями компанії відрізняється одне від одного, тому потрібно створити дві окремих організаційних одиниці (OU) для серверів та робочих станцій. Найчастіше робочі станції розбиваються на більш дрібні групи. Так, робочим станціям комерційного відділу, наприклад, необхідні додатки, відмінні від додатків, що використовуються робочими станціями технічного відділу. Створюючи дві організаційні одиниці та поміщаючи робочі станції у відповідні OU, з'являється можливість різними способами управляти двома типами робочих станцій. Комп'ютерні облікові записи створюються в домені при приєднанні комп'ютера до домену. 2.15. Об'єкт Принтер Наступна категорія об'єктів Active Directory це об'єкти printer. Цей об'єкт можна створити шляхом опублікування принтера в Active Directory, при цьому зберігаються такі атрибути принтера, як місце його розташування, а також властивості принтера (швидкість друку, можливість кольорового друку та інші). Підставою для публікації об'єктів printer в Active Directory є полегшення для користувачів пошуку та з'єднання з мережними принтерами. Після публікації принтера інформація про нього автоматично реєструється у вікні Properties (Свойства) принтера, доступного з інструмента Active Directory Users And Computers. 2.16. Організаційні підрозділи Підрозділом (organizational unit, OU) називається контейнер, призначення якого полягає в систематизації об'єктів домена в рамках логічних адміністративних груп. До об'єктів, які можуть міститися в підрозділах, відносяться облікові записи користувачів, групи, комп'ютери, принтери, додатки, загальні папки, а також інші вкладені підрозділи, що входять у локальний домен. Графічно підрозділи позначаються піктограмою папки із книгою. При встановленні Active Directory на нові контролери домена автоматично створюється підрозділ Domain Controllers (Контроллеры домена). В результаті доповнення одних підрозділів іншими формується ієрархічна структура, називається цей процес вкладенням підрозділів. Структура підрозділів існує на будь-якому контролері домена. При цьому структури підрозділів різних доменів є незалежними один від одного. Організаційні одиниці мають наступні характеристики:
В порівнянні з іншими компонентами Active Directory, такими як домени та ліси, структуру OU легко змінити після розгортання. Переміщення об'єктів між OU зводиться до клацання правою кнопкою миші на об'єкті та вибору Move (Переместить) з контекстного меню. Існує три основних задачі, керуючись якими адміністратори створюють підрозділи:
Проект OU, заснований на делегуванні адміністрування Одна із причин створення структури OU полягає в можливості делегування адміністративних задач. Наприклад, компанії, які з'єднали домени ресурсів Windows NT у єдиний домен Active Directory, можуть, при необхідності, делегувати адміністративні задачі, які раніше виконували адміністратори домена в домені ресурсів. Компанії, які мають кілька офісів з локальними мережевими адміністраторами в кожному, можуть делегувати адміністрування кожному із цих офісів. Крім того можна делегувати конкретну адміністративну задачу. Наприклад, надати одному або двом співробітникам у кожному відділі право скидувати паролі користувачів, а також змінювати інформацію для всіх користувачів відділу. Все це стає можливим завдяки створенню структури OU в Active Directory і подальшому делегуванні адміністративного доступу. На рівні OU стає можливим представити будь-який рівень адміністративного доступу. Якщо OU створюється для віддаленого офісу, то можна надати його адміністратору повне управління об'єктами цього офісу. Адміністратор може виконувати будь-яку адміністративну задачу в цій OU, включаючи створення дочірніх OU і делегування дозволів іншим адміністраторам. Якщо OU створюється для кожного відділу, то можна надати досить специфічні права декільком користувачам у відділі, наприклад право скидування паролів. Також можна надати адміністративні права, що засновані на типах об'єктів в OU, наприклад, адміністратори відділу можуть змінювати облікові записи користувача, але не можуть змінювати об'єкти груп або комп'ютерів. В підрозділі 3.3 надана інформація, що розкриває поняття делегування адміністрування. Для більшості компаній організаційні одиниці вищого рівня будуються на основі вимог, пов'язаних з делегуванням адміністрування. Найчастіше, ці одиниці OU засновані на основі географічного місця розташування офісів компанії або на основі ділових підрозділів. Ці границі OU будуть також і адміністративними границями. Проект ОU, заснований на адмініструванні групових політик Друга причина для створення OU полягає в управлінні групових політик. Групові політики використовується для зміни та керування конфігурацією робочих середовищ. За допомогою групової політики можна організувати для користувачів стандартну конфігурацію робочого столу, включаючи автоматичну інсталяцію набору додатків. Групова політика може управляти змінами, які користувачі виконують на своїх комп'ютерах, і конфігурувати параметри настроювання захисту. Майже всі групові політики в Active Directory призначаються на рівні OU, так що розгортання групових політик буде відігравати важливу роль в проекті OU. При плануванні структури OU об'єкти, які вимагають однакових параметрів настроювання групової політики, групуються разом. Наприклад, якщо всім користувачам одного відділу потрібно використовувати однаковий набір додатків, їх можна встановити, настроївши відповідну групову політику. Сценарії входження в систему для користувачів можна призначити, також використовуючи групову політику. Може бути необхідно застосовувати шаблон захисту до всіх файлових серверів організації. Щоб зробити це, потрібно сгрупувати всі файлові сервери в OU і призначити шаблон захисту, використовуючи групову політику. В більшості компаній вимоги до рівня проекту OU будуть визначатися, насамперед, потребою застосування групової політики. За замовчуванням всі групові політики наслідуються від батьківських OU. Це означає, що можна застосувати групову політику на високому рівні в структурі OU, а потім застосувати специфічну групову політику на більш низькому рівні. Якщо потрібно змінити задане по замовчуванню наслідування групової політики, це можна зробити, створивши OU і заблокувавши будь-яке наслідування групової політики на рівні OU. Така залежність проекту OU від групових політик означає, що потрібно чітко розуміти функціональні можливості групових політик і вимоги організації. В підрозділі 2.19 докладно обговорюються поняття, пов'язані із груповими політиками. Проект ОU, заснований на сховуванні об'єктів Іноді згідно вимог компанії необхідно приховати окремі об'єкти від певних категорій користувачів. Приміром, не маючи повноважень на читання атрибутів того або іншого об'єкта користувач може мати дозвіл на перегляд даних в його батьківському контейнері, і тоді сам факт існування об'єкта буде йому відомий. Для приховування об'єктів в рамках домена вони поєднуються в підрозділи, а в цих підрозділах настроюються повноваження List Contents (Список содержимого), які поширюються не на всіх користувачів, а лише на деяких. Більш докладні відомості про повноваження приводяться в підрозділі 3.2. Створення проекту OU Розробка проекту OU починається з організаційних одиниць вищого рівня. Їх складніше модифікувати після розгортання через організаційні одиниці, що розташовані нижче. OU вищого рівня повинні бути основані на тому, що має бути незмінним: на географічних регіонах або ділових підрозділах. Проект OU, заснований на географії компанії, буде найбільш стійкий до змін. Деякі компанії часто реорганізуються, але рідко змінюють географічну конфігурацію. Структура OU, заснована на географії компанії, добре працює, якщо компанія використовує децентралізовану адміністративну модель, також засновану на географії. Якщо кожне географічне місце (один офіс або центральний офіс із декількома філіями) має свій власний набір мережевих адміністраторів, то географічні OU можуть використовуватися для делегування адміністративних завдань цим адміністраторам. Основний недолік структури OU, заснованої на географії, проявляється тоді, коли виникає кілька ділових підрозділів у кожному географічному місці. Якщо в кожному офісі компанії існує декілька відділів, ефективніше на вищому рівні використовувати структуру OU, засновану на ділових підрозділах. Інша структура OU вищого рівня основана на ділових підрозділах. В такій моделі OU вищого рівня створюється для кожного ділового підрозділу в межах корпорації. Цей тип конфігурації є найбільш підходящим, якщо компанія розташовується в одному місці або якщо багато адміністративних задач делегуються на рівень ділового підрозділу. Проблема, що може виникнути, полягає в тому, що OU вищого рівня зміняться у випадку реорганізації компанії. Більшість великих корпорацій фактично будуть використовувати комбінацію одиниць, заснованих на географії та на ділових підрозділах. Звичайна конфігурація - це OU вищого рівня, засновані на географічних регіонах, з наступним рівнем OU в межах кожного регіону, заснованих на ділових підрозділах. Деякі компанії можуть вибрати OU вищого рівня, засновані на ділових підрозділах, а потім створювати під вищим рівнем структуру OU, засновану на географії. На рисунку 2.11 показаний проект OU для великої компанії. OU вищого рівня включає Domain Controllers OU (OU контролерів домена) (всі контролери домена розташовані в цій OU) і OU адміністраторів рівня домена. OU вищого рівня можуть включати OU служби облікових записів для всіх службових облікових записів (Service Account), що використовуються в домені. Створення на вищому рівні OU для спеціальних облікових записів користувачів, таких як службові облікові записи, спрощує їхнє адміністрування. OU вищого рівня можуть включати OU серверів, якщо всі сервери управляються централізовано. На додаток до цих адміністративних OU можуть бути також OU вищого рівня, засновані на географії корпорації. Організаційні одиниці вищого рівня, засновані на географії, можуть використовуватися для делегування адміністративних завдань.  Рисунок 2.11 – Типова структура OU OU другого рівня в кожному географічному регіоні засновані на ділових підрозділах регіону. OU бізнес-підрозділів могли б використовуватися для делегування адміністрування, а також для призначення групових політик. Під діловими OU розташовуються OU, засновані на відділах. На цьому рівні OU буде використовуватися для призначення групових політик або певних адміністративних завдань. OU відділів можуть містити інші OU.
Теоретично, не існує обмеження на кількість рівнів, що може мати структура OU. Зазвичай, практичний досвід підказує, що не потрібно мати більше десяти рівнів. Для більшості компаній структура OU, що складається із чотирьох або п'яти рівнів є опримальною. Працюючи над створенням проекту OU, потрібно його ретельно задокументувати. Проект буде включати діаграму структури OU, список всіх організаційних одиниць OU і мету кожного OU. 2.17. Іменування об'єктів Active Directory Облікові записи користувачів, групи, а також облікові записи комп'ютерів, принтерів і т.д. є об'єктами Active Directory і мають певні правила іменування. Cлужба каталогів Active Directory сумісна із протоколом LDAP (Lightweight Directory Access Protocol), при подачі запитів до бази даних Active Directory мережеві клієнти користуються саме цим протоколом. Кожний об'єкт Active Directory ідентифікується по імені, правила іменування об'єктів задаються стандартами LDAP. Серед прийнятих в Active Directory схем іменування існують складене, відносно складене, глобально-унікальний ідентифікатор і основне ім'я користувача. Складене ім'я У кожного об'єкта Active Directory є складене ім'я (distinguished name, DN), що, по-перше, виконує роль його унікального ідентифікатора, а, по-друге, містить дані, що дозволяють клієнту отримати його з каталогу. DN складається з імені домена, в якому розміщується об'єкт, і повного шляху до нього через ієрархію контейнерів. Приміром, наведене нижче складене ім'я ідентифікує об'єкт користувача Scott Cooper в домені ссылка скрыта: CN=Scott Cooper,ОU=Promotions,ОU=Marketing,DC=Microsoft,DC=Com В складі DN для позначення імен застосовуються три характерні для LDAP скорочення:
DN в Active Directory повинні бути унікальними. Скорочення LDAP, що позначають атрибути іменування - CN, OU і DC - в Active Directory не відображаються. У наведеному прикладі вони фігурують з метою демонстрації того, як LDAP розрізняє елементи складеного імені. Відносно складене ім'я Реалізована в Active Directory підтримка запитів по атрибутах дозволяє виявляти навіть ті об'єкти, чиї складені імена невідомі або були змінені. Відносно складеним ім'ям (relative distinguished name, RDN) об'єкта називається одна із частин його імені, що одночасно є атрибутом об'єкта. В наведеному вище прикладі в якості RDN об'єкта користувача Scott Cooper виступає Scott Cooper. RDN батьківського об'єкта — Promotions. Глобально унікальний ідентифікатор Глобально унікальним ідентифікатором (globally unique identifier, GUID) називається 128-розрядне шістнадцятирічне число, що в масштабі підприємства обов'язково повинно бути унікальним. Ідентифікатори GUID призначаються об'єктам в момент їхнього створення. Навіть у випадку переміщення або переіменування об'єкта його GUID залишається незмінним. Зберігаючи GUID об'єкта, додаток одержує можливість звертатися до нього без допомоги поточного DN. В системі Windows NT кожний ресурс домена асоціювався з ідентифікатором безпеки (security identifier, SID), що генерувався всередині цього домена. Саме в масштабах домена гарантувалася його унікальність. Що ж стосується GUID, то він унікальний для всіх доменів відразу - таким чином, навіть при переміщенні об'єкта з одного домена в інший його ідентифікатор не перестане бути унікальним. Основне ім'я користувача У кожного облікового запису є «зручне» ім'я, і називається воно основним ім'ям користувача (user principal name, UPN). UPN складається з імені облікового запису користувача [іноді його називають реєстраційним іменем користувача або іменем входу (user logon name)] і доменного імені, що ідентифікує домен, в якому розміщено цей обліковий запис. Наприклад, об'єкту користувача Scott Cooper, що знаходиться в домені mісссылка скрыта може відповідати основне ім'я ScottC@microsoft.com (воно складається з імені та першої букви прізвища користувача). 2.18. Організація пошуку об'єктів Active Directory Процедура визначення місця розміщення об'єктів Active Directory зводиться до формування критеріїв пошуку. Ці критерії повинні бути задані у властивостях об'єкта при його створенні або редагуванні. Саме тому так важливо вказувати в процесі створення об'єктів Active Directory всі важливі для компанії атрибути. Чим більше атрибутів задано для об’єкта, тим більша гнучкість при його пошуку. Існує два інструменти визначення місця розміщення об'єктів Active Directory:
За допомогою функції Find (Найти) можна знайти будь-який об'єкт, опублікований в Active Directory. Ця функція дозволяє проводити пошук користувачів, контактів, груп, комп'ютерів, принтерів, загальних папок, підрозділів, серверів і клієнтів віддаленої установки. Крім того, вона передбачає можливість формування спеціальних пошукових запитів і подачі стандартних адміністративних запитів, спрямованих на керування користувачами, контактами та групами. Критерії пошуку, що вводяться за допомогою функції Find (Найти) перетворюються в запити LDAP, саме вони фактично застосовуються для виявлення об'єктів Active Directory у глобальному каталозі. Dsquery - це утиліта, що дозволяє проводити за заданими критеріями пошук комп'ютерів, контактів, підмереж, груп, підрозділів, вузлів, серверів і користувачів Active Directory. Для цього використовуються наступні команди:
Синтаксис всіх команд утиліти Dsquery проводиться в Довідковій системі Windows Server 2003. Нижче наведені кілька прикладів використання утиліти Dsquery для організації пошуку:
dsquery computer -inactive 4
dsquery user OU=Marketing, DC=Microsoft, DC=Com
dsquery user -name Mike*
dsquery * OU=Test, DC=Microsoft, DC=Com - scope base -attr * Крім створення запитів на пошук об'єктів Active Directory існує можливість збереження запитів. Це дозволяє адміністраторам створювати запити, редагувати їх, зберігати, систематизувати і відправляти по електронній пошті. За рахунок можливості збереження запитів адміністратори одержують доступ до зазначеного набору об'єктів каталогу для проведення моніторингу або виконання інших завдань. Збережені запити розміщуються в контейнері консолі Active Directory Users And Computers. Вони фіксуються в файлі цієї консолі Dsa.msc і оновлюються щораз при її відкритті. Створивши власний набір запитів, можна перенести файл консолі на будь-який інший контролер Windows Server 2003 в межах домена. Крім того, збережені запити можна експортувати у файл .xml, а з нього — імпортувати в інші консолі Active Directory Users And Computers контролерів локального домена. |