Active Directory

Aktīvais direktorijs jeb AD (no  Active Directory) ir direktorija pakalpojumu (directory service) LDAP savietojama Microsoft realizācija Windows NT saimes operētājsistēmām. AD ļauj administratoriem izmantot grupu politikas (GPO), lai nodrošinātu lietotāja darba vides unifikāciju, vienkārši instalēt un uzturēt programmnodrošinājumu vienlaicīgi uz daudziem datoriem (ar grupu politikām vai izmantojot Microsoft System management Server 2003 vai System Center Configuration Manager), ļauj instalēt OS, papildus un servera programmatūras atjauninājumus (updates), visiem datoriem tīklā (pielietojot Windows Server Update Services (WSUS); agrāk: Software Update Services (SUS)). Active Directory datus un vides iestatījumus uztur un glabā fiziski izkliedētā(Pa Domēna kontrolieriem), loģiski centralizētā (Pa Domēniem, Kokiem un Mežiem) datubāzē. Tīkli ar Active Directory var būt dažāda izmēra: daži simti līdz vairāki miljoni objektu.

Pirmoreiz Active Directory prezentēja 1996. gadā, pirmoreiz tas bija iekļauts Windows 2000 Server, vēlāk tika modificēts un uzlabots sākumā izlaižot Windows Server 2003,(2003. gads) vēlāk Windows Server 2003 R2. (2005. gads)

Pretēji WINDOWS versijām līdz WINDOWS 2000, kuras pamatā izmantoja NetBIOS protokolu savstarpējai mijiedarbībai tīklā, Active Directory pakalpojums ir integrēts ar DNS un TCP/IP. DNS-serverim, kurš apkalpo AD, ir jābūt savietojamam ar BIND 8.1.2 versiju, vai vēlāku, serverim jāatbalsta SRV tipa ieraksti () un dinamiskais atjaunošanas protokols ().

 Objekti 
Active Directory (AD) ir hierarhiska struktūra ar objektiem. Ir trīs tipu pamata kategoriju objekti:
 resursi (piemēram, printeri, shāres)
 servisi (piemēram, elektroniskais pasts)
 cilvēki (lietotāju un grupu konti).
Active Directory uztur informāciju par objektiem, ļauj organizēt objektus, vada piekļuvi tiem, un kontrolē, regulē drošības noteikumus.

Katrs objekts attēlo atsevišķu entītiju (vienību)- lietotāju, datoru, printeri, programmu vai kopējo tīkla mapi un to atribūtus ar vērtībām. Objekti var būt arī kā konteineri citiem objektiem. Objekts unikāli identificējas ar savu vārdu un tam ir atribūtu kopa—īpašības un dati, kurus objekts var saturēt, kādi tie ir, tas atkarīgs no objekta tipa. Atribūti ir objekta bāzes struktūras sastāvdaļa un tos nosaka shēmā. Shēma nosaka, kāda(kura) tipa objekti var atrasties AD.

Shēma satur divu tipu objektus: shēmas klases objekti un shēmas atribūtu objekti. Viens shēmas klases objekts atbilst viena AD tipa objektam (piemēram, objekts „lietotājs”), savukārt viens shēmas atribūta objekts nosaka atribūtu, kurš objektam var būt.

Katrs atribūta objekts var tikt pielietots vairākiem dažādiem shēmas klases objektiem. Šos objektus sauc par shēmas objektiem (vai metadatiem) un ļauj mainīt un papildināt shēmu, kad tas ir nepieciešams. Tomēr katrs shēmas objekts ir AD objektu noteikta daļa, tāpēc šo objektu dezaktivācijai vai izmaiņām var būt nopietnas sekas, tā kā šo izmaiņu rezultātā tiks izmainīta AD struktūra. Shēmas objekta izmaiņa automātiski tiek izplatīta Aktīvajā direktorijā. Vienreiz izveidotu shēmas objektu nevar dzēst, to var tikai dezaktivēt. Parasti visas shēmas izmaiņas ir rūpīgi jāplāno.

 Meži, koki un domēni 
Struktūras augšējais līmenis ir mežs — visu objektu, atribūtu un noteikumu (atribūtu sintakse) kopums Aktīvajā direktorijā jeb shēma. Mežs satur vienu vai vairākus kokus, kuri saistīti ar tranzitīvām uzticības saitēm (attiecībām). Koks satur vienu vai vairākus domēnus, tāpat hierarhiski saistītus ar transitīvām uzticības attiecībām. Domēni identificējas ar savām DNS vārdu struktūrām — vārdu apgabaliem.

