Erreur « Unknown user » Teams : corriger l’ajout de membres internes via le paramètre Entra ID

Blocage lors de l’ajout de membres internes dans Microsoft Teams ? Découvrez comment corriger l’erreur « Unknown user / You are not authorized » en réactivant le paramètre UsersPermissionToReadOtherUsersEnabled dans Entra ID, et appliquez des bonnes pratiques de gouvernance pour éviter tout retour du problème.

Problématique

Dans plusieurs locataires Microsoft 365 Business Premium, l’ajout d’utilisateurs internes (déjà licenciés pour Teams) échoue brusquement :

• Ancien client Teams : message « You are not authorized ».
• Nouveau client Teams : message « Unknown user – *** Email address is removed for privacy *** ».

Le contournement le plus souvent observé consiste à :

1. Créer un groupe Microsoft 365 depuis Outlook ;
2. Convertir ce groupe en équipe Teams via la commande « Créer une équipe à partir d’un groupe existant ».

Ce détour fonctionne, mais il masque seulement la véritable cause racine.

Diagnostic rapide

Le symptôme pointe presque toujours vers une désactivation du paramètre Entra ID UsersPermissionToReadOtherUsersEnabled. Lorsque ce commutateur est à False, Teams ne peut plus interroger l’annuaire pour récupérer l’objet utilisateur à inviter.

Pourquoi ce paramètre change-t‑il ? Les causes fréquentes incluent :

• Déploiement d’un script de durcissement de la sécurité (security hardening) ;
• Import d’un modèle de configuration CIS/CMMC qui force la confidentialité des objets ;
• Modification manuelle dans le portail par un administrateur pensant limiter l’exposition des profils.

Solution recommandée

1. Réactiver la permission de lecture pour tous

Via le portail Entra ID

1. Connectez‑vous au Portail Microsoft Entra avec un administrateur général.
2. Naviguez vers Identité ▸ Paramètres ▸ Paramètres utilisateur.
3. Basculez « Les utilisateurs peuvent voir les informations des autres utilisateurs » sur Activé.
4. Enregistrez. La propagation dure généralement moins de dix minutes, mais peut monter à une heure selon la taille du tenant.

Via PowerShell MSOnline

Install-Module MSOnline          # première installation si nécessaire
Connect-MsolService              # ouverture de session administrateur
Set-MsolCompanySettings -UsersPermissionToReadOtherUsersEnabled $true

Remarque : Le module AzureADPreview ou EntraID (successeur) propose la même cmdlet, avec une syntaxe identique. Vous pouvez donc utiliser :

Connect-AzureAD
Set-AzureADMSCompanySettings -UsersPermissionToReadOtherUsersEnabled $true

2. Tester immédiatement

Ouvrez Teams (application de bureau, web ou mobile), sélectionnez l’équipe concernée et relancez l’ajout d’un utilisateur interne. Si la propagation est terminée, l’invitation est acceptée sans message d’erreur.

Points de contrôle supplémentaires

Vérification	Pourquoi ?	Correctif éventuel
Rôle du demandeur	Seul un Owner peut inviter des membres.	Promouvoir l’utilisateur en propriétaire ou demander à un Owner existant d’effectuer l’ajout.
Type de groupe	Seules les équipes basées sur un groupe Microsoft 365 autorisent l’invitation.	Créer l’équipe depuis Teams ou à partir d’un groupe existant.
Licences Teams	Les utilisateurs doivent posséder une licence Teams ou Microsoft 365 éligible.	Vérifier dans le Centre d’administration Microsoft 365, onglet Licences.
Synchronisation AAD Connect	Un attribut manquant (userPrincipalName, mail) bloque la création.	Lancer Start-ADSyncSyncCycle ou corriger l’attribut côté AD On‑Prem.

Analyse détaillée : pourquoi ce paramètre est‑il crucial ?

Le champ UsersPermissionToReadOtherUsersEnabled contrôle la visibilité interne du répertoire. Lorsque False :

• Les appels Graph /users retournent HTTP 403 – Insufficient privileges ;
• Teams (qui s’appuie massivement sur le Graph) échoue en silence et affiche des messages génériques ;
• Les fonctionnalités de recherche et de suggestion automatique (people picker) se dégradent dans l’ensemble de Microsoft 365 : SharePoint, Viva Engage, Loop, etc.

À l’inverse, quand le paramètre est True, tous les utilisateurs authentifiés peuvent lire les attributs public profile (nom, prénom, email, photo). Les autorisations d’accès conditionnel et la classification de sensibilité continuent de protéger les données sensibles ; seules les métadonnées basiques restent exposées.

