Активни Директоријум

Active Directory, Активни Директоријум (AD) – Мајкрософт мреже подржавају два основна модела уређења и контроле целокупног мрежног окружења: радну групу и домен. Радна група је предвиђена за мреже са малим бројем рачунара и свако озбиљније планирање Мајкрософтове мреже подразумева употребу домена.

Модел доменске мреже подразумева централизацију управљања ресурсима, а основа ове централизовано уређене доменске архитектуре је Активни Директоријум – база података која чува информације о свим ресурсима на мрежи. Предности мрежног окружења уређеног и контролисаног путем Активног Директоријума у односу на радну групу су немерљиве.

Аспекти контроле и управљања окружењем које омогућују Active Directory Domain Services су бројни. Администраторски посао у иоле већој мрежи заснованој на Мајкрософт клијентима и серверима био би веома тешко изводљив без организовања елемената и објеката мреже путем Активног Директоријума и алата за централизовано управљање окружењем као што су Групне Полисе. Покушаћемо да у ограниченом оквиру једног текста представимо основну терминологију и функције Активног Директоријума.

Можда вам може бити занимљиво и: Како инсталирати Активни Директоријум на Windows Server 2008R2 серверу

Дефиниција и појмови везани за AD

Активни Директоријум, Домен (Domain), Доменски контролер (Domain Controler), Стабло (Tree), Шума (Forest), Организационе јединице (Organizational Units, скраћено OU), Групне полисе (Group Policy), неки су од термина широко коришћених у релацији са овом технологијом.

Ево неколико основних дефиниција везано за Активни Директоријум, издвојених кратким прегледом на вебу:

• „Активни Директоријум је база података специјалне намене, дизајнирана да подржи релативно велики број read/search операција и значајно мањи број операција промена и уноса података. AD је хијерархијски уређена, проширива и са могућношћу репликације на више хостова.“
• „AD је структура која се креира на Мајкрософт Windows (Server) оперативним системима, чија је сврха да похрањује и обезбеђује информације о мрежи, домену и корисницима.“
• „Активни Директоријум је сервис креиран од стране Мајкрософта, који чува информације о објектима на мрежи тако да им аутентификовани корисници као и администратори мреже у сваком тренутку могу лако приступити. Коришћењем AD могуће је манипулисати великим број мрежних објеката са једног места и обезбедити хијарархјску структуру и преглед целе мреже.“

AD се ослања се на Lightweight Directory Access Protocol (LDAP), Kerberos безбедносни протокол, DNS (Domain Name System), File Replication протокол (FRS).

LDAP похрањује податке о свим мрежним ресурсима (директоријуми, фајлови, рачунари, корисници, штампачи, итд.) а Kerberos омогућује мрежну аутентификацију и потврду идентитета корисника који приступају удаљеним ресурсима. За ефикасно проналажење ресурса на мрежи задужен је DNS систем.

Сви ови елементи заједно у оквиру AD система, омогућују аутентификацију ентитета, ауторизацију и контролу приступа над ресурсима, форсирање сигурносних полиса као и конфигурационих параметара, удаљену инсталацију печева и софтвера на рачунаре у мрежи… и још понешто. Актуелна верзија Активног Директоријума на датум писања овог текста на Windows Server 2008R2 је довољно комплексна да чини покушај набрајања свих функционалности које су омогућене излишним.

Једна од највећих вредности овог система јесте у могућности да се управљање рачунарима на мрежи, по скоро свим најбитнијим параметрима админстрације, може радити централизовано, интервенцијом на једном или неколико објеката у оквиру Активног Директоријума. Измена на одговарајућем објекту AD ће рефлектовати промену на великом броју рачунара, уместо засебног, локалног подешавања на сваком рачунару појединачно.

Domain Controler – Потребно је да на почетку дефинишемо и појам доменског контролера: то је сервер у оквиру Мајкрософт мреже на коме је инсталирана Active Directory Domain Services рола, поседује копију базе Активног Директоријума и физички је репрезент Active Directory сервиса. Домен контролер (скраћено DC) прихвата и разрешава све захтеве за аутентификацијом на мрежи, похрањује податке о корисничкиим налозима, спроводи форсирање сигурносних полиса на домену и контролише приступ свим ресурсима.

Структура и објекти Активног Директоријума

При администрирању Активног Директоријума, манипулише се великим бројем објеката па ћемо покушати да ближе објаснимо ове ентитете. Сви ресурси које једна мрежа поседује, од хардвеских уређаја, до корисничких и мејл налога репрезентовани су у AD као засебни објекти. Ресурсима се називају управо хардверски уређаји, док се нпр. кориснички и имејл налози, као и групе које их обједињују називају security principals .

