Condividi tramite

Risolvere i problemi di autenticazione e autorizzazione basati sull'identità File di Azure (SMB)

  • Articolo

Questo articolo elenca i problemi comuni quando si usano condivisioni file di Azure SMB con l'autenticazione basata su identità. L'articolo descrive anche le possibili cause e risoluzioni per tali problemi. L'autenticazione basata su identità non è attualmente supportata per le condivisioni file di Azure NFS.

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

Errore durante l'esecuzione del modulo AzFilesHybrid

Quando si tenta di eseguire il modulo AzFilesHybrid, è possibile che venga visualizzato l'errore seguente:

Il client non dispone di un privilegio necessario.

Causa: le autorizzazioni di Active Directory non sono sufficienti

Questo problema si verifica perché non si dispone delle autorizzazioni di Active Directory (AD) necessarie per eseguire il modulo.

Soluzione

Fare riferimento ai privilegi di Active Directory o contattare l'amministratore di ACTIVE Directory per fornire i privilegi necessari.

Errore 5 durante il montaggio di una condivisione file di Azure

Quando si tenta di montare una condivisione file, è possibile che si riceva l'errore seguente:

Errore di sistema 5. Accesso negato.

Causa: le autorizzazioni a livello di condivisione non sono corrette

Se gli utenti finali accedono alla condivisione file di Azure tramite Dominio di Active Directory Services (AD DS) o l'autenticazione di Microsoft Entra Domain Services, l'accesso alla condivisione file non riesce e viene visualizzato l'errore "Accesso negato" se le autorizzazioni a livello di condivisione non sono corrette.

Note

Questo errore potrebbe essere causato da problemi diversi da autorizzazioni a livello di condivisione non corrette. Per informazioni su altre possibili cause e soluzioni, vedere Risolvere i problemi di connettività e accesso File di Azure.

Soluzione

Verificare che le autorizzazioni siano configurate correttamente:

  • Dominio di Active Directory Services (AD DS) vedere Assegnare autorizzazioni a livello di condivisione.

    Le assegnazioni di autorizzazioni a livello di condivisione sono supportate per i gruppi e gli utenti sincronizzati da Servizi di dominio Active Directory a Microsoft Entra ID usando la sincronizzazione cloud Microsoft Entra Connect o Microsoft Entra Connect. Verificare che i gruppi e gli utenti a cui sono assegnate autorizzazioni a livello di condivisione non siano gruppi "solo cloud" non supportati.

  • Microsoft Entra Domain Services vedere Assegnare autorizzazioni a livello di condivisione.

Errore AadDsTenantNotFound durante l'abilitazione dell'autenticazione di Microsoft Entra Domain Services per file di Azure "Impossibile individuare tenant attivi con ID tenant Microsoft Entra tenant-id"

Causa

L'errore AadDsTenantNotFound si verifica quando si tenta di abilitare l'autenticazione di Microsoft Entra Domain Services per File di Azure in un account di archiviazione in cui Microsoft Entra Domain Services non viene creato nel tenant Microsoft Entra della sottoscrizione associata.

Soluzione

Abilitare Microsoft Entra Domain Services nel tenant Microsoft Entra della sottoscrizione in cui è distribuito l'account di archiviazione. Sono necessari privilegi di amministratore del tenant di Microsoft Entra per creare un dominio gestito. Se non si è l'amministratore del tenant di Microsoft Entra, contattare l'amministratore e seguire le istruzioni dettagliate per creare e configurare un dominio gestito di Microsoft Entra Domain Services.

Non è possibile montare condivisioni file di Azure con credenziali di Active Directory

Procedura di autodiagnosi

Prima di tutto, assicurarsi di aver seguito i passaggi per abilitare File di Azure'autenticazione di Active Directory Domain Services.

