Functiile Active Directory Intr O Retea de Organizatie

Introducere

Scopul acestei teme este de a ne ajuta în modul de lucru în cadrul rețelelor IT care devin din ce în ce mai complexe cu echipamente variate. Procesarea eficientă și sigură în rețea este mai importantă ca oricând pentru ca o companie să rămână competitivă.

Sistemele de operare de rețea permit organizațiilor să profite din plin de investițiile IT precedente și să extindă aceste avantaje către parteneri, clienți și furnizori prin implementarea unor caracteristici cheie.

Lucrarea de față este împărțită în două mari capitole, mai exact primul capitol conține o privire de ansamblu asupra serviciului Active Directory cu privire la ceea ce înseamnă și din ce este compus, exemplificând foarte clar cu câteva scheme concrete. În al doilea capitol am intrat în amănunte cu privire la serviciul Active Directory pe platforme ca Windows Server 2000 și respectiv Windows Server 2003 făcând referire la modul de configurare și respectiv modul de lucru din mediul Active Directory.

Încă de la apariția pe piață împreună cu platforma Windows 2000 Server, AD a devenit o parte integrantă în multe medii IT. Ca serviciu director cum este Active Directory, permite ca obiectele incluse să fie stocate într-un mod ierarhic sau structurat.

Active Directory – Privire de ansamblu

Rețelele Microsoft Windows suportă două modele de servicii de directoare: modelul workgroup și modelul domeniu. Modelul domeniu este de departe cel mai comun și mai utilizat când vine vorba de implementarea Windows Server 2003. Este caracterizat de o singură structură de directoare – Active Directory – fiind apobată de toate sistemele de securitate care aparțin domeniului. Acele sisteme folosesc principiile de securitate ale directorului pentru a securiza resursele (utilizatori, grupuri și conturi).

Serviciul director

Un director, folosind o analogie de termeni clasici, reprezintă o carte de telefoane albă sau galbenă, avantajul celor două tipuri de cărți este faptul că au abilitatea de a ne ajuta să găsim informația de care avem nevoie în cazul unei adrese sau pentru a afla mai multe numere de telefon; singura diferentă dintre cele două este modul în care sunt indexate.

Publicarea informațiilor într-un director și permiterea accesului la acestea pentru utilizatori, aplicații precum și a administratorilor de sistem pentru a facilita fluxurile de informații care vor circula între utilizatori și aplicații, sunt câteva dintre avantajele fundamentale ale unui Director.

Directoarele ca LDAP și AD reprezintă tipuri de baze de date care poti fi folosite în cadrul unei rețele pentru a oferi informații folositoare utilizatorilor. Un utilizator poate căuta într-un AD un director partajat fără să cunoască arhitectura acestuia. Fără Serviciile Director utilizatorul trebuie să cunoască numele serverului unde este partajată informația sau fișierele dorite precum și numele exact al fișierelor.

Căutarea este un serviciu fundamental furnizat de LDAP ca atare cu cât există mai multă informație într-un director cu atât acel director devine mai căutat de utilizatori în cadrul unei rețele.

În cadrul unui AD informația unui domeniu este stocată în cel mai comun și ușor de căutat mod. Toate conturile de utilizatori, grupurile din care fac parte conturile de utilizatori, ACL, identificatori de securitate, fișiere partajate, imprimante partajate, informații cu privire la utilizatori sunt toate stocate într-un AD. Mai mult cei de la Microsoft furnizează o interfață Microsoft Management Console comună pentru administratorii unui AD.

Microsoft Active Directory

AD reprezintă una din implementările Microsoft de servicii director și este bazat pe standardele cele mai importante respectiv LDAP și X.500.

În cadrul compatibilității cu LDAP, AD oferă facilități ca integrarea serviciilor director cu domeniile Windows precum și cu DNS. Integrarea serviciilor director în domeniile Windows este cheia scalabilității directoarelor; securitatea dintr-un AD, autentificarea și controlul acceselor sunt și ele dependente de integrarea domeniilor într-un director.

Un important aspect este acela că un domeniu Windows trebuie să conțină numele identic cu cel al DNS-ului alocat; în același mod numele DNS este folosit pentru resoluția de adresă IP precum și la numele domeniului AD.

Componentele unui AD

Serviciul Active Directory funcționează pe două nivele: fizic și logic. Având în vedere structura fizică, AD este un singur fișier pe un hard disk dintr-un serverpentru fiecare controler de domeniu care găzduiesc serviciul. Structura logică a unui AD presupune containerele folosite pentru a stoca obiectele serviciului director (cum sunt partițiile director, domeniile și “pădurile”). Aceste partiții director, domenii și “pădurile” sunt reduse la câțiva biți și sunt stocate pe componente fizice ale serviciului director.

Structura fizică a Active Directory este concepută ca un singur fișier localizat în fiecare controler de domeniu din cadrul domeniului. Implementarea fizică a serviciului AD este descrisă de locația controlerelor de comeniu unde serviciul este găzduit. În cadrul implementării AD se pot adăuga câte controlere de domeniu este nevoie pentru a susține serviciul director al organizației. Acest fișier localizat în controlerele de domeniu – Ntds.dit este stocat în folderul: %SystemRoot%\NTDS. Acest fișier stochează toate informațiile legate de domeniu ca și informațiile partajate de toate controlerele de domeniu din cadrul organizației.

O copie a fișierului Ntds.dit poate fi găsit și în folderul %SystemRoot%\System32. Această copie a fișierului este copia standard folosită de baza de date a directorului și este folosită la instalarea serviciului Active Directory. Acest fișier este copiat pe server când platforma Microsoft Windows Server 2003 este instalată pentru ca platforma să fie promovată în cadrul controlerului de domeniu fără a mai fi nevoie de disc-ul de instalare.

În momentul în care Wizard-ul (clientul) de instalare a serviciului Active Directory Dcpromo.exe rulează, fișierul Ntds.dit este copiat din folderul System32 în folderul NTDS și devine copia originală a directorului. Dacă acest controler de domeniu nu reprezintă primul controler de domeniu din domeniu, acest fișier v-a fi actualizat de pe un alt controler de domeniudin cadrul domeniului folosind procesul de replicare.

Domeniul

Elementul cel mai important în structura unui AD este domeniul, unde pot fi stocate milioane de obiecte. Obiectele stocate într-un domeniu sunt considerate “Interesante” într-o rețea. Obiectele “Interesante” dintr-o rețea sunt acelea care vor fi folosite de utilizatori în cadrul locurilor de muncă ale utilizatorilor acestei rețele, mai exact imprimante, documente, adrese e-mail, baze de date, utilizatori precum și alte resurse. Toate obiectele unei rețele sunt stocate in cadrul unui domeniu și fiecare domeniu stochează doar informația aferentă obiectelor. Un AD este compus din unul sau mai multe domenii.

Domeniile conțin următoarele caracteristici:

toate obiectele dintr-o rețea fac parte dintr-un domeniu și fiecare domeniu stochează doar informațiile aferente obiectelor conținute;

un domeniu este o limită de securitate. Listele ACL controlează accesul obiectelor din domeniu. Toate politicile de securitate și setările de drepturi administrative nu sunt aplicate distinct la două domenii în același timp;

administratorul unui domeniu deține drepturile depline la politicile de securitate în cadrul aceluiași domeniu.

Un aspect important în cadrul structurii ierarhice unui domeniu este acela că drepturile utilizatorilor și grupul politicilor de securitate sunt moștenite în întreaga ierarhie OU.

“Copacii”

Un domeniu “copac” reprezintă o colecție de domenii Windows 2000 care formează un spațiu de nume adiacent. Un “copac” este format în momentul în care un domeniu “copil” este creeat și asociat cu un domeniu root existent. Un “copac” se aseamănă cu un copac din natură cu rădăcina în sus (cu zona de root în partea de sus), cu ramurile (domeniile “copil”) încolțite în jos.

“Copacii” sunt elemente structurale care asigură scalabilitatea într-un AD. Cum fiecare domeniu reprezintă o partiție (parte dintr-un întreg director), “copacii” asigură necesarul ierarhic într-o organizație, în același mod DNS asigură structura ierarhică în mediul Internet. Domeniile într-un „copac” trebuie să aibă același nume cu cel al numelui alocat în DNS.

În diagrama de mai jos avem un exemplu de ierarhie „copac”; numele domeniilor sunt aceleași cu cele alocate prin numele domeniilor DNS:

“Pădurile”

Există cazuri în care două sau mai multe domenii “copac”, definindu-se fiecare separat printr-un spațiu de nume DNS, trebuie să fie incluse într-o singură organizație. Un “copac” trebuie să fie reprezentat de un spațiu de nume DNS adiacent care interzice alocarea domeniilor care nu fac parte din acest spațiu de nume. Mecanismul prin care se îmbină una sau mai multe domenii “copac” se numește „Pădure”.

Toți “copacii” din cadrul unei “păduri” împart următoarele beneficii:

aceeași schemă;

aceeași infrastructură AD;

catalog global;

fiecare domeniu “copac” dintr-o “pădure” folosesc același mecanism tranzitiv de încredere Kerberos.

Notă: Un AD care conține un singur “copac” dintr-un singur domeniu este considerată “Pădure”.

În schema de mai sus este prezentată o “Pădure” cu două domenii “copac” microsoft.com și respectiv msn.com.

“Unități Organizaționale”

Unitățile organizaționale reprezintă un factor foarte important și cu un impact deosebit în politicile de securitate, eficință și costurile de administrare. Acestea reprezintă un tip de container LDAP (X.500) și poate fi denumit ca un element dintr-un sub-domeniu cu proprietăți similare domeniului din care face parte. Aceste OU fac parte din spațiul de nume LDAP și nu aparțin spațiilor de nume DNS.

Spre deosebire de structura ierarhică a unui domeniu, drepturile utilizatorilor și politicile de securitate sunt moștenite printr-o ierarhie OU.

Unul din principalele avantaje/beneficii ale OU este posibilitatea de a îndeplini funcțiile domeniului din care fac parte și totodată reduc numărul total de domenii necesare.

Unitățile organizaționale sunt folosite în mod constant pentru a stoca conturile de utilizatori și conturi de grupuri de utilizatori.

Un alt avantaj în utilizarea acestor OU este conceptul de delegare autorității. Administratorii unui domeniu pot delega parțial drepturile domeniului prin OU; spre exemplu administratorul domeniului poate delega resetarea parolelor utilizatorilor personalului din help desk. Această opțiune de resetare a parolelor este de obicei folosită prin intermediul GPO filtrate de grupurile de securitate și aplicate la nivelul de OU.

Privind în ansamblu design-ul structurii unui OU în mod uzual se reflectă structura unei tehnologii informaționale.

“Schema”

Termenul de schemă într-un AD descrie definițiile de date pentru AD. Dacă un obiect sau un atribut nu face parte din schemă, atunci acel obiect/atribut nu v-a fi stocat în AD.

Directorul conține informații de forma unor obiecte și atribute de obiecte, în acest fel acest Director este un tip de bază de date optimizată pentru interogări. Informațiile care sunt mai mult sau mai puțin statice și sunt cautate deseori pot fi stocate într-un mod benefic în Director, in schimb informațiile care sunt modificate cel mai frecvent, nu este o idee bună de a le stoca într-un Director.

De exemplu datele personale ale utilizatorilor (numere de telefon, adresă), setări de configurare ale aplicației sunt cateva din informațiile statice care pot fi întreținute de serviciile Director. Astfel de informații sunt mai căutate decăt modificate, astfel ne putem da seama că informațiile dinamice ca fișierele log și fișierele de sistem nu vor fi stocate în Director.

Schema Manager este o aplicație folosită de administratorii unui AD care definește atributele care vor fi publicate într-un catalog global, un aspect deosebit de importantimportant este acela de a alege informația ce urmează a fi stocata în acest catalog.

“Group Policy Object” – GPO

Unitățile organizaționale sunt folosite pentru a colecta obiecte – coputere și utilizatori – configurate similar. Politica de grup (Group Policy) ne oferă posibilitatea de a efectua setări de securitate, implementări software și configurări de sisteme de operare și managementul unor aplicații fără a utiliza în mod direct acel calculator. Se implementează prin configurarea din cadrul unui GPO. Aceste unități reprezină colecții de mai multe configurații cum ar fi drepturi de autentificare pentru utilizatori și privilegii pentru anumite aplicații de a le putea rula sau nu în cadrul sistemelor de operare.

Obiectele GPO sunt informații de caracter critic fiind folosite ca justificare pentru suplimentarea domeniilor.

În următorul tabel vom identifica cele mai importante aspecte implicate într-un CCM:

“Global Catalog”

Catalogul global este folosit pentru a îmbunătăți timpul de răspuns al căutărilor LDAP. GC-ul conține toate proprietățile obiectelor din cadrul unei “Păduri”. Proprietățile incluse într-un GC sunt în general utile pentru căutările considerate statice (proprietățile dinamice vor cauza replicări masive).

În cazul unei interogări LDAP într-un AD prima locație unde se efectuează căutarea v-a fi în GC – Catalogul global, din acest motiv într-un GC sunt stocate proprietățile obiectelor utile căutarilor. În cazul în care proprietățile obiectelor căutate nu se regăsesc în GC, interogarea se v-a muta în AD.

1.2.2 Naming context, partiționarea și replicarea într-un AD

În cadrul unui AD sunt stocate informațiile necesare unei configurații de tip “Pădure”. Fiecare domeniu este o partiție separată în cadrul unui Director și este considerat un name context separat.

Partiționarea asigură scalabilitatea Directorului. Deși un singur domeniu poate conține milioane de obiecte există situații de adăugare de noi domenii în cadrul aceleiași “Păduri”. Adăugarea unui nou domeniu are un impact minim conținutului celorlalte domenii.

AD este partiționat în trei contexte de nume (Naming context): DNC(Domain Naming Context), CNC (Configuration Naming Context) și SNC (Schema Naming Context). Un domeniu este propriul context de nume și scopul său este localizat în membrii domeniului.

Fiecare context de nume trebuie replicat printr-un scop. DNC este replicat către toate controller-ele de domeniu în cadrul aceluiași domeniu. CNC și SNC sunt replicate pe fiecare controller de domeniu în cadrul unei “Păduri”. Replicarea este un alt aspect major în design-ul unui AD. O altă funcționalitate majoră care este replicată în cadrul unui AD sunt GC-urile, iar acestea nu reprezintă un context de nume separat; de fapt ele reprezintă o replică parțială a tuturor obiectelor dintr-o “Pădure”.

“Încrederea Kerberos”

„Încrederea” face posibilă alocarea posibilelor principii de securitate de la un domeniu la altul. Principiul de „încredere” din Windows NT era bazat pe principiul de „încredere” din LAN Manager (NTLM).

Exemplul 1: – Am un cont în domeniul A, domeniul B „are încredere” în domeniul A deci mă voi putea loga în domeniul B cu contul din domeniul A folosind politica de login din domeniul A.

În consecință pentru a se stabili principiul de „încredere” între cele două domenii „încrederea” trebuie să se stabilească în ambele direcții și anume:

Domeniul A trebuie să stabilească o politică de „încredere” către Domeniul B;

Domeniul B trebuie să stabilească o politică de „încredere” către Domeniul A.

Exemplul 2: – Dacă Domeniul A are „încredere” în Domeniul B și Domeniul B are „încredere” în Domeniul C, atunci Domeniul A are „încredere” în Domeniul C.

Fără „încrederea” tranzitivă scenariul de mai sus s-ar transforma în:

Dacă Domeniul A are „încredere” în domeniul B și, Domeniul B are „încredere” în Domeniul C, atunci Domeniul A nu are încredere în Domeniul C.

„Încrederea” Kerberos în Active Directory este tranzitivă și bidirecțională. Acest aspect simplifică managementul „încrederilor”, facilitează partajarea informației în cadrul unei “Păduri”. O “Pădure” poate fi vizualizată ca un model de “încredere” complet de autentificare.

Unul dintre principalele avantaje ale tehnologiei Kerberos este reducerea semnificativă a numărului de „încrederi”, și având în vedere că acestea sunt tranzitive reprezintă modelul de “încredere” complet. Beneficiile modelului Kerberos de “incredere” au repercusiuni sau constrângeri de design în cerințele stricte de securitate.

Având în vedere cele 2 scheme de mai sus putem observa că simbolul pentru un domeniu NT la Microsoft este reprezintat printr-un cerc, iar pentru un domeniu AD printr-un triunghi.

1.2.3 Delegarea autorității

Arhitecturile foarte mari NT cu peste 40.000 de conturi au nevoie de un cont master de administrator de domeniu unde toate conturile sunt stocate în account domain și resursele folosite în domenii separate de resurse.

Resursele de domenii au “încredere” în domeniul de conturi însă contul master nu întotdeauna are “încredere” în domeniile de resurse, acest aspect se poate observa în diagrama de mai jos. O problemă fundamentală cu acest model este că numărul de domenii tind să crească.

Un administrator de domeniu poate să delege autoritatea de a schimba/reseta parolele utilizatorilor domeniului către personalul din help desk. Când un utilizator al domeniului își uită parola de acces poate apela la colegii din help desk pentru a-i reseta parola. Personalul din help desk nu v-a avea alte drepturi în domeniu.

Avantajul principal al delegării autorității este acela că poate reduce numărul domeniilor și poate furniza privilegii sau drepturi specifice task-urilor necesare utilizatorilor domeniului.

Schema de proces a Microsoft Active Directory

Aspectele de design ale unităților organizaționale (OU) necesită cunoștințe complexe ale misiunii, personalului implicat precum și a procedurilor operaționale a departamentului sau a proiectului reprezentat de OU. Parametrii unei OU pot fi subiectul unor modificări rapide cum ar fi: modificări de personal, noi proiecte sau noi cerințe de conformitate. Justificarea faptului de a împinge complexitatea către OU este aceea că tehnologiile AD se acomodează cu modificările la nivelul OU doar prin procedura simplă de drag-and-drop.

Modificările aduse structurii de Domeniu sau de “Pădure” sunt mult mai complexe deoarece orice modificare aici necesită modificări și la structura DNS. Astfel orice greșeală în procesul de design v-a genera o dificultate crescută în remedierea ei ulterioară după implementare.

Metodologia Microsoft de planificare a rezultatelor este reprezentată prin cele 4 documente de planificare după cum urmează:

Planul Pădure;

Planul Domeniu;

Planul OU;

Planul site.

Planul “Pădure”

O pădure este o colecție de domenii AD. Pădurile deservesc 2 mari scopuri:

simplificarea interacțiunii cu directorul;

simplificarea managementului mai multor domenii.

Pădurile au următoarele caracteristici:

o singură schemă;

un singur container de configurare;

“Încredere” completă;

un singur GC (catalog global);

căutare utilizatori în GC;

autentificare utilizatori folosind User Principal Names.

Pentru crearea unui plan “Pădure” se vor folosi următorii pași:

determinarea numărului de păduri pentru rețea;

crearea uneu politici de control al modificărilor;

înțelegerea impactului modificărilor survenite “Pădurii” după implementare.

În momentul planificării unui model de domeniu tip “Pădure” se v-a alege un model cu o singură Pădure fiind necesară în multe situații; pentru a crea mai multe Păduri este necesar să deținem o justificare tehnică.

În cazul unei singure Păduri toți utilizatorii vor vedea un singur Director printr-un GC și nu vor avea alte griji pentru structuri suplimentare de directoare. Când se adaugă un nou domeniu în cadrul unei Păduri nu sunt necesare alte politici de configurare pe “încredere”. Ulterior orice modificare într-o Pădure v-a afecta toate domeniile în cadrul aceleiași Păduri.

Dacă administrarea rețelei este distribuită pe mai multe diviziuni autonome v-a fi necesară crearea mai multor Păduri. Deoarece Pădurile au elemente partajate între ele, cum ar fi o Schemă este necesar ca toți participanții în cdrul unei Păduri să agreeze conținutul și administrarea elementelor partajate.

Cazuri posibile de dezvoltare a mai multor “Păduri”:

administrarea rețelei este împărțită în mai multe grupuri autonome;

grupurile autonome nu au încredere una în cealaltă;

fiecare grup autonom va deține un control individual pe Schema proprie;

necesarul limitării încrederilor relațiilor între domenii și “Copaci”.

Consecințele deținerii unui sistem cu mai multe Păduri:

Multiple Scheme și menținerea consistenței între ele v-a fi peste măsură;

Deținerea de mai multe containere de configurații. Topologia modificărilor de rețea vor fi replicate manual fiecărei Păduri suplimentare lucru care v-a crea mai multe cerințe de management.

Utilizatorii vor trebui să interogheze resursele în afara Pădurii din care fac parte;

Orice replicare a informației între Păduri se v-a face manual;

Nu se vor putea muta foarte ușor conturile de utilizatori între Păduri.

