Group Managed Service Accounts in Windows 2012
Una dintre noutatile din Windows 2012 ce nu prea am vazut-o folosita foarte des este Group Managed Service Accounts (aka gMSA) si este o urmare fireasca a Managed Service Accounts (MSA) din Windows 2008.
Mai tineti minte MSA, nu? Eu nu prea pentru ca nu mi se paruse utilizabil, trebuia sa fac cate un cont pe fiecare server, scenariile de utilizare erau foarte limitate, etc. Ce e important sa ne amintim, este ca un managed service account isi gestioneaza singur parola si astfel administratorul poate elimina de pe lista de taskuri schimbarea periodica a parolei si modificarea ei pe serverele unde este folosit contul.
Ei bine gMSA este o evolutie normala a MSA si rezolva o problema pe care am spus-o mai sus. Si anume, un astfel de cont poate fi folosit pe mai multe sisteme. De aici si denumirea, este de fapt un service account ce poate fi folosit pe un grup de servere.
Schimbarile constau in special in modul de generare si folosire a parolei. De data aceasta parola este generata pe domain controller de serviciul Key Distribution Service (KDS) ce foloseste un algoritm ce include o cheie creata in prealabil, cheie ce se va afla pe toate domain controllere. Cum toate domain controllerele vor folosi acelasi algoritm si aceeasi cheie ce va fi replicata intre DC-uri, parola va fi identica indiferent de cine o genereaza.
Ca sa puteti folosi gMSA va fi nevoie sa aveti macar un DC cu Windows 2012 in domeniu (automat si update de schema cu atributele necesare pentru gMSA).
Primul pas este sa creati ROOT KEY, acea cheie folosita pentru generarea parolei. Se face din Powershell (de fapt cam tot ce implica gMSA se face din Powershell) cu comanda Add-KdsRootKey –EffectiveImmediately.
Atentie ca –EffectiveImmediately nu inseamna ca se face instantaneu. A fost introdus un ‘lag’ de 10 ore pentru ca aceasta cheie sa fie replicata pe toate domain controllerele si deci va trebui sa asteptati ceva pana sa puteti seta primul gMSA.
Exista si un workaround (pentru medii de test) ce face totul instantaneu (recomand totusi un repadmin /syncall):
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
Odata creata cheia avem liber la creat primul service account. Dar mai intai trebuie sa stabilim ce servere vor avea acces la acest cont. Iar lucrul asta il putem face printr-un security group. Putem face unul nou sau ne putem folosi de un grup existent. De exemplu eu o sa folosesc grupul domain controllers pentru a folosi noul cont pe toate domain controllerele.
Nota: In caz ca folositi un grup nou, serverele respective vor trebui sa isi reinoiasca ticketele Kerberos, reboot, sau klist purge –li 0x3e7 pentru a face purge la ticketele din sesiunea computer account-ului. Comenzile pentru gMSA specifica si faptul ca poti adauga direct lista de servere ce vor avea acces fara a folosi un grup de securitate, insa eu nu am vazut sa mearga aceasta optiune. Deci tot la grup ramanem.
Contul il facem cu New-ADServiceAccount si trebuie sa specificam numele contului, un nume FQDN si grupul ce va avea acces (parametrul –PrincipalsAllowedToRetrieveManagedPassword).
Noul cont il putem vedea deja in AD.
Pasul urmator va fi sa “instalam” acest cont pe un server si sa testam daca poate fi folosit. Pentru asta vom folosi Install-ADServiceAccount si Test-ADServiceAccount.
Dar asta nu este tot. In exemplu de aici dorim sa folosim acest cont pe domain controllere, asa ca va trebui sa ii dam drepurile necesare pentru a putea rula aici, adica eu in cazul meu va trebui sa il adaug in grupul domain admins.
Din acest moment contul meu are drepturi depline de a rula pe domain controllere si dupa cum am si denumit contul backupAccount, va avea drepturi de a face backup si de a rula ca si job.
Dar in acest moment voi folosi ca exemplu un serviciu pentru ca setarea unui job de backup presupune si alte elemente ce nu le voi acoperi in acest articol.
Tot ce trebuie sa faceti este sa adaugati un $ la numele contului si sa nu setati parola.
Pentru setarea unui job de backup este nevoie de crearea unui job in task scheduler iar interfata grafica nu functioneaza cu gMSA. Va fi nevoie din nou de Powershell si de un batch cu comanda de backup (wbadmin parca e mai simplu decat powershell la capitolul asta). Probabil voi reveni in curand cu detalii si despre acest task.
Retineti ca nu toate componentele din OS functioneaza cu gMSA. Important este ca merg serviciile si Task Scheduler. Din ce am mai citit am inteles ca functioneaza si cu IIS application Pool si SQL 2012.
Recunosc ca pare destul de complicat la inceput si poate ca si asta este motivul pentru care nu a prea prins la public, insa dupa ce faci task-ul asta de cateva ori devine destul de banal.