In secondo luogo, provare a montare la condivisione file di Azure con la chiave dell'account di archiviazione. Se la condivisione non riesce a eseguire il montaggio, scaricare AzFileDiagnostics per convalidare l'ambiente in esecuzione del client. AzFileDiagnostics può rilevare configurazioni client incompatibili che potrebbero causare errori di accesso per File di Azure, fornire indicazioni prescrittive sulla correzione automatica e raccogliere le tracce di diagnostica.

In terzo luogo, è possibile eseguire il Debug-AzStorageAccountAuth cmdlet per eseguire un set di controlli di base sulla configurazione di ACTIVE Directory con l'utente ad connesso. Questo cmdlet è supportato nella versione AzFilesHybrid v 0.1.2+. È necessario eseguire questo cmdlet con un utente di AD che disponga dell'autorizzazione di proprietario per l'account di archiviazione di destinazione.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

Il cmdlet esegue questi controlli in sequenza e fornisce indicazioni per gli errori:

  1. CheckADObjectPasswordIsCorrect: assicurarsi che la password configurata nell'identità di AD che rappresenta l'account di archiviazione corrisponda a quella della chiave kerb1 o kerb2 dell'account di archiviazione. Se la password non è corretta, è possibile eseguire Update-AzStorageAccountADObjectPassword per reimpostare la password.
  2. CheckADObject: verificare che sia presente un oggetto in Active Directory che rappresenta l'account di archiviazione e che abbia il nome SPN corretto (nome dell'entità servizio). Se il nome SPN non è configurato correttamente, eseguire il Set-AD cmdlet restituito nel cmdlet di debug per configurare il nome SPN.
  3. CheckDomainJoined: verificare che il computer client sia aggiunto ad Active Directory. Se il computer non è aggiunto ad ACTIVE Directory, fare riferimento a Aggiungere un computer a un dominio per istruzioni di aggiunta a un dominio.
  4. CheckPort445Connectivity: controllare se la porta 445 è aperta per la connessione SMB. Se la porta 445 non è aperta, vedere lo strumento di risoluzione dei problemi AzFileDiagnostics per problemi di connettività con File di Azure.
  5. CheckSidHasAadUser: controllare se l'utente di ACTIVE Directory connesso è sincronizzato con Microsoft Entra ID. Per verificare se un utente di ACTIVE Directory specifico è sincronizzato con Microsoft Entra ID, è possibile specificare -UserName e -Domain nei parametri di input. Per un determinato SID, verifica se è associato un utente di Microsoft Entra.
  6. CheckAadUserHasSid: controllare se l'utente di ACTIVE Directory connesso è sincronizzato con Microsoft Entra ID. Per verificare se un utente di ACTIVE Directory specifico è sincronizzato con Microsoft Entra ID, è possibile specificare -UserName e -Domain nei parametri di input. Per un determinato utente di Microsoft Entra, controlla il suo SID. Per eseguire questo controllo, è necessario specificare il -ObjectId parametro , insieme all'ID oggetto dell'utente Microsoft Entra.
  7. CheckGetKerberosTicket: tentativo di ottenere un ticket Kerberos per connettersi all'account di archiviazione. Se non è presente un token Kerberos valido, eseguire il klist get cifs/storage-account-name.file.core.windows.net cmdlet ed esaminare il codice di errore per determinare la causa dell'errore di recupero del ticket.
  8. CheckStorageAccountDomainJoined: controllare se l'autenticazione di Active Directory è abilitata e le proprietà di Active Directory dell'account vengono popolate. In caso contrario, abilitare l'autenticazione di Active Directory Domain Services in File di Azure.
  9. CheckUserRbacAssignment: controllare se l'identità di Active Directory dispone dell'assegnazione di ruolo del controllo degli accessi in base al ruolo appropriata per fornire autorizzazioni a livello di condivisione per l'accesso File di Azure. In caso contrario, configurare l'autorizzazione a livello di condivisione. (supportato nelle versioni di AzFilesHybrid successive alla 0.2.3).
  10. CheckUserFileAccess: controllare se l'identità di ACTIVE Directory dispone dell'autorizzazione directory/file appropriata (ACL di Windows) per accedere a File di Azure. In caso contrario, configurare l'autorizzazione a livello di directory/file. Per eseguire questo controllo, è necessario specificare il -FilePath parametro , insieme al percorso del file montato a cui si vuole eseguire il debug dell'accesso. (supportato nelle versioni di AzFilesHybrid successive alla 0.2.3).
  11. CheckAadKerberosRegistryKeyIsOff: controllare se la chiave del Registro di sistema Kerberos di Microsoft Entra è disattivata. Se la chiave è attivata, eseguire reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 0 da un prompt dei comandi con privilegi elevati per disattivarla e quindi riavviare il computer. (Supportato in AzFilesHybrid v0.2.9+ versione)

