Tag Archives: Active Directory

AdminSDholder, SDProp si “Protected Groups”


Active-Directory-logo

AdminSDholder, SDProp si “Protected Groups”

De cele mai multe ori ne lovim sau aflam de AdminSDHolder atunci cand permisiunile delegate unui obiect dispar.

Cateva exemple care ne atrag atentia in acest sens ar fi pierderea delegarilor facute in Active Direcctory, device-uri BlackBerry/ActiveSync care nu se sincronizeaza cu serverele de Exchange, sau permisiuni insuficiente in administrarea serverelor de Lync. Posibil sa fie si alte scenarii acestea sunt doar cateva.

Ce este AdminSDHolder?

Un mecanism de protectie al permisiunilor membrilor unor grupuri ‘administrative’.

Pe scurt, fiecare domeniu din forest are un obiect AdminSDHolder care se gaseste in containerul System.

adminSDHolder

Acesta tine permisiunile default pentru anumite grupuri protejate. Grupurile protejate difera in functie de vesiunea de Windows Server dar se poate ‘edita’ lista de grupuri ‘Protected Groups’.

Acestea sunt grupurile protejate implicite per versiune de server:

Windows 2000 Server RTM Windows 2000 Server with SP1 Windows 2000 Server with SP2 Windows 2000 Server with SP3 Windows 2000 Server with SP4 Windows Server 2003 RTM Windows Server 2003 with SP1 Windows Server 2003 with SP2 Windows Server 2008 RTM Windows Server 2008 R2
Administrators Account Operators Account Operators Account Operators
Domain Admins Administrator Administrator Administrator
Enterprise Admins Administrators Administrators Administrators
Schema Admins Backup Operators Backup Operators Backup Operators
Cert Publishers Domain Admins Domain Admins
Domain Admins Domain Controllers Domain Controllers
Domain Controllers Enterprise Admins Enterprise Admins
Enterprise Admins Krbtgt Krbtgt
Krbtgt Print Operators Print Operators
Print Operators Replicator Read-only Domain Controllers
Replicator Schema Admins Replicator
Schema Admins Server Operators Schema Admins
Server Operators Server Operators

Cum functioneaza AdminSDHolder?

Pe domain controller-ul ce tine rolul de PDC emulator ruleaza by default la un interval de 60 de minute un proces numit SDPprop (Security Descriptor Propagator) ce compara permisiunile ACL pentru membrii grupurilor protejate cu acelea de pe AdminSDHolder. (Acest process se poate initializa si manual, vezi aici.)

Se mai poate modifica intervalul folosind urmatoarea cheie pana la max 2 ore dar nu este recomandat datorita overheadului generat de procesul LSASS.

REG ADD HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /V AdminSDProtectFrequency /T REG_DWORD /F /D 600

Microsoft recomanda ca ‘best practice’ sa avem un set de 2 conturi in Active Directory. Un cont obisnuit pentru rutinele de zi cu zi si un alt cont cu drepturi administrative pe care s ail folosim atunci cand trebuie sa efectuam operatiuni cu drepturi elevate. Nu intotdeauna se respecta aceasta situatie.

De exemplu, daca un user cu drepturi normale (cu casuta de email, device mobil cu activesync) face parte din unul din grupurile de mai sus, poate a fost adaugat in Print Operators sa administreze cine stie ce print server, la un moment dat acel user se poate trezi ca nu se mai sincronizeaza device-ul mobil cu activesync sau daca avea ceva delegari mai speciale acestea nu mai sunt in efect.

Deasemenea, daca face parte dintr-un grup de securitate sau distributie. Asa ca group nesting este valabil in acest caz.

Daca se prezinta astfel de simptome, primele lucruri care trebuiesc verificate sunt urmatoarele:

AdminSDHolder2

  1. Lipseste bifa pentru ACL inheritance.

AdminSDHolder4

  1. Valoarea atributului adminCount este 1.

Daca valoarea este 1 sau >1, atunci acest obiect face parte din unul din acele grupuri protejate sau a fost membru. Daca acel user a facut parte din unul din grupuri dar a fost scos ulterior, atunci valoarea atributului ramane neschimbata. By default valoarea este <not set>. Atata timp cat valoarea este 1 inheritancce-ul de ACL-uri va ramane neselectat. Pentru fiecare user trebuie modificat acest atribut, fie la <not set>, fie 0. Daca punem 0 putem sa avem un istoric cu obiectele afectate.