Domēna objekti var būt sagrupēti konteineros — apakšvienībās. Apakšvienības ļauj veidot hierarhiju domēna iekšienē, vienkāršo tā administrēšanu un ļauj modelēt organizatorisko un/vai ģeogrāfisko kompānijas struktūru Aktīvajā direktorijā. Apakšvienības var saturēt citas apakšvienības. Autors iesaka izmantot pēc iespējas mazāk domēnu Aktīvajā direktorijā, bet lai strukturētu AD un politikas jāizmanto konteineri(OU) jeb apakšvienības. Bieži grupu politikas pielieto tieši apakšvienībām(konteineriem jeb Organizational Unit (OU)). Arī pašas grupu politikas ir objekti. Apakšvienība ir pats zemākais līmenis, kuram var deleģēt administratīvās pilnvaras (tiesības).

Savādāk AD var iedalīt saitos (vietās), tā ir fiziskā (ne loģiskā) grupēšana, tās pamatā ir IP apakštīkli. Saitus iedala pēc pieslēguma veida: 
 Zema ātruma kanāliem (piemēram, globālo tīklu kanāliem ar VPN palīdzību)
 Augsta ātruma kanāliem (piemēram, caur lokālo tīklu).
Saitā var būt viens vai vairāki domēni, savukārt domēns var saturēt vienu vai vairākus saitus. Projektējot Aktīvo direktoriju ir svarīgi ņemt vērā tīkla datplūsmu, kura veidojas pie AD datu sinhronizācijas starp saitiem.

Svarīgākais lēmums projektējot AD ir lēmums par informācijas infrastruktūras sadalīšanu hierarhiskos domēnos un augstākā līmeņa apakšvienībās(OU). Tipiskie modeļi, tādai sadalīšanai, ir sadalīšana pēc kompānijas funkcionālām struktūrvienībām, pēc ģeogrāfiskā novietojuma un pēc lomām kompānijas informatīvajā struktūrā. Bieži izmanto šo modeļu kombināciju.

 Fiziskā struktūra un replikācija. 
Fiziski AD informācija tiek glabāta un uzturēta uz viena vai vairākiem līdztiesīgiem domēna kontrolieriem , aizstājot Windows NT izmantotajiem pamata(PDC) un rezerves (BDC) domēna kontrolieriem (tomēr lai izpildītu dažas operācijas ir saglabāts tā saucamais serveris „operācijas ar vienu galveno serveri”, kuru var emulēt galvenais domēna kontrolieris). Katrs domēna kontrolieris glabā un uztur AD datubāzes kopiju, kura paredzēta gan lasīšanai, gan ierakstīšanai. Izmaiņas, kuras veiktas vienā kontrolierī, tiek sinhronizētas uz visiem domēna kontrolieriem replikācijas laikā. Serveri, uz kuriem nav uzstādīts pats AD pakalpojums, bet tie ir iekļauti AD domēnā, tiek saukti par dalības(member) serverim.

AD replikācija tiek veikta pēc pieprasījuma. KCC pakalpojums izveido replikācijas topoloģiju, kura izmanto saitus, kuri noteikti sistēmā datplūsmas vadībai. Iekšsaita replikācija tiek veikta bieži un automātiski ar saskaņotības pārbaudes rīka palīdzību(brīdinot replikācijas partnerus par izmaiņām). Replikācija starp saitiem var būt noregulēta katram saita kanālam(atkarībā no kanāla kvalitātes), atšķirīga prioritāte vai cena var būt norādīta katram kanālam (piemēram, DS3, T1, ISDN un t.t.), un replikācijas datu plūsma būs ierobežota, to sūtīs pēc saraksta un maršrutēs atbilstoši norādītajai kanāla cenai. Replikācijas datus var pārsūtīt tranzitīvi caur vairākiem saitiem, caur saitu (vietu) saišu tiltiem, ja cena ir zema, lai gan AD automātiski piešķir daudz zemāku cenu „saits-saits” savienojumiem, nekā transitīviem savienojumiem. Replikāciju „saits-saits” veic platformu serveri katrā saitā(vietā), kuri vēlāk izmaiņas replicē katram sava saita domēna kontrolierim. Iekšdomēna replikācija izmanto RPC protokolu IP tīklā, starpdomēnu(piemēram, mežā)—var izmantot arī SMTP protokolu.

