Usare File di Azure con più foreste di Active Directory

Molte organizzazioni vogliono usare l'autenticazione basata su identità per condivisioni file di Azure SMB in ambienti con più foreste di Servizi di dominio di Active Directory locale. Si tratta di uno scenario IT comune, in particolare in seguito a fusioni e acquisizioni, in cui le foreste di Active Directory dell'azienda acquisita sono isolate dalle foreste di Active Directory 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 le autorizzazioni a livello di condivisione per utenti o gruppi specifici di Microsoft Entra 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.

Si applica a

Tipo di condivisione file	SMB	NFS
Condivisioni file Standard (GPv2), archiviazione con ridondanza locale/archiviazione con ridondanza della zona
Condivisioni file Standard (GPv2), archiviazione con ridondanza geografica/archiviazione con ridondanza geografica della zona
Condivisioni file Premium (FileStorage), archiviazione con ridondanza locale/archiviazione con ridondanza della zona

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, Domain Admin)
• Se si usa il controllo degli accessi in base al ruolo di Azure, entrambe le foreste devono essere raggiungibili da un singolo server di sincronizzazione Microsoft Entra Connect

Funzionamento delle relazioni di trust tra foreste

File di Azure'autenticazione di Active Directory Domain Services locale è supportata solo nella foresta di Active Directory del servizio di dominio a 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 è necessario 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 di Active Directory che consente agli utenti in uno dei domini di una foresta di essere autenticati in uno qualsiasi dei domini nell'altra foresta.

Configurazione di più foreste

Per configurare una configurazione a 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/carichi di lavoro

Stabilire e configurare l'attendibilità

Per consentire ai client della foresta 1 di accedere alle risorse di dominio File di Azure nella foresta 2, è necessario stabilire un trust tra le due foreste. Per stabilire l'attendibilità, seguire questa procedura.

Nota

Per File di Azure sono supportati solo i trust tra foreste. Altri tipi di trust, ad esempio trust esterni, non sono supportati.

Se si dispone già di un trust configurato, è possibile controllarne il tipo accedendo a un computer aggiunto alla foresta 2, aprendo la console Dominio di Active Directory e trusts, facendo clic con il pulsante destro del mouse sul onpremad2.com del dominio locale e quindi scegliendo Trusts scheda. Se il trust esistente non è un trust tra foreste e se un trust tra foreste soddisfa i requisiti dell'ambiente, sarà necessario rimuovere l'attendibilità esistente e ricreare un trust tra foreste al suo posto. A tale scopo, segui le istruzioni riportate di seguito.

1. Accedere a un computer aggiunto a un dominio alla foresta 2 e aprire la console Dominio di Active Directory e Trusts.

2. Fare clic con il pulsante destro del mouse sul onpremad2.com di dominio locale e quindi selezionare la scheda Trusts (Trust).

3. Selezionare Nuovi trust per avviare la Creazione guidata nuova attendibilità.

4. Specificare il nome di dominio con cui si vuole creare un trust (in questo esempio onpremad1.com) e quindi selezionare Avanti.

5. In Tipo di attendibilità selezionare Trust tra foreste e quindi Avanti.

6. Per Direzione attendibilità selezionare Bidirezionale e quindi avanti.

   

7. Per Lati di attendibilità selezionare Solo questo dominio e quindi selezionare Avanti.

8. Gli utenti nella foresta specificata possono essere autenticati per usare tutte le risorse nella foresta locale (autenticazione a livello di foresta) o solo quelle selezionate (autenticazione selettiva). Per Livello di autenticazione attendibilità in uscita selezionare Autenticazione a livello di foresta, che è l'opzione preferita quando entrambe le foreste appartengono alla stessa organizzazione. Selezionare Avanti.

9. Immettere una password per l'attendibilità e quindi selezionare Avanti. La stessa password deve essere usata durante la creazione di questa relazione di trust nel dominio specificato.

   

