Application Catalog website error

O problema cu care m-am intalnit recent atunci cand instalam Application Catalog Website Point site system role.

Am verificat logurile, permisiunile pentru comuter account in baza de date _CM totul parea in regula.

Mesajul de pe pagina respectiva a fost de ajutor iar codul de eroare direct din consola (500 – internal server error) este un cod genereal de tipul ‘catch all’.

Problema este oarecum cunoscuta si se intampla atunci cand se instaleaza de exemplu .NET Framework 4.0 iar apoi se instaleaza o versiune mai veche de .NET Framework sau se configureaza ‘.NET 3.0 WCF HTTP Activation’ , unul din ‘requirements’ necesare pentru SMS.

Pentru cine este interesat de mai multe detalii, in fisierul Applicationhost.config (%windir%\system32\inetsrv\config) exista o sectiune incompatibila cu .NET Framework 4.0:

<add name=”ServiceModel” type=”System.ServiceModel.Activation.HttpModule, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ preCondition=”managedHandler” />

Ar trebui sa fie:

<add name=”ServiceModel” type=”System.ServiceModel.Activation.HttpModule, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ preCondition=”managedHandler,runtimeVersionv2.0″ />

Solutia cea mai rapida este sa rulam un utilitar Aspnet_regiis.exe /iru care se gaseste in :

%windir%\Microsoft.NET\Framework\v4.0.30319

%windir%\Microsoft.NET\Framework64\v4.0.30319 (on a 64-bit computer)

Pentru mai multe dedtalii despre Aspnet_regiis.exe :

http://msdn.microsoft.com/en-us/library/k6h9cz8h(v=vs.100).aspx

THE END

Instalarea agentilor SCOM in reteaua DMZ

Pentru a avea o imagine de ansamblu cat mai completa a unei ‘aplicatii distribuite’ cum ar fi Exchange sau Lync, atunci trebuie sa avem posibilitatea de a monitoriza si serverele aflate in DMZ, acestea de obicei ruland roluri de Edge.

