Risolvere i problemi relativi all'accesso e alle autorizzazioni
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
A causa dell'ampia struttura di sicurezza e autorizzazione di Azure DevOps, potrebbe essere necessario esaminare il motivo per cui un utente non ha accesso a un progetto, a un servizio o a una funzionalità prevista. Trovare indicazioni dettagliate per comprendere e risolvere i problemi che un utente potrebbe riscontrare durante la connessione a un progetto o l'accesso a un servizio o a una funzionalità di Azure DevOps.
Prima di usare questa guida, è consigliabile acquisire familiarità con il contenuto seguente:
- Introduzione alle autorizzazioni, all'accesso e ai gruppi di sicurezza
- Autorizzazioni predefinite e riferimento rapido per l'accesso.
Suggerimento
Quando si crea un gruppo di sicurezza di Azure DevOps, etichettarlo chiaramente per indicare se è destinato a limitare l'accesso.
È possibile impostare le autorizzazioni ai livelli seguenti:
- Livello oggetto
- Livello progetto
- Livello di raccolta dell'organizzazione o del progetto
- Ruolo di sicurezza
- Ruolo di amministratore del team
Problemi comuni di accesso e autorizzazione
Vedere i motivi più comuni per cui un membro del progetto non può accedere a un progetto, a un servizio o a una funzionalità:
| Problema | Azione di risoluzione dei problemi |
|---|---|
| Il livello di accesso non supporta l'accesso al servizio o alla funzionalità. | Per determinare se è la causa, determinare il livello di accesso e lo stato della sottoscrizione dell'utente. |
| L'appartenenza all'interno di un gruppo di sicurezza non supporta l'accesso a una funzionalità o è stata negata esplicitamente l'autorizzazione a una funzionalità. | Per determinare se è la causa, tracciare un'autorizzazione. |
| All'utente è stata concessa di recente l'autorizzazione, ma il client necessita di un aggiornamento per riconoscere le modifiche. | Chiedere all'utente di aggiornare o rivalutare le autorizzazioni. |
| L'utente sta tentando di esercitare una funzionalità concessa solo a un amministratore del team per un team specifico, ma non viene concesso tale ruolo. | Per aggiungerli al ruolo, vedere Aggiungere, rimuovere l'amministratore del team. |
| L'utente non ha abilitato una funzionalità di anteprima. | Chiedere all'utente di aprire le funzionalità di anteprima e determinare lo stato di on/off per la funzionalità specifica. Per altre informazioni, vedere Gestire le funzionalità di anteprima. |
| Il membro del progetto è stato aggiunto a un gruppo di sicurezza con ambito limitato, ad esempio il gruppo Project-Scoped Users. | Per determinare se è la causa, cercare le appartenenze ai gruppi di sicurezza dell'utente. |
Problemi di accesso e autorizzazione meno comuni
I motivi meno comuni per l'accesso limitato sono i casi in cui si è verificato uno degli eventi seguenti:
| Problema | Azione di risoluzione dei problemi |
|---|---|
| Un amministratore del progetto ha disabilitato un servizio. In questo caso, nessuno ha accesso al servizio disabilitato. | Per determinare se un servizio è disabilitato, vedere Attivare o disattivare un servizio Azure DevOps. |
| Un amministratore raccolta progetti ha disabilitato una funzionalità di anteprima, che la disabilita per tutti i membri del progetto nell'organizzazione. | Vedere Gestire le funzionalità di anteprima. |
| Le regole di gruppo che regolano il livello di accesso o l'appartenenza al progetto dell'utente limitano l'accesso. | Vedere Determinare il livello di accesso e lo stato della sottoscrizione di un utente. |
| Le regole personalizzate sono state definite per il flusso di lavoro di un tipo di elemento di lavoro. | vedere Regole applicate a un tipo di elemento di lavoro che limita l'operazione di selezione. |
Determinare il livello di accesso e lo stato della sottoscrizione di un utente
È possibile assegnare utenti o gruppi di utenti a uno dei livelli di accesso seguenti:
- Parte interessata
- Di base
- Piani Basic + Test
- Sottoscrizione di Visual Studio
Per altre informazioni sulla limitazione dei livelli di accesso in Azure DevOps, vedere Livelli di accesso supportati.
Per usare le funzionalità di Azure DevOps, gli utenti devono essere aggiunti a un gruppo di sicurezza con le autorizzazioni appropriate e avere accesso al portale Web. Le limitazioni delle funzionalità si basano sul livello di accesso e sul gruppo di sicurezza dell'utente.
Gli utenti possono perdere l'accesso per i motivi seguenti:
| Motivo della perdita di accesso | Azione di risoluzione dei problemi |
|---|---|
| La sottoscrizione di Visual Studio dell'utente è scaduta. | Nel frattempo, l'utente può lavorare come stakeholder oppure concedere all'utente l'accesso Basic fino a quando l'utente non rinnova la propria sottoscrizione. Dopo che l'utente ha eseguito l'accesso, Azure DevOps ripristina automaticamente l'accesso. |
| La sottoscrizione di Azure usata per la fatturazione non è più attiva. | Tutti gli acquisti effettuati con questa sottoscrizione sono interessati, incluse le sottoscrizioni di Visual Studio. Per risolvere questo problema, visitare il portale degli account di Azure. |
| La sottoscrizione di Azure usata per la fatturazione è stata rimossa dall'organizzazione. | Altre informazioni sul collegamento dell'organizzazione |
In caso contrario, il primo giorno del mese di calendario, gli utenti che non hanno eseguito l'accesso all'organizzazione per la prima volta perdono l'accesso. Se l'organizzazione ha utenti che non hanno più bisogno di accesso, rimuoverli dall'organizzazione.
Per altre informazioni sulle autorizzazioni, vedere Autorizzazioni e gruppi e la guida alla ricerca delle autorizzazioni.
Tracciare un'autorizzazione
Usare la traccia delle autorizzazioni per determinare il motivo per cui le autorizzazioni di un utente non consentono l'accesso a una funzionalità o a una funzione specifica. Informazioni su come un utente o un amministratore può analizzare l'ereditarietà delle autorizzazioni. Per tracciare un'autorizzazione dal portale Web, aprire la pagina relativa all'autorizzazione o alla sicurezza per il livello corrispondente. Per altre informazioni, vedere Richiedere un aumento dei livelli di autorizzazione.
Se un utente presenta problemi di autorizzazioni e si usano gruppi di sicurezza predefiniti o gruppi personalizzati per le autorizzazioni, usare la traccia per analizzare la provenienza di tali autorizzazioni. I problemi relativi alle autorizzazioni potrebbero essere causati da modifiche ritardate. La propagazione delle appartenenze ai gruppi o delle autorizzazioni di Microsoft Entra in Azure DevOps può richiedere fino a 1 ora. Se un utente presenta problemi che non vengono risolti immediatamente, attendere un giorno per verificare se si risolvono. Per altre informazioni sulla gestione degli utenti e degli accessi, vedere Gestire utenti e accesso in Azure DevOps.
Se un utente ha problemi di autorizzazioni e si usano gruppi di sicurezza predefiniti o gruppi personalizzati per le autorizzazioni, è possibile esaminare la provenienza di tali autorizzazioni usando la traccia delle autorizzazioni. I problemi relativi alle autorizzazioni potrebbero essere dovuti al fatto che l'utente non ha il livello di accesso necessario.
Gli utenti possono ricevere le autorizzazioni valide direttamente o tramite gruppi.
Completare i passaggi seguenti per consentire agli amministratori di capire da dove provengono esattamente tali autorizzazioni e modificarle in base alle esigenze.
Selezionare Impostazioni progetto>Autorizzazioni>Utenti e quindi selezionare l'utente.
A questo momento dovrebbe essere disponibile una visualizzazione specifica dell'utente che mostra le autorizzazioni di cui dispongono.
Per tracciare il motivo per cui un utente ha o non dispone delle autorizzazioni elencate, selezionare l'icona delle informazioni accanto all'autorizzazione in questione.
La traccia risultante consente di sapere come ereditano l'autorizzazione elencata. È quindi possibile modificare le autorizzazioni dell'utente modificando le autorizzazioni fornite ai gruppi in cui si trovano.
Selezionare Sicurezza impostazioni>progetto e quindi immettere il nome utente nella casella di filtro.
A questo momento dovrebbe essere disponibile una visualizzazione specifica dell'utente che mostra le autorizzazioni di cui dispongono.
Tracciare il motivo per cui un utente fa o non dispone di alcuna delle autorizzazioni elencate. Passare il puntatore del mouse sull'autorizzazione e quindi scegliere Perché.
La traccia risultante consente di sapere come ereditano l'autorizzazione elencata. È quindi possibile modificare le autorizzazioni dell'utente modificando le autorizzazioni fornite ai gruppi in cui si trovano.
Per altre informazioni, vedere Gestire l'accesso a funzionalità e funzioni specifiche o Richiedere un aumento dei livelli di autorizzazione.
Aggiornare o rivalutare le autorizzazioni
Vedere lo scenario seguente in cui potrebbe essere necessario aggiornare o rivalutare le autorizzazioni.
Problema
Gli utenti vengono aggiunti a un gruppo Azure DevOps o Microsoft Entra. Questa azione concede l'accesso ereditato a un'organizzazione o a un progetto. Ma non ottengono immediatamente l'accesso. Gli utenti devono attendere o disconnettersi, chiudere il browser e quindi accedere di nuovo per aggiornare le autorizzazioni.
Gli utenti vengono aggiunti a un gruppo di Azure DevOps. Questa azione concede l'accesso ereditato a un'organizzazione o a un progetto. Ma non ottengono immediatamente l'accesso. Gli utenti devono attendere o disconnettersi, chiudere il browser e quindi accedere di nuovo per aggiornare le autorizzazioni.
Soluzione
Passare a 
Impostazioni utente>Autorizzazioni>Rivalutare le autorizzazioni. Questa funzione rivaluta le appartenenze ai gruppi e le autorizzazioni e quindi tutte le modifiche recenti diventano effettive immediatamente.
Regole applicate a un tipo di elemento di lavoro che limitano le operazioni di selezione
Prima di personalizzare un processo, è consigliabile consultare Configurare e personalizzare Azure Boards, che fornisce indicazioni su come personalizzare Azure Boards per soddisfare le esigenze aziendali.
Per altre informazioni sulle regole relative al tipo di elemento di lavoro che si applicano alle operazioni di limitazione, vedere:
- Applicare regole agli stati del flusso di lavoro (processo di ereditarietà)
- Scenari di regole di esempio
- Definire i percorsi area e assegnarli a un team
Nascondere le impostazioni dell'organizzazione agli utenti
Se un utente è limitato a visualizzare solo i progetti o non può accedere alle impostazioni dell'organizzazione, le informazioni seguenti potrebbero spiegare il motivo. Per impedire agli utenti di accedere alle impostazioni dell'organizzazione, abilitare la funzionalità Limita visibilità utente e collaborazione a progetti specifici. Per altre informazioni, tra cui callout importanti correlati alla sicurezza, vedere Gestire l'organizzazione, Limitare la visibilità degli utenti per i progetti e altro ancora.
Esempi di utenti con restrizioni includono stakeholder, utenti guest di Microsoft Entra o membri di un gruppo di sicurezza. Dopo l'abilitazione, qualsiasi utente o gruppo aggiunto al gruppo Utenti con ambito progetto non può accedere alle pagine delle impostazioni dell'organizzazione, ad eccezione di Panoramica e progetti. Possono accedere solo ai progetti a cui vengono aggiunti.
Esempi di utenti con restrizioni includono stakeholder o membri di un gruppo di sicurezza. Una volta abilitato, qualsiasi utente o gruppo aggiunto al gruppo Utenti con ambito progetto non può accedere alle pagine Impostazioni organizzazione, ad eccezione di Panoramica e progetti. Possono accedere solo ai progetti a cui vengono aggiunti.
Per altre informazioni, vedere Gestire l'organizzazione, Limitare la visibilità degli utenti per i progetti e altro ancora.
Visualizzare, aggiungere e gestire le autorizzazioni con l'interfaccia della riga di comando
È possibile visualizzare, aggiungere e gestire le autorizzazioni a un livello granulare con i az devops security permission comandi. Per altre informazioni, vedere Gestire le autorizzazioni con lo strumento da riga di comando.
Regole di gruppo con autorizzazioni minori
I tipi di regole di gruppo sono classificati nell'ordine seguente: Sottoscrittore > Basic + Piani > di test stakeholder di base > . Gli utenti ricevono sempre il livello di accesso più alto disponibile per tutte le regole di gruppo, incluse tutte le sottoscrizioni di Visual Studio (VS).
Nota
- Le modifiche apportate ai lettori del progetto tramite regole di gruppo non vengono mantenute. Per modificare i lettori del progetto, prendere in considerazione metodi alternativi, ad esempio l'assegnazione diretta o i gruppi di sicurezza personalizzati.
- Esaminare regolarmente le regole elencate nella scheda "Regole di gruppo" della pagina "Utenti". Le modifiche apportate all'appartenenza al gruppo Microsoft Entra ID verranno visualizzate nella successiva rivalutazione delle regole di gruppo, che possono essere eseguite su richiesta, quando una regola di gruppo viene modificata o automaticamente ogni 24 ore. Azure DevOps aggiorna l'appartenenza al gruppo Microsoft Entra ogni ora, ma potrebbero essere necessarie fino a 24 ore prima che Microsoft Entra ID aggiorni l'appartenenza dinamica al gruppo.
Vedere gli esempi seguenti, che illustrano come i fattori di rilevamento dei sottoscrittori nelle regole di gruppo.
Esempio 1: La regola di gruppo offre un accesso maggiore
Se si ha una sottoscrizione di VS Pro e si è in una regola di gruppo che fornisce i piani di base e test, cosa accade?
Previsto: si ottengono piani di base e test perché ciò che la regola di gruppo fornisce è maggiore della sottoscrizione. L'assegnazione di regole di gruppo fornisce sempre l'accesso maggiore, anziché limitare l'accesso.
Esempio 2: La regola di gruppo consente lo stesso accesso
Si dispone di una sottoscrizione di Visual Studio Test Pro e si trova in una regola di gruppo che fornisce i piani di base e test, cosa accade?
Previsto: viene rilevato come sottoscrittore di Visual Studio Test Pro, perché l'accesso è uguale alla regola di gruppo. Si paga già per Visual Studio Test Pro, quindi non si vuole pagare di nuovo.
Usare GitHub
Vedere le informazioni seguenti sulla risoluzione dei problemi per la distribuzione del codice in Azure DevOps con GitHub.
Problema
Non è possibile portare il resto del team nell'organizzazione e nel progetto, nonostante l'aggiunta come membri. Ricevono messaggi di posta elettronica, ma durante l'accesso ricevono un errore 401.
Soluzione
È possibile che sia stato eseguito l'accesso ad Azure DevOps con un'identità errata. Effettua i passaggi seguenti:
Chiudere tutti i browser, inclusi i browser che non eseguono Azure DevOps.
Aprire una sessione di esplorazione privata o in incognito.
Passare all'URL seguente: https://aka.ms/vssignout.
Viene visualizzato un messaggio "Disconnetti in corso". Dopo la disconnessione, si viene reindirizzati a
dev.azure.microsoft.com.Accedere di nuovo ad Azure DevOps e scegliere un'identità diversa.
Altre aree in cui è possibile applicare le autorizzazioni
- Autorizzazioni percorso area
- Tag dell'elemento di lavoro
- Elementi di lavoro spostati da un progetto
- Elementi di lavoro eliminati
- Guida rapida alle autorizzazioni predefinite e all'accesso per Azure Boards
- Regole personalizzate
- Esempi di scenari di regole personalizzate
- Backlog e bacheche personalizzati
- Controlli personalizzati