În momentul dezvoltării unei “Păduri” trebuie să avem asociată o politică de control a modificărilor ca parte integrantă în Forest Plan. Această politică v-a fi folosită în scopul ghidării modificărilor globale asupra “Pădurilor”. Pentru a continua nu este nevoie înțelegerea proceselor individuale ci doar înțelegerea proprietății acestor “Păduri”. Politica de control trebui să includă informații despre fiecare element partajat în cadrul “Pădurii”.

Politica de modificare Schema

Grupul administratorilor schemei au control deplin asupra schemei unei “Păduri” iar politica de modificare a acestei scheme v-a include:

numele echipei din organizație care v-a controla grupul administratorilor schemei;

aparteneța de început a grupului de administratori ai schemei;

orientările și procesele de cerere și evaluare a modificărilor din schemă.

Politica de modificare a configurației

Grupul de administratori enterprise au control deplin asupra containerului cu configurații care este replicat în toată “Pădurea” și v-a trebui să includă:

numele echipei din cadrul organizației care controlează grupul de administratori enterprise;

apartenența grupului de administratori enterprise;

orientările și procesele de creare a noilor domenii în cadrul unei “păduri”.

orientările și procesele de modificare a topologiei “pădurii”.

Când un domeniu este creat, poate fi inclus într-o “pădure” existentă. Când vom crea un domeniu prin promovarea Windows 2000 server într-un rol AD dintr-un controler de domeniu, sau printr-un upgrade de la NT Primary Domain Controller la Windows 2000.

Obiectele individuale pot fi mutate între “păduri”, totodată este bine de știut faptul că metodele și aplicațiile curente de import și export a obiectelor între mai multe “păduri” este destul de brut. Este important faptul că două “păduri” nu pot fi suprapuse după un singur pas, la fel cum nu se poate muta un domeniu între mai multe “păduri” folosind o singură operație.

Planul “Domeniu”

Un plan domeniu este unul din cele mai complexe aspecte dintr-un AD. Microsoft a integrat tehnologiile Microsoft Domains, Serviciile Director LDAP și DNS.

Procesul de planificare este împărțit în trei:

Determinarea numărului de domenii;

DNS și Numele de domenii;

Managementul implementărilor ulterioare.

Reducerea numărului de domenii într-o “pădure” este pentru noi o scurtă listă de obiective. Planul domeniu v-a determina disponibilitatea directoarelor în cadrul rețelei, interogarea caracteristicilor clienților și replicarea caracteristicilor de trafic ale controlerelor de domeniu. Când vom crea un plan domeniu pentru fiecare “pădure” cel mai probabil vom consulta următoarele aspecte:

administratorii de domeniu care sunt responsabili cu conturile de utilizatori, grupuri și PC-uri;

echipele care administrează și monitorizează rețelele la nivel fizic;

echipele care administrează serverele DNS;

echipele care administrează rețeaua/domeniile/pădurile din punct de vedere al securității.

Pașii care trebuie urmați pentru a crea un plan domeniu pentru o “pădure” sunt:

determinarea numărului de domenii în fiecare pădure;

alegerea unui domeniu root în cadrul fiecărei păduri;

asignarea unui nume DNS fiecărui domeniu pentru a se crea o ierarhie de domenii;

planificarea serverului DNS pentru implementare;

optimizarea autentificării utilizatorilor folosind scurtături pe “încrederi”;

înțelegerea impactului adus modificărilor planului de domeniu după implementarea lui.

Domeniile AD sunt denumite după numele DNS care funcționează ca niște servicii de localizare pentru AD. Clienții interoghează DNS-ul pentru a localiza servicii ca LDAP și Kerberos Key Distribution Center. Un client folosește DNS pentru a determina ce site folosit precum și ce controler de domeniu folosește acest domeniu. Pentru a localiza serviciul trebuie trecut printr-un proces complex folosind integorări DNS și LDAP.

Asignarea unui nume DNS cu fiecare domeniu creat este asociată planificarea numărului de “copaci”. Obiectivul acestei planificări este acela de a minimiza numărul de “copaci” deoarece fiecare copac necesită o zonă DNS separat. Copacii suplimentari necesită mentenanță asupra unei zone DNS suplimentare pentru fiecare copac.

Microsoft recunoaște că cele mai multe infrastructuri DNS sunt bazate pe BIND. Orice domeniu creat pe platforma Windows 2000 deține un nume DNS (domeniu.gov) și fiecare PC cu sistem de operare Windows 2000 are un nume DNS (statie.domeniu.gov). Astfel domeniile și calculatoarele sunt reprezentate ca obiecte în AD și ca noduri în DNS.

Deoarece domeniile DNS și domeniile AD partajează aceleași nume de domenii este foarte ușor să se confundă rolurile fiecăruia. Diferența este că două spații de nume chiar dacă partajează structura de domeniu identică, stochează date diferite și ca atare controlează obiecte diferite: DNS stochează zone și resurse, AD stochează domenii și obiecte ale domeniilor. Amândouă sistemele folosesc o bază de date pentru a rezolva numele.

DNS rezolvă numele de domeniu și numele de calculatoare referitoare la înregistrările de resurse prin intermediul cererilor primite de la serverele DNS ca interogări dintr-o bază de date DNS.

AD rezolvă numele obiectelor de domeniu referitoare la înregistrările obiectelor prin intermediul cererilor care sunt recepționate de controlerele de domeniu, ca cereri de căutare LDAP sau ca cereri de modificare la baza de date AD.

Un aspect important referitor la DNS și Ad este acela că un nume de domeniu DNS folosit de un client determină în ce locație v-a căuta în cadrul AD resursele necesare. Ca exemplu concret: clientul client.w2k.local folosește w2k.local ca domeniu DNS parte integrantă din numele complet. Când acest client pornește o căutare LDAP, interogarea LDAP v-a căuta în GC (Catalogul Global). Dacă informația căutată nu este găsită în GC, clientul v-a căuta în DNS.

Planul OU

Design-ul și planul OU este un alt aspect complex al AD. Totodată acest aspect nu este la fel de complex cum este în cazul planului Domeniu, când vine vorba de modificări ulterioare implementării. Un plan OU bine implementat v-a aduce cu siguranță un ROI pentru companie în cazul AD.

Partea decizională când vine vorba despre design-ul OU, GPO, grupuri de securitate și delegările, are un aspect critic; totodată putem spune că aspectele AD sunt desemnate pentru a controla modificările în cadrul Directorului. Aceste decizii nu reprezintă un grad de risc ridicat pentru DNS.

Cea mai bună alegere inainte de a pune în practică structura unui AD este de a muta complexitatea la nivelul planului OU având în vedere următoarele motive:

Modificarea structurii OU este foarte ușoară;

Unitățile OU sunt foarte flexibile când sunt folosite în combinație cu grupurile de securitate și unitățile GPO;

Unitățile OU oferă o limită de securitate;

Unitățile GPO structurate ca “părinți” pentru OU sunt moștenite de o unitate “copil” OU (un domeniu copil nu moștenește politica de securitate de la domeniul părinte în cadrul unui spațiu de nume);

Unitățile OU pot fi delegate ca și drepturi administrative, în consecință pot salva costurile de adăugare a unui nou domeniu doar pentru roluri administrative;

În diagrama care urmează voi prezenta o structură standard de unități OU:

În această diagramă este prezentată o structură standard de OU care include unități GPO și începe de la un controler de domeniu principal și o politică de domeniu standard. Toate controlerele de domeniu sunt stocate într-o unitate OU separată și unitatea GPO este specifică DC-ului (Domain Controler-ului).

Acest domeniu are multiple diviziuni și o singură unitate OU divizională. Toată structura divizională OU moștenește politica de domeniu standard. Administratorii de sistem operează independent de administratorii de domeniu; administratorii de domeniu au delegat “drepturile de control depline” către Administratorii divizionali care fac parte și din grupul de securitate al structurii OU.

Administratorii divizionali ai unitaților OU au creat patru unități OU sub diviziunea OU principală. Fiecare unitate OU creată are următoarele observații:

Toate serverele de diviziune sunt localizate în serverele OU și în unitățile OU “copil”. O unitate GPO separată este aplicată severului OU pentru a îmbunătăți funcționarea fiecărui server. Serverele Web localizate în unitatea OU – WWW are un adițional GPO care conține politica de securitate standard specifică IIS și care previne rularea altor servicii pe serverele IIS;

Toate stațiile de lucru sunt localizate într-o unitate OU destinată lor. Pentru o operare sigură este alocată și o unitate GPO care asigură distribuția de software precum și politica de securitate aferentă. Setările aferente vulnerabilităților sunt incluse în politica de securitate și aplicate tuturor stațiilor de lucru din cadrul unității OU;

Toți utilizatorii diviziei sunt localizați în unitatea OU aferentă lor. Politica de domeniu este moștenită și este adecvată utilizatorilor (politica de conturi, politica aferentă blocării conturilor și politica Kerberos). Celelalte două grupuri de administratori și ingineri necesită cerințe speciale:

Inginerii au cerințe de software speciale și necesită drepturi de sistem pentru a putea dezvolta aplicații;

Administratorii în schimb au de asemenea propriul lor OU care conține politica aferentă de securitate.

Unitatea aferentă proiectului X conține infrastructura necesară acestui proiect. Toate conturile ale utilizatorilor implicați în acest proiect sunt stocate în OU. Controlul administrativ deplin a fost delegat grupului de securitate aferent proiectului.

Ultima unitate OU este aplicată în cadrul protecției sistemelor critice și reprezintă programul sensibil al unei OU. Această unitate are alocată și o unitate GPO.

Procesul de planificare al Site-urilor

Un Site este definit ca fiind un set de rețele cu o conexiune rapidă și sigură și este reprezentat de un set de IP subrețele. O topologie AD a unui Site este reprezentată printr-o schemă logică la nivel fizic. Topologia Site-ului este definită folosind bazele per-forest (Pădure). Clienții și serverele AD folosesc topologia Site-ului a unei “Păduri” pentru a ruta interogările și replicarea traficului într-un mod cât mai eficient. Deasemenea ne ajută în decizia poziționării controler-ului de domeniu într-o rețea.

Pentru crearea unei topologii pentru o “Pădure” vom folosi următoarele procese:

Definirea Site-ului și a link-urilor folosind topologia fizică ca punct de pornire (Link-urile unui Site sunt conexiunile dintre obiecte, folosite pentru a conecta 2 Site-uri conectate în mod uzual ca o rețea de tip WAN);

Plasarea serverelor în Site-uri;

Înțelegerea impactului asupra utilizatorilor finali, a modificărilor topologiei site-ului după implementare;

