Condividi tramite

Configurare un trust cloud tra Active Directory Domain Services locale e Microsoft Entra ID per l'accesso a File di Azure

  • Articolo

Molte organizzazioni vogliono usare l'autenticazione basata su identità per condivisioni file di Azure SMB in ambienti che si estendono sia Active Directory locale Domain Services (AD DS) che Microsoft Entra ID (in precedenza Azure Active Directory), ma non soddisfano i prerequisiti necessari per il sistema operativo o il dominio.

In questi scenari, i clienti possono abilitare l'autenticazione Kerberos di Microsoft Entra per le identità utente ibride e quindi stabilire un trust cloud tra i servizi di dominio Active Directory locali e l'ID Microsoft Entra per accedere alle condivisioni file SMB usando le credenziali locali. Questo articolo illustra il funzionamento di un trust cloud e fornisce istruzioni per la configurazione e la convalida. Include anche i passaggi per ruotare una chiave Kerberos per l'account del servizio in Microsoft Entra ID e oggetto dominio attendibile e i passaggi per rimuovere un oggetto dominio attendibile e tutte le impostazioni Kerberos, se necessario.

Questo articolo è incentrato sull'autenticazione delle identità utente ibride, che sono identità di Active Directory Domain Services locali sincronizzate con Microsoft Entra ID usando la sincronizzazione cloud microsoft Entra Connect o Microsoft Entra Connect. Le identità solo cloud non sono attualmente supportate per File di Azure.

Si applica a

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

Scenari

Di seguito sono riportati alcuni esempi di scenari in cui è possibile configurare un trust cloud:

  • Si dispone di un servizio di dominio Active Directory locale tradizionale, ma non è possibile usarlo per l'autenticazione perché non si dispone di connettività di rete non implementata ai controller di dominio.

  • È stata avviata la migrazione al cloud, ma attualmente le applicazioni sono ancora in esecuzione in Servizi di dominio Active Directory locali tradizionali.

  • Alcuni o tutti i computer client non soddisfano i requisiti del sistema operativo per l'autenticazione Kerberos di Microsoft Entra.

Autorizzazioni

Per completare i passaggi descritti in questo articolo, è necessario:

  • Nome utente e password dell'amministratore Active Directory locale
  • Nome utente e password dell'account Amministratore globale di Microsoft Entra

Prerequisiti

Prima di implementare il flusso di autenticazione basata su attendibilità in ingresso, assicurarsi che siano soddisfatti i prerequisiti seguenti:

Prerequisito Descrizione
I client devono eseguire Windows 10, Windows Server 2012 o una versione successiva di Windows.
I client devono essere aggiunti ad Active Directory (AD). Il dominio deve avere un livello funzionale di Windows Server 2012 o successivo. È possibile determinare se il client ha un join ad AD eseguendo il comando dsregcmd: dsregcmd.exe /status
Un tenant di Microsoft Entra. Un tenant di Microsoft Entra è un limite di sicurezza delle identità sotto il controllo del reparto IT dell'organizzazione. Si tratta di un'istanza di Microsoft Entra ID in cui si trovano le informazioni su una singola organizzazione.
Una sottoscrizione di Azure nello stesso tenant di Microsoft Entra che si prevede di usare per l'autenticazione.
Un account di archiviazione di Azure nella sottoscrizione di Azure. Un account di archiviazione di Azure è una risorsa che funge da contenitore per raggruppare tutti i servizi dati da Archiviazione di Azure, inclusi i file.
È necessario installare la sincronizzazione cloud Microsoft Entra Connect o Microsoft Entra Connect. Queste soluzioni vengono usate in ambienti ibridi in cui esistono identità sia in Microsoft Entra ID che in Active Directory Domain Services locale.

Abilitare l'autenticazione Kerberos di Microsoft Entra

