Configurazione della delega per server ADFS/SAML, file e DFS in Active Directory

 

Panoramica

In questo articolo vengono descritti i passaggi di configurazione della delega affinché ADFS/SAML funzioni correttamente con qualsiasi server file e DFS back-end in Active Directory. Quando le condivisioni di file si trovano su un server diverso dal server MyWorkDrive (MWD), verranno raggiunte tramite DFS o gli utenti verranno autenticati utilizzando ADFS/SAML, per passare correttamente i token utente alle condivisioni di file di back-end è necessario che il server MyWorkDrive è considerato attendibile da qualsiasi file server e server DFS per la delega.

Tipi di delega

Esistono due tipi di delega che puoi scegliere di utilizzare con MyWorkDrive.

• Delega vincolata/Delega vincolata Kerberos o KCD
• Delega vincolata Kerberos basata sulle risorse (RBKCD)

La delega vincolata o la delega vincolata Kerberos (KCD) può essere impostata tramite l'interfaccia utente di ADUC o tramite Powershell. È il tipo più comune, utilizzato nei casi in cui si dispone di un singolo dominio senza trust esterni.
Con la delega vincolata, limiti l'accesso a un servizio specifico (nel caso di MyWorkDrive, CIFS)
Con la delega vincolata Kerberos (KCD), limiti il tipo di autenticazione a Kerberos e il servizio a CIFS.

La delega vincolata Kerberos basata sulle risorse può essere impostata solo tramite Powershell. Con RBKCD specifichi inoltre quali server (risorse) consentiranno le richieste di accesso.
Viene utilizzato più comunemente quando è in uso un trust esterno (ovvero ci sono risorse su due domini diversi a cui si accede, ad esempio un server MyWorkDrive e utenti su Dominio1, con condivisioni di file su Dominio2). Con un Trust, alle risorse deve essere specificatamente indicato da dove accettare le richieste di autorizzazione; non accettano richieste di autorizzazione interdominio se non specificatamente autorizzate. Ulteriori informazioni sulla configurazione dell'attendibilità in Questo articolo.

Puoi trovare ulteriori informazioni sui diversi tipi di delega in questi articoli
Panoramica della delega vincolata Kerberos
Effettuare il secondo salto in PowerShell Remoting, che offre una buona panoramica dei casi d'uso per KCD e RBKCD
Delegazione Kerberos, Una buona discussione sull'implementazione di KCD/RBKCD

Questi articoli menzionano altre forme di autenticazione, come credSSP e JEA, che non vengono utilizzate con MyWorkDrive, e la delega non vincolata, che sconsigliamo a causa delle implicazioni sulla sicurezza.

Abilita tramite MyWorkDrive

A partire dal server MyWorkDrive 6.3, gli script integrati controlleranno per verificare se la delega vincolata è abilitata e offriranno di impostare la delega direttamente da MyWorkDrive.

Questo controllo e l'offerta di correzione sono disponibili sia nella scheda Condivisioni che nel nuovo Cruscotto della salute (anche una nuova funzionalità della 6.3)
Questa funzionalità funziona con la delega vincolata, impostata più frequentemente tramite l'impostazione della delega GUI basata su ADUC. Non rileva KCD/RBKCD e in questi casi gli avvisi possono essere tranquillamente ignorati.

Nell'elenco delle condivisioni, potresti notare un'icona di avviso che indica che la delega è obbligatoria, ma che non è impostata correttamente per una o più condivisioni specifiche.

 

Facendo clic per modificare la condivisione verrà visualizzato sia un avviso di delega SIA un pulsante che richiede di aggiungere una delega.

Facendo clic sul pulsante "Aggiungi delega" verrà visualizzato un messaggio sui requisiti dell'account: è necessario aver effettuato l'accesso a MyWorkDrive come amministratore di dominio per utilizzare la funzione di delega automatizzata. Se l'account con cui amministri MyWorkDrive non è un amministratore di dominio, puoi continuare ad abilitare la delega con uno dei passaggi descritti di seguito.

 

Gli script integrati che verificano se la delega è abilitata e offrono la possibilità di impostare la delega direttamente in MyWorkDrive vengono visualizzati anche nel nuovo Cruscotto della salute con la stessa offerta per impostare la funzionalità di delega.

Tieni presente che il metodo automatizzato potrebbe non funzionare per tutti gli ambienti, in particolare quelli che richiedono una forma specifica di delega come KCD. Se il metodo automatizzato non funziona per te, esamina le opzioni aggiuntive di seguito per individuare il metodo più appropriato per il tuo ambiente.

