Condividi tramite


Panoramica dell'autenticazione basata su identità File di Azure per l'accesso SMB

Questo articolo illustra come usare l'autenticazione basata su identità, in locale o in Azure, per abilitare l'accesso basato sulle identità alle condivisioni file di Azure tramite SMB. Proprio come i file server Windows, è possibile concedere autorizzazioni a un'identità a livello di condivisione, directory o file. Non sono previsti costi aggiuntivi per abilitare l'autenticazione basata su identità nell'account di archiviazione.

L'autenticazione basata su identità non è attualmente supportata con le condivisioni NFS (Network File System). Tuttavia, è disponibile tramite SMB per i client Windows e Linux.

Per motivi di sicurezza, è consigliabile usare l'autenticazione basata su identità per accedere alle condivisioni file usando la chiave dell'account di archiviazione.

Importante

Non condividere mai le chiavi dell'account di archiviazione. Usare invece l'autenticazione basata su identità.

Funzionamento

Le condivisioni file di Azure usano il protocollo Kerberos per l'autenticazione con un'origine di identità. Quando un'identità associata a un utente o a un'applicazione in esecuzione in un client tenta di accedere ai dati nelle condivisioni file di Azure, la richiesta viene inviata all'origine dell'identità per autenticare l'identità. Se l'autenticazione ha esito positivo, l'origine dell'identità restituisce un ticket Kerberos. Il client invia quindi una richiesta che include il ticket Kerberos e File di Azure usa tale ticket per autorizzare la richiesta. Il servizio File di Azure riceve solo il ticket Kerberos, non le credenziali di accesso dell'utente.

Casi d'uso comuni

L'autenticazione basata su identità con condivisioni file di Azure SMB può essere utile in diversi scenari:

Sostituire i file server locali

La sostituzione di file server locali sparsi è una sfida che ogni organizzazione deve affrontare durante il percorso di modernizzazione IT. L'uso dell'autenticazione basata su identità con File di Azure offre un'esperienza di migrazione senza problemi, consentendo agli utenti finali di continuare ad accedere ai dati con le stesse credenziali.

Trasferire in modalità lift-and-shift le applicazioni in Azure

Quando si spostano in modalità lift-and-shift le applicazioni nel cloud, è probabile che si voglia mantenere lo stesso modello di autenticazione per l'accesso alla condivisione file. L'autenticazione basata su identità elimina la necessità di modificare il servizio directory, accelerando l'adozione del cloud.

Backup e ripristino di emergenza

Se si mantiene l'archiviazione file primaria in locale, File di Azure è una soluzione ideale per il backup e il ripristino di emergenza per migliorare la continuità aziendale. È possibile usare le condivisioni file di Azure per eseguire il backup dei file server mantenendo al tempo stesso elenchi di controllo di accesso discrezionale (DACL) di Windows. Per gli scenari di ripristino di emergenza, è possibile configurare un'opzione di autenticazione per supportare l'applicazione corretta del controllo di accesso in fase di failover.

Scegliere un'origine di identità per l'account di archiviazione

Prima di abilitare l'autenticazione basata sull'identità nell'account di archiviazione, è necessario conoscere l'origine dell'identità che si intende usare. È probabile che ne sia già disponibile una, perché la maggior parte delle aziende e delle organizzazioni ha un certo tipo di ambiente di dominio configurato. Consultare Active Directory (AD) o l'amministratore IT per assicurarsi. Se non si ha già un'origine di identità, è necessario configurare una prima di poter abilitare l'autenticazione basata su identità.

Scenari di autenticazione supportati

È possibile abilitare l'autenticazione basata sull'identità tramite SMB usando una delle tre origini di identità: Servizi di Dominio di Active Directory locali (AD DS), Microsoft Entra Domain Services o Microsoft Entra Kerberos (solo identità ibride). È possibile usare un'unica origine di identità per l'autenticazione dell'accesso ai file per ogni account di archiviazione e si applica a tutte le condivisioni file nell'account.

  • Active Directory Domain Services locale: i client e le macchine virtuali di Active Directory Domain Services locali possono accedere alle condivisioni file di Azure con credenziali di Active Directory locale. L'ambiente di Active Directory Domain Services locale deve essere sincronizzato con Microsoft Entra ID usando l'applicazione Microsoft Entra Connect locale o la sincronizzazione cloud di Microsoft Entra Connect, un agente leggero che può essere installato dall'interfaccia di amministrazione di Microsoft Entra. Per usare questo metodo di autenticazione, il client deve essere aggiunto a un dominio o avere connettività di rete non implementata a Servizi di dominio Active Directory. Vedere l'elenco completo dei prerequisiti.

  • Microsoft Entra Kerberos per le identità ibride: è possibile usare Microsoft Entra ID per autenticare le identità utente ibride, consentendo agli utenti finali di accedere alle condivisioni file di Azure senza richiedere la connettività di rete ai controller di dominio. Questa opzione richiede una distribuzione di Active Directory Domain Services esistente, che viene quindi sincronizzata con il tenant di Microsoft Entra in modo che Microsoft Entra ID possa autenticare le identità ibride. Le identità solo cloud non sono attualmente supportate usando questo metodo. Vedere l'elenco completo dei prerequisiti.

  • Servizi di dominio Microsoft Entra: le macchine virtuali basate sul cloud aggiunte a Microsoft Entra Domain Services possono accedere alle condivisioni file di Azure con le credenziali di Microsoft Entra. In questa soluzione, Microsoft Entra ID esegue un dominio di Windows Server AD tradizionale figlio del tenant di Microsoft Entra del cliente. Microsoft Entra Domain Services è attualmente l'unica opzione per l'autenticazione delle identità solo cloud. Vedere l'elenco completo dei prerequisiti.