Consultarea echipelor care administrează și monitorizează rețelele la nivel TCP/IP;

Consultarea administratorilor de domeniu pentru fiecare domeniu din cadrul “Pădurilor”.

Politica de securitate la nivel de grup GPO v-a fi implementată de sus în jos pe următoarea ierarhie:

Site;

Domeniu;

OU.

Modelele de securitate și unitățile OU pot fi utilizate în scopul asocierii calculatoarelor care necesită un model unic de securitate. Orice setare generată de unitatea GPO sau modificarea de către administrator în regiștrii unui calculator vor trebui aplicate direct în unitatea OU care stochează contul utilizatorilor.

În următoarele cazuri nu este recomandată aplicarea prea multor politici la nivelul Site-ului. Multe din ele sunt la nivel de concept de domeniu:

Politica de parole cum sunt lungimea, perioada de valabilitate a parolelor;

Blocarea conturilor;

Politica Kerberos;

Recuperarea fișierelor de sistem criptate;

Politica de securitate IP;

Criptarea cheilor publice;

Certificatele de autoritate.

Înainte de crearea unei scheme de grup a politicilor de securitate (Group Policy) întotdeauna este bine testarea lor prealabilă într-o rețea pilot.

Când controlerele de domeniu, serverele GC și administratorii de domeniu sunt planificate se poate defini 1 sau mai multe Site-uri AD. Fiecare controler de domeniu v-a trebui poziționat într-un Site AD, ulterior se v-a afla care sunt sub-rețelele pe care se vor plasa serverele de domeniu. Apoi se v-a determina care alte subrețele sunt conectate la fiecare din subrețelele locale din LAN. Acest model de grupare de subrețele reprezintă un singur Site AD. Dacă avem controlere de domeniu în mai multe locații separate de WAN, procesul de grupare v-a avea loc la fiecare dintre aceste locații.

Un alt pas important este localizarea calculatoarelor client care sunt instalate în cadrul acestui AD.

În următoarea figură se v-a putea observa arhitectura hardware a unor Site-uri precum și legătura dintre ele la nivel fizic. Deasemenea această figură ilustrează maparea rețelelor la Site-uri AD separate de o conexiune/Link WAN. În fiecare subrețea avem o conexiune stabilă și de viteză 10Mbps sau mai bună, insă între aceste LAN-uri rețeaua WAN are o legătură mai slabă.

După crearea Site-urilor se vor creea conexiunile dintre ele prin intermediul cărora se v-a crea replicarea și autentificarea căilor dintre aceste Site-uri. Astfel de conexiuni pot lega mai mult de 2 Site-uri între ele, în multe cazuri unele companii și-au implementat topologii de rețea hub-spoke. Folosind acest model de topologie fiecare locație din finalul „spiței” este poziționat câte un Site și în centrul “roții” este poziționat hub-ul care la randul său este un Site. Cu această structură se poate folosi un singur link prin intermediul căruia se conectează toate Site-urile (având în vedere faptul că banda folosită și modul de comunicare sunt aceleași între hub și fiecare locație din “roată”). Pot să apară situații în care avem nevoie de lațime de bandă diferită precum și mijloace de comunicare diferite în funcție de locație și de distanța dintre locații. În următoarele două figuri se vor prezenta prima figură – o schemă de transformare a unei rețele fizice în topologie de tip Site iar a doua figură transformarea unei rețele de tip hub-and-spoke în topologie de tip Site. În cadrul acestor figuri se v-a face referie la câteva locații din mai multe județe din România conectate înte ele folosind diferite lățimi de bandă:

Diferențele dintre AD-Windows 2000 și AD-Windows Server 2003

Odată cu prima versiune foarte stabilă a Active Directory disponibilă cu Windows 2000 și îmbunătățită cu suficient de multe facilități, întotdeauna există și v-a exista loc de îmbunătățiri în jurul utilizării cât mai optime precum și din punct de vedere al performanțelor.

Diferența între Windows 2000 Active Directory și Windows Server 2003 Active Directory este bazată mai concret pe punctul de vedere al “evoluției” decât pe cel al “revoluției”. Decizia de a trece de la Windows 2000 la Windows 2003 este una subiectivă bazată pe necesități. De exemplu dacă rețeaua este organizată cu mai multe controlere de domeniu și Site-uri AD atunci vom avea nevoie în mod cert de îmbunătățiri cum ar fi replicarea datelor.

Privind în ansamblu în următoarele 2 tabele voi prezenta cele mai importante facilități Active Directory, funcționale la nivel de domeniu de pe cele două platforme Windows 2000 și respectiv Windows Server 2003:

Studiu de caz – Active Directory pe Windows 2003 Server

Un AD stochează informații referitoare la componentele dintr-o rețea, mai exact alocă unui client posibilitatea de a găsi obiectele de care are nevoie într-un spațiu de nume (namespace). Termenul de spațiu de nume se referă la locația unei componente de rețea. Un exemplu concret este acela că DNS-ul este un spațiu de nume care transformă un hostname intr-o adresă de IP. Un AD ne furnizează un spațiu de nume pentru transformarea numelor obiectelor de rețea în obiecte, mai exact poate transforma o varietate mai mare de obiecte ca nume de utilizatori, sisteme, servicii în cadrul unei rețele.

Ca o scurtă descriere a componentelor care intră în cadrul unui Active Directory voi descrie următoarele:

orice element stocat și căutat prin intermediul unui AD este considerat un obiect. Un obiect este considerat orice utilizator, resursă sau serviciu în cadrul unui AD. Termenul generic de obiect este folosit deoarece AD este capabil să urmărească o varietate de componente și astfel mai multe obiecte pot sa partajeze atribute comune.

Atributele descriu obiectele, mai exact toate obiectele utilizatori partajează atribute prin care se stochează contul utilizatorului, numele complet, adresa și o descriere. Sistemele, deasemenea sunt niște obiecte însă au un set separat de atribute care includ un host name, o adresă IP și o locație.

Setul de atribute disponibile unui obiect oarecare mai este denumit și schemă. O schemă are rolul de a diferenția clasele obiectelor între ele. Informația stocată într-o schemă este de fapt stocată într-un AD, ceea ce dă dreptul administratorilor să adauge atribute claselor de obiecte și să fie ulterior distribuite în cadrul rețelei în toate zonele din domeniu fără să mai fie nevoie de restart la controlerele de domeniu.

Exemplu: Clasa unui obiect cu numele computer este reprezentată într-o schemă după cum apare în următoarea figură:

Pentru a înțelege cum are loc o modificare intr-o schemă putem exemplifica ideea că într-o companie este necesară salvarea datei de angajare ale tuturor angajaților. Pentru a pune în aplicare acet aspect v-a trebui întreținută ‘data angajare’ a fiecărui angajat ca și atribut al obiectului ‘utilizator’ dintr-un AD. Pentru a fi disponibil acest atribut în momentul înregistrării unui angajat nou este necesară definirea acestui atribut în cadrul schemei, acest lucru se poate face completând următorul formular:

Un container este un tip special de obiect folosit pentru a organiza un AD și nu reprezintă nimic din punct de vedere fizic cum ar fi un cont de utilizator sau un sistem. Acesta este folosit pentru a grupa mai multe obiecte, astfel mai multe containere pot fi impricate cu alte containere.

Orice obiect din cadrul unui AD are un nume, mai exact nume complexe – LDAP. Spre exemplu numele complex al unui cont dintr-o rețea Microsoft este: “/O=Internet/DC=COM/DC=Microsoft/DC=MSP/CN=Users/CN=Thomas Angel”

Termenul de copac descrie un set de obiecte din cadrul unui AD, cand containerele și obiectele sunt combinate ierarhic acestea formează mai multe ramuri.

Termenul pădure descrie copacii care nu fac parte din același spațiu de nume dar își partajează aceeași schemă, configurație și acelai tip de GC. “Copacii” dintr-o “pădure” au “încredere” unii in ceilalți, deci obiectele din acești “copaci” sunt disponibile tuturor utilizatorilor dacă politica de securitate le permite acest lucru. Companiile care sunt împărțite în mai multe domenii ar trebui să grupeze acești “copaci” într-o singură “pădure”.

Un Site este o locație geografică definită în cadrul AD. Site-urile corespund adreselor IP logice dintr-o subrețea și pot fi folosite de aplicații pentru a localiza cel mai apropiat server dintr-o rețea. Folosind informațiile unui Site dintr-un AD putem reduce traficul în WAN.

2.1 Structura logică a unui AD

După instalarea unui Active Directory în cadrul rețelei v-a trebui implementat un design al acestui AD în scopuri de business, deci se v-a folosi structura logică a Active Directory (Acest model de structură logică definește precum și modul de organizare pentru fiecare politică de securitate în principal în cadrul companiei). Baza de date din cadrul AD v-a conține următoarele elemente importante:

Partiții;

Domenii;

Copacii domeniu;

Pădurile;

Site-urile;

Unitățile Organizaționale (OU).

Partițiile

Baza de date pentru Active Directory este stocată într-un singur fișier pe HDD pentru fiecare controller de domeniu. Directorul bazei de date este împărțit în mai multe partiții logice și pe fiecare din aceste partiții se v-a stoca diferite tipuri de informații. Partițiile unui AD se mai numesc NC li vor fi vizibile dacă se folosește utilitarul ADSI Edit (vezi mai jos figura acestui utilitar):

Pe partiția Domain este zona cea mai folosită unde au loc toate evenimentele din cadrul unui AD. Această partiție conține toate informațiile legate de domeniu cum ar fi utilizatori, grupuri de utilizatori, sisteme, contacte. În mod esețial totul poate fi vizualizat folosind utilitarul administrativ Active Directory Users and Computers stocat pe partiția Domain Directory. Această partiție este automat replicată în toate DC-urile din cadrul Domeniului.

Partiția Configuration conține informațiile referitoare la configurația aferentă întregii “Păduri”. De exemplu toate informațiile legate de Site-uri, link-uri, conexiuni replicate. Deoarece această partiție conține toate informațiile legate despre întreaga “Pădure” este și această partiție replicată în toate DC-urile din cadrul Domeniului.

Partiția Schema conține schema întregii “Păduri”. După cum am mai explicat mai devreme o schemă este un set de reguli care explică ce fel de obiecte pot fi create în cadrul AD, la fel și reguli desre fiecare tip de obiect in parte. Partiția Schema este replicată în toate DC-urișe din întreaga “Pădure”. Ca atare un singur DC, mai exact o schemă master deține o versiune modificabilă a partiției Schema. Toate modificările trebuie făcute pe DC-ul cu Schema master, după care modificările vor fi replicate și pe celelalte DC-uri.