Cum o rezolvam?

  1. Pentru test, putem pune bifa manual de “Inherit permissions” doar ca sa vedem daca problemele se rezolva in acest mod. Tineti cont ca dupa acel interval de timp inheritance-ul va fi din nou scos de SDProp.
  2. RECOMANDAT – Folositi 2 conturi asa cum se recomanda si de catre Microsoft, si scoate-ti conturile din grupurile respective.
  3. Modificati lista de Protected Groups.

Acest lucru se face modificand flagul dsHeuristics; Ca sa ajungeti acolo deschideti ADSIEDIT, deschideti naming contextual de Configuration, apoi mergeti la Services, WindowsNT, Directory Service.

AdminSDHolder3

Acest flag accepta valori hexazecimal. De exemplu:

Bit

Grupuri Excluse

Valoare in binar

Valoare in   hexazecimal

0

Account Operators

0001

1

1

Server Operators

0010

2

2

Print Operators

0100

4

3

Backup Operators

1000

8

Lucrurile se complica in cazul in care vrem sa excludem mai multe grupuri. In acest caz se aduna valoare lor in binar si se transforma apoi in hexazecimal.

Grupuri   Excluse

Valoare   in binar

Valoare   in hexazecimal

None   (Default)

0000

0

Account   Operators

0001

1

Server   Operators

0010

2

Account   Operators Server Operators

0001   + 0010 = 0011

3

Print   Operators

0100

4

Account   Operators Print Operators

0001   + 0100 = 0101

5

Server   Operators Print Operators

0010   + 0100 = 0110

6

Account   Operators Server Operators Print Operators

0001   + 0010 + 0100 = 0111

7

Backup   Operators

1000

8

Account   Operators Backup Operators

0001   + 1000 = 1001

9

Server   Operators Backup Operators

0010   + 1000 = 1010

a

Account   Operators Server Operators Backup Operators

0001   + 0010 + 1000 = 1011

b

Print   Operators Backup Operators

0100   + 1000 = 1100

c

Account   Operators Print Operators Backup Operators

0001   + 0100 + 1000 = 1101

d

Server   Operators Print Operators Backup Operators

0010   + 0100 + 1000 = 1110

e

Account   Operators Server Operators Print Operators Backup Operators

0001   + 0010 + 0100 + 1000 = 1111

f

Alte linkuri utile:

  1. Description and Update of the Active Directory AdminSDHolder Object
  2. Manually initializing the SD propagator thread to evaluate inherited permissions for objects in Active Directory
  3. AdminSDHolder Thread Affects Transitive Members of Distribution Groups
  4. Exchange 2010 and Resolution of the AdminSDHolder Elevation Issue
Advertisements

Event ID 13562, ISTG, KCC, multiple site connection objects


Active-Directory-logo

Event ID 13562, ISTG, KCC, multiple site connection objects

Am constatat ca folosind SCOM pentru monitorizarea de Active Directory, si nu numai, s-a dovedit a fi o alegere buna in detectarea diverselor erori care in mod normal nu stiu daca le aflam timp util decat atunci cand era destul de tarziu.

Notificarea care o dadea acest „scom” (cand vorbesc cu cineva in engleza, de multe ori ma aud zicand „scum” si aproape ca ma bufneste si rasul) era ceva de genul „A domain controller has an unusually high number of replication partners” ca si subiect iar la descriere iti zice DC-ul in cauza si numarul  de “parteneri de replicare”. Sistemul asta de monitorizare ofera descrieri si link-uri utile pentru diverse probleme mai simple dar ceva mai complex….iti arunca eroarea asta “seaca” si te lasa sa iti bati capul cu ea. Initial ce am zis, “scomu” asta e nebun, nu stie ce zice…. De ceva timp incoace, mi-am schimbat parerea, si am ajuns la concluzia ca fiecare alerta “taNpita” are la baza o problema reala. Trebuie doar sa te concentrezi mai mult pe ea….

Ok, sa ne apucam de treaba, sa vedem de ce a luat-o razna si spune numai bazaconii…

M-am logat pe serverul cu pricina si m-am uitat prin loguri. Logurile din Operations Manager, un warning cu Event ID 81 zice ca am 45 de outbound replication connections „which is more than the recommended number 40”…si e Warning ca peste 50 deja e critical error…

Deschid dssite.msc si navighez pe serverul din site-ul respectiv si dau Proprietati pe NTDS Settings.

In enuntul erorii scria „outbound” deci m-am uitat la Connections, Replicate To….

Si acolo intradevar, 45 de connection objects asa cum zicea batranul scom….sa-i dea Dumnezeu sanatate! Foarte multe din connexiuni  faceau trimitere la acelasi server in acelasi site.

