Apparentemente il mio karma è questo: implementare compiti standard in tutti i modi non banali. Se qualcuno ha una visione diversa del problema, si prega di discuterne in modo che il problema possa essere risolto.
Una bella mattina è sorto un compito interessante: distribuire i diritti a gruppi di utenti per diverse condivisioni contenenti sottocartelle di progetti con cartelle di documenti. Tutto andava bene ed è stato scritto uno script per assegnare i diritti alle cartelle. E poi si è scoperto che i gruppi dovrebbero contenere utenti di domini diversi, di foreste diverse (). Supponiamo che la condivisione stessa si trovi sul supporto Synology, registrato nel dominio FB della foresta PSI. Compito: consentire agli utenti dei domini di un'altra foresta di avere accesso ai contenuti di questa condivisione, e in modo molto selettivo.
Dopo qualche tempo, le specifiche tecniche hanno preso la seguente forma:
- 2 foreste: foresta PSI, foresta TG.
- Ogni foresta ha 3 domini: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Esiste una relazione di fiducia tra le foreste; Synology vede tutti i gruppi di sicurezza in tutte le foreste.
- Le condivisioni e le cartelle/sottocartelle devono avere account di amministratore di dominio FB con diritti FullControl
- I nomi delle cartelle dovrebbero essere sistematizzati. La direzione ha coordinato gli ID di progetto; ho deciso di collegare il nome dei gruppi di sicurezza agli ID di progetto.
- Le cartelle di progetto nelle condivisioni di sistema devono contenere una struttura preparata in anticipo in un file .xlsx, con privilegi di accesso adeguati (R/RW/NA, dove NA – nessun accesso)
- Dovrebbe essere possibile limitare i diritti degli utenti/membri del gruppo di un progetto solo a determinate directory di quel progetto. L'utente potrebbe non avere accesso ad altre directory/progetti, a seconda dell'appartenenza al gruppo.
- Quando si crea una cartella di progetto, i gruppi dovrebbero essere creati nel modo più automatico possibile nei domini appropriati con nomi corrispondenti agli ID di progetto.
Note alle specifiche tecniche
- La creazione di relazioni fiduciarie non rientra nell'ambito delle specifiche tecniche
- L'ID progetto contiene numeri e caratteri latini
- I ruoli utente del progetto per tutti i domini hanno nomi standard
- Prima dell'inizio dell'intero progetto viene preparato un file .xlsx con cartelle e diritti di accesso (matrice di accesso).
- Durante la realizzazione dei progetti è possibile creare gruppi di utenti nei domini corrispondenti
- L'automazione viene ottenuta utilizzando gli strumenti di amministrazione standard di MS Windows
Implementazione delle specifiche tecniche
Dopo aver formalizzato questi requisiti, è stata presa una pausa tattica per testare i metodi per creare directory e assegnare diritti alle stesse. Si prevedeva di utilizzare solo PowerShell, per non complicare il progetto. Come ho scritto prima, l'algoritmo dello script sembrava abbastanza semplice:
- registriamo i gruppi con un nome derivato dall'ID progetto (ad esempio KC40587) e i corrispondenti ruoli specificati nella matrice di accesso: KC40587-EN- per ingegnere; KC40587-PM – per responsabile prodotto, ecc.
- otteniamo i SID dei gruppi creati
- registrare la cartella del progetto e il corrispondente insieme di directory (l'elenco delle sottocartelle dipende dalla condivisione in cui è creata e definita nella matrice di accesso)
- assegnare i diritti ai gruppi per le nuove sottodirectory del progetto in base alla matrice di accesso.
Difficoltà incontrate nella fase 1:
- incomprensione del metodo per specificare la matrice di accesso nello script (ora è implementato un array multidimensionale, ma il percorso per riempirlo viene cercato in base al contenuto del file .xlsx/matrice di accesso)
- impossibilità di impostare i diritti di accesso nelle condivisioni SMB sulle unità synology utilizzando PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), per cui si è perso molto tempo ed è stato necessario adattare tutto agli script utilizzando l'utilità di modifica dei diritti di accesso icacls, che richiedeva la creazione di un repository intermedio di file di testo e cmd.
Nella modalità corrente, l'esecuzione dei file cmd è controllata manualmente, a seconda della necessità di registrare una cartella per il progetto.
Si è anche scoperto che lo script dovrebbe essere eseguito anche per registrare gruppi in altre foreste (è stato utilizzato il termine Cross-domains) e il rapporto può essere non solo 1 a uno, ma anche 1 a molti.
Ciò significa che i gruppi di altri domini incrociati, inclusa una foresta vicina, possono ora rivendicare l’accesso alle risorse di qualsiasi dominio. Per raggiungere l'uniformità, si è deciso di creare una struttura simmetrica nell'unità organizzativa di tutti i domini serviti di tutte le foreste (ovali verticali neri). Come si suol dire, nell'esercito tutto dovrebbe essere brutto, ma uniforme:
Pertanto, quando si registra il progetto 80XXX nel dominio TG, lo script esegue:
1. creazione delle UO corrispondenti (ovali orizzontali rossi) in questo dominio e tra domini incrociati, ovvero quei domini i cui dipendenti devono avere accesso a questa risorsa.
2. riempire l'unità organizzativa con gruppi con nomi simili -, Dove:
- Dominio SRC_: dominio incrociato i cui dipendenti avranno accesso alle risorse del dominio DST
- DST_domain – il dominio alle cui risorse, in effetti, dovrebbe essere fornito l'accesso, cioè per il quale tutto è stato avviato
- - progetto numero
- RUOLI – nomi dei ruoli elencati nella matrice di accesso.
3. leggere l'array dei SID di tutti i gruppi di tutti i domini coinvolti e salvarlo per il successivo trasferimento dei dati in un file che definisce i diritti su una specifica sottocartella del progetto
4. generazione di file sorgente (parametro /restore) con una serie di diritti per l'utilizzo da parte dell'utilità icacKC in modalità file eseguibile "icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"
5. creazione di un file CMD che combini tutti gli icacl avviati per tutte le cartelle del progetto
Come è stato scritto in precedenza, l'avvio del file eseguibile viene eseguito manualmente e anche la valutazione dei risultati dell'esecuzione viene eseguita manualmente.
Difficoltà che alla fine abbiamo dovuto affrontare:
- se la cartella del progetto è già piena di un numero elevato di file, l'esecuzione del comando icacls sui volumi esistenti può richiedere molto tempo e in alcuni casi portare a errori (ad esempio, quando sono presenti percorsi di file lunghi);
- oltre al parametro /restore, abbiamo dovuto aggiungere delle righe con il parametro /reset nel caso in cui le cartelle non fossero state create, ma fossero state trasferite da cartelle preesistenti, con diritti di ereditarietà dal root disabilitati;
- Parte dello script per la creazione dei gruppi doveva essere eseguito su un dc arbitrario di ciascuna foresta, il problema riguarda gli account amministrativi per ciascun albero.
Conclusione generale: è molto strano che sul mercato non siano ancora disponibili utility con funzionalità simili. Sembra possibile implementare funzionalità simili basate sul portale Sharepoint.
È inoltre incomprensibile che non sia possibile utilizzare le utilità PoSH per impostare i diritti sulle cartelle sui dispositivi Sinology.
Se lo si desidera, sono pronto a condividere lo script creando qualche progetto su github se qualcuno è interessato.
Fonte: habr.com