In Scom 2012 schimbul de informatii dintre serverul de management (scom) si agenti (sistemele monitorizate) trebuie sa se faca intr-un context securizat folosind Mutual Authentication (http://technet.microsoft.com/en-us/library/cc961730.aspx). Atunci cand si serverul de monitorizare si sistemele se afla in acelasi domeniu sau forest procesul este nativ folosind autentificare Kerberos V5. Cand serverul si sistemul nu sunt in acelsi domeniu/forest/trusted realm trebuie folosit un alt sistem care utilizeaza mutual authentication. Varianta ‘oficiala’ si cea mai eleganta ar fi folosirea unui server Gateway (http://technet.microsoft.com/en-us/library/hh212823.aspx). Dar daca nu avem trebuie sa ne descurcam si fara.

Vom folosi certificate  TLS si astfel procesul de autentificare se va efectua prin MTLS.

Cum facem…

Ne asiguram ca si serverul de management (SCOM) cat si sistemul sau sistemele monitorizate folosesc acelasi Root Certificate Authority. Importam certificatele Root CA pe server si sistemele ce urmeaza sa fie monitorizate. Pe serverul de RMS (2007) sau/si serverele MS (2012) navigam la pagina certsrv a autoritatii configurate sa emita certificate in domeniul respectiv. Selectam Download a CA certificate, certificate chain, or CRL, apoi Download a CA certificate, certificate chain. Va descarca automat un certificat certnew.p7b pe care il salvam intr-o locatie la alegere (ex. Desktop).

Odata salvat, deschidem un MMC si importam snapin-ul pentru Certificates (Local Computer), navigam la Trusted Root Authorities si dam import certificatului salvat anterior.

So far so good…

Acum trebuie configurata Autoritatea de Certificate (issuing CA) sa suporte certificate pentru SCOM. Mai exact sa facem un template pentru emiterea unui certificat compatibil cu “nevoile” serverului de scom pentru a comunica cu agentii.

Ne logam cu credentialele necesare pe autoritatea de certificate (enterprise CA) si dechidem mmc pentru Certificate Templates. Duplicam template-ul pentru Computer si denumim corespunzator template-ul. Selectati 2008 (V3) dar ca sa fiti siguri de functionalitate mergeti pe variant de 2003 (V2). Ajustati validiatatea certificatului, la Request Handling bifati Allow private key to be exported. Poi apasam tabul de Subject Name si selectam Supply in the request pentru a introduce datele manual cand facem cererea. Va aparea un mesaj de Warrning, il puteti ignora, vom modifica ACL-ul pe Template imediat. Apasam tabul de Security, si permiteti Enroll si Autoenroll pentru urmatorii UPNs Authenticated users, Domain Admins, Domain Computers, Enterprise Admins. Apply si OK.

In certsrv.msc expandam Certificate Templates, click dreapta, New, Cetificate Template to issue si selectam Template-ul corespunzator. Ne asiguram ca informatia (noul template disponibil) s-a replicat pe toate DC-urile si folosim Gpupdate /force sa aplicam noile configurari.

De pe serverul de management verificam ca template-ul este disponibil. Navigam la pagina certsrv a autoritatii emitente, selectam Advanced Certificate Request si vedem daca apare si noul template.

Daca nu aveti SSL configurat pe pagina de certsrv si va apare mesajul urmator:

In mod normal trebuie configurat accesul SSL pe pagina respectiva, dar daca sunteti mai ‘lazy’ ….

Exista un workaround pentru asta, destul de rapid. Adaugati site-ul certsrv la Trusted sites. Selectati Custom Level si faceti Enable la setarea de mai jos:

Data viitoare cand accesati pagina o sa va intampine o casuta de dialog, apasati Yes.

Acum ca nu mai apare eroarea respectiva putem sa cerem certificatul selectand template-ul corespunzator.

In campurile Name si Friendly Nname completam FQDN-ul serverului de management, si selectam Mark key as exportable (foarte important).

Acelasi lucru facem si pe serverul aflat in DMZ, doar in dreptul campurilor Name si Friendly Name completam numele serverului FQDN .

Ca sa verificam ca importul este correct, deschidem MMC, User Certificatets, personal si acolo ar trebui sa fie un certificate emis. Deschidem proprietatile certificatului si verificam tabul Certification Path ca toata ierarhia de certificate sa fie in regula (trusted).

Urmatorii pasi trebuiesc facuti pe serverele de management si sistemele din DMZ.

MMC, Certificates, User Certificates, Personal, Certificates si da-ti export pe noul certificat instalat. Selectati sa exportati cheia privata. Nu bifati nimic in urmatoarea fereastra, next, setati o parola si salvati sub un nume corespunzator sub extensia .pfx.

Instalam manual agentii de scom pe serverele din DMZ. Verificam ca serverul scom sacomunice cu agentii din afara domeniului (Administration, Settings, Security sa nu fie reject selectat)

Acum trebuie folosit un tool MomCertImport.exe care se gaseste in \SUPPORTTOOLS\AMD64 de pe imaginea installerului SCOM 2012. Acest tool trebuie fie copiat local pe fiecare server fie facut acesibil in retea pentru a fi utilizat. Rulam aplicatia iar ca parametrii specificam calea catre .pfx.

Dupa ce am executat comanda restartam serviciul de management scom pe fiecare masina inclusive pe serverele SCOM (net stop healthservice && net start healthservice).

Asteptati cateva minute (3-10). Daca in logul OperationsManager nu apare ca fiind stabilita comunicarea, mai restartati odata serviciul de health dar doar de pe serverele care trebuiesc monitorizate.

Daca apare aceasta eroare, trebuie sa dati ‘approve’ agentului in scom.

Verificati in Administration>Device Management>Pending Management si dati ‘approve’ agentului.

Dupa ce ati dat ‘approve’ verificati din nou Event Log-ul .

THE END

SMS Provider Reported an error

Salutare, azi va delectez cu o problema de SCCM 2012 SP1. Problema a fost simpla asa ca nu va retin prea mult atentia.

Ce este SMS Provider?

Pe scurt este intermediarul ce face posibila comunicarea intre SCCM si baza de SQL.

Cand apare problema?

Am zis sa incerc si eu ca tot omul chestiile astea noi in SCCM cum ar fi Application Distribution vs Package Distribution dar cand incerc sa fac deploy la o applicatie fie in Native Mode fie Virtual App (App-V) imi arata urmatoarea erroare:

Verificand SmsProv.log gasesc ceva ce nu ofera prea multe informarii, cel putin pentru mine:

Updating SDM content definition.  $$<SMS Provider><05-04-2013 01:13:28.148-180><thread=3472 (0xD90)> *** declare @rc int, @errxml xml; EXEC @rc=sp_SetupCI 16780320, 0, @errxml out; select @rc, @errxml  $$<SMS Provider><05-04-2013 01:13:29.233-180><thread=3472 (0xD90)> *** *** Unknown SQL Error!  $$<SMS Provider><05-04-2013 01:13:29.234-180><thread=3472 (0xD90)> ~*~*~*** Unknown SQL Error!     ThreadID : 3472 , DbError: 50000 , Sev: 16~*~*~  $$<SMS Provider><05-04-2013 01:13:29.234-180><thread=3472 (0xD90)> *** if (object_id(‘tempdb..#sp_setupci_resultstr’) IS NOT NULL) select * from #sp_setupci_resultstr; else select N”;  $$<SMS Provider><05-04-2013 01:13:29.234-180><thread=3472 (0xD90)> *** [24000][0][Microsoft][SQL Server Native Client 10.0]Invalid cursor state  $$<SMS Provider><05-04-2013 01:13:29.234-180><thread=3472 (0xD90)> ~*~*~[24000][0][Microsoft][SQL Server Native Client 10.0]Invalid cursor state   *** Unknown SQL Error!  ThreadID : 3472 , DbError: 0 , Sev: 0~*~*~  $$<SMS Provider><05-04-2013 01:13:29.234-180><thread=3472

…..and so on.

Cauza?

Am mutat bazele de date pentru SCCM pe un alt drive. Cum le-am mutat? Ca pe orice baza de date SQL , detach, move, attach, DBCC CHECKDB. Procedura perfect valabila la SQL.

Din pacate pentru bazele de SCCM se modifica cateva proprietati atunci cand se face detach si trebuiesc puse la loc.

Rezolvarea

Rulati urmatoarele query-uri:

ALTER DATABASE <ConfigMgr DB> SET TRUSTWORTHY ON

ALTER DATABASE <ConfigMgr DB>  SET ALLOW_SNAPSHOT_ISOLATION ON

ALTER DATABASE <ConfigMgr DB>  SET READ_COMMITTED_SNAPSHOT ON

sp_changedbowner ‘sa’

Acum totul functioneaza cum trebuie.

Problema este documentata aici http://support.microsoft.com/kb/2709082 .

Paste Fericit, Romane! )

SCOM ACS database full

Acest articol este unul de genul ‘note to self’, bun de stiut pe viitor. M-am trezit ca baza de date pentru Audit Collections Services era full noroc ca am pus o limita odata pee a preventiv sa nu ocupe mai mult decat trebuie.

Pe scurt ACS este folosit sa trimita security events de pe orice host, in general servere, pentru a folosi la auditare. Altfel spus se pot tine centralizat evenimente ce sunt de interes companiei, cine ce a sters, ce a modificat, etc. ACS prezinta cateva avantaje in plus fata de alte ‘event forwarding solutions’ in sensul ca nu pot fi sterse ‘urmele’, se pot rula rapoarte complexe de corelare evenimente prin reporting services, etc.

Mai multe informatii aici: http://technet.microsoft.com/en-us/library/hh212908.aspx

Bun, am zis ca se intampla ca si la baza de date de data warehouse si trebuie sa aiba un ‘grooming period’ care il putem seta.

Si, am rulat pe baza de date OperationsManagerAC urmatorul query:

SELECT * FROM dtConfig

Si rezultatul a fost cel putin interesant pentru mine.

In al 6-lea rand ‘number of partitions’ ar trebui sa afiseze numarul de zile de retinere de infromatii. By default sunt 14 zile din ce stiam eu.

Se pare ca era problema asta la 2007, si trebuia sa se fi rezolvat dar se pare ca si la 2012 persista. Exista si un hotfix la un moment dat, care il puteti gasi aici:

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

Desi ma gandesc ca scenariul asta e posibil in cazul in care se face upgrade dela 2007 R3 la 2012.

Oricum, ca sa vedeti ce se afla exact in acele partition tables folositi urmatorul query:

SELECT * FROM dtPartition order by PartitionStartTime

La ‘Status’ valoarea ce trebuie sa o aiba partitia respective este 2, adica ca e gata de ‘grooming’ sau sters.

Daca au o valoare de 1, este mai ‘nasol’, pentru ca acele partitii nu vor fi sterse (groomed) niciodata si vor ajunge sa umple baza de ACS. Statusul de ‘1’ poate aparea de exemplu daca seara, cand se face by default mentenanta bazei de ACS, nu se reuseste indexarea acelor partition tables. Pentru cei mai curiosi exista urmatorul articol care explica cum functioneaza indexare partition tables-urilor:

http://msdn.microsoft.com/en-us/library/ms190787.aspx

Pentru a rezolva automat problema cu ‘status =1’  putem rula urmatorul query:

Use OperationsManagerAC

Update dtPartition

Set Status = 2

Where Status = 1

Dup ace s-a rulat query-ul restartati serviciul de Operations Manager Audit Collection Service (AdtServer).

Acum baza de date va fi ‘curatata’ la urmatorul ‘scheduled maintenance’ de obicei pe timpul noptii cand numarul de evenimente generate este mai mic.

THE END…

SCOM Event ID 10830, Health Service Modules error

Acum câteva săptămâni m-am lovit de o problema care mi-a dat ceva de furca… O eroare care apare din minut in minut.

Poate au mai întâlnit-o si alții, dar din ce soluții am găsit pe net majoritatea ziceau sa refaci baza, restore, flush cache, etc,  si alte povesti de genul asta.

Abia acum scriu despre asta pentru ca am așteptat sa vad daca reapare problema dar totul este in regula acum.

Eroarea respectiva arata cam așa:

Ok , deci avem un ID pentru regula de colectare, numele bazei afectate, tabelul, coloana si de la ce e conflictul, adică ‚FOREIGN KEY constraint’.

Prima data sa vedem ce este afectat. Trebuie sa identificam regula menționata in mesaj. Deschidem o consola de PS cu modulul de SCOM importat.

Get-SCOMRule -Id 4fc013b2-aa11-b2d2-ec51-b198640fae00 | fl name, id, displayname

OK, deci acum știam ce este afectat de aceasta eroare.

Mai departe sa vedem in baza de date mai multe detalii. Navigam ‚bătrânește’ in baza operaționala  OperationsManager, tabelul dbo.BaseManagedEntity, coloana BaseManagedEntityId, asa cum scria in mesajul de eroare

Facem click dreapta pe dbo.BaseManagedEntity si selectam Design. Apoi selectam Relationships.

Apare fereastra de Foreign Key Relationships si verificam sa fie selectata rubrica care ne interesează, in acest caz FK_AlertBasedManagedEntity. Apoi deselectam FK constraint după care salvam.

Pe scurt Foreign Key constraint asigura relaționarea intre tabele, coloane, grupuri de coloane etc.\

Mai multe detalii despre Foreign Key constraint :

http://msdn.microsoft.com/en-us/library/ms175464(v=sql.105).aspx

Atenție! Acest mod de funcționare nu este recomandat in producție pentru ca nu se mai asigura consistenta datelor, dar având in vedere ca știam despre ce date este vorba si ce presupunea modificarea respectiva am ales sa o configurez astfel.

După dezactivarea setării de foregin Key constraint normal ca datele (alertele) au putut f introduse baza de date.

După o perioada de aproximativ 15 minute am reactivat opțiunea de FK constraint si workflow-ul a revenit la normal.

Pana in prezent nu a mai apărut aceasta eroare.

THE END!

ADM import fail (The file cannot be loaded)

O chestie de care m-am lovit la un moment dat cu SCOM 2007 R3 speram sa se fi rezolvat pentru SCOM 2012/SP1. Se pare ca nu.

Ideea este ca dupa ce urmezi Wizard-ul de Configure Client Monitoring, adica ‘asta’…

..totul merge ok si iti configureaza share-ul unde sa tina rapoartele si informatiile cu erorile de pe clienti, si iti exporta un template de Group Policy adm (nu ADMX desi se poate converti folosind ADMX Migrator sau altceva…).

Acest template se importa pe domain controller pentru a configura setarile de ‘error reporting’ pe clienti prin Group Policy. Acest tip de configuratie se numeste AEM (‘agentless exception monitoring‘) deci nu foloseste agenti. Acest tip de configuratie consuma mai multe resurse decat ‘agent based’ monitoring.

Si iau frumos fisieru, intru pe DC, scriu gpedit.msc, click dreapta pe Administrative Templates si …..

Urat …

Solutia:

Instalati un utilitar de genul Notepad++ , editati fisierul adm, mergeti la liniile respective, si veti gasi calea cate serverul de SCOM este scrisa pur si simplu, fara ghilimele. Sunt cam patru linii unde trebuie incadrata calea in ghilimele si asta este tot.

Apoi o sa gasiti setarile urmatoare in GPO pe orice domain controller dupa ce replicarea a ajuns la convergenta…

Iar in SCOM in tab-ul de Monitoring , Agentless Exception Monitoring…

THE END….

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….

• 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…

M-am gandit sa scriu ceva despre cum trebuie configurat autoenrollment-ul certificatelor pentru a funcționa corect. Cum se face… intai va trebui sa publicam un template care sa faca ce vrem noi. Ne logam pe serverul de CA sau folosim RSAT si deschidem certsrv.msc pentru a administra certificatele. Facem click dreapta si selectam Manage.

Apoi duplicam un template predefinit si il configuram in functie de necesitati. In cazul nostru folosim template-ul Workstation Authentication.

Apoi partea importanta, modificam securitatea template-ului creat corespunzator. Daca spe exemplu vrem sa facem autoenroll atunci trebuie selectata si optiunea de autoenroll.

Important:

Daca vrem sa permitem Autoenroll este obligatioriu sa selectam si permisiunea de Enroll.

Pe proprietatile Template-ului publicat permisiunile de baza ce trebuiesc asignate pentru a functiona corect sunt:

• Authenticated Users (implicit) – Read (acesta este obligatoriu altfel nu o sa mearga autoenroll)
• Domain Admins (implicit) – Read, Write, Enroll
• Domain Computers (implicit) – Enroll + Autoenroll ca sa faca ….autoenroll
• Enterprise Admins (Implicit) – Read, Write, Enroll
• Daca avem Users sau Computers din alte domenii trebuiesc adaugate permisiunile pe template.

Cam atat cu configurarea template-ului…

Mai departe configuram o Politica de Grup prin care setam sa faca autoenroll si o aplicam pe Computers sau Users in functie de cum am configurat template-ul. In cazul nostru vrem sa facem autoenroll pe computer deci modificam setarile corespunzatoare computerelor si aplicam politica computerelor sau grupului de computere, de exemplu Domain Computers.

Setarile de configurare pentru Autoenrollment in GPO se gasesc la :

Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\Certificate Services Client – Auto-Enrollment Settings

La Configuration Model selectam Enabled.

Asignam (link) politica la Domeniu sau la un OU in funcție de caz, varificam ca la Scope sa vizeze Computer objects sau un grup de Computer objects. In cazul meu am restrans aplicabilitatea la doar un singur host.

In aceasta fereastra la Delegation mergem pe Advanced, si verificam ca acel Computer sau Grup sa aibă drept de Read si Apply group policy.

Cam asta este si cu configurarea politicii de Autoenrollment…

Acum, pe client pentru a forta Autoenrollment-ul, deschidem o ferastra CMD si executam gpupdate /force.

Apoi sa verificam executand MMC – Certificates –Local Computer si verificam containerul Personal. Acolo ar trebui sa apara un alt container Certificates care sa contina certificatul dorit.

Asta este tot ce trebuie configurat.

Daca ceva nu merge? Ce fac?

Dupa ce am configurat tot ce era de configurat pe partea de server (Politica, Template, Permisiuni) verificam setarile din partea de client. In primul rand sa vedem daca se aplica politica ce face posibil autoenrollmentul. Tool-urile sunt cele obisnuite cu care sunt sigur ca sunteti familiarizati de exemplu gpresult /h c:\report.html, rsop.msc, Group Policy logging, etc.

Odata ce suntem siguri ca politica se aplica corespunzator verificam si in registri pentru a fi siguri ca a fost activat autoenrollment-ul. Daca se configureaza autoenrolment pentru User sa va deschide HKEY_CURRENT_USER, daca se face pentru computer se va merge pe HKEY_LOCAL_MACHINE. In cazul nostru varianta a doua deci calea va fi:

HKLM\SOFTWARE\Policies\Microsoft\Cryptography\AutoEnrollment

Daca AutoEnrollment-ul a fost configurat cum trebuie acolo va fi o inregistrare DWORD AEPolicy cu valoarea 7. Atentie daca nu exista aceasta inregistrare Autoenrollment-ul NU FUNCTIONEAZA.

Ca si informatii aditionale aveti un tabel cu valorile posibile ale inregistrarii AEPolicy:

Dupa ce am vazut ca se aplica corect politica, trebuie sa vedem daca avem drepturi pe template.

MMC – Certificates –Local Computer si click dreapta pe containerul Personal. Selectam All tasks – Request New Certificate. Apasam Next de doua ori si acolo ar trebui sa vedem daca putem face manual Enroll la acel template. Daca nu vedem Template-ul selectam casuta din dreptul Show all templates.

Odata ce o gasim, vedem ce mesaj apare in dreptul ei, de exemplu „You do not have permissions to view/enroll this type of certificate.” – in acest caz trebuiesc revazute permisiunile pe template.

Daca se aplica politica, am drepturi dar nu apare acea inregistrare?

Daca acesta este cazul putem sa pornim Logging-ul pentru a afla mai multe detalii. Deschidem Regedit si configuram logging-ul in functie de aplicabilitatea template-ului (User sau Computer).

HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Autoenrollment (Computer AE)

HKEY_CURRENT_USER\Software\Microsoft\Cryptography\Autoenrollment (User AE)

Cream  o inregistrare DWORD numita AEEventLogLevel cu valoarea 0.

Ne uitam in eventvwr.msc in Application log pentru mai multe detalii dupa ce incercam sa fortam procesul folosind gpupdate /force. Acum, in functie de mesaj puteti gasi online tot felul de solutii dar am sa va dau totusi un exemplu in care AutoEnrollment-ul nu functiona corespunzator.

Mai mult incercam si sa facem enroll manual sa vedem ce apare…

MMC – Certificates –Local Computer si click dreapta pe containerul Personal. Selectam All tasks – Request New Certificate. Apasam Next de doua ori si acolo ar trebui sa vedem daca putem face manual Enroll la acel template.

Ce trebuie verificat in acest caz? Pe serverul de CA trebuie sa verificam permisiunile de COM Security pentru grupul Certificate Service DCOM Access. Fiecare server de certificate are un astfel de grup local. Daca avem mai multe servere CA, aceste setari trebuies verificate pe fiecare din ele. Deci verificam sa aiba permisiuni de Local Access si Remote Access.

Start – Accessiories – Component Services – expandam Computers si dam click dreapta pe My Computer.

Navigam la COM Security si accesam Access Permissions – Edit Limits. Verificam permisiunile Grupului mentionat anterior.

Totul bine pana acum. Mai departe verificam Membrii grupului Certificate Service DCOM Access pe serverul de CA.

Si aici era problema. Acest grup reprezinta cine se poate conecta la serverul de CA din acel enterprise. By default Membrii acestui Grup sunt NT AUTHORITY\Authenticated Users. Aceasta setare merge fara probleme in cazul in care ai un single forest-single domain, dar daca ai mai multe domenii / foresturi cum se intampla la firmele mari, atunci trebuies adaugati ca membrii in acest grup, acele grupuri care trebuie sa contacteze CA-ul respectiv. De exemplu daca vrem sa impingem autoenroll pentru calculatoarele din doua domenii vom adauga ceva de genul:

• DOMAIN1\Domain Computers
• DOMAIN2\Domain Computers

La fel daca este cazul pentru User Autoenrollment.

Alte resurse utile:

http://blogs.msdn.com/b/windowsvistanow/archive/2008/04/08/troubleshooting-certificate-enrollment.aspx

Configure AutoEnrollment:

http://technet.microsoft.com/en-us/library/cc731522.aspx

Certificate Autoenrollment in Windows Server 2003:

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

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

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

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!

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