Se si vuole solo eseguire una sottoselezione dei controlli precedenti, è possibile usare il -Filter parametro , insieme a un elenco delimitato da virgole di controlli da eseguire. Ad esempio, per eseguire tutti i controlli correlati alle autorizzazioni a livello di condivisione , usare i cmdlet di PowerShell seguenti:

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -Filter CheckSidHasAadUser,CheckUserRbacAssignment `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

Se la condivisione file è montata in X:e se si vuole eseguire solo il controllo relativo alle autorizzazioni a livello di file (ACL di Windows), è possibile eseguire i cmdlet di PowerShell seguenti:

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
$FilePath = "X:\example.txt"

Debug-AzStorageAccountAuth `
    -Filter CheckUserFileAccess `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -FilePath $FilePath `
    -Verbose

Impossibile montare condivisioni file di Azure con Microsoft Entra Kerberos

Procedura di autodiagnosi

Prima di tutto, assicurarsi di aver seguito i passaggi per abilitare l'autenticazione Kerberos di Microsoft Entra.

In secondo luogo, è possibile eseguire il Debug-AzStorageAccountAuth cmdlet per eseguire un set di controlli di base. Questo cmdlet è supportato per gli account di archiviazione configurati per l'autenticazione Kerberos di Microsoft Entra, in AzFilesHybrid v0.3.0+ versione.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose

Il cmdlet esegue questi controlli in sequenza e fornisce indicazioni per gli errori:

  1. CheckPort445Connectivity: controllare se la porta 445 è aperta per la connessione SMB. Se la porta 445 non è aperta, usare lo strumento di risoluzione dei problemi AzFileDiagnostics per problemi di connettività con File di Azure.
  2. CheckAADConnectivity: verificare la connettività entra. I montaggi SMB con autenticazione Kerberos possono non riuscire se il client non riesce a contattare Entra. Se questo controllo ha esito negativo, indica che si è verificato un errore di rete (ad esempio un problema di firewall o VPN).
  3. CheckEntraObject: verificare che sia presente un oggetto in Entra che rappresenta l'account di archiviazione e abbia il nome dell'entità servizio (SPN) corretto. Se il nome SPN non è configurato correttamente, disabilitare e riabilitare l'autenticazione Kerberos entra nell'account di archiviazione.
  4. CheckRegKey: controllare se la chiave del CloudKerberosTicketRetrieval Registro di sistema è abilitata. Questa chiave del Registro di sistema è necessaria per l'autenticazione Kerberos di Entra.
  5. CheckRealmMap: controllare se l'utente ha configurato i mapping dell'area di autenticazione che aggiungerebbero l'account a un'altra area di autenticazione Kerberos rispetto KERBEROS.MICROSOFTONLINE.COMa .
  6. CheckAdminConsent: controllare se all'entità servizio Entra è stato concesso il consenso amministratore per le autorizzazioni di Microsoft Graph necessarie per ottenere un ticket Kerberos.
  7. CheckWinHttpAutoProxySvc: verifica la presenza del servizio di individuazione automatica proxy Web WinHTTP (WinHttpAutoProxySvc) necessaria per l'autenticazione Kerberos di Microsoft Entra. Il relativo stato deve essere impostato su Running.
  8. CheckIpHlpScv: verificare la presenza del servizio helper IP (iphlpsvc) necessario per l'autenticazione Kerberos di Microsoft Entra. Il relativo stato deve essere impostato su Running.
  9. CheckFiddlerProxy: controllare se esiste un proxy Fiddler che impedisce l'autenticazione Kerberos di Microsoft Entra.
  10. CheckEntraJoinType: controllare se il computer è aggiunto al dominio Entra o al dominio Entra ibrido aggiunto. È un prerequisito per l'autenticazione Kerberos di Microsoft Entra.

