Mon premier IAM

Microsoft Entra ID · Provisioning

Erreur InvalidAnchor dans Microsoft Entra : comprendre et résoudre l’échec de provisioning

InvalidAnchor signifie qu’un utilisateur précédemment créé ou rapproché par le service de provisioning n’existe plus. Commencez par retrouver l’événement et vérifier le compte dans le système cible, avant de redémarrer le job.

Ce n’est pas une erreur de licence Microsoft 365. Une relance n’est pas une solution universelle : son effet dépend de l’état du compte et des correspondances conservées par le service.

Que signifie exactement InvalidAnchor ?

Dans sa liste des erreurs de provisioning, Microsoft donne la description suivante :

“A user that was previously created or matched by the provisioning service no longer exists.”

Description officielle du code InvalidAnchor

Le rapprochement, ou matching, consiste à retrouver dans la cible le compte correspondant à l’identité source, à l’aide des attributs configurés. Après une création ou un rapprochement, le service conserve l’identifiant du compte cible et l’utilise pour les opérations suivantes. C’est le mécanisme décrit dans le fonctionnement du provisioning.

Le code ne suffit pas à expliquer pourquoi le compte n’existe plus. Il ne prouve ni une suppression volontaire, ni un problème de licence, ni un défaut de votre source RH : ces points doivent être vérifiés dans le contexte de l’événement.

Retrouver l’erreur dans les journaux Entra

  1. Connectez-vous au centre d’administration Microsoft Entra. Microsoft indique que Reports Reader est le rôle minimal pour consulter les journaux ; les propriétaires d’application peuvent aussi consulter ceux de leurs applications.
  2. Ouvrez Entra ID > Monitoring & health > Provisioning logs (journaux de provisioning).
  3. Limitez la période au moment de l’échec et filtrez sur le statut Failure. Affinez avec l’identité et l’application concernées lorsqu’elles sont connues.
  4. Ouvrez l’événement en échec et vérifiez que le code est bien InvalidAnchor. Examinez la source, la cible, l’action et les étapes de provisioning, pas seulement le résumé de l’erreur.

Conservez l’horodatage, les identifiants disponibles et les détails de l’événement pour comparer les tentatives. Les journaux peuvent être téléchargés en CSV ou JSON ; le guide Microsoft des journaux détaille aussi les filtres et les informations des événements.

Identifier l’utilisateur et le compte cible

  1. Confirmez la source et la destination. Ne supposez pas qu’Entra est toujours la source : vérifiez le sens du flux affiché et le job de l’application concernée.
  2. Retrouvez l’identité source. Contrôlez son identifiant, son état et son appartenance au périmètre de provisioning.
  3. Cherchez le compte dans la cible. Utilisez l’identifiant indiqué dans les détails, s’il est disponible, et les attributs de rapprochement configurés. La présence d’un compte portant le même nom ne garantit pas qu’il s’agit du même objet.
  4. Vérifiez son état avec le responsable de l’application. Existe-t-il encore ? Est-il désactivé, supprimé ou remplacé par un autre objet ? Confirmez les faits dans la cible avant toute correction.

Corriger le compte ou refaire le rapprochement ?

Microsoft recommande d’abord de s’assurer que l’utilisateur existe. Le choix suivant dépend du diagnostic : les pistes ci-dessous ne constituent pas une procédure universelle de restauration pour toutes les applications.

Le compte attendu a disparu
Vérifiez s’il doit encore exister. Si sa disparition est involontaire, examinez les possibilités de correction ou de restauration documentées par l’application cible avec son responsable. Ne supposez pas qu’une recréation manuelle conservera le même identifiant.
Un compte existe, mais son identifiant ne correspond plus
Comparez les détails du journal et les attributs de rapprochement. Un nouveau rapprochement peut être nécessaire. Microsoft renvoie vers le redémarrage du job par Graph pour forcer un nouveau matching de tous les utilisateurs : c’est une action globale, pas une correction limitée à ce compte.
Le compte ne doit plus être actif
Ne le recréez pas uniquement pour effacer l’erreur. Vérifiez l’événement de départ, le périmètre du job et le résultat attendu dans la cible : désactivation, retrait d’accès ou suppression selon vos règles et les capacités de l’application.
Le compte et son identifiant semblent corrects
Reprenez les étapes détaillées et les traces côté application. Si l’écart reste inexpliqué, transmettez ces éléments au support concerné plutôt que de réinitialiser les correspondances sans cause identifiée.

Ce qu’un redémarrage du job change réellement

La documentation du fonctionnement apporte une distinction essentielle : réévaluer les objets n’est pas nécessairement rompre leurs correspondances. Un watermark est le point de reprise enregistré pour les cycles incrémentaux.

