Se in Microsoft Teams non riesci ad aggiungere colleghi interni e vedi gli errori “You are not authorized” o “Unknown user – Email address is removed for privacy”, quasi sempre il tenant blocca la lettura dei dati utente in Azure AD/Entra ID. Qui trovi diagnosi e soluzione definitiva.
Scenario e sintomi
Hai creato un nuovo team in Microsoft Teams, sei indicato come Owner e tutti gli utenti hanno licenze Microsoft 365 Business Premium. Nonostante ciò, l’aggiunta dei membri interni fallisce con messaggi diversi a seconda del client:
- Teams “classico” →
You are not authorized. - Nuovo Teams →
Unknown user – Email address is removed for privacy
Per aggirare il blocco, può funzionare — ma solo temporaneamente — il trucco di creare prima un gruppo in Outlook, aggiungere i colleghi al gruppo e poi “convertire” quel gruppo in un team. Tuttavia questo non risolve la radice del problema e introduce passaggi inutili di gestione.
Perché accade: il legame tra Teams e Azure AD (oggi Microsoft Entra ID)
Teams non gestisce direttamente l’identità degli utenti: per cercare persone, risolvere indirizzi e validare i membri usa Microsoft Graph che, a sua volta, legge i dati dal servizio di directory dell’organizzazione (Azure Active Directory, rinominato Microsoft Entra ID). Se il tenant è configurato per impedire agli utenti di leggere le informazioni sugli altri utenti, l’operazione di aggiunta in Teams non riesce: il client non riesce a “risolvere” l’utente e mostra un errore dal significato poco chiaro.
In concreto, la funzione di people search che si attiva quando digiti nome, cognome o indirizzo nella maschera di aggiunta membri si appoggia a query verso la directory. Quando la lettura è vietata a livello tenant, la query restituisce un deny o un risultato vuoto. Ecco perché in Teams classico compare un generico “non autorizzato”, mentre nel nuovo Teams l’app tenta di proteggere la privacy rendendo l’indirizzo “anonimo” con la dicitura Email address is removed for privacy.
Il parametro chiave che blocca tutto
La causa più frequente è un’impostazione di organizzazione in Azure AD/Entra ID:
| Impostazione | Valore corretto | Effetto se impostato su False |
|---|---|---|
UsersPermissionToReadOtherUsersEnabled | True | Impedisce a Teams di recuperare i dati sugli utenti; il proprietario del team non può aggiungerli dal client. |
Questa opzione è stata spesso lasciata su False per esigenze di riservatezza o perché il tenant è stato “clonato” da ambienti di test con restrizioni elevate. In contesti reali, però, impedisce flussi basilari come la gestione dei membri dei team o la creazione di gruppi Microsoft 365 dal client.
Come risolvere in modo rapido e pulito
- Coinvolgi l’amministratore del tenant (IT/Azure AD)
Solo un utente con privilegi amministrativi (es. Global Administrator, Privileged Role Administrator) può modificare le impostazioni dell’organizzazione. - Verifica e correggi la configurazione Via portale (interfaccia grafica)
- Apri il portale di Azure Active Directory / Microsoft Entra ID.
- Vai su Users → User settings.
- Trova Users can see other users’ information e imposta su Yes.
- Salva le modifiche.
<h3>Via PowerShell (MSOnline o AzureAD)</h3> <p>Se preferisci uno script o stai automatizzando, puoi intervenire con PowerShell. Di seguito un esempio con il modulo <code>MSOnline</code> (ampiamente usato negli ambienti Microsoft 365):</p> <pre><code># Accedi al tenantConnect-MsolService Verifica lo stato attuale (facoltativo) Get-MsolCompanyInformation | Select UsersPermissionToReadOtherUsersEnabled Imposta il valore corretto Set-MsolCompanySettings -UsersPermissionToReadOtherUsersEnabled $true Nota: in alcuni tenant i moduliAzureAD/MSOnlinepossono risultare dismessi in favore delle API Microsoft Graph. Se non li hai disponibili, esegui la modifica dal portale: è la via più semplice e sicura. - Attendi la propagazione
In genere bastano pochi minuti perché la modifica si diffonda. A volte serve un nuovo accesso a Teams o un refresh della sessione. - Riprova l’aggiunta dei membri in Teams
Apri il team → Manage team → Members → Add member, digita il nome/indirizzo e conferma. Se l’impostazione è corretta, la ricerca risolverà subito i colleghi e l’inserimento andrà a buon fine.
Verifiche post-riparazione e controlli rapidi
- Aggiorna/riavvia il client (desktop o web) ed esegui un sign-out/sign-in, specialmente se il problema persiste solo su una postazione.
- Controlla il ruolo nel team: il proprietario deve essere davvero Owner. In caso di dubbi, verifica da Manage team → Members.
- Prova da Teams web (https) rispetto al client desktop per escludere cache locali anomale.
- Fai un test incrociato: un altro Owner del team riesce ad aggiungere gli stessi utenti? Se sì, indaga su policy o permessi dell’account originario.
Workaround: gruppo in Outlook → team (quando usarlo e limiti)
Il workaround che crea un Microsoft 365 Group da Outlook, aggiunge i colleghi e poi “eleva” quel gruppo a team può sbloccare una situazione urgente (kick-off imminente, scadenza a breve). Tuttavia:
- Non risolve la causa: il giorno dopo il problema si ripresenta su nuovi team.
- Duplica attività amministrative e può generare gruppi non allineati con la naming convention.
- Complica la governance (policy, scadenze, proprietari).
Usalo solo come soluzione temporanea e pianifica subito la correzione dell’impostazione in Azure AD.
Ulteriori suggerimenti utili (da non saltare)
Licenze e ruoli
- Licenze: assicurati che i membri da aggiungere dispongano di una licenza che includa Teams. Con Business Premium di norma è tutto incluso, ma una rimozione accidentale della “service plan” di Teams può bloccare l’aggiunta.
- Ruoli nel team: verifica che chi esegue l’operazione sia Owner. I Member potrebbero non poter aggiungere nuovi utenti a seconda delle impostazioni.
Limiti di membership
Se il team (o il gruppo di base) supera il limite di membri (10 000 per i team standard), l’aggiunta fallisce in ogni caso. In progetti molto grandi, valuta la suddivisione in più team o l’uso di dynamic membership basata su regole di gruppo.
Policy che possono interferire
- Teams policies: in rari casi una policy di Teams può impedire ad alcuni ruoli/utenti di invitare altri membri.
- Azure AD B2B: se sono state definite restrizioni aggressive per gli inviti esterni, assicurati che non impattino anche gli utenti interni (es. domini bloccati in modo troppo ampio). Qui parliamo di utenti interni, ma policy mal configurate possono avere effetti collaterali.
- Privacy della directory: oltre all’impostazione principale trattata in questa guida, verifica che non esistano regole o estensioni custom che nascondono selettivamente alcuni utenti (es. “utenti nascosti dalla rubrica”).
Sincronizzazione e identità (ambienti ibridi)
- UPN coerente: se usi sincronizzazione da AD locale (Entra Connect), assicurati che l’UPN dell’utente corrisponda al dominio verificato nel tenant.
- Attributi mancanti: profili senza mail o proxyAddresses correttamente valorizzati possono essere più difficili da individuare con la ricerca di Teams.
Cache locale del client
La cache di Teams raramente è la causa principale di questo specifico errore, ma può “congelare” uno stato non più attuale. Se necessario, esegui un sign-out, chiudi Teams, svuota la cache e riaccedi. In alternativa, prova direttamente da browser in modalità in incognito.
Domande frequenti (FAQ)
Perché Teams mi dà “You are not authorized” quando aggiungo un collega interno?
Perché il tenant è configurato in modo che gli utenti non possano leggere le informazioni di altri utenti in Azure AD/Entra ID. Teams dipende da quella lettura per risolvere e validare i membri.
Non voglio che tutti vedano i dettagli degli altri: c’è un compromesso?
Sì: impostare UsersPermissionToReadOtherUsersEnabled=True abilita la risoluzione minima necessaria al funzionamento dei servizi collaborativi. Puoi comunque regolare la quantità di dettagli visibili nei profili, applicare policy di privacy, limitare attributi sensibili e usare gruppi o canali privati per i contenuti riservati.
Perché il workaround via Outlook funziona?
Perché la creazione di un Microsoft 365 Group con l’elenco dei membri avviene in un punto diverso della pipeline, spesso gestito da servizi che hanno privilegi elevati. Tuttavia, quando torni a usare Teams per gestire i membri, ti scontri di nuovo con la restrizione di directory.
Ci sono rischi nel cambiare l’impostazione?
Abilitare la lettura di base degli utenti è una configurazione standard per ambienti collaborativi. Non espone i contenuti del tenant, ma consente la visualizzazione delle schede profilo e l’individuazione delle persone. Puoi mantenere controlli forti su dati sensibili e su cosa viene sincronizzato.
Checklist operativa: dalla diagnosi alla correzione
- Conferma i sintomi in Teams (classico: “You are not authorized”; nuovo: “Unknown user – Email address is removed for privacy”).
- Accedi ad Azure AD/Entra ID come amministratore.
- Vai a Users → User settings e imposta Users can see other users’ information su Yes.
- In alternativa: PowerShell
Set-MsolCompanySettings -UsersPermissionToReadOtherUsersEnabled $true. - Attendi la propagazione (alcuni minuti) e rifai l’aggiunta in Teams.
- Se persiste: verifica licenze, ruolo Owner, limiti di membership, policy particolari e — in ambienti ibridi — coerenza degli attributi.
Guida passo–passo: portale Azure AD/Entra ID
- Apri il portale e seleziona l’organizzazione corretta (se gestisci più tenant).
- Nel riquadro di navigazione, seleziona Users.
- Apri User settings e trova la voce Users can see other users’ information.
- Imposta l’opzione su Yes e salva.
- Comunica ai proprietari dei team di riprovare l’aggiunta dopo qualche minuto; se possibile, chiedi di fare sign-out e sign-in.
Script di esempio (PowerShell)
Per amministratori che desiderano automatizzare la verifica e la correzione in più tenant:
# Richiede il modulo MSOnline
Install-Module MSOnline -Scope CurrentUser
Connect-MsolService
Verifica il valore corrente
$info = Get-MsolCompanyInformation | Select-Object UsersPermissionToReadOtherUsersEnabled
"Valore attuale UsersPermissionToReadOtherUsersEnabled: $($info.UsersPermissionToReadOtherUsersEnabled)"
Imposta su True se non lo è già
if (-not $info.UsersPermissionToReadOtherUsersEnabled) {
Write-Host "Imposto UsersPermissionToReadOtherUsersEnabled su True..."
Set-MsolCompanySettings -UsersPermissionToReadOtherUsersEnabled $true
Start-Sleep -Seconds 30
$check = Get-MsolCompanyInformation | Select-Object UsersPermissionToReadOtherUsersEnabled
"Nuovo valore: $($check.UsersPermissionToReadOtherUsersEnabled)"
} else {
Write-Host "Nessuna modifica necessaria."
} </code></pre>
<p><em>Consiglio pratico:</em> esegui lo script in una finestra con privilegi amministrativi e conserva un log delle modifiche (trascrizione PowerShell) per la conformità.</p>
<h2>Diagnostica avanzata: cosa succede sotto il cofano</h2>
<p>Quando digiti un nome nel campo <em>Add member</em>, il client Teams invia richieste a Microsoft Graph per cercare utenti (<em>search</em> e <em>people</em>). Se la directory blocca la lettura, la risposta è un errore di autorizzazione o una lista vuota. La UI, non potendo mostrare dettagli, propone messaggi generici. Se usi strumenti di sviluppo del browser, potresti notare chiamate che falliscono con codice 403/401 nelle sessioni problematiche. Non è necessario fare <em>debug</em> di basso livello per risolvere: la correzione dell’impostazione di directory è sufficiente nella quasi totalità dei casi.</p>
<h2>Best practice di governance per evitare recidive</h2>
<ul>
<li><strong>Allinea la baseline del tenant</strong>: nelle checklist di sicurezza includi esplicitamente l’impostazione <code>UsersPermissionToReadOtherUsersEnabled=True</code> per ambienti collaborativi.</li>
<li><strong>Documenta la scelta</strong>: se per motivi di privacy vuoi limitare la visibilità, definisci alternative operative (es. richieste d’accesso via IT) e misura l’impatto su Teams, Planner, Outlook e SharePoint.</li>
<li><strong>Standardizza i flussi</strong>: evita workarounds manuali (gruppo Outlook → team) salvo emergenze; crea procedure e modelli di team con proprietari chiari.</li>
<li><strong>Monitora</strong>: prevedi controlli periodici su impostazioni chiave e limiti di membership per i team critici.</li>
</ul>
<h2>In sintesi</h2>
<p>L’impossibilità di aggiungere membri interni a un team con errori del tipo <em>“You are not authorized”</em> o <em>“Unknown user – Email address is removed for privacy”</em> è quasi sempre dovuta al fatto che Azure AD/Entra ID non consente la lettura dei dettagli sugli altri utenti. Impostando <code>UsersPermissionToReadOtherUsersEnabled=True</code> — via portale o con PowerShell — il problema si risolve e diventa possibile aggiungere i colleghi direttamente dal client Teams, senza ricorrere al workaround basato su Outlook. Ricorda di verificare anche licenze, ruolo <em>Owner</em>, limiti di membership e policy speciali del tenant per evitare che fattori secondari mascherino la stessa sintomatologia.</p>
<hr>
<p><strong>Riferimento operativo breve</strong></p>
<ol>
<li>Admin → Azure AD/Entra ID → <em>Users</em> → <em>User settings</em> → <em>Users can see other users’ information</em> = <strong>Yes</strong>.</li>
<li>Oppure PowerShell:
<pre><code>Connect-MsolService
Set-MsolCompanySettings -UsersPermissionToReadOtherUsersEnabled $true
Attendi propagazione e riprova l’aggiunta in Teams.
Con questa regolazione, l’esperienza d’uso di Teams torna coerente: la ricerca trova i colleghi, l’aggiunta è immediata e la gestione dei team torna semplice e sicura.