Se si vuole solo eseguire una sottoselezione dei controlli precedenti, è possibile usare il -Filter parametro , insieme a un elenco delimitato da virgole di controlli da eseguire.

Non è possibile configurare le autorizzazioni a livello di directory/file (ACL di Windows) con Esplora file di Windows

Sintomo

Se si tenta di configurare ACL di Windows con Esplora file in una condivisione file montata, è possibile che venga rilevato uno dei sintomi descritti di seguito:

  • Dopo aver fatto clic su Modifica autorizzazione nella scheda Sicurezza, la procedura guidata Autorizzazioni non viene caricata.
  • Quando si tenta di selezionare un nuovo utente o gruppo, il percorso di dominio non visualizza il dominio di Active Directory Domain Services corretto.
  • Si usano più foreste Active Directory e viene visualizzato il messaggio di errore seguente: "I controller di dominio Active Directory necessari per trovare gli oggetti selezionati nei domini seguenti non sono disponibili. Verificare che i controller di dominio Active Directory siano disponibili e provare a selezionare di nuovo gli oggetti".

Soluzione

È consigliabile configurare le autorizzazioni a livello di directory/file usando icacls anziché usare Windows Esplora file.

Impossibile visualizzare UserPrincipalName (UPN) di un proprietario di file/directory in Esplora file

Sintomo

Esplora file visualizza l'identificatore di sicurezza (SID) di un proprietario di file/directory, ma non l'UPN.

Causa

Esplora file chiama un'API RPC direttamente nel server (File di Azure) per convertire il SID in un UPN. File di Azure non supporta questa API, quindi l'UPN non viene visualizzato.

Soluzione

In un client aggiunto a un dominio usare il comando di PowerShell seguente per visualizzare tutti gli elementi in una directory e il relativo proprietario, incluso l'UPN:

Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Errori durante l'esecuzione del cmdlet Join-AzStorageAccountForAuth

Errore: "Il servizio directory non è stato in grado di assegnare un identificatore relativo"

Questo errore potrebbe verificarsi se un controller di dominio che dispone del ruolo FSMO del master RID non è disponibile o è stato rimosso dal dominio e ripristinato dal backup. Verificare che tutti i controller di dominio siano in esecuzione e disponibili.

Errore: "Cannot bind positional parameters because no names were given" (Non è possibile associare i parametri posizionali perché non è stato indicato alcun nome)