10. Verrà visualizzato un messaggio che indica che la relazione di trust è stata creata correttamente. Per configurare l'attendibilità, selezionare Avanti.

11. Confermare l'attendibilità in uscita e selezionare Avanti.

12. Immettere il nome utente e la password di un utente con privilegi di amministratore dall'altro dominio.

Una volta superata l'autenticazione, viene stabilita l'attendibilità e dovrebbe essere possibile visualizzare il dominio specificato onpremad1.com elencato nella scheda Trust.

Configurare l'autenticazione basata su identità e gli account utente ibridi

Dopo aver stabilito l'attendibilità, 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 negli account di archiviazione e creare account utente ibridi sincronizzati con Microsoft Entra ID.

1. 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 dei client da cui si prevede di accedere alle condivisioni.

   Nota

   La creazione di un secondo account di archiviazione non è necessaria. Queste istruzioni sono progettate per illustrare 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 di configurazione del secondo account di archiviazione.

2. Creare una condivisione file di Azure SMB in ogni account di archiviazione.

3. Sincronizzare l'istanza locale di AD con Microsoft Entra ID usando l'applicazione Microsoft Entra Connect Sync .

4. 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.

5. 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 di onpremad1.com . È possibile verificare che l'identità di ACTIVE Directory che rappresenta l'account di archiviazione sia stata creata cercando Utenti e computer di Active Directory per onpremad1.com. In questo esempio viene visualizzato un account computer denominato onprem1sa.

6. 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 Password never expires (facoltativo).

7. 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 usando Microsoft Entra Connect. In genere, Microsoft Entra Connect Sync viene aggiornato ogni 30 minuti. Tuttavia, è possibile 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 eseguendo Import-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.> La sincronizzazione locale abilitata deve pronunciare Sì.

8. 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 tale 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 che si applica a tutte le identità autenticate.

Ripetere i passaggi da 4 a 8 per onpremad2.com di 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 montando la condivisione con la chiave dell'account di archiviazione.

1. Eliminare il montaggio di condivisione esistente: net use * /delete /y

2. Rimontare la condivisione usando la chiave dell'account di archiviazione:

   net use <driveletter> \\storageaccount.file.core.windows.net\sharename /user:AZURE\<storageaccountname> <storageaccountkey>
   

3. Impostare le autorizzazioni icacls per l'utente in Forest2 nell'account di archiviazione aggiunto a Forest1 dal client in Forest1.

Nota

Non è consigliabile usare Esplora file per configurare gli elenchi di controllo di accesso in un ambiente a più foreste. Anche se gli utenti che appartengono alla foresta aggiunta a un dominio all'account di archiviazione possono avere autorizzazioni a livello di file/directory impostate tramite Esplora file, non funzioneranno per gli utenti che non appartengono alla stessa foresta aggiunta a un dominio all'account di archiviazione.

Configurare i suffissi di dominio

Come illustrato in precedenza, il modo in cui File di Azure registri in Servizi di dominio Active Directory è quasi identico a quello di un file server normale, in cui crea un'identità (per impostazione predefinita un account computer, potrebbe anche essere un account di accesso al servizio) che rappresenta l'account di archiviazione in Servizi di dominio Active Directory per l'autenticazione. L'unica differenza è che il nome dell'entità servizio registrato (SPN) dell'account di archiviazione termina con file.core.windows.net, che non corrisponde al suffisso di 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 per tutte le risorse File di Azure anziché un suffisso per un dominio di Active Directory specifico, il controller di dominio del client non conosce il dominio a cui inoltrare la richiesta e quindi non riuscirà a tutte le richieste in cui la risorsa non viene trovata nel proprio dominio.

Ad esempio, quando gli utenti di un dominio nella foresta 1 vogliono raggiungere una condivisione file con l'account di archiviazione registrato in un dominio nella foresta 2, questo non funzionerà automaticamente perché l'entità servizio dell'account di archiviazione non ha un suffisso corrispondente al suffisso di qualsiasi dominio 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 funziona per gli ambienti con due o più foreste.

