Atribuirea extinsă a drepturilor pentru utilizatorii domeniilor din păduri diferite

Se pare că am o karmă de acest gen: să realizez sarcini standard în moduri neobișnuite. Dacă cineva are o altă viziune asupra problemei — vă rog să participați la discuție pentru a dezbate subiectul.

Într-o dimineața frumoasă, a apărut o sarcină interesantă: de a distribui drepturi grupurilor de utilizatori pentru diferite share-uri, care conțin subfoldere ale proiectelor cu foldere de documente. Totul mergea bine și am scris un script care atribuia drepturile asupra folderelor. Apoi s-a descoperit că grupurile trebuiau să conțină utilizatori din domenii diferite, din păduri diferite (pentru cei care au uitat ce este aceasta). Să presupunem că share-ul în sine este găzduit pe un suport Synology, înregistrat în domeniul FB, pădurea PSI. Sarcina: a permite utilizatorilor domenii din altă pădure să acceseze conținutul acestui share, și anume, foarte selective.

Cerințele au început să contureze astfel:

• 2 păduri: Pădurea PSI, pădurea TG.

  

• În fiecare pădure există 3 domenii: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Între păduri există relații de încredere, Synology vede toate grupurile de securitate din toate pădurile.
• Pe share-uri și foldere/subfoldere trebuie să existe neapărat conturi de admini din domeniul FB cu drepturi de FullControl
• Numele folderelor share trebuie să fie sistematizate. Aprobat de conducere, am decis să leg numele grupurilor de securitate de ID-urile proiectelor.
• Folderele proiectelor din share-urile sistemice trebuie să conțină o structură pregătită anterior în fișierul .xlsx, cu privilegii corespunzătoare de acces (R/RW/NA, unde NA – accesul nu există)

  

• Trebuie să existe posibilitatea de a restricționa drepturile utilizatorilor/membrilor unui proiect doar la anumite directoare ale acelui proiect. La alte directoare/proiecte, utilizatorul poate să nu aibă acces, conform apartenenței la grupuri.
• La crearea folderului proiectului, grupurile corespunzătoare din domeniile relevante trebuie să fie create cât mai automatizat, cu nume care corespund ID-urilor proiectelor.

Note referitoare la cerințele tehnice

• Configurarea relațiilor de încredere nu este inclusă în cerințele tehnice
• ID-ul proiectului conține cifre și litere latine
• Rolurile utilizatorilor proiectelor pentru toate domeniile au denumiri standardizate
• Fișierul .xlsx cu foldere și drepturi de acces (matricea de acces) este pregătit înainte de începerea implementării întregului proiect
• În implementarea proiectelor, este posibilă crearea de grupuri de utilizatori în domeniile corespunzătoare.
• Automatizarea se realizează prin utilizarea resurselor standard de administrare MS Windows.

Implementarea specificației tehnice.

După formalizarea acestor cerințe, a fost luată o pauză tactică pentru a testa metodele de creare a directoarelor și de atribuire a drepturilor asupra acestora. Se dorea utilizarea exclusivă a PowerShell pentru a nu complica proiectul. Așa cum am menționat anterior, algoritmul scriptului era considerat destul de simplu:

• înregistrăm grupuri cu denumiri derivate din ID-ul proiectului (de exemplu KC40587) și rolurile corespunzătoare, specificate în matricea de acces: KC40587-EN- pentru inginer; KC40587-PM – pentru managerul de produs etc.
• obținem SID-urile grupurilor create.
• înregistrăm folderul proiectului și setul corespunzător de directoare (lista subdirectoarelor depinde de share-ul în care este creat și este definită în matricea de acces).
• atribuim noi subdirectoare proiectului drepturi grupurilor conform matricei de acces.

Dificultățile întâmpinate în prima etapă:

• neînțelegerea modului de a specifica matricea de acces în script (acum este implementat un array multidimensional, dar se caută o cale pentru completarea acestuia pe baza conținutului fișierului .xlsx/matricea de acces).

  