In site-ul respectiv aveam 2 DC-uri unul cu „database errors” (sa-i zicem DC1) , alta poveste, deci unu mai bolnav…in fine urma sa fie scos. Dar nu era acesta serverul care aparea in loguri ci celalat care nu dadea nici un semn ca ar fi ceva in neregula…Nu foloseam „manual connection objects” si lasam KCC-ul sa isi faca treaba…dar cum sa greseasca KCC-ul care stia cel mai bine care e treaba…Un articol in teresant de citit „ You are not smarter then the KCC

Stiam ca serverul DC1 are probleme dar nu intelegeam de ce partenerul lui din acelasi site afisa problemele…

Daca nimeni nu a creat acele legaturi clar KCC-ul le-a creat. Si erau intre site-uri deci serverul care avea si rol de ISTG. Am verificat si DC1 era si ISTG pentru site-ul respectiv…

And then came the breakthrough…

Am citit un articol pe technet care avea cateva randuri foarte interesante:

„When there are two domain controllers in the site that appear to own the intersite topology generator role, there might be a temporary state of inbound replication connection objects being created by both computers. However, after replication occurs and all domain controllers receive the change that identifies the new intersite topology generator, the KCC on the intersite topology generator adjusts the topology.

Deci daca ambele servere din acel site se credeau „owner” de ISTG ambele DC-uri creau obiecte automat si fiindca replicarea era „busita” pentru unul din DC’uri obiectele respective nu mai erau sterse cand se ajungea la convergenta.

Dar ambele servere afisau acelasi ISTG adica DC1 (cel cu probleme). Ce mai puteam sa incerc…

Initial am sters pur si simplu obiectele care, normal au reaparut…

M-am gandit sa mut rolul de ISTG de pe DC1 pe DC2 sa vedem cum se comporta.

Dupa ce am facut modificarea am verificat si acele connection objects au disparut…puff!

Si-am incalecat pe o sha shi v-am spus povestea mea….

Cateva detalii despre KCC, ISTG, Bridgeheads si Preferred Bridgeheads

  • Se poate porni logging pentru KCC pentru a afla mai multe detalii modificand valoarea inregistrarii Replication Events in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics.
  • Fiecare KCC de pe fiecare DC ruleaza un algoritm care determina topologia din site-ul (intersite topology)din care face parte. Fiecare DC din acel site va avea aceeasi informative asa ca fiecare DC va deduce aceeasi topologie.
  • KCC creaza obiectele de la DC-urile sursa.
  • KCC creeaza in topologia intersite legaturi intre DC-uri redundante si care sa nu fie la o distanta mai mare de 3 hopuri pentru a reduce latenta.
  • Pentru a forta generarea topologiei se poate da click dreapta pe obiectul NTDS, All tasks, Check Replication Topology sau folosind repadmin /kcc <DSA>.
  • Un DC per Site isi asuma rolul de ISTG, este responsabil de creearea de “connection objects” intre DC-uri din site-uri diferite (intrasite topology).
  • Pentru a Identifica ce DC este si ISTG exista mai multe metode. Va zic doua:
  1. Repadmin /istg <DSA>
  2. Dssite.msc , navigati la site-ul respectiv, in panoul din dreapta, proprietati pe NTDS Object, Attribute Editor si cautati InterSiteTopologyGenerator….

istg

  • Cand ISTG trebuie sa modifice obiectul de pe un bridgehead din alt site, va face modificarea in copia locala din AD si replicarea normal isi va lua cursul.
  • In timp ce KCC genereaza topologia intersite, evalueaza fiecare DC ca si posibil candidat pentru bridgehead. Daca sunt configurati Preferred Bridgeheads acestia sunt candidati la selectie.
  • Daca am configurat mai multi Preferred BH si acestia din diverse motive nu mai sunt disponibili, nu se va face failover la alte DC-uri chiar daca sint eligibili.
  • Schimbarea ISTG-ului se face modificand atributul din imaginea de mai sus.
  • Ca sa ne asiguram ca modificarile facute unui connection object nu sunt suprascrise de KCC (care se pune owner pe acel obiect) este nevoie sa facem modificarile pe serverul care tine rolul de ISTG.

Daca imi mai amintesc alte chestii utile le mai adaug eu sau mai imi spuneti voi. Am scris cam repejor articolol asa ca imi cer scuze de eventualele greseli, dar le corectam daca e cazul…

A, si mai erau un articol pe technet:

http://support.microsoft.com/kb/251250

…care spune ca solutie sa stergeti pur si simplu obiectele duplicate. Pare o solutie temporara daca la urmatoarea replicare te pomenesti din nou cu ele…

