Condividi tramite

Risolvere i problemi di autenticazione e autorizzazione basati sull'identità di 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à. Fornisce anche possibili cause e soluzioni per questi 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), LRS/ZRS
Condivisioni file standard (GPv2), GRS/GZRS
Condivisioni file Premium (FileStorage), LRS/ZRS

Errore durante l'esecuzione del modulo AzFilesHybrid

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

Un privilegio obbligatorio non è mantenuto dal client.

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, potrebbe essere visualizzato l'errore seguente:

Si è verificato l'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 usando Active Directory Domain Services (AD DS) o l'autenticazione di Microsoft Entra Domain Services, l'accesso alla condivisione file non riesce con l'errore "Accesso negato" se le autorizzazioni a livello di condivisione non sono corrette.

Nota

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

Soluzione

Verificare che le autorizzazioni siano configurate correttamente:

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

    Le assegnazioni di autorizzazioni a livello di condivisione sono supportate per gruppi e utenti sincronizzati da Active Directory Domain Services a Microsoft Entra ID usando Microsoft Entra Connect Sync o Microsoft Entra Connect cloud sync. Verificare che i gruppi e gli utenti a cui vengono 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 nell'abilitazione dell'autenticazione di Microsoft Entra Domain Services per File di Azure "Impossibile individuare i 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 di Microsoft Entra della sottoscrizione associata.

Soluzione

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

Non è possibile montare condivisioni file di Azure con le credenziali di ACTIVE Directory

Procedura di auto-diagnostica

Prima di tutto, assicurarsi di aver seguito i passaggi per abilitare l'autenticazione di Ad DS di File di Azure.