Partiția GC-Catalog Global într-un AD Windows Server 2003 este partiția director aplicație. O singură partiție de acest tip este creată într-un AD destinată unui serviciu DNS-Domain Name System. Această partiție poate stoca orice tip de obiect AD cu excepția politicilor de securitate. Din cauza faptului că această partiție este creeată pentru a controla datele care urmează a fi replicate, nici un obiect din ea nu poate fi replicat pe partiția GC.

De exemplu numele DNS pentru partiția de configurare al “Pădurii” Microsoft.com este:

dc = Configuration, dc = Microsoft, dc = com

Dacă vom crea o partiție aplicație pentru Microsoft DNS-ul v-a fi:

dc = AppPartition1, dc = Microsoft, dc = com

dc = AppPartition2, dc = AppPartition1, dc = Microsoft, dc = com

Putem crea o partiție o partiție aplicație cu DNS-ul diferit față de cel din domeniu din cadrul “Pădurii”, astfel se v-a crea un nou “copac” în cadrul “Pădurii”.

dc = AppPartition

2.2 Active Directory și DNS în mediul Windows Server 2003

Serviciul Active Directory de pe platforma Microsoft Windows Server 2003 se bazează în totalitate pe DNS – Domain Name System pentru a putea localiza resursele într-o rețea. În cadrul unei rețele fără o infrastructură DNS stabilă, controlerele de domeniu din rețea nu se vor putea replica între ele, astfel clienții având sisteme de operare Windows 2000 sau Windows XP Profesional nu se vor putea autentifica în această rețea iar serverele cu Microsoft Exchange 2000 Server nu vor putea trimite e-mail-uri. În mod esențial serverele pe care nu este implementat într-un mod corect și stabil DNS-ul sistemul de operare Windows Server 2003 nu v-a face față.

Un aspect important este acela ca varianta Windows Server 2003 ediția Web nu necesită și nu suportă serviciul Active Directory.

2.2.1 DNS Privire de ansamblu

DNS-ul este un serviciu de rezoluție a numelui. Dacă încercăm să căutăm un server Online pe Web în mod clar acest server l-am memorat după numele lui www.microsoft.com nicidecum ca o adresă IP – 207.46.230.219. În orice caz PC-ul care încearcă această conexiune folosind Microsoft Web trebuie să cunoască adresa IP. Serviciul DNS translatează numele de site într-o adresă IP pentru a se putea executa conexiunea cu Site-ul.

Spații de nume ierarhice

DNS folosește spații ierarhice pentru a putea localiza PC-uri în cadrul unei rețele. În figura de mai jos se poate observa modul cum sunt organizate spațiile de nume. Domeniul root este începutul spațiului de nume DNS, și întregul spațiu de nume este localizat sub acest root.

După domeniul principal de pe primul nivel root urmează al doilea nivel unde de obicei sunt referite numele de companii care urmează să fie înregistrate de autoritatea Internet. După cel de-al doilea nivel urmează subdomeniile. De obicei subdomeniile se referă la departamentele sau diviziunile din cadrul unei companii. Aceste dubdomenii sunt înregistrate și întreținute de serverele DNS care conțin înformații despre nivelul al 2-lea din domeniu.

Baze de date distribuite

Înainte ca DNS-ul să fie implementate via Web toate resoluțiile de nume erau stocate într-un singur fișier. Odată cu creșterea numărului de gazde pe Internet întreținerea unui singur fișier a devenit impracticabil. În acest fel DNS-ul a fost menit să folosească baze de date distribuite.

Folosind o bază de date distribuită înseamnă că informația DNS este stocată pe mai multe calculatoare (fie că e vorba de Intranet sau Internet). Fiecare server DNS întreține doar o mică parte din baza de date DNS. Întreaga bază de date este distribuită în fișiere zonă bazate pe numele de domenii și distribuite pe mai multe servere.

Folosind această metodă cu bazele de date distribuite înseamnă ca nici un server de pe Web trebuie că stocheze toate informațiile referitoare la DNS. Multe din servere vor avea informații despre o porțiune din “Copaci”, dar când primesc solicitări care nu le pot soluționa aceste servere vor ști care server DNS conține informația dorită pentru a soluționa cererile.

Procesul de rezoluție a numelui

Un spațiu de nume DNS ierarhic și o bază de date distribuită vor fi folosite când un client încearcă să localizeze o adresă de IP dintr-o sursă Web (sursa exemplu test: www.NAmerica.Microsoft.com). Pentru a afla adresa de IP al sursei căutate se vor urma pașii de mai jos:

Clientul resolver începe să transmită o interogare recursivă serverului DNS(de obicei este vorba de serverul DNS al provider-ului de Internet). O astfel de interogare poate avea 2 posibile răspunsuri: – adresa de IP căutată de client sau mesajul de eroare care indică faptul că informația nu poate fi găsită.

Dacă serverul DNS al providerului conține informația dorită stocată într-un cache v-a returna adresa corectă de IP utilizatorului. Dacă nu o are acesta v-a încerca să găsească informația trimițând interogări iterative altui server care ar putea deține informația căutată. Răspunsul la o interogare iterativă poate fi ori o rezoluție care o caută clientul, ori o referință spre alt server DNS care ar putea soluționa interogarea.

Serverul root nu poate răspunde interogării, dar poate răspunde cu o listă de servere disponibile de pe nivelurile com de top. Acest proces furnizează serverele DNS alternative de contact și poate fi numită o sesizare/referință. Serverul DNS al provider-ului trimite interogări iterative unui astfel de server, încercând să afle adresa de IP dorită.

Serverul com răspunde cu o listă de servere responsabile domeniului dorit Microsoft.com. Serverul DNS al provider-ului v-a interoga serverul DNS al Microsoft.com, care v-a răspunde cu numele serverelor DNS care întrețin domeniul Namerica.Microsoft.com.

Serverul DNS Namerica.Microsoft.com conține toate informațiile despre domeniul căutat, deci v-a răspunde serverului DNS al provider-ului cu adresa de IP al gazdei căutate.

Severul DNS al provider-ului v-a răspunde interogării recursive recepționate de la clientul resolver și îi v-a trimite adresa IP al Web server-ului dorit.

În final calculatorul client se v-a conecta la adresa căutată www.NAmerica.Microsoft.com.

Tot acest proces de parcurs prin toți acești 7 pași se poate efectua foarte rapid, dar de obicei nu sunt necesari toți acești pași. Cand serverul DNS rezolvă orice tip de nume, salvează informațiile găsite într-un cache pentru o perioadă specifică de timp. Dacă după căutarea de mai sus v-a încerca cineva să redescidă aceeași pagină Web, serverul DNS îi v-a returna pagina într-un timp mult mai scurt deoarece o v-a extrage din acel cache.

Înregistrări de resurse

Actualele înregistrări stocate în fișiere zone DNS sunt denumite RRs (Resource Records). Acestea conțin informațiile actuale despre domeniu și se pot crea 22 tipuri diferite de resurse de acest tip pe platforma DNS – Windows Server 2003 server.

Cele mai importante înregistrări RR sunt descrise în tabelul de mai jos:

În figura de mai sus este descris modul de completare al unei înregistrări SOA în utilitarul administrativ al unui DNS. Înregistrările DNS pot fi scrise deasemenea și în mod simplu text pentru un host standard al unui server Web1.Microsoft.com astfel :

Web1.Microsoft.com IN A 192.168.1.100

Domenii DNS, Zone și Servere

Unul din aspectele cele mai importante ce vizează modul de utilizare al DNS este înțelegerea terminologiei folosite în descrierea componentelor DNS.

Una din problemele legate de terminologii este confuzia creată la diferența dintre domenii și zone. Una din metodele de a înțelege diferența este faptul că domeniul este o parte a unui spațiu de nume DNS iar zona este informația ce descrie acea parte din DNS.

De exemplu: O companie care deține un domeniu de nivel doi Microsoft.com. Acest lucru înseamnă că aceasă companie deține o parte din întregul spațiu de nume DNS – acesta este domeniul lor. Când compania implementează un server DNS pentru domeniu atunci toate informațiile despre acest domeniu sunt stocate într-unul sau mai multe servere DNS. Aceste informații includ RRs pentru toate PC-urile din domeniul DNS. Informațiile referitoare la fiecare domeniu reprezintă zona de informații și este stocață în fișiere zonă în serverele DNS.

Există două tipuri de fișiere zonă în DNS:

zona forward lookup: este folosită în primul rând pentru a transforma un hostname într-o adresă IP. Înregistrarea Host (A) (din tabela de înregistrări RR) furnizează această facilitate. Această zonă deasemenea include înregistrări de tipul SOA, NS, MZ, CNAME și SRV și este folosită când un client interoghează un server DNS pentru a localiza adresa IP a unui server din cadrul rețelei;

zona reverse lookup: execută funcțiile opuse zonei forward lookup, mai exact este folosită când o adresă IP a unei gazde este cunoscută și se dorește aflarea numelui gazdei (hostname). Această zonă include înregistrări SOA, NS și PTR.

Numele unei zone forward lookup reprezintă numele domeniului însă în contrast cu numele acestei zone, numele zonei reverse lookup este mult mai dificil de aflat deoarece este folosită adresa de IP a subrețelei, și nu se știe numele domeniului. Când vom crea o zonă reverse lookup v-a trebui să îi alocăm și un nume acestei zone bazat pe adresa de IP a subrețelei.

De exemplu:

creare zonă reverse lookup pentru subrețeaua 192.168.1.0

numele zonei v-a fi 1.168.192.in-addr.arpa

Servere de nume primare

Un server de nume primar este singurul server cu o copie modificabilă a unei versiuni de fișier zonă (zona localizată pe serverul primar de nume se mai numește și primary zone). Acest lucru înseamnă că administratorul serverului DNS v-a trebui să aibă acces pe serverul primar de nume la orice modificare adusă zonei de informații. După efectuarea unei modificări în fișierele zonă, datele se vor replica pe serverele secundare de nume folosind procesul numit zone transfer.

Servere de nume secundare

Un server de nume secundar are o copie read-only a fișierului zonă. Singurul mod de a modifica fișierul zonă pe serverul de nume secundar este prin zona de transfer de pe serverul primar.

