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 SMB
Molte organizzazioni vogliono usare l'autenticazione basata su identità per le condivisioni file di Azure SMB in ambienti con più foreste di Active Directory Domain Services (AD DS) 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
Per impostare le autorizzazioni a livello di condivisione per utenti o gruppi specifici di Microsoft Entra ID usando Azure controllo degli accessi in base al ruolo, sincronizzare prima gli account AD locali con Entra ID usando Microsoft Entra Connect Sync. In caso contrario, usare unimpostazione predefinita a livello di condivisione.
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 supporta solo la foresta di Active Directory del servizio di dominio in cui è registrato l'account di archiviazione. Per impostazione predefinita, è possibile accedere solo alle condivisioni di file Azure con le credenziali dei Servizi di dominio Active Directory da una singola foresta. Se è necessario accedere alla condivisione file di Azure da una foresta diversa, 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.
Configura l'autenticazione multi-forest di File di Azure
Per configurare un'installazione 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
Questo esempio utilizza due controller di dominio AD DS on-premises con due foreste diverse e in reti virtuali differenti.
| Foresta | Domain | Rete virtuale |
|---|---|---|
| Foresta 1 | onpremad1.com | DomainServicesVNet WUS |
| Foresta 2 | onpremad2.com | vnet2/workloads |
Stabilire e configurare il trust
Per consentire ai client di Forest 1 di accedere alle risorse di dominio File di Azure in Forest 2, è necessario stabilire un trust tra le due foreste. Per stabilire il trust, seguire questa procedura.
Note
File di Azure supporta solo i trust tra foreste. Non supporta altri tipi di trust, ad esempio trust esterni.
Se si dispone già di un trust configurato, è possibile controllarne il tipo accedendo a un computer appartenente al dominio della Foresta 2, aprendo la console Trust e domini di Active Directory, facendo clic con il pulsante destro del mouse sul dominio locale onpremad2.com e quindi selezionando la scheda Trust. Se il trust esistente non è un trust tra foreste e se un trust tra foreste soddisfa le necessità dell'ambiente, è necessario rimuovere l'attendibilità esistente e ricreare un trust tra foreste. A tale scopo, seguire queste istruzioni.
Accedere a una macchina aggiunta a un dominio nella 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. Seleziona Avanti.
Immettere una password per l'attendibilità e quindi selezionare Avanti. È necessario usare la stessa password 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 con privilegi di amministratore dall'altro dominio.
Al termine dell'autenticazione, viene stabilita l'attendibilità. Dovresti vedere il dominio specificato onpremad1.com elencato nella scheda Attendibilità.
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 Entra ID.
Accedere al portale di Azure e creare due account di archiviazione, ad esempio onprem1sa e onprem2sa. Per ottenere prestazioni ottimali, distribuire gli account di archiviazione nella stessa area dei client da cui si prevede di accedere alle condivisioni.
Note
Non è necessario creare un secondo account di archiviazione. Queste istruzioni illustrano 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 SMB Azure e assegnare autorizzazioni a livello di condivisione in ogni account di archiviazione.
Sincronizza il tuo AD on-premises con Microsoft Entra ID utilizzando 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. Questo passaggio crea un account computer in AD locale denominato onprem1sa per rappresentare l'account di archiviazione Azure e aggiunge 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 Utenti e computer di Active Directory per onpremad1.com. 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 Azure controllo degli accessi in base al ruolo per assegnare autorizzazioni a livello di condivisione, è necessario sincronizzare l'utente con Entra ID usando 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 sincronizzato con Entra ID, accedere al portale di Azure con la sottoscrizione 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 di controllo degli accessi in base al ruolo di Azure o un'autorizzazione predefinita per il livello di condivisione.
- Se l'utente è sincronizzato con Entra ID, concedere un'autorizzazione a livello di condivisione (ruolo Azure RBAC) all'utente onprem1user sull'account di archiviazione onprem1sa per consentire all'utente di montare la condivisione file. A tale scopo, passa alla condivisione file creata in onprem1sa e segui le istruzioni riportate in Assegnare autorizzazioni a livello di condivisione per utenti o gruppi specifici di Microsoft Entra.
- In caso contrario, usare un'autorizzazione predefinita a livello di condivisione applicabile a tutte le identità autenticate.
Ripetere i passaggi da 4 a 8 per il dominio Foresta 2onpremad2.com (account di archiviazione onprem2sa/utente 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 Windows ACL 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 /yRimontare la condivisione usando il modello di autorizzazione di Windows per l'amministratore SMB o la chiave dell'account di archiviazione (scelta non consigliata). Consulta Monta la condivisione di file SMB di Azure su Windows.
Impostare le autorizzazioni icacls per l'utente nella foresta 2 su un account di archiviazione aggiunto alla foresta 1 da un client nella foresta 1.
Note
Non usare Esplora file per configurare gli elenchi di controllo di accesso in un ambiente a più foreste. Anche se gli utenti appartenenti alla foresta che è collegata al dominio all'account di archiviazione possono avere permessi a livello di file e directory impostati tramite File Explorer, non funziona per gli utenti che non appartengono alla stessa foresta che è legata al dominio dell'account di archiviazione.
Configura il routing dei suffissi di dominio
Come spiegato in precedenza, File di Azure si registra nei Servizi di dominio Active Directory quasi allo stesso modo di un normale file server. Crea un'identità (per impostazione predefinita un account computer, ma potrebbe anche essere 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 del suffisso per abilitare l'autenticazione multi-foresta.
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. Pertanto, non gestisce correttamente tutte le richieste in cui la risorsa non viene trovata 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 SPN dell'account di archiviazione e aggiungere un record CNAME (scelta consigliata: funziona con due o più foreste)
- Aggiungere il suffisso del nome personalizzato e la regola di routing (non funziona con più di due foreste)
Modificare il suffisso SPN dell'account di archiviazione e aggiungere il record CNAME
È possibile risolvere il problema di routing del dominio modificando il suffisso SPN dell'account di archiviazione associato alla condivisione file 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 soluzione funziona per gli ambienti con due o più foreste.
In questo esempio, i domini contoso.com e adatum.com hanno contosofs e adatumfs come account di archiviazione associati a SMB Azure condivisioni file 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 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:
Aggiungi contosofs.contoso.com all'oggetto contosofs.file.core.windows.net in Active Directory e adatumfs.adatum.com all'oggetto adatumfs.file.core.windows.net in Active Directory.
Questa modifica consente ai client Adatum di montare la condivisione Contoso usando net use \\contosofs.contoso.com e i client Contoso di montare la condivisione Adatum usando net use \\adatumfs.adatum.com perché i client in Contoso o adatum sanno di cercare adatum.com o contoso.com di trovare la risorsa corretta per quell'account di archiviazione.
Per usare questo metodo, completare la procedura seguente:
Assicurarsi di aver stabilito un trust tra le due foreste e configurare l'autenticazione basata su identità e gli account utente ibridi , come descritto nelle sezioni precedenti.
Modifica lo SPN dell'account di archiviazione usando lo strumento setspn. È possibile trovare
<DomainDnsRoot>eseguendo il comando di PowerShell Active Directory seguente:(Get-AdDomain).DnsRootsetspn -s cifs/<storage-account-name>.<DomainDnsRoot> <storage-account-name>Seguendo il nostro esempio per contosofs.file.core.windows.net:
setspn -s cifs/contosofs.contoso.com contosofsAggiungi una voce CNAME usando Active Directory DNS Manager e segui questi passaggi per ogni account di archiviazione nel dominio a cui l'account di archiviazione è collegato. Se si usa un endpoint privato, aggiungere la voce CNAME per eseguire il mapping al nome dell'endpoint privato.
Apri Gestione DNS di Active Directory.
Vai nel tuo dominio (ad esempio, contoso.com).
Passare a "Zone di ricerca diretta".
Seleziona il nodo che prende il nome del tuo dominio (ad esempio, contoso.com) e clicca con il tasto destro su Nuovo Alias (CNAME).
Per il nome dell'alias, immettere il nome dell'account di archiviazione.
Per il nome di dominio completamente qualificato (FQDN), inserisci
<storage-account-name>.<domain-name>, ad esempio contosofs.contoso.com.Per l'host target FQDN, inserisci
<storage-account-name>.file.core.windows.net, come contosofs.file.core.windows.netSeleziona OK.
Ora, dai client collegati a un dominio, è possibile usare gli account di archiviazione associati a qualsiasi foresta.
Note
Assicurati che la parte host del FQDN corrisponda al nome dell'account di archiviazione come descritto in precedenza. In caso contrario, viene visualizzato un errore di accesso negato: "La sintassi del nome file, del nome della directory o dell'etichetta del volume non è corretta". Durante l'installazione della sessione SMB viene visualizzato STATUS_OBJECT_NAME_INVALID un messaggio di traccia di rete (0xc0000033).
Aggiungere il suffisso del nome personalizzato e la regola di routing
Questo metodo è un'alternativa alla modifica del suffisso SPN e all'aggiunta di un record CNAME. Risolve il problema di routing del dominio (1) registrando file.core.windows.net come suffisso UPN noto sulla Foresta 2 affinché la foresta rivendichi la proprietà di quel suffisso, e (2) configurando la Foresta 1 per inoltrare eventuali richieste Kerberos di quel suffisso alla Foresta 2. Usa questo metodo se preferisci non modificare i record DNS o gli SPN degli account di archiviazione.
Se hai già completato il metodo CNAME descritto nella sezione precedente, salta questa sezione.
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 stata stabilita una relazione di 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 Active Directory Domains and Trusts.
- Fare clic con il pulsante destro del mouse su Active Directory Domains and Trusts.
- 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 Active Directory Domains and Trusts.
- Fare clic con il pulsante destro del mouse sul dominio a cui si vuole accedere alla condivisione file. Selezionare la scheda Trusts. Selezionare il dominio Foresta 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
Dopo aver completato la configurazione, verifica che gli utenti di ogni foresta possano ottenere ticket Kerberos per autenticarsi e condividere file collegati all'altra foresta. Il comando klist mostra la cache delle credenziali di Kerberos. L'autenticazione tra foreste completata mostra i ticket emessi dal centro distribuzione chiavi dell'altra foresta.
Accedere a un computer o a una macchina virtuale associata a un dominio in Forest 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 SPN per la modifica dell'account di archiviazione ed è stato aggiunto il metodo del 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 SPN per la modifica dell'account di archiviazione ed è stato aggiunto il metodo del record CNAME, eseguire:
L'output dovrebbe essere simile al seguente. L'output klist varia leggermente 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.comAccedi a un computer o a una macchina virtuale collegata a un dominio in Forest 2 e apri 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 SPN per la modifica dell'account di archiviazione ed è stato aggiunto il metodo del 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 SPN per la modifica dell'account di archiviazione ed è stato aggiunto il metodo del record CNAME, eseguire:
L'output dovrebbe essere simile al seguente. L'output klist varia leggermente 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 e assicurare il funzionamento dell'autenticazione a più foreste.
Importante
L'aggiunta di un suffisso di nome personalizzato e regola di routing funziona solo in ambienti con due foreste. Se hai più di due foreste, modifica invece il suffisso SPN dell'account di archiviazione e aggiungi un record CNAME.
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 Active Directory Domains and Trusts.
- Fare clic con il pulsante destro del mouse su Active Directory Domains and Trusts.
- 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 Active Directory Domains and Trusts.
- 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.
Passo successivo
Per altre informazioni, vedere: