Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a: ✔️ Condivisioni file di Azure SMB
Molte organizzazioni vogliono usare l'autenticazione basata su identità per condivisioni file di Azure SMB in ambienti con più foreste Active Directory Domain Services locali. Si tratta di uno scenario IT comune, soprattutto in seguito a fusioni e acquisizioni, in cui le foreste Active Directory dell'azienda acquisita sono isolate da quelle della società padre. Questo articolo illustra il funzionamento delle relazioni di trust tra foreste e fornisce istruzioni dettagliate per la configurazione e la convalida di più foreste.
Importante
Se si desidera impostare autorizzazioni a livello di condivisione per utenti o gruppi di Microsoft Entra specifici usando il controllo degli accessi in base al ruolo di Azure, è prima necessario sincronizzare gli account AD locali con Microsoft Entra ID usando Microsoft Entra Connect. In caso contrario, è possibile usare un'autorizzazione a livello di condivisione predefinita.
Prerequisiti
- Due controller di dominio di Active Directory Domain Services con foreste diverse e in reti virtuali diverse
- Autorizzazioni di Active Directory sufficienti per eseguire attività amministrative(ad esempio, amministratore di dominio)
- Se si usa il controllo degli accessi in base al ruolo di Azure, entrambe le foreste devono essere raggiungibili da un singolo server Microsoft Entra Connect Sync
Funzionamento delle relazioni di trust tra foreste
L'autenticazione di Active Directory Domain Services locale di File di Azure è supportata solo nella foresta di Active Directory del servizio di dominio in cui è registrato l'account di archiviazione. Per impostazione predefinita, è possibile accedere solo alle condivisioni file di Azure con le credenziali di Active Directory Domain Services da una singola foresta. Se si desidera accedere alla condivisione file di Azure da una foresta diversa, è necessario configurare un trust tra foreste.
Un trust tra foreste è un trust transitivo tra due foreste Active Directory che consente agli utenti di qualsiasi dominio di una foresta di essere autenticati in qualsiasi dominio dell'altra foresta.
Configurazione di più foreste
Per eseguire una configurazione di più foreste, seguire questa procedura:
- Raccogliere informazioni sul dominio e connessioni di rete virtuale tra domini
- Stabilire e configurare un trust tra foreste
- Configurare l'autenticazione basata su identità e gli account utente ibridi
Raccogliere informazioni sul dominio
Per questo esercizio sono disponibili due controller di dominio Active Directory Domain Services locali con due foreste diverse e in reti virtuali diverse.
| Foresta | Dominio | Rete virtuale |
|---|---|---|
| Foresta 1 | onpremad1.com | DomainServicesVNet WUS |
| Foresta 2 | onpremad2.com | vnet2/workloads |
Stabilire e configurare il trust
Per consentire ai client della Foresta 1 di accedere alle risorse di dominio di File di Azure nella Foresta 2, è necessario stabilire un trust tra le due foreste. Per stabilire il trust, seguire questa procedura.
Note
Solo i trust tra foreste sono supportati per File di Azure. Non sono supportati altri tipi di trust, inclusi i trust esterni.
Se si dispone già di un trust configurato, è possibile verificarne il tipo accedendo a un computer aggiunto al dominio Forest 2, aprendo la console Domini e trust di Active Directory, facendo clic con il pulsante destro del mouse sul dominio locale onpremad2.com e selezionando la scheda Trust. Se il trust esistente non è un trust tra foreste e i requisiti dell'ambiente verrebbero soddisfatti da un trust tra foreste, sarà necessario rimuovere il trust esistente e ricreare un trust tra foreste da usare in sostituzione. A tale scopo, seguire queste istruzioni.
Accedere a un computer aggiunto a un dominio alla Foresta 2 e aprire la console Domini e trust di Active Directory.
Fare clic con il pulsante destro del mouse sul dominio locale onpremad2.com e quindi selezionare la scheda Trust.
Selezionare Nuovi trust per avviare la Creazione guidata nuova attendibilità.
Specificare il nome del dominio con cui si vuole creare un trust (in questo esempio, onpremad1.com) e quindi selezionare Avanti.
In Tipo di attendibilità, selezionare Trust tra foreste e quindi Avanti.
Per Direzione attendibilità, selezionare Bidirezionale, e quindi Avanti.
Per Parti del trust selezionare Solo questo dominio e quindi scegliere Avanti.
Gli utenti nella foresta specificata possono essere autenticati per usare tutte le risorse presenti nella foresta locale (autenticazione a livello di foresta) o solo le risorse selezionate (autenticazione selettiva). Per Livello di autenticazione trust in uscita selezionare Autenticazione a livello di foresta, che è l'opzione preferita quando entrambe le foreste appartengono alla stessa organizzazione. Selezionare Avanti.
Immettere una password per il trust e quindi selezionare Avanti. La stessa password deve essere usata durante la creazione di questa relazione di trust nel dominio specificato.
Verrà visualizzato un messaggio per confermare che la relazione di trust è stata creata correttamente. Per configurare il trust, selezionare Avanti.
Confermare l'attendibilità in uscita e selezionare Avanti.
Immettere il nome utente e la password di un utente che ha ottenuto privilegi di amministratore dall'altro dominio.
Una volta eseguita l'autenticazione, viene stabilito il trust e nella scheda Trust dovrebbe essere elencato il dominio specificato onpremad1.com.
Configurare l'autenticazione basata su identità e gli account utente ibridi
Dopo aver stabilito il trust, seguire questa procedura per creare un account di archiviazione e una condivisione file SMB per ogni dominio, abilitare l'autenticazione di Active Directory Domain Services sugli account di archiviazione e creare account utente ibridi sincronizzati con Microsoft Entra ID.
Accedere al portale di Azure e creare due account di archiviazione, ad esempio onprem1sa e onprem2sa. Per ottenere prestazioni ottimali, è consigliabile distribuire gli account di archiviazione nella stessa area del client da cui si prevede di accedere alle condivisioni.
Note
La creazione di un secondo account di archiviazione non è necessaria. Queste istruzioni hanno lo scopo di mostrare un esempio di come accedere agli account di archiviazione appartenenti a foreste diverse. Se si dispone di un solo account di archiviazione, è possibile ignorare le istruzioni per la configurazione del secondo account di archiviazione.
Creare una condivisione file di Azure SMB e assegnare autorizzazioni a livello di condivisione su ogni account di archiviazione.
Sincronizzare Active Directory locale con Microsoft Entra ID usando l'applicazione Microsoft Entra Connect Sync.
Aggiungere una macchina virtuale di Azure nella Foresta 1 ad Active Directory Domain Services locale. Per informazioni su come aggiungere un dominio, vedere Aggiungere un computer a un dominio.
Abilitare l'autenticazione di Active Directory Domain Services nell'account di archiviazione associato alla Foresta 1, ad esempio onprem1sa. Verrà creato un account computer in AD locale denominato onprem1sa per rappresentare l'account di archiviazione di Azure e aggiungere l'account di archiviazione al dominio onpremad1.com. È possibile verificare che l'identità di Active Directory che rappresenta l'account di archiviazione sia stata creata cercando onpremad1.com in Utenti e computer di Active Directory. In questo esempio viene visualizzato un account computer denominato onprem1sa.
Creare un account utente passando a Active Directory > onpremad1.com. Fare clic con il pulsante destro del mouse su Utenti, selezionare Crea, immettere un nome utente (ad esempio, onprem1user) e selezionare la casella Nessuna scadenza password (facoltativo).
Facoltativo: se si vuole usare il controllo degli accessi in base al ruolo di Azure per assegnare autorizzazioni a livello di condivisione, è necessario sincronizzare l'utente con Microsoft Entra ID tramite Microsoft Entra Connect. In genere, Microsoft Entra Connect Sync viene aggiornato ogni 30 minuti. È possibile tuttavia forzare la sincronizzazione immediatamente aprendo una sessione di PowerShell con privilegi elevati ed eseguendo
Start-ADSyncSyncCycle -PolicyType Delta. Potrebbe essere necessario installare prima il modulo ADSync eseguendoImport-Module ADSync. Per verificare che l'utente sia stato sincronizzato con Microsoft Entra ID, accedere al portale di Azure con la sottoscrizione di Azure associata al tenant multi-foresta e selezionare Microsoft Entra ID. Selezionare Gestisci > Utenti e cercare l'utente aggiunto (ad esempio, onprem1user). Sincronizzazione locale abilitata deve essere impostata su Sì.Impostare le autorizzazioni a livello di condivisione usando i ruoli controllo degli accessi in base al ruolo di Azure o un'autorizzazione a livello di condivisione predefinita.
- Se l'utente viene sincronizzato con Microsoft Entra ID, è possibile concedere un'autorizzazione a livello di condivisione (ruolo Controllo degli accessi in base al ruolo di Azure) all'utente onprem1user nell'account di archiviazione onprem1sa in modo che l'utente possa montare la condivisione file. A questo scopo, passare alla condivisione file creata in onprem1sa e seguire le istruzioni in Assegnare autorizzazioni a livello di condivisione per utenti o gruppi specifici di Microsoft Entra.
- In caso contrario, è possibile usare un'autorizzazione a livello di condivisione predefinita,valida per tutte le identità autenticate.
Ripetere i passaggi da 4 a 8 peronpremad2.com nel dominio Forest2 (account di archiviazione onprem2sa/user onprem2user). Se sono presenti più di due foreste, ripetere i passaggi per ogni foresta.
Configurare le autorizzazioni a livello di directory e file (facoltativo)
In un ambiente a più foreste, usare l'utilità della riga di comando icacls per configurare le autorizzazioni a livello di directory e file per gli utenti in entrambe le foreste. Vedere Configurare gli elenchi di controllo di accesso di Windows con icacls.
Se icacls ha esito negativo con un errore di accesso negato , seguire questa procedura per configurare le autorizzazioni a livello di directory e file.
Eliminare il montaggio di condivisione esistente:
net use * /delete /yRi-montare la condivisione usando il modello di autorizzazione Windows per amministratore SMB o la chiave dell'account di archiviazione (non consigliata). Consultare Montare una condivisione file SMB di Azure su Windows.
Impostare le autorizzazioni icacls per l'utente in Forest2 nell'account di archiviazione aggiunto a Forest1 dal client in Forest1.
Note
Non è consigliabile usare Esplora file per configurare gli elenchi di controllo di accesso in un ambiente a più foreste. Se gli utenti che appartengono alla foresta aggiunta al dominio dell'account di archiviazione possono disporre di autorizzazioni a livello di file/directory impostate tramite Esplora file, non è possibile fare altrettanto per gli utenti che non appartengono alla stessa foresta aggiunta al dominio dell'account di archiviazione.
Configurare i suffissi di dominio
Come sopra illustrato, il modo in cui File di Azure esegue la registrazione in Active Directory Domain Services è quasi identico a quello di un normale file server, in cui crea un'identità (per impostazione predefinita un account computer, ma può essere anche un account di accesso al servizio), che rappresenta l'account di archiviazione in Active Directory Domain Services per l'autenticazione. L'unica differenza è che il nome dell'entità servizio registrato per l'account di archiviazione termina con file.core.windows.net che non corrisponde al suffisso del dominio. A causa del suffisso di dominio diverso, è necessario configurare un criterio di routing suffisso per abilitare l'autenticazione a più foreste.
Poiché il suffisso file.core.windows.net è il suffisso di tutte le risorse di File di Azure, anziché il suffisso di un dominio Active Directory specifico, il controller di dominio del client non sa a quale dominio inoltrare la richiesta e quindi rifiuterà tutte le richieste la cui risorsa non si trova nel proprio dominio.
Se, ad esempio, gli utenti di un dominio della Foresta 1 vogliono accedere a una condivisione file con l'account di archiviazione registrato in un dominio della Foresta 2, questa operazione non riuscirà automaticamente perché l'entità servizio dell'account di archiviazione non ha un suffisso corrispondente al suffisso dei domini nella Foresta 1.
È possibile configurare i suffissi di dominio usando uno dei metodi seguenti:
- Modificare il suffisso dell'account di archiviazione e aggiungere un record CNAME (scelta consigliata: funzionerà con due o più foreste)
- Aggiungere il suffisso del nome personalizzato e la regola di routing (non funzionerà con più di due foreste)
Modificare il suffisso del nome dell'account di archiviazione e aggiungere il record CNAME
È possibile risolvere il problema di routing del dominio modificando il suffisso del nome dell'account di archiviazione associato alla condivisione file di Azure e quindi aggiungendo un record CNAME per instradare il nuovo suffisso all'endpoint dell'account di archiviazione. Con questa configurazione, i client aggiunti a un dominio possono accedere agli account di archiviazione aggiunti a qualsiasi foresta. Questa operazione può essere eseguita negli ambienti con due o più foreste.
In questo esempio sono presenti i domini onpremad1.com e onpremad2.com e gli account di archiviazione onprem1sa e onprem2sa associati a condivisioni file di Azure SMB nei rispettivi domini. Questi domini si trovano in foreste diverse unite da una relazione di trust e possono quindi accedere alle risorse delle rispettive foreste. Si vuole offrire ai client appartenenti a ogni foresta la possibilità di accedere a entrambi gli account di archiviazione. A questo scopo, è necessario modificare i suffissi SPN dell'account di archiviazione:
onprem1sa.onpremad1.com -> onprem1sa.file.core.windows.net
onprem2sa.onpremad2.com -> onprem2sa.file.core.windows.net
In questo modo, i client potranno montare la condivisione con net use \\onprem1sa.onpremad1.com perché i client in onpremad1 o onpremad2 sapranno cercare in onpremad1.com la risorsa corretta per l'account di archiviazione.
Per usare questo metodo, completare la procedura seguente:
Assicurarsi di aver stabilito un trust tra le due foreste e di aver configurato l'autenticazione basata su identità e account utente ibridi, come descritto nelle sezioni precedenti.
Modificare il nome SPN dell'account di archiviazione usando lo strumento setspn. È possibile trovare
<DomainDnsRoot>eseguendo il comando di PowerShell per Active Directory seguente:(Get-AdDomain).DnsRootsetspn -s cifs/<storage-account-name>.<DomainDnsRoot> <storage-account-name>Aggiungere una voce CNAME usando Gestore DNS di Active Directory e seguire la procedura seguente per ogni account di archiviazione nel dominio a cui è stato aggiunto l'account di archiviazione. Se si usa un endpoint privato, aggiungere la voce CNAME per eseguire il mapping al nome dell'endpoint privato.
Aprire Gestore DNS di Active Directory.
Passare al dominio (ad esempio, onpremad1.com).
Passare a "Zone di ricerca diretta".
Selezionare il nodo che ha acquisito il nome del dominio (ad esempio, onpremad1.com) e fare clic con il pulsante destro del mouse su Nuovo alias (CNAME).
Per il nome dell'alias, immettere il nome dell'account di archiviazione.
Per il nome di dominio completo, immettere
<storage-account-name>.<domain-name>, ad esempio mystorageaccount.onpremad1.com.Per il nome di dominio completo dell'host di destinazione, immettere
<storage-account-name>.file.core.windows.netSelezionare OK.
Ora, dai client aggiunti a un dominio, dovrebbe essere possibile usare gli account di archiviazione aggiunti a qualsiasi foresta.
Note
Verificare che la parte del nome di dominio completo relativa al nome host corrisponda al nome dell'account di archiviazione, come descritto in precedenza. In caso contrario, verrà visualizzato un errore di accesso negato: "La sintassi di nome file, nome directory o etichetta volume non è corretta". Durante l'installazione della sessione SMB, in una traccia di rete verrà visualizzato il messaggio STATUS_OBJECT_NAME_INVALID (0xc0000033).
Aggiungere il suffisso del nome personalizzato e la regola di routing
Se il suffisso del nome dell'account di archiviazione è già stato modificato e un record CNAME è già stato aggiunto, come descritto nella sezione precedente, è possibile ignorare questo passaggio. Se si preferisce non apportare modifiche al DNS o non modificare il suffisso del nome dell'account di archiviazione, è possibile configurare una regola di gestione del suffisso dalla Foresta 1 alla Foresta 2 per un suffisso personalizzato di file.core.windows.net.
Note
La configurazione del routing del suffisso del nome non influisce sulla possibilità di accedere alle risorse nel dominio locale. È necessario solo consentire al client di inoltrare la richiesta al dominio corrispondente al suffisso se la risorsa non viene trovata nel proprio dominio.
Per prima cosa, aggiungere un nuovo suffisso personalizzato nella Foresta 2. Assicurarsi di disporre delle autorizzazioni amministrative appropriate per modificare la configurazione e che sia stato stabilito un trust tra le due foreste. Seguire quindi questa procedura:
- Accedere a un computer o a una macchina virtuale aggiunta a un dominio nella Foresta 2.
- Aprire la console Domini e trust di Active Directory.
- Fare clic con il pulsante destro del mouse su Domini e trust di Active Directory.
- Selezionare Proprietà e quindi Aggiungi.
- Aggiungere "file.core.windows.net" come suffisso UPN.
- Selezionare Applica, quindi OK per chiudere la procedura guidata.
Aggiungere quindi la regola di gestione del suffisso alla Foresta 1, in modo che venga reindirizzata alla Foresta 2.
- Accedere a un computer o a una macchina virtuale aggiunta a un dominio nella Foresta 1.
- Aprire la console Domini e trust di Active Directory.
- Fare clic con il pulsante destro del mouse sul dominio in cui è presente la condivisione file a cui si desidera accedere, quindi selezionare la scheda Trust e selezionare il dominio Forest 2 dai trust in uscita.
- Selezionare Proprietà e quindi Assegna un nome al routing dei suffissi.
- Controllare se viene visualizzato il suffisso "*.file.core.windows.net". In caso contrario, selezionare Aggiorna.
- Selezionare "*.file.core.windows.net", quindi selezionare Abilita e Applica.
Verificare che il trust funzioni correttamente
Si verificherà ora che il trust funzioni correttamente eseguendo il comando klist per visualizzare il contenuto della cache delle credenziali Kerberos e della tabella delle chiavi.
- Accedere a un computer o a una macchina virtuale aggiunta a un dominio nella Foresta 1 e aprire un prompt dei comandi di Windows.
- Per visualizzare la cache delle credenziali per l'account di archiviazione aggiunto al dominio nella Foresta 2, eseguire uno dei comandi seguenti:
- Se è stato usato il suffisso Modifica nome account di archiviazione e aggiungi il metodo di record CNAME, eseguire:
klist get cifs/onprem2sa.onpremad2.com - Se è stato usato il metodo Aggiungere il suffisso del nome personalizzato e la regola di gestione, eseguire:
klist get cifs/onprem2sa.file.core.windows.net
- Se è stato usato il suffisso Modifica nome account di archiviazione e aggiungi il metodo di record CNAME, eseguire:
- L'output dovrebbe essere simile al seguente. L'output del comando klist sarà leggermente diverso in base al metodo usato per configurare i suffissi di dominio.
Client: onprem1user @ ONPREMAD1.COM
Server: cifs/onprem2sa.file.core.windows.net @ ONPREMAD2.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/22/2022 18:45:02 (local)
End Time: 11/23/2022 4:45:02 (local)
Renew Time: 11/29/2022 18:45:02 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
Kdc Called: onprem2.onpremad2.com
- Accedere a un computer o a una macchina virtuale aggiunta a un dominio nella Foresta 2 e aprire un prompt dei comandi di Windows.
- Per visualizzare la cache delle credenziali per l'account di archiviazione aggiunto al dominio nella Foresta 1, eseguire uno dei comandi seguenti:
- Se è stato usato il suffisso Modifica nome account di archiviazione e aggiungi il metodo di record CNAME, eseguire:
klist get cifs/onprem1sa.onpremad1.com - Se è stato usato il metodo Aggiungere il suffisso del nome personalizzato e la regola di gestione, eseguire:
klist get cifs/onprem1sa.file.core.windows.net
- Se è stato usato il suffisso Modifica nome account di archiviazione e aggiungi il metodo di record CNAME, eseguire:
- L'output dovrebbe essere simile al seguente. L'output del comando klist sarà leggermente diverso in base al metodo usato per configurare i suffissi di dominio.
Client: onprem2user @ ONPREMAD2.COM
Server: krbtgt/ONPREMAD2.COM @ ONPREMAD2.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/22/2022 18:46:35 (local)
End Time: 11/23/2022 4:46:35 (local)
Renew Time: 11/29/2022 18:46:35 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: onprem2
Client: onprem2user @ ONPREMAD2.COM
Server: cifs/onprem1sa.file.core.windows.net @ ONPREMAD1.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/22/2022 18:46:35 (local)
End Time: 11/23/2022 4:46:35 (local)
Renew Time: 11/29/2022 18:46:35 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
Kdc Called: onpremad1.onpremad1.com
Se viene visualizzato l'output sopra indicato, il processo è stato completato. In caso contrario, seguire questa procedura per fornire suffissi UPN alternativi e assicurare il funzionamento dell'autenticazione a più foreste.
Importante
Questo metodo funzionerà solo in ambienti con due foreste. Se sono presenti più di due foreste, usare uno degli altri metodi per configurare i suffissi di dominio.
Per prima cosa, aggiungere un nuovo suffisso personalizzato nella Foresta 1.
- Accedere a un computer o a una macchina virtuale aggiunta a un dominio nella Foresta 1.
- Aprire la console Domini e trust di Active Directory.
- Fare clic con il pulsante destro del mouse su Domini e trust di Active Directory.
- Selezionare Proprietà e quindi Aggiungi.
- Aggiungere un suffisso UPN alternativo, ad esempio "onprem1sa.file.core.windows.net".
- Selezionare Applica, quindi OK per chiudere la procedura guidata.
Aggiungere quindi la regola di routing del suffisso nella Foresta 2.
- Accedere a un computer o a una macchina virtuale aggiunta a un dominio nella Foresta 2.
- Aprire la console Domini e trust di Active Directory.
- Fare clic con il pulsante destro del mouse sul dominio a cui si vuole accedere alla condivisione file, quindi selezionare la scheda Trust e selezionare l'attendibilità in uscita della Foresta 2 in cui è stato aggiunto il nome di routing del suffisso .
- Selezionare Proprietà e quindi Assegna un nome al routing dei suffissi.
- Controllare se viene visualizzato il suffisso "onprem1sa.file.core.windows.net". In caso contrario, selezionare Aggiorna.
- Selezionare "onprem1sa.file.core.windows.net", quindi selezionare Abilita e Applica.
Passaggi successivi
Per ulteriori informazioni, vedere le risorse:
- Panoramica del supporto dell'autenticazione basata su identità in File di Azure (solo SMB)
- Azure Files FAQ (Domande frequenti su File di Azure)