Usare le linee guida seguenti per determinare quale origine di identità scegliere.

  • Se l'organizzazione ha già un'istanza di Active Directory locale e non è pronta per spostare le identità nel cloud e se i client, le macchine virtuali e le applicazioni sono aggiunti a un dominio o hanno connettività di rete non implementata a tali controller di dominio, scegliere Servizi di dominio Active Directory.

  • Se alcuni o tutti i client non hanno connettività di rete non implementata ad Active Directory Domain Services o se si archiviano profili FSLogix nelle condivisioni file di Azure per le macchine virtuali aggiunte a Microsoft Entra, scegliere Microsoft Entra Kerberos.

  • Se si dispone di un'istanza di ACTIVE Directory locale esistente ma si prevede di spostare le applicazioni nel cloud e si vuole che le identità esistano sia in locale che nel cloud, scegliere Microsoft Entra Kerberos.

  • Se non si dispone di un'origine di identità esistente, se è necessario autenticare le identità solo cloud o se si usa già Microsoft Entra Domain Services, scegliere Microsoft Entra Domain Services. Se non è già stato distribuito un servizio di dominio in Azure, si noterà un nuovo addebito sulla fattura di Azure per questo servizio.

Abilitare un'origine di identità

Dopo aver scelto un'origine di identità, è necessario abilitarla nell'account di archiviazione.

Servizi di dominio Active Directory

Per l'autenticazione di Active Directory Domain Services, è necessario aggiungere un dominio ai computer client o alle macchine virtuali. È possibile ospitare i controller di dominio DI AD in macchine virtuali di Azure o in locale. In entrambi i casi, i client aggiunti a un dominio devono avere connettività di rete non implementata al controller di dominio, quindi devono trovarsi all'interno della rete aziendale o della rete virtuale (VNET) del servizio di dominio.

Il diagramma seguente illustra l'autenticazione di Active Directory Domain Services locale nelle condivisioni file di Azure tramite SMB. L'istanza locale di Active Directory Domain Services deve essere sincronizzata con Microsoft Entra ID usando microsoft Entra Connect Sync o microsoft Entra Connect cloud sync. Solo le identità utente ibride presenti sia in Active Directory Domain Services locale che nell'ID Microsoft Entra possono essere autenticate e autorizzate per l'accesso alla condivisione file di Azure. Ciò è dovuto al fatto che l'autorizzazione a livello di condivisione è configurata in base all'identità rappresentata nell'ID Microsoft Entra, mentre l'autorizzazione a livello di directory/file viene applicata con quella in Active Directory Domain Services. Assicurarsi di configurare correttamente le autorizzazioni per lo stesso utente ibrido.

Diagramma che illustra l'autenticazione di Active Directory Domain Services locale nelle condivisioni file di Azure tramite SMB.

Per abilitare l'autenticazione di Active Directory Domain Services, leggere prima panoramica - Active Directory locale l'autenticazione di Domain Services tramite SMB per le condivisioni file di Azure e quindi vedere Abilitare l'autenticazione di Active Directory Domain Services per le condivisioni file di Azure.

Kerberos di Microsoft Entra per le identità ibride

L'abilitazione e la configurazione di Microsoft Entra ID per l'autenticazione delle identità utente ibride consente agli utenti di Microsoft Entra di accedere alle condivisioni file di Azure usando l'autenticazione Kerberos. Questa configurazione usa Microsoft Entra ID per rilasciare i ticket Kerberos per accedere alla condivisione file con il protocollo SMB standard del settore. Ciò significa che gli utenti finali possono accedere alle condivisioni file di Azure senza richiedere la connettività di rete ai controller di dominio da macchine virtuali aggiunte a Microsoft Entra ibride e microsoft Entra. Tuttavia, la configurazione delle autorizzazioni a livello di directory e file per utenti e gruppi richiede la connettività di rete non implementata al controller di dominio locale.