Delega vincolata

Impostazione della delega vincolata tramite utenti e computer di Active Directory dell'interfaccia utente ADUC

Il metodo più comune per configurare la delega è tramite le proprietà del server MyWorkDrive in Utenti e computer di Active Directory. Configura la delega di Active Directory sull'oggetto computer MyWorkDrive Server per aggiungere eventuali file server e server DFS nella tua organizzazione.

– Da un controller di dominio – Gestione server – Strumenti – Utenti e computer di Active Directory – Computer – {selezionare il computer su cui è installato MWD} – Proprietà – Delega – Considera attendibile questo computer per la delega solo ai servizi specificati – Utilizza qualsiasi protocollo di autenticazione – Aggiungi – Utenti o Computer – {selezionare il/i computer che contengono le condivisioni di rete richieste e i computer con il ruolo DFS installato} – OK – Servizi disponibili – selezionare cifs – OK

Noi fortemente ti consiglio NON SELEZIONARE l'opzione che dice "Considera attendibile questo computer per la delega a qualsiasi server (solo Kerberos)." (delegazione non vincolata) Noi fortemente consigliare di adottare un approccio con accesso con privilegi minimi specificando i server e i servizi come descritto sopra (delega vincolata). Puoi leggere ulteriori informazioni sulla protezione di Active Directory e sui rischi di delega su Petri.com E ADSecurity.org

Esempio di configurazione per consentire a MWD di considerare attendibile la delega tramite File-Server1 e DFS-Server1: – MWD installato sul computer MYWORKDRIVE-SERVER1 – Server di condivisione file di rete: FILE-SERVER1 – Server DFS: DFS-SERVER1

Con PowerShell

È anche possibile assegnare una delega vincolata a CIFS tramite Powershell, tuttavia si consiglia di utilizzare il metodo GUI tramite ADUC.

Questo esempio di script creerà un array di tutti i FileServer e abiliterà la delega a quei file server specifici sul protocollo CIFS sui server MyWorkDrive

—

# Importa il modulo ActiveDirectory
Modulo di importazione ActiveDirectory

# Crea un array e assegnalo ad una variabile. Nel componente @, aggiungi i nomi dei tuoi file server o
Server host #DFS.
$TargetComputers = @("FileShare1", "DFSshare1")

# Passa attraverso ogni elemento dell'array e configura la delega
Per ciascuno (Computer $ in Computer $Target) {

# Connettiti al server MyWorkDrive: sostituisci la frase "MWDServer" con il nome netbios del tuo
Server #MYWorkDrive. Se ne hai più di 1, eseguirai l'intero script più di una volta.
Get-ADComputer -Identity MWDServer

# Aggiungere l'SPN CIFS del computer corrente all'elenco dei servizi a cui FileServer può delegare
Set-ADComputer -Identity MWDServer -Add @{'msDS-AllowedToDelegateTo'= “cifs/$Computer”}
}

—

Test

Per verificare quale delega esiste utilizzando Powershell, questo comando ti fornirà un elenco dei file server che si fidano del tuo server MyWorkDrive per la delega. Nello script seguente, sostituisci "MWDServer" con il nome netbios del tuo server MyWorkDrive.

—

Get-ADComputer MWDSERVER -Properties msDS-AllowedToDelegateTo,Nome visualizzato | selezionare Nome visualizzato -ExpandProperty msDS-AllowedToDelegateTo | elenco-formati

—

*Nota: sono necessari almeno 15 minuti affinché i ticket Kerberos vengano riciclati e potenzialmente più tempo affinché Active Directory propaghi le modifiche. Attendi almeno 15 minuti prima di iniziare a testare l'accesso.

Potresti essere in grado di utilizzare gli argomenti "purge" e "–li 0x3e7" con il file klist comando sui file server e sui server MyWorkDrive per accelerare la parte di riciclo, ma non lo abbiamo trovato particolarmente efficace.

Delega vincolata Kerberos basata sulle risorse

Alcuni ambienti potrebbero richiedere il metodo di configurazione alternativo, Resource Based Kerberos Constrained Delegation (RBKCD).

Per i clienti con più domini (trust di dominio) o coloro che ospitano la propria Active Directory in Azure AD Domain Services (non è la stessa cosa di Azure AD), la delega deve essere abilitata utilizzando la delega vincolata basata sulle risorse in PowerShell. RBKCD è necessario per i domini attendibili poiché è l'unico metodo di delega sicura che supporta l'autenticazione double hop. Maggiori dettagli sono disponibili in questo Articolo Microsoft. Alcuni clienti che operano in ambienti ad alta sicurezza o che utilizzano dispositivi di file service potrebbero richiedere anche una delega vincolata basata sulle risorse.

