Share via

Risolvere File di Azure problemi di autenticazione e autorizzazione basati su identità (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 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 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 Servizi di dominio Active Directory 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 Microsoft Entra Domain Services per File di Azure "Impossibile individuare i tenant attivi con ID tenant Microsoft Entra tenant-id"

Causa

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

Soluzione

Abilitare Microsoft Entra Domain Services nel tenant Microsoft Entra della sottoscrizione in cui è distribuito l'account di archiviazione. Per creare un dominio gestito sono necessari privilegi di amministratore del tenant Microsoft Entra. Se non si è l'amministratore del tenant Microsoft Entra, contattare l'amministratore e seguire le istruzioni dettagliate per creare e configurare un dominio gestito 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 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 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: verificare che la porta 445 sia 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: verificare che l'utente di ACTIVE Directory connesso sia 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 SID specificato, verifica se è associato un utente Microsoft Entra.
  6. CheckAadUserHasSid: verificare che l'utente di ACTIVE Directory connesso sia 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 Microsoft Entra, controlla il relativo 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 è 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 o il file (ACL 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: verificare se la chiave del Registro di sistema Kerberos 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 configurare le autorizzazioni a livello di directory/file (ACL windows) con Windows Esplora file

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é Windows Esplora file.

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

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 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 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 Windows Server Active Directory per Windows Server Active Directory Scenari.

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 Microsoft Entra'autenticazione Kerberos, è necessario concedere esplicitamente il consenso amministratore alla nuova applicazione Microsoft Entra registrata nel tenant 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 Microsoft Entra per gli utenti ibridi

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

Errore - Concedere il consenso amministratore disabilitato

In alcuni casi, Microsoft Entra amministratore 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 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 Microsoft Entra'autenticazione Kerberos, potrebbe verificarsi 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

Questo errore può verificarsi anche se in precedenza è stata abilitata Microsoft Entra l'autenticazione Kerberos 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 in Microsoft Entra ID

Se in precedenza è stata abilitata Microsoft Entra'autenticazione Kerberos 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 ridurre 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à di 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 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 usando Microsoft Entra'autenticazione Kerberos, 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

Ciò è dovuto al fatto 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 Microsoft Entra log di accesso mostrerà un errore anche se gli utenti o i gruppi sono assegnati all'applicazione.

Soluzione

Non selezionare Assegnazione necessaria per Microsoft Entra'applicazione 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.