Security principals карактерише придружени Unique Security Identifier (SID) – јединствени ИД број који је непроменљив за све време трајања објекта у AD. Јединственост објекта AD гарантује уникатност – јединственост SID вредности, па је могуће објекту променити атрибуте, чак и назив а да при томе сви сигурносни параметри и референце са других објеката остану непромењени.

Сваком објекту се поред тога што је једиствено идентификован својим називом, може придружити и један или висе атрибута – информација које га ближе описују. Атрибути нису произвољни, већ стandардизовани типови информација из сета предефинисаних атрибута и класа објеката које је могуће креирати у AD, а одређени су у оквиру шема (schema).

Schema је формална дефиниција свих објеката (класа) који могу бити креирани у Forest-у Активног Директоријума као логичкој целини највећег реда, односно у целом AD-у. Schema, генерално представља сет правила карактеристичан за све базе података, помоћу ових правила се директно управља структуром базе тако што се дефинишу типови објеката и атрибута који се могу креирати (класе објеката, атрибути класа, релације између класа).

Логичка структура Активног Директоријума (говоримо о интерној структури базе – не о логичкој хијарархији објеката AD) је раздељена у неколико directory партиција:

Schema и Configuration партиције су део заједничке структуре свих домен контролера у истом Forest-у (највећа логичка целина AD) и из тог разлога се у процесу репликације апдејтују на све домен контролере.

1. Schema партиција садржи информације које смо управо поменули, па их нећемо понављати
2. Configuration партиција садржи податке о структури Активног директоријума, као што је информација о свим доменима и сајтовима у оквиру фореста, домен контролерима и њиховом распореду, као и о расположивим сервисима и њиховој локацији.
3. Domain партиције садрже информације о конкретним објектима у оквиру датог домена (корисници, рачунари, групе, OU). Будући да су карактеристичне за дати домен којем припадају, не реплицирају се на све домен контролере у форесту већ само на оне који припадају њиховом домену.
4. Application партиција похрањује информације о карактеристичним апликацијама Активног Директоријума – информације су специфичне за различите апликације и не реплицирају се на све домен контролере већ на оне који су назначени од стране администратора. Пример за коришћење апликационе партиције био би интегрисани DNS у оквиру Активног Директоријума. У овом случају DNS креира апликационе партиције за DNS зоне. Корисницима је трансparentна информација о томе који домен контролери у Forest-у хостују специфичне потребне апликације.

Логичка хијерархија AD (Forest, Tree, Domain)

Објекти су у Активном Директоријуму распоређени у оквиру структуриране хијарархије која укључује три нивоа: Forest (шума), Tree (стабло) и Domain .

Активни Директоријум не може постојати без барем једног домена и обратно.

Domain представља основну и независну административну јединицу Активног Директоријума, границу административних надлежности и јединицу логичког структурирања у оквиру AD. Објекти унутар домена деле заједничку directory датабасе партицију домена (стога је домен и основна јединица репликације), јединствени DNS назив домена, као и „трaст“ релације прем другим доменима. Групне полисе којима се подешава и дефинише окружење на радним станицама и корисничким налозима, придружују се објектима на нивоу истог домена и не могу се везивати за објекте других домена – ово се у потпуности односи и на сва безбедносна подешавања и параметре, као и на ACL (Access Control Lists) које су важеће унутар домена у коме су креиране.

Наравно, предузеће или организација може имати више од једног домена у свом Активном Директоријуму. Различити сектори или одељења се могу раздвојити у различите домене. Вишеструки домени чине логичку структуру стабла – Tree, уколико деле основни (root) домен стабла, односно креирају „parent-child“ структуру.

На пример, it-modul.rs би могао бити root, а redakcija.it-modul.rs и administracija.it-modul.rs итд. child гране стабла it-modul.rs домена.

Уколико баратамо са различитим доменима и вишеструким структурама стабла – у оквиру једне веће целине, долазимо до структуре шуме – Forest. Шума представља скуп свих домена у Активном Директоријуму, и бива креирана као таква, макар постојао само један домен.

На крају овог набрајања логичких структура поменућемо и Организационе једнице (OU – Organizational Units), објекте које се надовезују као елемент логичке хијарархије најнижег нивоа, а изузетно су важни као основни сегмент функционалног повезивања у AD.