In questo esempio sono presenti i domini onpremad1.com e onpremad2.com e sono disponibili onprem1sa e onprem2sa come account di archiviazione associati alle condivisioni file di Azure SMB nei rispettivi domini. Questi domini si trovano in foreste diverse che si considerano attendibili tra loro per accedere alle risorse nelle foreste. Si vuole consentire l'accesso a entrambi gli account di archiviazione dai client che appartengono a ogni foresta. A tale 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 onpremad1.com per trovare la risorsa appropriata per tale account di archiviazione.

Per usare questo metodo, completare la procedura seguente:

1. Assicurarsi di aver stabilito l'attendibilità tra le due foreste e configurare l'autenticazione basata su identità e gli account utente ibridi, come descritto nelle sezioni precedenti.

2. Modificare il nome SPN dell'account di archiviazione usando lo strumento setspn. È possibile trovare <DomainDnsRoot> eseguendo il comando di PowerShell di Active Directory seguente: (Get-AdDomain).DnsRoot

   setspn -s cifs/<storage-account-name>.<DomainDnsRoot> <storage-account-name>
   

3. Aggiungere una voce CNAME usando Gestione DNS di Active Directory e seguire la procedura seguente per ogni account di archiviazione nel dominio a cui è aggiunto l'account di archiviazione. Se si usa un endpoint privato, aggiungere la voce CNAME per eseguire il mapping al nome dell'endpoint privato.

   1. Aprire Gestione DNS di Active Directory.

   2. Passare al dominio, ad esempio onpremad1.com.

   3. Passare a "Zone di ricerca diretta".

   4. Selezionare il nodo denominato in base al dominio (ad esempio, onpremad1.com) e fare clic con il pulsante destro del mouse su Nuovo alias (CNAME).

   5. Per il nome dell'alias immettere il nome dell'account di archiviazione.

   6. Per il nome di dominio completo (FQDN), immettere <storage-account-name>.<domain-name>, ad esempio mystorageaccount.onpremad1.com.

   7. Per il nome di dominio completo dell'host di destinazione immettere <storage-account-name>.file.core.windows.net

   8. Seleziona OK.

      

Ora, dai client aggiunti a un dominio, dovrebbe essere possibile usare gli account di archiviazione aggiunti a qualsiasi foresta.

Nota

Verificare che la parte del nome host del nome di dominio completo corrisponda al nome dell'account di archiviazione come descritto in precedenza. In caso contrario, verrà visualizzato un errore di accesso negato: "Il nome file, il nome della directory o la sintassi dell'etichetta del volume non è corretto". Durante l'installazione della sessione SMB verrà visualizzato un messaggio di 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 aggiunto un record CNAME come descritto nella sezione precedente, è possibile ignorare questo passaggio. Se si preferisce non apportare modifiche DNS o modificare il suffisso del nome dell'account di archiviazione, è possibile configurare una regola di routing suffisso dalla foresta 1 alla foresta 2 per un suffisso personalizzato di file.core.windows.net.

Nota

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 quando la risorsa non viene trovata nel proprio dominio.

Aggiungere prima di tutto un nuovo suffisso personalizzato nella foresta 2. Assicurarsi di disporre delle autorizzazioni amministrative appropriate per modificare la configurazione e che sia stata stabilita una relazione di trust tra le due foreste. Quindi segui questi passaggi.

1. Accedere a un computer o a una macchina virtuale aggiunta a un dominio nella foresta 2.
2. Aprire la console Dominio di Active Directory e Trusts.
3. Fare clic con il pulsante destro del mouse su Dominio di Active Directory e trust.
4. Selezionare Proprietà e quindi Aggiungi.
5. Aggiungere "file.core.windows.net" come suffisso UPN.
6. Selezionare Applica, quindi OK per chiudere la procedura guidata.

Aggiungere quindi la regola di routing del suffisso nella foresta 1, in modo che venga reindirizzato alla foresta 2.