LepideAuditor for File Server


 LepideAuditor for File Server

Am avut recent ocazia de a lucra cu un tool excelent pentru audit de fișiere. Auditul accesului pe fisiere poate fi uneori dificil folosind instrumente implicite din Windows, trebuie configurate Group Policies, configurat audit pe foldere, configurare de event forwarding, atasarea taskurilor la evenimente pentru a trimite notificari pe email ( ce este interesant aici de mentionat este ca nu se poate configura inainte ca evenimenul sa se fi produs ceea ce inseamna bataie de cap aditionala), backup-ul acestor informatii, si pastrarea acestora pentru o perioada mai lunga de timp cum ar fi 6 luni de exemplu. Toate aceste activitati sunt consumatoare de timp mai ales daca nu aveti experienta in configurarea anterioara a acestor setari. LepideAuditor for File Server poate oferi toate aceste funcționalități și mai mult, principalul avantaj din punctul meu de vedere este timpul economisit in gasirea evenimentelor relevante situatiei. Nimanui nu ai place sa isi piarda timpul si sa parseze manual prin loguri … Configurarea acestui tool este foarte usoara, nimic special. Acesta folosește o instanță SQL, dar poate fi implementat foarte bine folosind SQL Express. Instrumentul are două console principale, consola de setări și Consola de raportare.

Consola de raportare, simpla si eficienta…

După cum puteți vedea in imagini am servere cu roluri diferite auditate, unele fiind chiar si DC-uri sau Exchange-uri. Puteți utiliza acest tool pentru diverse scopuri, si va voi arata un astfel de exemplu, folosind un DC mai târziu în acest document. Vom crea o regulă nouă în care putem defini politicile și setările pe care dorim să le pună în aplicare pentru audit. Aici incepe distracția. O altă caracteristică interesanta a acestui instrument este flexibilitatea cu care o puteți politici de audit. Atunci când implementati setările, puteti configura aplicatia pentru a lua în considerare politici individuale, politici de grup, sau puteti crea o nouă politică.

Creand astfel o nouă politică este destul de simplu, dar în cazul în care aveți probleme, vedeti documentatia Help a aplicatiei care explica clar utilitarul respectiv. Se poate seta un interval orar in care sa se aplice politica de audit, lucru foarte util de altfel pentru ca va permite oarecum sa controlati cantitatea de informatii generata de aplicatie.

Urmatoarele caracteristici va ofera o mai mare flexibilitate si anume va permite sa configurati politici pentru Drive Lists, Directories, File Names, File Types, Processes si Events. Fiecare din aceste setari se pot combina in finctie de scopul scontat si salvarea acestora intr-o politica. După cum puteți vedea diferite setări pot fi configurate intr-o singură politică.

Când vine vorba de setările de notificare aveți 3 opțiuni, e-mail, mesaje de retea si SMS-uri.

Puteți defini chiar și un query, folosind operatori si de a trimite notificări in cazul în care sunt îndeplinite anumite condiții.

O caracteristică interesantă care imi place, este gestionarea operațiunilor simple pe baza de date SQL direct din consola de setări prin intermediul unui wizard simplu. Nu este nevoie de a Management Studio sau alte instrumente pentru a face un database shrink.

Referitor la consola de raportare, vei putea vedea cine a modificat, accesat, sters, schimbat owner si alte evenimente care sunt utile atunci când faci un audit. De exemplu, atunci când un administrator sau un utilizator cu drepturi delegate a schimbat owner-ul unui fișier sau un folder, în scopul de a accesa acel conținut, in consola putem filtra doar acele evenimente care sunt relevante pentru căutarea noastră.

Sau putem folosi unul din filtrele builtin pentru rezultate rapide. Cum am spus si mai devreme, avantajul principal fiind rapiditatea cu care se pot accesa evenimentele dorite. Mai jos vom folosi filtrul Permission Changes filter (Folder).

La deschiderea evenimentului, putem vedea următoarele detalii:

Puteți crea rapoarte obisnuite, rapoarte personalizate și le puteți exporta în diferite tipuri, cum ar fi PDF, Word, HTML, CSV sau text simplu. Rapoartele sunt executate rapid și sunt bine formatate.