Se è già stata abilitata l'autenticazione Kerberos di Microsoft Entra nell'account di archiviazione, è possibile ignorare questo passaggio e procedere a Creare e configurare l'oggetto dominio attendibile Kerberos di Microsoft Entra.

È possibile abilitare l'autenticazione Kerberos di Microsoft Entra in File di Azure per gli account utente ibridi usando il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure.

Per abilitare l'autenticazione Kerberos di Microsoft Entra tramite il portale di Azure, seguire questa procedura.

  1. Accedere al portale di Azure e selezionare l'account di archiviazione per cui si desidera abilitare l'autenticazione Kerberos di Microsoft Entra.

  2. In Archiviazione dati, selezionare Condivisioni file.

  3. Accanto ad Active Directoryselezionare lo stato di configurazione, ad esempio Non configurato.

    Screenshot del portale di Azure che mostra le impostazioni di condivisione file per un account di archiviazione. Sono selezionate le impostazioni di configurazione di Active Directory.

  4. In Microsoft Entra Kerberosselezionare Configura.

  5. Selezionare la casella di controllo Microsoft Entra Kerberos.

    Screenshot del portale di Azure che mostra le impostazioni di configurazione di Active Directory per un account di archiviazione. Microsoft Entra Kerberos è selezionato.

  6. Facoltativo: se si desidera configurare le autorizzazioni a livello di directory e file tramite Esplora file di Windows, è necessario specificare il nome di dominio e il GUID di dominio per AD locale. È possibile ottenere queste informazioni dall'amministratore di dominio o eseguendo il cmdlet di PowerShell di Active Directory seguente da un client aggiunto a AD locale: Get-ADDomain. Il nome di dominio deve essere elencato nell'output DNSRoot in e il GUID del dominio deve essere elencato in ObjectGUID. Se si preferisce configurare le autorizzazioni a livello di directory e file usando icacls, è possibile ignorare questo passaggio. Tuttavia, se si desidera usare icacls, il client richiederà la connettività di rete non implementata a AD locale.

  7. Seleziona Salva.

Avviso

Se l'autenticazione Kerberos di Microsoft Entra è stata abilitata in precedenza tramite passaggi di anteprima limitati manuali per archiviare i profili FSLogix in File di Azure per le macchine virtuali aggiunte a Microsoft Entra, la password per l'entità servizio dell'account di archiviazione è impostata per scadere ogni sei mesi. Una volta scaduta la password, gli utenti non potranno ottenere ticket Kerberos per la condivisione file. Per attenuare questo problema, vedere "Errore - Password dell'entità servizio scaduta in Microsoft Entra ID" in Potenziali errori durante l'abilitazione dell'autenticazione Kerberos di Microsoft Entra per gli utenti ibridi.

Dopo aver abilitato l'autenticazione Kerberos di Microsoft Entra, è necessario concedere esplicitamente il consenso amministratore alla nuova applicazione Microsoft Entra registrata nel tenant di Microsoft Entra. Questa entità servizio viene generata automaticamente e non viene usata per l'autorizzazione per la condivisione file, quindi non apportare modifiche all'entità servizio differente da quelle documentate qui. In questo caso, è possibile che venga visualizzato un errore.

È possibile configurare le autorizzazioni API dal portale di Azure seguendo questa procedura:

  1. Aprire ID Microsoft Entra.
  2. Nel menu Servizio in Gestisci selezionare Registrazioni app.
  3. Selezionare Tutte le applicazioni.
  4. Selezionare l'applicazione con il nome corrispondente a [Account di archiviazione] <your-storage-account-name>.file.core.windows.net.
  5. Nel menu del servizio, in Gestisci, selezionare Autorizzazioni API.
  6. Selezionare Concedi consenso amministratore per [Nome directory] per concedere il consenso per le tre autorizzazioni API richieste (openid, profilo e User.Read) per tutti gli account nella directory.
  7. Seleziona Sì per confermare.

Importante