I passaggi di configurazione di Powershell per i domini Server 2012 o versioni successive si trovano nell'articolo di Microsoft su come abilitare la delega vincolata Kerberos (KCD) su un dominio gestito E Come configurare la delega del computer con PowerShell.

Un esempio di comando MyWorkDrive Server per un file server e un server MyWorkDrive è il seguente:

 

Dominio singolo:

Set-ADComputer MyWorkDriveServer -PrincipalsAllowedToDelegateToAccount (Get-ADComputer FileServer)

 

Domini multipli in cui il server, gli utenti o le risorse MyWorkDrive si trovano in domini diversi:

Dal server Windows che ospita le condivisioni file effettive, che si fideranno del server MyWorkDrive, esegui uno dei seguenti comandi PowerShell: dove $MyWorkDriveServer è il nome del server MyWorkDrive e $FileServer è il nome del file server che inserisce il tuo dominio dove il Il server MyWorkDrive si trova nella tua query nella base di ricerca o utilizzando il controller di dominio specificato di cui il server MyWorkDrive è membro:

 

Controller di dominio multipli/attendibili e server MyWorkDrive multipli:

È importante notare che l'esecuzione del comando Set-ADComputer in PowerShell lo farà cancellare eventuali voci di delega esistenti e sostituire con le tue nuove voci. Se hai già configurato la delega per i servizi esistenti, ciò può avere conseguenze indesiderate. Utilizzando il metodo consigliato, cercherai innanzitutto le impostazioni di delega esistenti e includerai tali server nella voce di delega, preservando le impostazioni di delega esistenti e aggiungendone di nuove per il tuo server MyWorkDrive.

Puoi scaricare un file zip di questo script PS1 Qui.

Ecco il contenuto dello script:

—

#NOTA IMPORTANTE: questo script sovrascriverà tutte le impostazioni di delega basate sulle risorse esistenti sui computer di destinazione.
#Leseguire il comando seguente per visualizzare eventuali impostazioni di delega esistenti e aggiungerle all'elenco $MWDServer:
Get-ADComputer -Identity $Computer -server $domain -Properties PrincipalsAllowedToDelegateToAccount

#L'elenco può utilizzare SID se proviene da un dominio attendibile. Se ti viene fornito un SID, utilizza il comando seguente per tradurre il SID da
#il dominio attendibile:
Get-ADComputer –Filter * | Where-Object {$_.SID –like “*1111”} | Seleziona oggetto: nome proprietà, SID
#re sostituisci “1111” con le ultime 4 cifre del SID

# Importa il modulo ActiveDirectory
Modulo di importazione ActiveDirectory

# Crea un array e assegnalo ad una variabile
#TargetComputers serve per l'elenco di file server e condivisioni DFS nell'ambiente.
1TP5 Sostituisci "FileShare1", "DFSSHare1" con i nomi netbios delle condivisioni file e degli host DFS.
#Aggiungi quanti ne servono.
#Domain è il tuo nome di dominio in formato URL, ovvero domain.local
$TargetComputers = @(“FileShare1”, “DFSShare1”)
$Domain = “dominio.tld”

$Delega corrente
$MWDServer1 = (Get-ADComputer -Identity MWDServer1)
$MWDServer2 = (Get-ADComputer -Identity MWDServer2)

# Passa attraverso ciascun file/server DFS per configurare la delega per il server MyWorkDrive
Per ciascuno (Computer $ in Computer $Target) {

# Aggiunge la risorsa del computer corrente all'elenco dei servizi a cui FileServer può delegare
# i “-server domain.tld” possono essere rimossi se tutti i server/computer sono contenuti nello stesso dominio; altrimenti specificare il dominio.
Set-ADComputer -Identity $Computer -server $domain -PrincipalsAllowedToDelegateToAccount $MWDServer1, $MWDServer2

# Verificare che il valore dell'attributo includa il server MyWorkDrive. Se proviene da un dominio attendibile, verrà visualizzato come SID.
Get-ADComputer -Identity $Computer -server $domain -Properties PrincipalsAllowedToDelegateToAccount
} Base di ricerca:
$MyWorkDriveServer= Get-ADComputer -Filter {Nome -eq “MYWORKDRIVE-SERVER”} -SearchBase “DC=MWF,DC=local” -Server “mwf.local”
$FileServer= Get-ADComputer -Filter {Nome -eq “FILE-SERVER”} -SearchBase “DC=MWF,DC=local” -Server “mwf.local”
Set-ADComputer $FileServer -PrincipalsAllowedToDelegateToAccount $MyWorkDriveServer