Am spus mai devreme că puteți utiliza acest instrument în diverse scenarii, de exemplu, pe un DC  sau Exchange Server. Desigur, Lepide are produse specializate separate pentru audit sau de gestionare a acestor sisteme, dar vreau doar sa demonstrez că se poate folosi si in alte moduri. Puteți configura, de exemplu, auditarea SYSVOL, containerul cu politicile de domeniu. Astfel veți putea monitoriza statusul GPO-urilor. Putem afla cine a modificat, sters, creat si cand referitor la politicile de grup. Intradevar nu este asa frumos fiind ca arata GUID-ul in loc de numele politicii (care se afla usor), dar funcționalitatea sa combinata cu funcția de alertare, va fi notifica imediat persoana in masura ca s-a modificat ceva și-ar putea sa ia niste masuri inainte ca acestea sa se propage sau ca utilizatorii sa primeasca setarile.

În imaginea de mai sus veți vedea, de exemplu, cum cineva a șters o politica de grup (în acest caz, dosarul a fost șters GPT.ini). Stiu, se vede GUID-ul politicii în loc de numele ei, dar totusi acesta este un auditor de file servere nu un auditor AD, pe langa asta oricine poate găsi GUID-ul prin căutarea în proprietățile obiectului. Același lucru se poate aplica pentru Loguri și alte fisiere din Exchange, depinde de cat de creativ esti …. Ca o concluzie despre acest instrument, bune si rele: Bune: • GUI Usor si instinctiv • Configurații foarte flexibile de politici de audit • Funcționează cu SQL Express • Consola de raportare genereaza rapoarte rapide, bine formatate • Notificări aproape in real time prin intermediul diferitelor medii. • Alerte personalizate cu ajutorul operatorilor (AND, OR) • Acces rapid la evenimente folosind filtre predefinite în Consola de raportare

Rele (primele două cred ca sunt inevitabile, deoarece cele mai multe Enterprise-uri folosesc software de monitorizare ce funcționează cu agenți și necesită macar o baze de date, dar în cazul în care se vrea a fi o soluție de tip enterprise poate că ar trebui să ofere mai multe feature-uri, iar unele sugerate mai jos ar putea fi utilizate pentru a îmbunătăți produsul): • Funcționează cu agenți • Necesită o bază de date SQL • Nici un mod de logging pentru troubleshooting-ul aplicatiei

• Necesită actualizarea de agenți frecventă pentru a împinge modificări catre acestia • Nu are user based authentication • Nu exista o consolă web • Ar putea utiliza datele din DB pentru a genera charturi/diagrame

Mai multe informații despre acest program puteți găsi la:

http://www.lepide.com/file-server-audit/?gclid=CM775_fp7bUCFfB3cAodhyIAqw

Demo Video:

http://www.lepide.com/file-server-audit/lfsa-overview-video.html

DcDiag Problem: Missing Expected Value


Active-Directory-logo

DcDiag Problem: Missing Expected Value

Am avut ocazia de curand sa intalnesc cateva “probleme” daca le putem numi asa, raportate de DCDIAG.  La un test obisnuit dcdiag totul parea ok, ceea ce ar fi linistit pe oricine vazand ca totul este in regula, insa la un test verbose folosind dcdiag /v /c /i /q pe orice DC din domeniu aparea urmatoarea eroare, enumerand missing expected value pe toate DC-urile din domeniul respectiv:

[1] Problem: Missing Expected Value
Base Object:
CN=DC1,OU=Domain Controllers,DC=child,DC=domain,DC=com
Base Object Description: "DC Account Object"
Value Object Attribute Name: msDFSR-ComputerReferenceBL
Value Object Description: "SYSVOL FRS Member Object"
Recommended Action: See Knowledge Base Article: Q312862

msDFSR-ComputerReferernceBL-edited

Cum spuneam, aceasta “problema” nu aparea ca si eroare in loguri sau in testele obisnuite din Active Directory, dar curioziatea de a intelege care este motivul generarii acestui mesaj este provocatoare.

In mesaj se face referire la un KBQ312862 in care se descrie metode de recuperearea a obiectelor si attributelor din Active Directory, cum sa detectam si sa reparam atrubute cu valoarea nula, etc…Oricum nu era cazul nostrum pentru ca daca aveam missing objects in AD era destul de grav, si nu mai alerta dcdiag doar in modul verbose ci in orice mod :)).

Explicatia acestor “erori” este mai simpla decat pare.

La o verificare a atributului mentionat msDFSR-ComputerReferenceBL am vazut ca valoarea acestuia nu este populata. Dar ce ar fi trebuit sa contina mai exact?

Am verificat un DC 2008 R2 intr-un mediu virtual si valoarea populata in acel atribut este:

CN=DCServerName,CN=Topology,CN=Domain System Volume,CN=DFSR -GlobalSettings,CN=System,DC=Domain,DC=Com

Atunci a fost clar care este problema…Acel atribut trebuia populat cu un backlink catre un DC care tine o replica Sysvol.