Se ci si connette a un account di archiviazione tramite un endpoint privato o un collegamento privato usando l'autenticazione Kerberos di Microsoft Entra, sarà necessario aggiungere anche il nome di dominio completo del collegamento privato all'applicazione Microsoft Entra dell'account di archiviazione. Per istruzioni, vedere la voce nella guida alla risoluzione dei problemi.

Disabilitare l'autenticazione a più fattori nell'account di archiviazione

Microsoft Entra Kerberos non supporta l'uso di MFA per accedere alle condivisioni file di Azure configurate con Microsoft Entra Kerberos. Se si applicano a tutte le app, è necessario escludere l'app Microsoft Entra che rappresenta l'account di archiviazione dai criteri di accesso condizionale MFA.

L'app dell'account di archiviazione deve avere lo stesso nome dell'account di archiviazione nell'elenco di esclusione dell'accesso condizionale. Quando si cerca l'app dell'account di archiviazione nell'elenco di esclusione dell'accesso condizionale, cercare : [Account di archiviazione] <your-storage-account-name>.file.core.windows.net

Ricordarsi di sostituire <your-storage-account-name> con il valore appropriato.

Importante

Se non si escludono criteri di autenticazione a più fattori dall'app dell'account di archiviazione, non sarà possibile accedere alla condivisione file. Se si tenta di eseguire il mapping della condivisione file con net use verrà visualizzato un messaggio di errore che indica che l'errore di sistema 1327: le restrizioni dell'account impediscono all'utente di eseguire l'accesso. Ad esempio, le password vuote non sono consentite, i tempi di accesso sono limitati o è stata applicata una restrizione dei criteri."

Per materiale sussidiario sulla disabilitazione dell'autenticazione a più fattori, vedere quanto segue:

Assegnare autorizzazioni a livello di condivisione

Quando si abilita l'accesso basato sull'identità, per ogni condivisione è necessario assegnare a quali utenti e gruppi è possibile accedere a tale condivisione specifica. Quando un utente o un gruppo è autorizzato ad accedere a una condivisione, gli ACL di Windows (detti anche autorizzazioni NTFS) su singoli file e directory assumono il controllo. In questo modo è possibile controllare con granularità fine sulle autorizzazioni, analogamente a una condivisione SMB in un server Windows.

Per impostare le autorizzazioni a livello di condivisione, seguire le istruzioni in Assegnare autorizzazioni a livello di condivisione a un'identità.

Configurare le autorizzazioni a livello di directory e file

Dopo aver impostato le autorizzazioni a livello di condivisione, è possibile assegnare autorizzazioni a livello di directory/file all'utente o al gruppo. Ciò richiede l'uso di un dispositivo con connettività di rete non implementata a un'istanza di AD locale.

Per configurare le autorizzazioni a livello di directory e file, seguire le istruzioni in Configurare le autorizzazioni a livello di directory e file su SMB.

Creare e configurare l'oggetto di dominio attendibile Kerberos di Microsoft Entra

Per creare e configurare l'oggetto dominio attendibile Microsoft Entra Kerberos, si userà il modulo PowerShell di Gestione autenticazione ibrida di Azure AD. Questo modulo consente alle organizzazioni di identità ibride di usare le credenziali moderne per le applicazioni e consente a Microsoft Entra ID di diventare l'origine attendibile sia per l'autenticazione cloud che per l'autenticazione locale.

Configurare l'oggetto di dominio attendibile

Si userà il modulo PowerShell di Gestione autenticazione ibrida di Azure AD per configurare un oggetto dominio attendibile nel dominio DI AD locale e registrare le informazioni di attendibilità con Microsoft Entra ID. In questo modo viene creata una relazione di attendibilità associata in AD in locale, che consente a Microsoft Entra ID di considerare attendibile AD in locale.