—

Test

Per verificare che le modifiche abbiano avuto esito positivo, esegui il comando per visualizzare le impostazioni di delega dal passaggio 1 di questo processo.
#Get-ADComputer -Identity $Computer -server $domain -Properties PrincipalsAllowedToDelegateToAccount

Ora dovresti vedere le voci preesistenti insieme alle nuove risorse che hai aggiunto.

*Come indicato in precedenza in questo articolo, sono necessari almeno 15 minuti affinché i ticket Kerberos vengano riciclati e potenzialmente più tempo affinché Active Directory propaghi le modifiche: attendere almeno 15 minuti prima di iniziare a testare l'accesso.

Potresti essere in grado di utilizzare gli argomenti "purge" e "–li 0x3e7" con il file klist comando sui file server e sui server MyWorkDrive per accelerare la parte di riciclo, ma non lo abbiamo trovato particolarmente efficace.

 

Account utente di archiviazione dei servizi di dominio Azure AD

Per abilitare la delega con Servizi di dominio Azure AD e un account utente di archiviazione, è necessario utilizzare il comando PowerShell riportato di seguito per impostare l'account utente di archiviazione in modo che consideri attendibile il computer server MyWorkDrive autorizzato a delegare utilizzando KCD. È inoltre necessario spostare l'account del computer del server MyWorkDrive e gli account utente per le condivisioni file di Azure dalle unità organizzative predefinite a un'unità organizzativa personalizzata. I dettagli sono disponibili in questo articolo di Microsoft. La delega non funzionerà se gli account in Active Directory non vengono spostati fuori dalle unità organizzative predefinite.

UO
Gli account per il computer server MyWorkDrive e gli utenti di Condivisioni file di Azure devono trovarsi in un'unità organizzativa personalizzata in cui si dispone delle autorizzazioni per configurare KCD basato su risorse. Non è possibile configurare KCD basato su risorse per un account computer nel contenitore AAD DC Computers predefinito.

Comandi di Powersell
$ImpersonatingAccount = Get-ADComputer -Identity
Set-ADUutente -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

Tieni presente che per StorageUserAccount potrebbe essere richiesto di utilizzare il nome dell'account SAM, non il nome/nome comune. Trova il nome dell'account SAM come nome precedente a Windows 2000 nella scheda dell'account degli elementi in ADUC o con Get-ADUser in Powershell

Esempio PowerShell

MWD01 – nome del server MyWorkDrive
SA_81e0bcb563 – SAMAccountName della condivisione file di Azure

$ImpersonatingAccount = Get-ADComputer -Identity MWD01
Set-ADUser SA_81e0bcb563 -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount

 

Test

Per verificare la delega, eseguire il seguente comando PowerShell:

Get-ADComputer $MyWorkDriveServer -Properties * | Format-List -Property *delegat*,msDS-AllowedToActOnBehalfOfOtherIdentity

O

A partire da MyWorkDrive Server 5.4 o versioni successive, puoi scegliere di eseguire i test nel pannello di amministrazione di MyWorkDrive Server su ciascuna condivisione utilizzando il nostro sistema integrato Condividi lo strumento di test, invece di accedere a un client come utente.

Casi speciali: DFS e AzureFiles

DFS

Quando utilizzi DFS con SSO e MyWorkDrive, devi configurare la delega per il server MyWorkDrive sia per i computer/host DFS che per i server di condivisione file.

IE, se disponi dei seguenti server

DFS1 DFS2

Configurato per condividere file dai seguenti file server (dispositivi di archiviazione aggiunti a Windows o AD) FileShareSanJose FileShareHouston FileShareNewYork

Quindi tutti e cinque i membri AD dovrebbero apparire come approvati per delegare tramite CIFS nella scheda Delega AD del server MyWorkDrive

File di Azure

Dopo aver completato con successo il nostro guida alla configurazione per l'uso di File di Azure con MyWorkDrive, l'account di archiviazione File di Azure sarà a membro del dominio. Il membro del dominio deve essere aggiunto alla delega per il server MyWorkDrive affinché SSO possa presentare correttamente l'unità come condivisione agli utenti.

Risoluzione dei problemi