M-am conectat la Default Naming Context si am vazut ca in CN=DFSR -GlobalSettings,CN=System,DC=Domain,DC=Com nu exista Domain System Volume (SysVol), si verificarea in containerul File Replication Services a confirmat faptul ca replicarea inca se face prin FRS.Desi recent fusese ridicat nivelul de functionare al domeniului si forestului la 2008 R2, replicarea inca se face prin FRS de aceea nu avea cum sa fie populat acel atribut!

FRS

Aceasta era de fapt problema alertata de dcdiag, care nu era chiar o “problema”…

Urmartoul pas este migrarea replicarii Sysvol de la FRS la DFSR, proces documentat in urmatorul articol Microsoft: http://www.microsoft.com/en-us/download/details.aspx?id=4843

AD Rights Management Services


Active Directory Rights Management Services

Vom demonstra functionalitatea serviciului de Rights Management Services intr-un mediu de testare.

Ce ar trebui sa pregatiti in general, inainte de a configura serviciul de RMS:

  1. Un cont de user obisnuit  (un service account) pentru a asigura o identitate serviciului de RMS si pentru a comunica cu alte servicii. Nu este recomandata instalarea AD RMS pe un DC dar daca acest lucru este necesar atunci contul va trebui sa faca parte din grupul Domain Admins sau Enterprise Admins.
  2. O instanta SQL 2005 sau 2008 instalata fie local fie pe un alt server si permisiunile necesare (System Administrators Database membership). In experimentul nostru vom folosi Windows Internal Database ceea ce ne limiteaza la folosirea unui singur server chiar daca vom creea un asa numit cluster RMS.
  3. Daca se foloseste un “named instance” trebuie pornit serviciul SQL Server Browser pe serverul de baze de date inainte de a instala RMS altfel instalarea nu va gasi cfg DB-ul respectiv.

Vom incepe instalarea rolului ca a oricarui altul din consola de  Server Manager…Nu am pus imagini cu fiecare pas deoarece sunt simpli, am trecut doar ce merita mentionat. Instalarea este destul de “straight forward”…

Se vor specifica baza de date, service accountul mentionat anterior si locul de stocare si modul de distribuire al cheii folosita de clusterul RMS pentru semnarea de certificate. (vezi imaginea de mai jos)

Prima varianta ne ofera posibilitatea de a stoca cheia direct in clusterul RMS si sa o criptam folosind o parola, astfel cand se vor adauga servere RMS in acest cluster aceasta va fi distribuita automat.

A doua varianta ne permite sa selectam noi un CSP (cryptographic service provider) pentru a stoca cheia. In cazul in care optam pentru a doua variata acestea erau optiunile, dar momentan vom merge pe prima varianta.

Vom specifica criptarea comunicarii cu serverul RMS prin SSL folosind un certificat emis de o autoritate interna.

Setam numele clusterului RMS…

Vom specifica adresa serverului “licentiator” care stabileste identitatea serverului catre clienti RMS.

La sfarsit se cere inregistrarea SCP-ului (service connection point) in Active Directory, iar daca membrul cu care sunteti logat face parte din grupul Enterprise Admins apasati Next, daca nu sunteti membru EA atunci selectati optiunea register later.

Gata instalarea. Acum configurarea.

Daca observati pe prima pagina de pe consola AD RMS aveti 2 URL-ri interne care fac trimitere la hostname-ul “ardms”.

Din cate stiu nu cred ca se face automat vreo inregistrare in dns de acest gen asa ca va fi nevoie sa va duceti singuri in consola da DNS si sa adaugati un CNAME care sa faca trimitere sa la hostname-ul serverului de RMS.

Adaugati service accountul pentru RMS in grupul local de Administrators pe serverul de RMS.

Stabiliti un folder share-uit la care utilizatorii sa aiba drept de read, iar service accountul pentru RMS sa aiba drept de write.

Deschideti consola de RMS si faceti click dreapta-proprietati pe nodul de Rights Policy Templates.

Bifati optiunea pentru export. Specificati calea catre share-ul stabilit pentru stocarea template-urilor.

Daca contul de ADRMS nu are drept de scriere va returna un mesaj prin care va zice acest lucru, caz in care trebuie sa revedeti setarile NTFS de pe share-ul respectiv.

Acum puteti crea un policy template care va stabili ce reguli si conditii se vor aplica continutului pe care vreti sa il protejati. Aici se pot stabili grupuri carora sa li se aplice setarile si ce anume sa li se aplice. Mai jos am facut o configurare simpla dar puteti vedea din optiuni ca setarile sunt foarte flexibile, putandu-se stabili si un interval de timp dupa care sa expire.