Questo errore è probabilmente attivato da un errore di sintassi nel Join-AzStorageAccountforAuth comando . Controllare la presenza di errori di ortografia o di sintassi nel comando e verificare che sia installata la versione più recente del modulo AzFilesHybrid (https://github.com/Azure-Samples/azure-files-samples/releases).

File di Azure supporto dell'autenticazione di Active Directory Domain Services locale per la crittografia Kerberos AES-256

File di Azure supporta la crittografia Kerberos AES-256 per l'autenticazione di Active Directory Domain Services a partire dal modulo AzFilesHybrid v0.2.2. AES-256 è il metodo di crittografia consigliato ed è il metodo di crittografia predefinito a partire dal modulo AzFilesHybrid v0.2.5. Se è stata abilitata l'autenticazione di Active Directory Domain Services con una versione del modulo precedente a v0.2.2, è necessario scaricare il modulo AzFilesHybrid più recente ed eseguire lo script di PowerShell seguente. Se non è ancora stata abilitata l'autenticazione di Active Directory Domain Services nell'account di archiviazione, seguire queste indicazioni.

Importante

Se in precedenza si usava la crittografia RC4 e si aggiorna l'account di archiviazione per usare AES-256, è necessario eseguire klist purge sul client e quindi rimontare la condivisione file per ottenere nuovi ticket Kerberos con AES-256.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

Come parte dell'aggiornamento, il cmdlet ruota le chiavi Kerberos, che è necessario per passare a AES-256. Non è necessario ruotare indietro a meno che non si voglia rigenerare entrambe le password.

L'identità utente in precedenza con l'assegnazione di ruolo Proprietario o Collaboratore ha ancora accesso alla chiave dell'account di archiviazione

I ruoli Proprietario e Collaboratore dell'account di archiviazione consentono di elencare le chiavi dell'account di archiviazione. La chiave dell'account di archiviazione consente l'accesso completo ai dati dell'account di archiviazione, tra cui condivisioni file, BLOB, tabelle e code. Fornisce inoltre accesso limitato alle operazioni di gestione File di Azure tramite le API di gestione legacy esposte tramite l'API FileREST. Se si modificano le assegnazioni di ruolo, è consigliabile considerare che gli utenti rimossi dai ruoli Proprietario o Collaboratore potrebbero continuare ad avere accesso all'account di archiviazione tramite chiavi dell'account di archiviazione salvate.

Soluzione 1

È possibile risolvere facilmente questo problema ruotando le chiavi dell'account di archiviazione. È consigliabile ruotare i tasti uno alla volta, passando l'accesso da uno all'altro mentre vengono ruotati. Esistono due tipi di chiavi condivise fornite dall'account di archiviazione: le chiavi dell'account di archiviazione, che forniscono l'accesso con privilegi avanzati di amministratore ai dati dell'account di archiviazione e le chiavi Kerberos, che funzionano come segreto condiviso tra l'account di archiviazione e il controller di dominio di Active Directory di Windows Server per gli scenari di Active Directory di Windows Server.

Per ruotare le chiavi Kerberos di un account di archiviazione, vedere Aggiornare la password dell'identità dell'account di archiviazione in Active Directory Domain Services.

Passare all'account di archiviazione desiderato nel portale di Azure. Nel sommario per l'account di archiviazione desiderato selezionare Chiavi di accesso nell'intestazione Sicurezza e rete. Nel riquadro Tasto di scelta selezionare Ruota chiave sopra la chiave desiderata.

Screenshot che mostra il riquadro

Impostare le autorizzazioni API per un'applicazione appena creata

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 per completare la configurazione. È possibile configurare le autorizzazioni API dal portale di Azure seguendo questa procedura.

  1. Aprire ID Microsoft Entra.
  2. Selezionare Registrazioni app nel riquadro sinistro.
  3. Selezionare Tutte le applicazioni nel riquadro destro.
  4. Selezionare l'applicazione con il nome corrispondente a [Account di archiviazione] $storageAccountName.file.core.windows.net.
  5. Selezionare Autorizzazioni API nel riquadro sinistro.
  6. Selezionare Aggiungi autorizzazioni nella parte inferiore della pagina.
  7. Selezionare Concedi consenso amministratore per "DirectoryName".

Potenziali errori durante l'abilitazione dell'autenticazione Kerberos di Microsoft Entra per gli utenti ibridi

Quando si abilita l'autenticazione Kerberos di Microsoft Entra per gli account utente ibridi, potrebbero verificarsi gli errori seguenti.

Errore - Concedere il consenso amministratore disabilitato

In alcuni casi, l'amministratore di Microsoft Entra può disabilitare la possibilità di concedere il consenso amministratore alle applicazioni Microsoft Entra. Ecco uno screenshot dell'aspetto del portale di Azure.

Screenshot che mostra il pannello

In questo caso, chiedere all'amministratore di Microsoft Entra di concedere il consenso amministratore alla nuova applicazione Microsoft Entra. Per trovare e visualizzare gli amministratori, selezionare ruoli e amministratori, quindi selezionare Amministratore applicazione cloud.

Errore: "La richiesta ad Azure AD Graph non è riuscita con codice BadRequest"

Causa 1: i criteri di gestione delle applicazioni impediscono la creazione delle credenziali

Quando si abilita l'autenticazione Kerberos di Microsoft Entra, potrebbe verificarsi questo errore se vengono soddisfatte le condizioni seguenti:

  1. Si sta usando la funzionalità beta/anteprima dei criteri di gestione delle applicazioni.
  2. L'utente (o l'amministratore) ha impostato un criterio a livello di tenant che:
    • Non ha una data di inizio o ha una data di inizio precedente al 1° gennaio 2019.
    • Imposta una restrizione sulle password dell'entità servizio, che impedisce password personalizzate o imposta una durata massima della password inferiore a 365,5 giorni.