Se le tue condivisioni vengono visualizzate vuote quando gli utenti accedono tramite SSO, è probabile che la delega non sia impostata correttamente. Se ritieni di aver configurato correttamente la delega tramite KCD o Active Directory, puoi utilizzare Powershell per verificare se il server/dispositivo di condivisione file accetta correttamente la delega. Questo ti dirà se l'utente che ha effettuato l'accesso può accedere a file e cartelle sulla condivisione file delegata.

Puoi utilizzare uno script PowerShell molto semplice per verificare se la delega è impostata correttamente, utilizzando una tecnica nota come "Double Hop". Ulteriori informazioni su questo test sono disponibili all'indirizzo https://4sysops.com/archives/solve-the-powershell-multi-hop-problem-without-using-credssp/ Per condurre questo test, avrai bisogno di 3 macchine nella tua directory attiva

• Client: può essere qualsiasi macchina aggiunta al dominio; come una workstation Windows 10. Eseguirai il comando Powershell dalla macchina.
• MyWorkDrive Server – il server che dovrebbe essere in grado di accedere alla condivisione tramite delega
• File Server: il server impostato per la delega sul server MyWorkDrive.

Avrai anche bisogno di conoscere il percorso di condivisione di una condivisione sul file server che contiene file, a cui può accedere l'utente che ha effettuato l'accesso. Il comando PowerShell è Invoke-Command -ComputerName $MyWorkDriveServerName -ScriptBlock {Get-ChildItem -Path \\$FileServer\ShareName } Sostituirai $MyWorkDriveServerName con il nome di rete del tuo server MyWorkDrive. Sostituirai $FileServer\ShareName con il file server e la condivisione che desideri testare. La condivisione dovrebbe contenere file ai quali si prevede che l'utente abbia accesso. Ed esegui il comando dalla workstation client Esempio Nel nostro esempio, stiamo testando la delega a una condivisione Samba Linux da due diversi server MyWorkDrive. Un server MyWorkDrive ha la delega impostata, l'altro no. Stiamo testando da un client Windows 10 sul dominio. Delega non configurata In questo test, testeremo la delega su un server in cui non abbiamo configurato intenzionalmente la delega e ci aspettiamo un errore.

• Server MyWorkDrive: mwf-scott6
• File server: Ubuntu-Samba
• Condividi: tutti

Esegui Powershell sul membro del dominio Windows 10 ed esegui il comando seguente Invoke-Command -ComputerName mwf-scott6 -ScriptBlock {Get-ChildItem -Path \\ubuntu-samba\everyone } I risultati che otteniamo sono: Un errore che indica che il percorso del file non esiste. La delega non ha funzionato e il nostro utente non è stato in grado di accedere alla condivisione. In questo scenario, la condivisione verrà visualizzata vuota quando l'utente accede a MyWorkDrive tramite SSO. Questo è il risultato previsto poiché non abbiamo impostato la delega. Potrebbe anche indicare che il file server/appliance non accetta la delega, se configurato correttamente. Configurazione della delegazione In questo test, testeremo la delega su un server in cui la delega è configurata correttamente

• Server MyWorkDrive: mwf-scott5
• File server: Ubuntu-Samba
• Condividi: tutti

Esegui Powershell sul membro del dominio Windows 10 ed esegui il comando seguente Invoke-Command -ComputerName mwf-scott5 -ScriptBlock {Get-ChildItem -Path \\ubuntu-samba\everyone } I risultati che otteniamo sono: Un elenco di file e cartelle nella directory. La delega ha funzionato e il nostro utente è stato in grado di accedere alla condivisione.

Aggiornamento di Windows di novembre 2021

Le patch rilasciate da Microsoft durante il Patch Tuesday di novembre 2021 del 9 novembre causano condivisioni vuote all'accesso con SSO in modo simile a non abilitare correttamente la delega. Il problema è stato risolto con le patch di fine novembre e infine risolto nei roll up di dicembre e gennaio.

A partire dalla metà del 2022 non dovrebbero presentarsi ulteriori casi simili, poiché tali aggiornamenti non sono più rilevanti.

Includiamo queste informazioni per scopi di archiviazione

Se gli accessi appaiono improvvisamente vuoti su un'installazione MyWorkDrive esistente che in precedenza funzionava correttamente, è necessario rimuovere la patch difettosa, vedere questo articolo per i dettagli.

Se stai configurando SSO per la prima volta sul tuo server MyWorkDrive, consultare l'articolo per i dettagli sull'applicazione della correzione ai controller di dominio, oltre a configurare la delega come descritto di seguito.
La correzione della patch fornita tramite Windows Update deve essere applicata manualmente. Senza aggiungere la correzione per la patch di Windows Update, gli accessi risulteranno in condivisioni vuote.