Ja AD struktūra satur vairākus domēnus, tad replikācija nenotiek visā mežā, bet lai atrisinātu objektu meklēšanu tiek izveidots GLOBĀLAIS KATALOGS, kurš satur visus objektus mežā, bet ar ierobežotu atribūtu kopumu (nepilna replika). Katalogs tiek glabāts un pārvaldīts uz norādītajiem GLOBĀLĀ KATALOGA serveriem(norādītajiem domēna kontrolieriem), kuri apkalpo starpdomēnu pieprasījumus.

Sadarbības iespēja ar vienu galveno komjūteru ļauj apstrādāt pieprasījumus, kad replikācija ar vairākiem galvenajiem serveriem nav pieejama.
Ir piecas šāda veida operācijas: 
 galvenā (agrāk primārā) domēna kontroliera (PDC — emulators) emulācija,
 relatīvās identifikācijas galvenais serveris (RID—master vai Relatīvo Identifikatoru meistars),
 Infrastruktūras galvenais serveris (Infrastruktūras meistars),
 Shēmas galvenais serveris (Shēmas meistars),
 Domēnu vārdošanas galvenais serveris (Domēnu vārdošanas meistars).
Pirmās trīs lomas ir unikālas domēna ietvaros, 4. un 5. lomas ir unikālas visa meža ietvaros.

AD datubāzi var sadalīt 3 loģiskajās krātuvēs jeb sadaļās. „Shēma” ir kā šablons (paraugs jeb matrica) priekš Aktīvā direktorija un tā nosaka visa tipa objektus, to klases un atribūtus, atribūtu sintaksi (visi koki atrodas vienā mežā, tāpēc, ka tiem ir viena kopēja shēma). „Konfigurācija” ir AD meža un koku struktūra. „Domēns” uztur visu informāciju par objektiem, kuri radīti un izvietoti šajā domēnā. Pirmās divas krātuves tiek replicētas uz visiem domēna kontrolieriem mežā, trešā krātuve tiek pilnībā replicēta starp kontrolieru replikām katra domēna ietvaros, un daļēji uz globālā kataloga serveriem.

AD datubāze (katalogu glabātuve) Windows 2000 izmanto paplašināmu glabāšanas apakšsistēmu Microsoft Jet Blue, kura ļauj katram domēna kontrolierim uzturēt db līdz 16 Terabaitiem un 1x10^9 objektiem (teorētiskais ierobežojums, praktiskie testi ir mēģināti ar aptuveni 100 miljoniem objektiem). Datubāzes fails ir NTDS.DIT un tajā ir divas pamata tabulas:
 Datu tabula
 Saišu tabula

Windows Server 2003 pievienota vēl viena tabula, lai nodrošinātu drošības deskriptoru eksemplāru unikalitāti.

 Nosaukumu sistēma 
AD uztur sekojošus objektu nosaukumu formātus: 
 universālā tipa nosaukumi UNC,
 URL 
 LDAP URL
X.500 nosaukuma formāta LDAP versija tiek izmantota Active Directory iekšienē.

Katram objektam ir atšķirīgs nosaukums (Distinguished name, DN). Piemēram, printera objektam ar vārdu HPLaser3 apakšvienībā „Tirgus” un domēnā foo.org būs sekojošs atšķirīgais vārds: CN=HPLaser3, OU=Tirgus, DC=foo, DC=org, kur „CN”—kopējs vārds, „OU”— apakšvienība (Organizacionālā vienība), „DC”—domēna objekta klase. Atšķirīgajiem vārdiem var būt daudz vairāk daļu, kā četras daļas šajā piemērā. Objektiem ir arī kanoniskie vārdi. Tie ir atšķirīgie vārdi, pierakstīti pretējā secībā, bez identifikatoriem un izmantojot slīpsvītras kā atdalītājus: foo.org/Tirgus/HPLaser3. Lai noteiktu objektu konteinera iekšienē, izmanto relatīvo atšķirīgo vārdu: CN=HPLaser3. Katram objektam ir Globālais Unikālais Identifikators (GUID) — unikāla un nemainīga 128-bitu rinda, kuru AD izmanto meklēšanai un replikācijai. Noteiktiem objektiem ir arī dalībnieka-lietotāja vārds (UPN, atbilstoši ) šādā formātā: objekts@domēns

Kategorija:Windows NT
Datortīkli