Gata si cu partea de configurare a serverului…

Acum pe partea de client trebuie deasemenea configurat cate ceva.

Daca aveti Vista sau 7 aveti noroc, clientul de RMS este deja instalat. Daca aveti XP trebuie sa descarcati clientul. Vezi Client requirements:

http://technet.microsoft.com/en-us/library/dd772753(v=ws.10).aspx

Acum, pe clientul de Windows 7 navigam la Scheduled Tasks si vedem in dreptul nodului de Rights Management Services doua taskuri. Una se numeste Automatic, cealalta Manual.

Taskul automat functioneaza pentru masini care sunt domain joined. Vom da Enable acestui task, si run pentu a vedea ca ruleaza fara probleme. Taskul manual functioneaza pentru utilizatori de domeniu dar care folosesc masini ce nu fac parte din domeniu.

Daca vrem sa activam pe toate masinile din domeniu putem folosi Group Policy si sa cream un script, care sa ruleze urmatoarea comanda:

schtasks /Change /TN “\Microsoft\Windows\Active Directory Rights Management Services Client\AD RMS Rights Policy Template Management (Automated)” /ENABLE

Apoi mai este nevoie sa facem urmatoarea modificare in registri (putem folosi tot Group Policy, un script, sau Group Policy Preferences). Cheia este urmatoarea:

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\DRM

Faceti clieck dreapta pe DRM, New si selectati Expandable String Value, iar la valoare treceti AdminTemplatePath.

Deschideti noua cheie AdminTemplatePath si scrieti:

%LocalAppData%\Microsoft\DRM\Templates

Apasati ok si close.

Daca aveti de exemplu Windows 7 pe 64 de biti trebuie sa modificati cheia si in HKEY_CURRENT_USER\Software\Wow6432Node\.

Acum o sa trebuiasca sa asteptam ceva timp (unele articole MS spun de o ora).

Asa se configureaza clientul automat.

Se mai poate face si manual, pasi difera putin, respectiv valoarea inregistrarii AdminTemplatePath va contine urmatorul string:

%LocalAppData%\Microsoft\DRM\Templates_Manual

Verifica calea C:\Users\UserName\AppData\Local\Microsoft\DRM\Templates\ ca directorul exista.

Verifica ca ai access la share-ul de pe server unde se tin template-urile si copiaza-le local in folderul de mai sus.

Avand template-urile local, fata de locatia din retea, clientii pot aplica restrictii in mod offline, ne mai fiind nevoie de acces la serverul de RMS.

Acum sa verificam…

Avem doi utilizatori pentru care avem configurat camplu de email din AD, repectiv Gheorghe@abc.local si Vasile@abc.local .

Fiind logat cu contul meu am creat un document Word pe care am ales sa il protejez si sa-I dau lui Gheorghe drept de citire fara drept de salvare, trimitere ca atasament sau modificare.

Acum sa verifica cu acei useri sa vedem daca intradevar se aplica ce am configurat.

Asta va vedea Gheorghe.

Dupa cum se observa Gheo are doar drept de citire, nu poate salva sau lista documentul (cel putin teoretic). Daca va ganditi ca poate merge cu Save & Send, am verificat deja, nu merge.

Cam asta este povestea noastra cu AD RMS. Desigur mai sunt si alte scenarii de integrare cu Exchange , Sharepoint, cateva chestii interesante legate de rapoarte in AD RMS dar cu alta ocazie voi scrie si despre asta.

Link-uri utile:

AD RMS Technet:

http://technet.microsoft.com/en-us/library/cc771234(v=ws.10).aspx

AD RMS Best Practice Analyser:

http://www.microsoft.com/en-us/download/details.aspx?id=1460

AD RMS Exchange Integration:

http://technet.microsoft.com/en-us/library/ee849857(v=ws.10).aspx

Tutoriale video pentru AD RMS:

VIDEO Tutorials AD RMS

Rollback DFL FFL Windows Server 2008 R2


Roll Back pentru Domain Functional Level si Forest Functional Level in Windows Server 2008 R2

Pe Windows Server 2008 R2 exista posibilitatea de a restaura nivelul de functionare al domeniului (DFL) desi exista anumite limitari. Pentru versiuni anterioare ale sistemului Windows Server nu este posibila efectuarea unui roll-back al nivelului de functionare. De exemplu daca s-a efectuat un upgrade de domeniu de la Windows Server 2003 la Windows Server 2008 nu se poate reveni la Domain Functional Level de Windows Server 2003.

Domain Functional Level (DFL)

Pentru a putea efectua cu succes un rollback de DFL trebuiesc întrunite doua condiții importante:

  • Domain Functional Level-ul actual trebuie sa fie Windows Server 2008 R2
  • Forest Functional Level trebuie sa accepte domenii de tipul pe care vrei sa faci roll-back

Cu toate ca este specificat faptul ca ESTE POSIBIL CA procesul sa nu fie reversibil, in realitate este posibil, din nou daca sistemul este Windows Server 2008 R2.

Am sa mentionez câteva observatii pe care unii probabil le sunt cunoscute dar poate altii nu inteleg pe deplin conceptul:

Functional Levels reglementeaza ce caracteristici (features) sunt activate in domeniul sau forestul respectiv. Deasemenea mai restrictioneaza tipul sistemului de operare ce ruleaza pe Domain Controllere.

Pentru mai multe detalii referitoare la nivelul de functioare al domeniilor sau forest-urilor consultati linkul urmator: http://technet.microsoft.com/en-us/library/cc754918.aspx

Pentru a se efectua downgrade-ul se va folosi cmdlet-ul Set-ADDomainMode inclus in Active Directory Module for PowerShell:

  1. Apasa Start, Administrative Tools, Active Diretory Module for Windows PowerShell.
  2. In command prompt-ul din PowerShell tasteaza urmatoarea comanda si apasa Enter:

Set-ADDomainMode -Identity Domain.local -DomainMode Windows2008Domain

Înlocuiti Domain.local cu numele FQDN al domeniului vostru. Aceasta comanda va face rollback la DFL 2008.

  1. Va apărea o întrebare de confirmare. Apasă “Y” si apoi Enter.
  2. Dupa ce apasati Enter nu va aparea nici un mesaj de confirmare care sa va asigure ca operatiunea s-a efectuat cu succes.

Pentru a putea confirma faptul ca rollbackul s-a efectuat cu success putem verifica prin doua metode:

  1. Event Viewer in categoria Directory Service daca exista un eveniment cu ID 2039. În detaliile acestui eveniment veti gasi confirmarea. Acolo va scrie New domain functional level: 3 în cazul DFL Window Server 2008.
  2. Folosind cmdlet-ul Get-ADDomain din Active Directory Module for PowerShell care este inclus in Windows Server 2008 R2.

Pentru mai multe informatii referitoare la cmdlet-ul Get-ADDomain consultati urmatorul link: http://technet.microsoft.com/en-us/library/ee617224.aspx

Forest Functional Level (FFL)

Pentru a putea efectua downgrade/rollback al nivelului de functionare al forest-ului trebuiesc îndeplinite următoarele condiții:

  1. Forest Functional level-ul trebuie obligatoriu sa fie Windows Server 2008 R2.
  2. Advanced Features cum ar fi Active Directory Recycle Bin nu trebuie sa fie activate. Aceasta optiune de exemplu este ireversibila. Alte optiuni avansate se pot dezactiva folosind cmdlet-ul Disable-ADOptionalFeatures.

Ramane valabila limitarea de downgrade FFL la 2008, la fel ca si in cazul DFL. De exemplu, nu putem face rollback de la Windows Server 2008 R2 FFL la Windows Server 2003 FFL, chiar daca anterior acesta fusese upgradat de la 2003 la 2008.

Pentru a se efectua downgrade-ul se va folosi cmdlet-ul Set-ADForestMode inclus in Active Directory Module for PowerShell:

  1. Apasa Start, Administrative Tools, Active Diretory Module for Windows PowerShell.
  2. In command prompt-ul din PowerShell tasteaza urmatoarea comanda si apasa Enter:

Set-ADForestMode -Identity Domain.local -DomainMode Windows2008Domain

Înlocuiti Domain.local cu numele FQDN al domeniului vostru. Aceasta comanda va face rollback la DFL 2008.

  1. Va apărea o întrebare de confirmare. Apasă “Y” si apoi Enter.
  2. Dupa ce apasati Enter nu va aparea nici un mesaj de confirmare care sa va asigure ca operatiunea s-a efectuat cu succes.

Pentru a putea confirma faptul ca rollback-ul s-a efectuat cu success putem verifica prin doua metode:

  • Event Viewer in categoria Directory Service daca exista un eveniment cu ID 2040. În detaliile acestui eveniment veti gasi confirmarea. Acolo va scrie New forest functional level: 3 în cazul FFL Window Server 2008.
  • Folosind cmdlet-ul Get-ADForest din Active Directory Module for PowerShell care este inclus in Windows Server 2008 R2.