È necessario configurare l'oggetto dominio attendibile una sola volta per ogni dominio. Se questa operazione è già stata eseguita per il dominio, è possibile ignorare questa sezione e procedere a Configurare i client per recuperare i ticket Kerberos.

Installare il modulo PowerShell di Gestione autenticazione ibrida di Azure AD

  1. Avviare una sessione di Windows PowerShell con l'opzione Esegui come amministratore .

  2. Installare il modulo PowerShell di Gestione autenticazione ibrida di Azure AD usando lo script seguente. Lo script:

    • Abilita TLS 1.2 per la comunicazione.
    • Installa il provider di pacchetti NuGet.
    • Registra il repository PSGallery.
    • Installa il modulo PowerShellGet.
    • Installa il modulo PowerShell di Gestione autenticazione ibrida di Azure AD.
      • Azure AD Hybrid Authentication Management PowerShell usa il modulo AzureADPreview, che fornisce funzionalità avanzate di gestione di Microsoft Entra.
      • Per proteggersi da conflitti di installazione non necessari con il modulo Azure AD PowerShell, questo comando include il flag di -AllowClobber opzione.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Install-PackageProvider -Name NuGet -Force

if (@(Get-PSRepository | ? {$_.Name -eq "PSGallery"}).Count -eq 0){
    Register-PSRepository -DefaultSet-PSRepository -Name "PSGallery" -InstallationPolicy Trusted
}

Install-Module -Name PowerShellGet -Force

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Creare l'oggetto di dominio attendibile

  1. Avviare una sessione di Windows PowerShell con l'opzione Esegui come amministratore .

  2. Impostare i parametri comuni. Personalizzare lo script seguente prima di eseguirlo.

    • Impostare il parametro $domain sul nome di dominio Active Directory locale.
    • Quando richiesto da Get-Credential, immettere un nome utente e una password Active Directory locale amministratore.
    • Impostare il parametro $cloudUserName sul nome utente di un account con privilegi di amministratore globale per l'accesso al cloud Microsoft Entra.

    Nota

    Se si vuole usare l'account di accesso di Windows corrente per l'accesso Active Directory locale, è possibile ignorare il passaggio in cui vengono assegnate le credenziali al parametro $domainCred. Se si usa questo approccio, non includere il -DomainCredential parametro nei comandi di PowerShell che seguono questo passaggio.

    $domain = "your on-premesis domain name, for example contoso.com"

$domainCred = Get-Credential

$cloudUserName = "Azure AD user principal name, for example admin@contoso.onmicrosoft.com"

  3. Controllare le Impostazioni di dominio Kerberos corrente.

    Eseguire il comando seguente per controllare le impostazioni Kerberos correnti del dominio:

    Get-AzureAdKerberosServer -Domain $domain `
    -DomainCredential $domainCred `
    -UserPrincipalName $cloudUserName

    Se questa è la prima volta che si chiama un comando Kerberos di Microsoft Entra, viene richiesto l'accesso al cloud Microsoft Entra.

    • Immettere la password per l'account da amministratore Microsoft Entra Global.
    • Se l'organizzazione usa altri metodi di autenticazione moderni, ad esempio l'autenticazione a più fattori Microsoft Entra o smart card, seguire le istruzioni richieste per l'accesso.

    Se questa è la prima volta che si configurano le impostazioni Kerberos di Microsoft Entra, il cmdlet Get-AzureAdKerberosServer visualizza informazioni vuote, come nell'output di esempio seguente:

    ID                  :
UserAccount         :
ComputerAccount     :
DisplayName         :
DomainDnsName       :
KeyVersion          :
KeyUpdatedOn        :
KeyUpdatedFrom      :
CloudDisplayName    :
CloudDomainDnsName  :
CloudId             :
CloudKeyVersion     :
CloudKeyUpdatedOn   :
CloudTrustDisplay   :

    Se il dominio supporta già l'autenticazione FIDO, il cmdlet Get-AzureAdKerberosServer visualizza le informazioni sull'account del servizio Microsoft Entra, come nell'output di esempio seguente. Il campo CloudTrustDisplay restituisce un valore vuoto.

    ID                  : XXXXX