Restart provisioning dans le portail
Déclenche un nouveau cycle initial, efface le watermark et réévalue les objets source. Microsoft précise que cette action ne rompt pas les liens entre objets source et cible.
Restart du job dans Microsoft Graph
La requête utilise des critères de réinitialisation. L’exemple de la référence v1.0 indique resetScope avec Watermark, Escrows, QuarantineState. Il ne faut pas assimiler cet exemple à l’effacement de toutes les correspondances.
Réinitialisation Full pour rompre les liens
Le guide du fonctionnement montre une requête avec resetScope: Full pour rompre les liens source-cible. Cet exemple utilise explicitement l’API Graph beta, pas l’URL v1.0 de la référence de redémarrage. Vérifiez la version et la documentation applicables avant toute utilisation ; ce guide ne propose pas de commande globale à copier sans contrôle.

Consultez conjointement la référence Graph du redémarrage et la distinction entre cycle initial et rupture des liens. Effacer le cache de traitement, reprendre un cycle et supprimer les correspondances ne sont pas des formulations interchangeables.

Checklist avant une action à impact global

  • Conserver l’événement InvalidAnchor, son horodatage, ses identifiants et ses étapes détaillées.
  • Confirmer l’application, le job, le sens du flux et les utilisateurs ou groupes concernés par son périmètre.
  • Vérifier l’existence et l’état du compte cible, ainsi que le résultat métier attendu.
  • Relever les attributs de rapprochement, mappings, affectations et filtres de périmètre actuels.
  • Identifier précisément l’action envisagée : reprise du cycle ou rupture des liens, version Graph et critères de réinitialisation.
  • Examiner les conséquences possibles d’un cycle initial : mise à jour d’un compte rapproché, ou création si aucune correspondance n’est trouvée, selon la configuration du job.
  • Faire valider l’intervention par les responsables du provisioning et de la cible ; prévoir la surveillance et le traitement des exceptions.

Contrôler le résultat après intervention

Relisez les nouveaux événements pour l’utilisateur et la cible concernés. Confirmez la réussite de l’action attendue puis contrôlez le compte dans l’application. Si un cycle initial a été déclenché, surveillez aussi les autres erreurs et opérations du job jusqu’à sa fin. L’absence d’un nouvel InvalidAnchor n’est pas, à elle seule, la preuve que tous les accès attendus fonctionnent.

Provisioning et licences : deux diagnostics distincts

Le provisioning crée, met à jour ou retire des comptes et droits dans les systèmes raccordés. L’attribution de licences Microsoft 365 répond à d’autres règles et produit ses propres erreurs. Acheter des licences ne constitue donc pas une correction documentée d’InvalidAnchor.

Si l’erreur porte en réalité sur une capacité de licences insuffisante, consultez le diagnostic CountViolation. Les deux problèmes peuvent être rencontrés dans le même environnement, sans que l’un explique automatiquement l’autre.

Questions fréquentes sur InvalidAnchor

InvalidAnchor est-il une erreur de licence Microsoft 365 ?

Non. Ce code concerne un utilisateur précédemment créé ou rapproché par le service de provisioning qui n’existe plus. Il ne signale pas un manque de licences. Une erreur d’attribution de licence se diagnostique séparément.

Le compte existe dans Entra : pourquoi vérifier l’application cible ?

L’existence de l’identité source ne garantit pas celle du compte ciblé par le service. Après création ou rapprochement, le provisioning conserve l’identifiant du compte cible pour ses opérations suivantes. Vérifiez ce compte et son identifiant dans l’application indiquée par l’événement.

Cliquer sur Restart provisioning suffit-il ?

Pas nécessairement. Microsoft précise que cette action relance un cycle initial et réévalue les objets source, mais ne rompt pas les correspondances source-cible. Un nouveau rapprochement complet demande de distinguer les critères de réinitialisation du job. Il ne remplace pas le diagnostic du compte manquant.

Faut-il recréer immédiatement le compte ?

Non. Confirmez d’abord qu’il doit encore exister, son état dans l’application, son identifiant et les attributs de rapprochement. Ne recréez pas un compte pour un collaborateur parti uniquement pour faire disparaître une erreur. Une création manuelle sans ces contrôles peut compliquer le rapprochement.

Comment vérifier que le problème est résolu ?

Consultez un nouvel événement pour la même identité et la même application : vérifiez l’opération, son résultat et les étapes exécutées. Contrôlez ensuite dans la cible le compte et les accès réellement attendus. L’acceptation d’un redémarrage ne prouve pas, à elle seule, la réussite du provisioning.

Relier le diagnostic au flux concerné

Une correction technique ne remplace pas la vérification de l’événement attendu. Ces fiches aident à situer le contrôle dans le cycle de vie :

Sources officielles Microsoft