Bonnes pratiques de gouvernance Entra ID / Teams

Pour éviter de futurs blocages :

1. Documentez votre configuration de sécurité avant toute modification, et conservez un journal des changements (Change Log).
2. Intégrez la vérification du paramètre UsersPermissionToReadOtherUsersEnabled dans vos scripts d’audit automatisés (Azure AD Graph Audit, MSGraph Check‑up).
3. Adoptez le principe du moindre privilège sans bloquer la couche d’annuaire : il est plus efficace de maîtriser l’accès aux données sensibles (SharePoint, OneDrive, Exchange) que d’interdire la lecture de l’identité de base.
4. Séparez les rôles : attribuez le rôle Administrateur des utilisateurs aux équipes Help‑Desk, et réservez le rôle Administrateur des paramètres ou Administrateur général à un nombre restreint de personnes.
5. Automatisez les tests de bout en bout : script PowerShell ou Playwright qui crée une équipe, tente d’ajouter un membre, puis supprime la ressource. Programmez‑le chaque semaine pour détecter immédiatement toute régression.

Alternatives et contournements

• Méthode Outlook → Teams (création d’un groupe Microsoft 365 puis conversion) : toujours valable si la modification du tenant est soumise à processus de validation.
• Teams Admin Center : un administrateur Teams Service Admin peut ajouter directement l’utilisateur dans Gestion des équipes ▸ Membres.
• Graph API : l’appel POST /groups/{id}/members/$ref fonctionne même lorsque l’UI bloque. Intéressant pour un runbook Azure Automation.

FAQ – Questions fréquentes

Est‑ce que la réactivation rend mon annuaire public ?

Non. Le paramètre restaure la visibilité des attributs public profile uniquement à l’intérieur du tenant. Il n’affecte pas la visibilité externe ni les invités B2B.

Peut‑on limiter la visibilité à certains groupes d’utilisateurs ?

Pas directement avec ce paramètre. Utilisez plutôt des stratégies Dynamic Administrative Units et des rôles personnalisés pour restreindre qui peut modifier les utilisateurs. La lecture reste globale ou bloquée.

Comment savoir qui a changé le paramètre ?

Consultez le journal d’audit Entra ID (Audit Logs) et filtrez sur l’activité Update company information. Vous y trouverez le compte, la date et même l’adresse IP à l’origine de la modification.

Les invités B2B sont‑ils impactés ?

Oui : si le paramètre est False, la suggestion automatique d’invitations B2B peut ne plus afficher le nom correct, et l’ajout d’un invité existant échouera de la même manière.

Exemple de script complet de remédiation

Voici un exemple de script PowerShell commenté qui :

1. Teste la valeur actuelle ;
2. La corrige si nécessaire ;
3. Envoie un rapport HTML par e‑mail.

#requires -Modules MSOnline, PnP.PowerShell
Param(
    [Parameter(Mandatory)]
    [string]$ReportTo
)

Import-Module MSOnline
Connect-MsolService

\$tenant = Get-MsolCompanyInformation
\$before = \$tenant.UsersPermissionToReadOtherUsersEnabled

if (-not \$before) {
Write-Host "Le paramètre est désactivé ; activation en cours..."
Set-MsolCompanySettings -UsersPermissionToReadOtherUsersEnabled \$true
Start-Sleep -Seconds 300    # attente propagation
}

\$tenant = Get-MsolCompanyInformation
\$after  = \$tenant.UsersPermissionToReadOtherUsersEnabled

\$html = @"
\Rapport de remédiation Teams / Entra ID\
\Valeur avant : \\$before\\
\Valeur après : \\$after\\
"@

Send-PnPMail -To \$ReportTo -Subject "Rapport Teams – Correctif visibilité annuaire" -Body \$html -BodyAsHtml 

Surveillance proactive

Mettez en place une règle Log Analytics ou un Workbook qui interroge quotidiennement le Graph pour vérifier la valeur du paramètre. En cas d’écart, déclenchez une alerte Teams ou un ticket ITSM.

Conclusion

Les messages « Unknown user » ou « You are not authorized » lors de l’ajout de membres internes dans Teams traduisent presque toujours une désactivation de UsersPermissionToReadOtherUsersEnabled. La correction est immédiate : repassez‑le à True, testez l’invitation et vérifiez vos processus de gouvernance pour que cette valeur ne soit plus modifiée sans justification. Vous garantirez ainsi la continuité des opérations, la cohérence de l’expérience utilisateur et la conformité aux meilleures pratiques Microsoft 365.