Importante

L'autenticazione Kerberos di Microsoft Entra supporta solo le identità utente ibride; non supporta le identità solo cloud. È necessaria una distribuzione tradizionale di Servizi di dominio Active Directory e deve essere sincronizzata con l'ID Microsoft Entra Connect usando la sincronizzazione cloud Microsoft Entra Connect o Microsoft Entra Connect. I client devono essere aggiunti a Microsoft Entra o aggiunti a Microsoft Entra ibrido. Microsoft Entra Kerberos non è supportato nei client aggiunti a Microsoft Entra Domain Services o aggiunti solo ad AD.

Diagramma della configurazione per l'autenticazione Kerberos di Microsoft Entra per le identità ibride tramite SMB.

Per abilitare l'autenticazione Kerberos di Microsoft Entra per le identità ibride, vedere Abilitare l'autenticazione Kerberos di Microsoft Entra per le identità ibride in File di Azure.

È anche possibile usare questa funzionalità per archiviare i profili FSLogix nelle condivisioni file di Azure per le macchine virtuali aggiunte a Microsoft Entra. Per altre informazioni, vedere Creare un contenitore di profili con File di Azure e ID Microsoft Entra.

Servizi di dominio Microsoft Entra

Per l'autenticazione di Microsoft Entra Domain Services, è necessario abilitare Microsoft Entra Domain Services e aggiungere al dominio le macchine virtuali da cui si prevede di accedere ai dati dei file. La macchina virtuale aggiunta a un dominio deve trovarsi nella stessa rete virtuale del dominio ospitato da Microsoft Entra Domain Services.

Il diagramma seguente rappresenta il flusso di lavoro per l'autenticazione di Microsoft Entra Domain Services nelle condivisioni file di Azure tramite SMB. Segue un modello simile all'autenticazione di Active Directory Domain Services locale, ma esistono due differenze principali:

  • Non è necessario creare un'identità in Microsoft Entra Domain Services per rappresentare l'account di archiviazione. Questa operazione viene eseguita dal processo di abilitazione in background.

  • Tutti gli utenti presenti in Microsoft Entra ID possono essere autenticati e autorizzati. Gli utenti possono essere solo cloud o ibridi. La sincronizzazione da Microsoft Entra ID a Microsoft Entra Domain Services viene gestita dalla piattaforma senza richiedere alcuna configurazione utente. Tuttavia, il client deve essere aggiunto al dominio ospitato di Microsoft Entra Domain Services. Non può essere registrato o aggiunto a Microsoft Entra. Microsoft Entra Domain Services non supporta i client non Azure (ad esempio portatili utente, workstation, macchine virtuali in altri cloud e così via) aggiunti al dominio ospitato da Microsoft Entra Domain Services. Tuttavia, è possibile montare una condivisione file da un client non aggiunto a un dominio specificando credenziali esplicite, ad esempio DOMAINNAME\username o usando il nome di dominio completo (username@FQDN).

Diagramma della configurazione per l'autenticazione di Microsoft Entra Domain Services con File di Azure su SMB.

Per abilitare l'autenticazione di Microsoft Entra Domain Services, vedere Abilitare l'autenticazione di Microsoft Entra Domain Services in File di Azure.

Autorizzazione e controllo di accesso

Indipendentemente dall'origine identità scelta, dopo averlo abilitato, sarà necessario configurare l'autorizzazione. File di Azure applica l'autorizzazione all'accesso utente sia a livello di condivisione che a livello di directory/file.

È possibile assegnare autorizzazioni a livello di condivisione a utenti o gruppi di Microsoft Entra gestiti tramite il controllo degli accessi in base al ruolo di Azure. Con il controllo degli accessi in base al ruolo di Azure, le credenziali usate per l'accesso ai file devono essere disponibili o sincronizzate con Microsoft Entra ID. È possibile assegnare ruoli predefiniti di Azure come lettore SMB di dati file di archiviazione a utenti o gruppi in Microsoft Entra ID per concedere l'accesso a una condivisione file.

A livello di directory/file, File di Azure supporta il mantenimento, l'ereditarietà e l'applicazione degli ACL di Windows. È possibile scegliere di mantenere gli ACL di Windows durante la copia dei dati tramite SMB tra la condivisione file esistente e le condivisioni file di Azure. Indipendentemente dal fatto che si intenda applicare o meno l'autorizzazione, è possibile usare condivisioni file di Azure per eseguire il backup degli ACL insieme ai dati.

Configurare le autorizzazioni a livello di condivisione