RFC1995 a introdus o metodă de transfer a zonelor mult mai eficientă denumită incremental zone transfer prin care modificările aduse fișierelor zonă de la ultimul transfer sunt replicate pe serverul secundar. O altă îmbunătățire adusă procesului zonei de transfer descrisă în RFC 1996 este mecanismul de notificare care activează pe serverul primar de nume o alertă ce se v-a transmite serverului secundar de nume când are loc o modificare pe fișierele de zonă. Fără o notificare prealabilă serverele secundare de nume vor contacta serverele primare de nume la un anumit interval pentru un refresh pe înregistrările SOA al fiecărei zone.

Serverul DNS de pe Windows 2003 Server suportă zona incrementală și notificările, deasemenea suportă și zonele integrate AD unde o zonă de transfer obișnuită este înlocuită de o replicare AD.

Zonele de autoritate

Ca să înțelegem în totalitate acest sistem DNS trebuie să fim familiari cu zonele de autoritate sau cu serverele de nume autoritare. Fiecare server de nume primar și secundar sunt autoritare pentru domeniul pe care îl reprezintă.

De exemplu: dacă un server DNS conține fișierul de zonă pentru domeniul Microsoft.com, atunci acel server este un server de nume autoritar pentru acel domeniu.

Multe companii își configurează serverul DNS într-un mod similar celui din figura de mai jos. Într-un astfel de scenariu există două servere DNS primare configurate pentru domeniul Microsoft.com. DNS1 conține înregistrarea host pentru serverul denumit Web1.Microsoft.com, dar DNS2 nu conține această înregistrare. Când un client se conectează la serverul DNS1, serverul v-a fi capabil s-a afle adresa de IP pentru Web1. Dacă același client sau altul se conectează la serverul DNS2 și cere adresa de IP pentru Web1, serverul îi v-a răspunde că nu acest host nu poate fi găsit. Pentru că DNS2 este autoritar pentru domeniul Microsoft.com, acesta nu v-a retrimite cererile către serverul DNS1 chiar dacă DNS2 a configurat serverul DNS1 ca forwarder/root agent, acesta nu v-a forwarda niciodată cererile către celălalt server, pentru că este autoritar pentru domeniul Microsoft.com. Acest comportament este datorat design-ului și oferă un avantaj din punctul de vedere al securității.

Zone delegate

DNS folosește spații de nume ierarhice, din această cauză există o metodă de a interconecta nivelurile ierarhice.

De exemplu: dacă un client se conectează la un server autoritar pentru domeniul de nivel 1 com, și are o cerere pentru domeniul Microsoft.com, serverul com trebuie să determine ce servere de nume sunt autoritare pentru domeniul Microsoft.com.

Acest aspect este rezolvat prin folosirea delegării înregistrărilor (delegation records). O înregistrare cu delegare este un pointer către un domeniu lower-level scăzut care identifică serverele de nume pentru domeniul lower-level.

În figura de mai sus DNS1.Microsoft.com este un server de nume autoritar pentru domeniul Microsoft.com. DNS2 și DNS3 sunt servere de nume autoritare pentru domeniul NAmerica.Microsoft.com. DNS1 este considerat autoritar pentru domeniul NAmerica.Microsoft.com dar nu are toate înregistrările resursă pentru domeniul copil. Totodată DNS1 deleagă înregistrarea către DNS2 și DNS3 ca servere de nume pentru domeniul copil. Când un client se conectează pe DNS1 furnizează o cerere de informație despre NAmerica.Microsoft.com, serverul v-a referi catre serverele de nume din domeniul copil.

O altă metodă de interconexiune între diferitele nivele din ierarhia DNS este folosirea root hints și a redirectărilor (forwarders). În cele mai multe cazuri redirectările și root hints sunt folosite de acele DNS-uri de pe nivelele inferioare în cadrul unui spațiu de nume DNS pentru a localiza informația de pe serverele DNS aflate pe nivelele superioare în ierarhie. Ambele metode de interconexiune sunt folosite de un server DNS pentru a localiza informația care nu se regăsește în fișierul zonă atașat.

Un forwarder este de fapt un alt server DNS pe care un alt server DNS îl folosește în momentul în care nu poate soluționa o interogare.

În momentul finalizării înstalării platformei Windows Server 2003 serverul DNS are automat acces la Internet iar lista de servere root este și ea configurată automat. Aceste servere autoritare pentru spațiul de nume de pe Internet. Daca serverul DNS primește o interogare pentru o zonă DNS fără autoritate pentru serverul curent, acesta din urmă v-a trimite o interogare iterativă către unul dintre serverele root până numele este rezolvat sau până serverul v-a confirma faptul că numele nu este rezolvat.

Serverele root configurate automat pe serverul DNS sunt copiate din fișierul Cache.dns inclus odată cu fișierele de instalare ale serverului DNS. Se pot adăuga servere DNS adiționale pe lista root hint incluzând serverele DNS în cadrul rețelei interne.

Serviciul Active Directory nu poate funcționa fără a avea configurat optim un server DNS. Fără DNS, controlerele de domeniu nu se pot localiza pentru a putea replica informațiile referitoare la domeniu. Acest aspect duce la funcționarea greoaie a clienților Windows 2000 și Windows XP Profesional în momentul localizării controlerelor de domeniu și pentru a se autentifica.

Restul platformelor mai vechi, ca Windows 95, 98, ME și NT nu se conectează la un server DNS pentru a localiza controlerele de domeniu Windows Server 2003. Acești clienți trebuie să folosească nume NetBIOS pentru a putea localiza controlerele de domeniu precum și de a avea configurat Windows Internet Naming Service (WINS) pentru a rezolva transformarea numelor NetBIOS în adrese IP. În mod standard, Windows 2003 Server suportă aceste platforme mai vechi prin înregistrarea numelor NetBIOS cu WINS.

2.2.2 Serviciul DNS Locator

DNS este foarte important în Active Directory deoarece furnizează informațiile de care un client are nevoie pentru a putea localiza controlerele de domeniu în rețea.

Exemplu: Pe platforma Windows NT, autentificarea a fost bazată pe numele NetBIOS. Fiecare controler de domeniu este înregistrat cu nume NetBIOS – Domainname cu un <1C> ca al 16-lea caracter din nume în rețea și în WINS. Când clientul încearcă să se autentifice în rețea, v-a incerca să localizeze serverele pe care sunt înregistrate numele controlerelor de domeniu înregistrate. Dacă acest client nu poate localiza nici un server autentificarea v-a eșua.

Înregistrările SRV din Windows 2003 sunt folosite de Windows 2000 și Windows XP Profesional pentru a localiza controlerele de domeniu. Fără aceste înregistrări, acești clienți nu vor putea să se autentifice într-un domeniu Windows Server 2003.

În următorul tabel voi prezenta componentele unei înregistrări SRV:

În mod esențial informația din această înregistrare spune că dacă un client caută un server LDAP – Lightweight Directory Access Protocol în domeniul Microsoft.com, clientul ar trebui să se conecteze la dc2.microsoft.com.

Controlerele de domeniu pe platforma domeniului Windows Server 2003 stochează mai multe înregistrări în DNS.

Exemplu înregistrare SRV:

_ldap._tcp.microsoft.com. 600 IN SRV 0 100 389 dc2.microsoft.com

Prima parte dintr-o înregistrare SRV identifică serviciul spre care pointează înregistrarea. Posibilele servicii sunt:

_ldap – AD este un serviciu director LDAP având controlerele de domeniu cu funcții de operare ca servicii LDAP. Aceste înregistrări identifică serverele LDAP (controlerele de domeniu Windows Server 2003 sau alte servere LDAP) disponibile în rețea;

_kerberos – Protocolul primar de autentificare pentru toți clienții Windows 2000 și Windows XP Profesional. Înregistrarea _kerberos SRV identifică toate KDCs – Key Distribution Centers din rețea, acestea pot fi controlere de domeniu sau alte servere KDC;

_kpassword – Înregistrarea _kpassword SRV identifică serverele password-change din rețea (ori controlerele de domeniu Windows Server 2003, sau alte servere kerberos password-change);

_gc – Înregistrarea _gc SRV este specifică funcției unui catalog GC în Active Directory. Serverul GC au rolul unor funcții importante din cadrul AD.

2.3 Crearea și întreținerea obiectelor de tip utilizatori

Serviciul Active Directory trebuie să treacă printr-un proces individual de verificare a identității – proces numit și autentificare – înainte ca utilizatorul să aibă acces la resursele necesare. Fundamentul autentificării reprezintă contul de utilizator, care conține un nume de login, o parolă și un identificator unic (SID).

În timpul procesului de login, serviciul AD autentifică numele de utilizator și parola introdusă. Ulterior subsistemul de securitate creează un ticket care reprezintă utilizatorul. Ticketul de acces conține SID-ul identic cu cel al grupului din care face parte utilizatorul și poate fi folosit ulterior pentru a verifica drepturile de care are parte utilizatorul local în sistem și autorizarea de acces la resursele securizate prin ACL.

Contul de utilizator este integrat în obiectul utilizator din cadrul serviciului AD. Acest obiect include nu doar numele de utilizator, parola și SID dar și informații de contact cum sunt numere de telefon și adresa, titlul job-ului, tipul de membership, profil roaming, serviciu terminal, acces la distanță, setări pentru accese de la distanță.

Pentru a crea un obiect utilizator, selectăm containerul în care dorim crearea acestui obiect accesând din meniu butonul Action, Domain Admins sau grupul Account Operators, v-a trebui să avem delegate permisiunile de creare de obiecte utilizatori pentru acest container. Dacă nu avem aceste drepturi delegate nu vom avea acces la crearea de noi utilizatori, ca atare comanda New User nu v-a fi disponibilă.

În fereastra de mai jos voi prezenta modul de adăugare a unui nou obiect utilizator:

Descrierea câmpurilor necesare adăugării unui nou obiect de tip utilizator

First Name – Numele utilizatorului. Nu este un câmp obligatoriu.

Initials – Inițialele numelui utilizatorului. Nu este câmp obligatoriu.

Last Name – Prenumele utilizatorului. Nu este un câmp obligatoriu

Full Name – Numele complet al utilizatorului. Dacă în câmpurile first name și last name avem completate corespunzător câmpul full name se completează automat cu cele 2 valori. Campul este obligatoriu de completat. Numele completat în acest câmp generează proprietăți ale obiectului, în special CN (common name), DN (distinguished name), numele complet și displayName (numele ce v-a fi afișat). Deoarece valoarea CN trebuie să fie o valoare unică în cadrul container-ului, numele completat în câmpul full name trebuie să fiu unic relativ la celelalte obiecte din cadrul Unității Organizaționale (OU) unde vom crea obiectul utilizator.

