Windows - Politică de grup - Numeroase unități de partajare cu direcționare la nivel de articol

Prezentare generală

Ne-am străduit să facem ca numeroasele noastre site-uri să mapeze drive-urile partajate pentru fiecare utilizator care are nevoie de acces la site-urile lor. Nu avem nicio modalitate de a standardiza acest lucru din cadrul profilului lor AD, deoarece unii utilizatori se deplasează mult și ajung să nu spună IT până când au nevoie de acces la o anumită unitate de partajare a site-ului. La rândul nostru, am creat grupuri de securitate pentru fiecare site și îl vom folosi ca țintă la nivel de articol în cadrul unei politici de grup la rădăcina structurii noastre AD pentru site-uri, în speranța că se va scurge și le va oferi doar celor din grupurile de securitate unitățile de care au nevoie.

Informatii despre sistem

Sistem de operare: Windows Server 2016

Următoarele se referă la patru mașini din două DC-uri

Controlere de domeniu (GPO, Active Directory)

Sistem de operare: NetApp care va fi înlocuit în viitorul apropiat cu Nutanix Files.

Partajați Drive-uri pentru fiecare dintre site-urile noastre sub rădăcină și fără sub-share, deoarece utilizatorii vor popula aceste dosare partajate cu orice fișiere pe care le folosesc/creează

Structura

Mapăm o unitate către utilizatorii noștri care se conectează la dispozitivul nostru NetApp. Dispozitivul NetApp are subfoldere bazate pe fiecare nume de site, care, la rândul lor, au orice au pus utilizatorii în aceste foldere. Structura arată similar cu următoarea:

NetApp Shares
âââ Site-ul 1
âââ Site-ul 2
âââ Site-ul 3
âââ Site-ul 4
âââ Site-ul 5

Avem mai multe grupuri de securitate, cum ar fi următoarele:

Site1-ShareDrive
Site2-ShareDrive
Site3-ShareDrive
Site4-ShareDrive
Site5-ShareDrive

În cadrul acestor grupuri de securitate avem utilizatori care s-ar putea să nu fie în mod nativ în OU al site-ului, deoarece unii administrează mai multe site-uri sau se deplasează des și au nevoie de mai multe site-uri în cadrul diviziei lor.

Exemplu:

Site1-ShareDrive
âââ Utilizator13
âââ Utilizator20
âââ Utilizator33
âââ Utilizator42
âââ Utilizator51

Site4-ShareDrive
âââ Utilizator13
âââ Utilizator22
âââ Utilizator23
âââ Utilizator1
âââ Utilizator5
âââ Utilizator3
âââ User100

Site9-ShareDrive
âââ Utilizator13
âââ Utilizator22
âââ Utilizator23
âââ Utilizator1
âââ Utilizator53
âââ Utilizator54
âââ Utilizator545

Structura AD:

Toate site-urile
âââ Divizia-1
| âââ Site-ul 1
| âââ Site-ul 2

âââ Divizia-2
| âââ Site-ul 3
| âââ Site-ul 4
| âââ Site-ul 5

âââ Divizia-3
| âââ Site-ul 6
| âââ Site-ul 7
| âââ Site-ul 8

âââ Divizia-4
| âââ Site-ul 9
| âââ Site-ul 10

Pentru Politica de grup, am dori să plasăm politicile la nivelul „Toate site-urile” pentru a se scurge teoretic în întreaga structură, dar să le aplicăm doar în funcție de dacă utilizatorii se află în grupul de securitate vizat.

Problema

În cadrul Politicii de grup, creăm noi politici pentru fiecare site care au o țintă la nivel de articol pentru grupul de securitate al site-ului respectiv.

De exemplu:

User1 aparține următoarelor grupuri:

Managerii
Site1-ShareDrive
Site9-ShareDrive

Utilizatorul 13 aparține următoarelor grupuri:

Partener
Site1-ShareDrive
Site4-ShareDrive
Site9-ShareDrive

În mod logic, următoarele ar trebui să fie configurația noastră:

• Utilizator1 ar trebui să aibă acces doar la \example.com\Shares\Site1 și \site9
• Utilizator13 ar trebui să aibă acces doar la \example.com\Shares\Site1, \site4 și \site9

Din păcate, această problemă există la o scară mult mai mare atunci când adăugați faptul că unii utilizatori care ar putea fi manageri au nevoie de un singur site, în timp ce alți manageri ar putea avea nevoie de mai multe site-uri și de acces de parteneri la divizia de care sunt responsabili. Cealaltă problemă cu care ne confruntăm este că unele site-uri sunt o cooperare între divizii, motiv pentru care unii utilizatori din afara OU al diviziei lor au nevoie de acces la site-urile unei alte divizii partajează drive-uri. În afară de adăugarea acestora la aceste grupuri de securitate, coborârea la nivelul fișierului pentru permisiunile NTFS în acest moment va fi un coșmar, deoarece folosim un vechi dispozitiv NetApp care de fapt va fi în curând EOL de către furnizorul nostru. Nu avem încă o cronologie privind momentul în care vom migra către o nouă platformă.

În plus

Am prefera să ascundem toate dosarele la care utilizatorii nu au acces. În exemplul de mai sus, de exemplu, User1 nici nu ar ști despre existența \example.com\Shares\Site8, deoarece utilizatorul nu aparține grupurilor de securitate respective.