Organizational Units (OU) су контејнери који се креирају унутар Domain контејнера и служе за обједињавање у логичку целину, елементарних објеката AD као што су кориснички налози, налози рачунара, сигурносне групе и друге организационе јединице. OU би биле први, основни ниво обједињавања објеката унутар Domain -а.

Поменули смо да се OU могу „гњездити“ једна у другу, и овај начин развијати структуре/хијарархије контејнера за смештај објеката у оквиру Domain-а. На овај начин се веома ефикасно може отпратити хијарархијска структура организације предузећа по секторима – одељењима и пресликати реална организација фирме на логичке објекте унутар Активног Директоријума.

Organizational Units су и најмањи контејнер односно јединица структуре за коју се могу везивати Групне Полисе (Group Policy) и делегирати административна права за њих. Ово је од изузетне важности јер се пресликавањем организационе структуре фирме, на овај начин грануларно може подешавати реално десткоп окружење, кориснички и налози рачунара, по свим параметрима подешавања које омогућују Групне Полисе, а број ових параметара није мали.

Group Policy – Групне Полисе су једна од најлепших и најкориснијих ствари у оквиру AD DS сервиса. Могли би смо их дефинисати као средство за централизовану контролу и управљање окружењем корисника на мрежи, било да су то кориснички налози или радне станице. Полисама се корисничко окружење може централно модификовати на много различитих начина, практично у скоро свим сферама администрирања, од десктоп окружења, параметара оперативног система, аспеката мрежног функционисања, публиковању и контроли апликација, пропагирању скрипти, итд.

За управљање Групним Полисама користи се Group Policy Menagement Console (Windows Server 2008 и 2008R2 платформе). Ова конзола обједињује све неопходне алате потребне за креирање и модификацију GPO (Group Policy Objects), управљање правима и дозволама, копирање, импортовање и бекап, као и репортинг компоненте.

GPO (Group Policy Objects) су објекти који репрезентују једно или више подешавања за контролу и управљање окружењем путем групних полиса. Када се GPO подешавање или више њих дефинишу (кроз GPMC интерфејс), да би била функционална, потребно је повезати (линковати) Group Policy Object са одговарајућим контејнером Активног Директоријума над којим желимо да подешавања буду ефективна.

Постоје три нивоа AD контејнера за које се могу конфигурисати (линковати) GP објекти: OU (Organizational Unit), Domain и Site . Будући да у хијарархији објеката Активног Директоријума често постоји већи број полиса и објеката распоређених на различитим локацијама у три поменута нивоа, разумљиво је да су врло могуће и честе ситуације да поједина GPO подешавања различитих нивоа међусобно буду конфликтна.

Начин пропагације (процесирања) GPO објеката је следећи:

Site GPO > Domain GPO > OU GPO > Child OU GPO

Практично, ово значи да се прво процесуира GPO објекат највишег нивоа ( Site ), затим Доменски, па све до најниже OU ( Organizational Unit ) при чему, уколико постоји конфликт, наредна полиса преписује претходну па ће у крајњем превагнути GPO везан за најнижи OU ниво. Што је ниво AD контејнера за који се полиса везује нижи, сигурније је да ће се полиса извршти, тј неће бити надјачана „специфичнијом“ полисом на још нижем нивоу.

Сваки GPO објекат поседује две основне секције: User Configuration и Computer Configuration у оквиру којих се може дефинисати велики број параметара. Подешавања у оквиру Computer Configuration се односе на конфигурацију рачунара/оперативног система и извршавају се током подизања система, док се User Configuration односи на подешавања корисничког налога и извршавају се током логон процеса.

Пример: рецимо да смо на нивоу домена it-modul.rs креирали и линковали GPO која дефинише proxy порт и сервер за Интернет Експлорер у оквиру User Configuration, као и додатно подешавање које блокира да корисници у оквиру ИЕ мануелно мењају параметре за проксирање.

Рецимо, такође да у оквиру домена it-modul.rs имамо две OU: Redakcija и Administracija.

OU Administracija има линковану GPO која форсирано дозвољава промену proxy подешавања у оквиру Интернет Експлорера, а OU Redakcija нема везану такву полису.

У резултату, OU Redakcija ће имати пропагирану доменску полису и корисницима ће ИЕ бити закључан за промене proxy сервера, док ће OU Administracija имати додатну полису са откључаним ИЕ proxy подешавањима, која ће надјачати доменску.

Trust релације:

Већ смо поменули појам Траст релације између домена.

Корисници који припадају једном домену могу приступати ресурсима који припадају другом домену, само у случају да постоји Trust релација између два домена.

• Transitive Trust – Транзитивност труст релације односи се на преношење поверења (труст релација) између домена на начин да, ако је домен А у Trust релацији са доменом Б, а домен Б у Trust релацији са доменом Ц, онда ће и домен А бити у Trust релацији са доменом Ц.
  Овај тип преношења поверења се најочигледније преноси у двосмерном транзитивном Trust односу који се аутоматски креира за све child-parent структуре у стаблу активног директоријума – при креирању child домена по аутоматизму се формира труст однос са root доменом стабла, што по закону транзиције доводи до међусобног Trust односа свих поддомена једог стабла.
  Сличан однос успоставља се и у оквиру целе шуме (Forest) по основу чињенице да root домени свих стабала у једној шуми креирају аутоматски Trust однос са root доменом шуме ( Forest ). Крајњи резултат био би Trust однос између свих домена у Forest -у.
• Explicit Trust – Експлицитни Trust је релација која није плод аутоматизма као у претходним случајевима већ се успоставља мануелно и директно за два домена, кроз једносмерни Trust однос, било као једносмерна експлицитно креирана пречица између два домена односно поддомена у оквиру истог Forest -а, са циљем да скрати пропагацију Trust релације кроз структуру шуме, или као експлицитно дефинисани екстерни Trust који прелази границу Forest -а.

Битно је нагласити да сама чињеница да се два домена налазе у Trust релацији не омогућује аутоматски корисницима једног домена приступ ресурсима у другом домену. Trust однос креира основу за дефинисање одговарајућих дозвола за приступ, али без експлицитних дозвола приступ и даље није могућ.

Global Catalog

Први домен контролер који је се креира у првом домену AD Forest-а, по дифолту укључује и Global Catalog Server ролу. Идеја иза Global Catalog сервера јесте да одређени доменски контролер поред детаљних информација о објектима домена за који је задужен, поседује и базу ограничених, делимичних информација о свим објектима у свим доменима у оквиру фореста коме припада. Намена оваквог, свеобухватног адресара објеката целог фореста је унапређење LDAP претраге на нивоу целог AD.

Информације о свим објектима које Global Catalog поседује своде се на сет неопходних информација за претрагу, како би се добила што компактнија база неопходних података који су довољни за проналажење објеката путем LDAP претраге, при чему се бенефит у брзини претраге остварује кроз избегавање референцирања других домен контролера у мултидоменском окружењу, будући да се сви неопходни подаци за проналажење свих објеката налазе на једном месту. Global Catalog се налази на домен контролерима на којима је промовисана ова рола,а база података се међу њима дистрибуира путем мултимастер репликације.

Однос доменских контролера и различите AD роле

База Активног Директоријума може бити инсталирана на једном доменском контролеру или на више њих. Сваки од постојећих доменских контролера поседује своју копију базе Активног Директоријума а базе се међусобно синхронизују процесом репликације. Поменули смо да се структура AD локалне базе састоји из више партицијиа које подржавају различите функционалности и њихова репликација на остале домен контролере се разликује у зависности од врсте партиције.

Schema и Configuration су јединствене партиције које садрже информације од есенцијалне важности за све домене у оквиру фореста, и улазе у састав базе сваког домен контролера активног директоријума. Domain партиција која похрањује информације карактеристичне за односни домен, налази се на свим домен контролерима истог домена и аналогно томе се и реплицира само у оквиру истог домена.

Како сви домен контролери у AD окружењу имају једнаку вредност по питању надлежности за упис и читање directory информација за заједничку базу домена за којег су задужени, овај модел односа можемо назвати мулти-мастер односом. Проблем при одржавању јединствене базе директоријума конзистентном, у мултидоменском окружењу, може настати у процесу репликације и упдатовања промена на остале домен контролере истога нивоа. Један од начина за решавање конфликта при ажурирању података са више извора на заједничку дистрибуирану базу у мултимастер окружењу, јесу алгоритми који су у стању да детерминишу „временски последњи (најмлађи) унос“ који ће анулирати све остале промене на другим домен контролерима. Иако је употребљив, за одређене ситуације и функционалности овај приступ није довољно добар, па је неопходно постојање Operations Master рола које се придружују појединим домен контролерима.

Operations Master домен контролери имају специфичне улоге у оквиру Активног Директоријума, усмерене на превенцију конфликтних ситуација по питању уписа у јединствену дистрибуирану базу, тамо где није примерено мултимастер реплицирање података.