Dopo aver abilitato un'origine di identità nell'account di archiviazione, è necessario eseguire una delle operazioni seguenti per accedere alla condivisione file:

  • Impostare un'autorizzazione a livello di condivisione predefinita che si applica a tutti gli utenti e i gruppi autenticati
  • Assegnare ruoli predefiniti del controllo degli accessi in base al ruolo di Azure a utenti e gruppi o
  • Configurare ruoli personalizzati per le identità di Microsoft Entra e assegnare diritti di accesso alle condivisioni file nell'account di archiviazione.

L'autorizzazione a livello di condivisione assegnata consente all'identità concessa di ottenere l'accesso solo alla condivisione, nient'altro, nemmeno la directory radice. È comunque necessario configurare separatamente le autorizzazioni a livello di directory e file.

Nota

Non è possibile assegnare autorizzazioni a livello di condivisione agli account computer (account computer) usando il controllo degli accessi in base al ruolo di Azure, perché gli account computer non possono essere sincronizzati con un'identità in Microsoft Entra ID. Se si vuole consentire a un account computer di accedere alle condivisioni file di Azure usando l'autenticazione basata sull'identità, usare invece un'autorizzazione predefinita a livello di condivisione o prendere in considerazione l'uso di un account di accesso al servizio.

Configurare le autorizzazioni a livello di directory o file

Le condivisioni file di Azure applicano gli ACL di Windows standard sia a livello di directory che a livello di file, inclusa la directory radice. La configurazione delle autorizzazioni a livello di directory o file è supportata sia su SMB che su REST. Montare la condivisione file di destinazione dalla macchina virtuale e configurare le autorizzazioni usando Windows Esplora file, Windows icacls o il comando Set-ACL.

Mantenere gli ACL di directory e file durante l'importazione di dati in File di Azure

File di Azure supporta il mantenimento degli ACL a livello di directory o di file durante la copia dei dati nelle condivisioni file di Azure. È possibile copiare gli ACL di una directory o di un file in condivisioni file di Azure usando Sincronizzazione file di Azure o comuni set di strumenti di spostamento di file. Ad esempio, è possibile usare robocopy con il /copy:s flag per copiare dati e ACL in una condivisione file di Azure. Gli ACL vengono mantenuti per impostazione predefinita, quindi non è necessario abilitare l'autenticazione basata su identità nell'account di archiviazione per mantenere gli elenchi di controllo di accesso.

Glossario

È utile comprendere alcuni termini chiave relativi all'autenticazione basata su identità per le condivisioni file di Azure:

  • Autenticazione Kerberos

    Kerberos è un protocollo di autenticazione usato per verificare l'identità di un utente o di un host. Per altre informazioni su Kerberos, vedere Panoramica dell'autenticazione Kerberos.

  • Protocollo Server Message Block (SMB)

    SMB è un protocollo standard di settore per la condivisione dei file in rete. Per altre informazioni su SMB, vedere Protocollo SMB di Microsoft e panoramica del protocollo CIFS.

  • Microsoft Entra ID

    Microsoft Entra ID (in precedenza Azure AD) è il servizio di gestione delle identità e della directory multi-tenant basato sul cloud di Microsoft. Microsoft Entra ID combina i servizi directory di base, la gestione degli accessi alle applicazioni e la protezione delle identità in un'unica soluzione.

  • Microsoft Entra Domain Services

    Servizi di dominio Microsoft Entra fornisce servizi di dominio gestiti, ad esempio l'aggiunta a un dominio, criteri di gruppo, LDAP e l'autenticazione Kerberos/NTLM. Questi servizi sono completamente compatibili con Active Directory Domain Services. Per altre informazioni, vedere Microsoft Entra Domain Services.

  • Servizi di Dominio di Active Directory locali

    Active Directory Domain Services viene comunemente adottato dalle aziende in ambienti locali o in macchine virtuali ospitate nel cloud e le credenziali di Active Directory Domain Services vengono usate per il controllo di accesso. Per altre informazioni, vedere Panoramica di Dominio di Active Directory Services.

  • Controllo degli accessi in base al ruolo di Azure

    Il controllo degli accessi in base al ruolo di Azure consente di gestire gli accessi con granularità fine per Azure. Usando il controllo degli accessi in base al ruolo di Azure, è possibile gestire l'accesso alle risorse concedendo agli utenti le autorizzazioni più poche necessarie per eseguire i processi. Per altre informazioni, vedere Che cos'è il controllo degli accessi in base al ruolo di Azure?

  • Identità ibride

    Le identità utente ibride sono identità in Servizi di dominio Active Directory sincronizzate con Microsoft Entra ID usando l'applicazione locale Microsoft Entra Connect Sync o microsoft Entra Connect cloud sync, un agente leggero che può essere installato dall'interfaccia di amministrazione di Microsoft Entra.

Passaggio successivo

Per altre informazioni, vedi: