Risolvere i problemi di autenticazione e autorizzazione basati sull'identità File di Azure (SMB)
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.
Nota
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 microsoft Entra Connect Sync o la sincronizzazione cloud Microsoft Entra Connect. 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 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:
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.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 ilSet-AD
cmdlet restituito nel cmdlet di debug per configurare il nome SPN.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.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.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.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.CheckGetKerberosTicket
: tentativo di ottenere un ticket Kerberos per connettersi all'account di archiviazione. Se non è presente un token Kerberos valido, eseguire ilklist 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.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.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).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).CheckAadKerberosRegistryKeyIsOff
: controllare se la chiave del Registro di sistema Kerberos di Microsoft Entra è disattivata. Se la chiave è attivata, eseguirereg 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:
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.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).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.CheckRegKey
: controllare se la chiave delCloudKerberosTicketRetrieval
Registro di sistema è abilitata. Questa chiave del Registro di sistema è necessaria per l'autenticazione Kerberos di Entra.CheckRealmMap
: controllare se l'utente ha configurato i mapping dell'area di autenticazione che aggiungerebbero l'account a un'altra area di autenticazione Kerberos rispettoKERBEROS.MICROSOFTONLINE.COM
a .CheckAdminConsent
: controllare se all'entità servizio Entra è stato concesso il consenso amministratore per le autorizzazioni di Microsoft Graph necessarie per ottenere un ticket Kerberos.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 suRunning
.CheckIpHlpScv
: verifica la presenza del servizio helper IP (iphlpsvc) necessaria per l'autenticazione Kerberos di Microsoft Entra. Il relativo stato deve essere impostato suRunning
.
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.
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, sarà necessario scaricare il modulo AzFilesHybrid più recente ed eseguire PowerShell di seguito. 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, contenitori BLOB, tabelle e code e 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 possono continuare a mantenere l'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.
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.
- Aprire ID Microsoft Entra.
- Selezionare Registrazioni app nel riquadro sinistro.
- Selezionare Tutte le applicazioni nel riquadro destro.
- Selezionare l'applicazione con il nome corrispondente a [Account di archiviazione] $storageAccountName.file.core.windows.net.
- Selezionare Autorizzazioni API nel riquadro sinistro.
- Selezionare Aggiungi autorizzazioni nella parte inferiore della pagina.
- 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 di ciò che può essere simile al portale di Azure.
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:
- Si sta usando la funzionalità beta/anteprima dei criteri di gestione delle applicazioni.
- 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.
- Disabilitare Microsoft Entra Kerberos
- Eliminare l'applicazione esistente
- 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.
Aprire ID Microsoft Entra.
Selezionare Registrazioni app nel riquadro sinistro.
Selezionare Tutte le applicazioni.
Selezionare l'applicazione con il nome corrispondente a [Account di archiviazione] $storageAccountName.file.core.windows.net.
Selezionare Manifesto nel riquadro sinistro.
Copiare e incollare il contenuto esistente in modo da avere una copia duplicata.
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 peridentifierUris
:"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" ],
Esaminare il contenuto e selezionare Salva per aggiornare l'oggetto applicazione con i nuovi identificatoriUri.
Aggiornare tutti i riferimenti DNS interni in modo che puntino al collegamento privato.
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
- Risolvere i problemi relativi ad Azure AD
- Risolvere i problemi relativi alle prestazioni di File di Azure
- Risolvere i problemi di connettività File di Azure (SMB)
- Risolvere File di Azure problemi SMB generali in Linux
- Risolvere File di Azure problemi NFS generali in Linux
- Risolvere i problemi di Sincronizzazione file di Azure
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.