Некада Flexible Single Master Operations (FSMO), од 2005 назива се једноставније Operations Master и актуелне верзија Мајкрософт AD DS дефинише 5 Operations Master рола.

Operations Master роле које се могу извршавати на само једном домен контролеру у оквиру фореста:

• Schema master (контролише све schema модификације)
• Domain naming master (контролише додавање и уклањање домена у оквиру фореста)

Operations Master роле које се могу извршавати на само једном домен контролеру у оквиру домена:

• Primary Domain Controler (PDC) емулатор – емулира напуштену Primary DC ролу, одржава компатибилност са NT4 доменима и још неке битне функције у актуелном AD DS окружењу
• Infrastructure master – одржава референце у оквиру група за објекте чији је назив промењен
• Relative ID (RID) master (контролише поол Relative ID вредности које остали домен контролери корсте при креирању SID уноса за објекте из своје надлежности)

Репликација у оквиру AD (AD Sites and Services)

Ради постизања што бољих ефеката при репликацији AD базе и актуених промена у њој, поред логичке структуре/хијарархије објеката у AD коју чине Domain, Tree и Forest, постоји и независна физичка структура са својим објектима и односима међу њима. Ова физичка структура је репрезентована објектима који се називају Sites, Subnets и Site Links, чија је улога да дефинишу што квалитетнију репликациону топологију за неопходну размену информација у оквиру Активног Директоријума.

Управљање репликационом топологијом, како на нивоу локалног LAN окружења (Site) тако и на нивоу ширег физичког окружења (WAN – intersite replikacija) врши се помоћу Active Directory Sites and Services snap-in конзоле.

Active Directory Site (сајт) је репрезент физичког окружења већег броја рачунара који су међусобно повезани квалитетним физичким линком, са добром могућношћу међусобне комуникације. Концепт сајта (физичке области) не треба мешати са AD доменом који је логичка целина – сајт може обухватати више домена и обратно, домен се може простирати преко више сајтова.

Основна сврха Site објекта је у контроли и управљању репликацијом и остваривању што ефикаснијег протока информација при репликацији. Site омогућује да се направи баланс између потребе за актуелном информацијом о стању базе осталих домен контролера и цене конекције између учесника у процесу репликације. Информацију о најоптималнијој путањи ка ресурсима на мрежи коју обезбеђује Site објекат, практично користе и сви клијенти – радна станица или корисник ће за аутентификацију изабрати домен контролер у оквиру локалног сајта. Поред поменутог Site објекат има аналогну улогу и у лоцирању провајдера одређених сервиса (Exchange, Certificate services, etc).

Subnet објекат служи за груписање рачунара исте IP адресне локације у оквиру Site-а. Дефинисањем Subnet објекта, практично додељујемо одређени IP адресни простор Site-у. Subnet објеката може бити више и битно је нагласити да дефинисање субнета у AD не мора да у потпуности кореспондира одговарајућом шемом layer 3 рутирања које већ постоји у оквиру мреже.

Site линкс објекти представљају конекције за репликацију између Site локација (будући да су intersite конекције, подразумевано користе спорији транспортни медијум него intersite репликација). Репликација између Site локација се може подешавати мењањем/конфигурисањем параметара Site линка (измена Site објеката који користе линк, фреквенција репликације, „cost“ вредност…).

У процесу креирања и одржавања информације о најефикаснијиим репликационим рутама, учествује KKC (Knowledge Consistency Checker) сервис који локално функционише на сваком домен контролеру.

Овај локални сервис не комуницира директно са осталим KKC сервисима на другим домен контролерима већ податке о потребним објектима за цео AD Forest преузима из Sites објекта (Sites контејнер у оквир Configuration партиције директоријума) и на основу ових података генерише репликационе руте за локални DC.

По један домен контролер у оквиру сваког сајта има додељену Intersite Topology Generator (ISTG) улогу и задужен је за омогућавање intersite репликације (идентификује одговарајуће сервере за репликацију ка удаљеним Site локацијама). ISTG креира приказ репликационе топологије на вишем нивоу, за све Site локације и аутоматски препознаје одговарајуће сервере исте намене у оквиру других Site локација. Практично, подела надлежности може се дефинисати на следећи начин: KKC сервис је задужен за репликациони процес локалног домен контролера, а ISTG има надлежност за локални Site.

Текст је преузет са угашеног блога ИТ модул и оригинални аутори овог текста су Бранислав Колар и Владимир Благојевић.