Se pare că karma mea este aceasta: să implementez sarcini standard în tot felul de moduri non-triviale. Dacă cineva are o viziune diferită asupra problemei, vă rugăm să discutați despre aceasta, astfel încât problema să poată fi rezolvată.
Într-o bună dimineață a apărut o sarcină interesantă de a distribui drepturi către grupuri de utilizatori pentru diferite partajări care conțin subdosare de proiecte cu foldere de documente. Totul a fost în regulă și a fost scris un script pentru a atribui drepturi folderelor. Și apoi s-a dovedit că grupurile ar trebui să conțină utilizatori din diferite domenii, din diferite păduri (). Să presupunem că share-ul în sine se află pe suportul Synology, înregistrat în domeniul FB al pădurii PSI. Sarcină: să permită utilizatorilor domeniilor dintr-o altă pădure să aibă acces la conținutul acestui share, și foarte selectiv.
După ceva timp, specificațiile tehnice au luat următoarea formă:
- 2 paduri: padure PSI, padure TG.
- Fiecare pădure are 3 domenii: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Există o relație de încredere între păduri; Synology vede toate grupurile de securitate din toate pădurile.
- Partajările și folderele/subdosarele trebuie să aibă conturi de administrator de domeniu FB cu drepturi FullControl
- Numele folderelor ar trebui sistematizate. Managementul a coordonat ID-urile proiectului; am decis să leg numele grupurilor de securitate la ID-urile proiectului.
- Dosarele de proiect din partajarea sistemului trebuie să conțină o structură pregătită în prealabil într-un fișier .xlsx, cu privilegii de acces adecvate (R/RW/NA, unde NA – fără acces)
- Ar trebui să fie posibil să se limiteze drepturile utilizatorilor/membrilor grupului unui proiect doar la anumite directoare ale acelui proiect. Este posibil ca utilizatorul să nu aibă acces la alte directoare/proiecte, în funcție de apartenența la grup.
- Când se creează un folder de proiect, grupurile ar trebui create cât mai automat posibil în domeniile corespunzătoare, cu nume corespunzătoare ID-urilor proiectului.
Note la specificațiile tehnice
- Stabilirea relațiilor de încredere nu este inclusă în domeniul de aplicare al specificațiilor tehnice
- ID-ul proiectului conține numere și caractere latine
- Rolurile de utilizator de proiect pentru toate domeniile au nume standard
- Un fișier .xlsx cu foldere și drepturi de acces (matrice de acces) este pregătit înainte de începerea întregului proiect
- La implementarea proiectelor, este posibil să se creeze grupuri de utilizatori în domeniile corespunzătoare
- Automatizarea este realizată prin utilizarea instrumentelor standard de administrare MS Windows
Implementarea specificațiilor 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 acestora. A fost destinat să folosească doar PowerShell, pentru a nu complica proiectul. După cum am scris mai devreme, algoritmul de script mi s-a părut destul de simplu:
- înregistrăm grupuri cu un nume derivat din ID-ul proiectului (de exemplu KC40587) și rolurile corespunzătoare specificate în matricea de acces: KC40587-EN- pentru inginer; KC40587-PM – pentru manager de produs etc.
- obținem SID-urile grupurilor create
- înregistrați folderul proiectului și setul corespunzător de directoare (lista de subdirectoare depinde de partajarea în care este creat și definit în matricea de acces)
- atribuie drepturi grupurilor pentru noi subdirectoare ale proiectului conform matricei de acces.
Dificultăți întâmpinate în etapa 1:
- neînțelegere a metodei de specificare a matricei de acces în script (acum este implementată o matrice multidimensională, dar se caută calea pentru completarea acesteia pe baza conținutului fișierului .xlsx/matricei de acces)
- imposibilitatea de a seta drepturi de acces în partajările SMB pe unitățile synology folosind 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ăruia s-a pierdut mult timp și totul a trebuit adaptat la scripturi folosind utilitarul de editare a drepturilor de acces icacls, care 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 unui folder pentru proiect.
De asemenea, s-a dovedit că scriptul ar trebui să fie executat și pentru a înregistra grupuri în alte păduri (a fost folosit termenul Cross-domains), iar raportul poate fi nu numai 1 la unu, ci și 1 la mulți.
Aceasta înseamnă că grupurile din alte domenii încrucișate, inclusiv o pădure învecinată, pot revendica acum acces la resursele oricărui domeniu. Pentru a obține uniformitate, s-a decis crearea unei structuri simetrice în OU a tuturor domeniilor deservite ale tuturor pădurilor (ovale verticale negre). După cum se spune, în armată totul ar trebui să fie urât, dar uniform:
Astfel, la înregistrarea proiectului 80XXX în domeniul TG, scriptul execută:
1. crearea OU-ului corespunzătoare (ovale orizontale roșii) în acest domeniu și cross-domains, adică acele domenii ai căror angajați trebuie să aibă acces la această resursă.
2. completarea OU cu grupuri cu nume precum -, unde:
- Domeniul SRC_ – domeniu încrucișat ai cărui angajați vor avea acces la resursele domeniului DST
- DST_domain – domeniul la ale cărui resurse, de fapt, ar trebui să se asigure accesul, adică de dragul căruia totul a fost început
- — numărul proiectului
- ROLURI – numele rolurilor enumerate în matricea de acces.
3. citirea matricei de SID-uri ale tuturor grupurilor din toate domeniile implicate și salvarea acesteia pentru transferul ulterior de date într-un fișier care definește drepturile pentru un anumit subdosar de proiect
4. generarea de fișiere sursă (parametru /restore) cu un set de drepturi pentru utilizare de către utilitarul icacKC în modul fișier executabil „icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"
5. crearea unui fișier CMD care combină toate icacls lansate pentru toate folderele de proiect
După cum a fost scris mai devreme, lansarea fișierului executabil se face manual, iar evaluarea rezultatelor execuției se face și manual.
Dificultăți cu care a trebuit să ne confruntăm în final:
- dacă folderul proiectului este deja umplut cu un număr mare de fișiere, atunci rularea comenzii icacls pe volumele existente poate dura mult timp și, în unele cazuri, poate duce la eșec (de exemplu, când există căi lungi pentru fișiere);
- pe langa parametrul /restore a trebuit sa adaugam linii cu parametrul /reset in cazul in care folderele nu au fost create, ci au fost transferate din foldere existente anterior, cu drepturi de mostenire de la root dezactivate;
- O parte din scriptul pentru crearea de grupuri trebuia executată pe un dc arbitrar al fiecărei păduri, problema se referă la conturile administrative pentru fiecare arbore.
Concluzie generală: este foarte ciudat că nu există încă utilități cu funcționalitate similară pe piață. Se pare că este posibil să se implementeze funcționalități similare pe baza portalului Sharepoint.
De asemenea, este de neînțeles faptul că nu este posibilă utilizarea utilităților PoSH pentru setarea drepturilor de folder pe dispozitivele sinologie.
Dacă doriți, sunt gata să partajez scriptul creând un proiect pe github, dacă este cineva interesat.
Sursa: www.habr.com