User Logon Name – UPN – User Principal Name conține numele de login folosit la autentificare și un suffix ce este de fapt numele DNS al domeniului unde se v-a creea acest obiect logon-name@UPN-suffix, trebuie să fie unic în cadrul “Pădurii” AD. Exemplu de UPN: [anonimizat]. Numele UPN poate fi folosit pentru autentificare către orice platforma Microsoft Windows care rulează Windows 2000, Windows XP sau Windows 2003.

User Logon Name(Pre-Windows 2000) – Acest nume de autentificare utilizator este folosit pentru autentificarea de pe o platforma Microsoft Windows mai veche cum este: Windows 95, Windows 98, Windows Me, Windows NT4 sau Windows NT 3.51. Acest câmp este obligatoriu și trebuie să fie unic în cadrul domeniului.

După completarea tuturor câmpurilor se v-a trece la următoarea pagină prin acționarea butonului Next, după cum urmează:

În cea de-a doua pagină în procesul de creare obiect utilizator trebuie să introducem parola de autentificare și confirmarea ei urmată de câteva opțiuni pentru această parolă.

Politică de securitate a parolelor

Politica de conturi a domeniului Windows Server 2003 setată în grupul GPO necesită folosirea unei parole complexe care să conțină un minim de șapte caractere. Acest aspect presupune trei din patru tipuri de caractere: litere mari, litere mici, numerice și non-alfa-numerice.

Password – Parola care v-a fi folosită de utilizator la autentificare. Din motive de securitate trebuie alocată o parolă pentru fiecare cont creat, care v-a fi mascată în momentul tastării.

Confirm Password – Confirmarea parolei prin introducerea ei a doua oară în mod corect.

User Must Change Password At Next Logon – Acest check-box dacă este selectat are utilizatorul v-a trebui să schimbe parola la prima autentificare. Dacă avem selectată opțiunea de mai jos Password Never Expires această opțiune nu v-a fi activă.

User Cannot Change Password – Selectând acest check-box avem posibilitatea de a utiliza același cont de mai multe persoane în același domeniu (Guest) sau pentru a menține controlul asupra acestui cont de utilizator. Această opțiune nu poate fi selectată dacă avem selectată opțiunea User Must Change Password At Next Logon.

Password Never Expires – Selectăm această opțiune dacă dorim ca parola să nu aibă un termen de valabilitate.

Account Is Disabled – Prin selectarea acestei opțiuni vom dezactiva acest cont de utilizator, de exemplu când creem un obiect pentru angajații noi în cadrul unei companii care încă nu au acces în rețea.

Când am creat un utilizator, suntem solicitați să configurăm cele mai importante proprietăți aferente utilizatorului cum ar fi numele de utilizator și parola de autentificare. Totodată obiectele utilizator suportă numeroase alte proprietăți configurabile în orice moment folosind serviciul Active Directory Users And Computers. Pentru a ajunge la aceste proprietăți suplimentare selectăm utilizatorul nou creat, selectăm opțiunea Action din meniu și alegem opțiunea Properties sau mai simplu selectăm contul creat apoi click dreapta și alegem opțiunea Properties și ne v-a apare fereastra de mai jos:

În cele ce urmează voi descrie cateva din categoriile de proprietăți, cele mai importante ale ferestrei de descriere a conturilor de utilizatori din cadrul serviciului Active Directory.

Account properties: – Account – Proprietățile aferente acestui tab sunt aceleași cu cele introduse la momentul în care am creat contul obiect incluzând aici numele de autentificare, parola și câteva câmpuri opționale de selectat.

“Logon Hours” este folosit pentru a configura intervalul orar în care utilizatorul este îndreptățit să se autentifice în rețea.

“Log On To” este folosit dacă dorim să limităm stațiile (calculatoarele) la care acest utilizator să se poată conecta. Acest aspect mai este numit și Computer Restrictions în alte zone ale interfeței. Pentru a beneficia de această facilitate trebuie instalat și configurat NetBIOS pe protocolul TCP/IP deoarece folosește numele calculatorului în locul adresei MAC pentru a restricționa autentificarea.

Personal Information: – Următoarele tab-uri General, Adresa, Telefoane și Organizația reprezintă niște tab-uri cu informații cu caracter personal referitoare la datele de contact ale utilizatorului contului nou creat.

User configuration management: – Tab-ul Profile din fereastra proprietăți utilizator reprezintă configurațiile referitoare la profilul utilizatorului, scriptul de autentificare, locația fișierelor personale.

Group membership: – În tab-ul Member Of putem adăuga sau șterge grupuri de utilizatori precum și setarea grupului primar din care v-a face parte contul curent.

Terminal Services: – Tab-urile Terminal Services Profile, Environment, Remote Control și Session ne asigură posibilitatea de a configura și întreține experiența utilizatorului în momentul conexiunii cu sesiunea Terminal Services.

Remote access: – Tab-ul Dial-in ne asigură posibilitatea de a configura drepturile accesului de la distanță (remote) ale utilizatorului.

Applications: – Tab-ul COM+ asignează partiția COM+ a serviciului Active Directory setată pentru utilizator. Această facilitate nouă în cadrul platformei Windows Server 2003 facilitează managementul aplicațiilor distribuite.

Întreținerea proprietăților pe mai multe conturi simultan

Platforma Windows Server 2003 ne ajută cu facilitatea de a putea modifica proprietățile mai multor conturi de utilizatori în același timp. În cel mai simplu mod se selectează obiectele create prin ținerea apăsată a tastei CTRL în momentul selecției fiecărui cont sau prin folosirea oricărei altă opțiune de selecție multiplă. Trebuie avut în vedere faptul că selecția se face doar pe obiectele din aceeași clasă cum sunt obiectele utilizatori. După selecția tuturor conturilor pe care vrem să le modificăm proprietățile accesăm butonul Action din meniu urmat de Properties. Odată cu selecția multiplă avem acces de modificare la un subset de proprietăți cum sunt:

General: Description, Office, Telephone Number, Fax, Web Page, E-mail

Account: UPN Suffix, Logon Hours, Computer Restrictions (logon workstations), all Account Options, Account Expires

Address: Street, PO Box, City, State/Province, ZIP/Postal Code, Country/Region

Profile: Profile Path, Logon Script, Home Folder

Organization: Title, Departament, Company, Manager

Aspectul de resetare și redenumire a obiectelor conturi de utilizator se vor efectua în continuare obiect cu obiect nu simultat prin selecție multiplă. Un alt aspect deosebit de important este acela că în platforma Windows Server 2003 avem posibilitatea de drag-and-drop, mai exact putem muta obiecte între Unități Organizaționale (OUs) prin drag and drop în Snap-in-ul Active Directory Users And Computers.

2.3.1 Întreținerea profilelor utilizator

Există momente în care ne dorim ca în momentul deschiderii calculatorului să avem acces imediat la paginile favorite salvate în Internet Explorer sau să regăsim în aceeași ordine icoanele de pe desktop după cum le-am salvat înainte cu 1-2 zile. Toate aceste aspecte construiesc anumite configurări suplimentare pen profilul unui cont de utilizator. Profilele pot fi configurate pentru a-i îmbunătăți securitatea, încrederea, fiabilitatea și nu în ultimul rând disponibilitatea.

Un profil de utilizator este o colecție de foldere și fișiere cu date care conțin elemente din cadrul mediului Desktop care îl pot face unic. Dintre aceste elemente putem aminti:

Scurtături în meniul de Start, icoane de pe desktop, icoane din Quick Launch;

Documente pe Desktop sau redirectarea icoanelor în folderul My Documents. Acest proces de salvare redirectată de pe desktop direct în folderul My Documents ne ajută ca datele salvate să poată fi scanate împotriva virușilor, creare de backup periodic pe server. Folderul My Documents poate fi întreținut în așa fel încât poate fi folosit și cu setări de Offline – în afara rețelei precum și Online – doar când utilizatorul este conectat în rețea.

Pagini favorite și cookie-uri în Internet Explorer;

Certificate – dacă sunt implementate;

Accesul la aplicații specifice cum este Microsoft Office;

My Network Places;

Setări de vizualizare desktop, „Appearance”, “Wallpaper” și Screensaver.

Aceste elemente sunt specifice fiecărui utilizator în parte.

Profil de utilizator local

În mod standard profilul unui utilizator este salvat local în folderul %Systemdrive%\Documents and Settings\%Username%. Profilele utilizatorilor operează în felul următor:

Când un utilizator se autentifică pentru prima dată, sistemul creează un profil pentru acest utilizator copiindu-i profilul Default User. Noul folder profil este denumit după numele de login specifica la prima autentificare.

Toate modificările efectuate pe desktop-ul utilizatorului și al mediului software sunt stocate în profilul utilizatorului. Fiecare utilizator are un profil individual deci setările sunt specifice fiecărui utilizator în parte.

Mediul utilizatorului este extins în profilul “All Users”, care poate include icoane de pe desktop, meniul de start, “network places”. Elementele unui profil “All users” sunt combinate cu profilul utilizatorului curent. Doar utilizatorii din grupul “Administrators” pot efectua modificări pe grupuri sau pe profilul “All Users”.

Profilul este în totalitate local. Dacă acest utilizator se autentifică pe un alt sistem, nu v-a avea acces la documentele și setările personale profilului creat pe celălalt sistem. Deci utilizatorul se autentifică din nou pentru prima dată pe noul sistem și trebuie să-și facă din nou aceleași configurații de la început.

Profil de utilizator la distanță

Dacă utilizatorii lucrează la mai multe calculatoare, se poate configura profiluri de utilizatori la distanță (Roaming User Profiles-RUPs) pentru a fi siguri că vor avea acces la aceleași fișiere și setări de oriunde s-ar autentifica în cadrul aceleiași rețele. RUP stochează profilele direct pe server ceea ce înseamnă că profilele pot fi salvate prin backup ulterior, scanate împotriva virușilor, și controlate centralizat. Dacă un sistem al unui utilizator s-a defectat și este necesară reinstalarea acestuia profilul RUP al utilizatorului v-a avea grijă ca după finalizarea reinstalării desktop-ul să devină același cu cel de dinaintea defecțiunii adică să conțină aceleași setări/configurații și aplicații instalate.

Pentru a configura un profil RUP, se creează un folder partajat pe un server de fișiere care este în mod frecvent preinstalat cu sistem de backup periodic. Permisiunile de partajare pentru acest folder v-a trebui să fie cu drepturi depline. Pe platforma Windows Server 2003 modul standard de partajare permite doar modul Read Only ceea ce nu este suficient pentru un profil RUP de fișier partajat.

În tab-ul Profile din fereastra de proprietăți al user-ului se tastează calea spre Profilul utilizatorului după cum urmează: \\<server>\<share>\%Username%. Variabila %Username% v-a fi automat înlocuită cu numele de login al utilizatorului.

În momentul în care utilizatorul se autentifică sistemul v-a identifica locația folderului profilului RUP creat și alocat acestui utilizator. Când utilizatorul părăsește sistemul prin logoff, se v-a face un upload al profilului pe server. Ulterior utilizatorul se v-a putea autentifica și din altă parte din cadrul rețelei și al domeniului și v-a avea acces la aceleași fișiere și setări în cadrul sistemului. Dacă un utilizator se autentifică sau părăsește de mai multe ori un calculator, sistemul v-a copia pe server doar modificările aduse ulterior autentificărilor.

Conturi grup

Utilizatorii, grupurile și calculatoarele sunt obiectele cheie în serviciul director AD deoarece îi lasă pe angajați, managerii angajaților, administratorii de sistem și oricărei persoane care utilizeaza un calculator în cadrul rețelei – pentru a-și stabili identitatea în rețea ca politică principală. Fără această identificare, personalul nu poate avea acces la PC-uri, aplicații și informațiile de au nevoie la locul de muncă. Asignarea permisiunilor la sunte de utilizatori individual nu este o metodă scalabilă; utilizarea pe scară largă a grupurilor de utilizatori îmbunătățește crearea și administrarea permisiunilor mult mai bine.

Grupurile sunt containere care conțin utilizatori și obiecte PC ca membri. Când sunt creeate mai multe seturi de permisiuni pentru un grup în ACL (Access Control List) pe o anumită resursă, toți membrii din acel grup primesc aceste seturi de permisiuni.

Platforma Microsoft Windows Server 2003 are două tipuri de grupuri fiecare cu câte trei scopuri distincte: securitate și distribuție.

Grupurile de securitate sunt folosite pentru a asigura permisiuni de acces la resursele unei rețele.

Grupurile de distribuție sunt folosite pentru a combina utilizatorii pentru mai multe liste de distribuție via e-mail.

Grupurile de securitate pot fi folosite ca niște grupuri de securitate însă grupurile de distribuție nu pot fi folosite ca grupuri de securitate. Planificarea corectă a structurii de grupuri afectează într-un mod sau altul scalabilitatea și mentenanța în special în mediul enterprise unde sunt implicate mai multe domenii.

Scopul grupului/grupurilor definește cum vor fi asignate permisiunile membrilor de grup. Grupurile de pe platforma Windows Server 2003 ambele grupuri de securitate și distribuție sunt clasificate într-unul din cele 3 scopuri de grup: domeniul local, domeniul global și domeniul universal.

2.4.1 Grupuri și domenii locale

Grupurile locale sunt folosite în mod primordial pentru o compatibilitate cu Windows NT4. Există useri și grupuri locale cu PC-uri pe care rulează Windows Server 2003 configurate ca servere membru. Controlerele domeniu nu folosesc grupuri locale. Aceste grupuri pot include membrii din orice domeniu în cadrul unei “Păduri” dintr-un domeniu cu “încredere” pentru alte “Păduri” și din domenii de nivel scăzut și sunt folosite în mod primordial pentru a asigna permisiuni grupurilor globale pentru resursele dintr-un domeniu local.

2.4.2 Grupuri globale

Grupurile globale sunt folosite pentru a furniza o apartenență categorizată într-un grup de domenii locale pentru principii de securitate individuale sau asignări de permisiuni directe. De cele mai multe ori grupurile globale sunt folosite pentru a colecta utilizatori sau PC-uri din același domeniu pentru a partaja același job, rol sau funcție.

Grupurile globale au următoarele facilități:

pot include doar membri din cadrul domeniului;

un membru poate fi făcut din cadrul unei mașini/stații de lucru locale sau dintr-un grup local al domeniului;

pot fi asigurate permisiuni în orice tip de domeniu;

poate conține și alte grupuri globale.

2.4.3 Grupuri universale

Grupurile universale sunt folosite pentru a asigura acces la resurse în toate domeniile care dețin o “încredere”, dar grupurile universale pot fi folosite ca principiu de securitate pe platformele Windows 2000 native sau Windows Server 2003.

Grupurile universale pot include membri din orice domeniu în cadrul unei “Păduri”

Scopul unui grup este determinat de timpul de creare.

Există câteva grupuri speciale denumite identități speciale (special identities) care sunt întreținute de sistemul de operare. Aceste identități nu pot fi create sau șterse și nici nu poate fi modificate calitățile de membership de administratori. Identitățile speciale nu apare în modulul Active Directory Users And Computers sau în orice altă aplicație de management al PC-urilor însă pot fi asignate ca permisiuni în listele ACL.

În următorul tabel se vor explica în detaliu identitățile speciale de pe platforma Windows Server 2003:

Acestor grupuri pot fi asignate permisiuni asupra resurselor de rețea, totuși trebuie avută grijă când se alocă o permisiune unuia din aceste grupuri. Membrii acestor grupuri nu sunt în mod pbligatoriu autentificați într-un domeniu. De exemplu asignăm dreptul de share pe grupul Everyone, utilizatorii care se conectează dintr-un alt domeniu vor avea acces la acest share. În fereastra de mai jos se pot observa câmpurile necesare pentru crearea unui obiect user în cadrul unui domeniu contoso.com:

După ce am creat sau am șters vreun membru dintr-un grup v-a trebui prin intermediul AD sa-i modificăm proprietățile după cum urmează în fereastra de mai jos:

Computer Accounts

Cofigurația de bază a Windows Server 2003 precum și a celorlalte sisteme de operare Microsoft Windows este aceea că PC-ul face parte dintr-un Workgroup. În cadrul acestui Workgroup PC-urile cu Windows NT (Windows NT4, Windows 2000, Windows XP și Windows Server 2003) pot autentifica utilizatori doar din baza de date SAM locală. Un utilizator conectat la acel calculator se poate conecta la fișierele partajate de pe alte stații din cadrul Workgroup-ului sau a domeniului, utilizatorul nu este niciodată conectat și autentificat pe calculatorul local cu un cont de domeniu.

Înainte de a ne putea autentifica pe calculator cu un cont de utilizator de domeniu, acel calculator trebuie să aparțină unui domeniu. Există doi pași necesari pentru a putea include într-un domeniu un calculator:

crearea contului pentru acel calculator;

configurarea calculatorului pentru a putea fi inclus în domeniu folosind acel cont.

Calculatoarele își întrețin conturile exact cum fac utilizatorii și aici vorbim despre un nume, o parolă și un SID (security identifier). Acele proprietăți sunt încorporate în clasa obiect calculator din cadrul AD.

Crearea unei clase obiect calculator în cadrul unui serviciu AD se face folosind serviciul Active Directory Users And Computers – selectăm containerul sau OU (unitatea organizațională) în care dorim crearea obiectului – după care din meniul Action – New Computer și ne v-a apare fereastra următoare:

În această fereastră vom completa informațiile necesare pentru a crea un obiect calculator. După ce am creat contul obiect vom include calculatorul în cadrul domeniului, mai exact pentru a crea o relație securizată între domeniu și stația locală folosind următorii pași – autentificați cu drepturi depline de Administrator:

Click dreapta pe icoana My Computer de pe desktop –> Properties –> alegem tab-ul Computer Name care mai este numit și Network Identification pe sistemele Windows 2000.

Alegem Change unde vom putea modifica numele și domeniul & membership workgroup al stației.

După ce am efectuat modificările aferente noului domeniu din care v-a face parte stația dăm click pe OK și în mod normal stația trebuie să se conecteze cu domeniul nostru. Dacă apare probleme cu conexiunea cu domeniul trebuie examinată conectivitatea cu rețeaua precum și configurația DNS și cea de rețea aferentă stației. Dacă relația de conexiune cu domeniul s-a efectuat cu succes v-a apare următoarea figură unde suntem averitzați să introducem username și parola aferente permisiunilor din domeniu pentru a ne conecta în domeniu.

Dacă nu avem creat un cont de domeniu din clasa obiecte calculatoare cu numele similar cu cel am calculatorului, AD v-a crea automat un cont automat în containterul standard după care se v-a crea legătura de conexiune între domeniu și stație. Ulterior v-a trebui să identificăm stația în AD, îi modificăm permisiunile și contul după care se restartează stația pentru a seautentifica în domeniu.

Bibliografie

Steve Clines, Marcia Loughry – Active Directory For Dummies;

John Dias – A guide to Microsoft Active Directory (AD) Design;

Dan Holme, Orin Thomas – Managing and Maintaining a Microsoft Windows Server 2003 Environment, Microsoft Press, 2004;

Robbir Allen, Alistair G. Lowe-Norris – Active Directory, 2nd Edition, O’Reilly, April 2003;

Robbie Allen, Alistair G. Lowe-Norris, Joe Richards – Active Directory 3rd Edition, O’Reilly, January 2006;

Robbie Allen, Laura E. Hunter – Active Directory Cookbook, 2nd Edition, O’Reilly, June 2006;

Robbie Allen – Active Directory Cookbook for Windows 2003 & Windows 2000, O’Reilly, September 2003;

Active Directory for Microsoft Windows Server 2003 Technical Reference, 2003;

Site-uri Web:

www.wikipedia.org (Virtual Library)

www.google.ro (Search Engine)

http://technet.microsoft.com (Microsoft – Virtual Library)

http://msdn.microsoft.com (Microsoft – Virtual Library)

Bibliografie

Steve Clines, Marcia Loughry – Active Directory For Dummies;

John Dias – A guide to Microsoft Active Directory (AD) Design;

Dan Holme, Orin Thomas – Managing and Maintaining a Microsoft Windows Server 2003 Environment, Microsoft Press, 2004;

Robbir Allen, Alistair G. Lowe-Norris – Active Directory, 2nd Edition, O’Reilly, April 2003;

Robbie Allen, Alistair G. Lowe-Norris, Joe Richards – Active Directory 3rd Edition, O’Reilly, January 2006;

Robbie Allen, Laura E. Hunter – Active Directory Cookbook, 2nd Edition, O’Reilly, June 2006;

Robbie Allen – Active Directory Cookbook for Windows 2003 & Windows 2000, O’Reilly, September 2003;

Active Directory for Microsoft Windows Server 2003 Technical Reference, 2003;

Site-uri Web:

www.wikipedia.org (Virtual Library)

www.google.ro (Search Engine)

http://technet.microsoft.com (Microsoft – Virtual Library)

http://msdn.microsoft.com (Microsoft – Virtual Library)