Local Administrator Password Solution aka LAPS

Eu am spus de multe ori ca cea mai buna solutie pentru protejarea conturilor locale (si de acolo a intregii infrastructuri) este parola unica pe fiecare cont local. Cu un sistem centralizat si bine securizat in care sa stochezi aceste parole, devine floare la ureche. Insa pana de curand, cam tot ce vazusem era destul de complicat, greu de folosit si foarte putina lume incerca asa ceva iar unii chiar nu auzisera.

Exista si o varianta scriptata dar si acolo foarte putini se avantau pentru ca le parea ceva destul de complicat. Asa ca stateau cu aceeasi parola pe contul de administrator si bineinteles expusi atacurilor de tip PTH.

Dar anul trecut Microsoft a pus la dispozitie un tool (LAPS) pentru gestionarea parolelor pentru contul de administrator local. Tool-ul se ocupa cu generarea parolei unice a contului de administrator pe statie si stocarea ei in Active Directory (locul unde vor fi stocate aceste parole).

Nota: LAPS era disponibil si pana acum clientilor ce aveau contracte de suport de tip Premier.

Pentru moment o sa incerc in mare sa fac un rezumat al componentelor ce fac parte din aceasta solutie pentru a fi mai usor de inteles. Solutia este baza pe pe Group Policy. Astfel fiecare computer administrat prin LAPS va avea nevoie de un nou CSE (Client Side Extension) ce se va ocupa de schimbarile de parola. Iar parolele vor fi stocate in Active Directory. Deci vom avea asa:

– un CSE ce se instaleaza pe client (este un DLL ce se va instala dintr-un MSI)

– un ADM ce va fi necesar pe statia de management pentru a administra setarile din GPO

– script pentru extinderea schemei AD ca sa poata stoca noile parole

– tooluri pentru a vizualiza parola din AD

Prima data trebuie sa downloadati solutia de aici:

https://www.microsoft.com/en-us/download/details.aspx?id=46899

In download gasiti urmatoarele fisiere:

 

Vom avea nevoie de un sistem de management, asa ca vom instala versiunea x64 pe sistemul nostru de management (in cazul meu este chiar un domain controller pentru ca este un mediu de test; altfel nu as recomanda).

By default, MSI-ul instaleaza doar AdmPwd GPO Extension (acel CSE sau extensie GPO de care va spuneam mai devreme). Dar pentru sistemul de management vom avea nevoie sa selectam toate componentele, exact ca mai jos:

Un nou modul powershell va fi instalat iar mai jos puteti vedea noile comenzi.

Iar una dintre ele este Update-AdmPwdADSSchema, comanda ce va face update-ul de schema cu noile atribute pentru stocarea parolei. Nu trebuie sa va mai spun ca aveti nevoie de Schema Admins ca sa efectuati acest update.

Odata ce am extins schema mai este ceva de setat legat de aceste atribute. By default userii normali din AD au dreptul sa citeasca foarte multe atribute. De aceea acum va trebui sa verificam si sa restrictionam daca este necesar accesul la aceste atribute. Accesul se va face prin “All extended rights” si avem la dispozitie chiar si un cmdlet prin care putem verifica cine are drepturi pe acest atribut pe un anumit OU:

Daca totusi avem useri sau grupuri ce nu trebuie sa aiba acces, atunci va trebui sa ne conectam cu ADSIEdit, properties pe OU, mers pe tab-ul Security, Advanced:

Selectat user/grupul, Edit si debifat “All extended rights” .

Bun, acum ca ne-am asigurat ca in afara de domain admins nu are nimeni drepturi, e timpul sa dam si cateva drepturi. Odata o sa facem un grup nou numit PasswordRecovery (puteti alege orice nume doriti) si ii vom da drepturi sa citeasca parolele folosind Set-AdmPwdReadPasswordPermission:

Nota: Putem avea grupuri diferite ce pot citi parolele de pe OU-uri diferite. De exemplu putem avea OU cu servere, unde doar anumiti admini vor avea acces la parole.

Dar pe aceste atribute si computer account-urile vor avea nevoie de drepturi ca sa poata updata parola si vom folosi Set-AdmPwdComputerSelfPermission:

Acum ca am terminat cu setat drepturile in AD, hai sa vedem cum facem deployment la acel GPO CSE pe statii. Si solutia pe care o propun acum este tot GPO. Bineinteles ca exista si alte variante, dar momentam lucram cu ce avem builtin. Deci vom face in GPO nou ce se va aplica pe OU-ul nostru cu statii (in cazul meu, acel Test1) si vom folosi functia de deploy software din Group Policy:

Selectam pe rand ambele MSI-uri ce au venit in solutie, setam ca deployment Assigned:

NOTA: Fisierele trebuie sa fie accesibile de catre statii. Eu le-am pus in NETLOGON pentru ca locatia accesibila si este replicata pe toate DC-urile.

Iar la MSI-ul pe 32 de biti trebuie sa mergem in advanced si sa debifam “Make this 32-bit X86 application available to Win64 machines” (pentru ca avem separat versiune pe 64 de biti).

Dupa ce setam politica, si cateva reboot-uri pe statii, o sa putem vedea ca LAPS s-a instalat in Programs and Features:

Iar acum ultimul pas din configurare, este setarea GPO-ului ce va trimite “instructiuni” CSE-ului de pe client. Putem face asta in acelasi GPO ce l-am folosit pentru instalarea pachetelor MSI sau in altul. In exemplul meu, o sa ma folosesc de acelasi GPO. Pe statia de management, in Administrative Templates putem vedea acum o noua rubrica, LAPS:

Urmatoarea setare o sa o las pe Not Configured, pentru ca intentia mea este sa controlez contul Administrator builtin. Acum depinde de cum gestionati statiile si daca ati facut enable la cont in imagine sau ati mers pe varianta cu un alt cont local:

Iar optiunea de mai jos se explica singura; cand CSE-ul va detecta ca parola a expirat va initia imediat schimbarea.

Si ultima optiune dar nu lipsta de importanta este “Enable local admin password management”. Fara aceasta optiune activa, CSE-ul nu va face nimic.

Dupa ce am salvat politica si a fost preluata de una din statiile pe care am instalat si CSE-ul putem vedea deja update-urile in AD. O varianta ar fi prin orice editor de atribute avem la indemana:

Nota: Password Expiration date-ul il putem converti cu w32tm /ntte:

Sau mai putem vizualiza parola si cu unul din tool-urile ce se instaleaza pe statia de management:

Sau din powershell cu Get-AdmPwdPassword:

Si gata, puteti uita de bataia de cap produsa de mentenanta conturilor locale.  GPO & AD will take care of that 🙂

2 Responses to “Local Administrator Password Solution aka LAPS”