Am dori să putem aplica câteva grupuri de securitate în funcție de site-ul de care are nevoie utilizatorul. Împreună cu plasarea unei ținte la nivel de articol pe acel grup de securitate. Structura noastră actuală OU seamănă cu următoarea:

Exemplu de structură OU

Toate site-urile
    Site 1
      Utilizator13
    Site 4
      Utilizator1
    Site-ul 9
      Utilizator545

Întrebări

1. Cum ne putem asigura că structura noastră funcționează cu direcționarea la nivel de articol? (adicăGP: „Acces laSite1-ShareDrive” ar avea unitatea „\example.com\shares\Site1” mapată prin „Actualizare” și „Reconectare” Bifată, împreună cu „Rulează în contextul de securitate al utilizatorului” și „Țintă la nivel de articol” setate la „Site1-ShareDrive”, cu linkul la „Toate site-urile”)?
2. Dacă unele dintre cele de mai sus nu sunt posibile, cum putem asigura ușurința de utilizare pentru utilizatorii noștri, sporind în același timp productivitatea IT?

Cateva lucruri:

Ascunderea fișierelor și folderelor fără permisiuni:
Pentru a ascunde folderele la care utilizatorii nu au acces, puteți activa „Enumerarea bazată pe acces” pe partajări. Acestea fiind spuse, nu este recomandat să faceți acest lucru decât dacă aveți o cerință strictă pentru aceasta. ABE poate provoca o creștere semnificativă a utilizării CPU pe partajările de fișiere, deoarece ACL-ul fiecărui fișier trebuie enumerat ori de câte ori este traversat un director.

Conectarea GPO-urilor la site-uri logice AD:
Puteți economisi ceva timp de procesare a preferințelor de politică de grup aplicând un GPO pentru unitățile mapate direct pe site-urile dvs. logice Active Directory, dacă aveți un site AD logic care reprezintă fiecare locație fizică. (Rețineți că acest lucru necesită utilizarea consolei de gestionare a site-urilor și serviciilor AD sau a modulului AD PowerShell pentru a mapa subrețele la anumite site-uri.) Singura provocare a acestei abordări este câțiva utilizatori care trebuie să acceseze mai multe site-uri partajate, indiferent de site. sunt la. Acest lucru poate fi realizat prin crearea unei anumite redundanțe între GPO-urile specifice site-ului pentru maparea unităților, dar din nou... devine mai puțin eficient.

Înapoi la preferințele politicii de grup:
Se pare că aveți o bună înțelegere inițială a modului de utilizare a direcționării la nivel de articol pentru acest job. Iată un potențial layout ILT pentru un ipotetic "Distribuie 1" la "Site-ul A":

Editați GPO și extindeți prin Configurare utilizator > Preferințe > Setări Windows, apoi faceți clic pe Drive Maps.

1. Configurați setările generale ale hărții unității pentru Distribuie 1 la Site-ul A.
2. Accesați fila Comune, activați direcționarea la nivel de articol și faceți clic pe butonul Setări de direcționare.
3. Acum veți dori să utilizați mai multe colecții ILT pentru a grupa condițiile de direcționare. Din ceea ce ați descris, aș crea ceva care să arate astfel:

Articole și colecții ILT

1. Adăugați o colecție în care „aceasta colecție este adevărată”

• Adăugați o condiție care afirmă utilizatorul este membru al grupului de securitate „Site A”
• Adăugați o condiție [ȘI] site-ul este „SiteA”

2. Adăugați o a doua colecție (unde această colecție este adevărată) și setați Opțiunile pentru articole ale colecției la SAU

• În a doua colecție, adăugați un articol pentru a include managerii care au nevoie de acces la mai multe partajări ale site-ului. Utilizați un grup de securitate și setați elementul la „utilizatorul este membru al grupului de securitate „Administratorii de site” (presupunând că acest grup are acces la mai multe partajări de site.

Faceți clic pe OK pentru a salva și a închide elementul actual al hărții unității. Acest exemplu vă poate rezolva provocarea.

Control dinamic al accesului
De asemenea, poate doriți să verificați utilizarea funcției Dynamic Access Control pe serverul dvs. de fișiere. Această caracteristică face ACL-urile (liste de control al accesului) dintr-un sistem de fișiere mult mai puternice, activând două funcții noi:

• Capacitatea de a folosi ambele SAU și ȘI operatori în ACL-uri
• Posibilitatea de a adăuga permisiuni bazate pe revendicări sau condiții la permisiuni. Afirmațiile se pot baza pe 3 tipuri de obiecte: atribute utilizator, atribute dispozitiv sau revendicări de transformare (de obicei din regulile create într-o politică).

Afirmațiile utilizatorilor și dispozitivelor se pot baza pe majoritatea atributelor obiectelor utilizator sau dispozitiv din AD, așa că, ipotetic, ați putea merge până la crearea unei reguli DAC care spune: acordați acces utilizatorului dacă acesta se află în „Grupul A” și nu se află pe un dispozitiv mobil și dacă utilizează un computer care se află în „Site-ul A” (acest lucru s-ar baza pe subrețeaua de adrese IP care este mapată în AD). În plus, puteți utiliza politicile de clasificare a datelor pentru a aplica diferite reguli de control dinamic al accesului, în funcție de afirmațiile utilizatorului sau dispozitivului... dar acesta este următorul nivel! Aș recomanda să cercetați DAC, dar să știți că are dependențe mai complexe decât pur și simplu să lucrați printr-o configurație bună de direcționare la nivel de articol.