In secondo luogo, provare a montare la condivisione file di Azure con la chiave dell'account di archiviazione. Se il montaggio della condivisione non riesce, 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 sull'auto-correzione 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 di ACTIVE Directory connesso. Questo cmdlet è supportato nella versione AzFilesHybrid v0.1.2+. È necessario eseguire questo cmdlet con un utente di Active Directory che dispone 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 Active Directory 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 ha il nome SPN (nome dell'entità servizio) corretto. Se l'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 al dominio ad AD. Se il computer non è aggiunto a un dominio di Active Directory, vedere Aggiungere un computer a un dominio per istruzioni di aggiunta al dominio.
  4. CheckPort445Connectivity: controllare se la porta 445 è aperta per la connessione SMB. Se la porta 445 non è aperta, fare riferimento allo strumento di risoluzione dei problemi AzFileDiagnostics per i problemi di connettività con File di Azure.
  5. CheckSidHasAadUser: controllare se l'utente di ACTIVE Directory connesso è sincronizzato con l'ID Microsoft Entra. Se si vuole verificare se un utente di Active Directory specifico è sincronizzato con Microsoft Entra ID, è possibile specificare e -UserName-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 l'ID Microsoft Entra. Se si vuole verificare se un utente di Active Directory specifico è sincronizzato con Microsoft Entra ID, è possibile specificare e -UserName-Domain nei parametri di input. Per un determinato utente di Microsoft Entra, controlla il relativo SID. Per eseguire questo controllo, è necessario specificare il -ObjectId parametro , insieme all'ID oggetto dell'utente di 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 è stata 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 ha l'assegnazione di ruolo controllo degli accessi in base al ruolo appropriata per fornire le autorizzazioni a livello di condivisione per accedere a File di Azure. In caso contrario, configurare l'autorizzazione a livello di condivisione. (Supportato in AzFilesHybrid v0.2.3+ versione)
  10. CheckUserFileAccess: controllare se l'identità di Active Directory dispone dell'autorizzazione appropriata per la directory/file (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 in AzFilesHybrid v0.2.3+ versione)
  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 semplicemente eseguire una sottoselezione dei controlli precedenti, è possibile utilizzare il -Filter parametro , insieme a un elenco delimitato da virgole di controlli da eseguire. Ad esempio, per eseguire tutti i controlli relativi alle autorizzazioni a livello di condivisione ( RBAC), 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 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 auto-diagnostica

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 nella versione AzFilesHybrid v0.3.0+.

$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 i problemi di connettività con File di Azure.
  2. CheckAADConnectivity: verificare la connettività di Entra. I montaggi SMB con autenticazione Kerberos possono non riuscire se il client non riesce a contattare Entra. Se questo controllo non riesce, indica che si verifica 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 ha il nome dell'entità servizio (SPN) corretto. Se l'SPN non è configurato correttamente, disabilitare e riabilitare l'autenticazione Kerberos Entra nell'account di archiviazione.
  4. CheckRegKey: verificare se la chiave del CloudKerberosTicketRetrieval Registro di sistema è abilitata. Questa chiave del Registro di sistema è necessaria per l'autenticazione Kerberos 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 di KERBEROS.MICROSOFTONLINE.COM.
  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.

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

Impossibile configurare le autorizzazioni a livello di directory/file (ACL di Windows) con Esplora file di Windows

Sintomo

È possibile che si verifichi uno dei sintomi descritti di seguito durante il tentativo di configurare gli elenchi di controllo di accesso di Windows con Esplora file in una condivisione file montata:

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

Soluzione

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

Errori durante l'esecuzione di Join-AzStorageAccountForAuth cmdlet

Errore: "Il servizio directory non è riuscito ad allocare un identificatore relativo"

Questo errore può verificarsi se un controller di dominio che contiene il ruolo FSMO 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: "Impossibile associare parametri posizionari perché non sono stati specificati nomi"

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

Supporto dell'autenticazione di Ad DS locale in File di Azure 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 inferiore alla versione 0.2.2, sarà necessario scaricare il modulo AzFilesHybrid più recente ed eseguire PowerShell seguente. Se l'autenticazione di Active Directory Domain Services non è ancora stata abilitata nell'account di archiviazione, seguire queste indicazioni.

Importante

Se in precedenza si usava la crittografia RC4 e si aggiornava l'account di archiviazione per l'uso di AES-256, è necessario eseguire klist purge nel 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 ad AES-256. Non è necessario ruotare indietro a meno che non si voglia rigenerare entrambe le password.

L'identità utente che in precedenza aveva l'assegnazione del ruolo Proprietario o Collaboratore ha ancora l'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, contenitori BLOB, tabelle e code e accesso limitato alle operazioni di gestione di 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 a mantenere l'accesso all'account di archiviazione tramite le 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 man mano che 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 di amministratore con privilegi avanzati ai dati dell'account di archiviazione, e le chiavi Kerberos, che fungono da segreto condiviso tra l'account di archiviazione e il controller di dominio di Windows Server Active Directory per gli scenari di Windows Server Active Directory.

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 dell'account di archiviazione desiderato selezionare Chiavi di accesso nell'intestazione Sicurezza e rete . Nel riquadro Chiave di accesso 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 Microsoft Entra ID.
  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. Di seguito è riportato lo screenshot dell'aspetto di questo aspetto nel 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 applicazioni 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, è possibile che si verifichi questo errore se vengono soddisfatte le condizioni seguenti:

  1. Si usa 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 per le password dell'entità servizio, che non consente password personalizzate o imposta una durata massima delle password inferiore a 365,5 giorni.

Attualmente non è disponibile alcuna soluzione alternativa per questo errore.

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

È anche possibile che si verifichi questo errore se in precedenza è stata abilitata l'autenticazione Kerberos di Microsoft Entra tramite passaggi di anteprima limitati manuali. Per eliminare l'applicazione esistente, il cliente o il relativo amministratore IT può eseguire lo script seguente. L'esecuzione di questo script rimuoverà l'applicazione creata manualmente precedente 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 Strumenti da riga di comando di Microsoft Graph 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 : la password dell'entità servizio è scaduta nell'ID Microsoft Entra

Se in precedenza è stata abilitata l'autenticazione Kerberos di Microsoft Entra tramite passaggi di anteprima limitati manuali, la password per l'entità servizio dell'account di archiviazione scadrà ogni sei mesi. Una volta scaduta la password, gli utenti non saranno in grado di ottenere i 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 Esplora file di Windows. Se non sono state salvate le proprietà del dominio, è 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: nome utente o password non corretto quando si usa un collegamento privato

Se ci si connette a un account di archiviazione tramite un endpoint privato o un collegamento privato tramite 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 digiti le credenziali in , ma le credenziali vengono rifiutate.

Causa

Il motivo è che il client SMB ha tentato di usare Kerberos ma non è riuscito, quindi rientra nell'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 il nome di dominio completo privateLink all'applicazione Microsoft Entra dell'account di archiviazione prima di montare la condivisione file. È possibile aggiungere gli identifierUris necessari all'oggetto applicazione usando il portale di Azure seguendo questa procedura.

  1. Aprire Microsoft Entra ID.

  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"
],

    Modificare quindi 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 il nuovo identifierUris.

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

  10. Riprovare a montare la condivisione.

Errore AADSTS50105

La richiesta è stata interrotta dal AADSTS50105 di errore seguente:

L'amministratore ha configurato l'applicazione "Enterprise application name" per bloccare gli utenti, a meno che non gli venga concesso l'accesso specifico (assegnato) 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 "assegnazione obbligatoria" per l'applicazione aziendale corrispondente, non sarà possibile ottenere un ticket Kerberos e i log di accesso di Microsoft Entra mostreranno un errore anche se gli utenti o i gruppi sono assegnati all'applicazione.

Soluzione

Non selezionare Assegnazione necessaria 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 Error AADSTS50105 - L'utente connesso non è assegnato a un ruolo per l'applicazione.

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