Attualmente non esiste alcuna soluzione alternativa per questo errore.

Causa 2: Esiste già un'applicazione per l'account di archiviazione

Questo errore può verificarsi anche se in precedenza è stata abilitata l'autenticazione Kerberos di Microsoft Entra tramite passaggi manuali di anteprima limitata. Per eliminare l'applicazione esistente, il cliente o l'amministratore IT può eseguire lo script seguente. L'esecuzione di questo script rimuoverà l'applicazione creata manualmente e consentirà alla nuova esperienza di creare e gestire automaticamente l'applicazione appena creata. Dopo aver avviato la connessione a Microsoft Graph, accedere all'applicazione Microsoft Graph Command Line Tools nel dispositivo e concedere le autorizzazioni all'app.

$storageAccount = "exampleStorageAccountName"
$tenantId = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
Install-Module Microsoft.Graph
Import-Module Microsoft.Graph
Connect-MgGraph -TenantId $tenantId -Scopes "User.Read","Application.Read.All"

$application = Get-MgApplication -Filter "DisplayName eq '${storageAccount}'"
if ($null -ne $application) {
   Remove-MgApplication -ObjectId $application.ObjectId
}

Errore - Password dell'entità servizio scaduta in Microsoft Entra ID

Se in precedenza è stata abilitata l'autenticazione Kerberos di Microsoft Entra tramite passaggi manuali di anteprima limitata, 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, sono disponibili due opzioni: ruotare la password dell'entità servizio in Microsoft Entra ogni sei mesi oppure seguire questa procedura per disabilitare Microsoft Entra Kerberos, eliminare l'applicazione esistente e riconfigurare Microsoft Entra Kerberos.

Assicurarsi di salvare le proprietà del dominio (domainName e domainGUID) prima di disabilitare Microsoft Entra Kerberos, perché saranno necessarie durante la riconfigurazione se si desidera configurare le autorizzazioni a livello di directory e file usando Windows Esplora file. Se le proprietà del dominio non sono state salvate, è comunque possibile configurare le autorizzazioni a livello di directory/file usando icacls come soluzione alternativa.

  1. Disabilitare Microsoft Entra Kerberos
  2. Eliminare l'applicazione esistente
  3. Riconfigurare Microsoft Entra Kerberos tramite il portale di Azure

Dopo aver riconfigurato Microsoft Entra Kerberos, la nuova esperienza creerà e gestirà automaticamente l'applicazione appena creata.

Errore 1326 - Il nome utente o la password non è corretto quando si usa il collegamento privato

Se ci si connette a un account di archiviazione tramite un endpoint privato o un collegamento privato usando l'autenticazione Kerberos di Microsoft Entra, quando si tenta di montare una condivisione file tramite net use o un altro metodo, al client vengono richieste le credenziali. È probabile che l'utente digita le credenziali in, ma le credenziali vengono rifiutate.

