Assegnazione su larga scala dei diritti agli utenti dei domini provenienti da diverse foreste

Credo di avere una certa karma: realizzare compiti standard in modi poco convenzionali. Se qualcuno ha una visione diversa del problema, è invitato a discuterne per approfondire la questione.

Una bella mattina è emersa l'interessante sfida di assegnare i diritti a gruppi di utenti su diverse condivisioni, contenenti sottocartelle di progetti con cartelle di documenti. Tutto sembrava funzionare bene e ho scritto uno script per assegnare diritti alle cartelle. Poi si è scoperto che i gruppi dovevano contenere utenti di domini diversi, provenienti da foreste diverse (per chi avesse dimenticato cosa sia). Supponiamo che la condivisione stessa sia ospitata su un dispositivo Synology, registrato nel dominio FB, nella foresta PSI. Compito: consentire agli utenti domini dell'altra foresta di accedere al contenuto di questa condivisione, in modo molto selettivo.

Il capitolato iniziò a delinearsi 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 ci sono relazioni di fiducia, Synology vede tutti i gruppi di sicurezza in tutte le foreste.
• Sulle condivisioni e cartelle/sottocartelle devono necessariamente essere presenti account di amministratori del dominio FB con diritti FullControl.
• I nomi delle cartelle condivise devono essere sistematizzati. La direzione si è occupata dell'approvazione degli ID dei progetti, e 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 preparata in un file .xlsx, con i corrispondenti privilegi di accesso (R/RW/NA, dove NA indica accesso non disponibile).

  

• Deve essere possibile limitare i diritti degli utenti/membri di un progetto solo a determinati cataloghi di questo progetto. L'utente potrebbe non avere accesso ad altri cataloghi/progetti, a seconda dell'appartenenza ai gruppi.
• Quando si crea una nuova cartella di progetto, devono essere automaticamente create le gruppi corrispondenti nei domini pertinenti con nomi che corrispondono agli ID dei progetti.

Note al capitolato

• La configurazione delle relazioni di fiducia non rientra nel capitolato
• L'ID del progetto contiene numeri e caratteri latini
• I ruoli degli utenti nei progetti per tutti i domini hanno nomi standardizzati
• Il file .xlsx con le cartelle e i diritti di accesso (matrice di accesso) deve essere preparato prima dell'inizio dell'implementazione dell'intero progetto.
• Durante l'implementazione dei progetti è possibile creare gruppi di utenti nei domini pertinenti.
• L'automazione si ottiene tramite l'uso degli strumenti di amministrazione di MS Windows.

Implementazione del documento tecnico.

Dopo la formalizzazione dei requisiti, è stata presa una pausa tattica per testare i metodi di creazione delle directory e di assegnazione dei diritti su di esse. Si intendeva utilizzare solo PowerShell per semplificare il progetto. Come ho già scritto in precedenza, l'algoritmo dello script si presentava abbastanza semplice:

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

Difficoltà incontrate nella prima fase:

• mancanza di comprensione su come specificare la matrice di accesso nello script (attualmente è implementato un array multidimensionale, ma si sta cercando un modo per popolarlo sulla base del contenuto del file .xlsx/matrice di accesso).

  

• l'impossibilità di impostare i diritti di accesso nelle condivisioni SMB sui dispositivi 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, costringendomi a adattare tutto a script che utilizzano l'utility per modificare i diritti di accesso icacls, richiedendo così la creazione di uno storage intermedio di file di testo e cmd.

Nell'attuale modalità, l'esecuzione dei file cmd è controllata manualmente, a seconda della necessità di registrare una cartella per il progetto.

È emerso anche che lo script deve essere eseguito per registrare gruppi in altri forest (abbiamo usato il termine Cross-domains), con la possibilità che la relazione sia non solo 1 a 1, ma anche 1 a molti.

Ciò significa che l'accesso alle risorse di un determinato dominio può ora essere rivendicato da gruppi di altri cross-domain, incluso un altro forest vicino. Per garantire uniformità, è stata presa la decisione di creare una struttura simmetrica nell'OU di tutti i domini gestiti di tutti i forest (ovali neri verticali). Come si suol dire, nell'esercito tutto deve essere inadeguato, ma uniforme:

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

1. creazione della corrispondente OU (ellissi orizzontali rosse) in questo dominio e nei cross-dominio, cioè quelli domini ai quali i dipendenti devono avere accesso a questa risorsa.

2. riempimento dell'OU con gruppi denominati come <SRC_domain><DST_domain><ID_progetto>-, dove:

• SRC_domain – cross-dominio, i cui dipendenti avranno accesso alle risorse del dominio DST
• DST_domain – dominio, alle risorse del quale, in effetti, deve essere fornito accesso, cioè per cui è stato tutto pianificato
• <ID_progetto> — numero del progetto
• ROLES – nomi dei ruoli elencati nella matrice di accesso.

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 per l'utilizzo dell'utilità icacKC in modalità eseguibile "icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"

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

Come accennato in precedenza, l'esecuzione del file eseguibile avviene manualmente e la valutazione dei risultati dell'esecuzione viene effettuata anch'essa manualmente.

Difficoltà riscontrate:

• se la cartella del progetto è già piena di un gran numero di file, l'esecuzione del comando icacls sugli attuali volumi può richiedere molto tempo e in alcuni casi portava 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 venissero create, ma fossero state trasferite da cartelle già esistenti, con i diritti di eredità disattivati dal root;
• parte dello script per la creazione di gruppi ha dovuto essere eseguita su un dc arbitrario di ogni foresta, il problema riguarda gli account amministrativi per ogni albero.

Conclusione generale: è molto strano che attualmente sul mercato non ci siano utility con funzionalità simili. Si potrebbe realizzare una funzionalità di questo tipo basata sul portale SharePoint.
È inoltre incomprensibile il fatto che non sia possibile utilizzare le utility PoSH per assegnare i diritti sulle cartelle sui dispositivi sinology.

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

Fonte: habr.com