Assegnazione massiccia dei diritti agli utenti dei domini da foreste diverse

Sembra che la mia karma sia questa: realizzare compiti standard in modi non convenzionali. Se qualcuno ha una visione diversa del problema, è invitato a discuterne per elaborare la questione.

Una mattina splendida è emerso un compito interessante: assegnare diritti ai gruppi di utenti su diverse condivisioni, contenenti sottocartelle di progetti con cartelle di documenti. Tutto andava bene e era stato scritto uno script per assegnare diritti alle cartelle. Poi è emerso che i gruppi dovevano contenere utenti di diversi domini, provenienti da diverse foreste (per chi ha dimenticato cosa sia). Supponiamo che la condivisione stessa sia posizionata su un dispositivo Synology, registrato nel dominio FB, nella foresta PSI. Obiettivo: consentire agli utenti dei domini di un'altra foresta di avere accesso al contenuto di questa condivisione, in modo molto selettivo.

Il documento di specifiche si stava delineando nel seguente modo:

• 2 foreste: Foresta PSI, foresta TG.

  

• In ogni foresta ci sono 3 domini: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Tra le foreste esistono relazioni di fiducia, Synology vede tutti i gruppi di sicurezza in tutte le foreste.
• Sulle condivisioni e cartelle/sottocartelle devono essere necessariamente presenti account admin del dominio FB con diritti di FullControl.
• I nomi delle cartelle delle condivisioni devono essere sistematizzati. L'approvazione degli ID dei progetti è stata gestita dalla direzione, ho deciso di collegare i nomi dei gruppi di sicurezza agli ID dei progetti.
• Le cartelle dei progetti nelle condivisioni di sistema devono contenere una struttura già predisposta in un file .xlsx, con le relative privilegi di accesso (R/RW/NA, dove NA indica che l'accesso è assente)

  

• Deve essere possibile limitare i diritti degli utenti/membri del gruppo di un progetto solo a determinate directory di quel progetto. Per altre directory/progetti, l'utente può non avere accesso, in base all'appartenenza ai gruppi.
• Quando viene creata una cartella di progetto, le gruppi corrispondenti devono essere creati in modo massimo automatico nei domini appropriati con nomi relativi agli ID dei progetti.

Note al documento di specifiche

• La configurazione delle relazioni di fiducia non rientra nell'ambito del documento di specifiche
• L'ID del progetto contiene numeri e lettere latine
• I ruoli degli utenti dei progetti per tutti i domini hanno nomi standard
• Il file .xlsx con le cartelle e i diritti di accesso (matrice di accesso) deve essere preparato prima dell'inizio di tutto il progetto
• Nella realizzazione dei progetti è possibile creare gruppi di utenti nei domini appropriati.
• L'automazione si ottiene utilizzando gli strumenti di amministrazione standard di MS Windows

Implementazione del capitolato

Dopo la formalizzazione di questi requisiti, è stata presa una pausa tattica per testare i metodi di creazione delle directory e l'assegnazione dei diritti. Si prevedeva di utilizzare solo PowerShell, per non complicare il progetto. Come avevo già scritto in precedenza, l'algoritmo dello script sembrava piuttosto semplice:

• registriamo i gruppi con un nome derivante dall'ID del progetto (ad esempio KC40587) e con i rispettivi ruoli indicati nella matrice di accesso: KC40587-EN- per l'ingegnere; KC40587-PM – per il product manager, ecc.
• otteniamo i SID dei gruppi creati
• registriamo la cartella del progetto e il relativo insieme di directory (l'elenco delle sottocartelle dipende dalla condivisione in cui viene creata ed è definito nella matrice di accesso)
• assegniamo i diritti sui nuovi sottodirectory del progetto ai gruppi secondo la matrice di accesso.

Le difficoltà che abbiamo dovuto affrontare nella prima fase:

• incomprensione del modo di impostare la matrice di accesso nello script (ora è implementato un array multidimensionale, ma si sta cercando un modo per compilarlo in base al contenuto del file .xlsx/matrice di accesso)

  

• impossibilità di stabilire i diritti di accesso nelle condivisioni SMB sui dispositivi storage Synology utilizzando PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas-share?forum=winserverpowershell), il che ha comportato una significativa perdita di tempo e ha reso necessario adattare tutto per gli script utilizzando l'utility di modifica dei diritti icacls, richiedendo così la creazione di un deposito intermedio di file di testo e cmd.

Nella modalità attuale, l'esecuzione dei file cmd è controllata manualmente, sulla base della necessità di registrare la cartella per il progetto.

Si è anche scoperto che lo script deve essere eseguito anche per la registrazione dei gruppi in altri foreste (abbiamo usato il termine Cross-domains), e il rapporto può non essere solo 1 a 1, ma anche 1 a molti.

Ciò significa che l'accesso alle risorse di un dominio può ora essere rivendicato anche da gruppi di altri cross-dominio, inclusa la foresta vicina. Per garantire l'uniformità, è stata presa la decisione di creare una struttura simmetrica in OU di tutti i domini serviti di tutte le foreste (ovali neri verticali). Come si suol dire, in un esercito tutto deve essere disordinato, ma uniforme:

Pertanto, durante la registrazione del progetto 80XXX nel dominio TG, lo script esegue:

1. la creazione dell'OU corrispondente (ovali orizzontali rossi) in questo dominio e nei domini cross, ovvero quelli ai quali i dipendenti devono avere accesso a questa risorsa.

2. il riempimento dell'OU con gruppi di nomi del tipo -, dove:

• SRC_domain – dominio cross, i cui dipendenti avranno accesso alle risorse del dominio DST
• DST_domain – dominio al quale, in effetti, deve essere fornito l'accesso, cioè il motivo per cui è stato tutto pensato
• — numero del progetto
• ROLES – nomi dei ruoli elencati nella matrice degli accessi.

3. lettura dell'array SID di tutti i gruppi di tutti i domini coinvolti e salvataggio per la successiva trasmissione dei dati in un file che definisce i diritti su una sottocartella specifica del progetto

4. generazione di file sorgente (parametro /restore) con un insieme di diritti da utilizzare con l'utilità icacKC in modalità file eseguibile "icacKC \"as-nasNNKCProjects\" /restore C:TempKCKC40XXKC40XX.txt"

5. creazione di un file CMD, che unisce tutti gli icacls eseguibili per tutte le cartelle del progetto

Come già scritto, l'esecuzione del file eseguibile avviene manualmente e anche la valutazione dei risultati dell'esecuzione viene eseguita manualmente.

Difficoltà con cui si è stati costretti a confrontarsi alla fine:

• se la cartella del progetto è già piena di un gran numero di file, l'esecuzione del comando icacls sui volumi esistenti può richiedere molto tempo e, in alcuni casi, ha portato a un rifiuto (ad esempio, in presenza di percorsi di file lunghi);
• oltre al parametro /restore, è stato necessario aggiungere righe con il parametro /reset nel caso in cui le cartelle non fossero state create, ma trasferite da cartelle già esistenti, disabilitando i diritti di ereditarietà dalla radice;
• eseguire parte dello script per la creazione di gruppi ha dovuto essere fatto su un dc casuale di ogni foresta, il problema riguarda gli account amministrativi per ogni albero.

Conclusioni generali: è molto strano che attualmente non ci siano strumenti sul mercato con funzionalità simili. Si può considerare possibile implementare funzionalità simili basate sul portale Sharepoint.
Risulta inoltre incomprensibile il fatto che non si possa utilizzare l'utilità PoSH per impostare i diritti su una cartella sui dispositivi Sinology.

Su richiesta, sono disponibile a condividere lo script, creando un progetto su github, se a qualcuno interessa.

Fonte: habr.com