UserAccount         : CN=krbtgt-AzureAD, CN=Users, DC=contoso, DC=com
ComputerAccount     : CN=AzureADKerberos, OU=Domain Controllers, DC=contoso, DC=com
DisplayName         : XXXXXX_XXXXX
DomainDnsName       : contoso.com
KeyVersion          : 53325
KeyUpdatedOn        : 2/24/2024 9:03:15 AM
KeyUpdatedFrom      : ds-aad-auth-dem.contoso.com
CloudDisplayName    : XXXXXX_XXXXX
CloudDomainDnsName  : contoso.com
CloudId             : XXXXX
CloudKeyVersion     : 53325
CloudKeyUpdatedOn   : 2/24/2024 9:03:15 AM
CloudTrustDisplay   :

  4. Aggiungere l'oggetto di dominio attendibile.

    Eseguire il cmdlet Set-AzureAdKerberosServer PowerShell per aggiungere l'oggetto di dominio attendibile. Assicurarsi di includere il parametro -SetupCloudTrust. Se non è presente alcun account del servizio Microsoft Entra, questo comando crea un nuovo account del servizio Microsoft Entra. Questo comando creerà l'oggetto di dominio attendibile richiesto solo se è presente un account del servizio Microsoft Entra.

    Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUserName -DomainCredential $domainCred -SetupCloudTrust

    Nota

    In un forest a più domini, per evitare l'errore LsaCreateTrustedDomainEx 0x549 quando si esegue il comando in un dominio figlio:

    1. Eseguire il comando nel dominio radice (include il parametro -SetupCloudTrust).
    2. Eseguire lo stesso comando nel dominio figlio senza il parametro -SetupCloudTrust.

    Dopo aver creato l'oggetto di dominio attendibile, è possibile controllare le Impostazioni Kerberos aggiornate usando il cmdlet Get-AzureAdKerberosServer di PowerShell, come illustrato nel passaggio precedente. Se il cmdlet Set-AzureAdKerberosServer è stato eseguito correttamente con il parametro -SetupCloudTrust, il CloudTrustDisplay campo dovrebbe ora restituire Microsoft.AzureAD.Kdc.Service.TrustDisplay, come nell'output di esempio seguente:

    ID                  : XXXXX
UserAccount         : CN=krbtgt-AzureAD, CN=Users, DC=contoso, DC=com
ComputerAccount     : CN=AzureADKerberos, OU=Domain Controllers, DC=contoso, DC=com
DisplayName         : XXXXXX_XXXXX
DomainDnsName       : contoso.com
KeyVersion          : 53325
KeyUpdatedOn        : 2/24/2024 9:03:15 AM
KeyUpdatedFrom      : ds-aad-auth-dem.contoso.com
CloudDisplayName    : XXXXXX_XXXXX
CloudDomainDnsName  : contoso.com
CloudId             : XXXXX
CloudKeyVersion     : 53325
CloudKeyUpdatedOn   : 2/24/2024 9:03:15 AM
CloudTrustDisplay   : Microsoft.AzureAD.Kdc.Service.TrustDisplay

    Nota

    I cloud sovrani di Azure richiedono l'impostazione della proprietà TopLevelNames che è configurata su windows.net per impostazione predefinita. Le distribuzioni di cloud sovrani di Azure di Istanza gestita di SQL usano un nome di dominio di primo livello diverso, ad esempio usgovcloudapi.net per Azure US Government. Impostare l'oggetto dominio attendibile su tale nome di dominio di primo livello usando il comando di PowerShell seguente: Set-AzureADKerberosServer -Domain $domain -DomainCredential $domainCred -CloudCredential $cloudCred -SetupCloudTrust -TopLevelNames "usgovcloudapi.net,windows.net". L'impostazione può essere verificata da PowerShell con il comando seguente: Get-AzureAdKerberosServer -Domain $domain -DomainCredential $domainCred -UserPrincipalName $cloudUserName | Select-Object -ExpandProperty CloudTrustDisplay.

Configurare i client per recuperare i ticket Kerberos

Identificare l'ID tenant di Microsoft Entra e usare Criteri di gruppo per configurare i computer client da cui si vuole montare/usare condivisioni file di Azure. È necessario eseguire questa operazione in ogni client in cui verranno usati File di Azure.

Impostare questi criteri di gruppo nel/i client su "Abilitato": Administrative Templates\System\Kerberos\Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon

  1. Distribuire l'impostazione di Criteri di gruppo seguente nei computer client usando il flusso basato sull'attendibilità in ingresso:

    1. Modificare l'impostazione dei criteri Modelli amministrativi\Sistema\Kerberos\Specifica i server proxy KDC per i client Kerberos.

    2. Selezionare Enabled.

    3. In Opzioni selezionare Mostra.... Verrà visualizzata la finestra di dialogo Mostra contenuto.

      Screenshot della finestra di dialogo per abilitare

    4. Definire le impostazioni dei server proxy KDC usando i mapping come indicato di seguito. Sostituire l'ID tenant di Microsoft Entra per il placeholder your_Azure_AD_tenant_id. Si noti lo spazio che segue https e prima della chiusura di / nel mapping dei valori.

      Nome valore Valore
      KERBEROS.MICROSOFTONLINE.COM <https login.microsoftonline.com:443:your_Azure_AD_tenant_id/kerberos />

      Screenshot della finestra di dialogo

    5. Selezionare OK per chiudere la finestra di dialogo "Mostra contenuti".

    6. Selezionare Applica nella finestra di dialogo "Specifica i server proxy KDC per i client Kerberos".

Ruotare la chiave Kerberos

È possibile ruotare periodicamente la chiave Kerberos per l'account del servizio Microsoft Entra creato e l'oggetto di dominio attendibile a scopo di gestione.

Set-AzureAdKerberosServer -Domain $domain `
   -DomainCredential $domainCred `
   -UserPrincipalName $cloudUserName -SetupCloudTrust `
   -RotateServerKey

Una volta ruotata la chiave, sono necessarie diverse ore per propagare la chiave modificata tra i server KDC Kerberos. A causa di questo intervallo di distribuzione delle chiavi, è possibile ruotare la chiave una volta entro 24 ore. Se è necessario ruotare nuovamente la chiave entro 24 ore per qualsiasi motivo, ad esempio, subito dopo aver creato l'oggetto di dominio attendibile, è possibile aggiungere il parametro -Force:

Set-AzureAdKerberosServer -Domain $domain `
   -DomainCredential $domainCred `
   -UserPrincipalName $cloudUserName -SetupCloudTrust `
   -RotateServerKey -Force

Rimuovere l'oggetto di dominio attendibile

È possibile rimuovere l'oggetto dominio attendibile aggiunto usando il comando seguente:

Remove-AzureADKerberosServerTrustedDomainObject -Domain $domain `
   -DomainCredential $domainCred `
   -UserPrincipalName $cloudUserName

Questo comando rimuoverà solo l'oggetto di dominio attendibile. Se il dominio supporta l'autenticazione FIDO, è possibile rimuovere l'oggetto di dominio attendibile mantenendo l'account del servizio Microsoft Entra necessario per il servizio di autenticazione FIDO.

Rimuovere tutte le impostazioni Kerberos

È possibile rimuovere sia l'account del servizio Microsoft Entra sia l'oggetto di dominio attendibile usando il comando seguente:

Remove-AzureAdKerberosServer -Domain $domain `
   -DomainCredential $domainCred `
   -UserPrincipalName $cloudUserName

Passaggio successivo