Causa

Questo perché il client SMB ha provato a usare Kerberos ma non è riuscito, quindi esegue il fallback all'uso dell'autenticazione NTLM e File di Azure non supporta l'uso dell'autenticazione NTLM per le credenziali di dominio. Il client non può ottenere un ticket Kerberos per l'account di archiviazione perché il nome di dominio completo del collegamento privato non è registrato in alcuna applicazione Microsoft Entra esistente.

Soluzione

La soluzione consiste nell'aggiungere l'FQDN privateLink all'applicazione Microsoft Entra dell'account di archiviazione prima di montare la condivisione file. È possibile aggiungere gli identifierUri necessari all'oggetto applicazione usando il portale di Azure seguendo questa procedura.

  1. Aprire ID Microsoft Entra.

  2. Selezionare Registrazioni app nel riquadro sinistro.

  3. Selezionare Tutte le applicazioni.

  4. Selezionare l'applicazione con il nome corrispondente a [Account di archiviazione] $storageAccountName.file.core.windows.net.

  5. Selezionare Manifesto nel riquadro sinistro.

  6. Copiare e incollare il contenuto esistente in modo da avere una copia duplicata.

  7. Modificare il manifesto JSON. Per ogni <storageAccount>.file.core.windows.net voce, aggiungere una voce corrispondente <storageAccount>.privatelink.file.core.windows.net . Ad esempio, se il manifesto ha il valore seguente per identifierUris:

    "identifierUris": [
    "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
    "HOST/<storageaccount>.file.core.windows.net",
    "CIFS/<storageaccount>.file.core.windows.net",
    "HTTP/<storageaccount>.file.core.windows.net"
],

    È quindi necessario modificare il identifierUris campo nel modo seguente:

    "identifierUris": [
    "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
    "HOST/<storageaccount>.file.core.windows.net",
    "CIFS/<storageaccount>.file.core.windows.net",
    "HTTP/<storageaccount>.file.core.windows.net",

    "api://<tenantId>/HOST/<storageaccount>.privatelink.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.privatelink.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.privatelink.file.core.windows.net",
    "HOST/<storageaccount>.privatelink.file.core.windows.net",
    "CIFS/<storageaccount>.privatelink.file.core.windows.net",
    "HTTP/<storageaccount>.privatelink.file.core.windows.net"
],

  8. Esaminare il contenuto e selezionare Salva per aggiornare l'oggetto applicazione con i nuovi identificatoriUri.

  9. Aggiornare tutti i riferimenti DNS interni in modo che puntino al collegamento privato.

  10. Riprovare a montare la condivisione.

Errore AADSTS50105

La richiesta è stata interrotta dall'errore seguente AADSTS50105:

L'amministratore ha configurato l'applicazione "Nome applicazione aziendale" per bloccare gli utenti, a meno che non venga concesso in modo specifico (assegnato) l'accesso all'applicazione. L'utente connesso '{EmailHidden}' è bloccato perché non è un membro diretto di un gruppo con accesso, né ha avuto accesso direttamente assegnato da un amministratore. Contattare l'amministratore per assegnare l'accesso a questa applicazione.

Causa

Se si configura l'assegnazione richiesta per l'applicazione aziendale corrispondente, non sarà possibile ottenere un ticket Kerberos e i log di accesso di Microsoft Entra visualizzeranno un errore anche se all'applicazione sono assegnati utenti o gruppi.

Soluzione

Non selezionare Assegnazione richiesta per l'applicazione Microsoft Entra per l'account di archiviazione perché non vengono popolati i diritti nel ticket Kerberos restituito al richiedente. Per altre informazioni, vedere Errore AADSTS50105 - L'utente connesso non è assegnato a un ruolo per l'applicazione.

Vedi anche

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.