• imposibilitatea de a stabili drepturile de acces în share-urile SMB pe unitățile Synology prin mijloace PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas-share?forum=winserverpowershell), din cauza căreia s-a pierdut mult timp și a fost necesară adaptarea totul la scripturi folosind utilitarul de editare a drepturilor icacls, ceea ce a necesitat crearea unui depozit intermediar de fișiere text și cmd.

În modul curent, execuția fișierelor cmd este controlată manual, în funcție de necesitatea înregistrării folderului pentru proiect.

De asemenea, s-a constatat că scriptul trebuie să fie executat, inclusiv pentru înregistrarea grupurilor în alte păduri (am folosit termenul Cross-domains), iar relația poate fi nu doar 1 la 1, ci și 1 la mulți.

Aceasta înseamnă că grupurile din domenii încrucișate pot revendica acum accesul la resursele unui anumit domeniu, inclusiv dintr-o pădure vecină. Pentru a realiza uniformitatea, s-a decis crearea unei structuri simetrice în OU pentru toate domeniile gestionate din toate pădurile (ovale verticale negre). Așa cum se spune, armata trebuie să fie totul dezordonat, dar uniform:

Astfel, la înregistrarea proiectului 80XXX în domeniul TG, scriptul efectuează:

1. crearea OU corespunzătoare (ovale orizontale roșii) în acest domeniu și în domeniile încrucișate, adică în acele domenii la care angajații trebuie să aibă acces la acest resource.

2. popularea OU cu grupuri cu denumiri de tipul <SRC_domain><DST_domain><ID_project>- , unde:

• SRC_domain – domeniul încrucișat, angajații căruia vor avea acces la resursele domeniului DST
• DST_domain – domeniul căruia, în esență, ar trebui să i se ofere acces, adică de aceea a fost început totul
• <ID_project> — numărul proiectului
• ROLES – denumirile rolurilor enumerate în matricea de acces.

3. citirea matricei SID a tuturor grupurilor din toate domeniile implicate și salvarea acesteia pentru transmiterea ulterioară a datelor într-un fișier, care definește drepturile asupra unei subfoldere specifice a proiectului

4. generarea fișierelor sursă (parametrul /restore) cu setul de drepturi pentru a fi utilizat de utilitarul icacKC în modul fișier executabil „icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt”

5. crearea unui fișier CMD, care să unifice toate comenzile icacls utilizabile pentru toate folder-urile proiectului

Așa cum s-a menționat anterior, rularea fișierului executabil se face manual, iar evaluarea rezultatelor execuției – de asemenea, se efectuează manual.

Dificultățile întâmpinate în cele din urmă:

• dacă folderul proiectului este deja umplut cu un număr mare de fișiere, atunci executarea comenzii icacls pe volumele existente poate dura un timp semnificativ și în unele cazuri a dus la eșec (de exemplu, în cazul în care există căi lungi pentru fișiere);
• pe lângă parametrul /restore a fost necesar să se adauge linii cu parametrul /reset în cazul în care folderele nu au fost create, ci au fost mutate din foldere existente anterior, cu drepturile de moștenire dezactivate din rădăcină;
• a fost necesar să executăm o parte din script pentru crearea grupurilor pe un dc aleatoriu din fiecare pădure, problema se referă la conturile administrative utilizate pentru fiecare arbore.

Concluzie generală: este foarte ciudat că pe piață nu există până acum utilitare cu funcționalități similare. Este posibilă implementarea unei astfel de funcționalități pe baza portalului Sharepoint.
De asemenea, este un fapt incomprehensibil absența posibilității de a utiliza utilitare PoSH pentru setarea permisiunilor pe foldere pe dispozitivele Sinology.

Dacă cineva este interesat, sunt dispus să împărtășesc scriptul, creând un proiect pe github.

Sursa: habr.com