1. Accedere a un computer o a una macchina virtuale aggiunta a un dominio nella foresta 1.
2. Aprire la console Dominio di Active Directory e Trusts.
3. Fare clic con il pulsante destro del mouse sul dominio a cui si vuole accedere alla condivisione file, quindi selezionare la scheda Trusts (Trust) e selezionare Forest 2 domain from outgoing trusts (Foresta 2 dominio da trust in uscita).
4. Selezionare Proprietà e quindi Assegnare un nome al routing dei suffissi.
5. Controllare se viene visualizzato il suffisso "*.file.core.windows.net". In caso contrario, selezionare Aggiorna.
6. Selezionare "*.file.core.windows.net", quindi selezionare Abilita e applica.

Verificare che l'attendibilità funzioni

A questo punto si verifica che l'attendibilità funzioni eseguendo il comando klist per visualizzare il contenuto della cache delle credenziali Kerberos e della tabella delle chiavi.

1. Accedere a un computer o a una macchina virtuale aggiunta a un dominio nella foresta 1 e aprire un prompt dei comandi di Windows.
2. 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 Modify storage account name (Modifica nome account di archiviazione) e si aggiunge il metodo di record CNAME, eseguire: klist get cifs/onprem2sa.onpremad2.com
   • Se è stato usato il metodo Add custom name suffix and routing rule (Aggiungi suffisso nome personalizzato e regola di routing), eseguire: klist get cifs/onprem2sa.file.core.windows.net
3. L'output dovrebbe essere simile al seguente. L'output 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

4. Accedere a un computer o a una macchina virtuale aggiunta a un dominio nella foresta 2 e aprire un prompt dei comandi di Windows.
5. 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 Modify storage account name (Modifica nome account di archiviazione) e si aggiunge il metodo di record CNAME, eseguire: klist get cifs/onprem1sa.onpremad1.com
   • Se è stato usato il metodo Add custom name suffix and routing rule (Aggiungi suffisso nome personalizzato e regola di routing), eseguire: klist get cifs/onprem1sa.file.core.windows.net
6. L'output dovrebbe essere simile al seguente. L'output 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 precedente, l'operazione è stata completata. In caso contrario, seguire questa procedura per fornire suffissi UPN alternativi per 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.

Aggiungere prima di tutto un nuovo suffisso personalizzato nella foresta 1.

1. Accedere a un computer o a una macchina virtuale aggiunta a un dominio nella foresta 1.
2. Aprire la console Dominio di Active Directory e Trusts.
3. Fare clic con il pulsante destro del mouse su Dominio di Active Directory e trust.
4. Selezionare Proprietà e quindi Aggiungi.
5. Aggiungere un suffisso UPN alternativo, ad esempio "onprem1sa.file.core.windows.net".
6. Selezionare Applica, quindi OK per chiudere la procedura guidata.

Aggiungere quindi la regola di routing del suffisso nella foresta 2.

1. Accedere a un computer o a una macchina virtuale aggiunta a un dominio nella foresta 2.
2. Aprire la console Dominio di Active Directory e Trusts.
3. Fare clic con il pulsante destro del mouse sul dominio a cui si vuole accedere alla condivisione file, quindi selezionare la scheda Trusts (Trust) e selezionare l'attendibilità in uscita della foresta 2 in cui è stato aggiunto il nome di routing del suffisso.
4. Selezionare Proprietà e quindi Assegnare un nome al routing dei suffissi.
5. Controllare se viene visualizzato il suffisso "onprem1sa.file.core.windows.net". In caso contrario, selezionare Aggiorna.
6. Selezionare "onprem1sa.file.core.windows.net", quindi selezionare Abilita e applica.

Passaggi successivi

Per ulteriori informazioni, vedi queste risorse:

• Panoramica del supporto dell'autenticazione basata su identità File di Azure (solo SMB)
• Azure Files FAQ (Domande frequenti su File di Azure)