Résumé : Claude utilise l'adresse e-mail comme identifiant principal pour faire correspondre les connexions SSO aux sièges provisionnés. Dans Google Workspace, l'auto-provisionnement SCIM et l'authentification SAML peuvent envoyer des valeurs d'e-mail différentes — en particulier lorsque les utilisateurs ont des alias d'e-mail — ce qui provoque une non-correspondance qui bloque l'accès.

Symptômes

Les utilisateurs peuvent rencontrer un ou plusieurs des problèmes suivants lorsqu'ils tentent d'accéder à Claude for Enterprise via SSO :

« La création de compte est bloquée » — L'utilisateur s'authentifie via SSO mais Claude ne peut pas trouver un compte provisionné correspondant. Si votre organisation a restreint la création d'organisation (recommandé), l'utilisateur est complètement bloqué et ne peut pas continuer.
Accès à un compte personnel gratuit — Si la création d'organisation n'est pas restreinte, l'utilisateur contourne complètement l'organisation d'entreprise et crée ou accède à un compte personnel gratuit au lieu de son siège d'entreprise.
« Veuillez confirmer votre e-mail » non-correspondance — Le rappel SSO affiche un e-mail différent de celui que l'utilisateur a saisi à la connexion.
Échec de l'authentification Claude Code — L'interface de ligne de commande Claude Code affiche une erreur de non-correspondance d'e-mail lors du flux d'authentification, empêchant l'utilisateur de se connecter à l'organisation d'entreprise.

Comment cela se produit

Les comptes utilisateurs Google Workspace ont une adresse e-mail principale et peuvent avoir plusieurs alias. L'auto-provisionnement SCIM et l'authentification SAML sont configurés séparément dans la console Google Admin et peuvent extraire des champs d'adresse différents :

Attribut Google	Valeur typique	Couramment utilisé par
`primaryEmail`	`[email protected]`	Recommandé pour SCIM et SAML
Alias d'e-mail	`[email protected]`, `[email protected]`	Parfois mappés par erreur dans SCIM
Champs de schéma personnalisé	Attributs personnalisés définis par organisation	Mappages d'attributs avancés
E-mail de l'unité organisationnelle	Variantes d'adresse dérivées de l'UO	Rarement, dans les structures organisationnelles complexes

La non-correspondance la plus courante : SCIM est configuré pour envoyer une adresse alias tandis que SAML envoie l'e-mail principal (ou vice versa). Puisque les alias et les e-mails principaux sont des chaînes différentes, Claude ne peut pas les faire correspondre. Claude nécessite une correspondance exacte de chaîne.

Confusion courante : Dans Google Admin, les paramètres d'auto-provisionnement SCIM et le mappage d'attributs SAML se trouvent sur des onglets séparés dans la même application. Les administrateurs mettent parfois à jour l'un et oublient l'autre. Vérifiez les deux emplacements.

Étapes de diagnostic

Étape 1 — Confirmer la non-correspondance

Vérifiez l'e-mail SCIM : Dans la console Google Admin, allez à Applications → Applications web et mobiles → [Claude App] → Auto-provisionnement. Vérifiez quel attribut est mappé au champ d'e-mail envoyé à Claude.
Vérifiez l'e-mail SAML : Dans la même application, allez à la section Mappage d'attributs SAML. Trouvez l'attribut mappé à email et notez sa source.
Vérifiez un utilisateur spécifique : Dans Annuaire → Utilisateurs → [Utilisateur], comparez l'E-mail principal de l'utilisateur avec tous les E-mails alias listés.

Étape 2 — Identifier l'étendue du problème

Déterminez s'il s'agit d'un utilisateur affecté ou d'un problème systémique :

Si la plupart ou tous les utilisateurs provisionnés partagent la même non-correspondance de format d'e-mail, c'est un problème systémique de mappage d'attributs. La solution se trouve dans le mappage d'attributs SCIM de votre fournisseur d'identité.
Si seul un ou deux utilisateurs sont affectés, le problème est probablement spécifique à ces comptes utilisateurs. Vérifiez directement leur profil utilisateur.

Étape 3 — Vérifier l'ID de nom dans la configuration SAML

Dans les paramètres de l'application, allez à SAML → Détails du fournisseur de services.
Confirmez que l'ID de nom est défini sur Informations de base → E-mail principal.
Si l'ID de nom est défini sur un champ de schéma personnalisé ou un alias, il peut envoyer une valeur différente de celle de SCIM.

Résolution

Aligner les deux mappages sur primaryEmail

L'attribut primaryEmail de Google Workspace est la source la plus fiable pour SCIM et SAML.

Mettez à jour l'auto-provisionnement SCIM : Dans Applications → Applications web et mobiles → [Claude App] → Auto-provisionnement → Mappage d'attributs, assurez-vous que l'attribut d'e-mail est mappé à primaryEmail.
Mettez à jour l'ID de nom SAML : Dans SAML → Détails du fournisseur de services, définissez l'ID de nom sur Informations de base → E-mail principal.
Mettez à jour le mappage d'attributs SAML : À l'étape Mappage d'attributs, assurez-vous que l'attribut email est mappé sur Informations de base → E-mail principal.
Enregistrez toutes les modifications.

Déclencher une resynchronisation complète

Critique — Synchronisation complète requise : Une synchronisation incrémentale ne mettra pas à jour les utilisateurs existants après que vous ayez modifié un mappage d'attributs. Vous devez déclencher un redémarrage complet du cycle d'auto-provisionnement.

Dans la console Google Admin, allez aux paramètres Auto-provisionnement de l'application.
Suspendez temporairement l'auto-provisionnement, puis réactivez-le. Cela déclenche une synchronisation complète de tous les utilisateurs assignés.
Vous pouvez également supprimer et réajouter les utilisateurs affectés à l'assignation d'application pour forcer la reprovisionnement de leurs enregistrements individuels.
Surveillez les journaux d'auto-provisionnement pour les erreurs et confirmez que les e-mails des utilisateurs ont été mis à jour pour correspondre au format SAML avant de demander aux utilisateurs de réessayer.

Nettoyage après correction

Après avoir corrigé le mappage d'attributs et complété la synchronisation complète, vous devrez peut-être effectuer un nettoyage supplémentaire :

Comptes gratuits non autorisés : Si la création d'organisation n'était pas restreinte avant la correction, certains utilisateurs ont peut-être involontairement créé des comptes Claude personnels gratuits. Contactez Anthropic Support pour les faire supprimer.
Comptes fantômes (sièges avec mauvais e-mail) : Les comptes provisionnés à l'origine (avec l'e-mail incorrect) peuvent toujours exister dans votre organisation d'entreprise, occupant des sièges. Contactez Anthropic Support pour déprovisionner ces comptes fantômes.
Disponibilité des sièges : Si les comptes fantômes occupent tous les sièges contractés, les nouvelles connexions échoueront avec une erreur de dépassement de sièges. La déprovisionnement des comptes fantômes libère ces sièges.
Réajout des utilisateurs affectés : Après la suppression des comptes fantômes, les utilisateurs avec l'e-mail corrigé devront peut-être être réinvités ou reprovisionnés.

Prévenir les occurrences futures : Activez « Restreindre la création d'organisation » dans vos paramètres d'entreprise. Cela empêche les utilisateurs qui ne sont pas encore provisionnés de créer accidentellement des comptes personnels gratuits.

Vérification

Vérifiez un échantillon d'utilisateurs provisionnés — confirmez que leur e-mail dans le journal d'auto-provisionnement de votre fournisseur d'identité correspond au format d'e-mail que SSO envoie.
Demandez à un utilisateur affecté d'effacer les cookies du navigateur pour claude.ai, puis de se connecter via SSO. Il devrait accéder directement à l'espace de travail d'entreprise sans aucune erreur.
Confirmez que les utilisateurs ne créent pas accidentellement de comptes gratuits — si la création d'organisation est restreinte, les utilisateurs bloqués verront une erreur claire au lieu d'accéder à un compte personnel.
Si Claude Code a été affecté, demandez à l'utilisateur de réexécuter claude auth login --enterprise et confirmez que l'e-mail correspond à son siège d'entreprise.

Pièges courants

Piège	Solution
SCIM envoie un alias tandis que SAML envoie l'e-mail principal	Utilisez toujours `primaryEmail` pour les deux.
L'ID de nom dans les paramètres SAML n'a pas été vérifié	Le champ ID de nom détermine l'e-mail envoyé à la connexion. C'est différent de la section de mappage d'attributs. Vérifiez les deux.
Le champ de schéma personnalisé est vide pour certains utilisateurs	Restez avec les attributs Google standard comme `primaryEmail`.
La reprovisionnement ne se déclenche pas automatiquement après le changement de mappage	Vous devrez peut-être suspendre et réactiver manuellement l'auto-provisionnement pour forcer une synchronisation complète.
L'e-mail principal de l'utilisateur a changé mais l'ancien e-mail apparaît toujours dans Claude	Une resynchronisation complète est nécessaire après les modifications d'e-mail principal.
Les e-mails ont été mis à jour dans SCIM mais l'utilisateur ne peut toujours pas se connecter	Vérifiez les organisations gratuites non autorisées ou les comptes fantômes. Effacez les cookies du navigateur et réessayez.

Quand contacter Anthropic Support

Les attributs SCIM et SSO semblent identiques mais les utilisateurs ne peuvent toujours pas accéder à leurs sièges.
Vous devez confirmer quel e-mail Claude a enregistré lors de l'auto-provisionnement SCIM pour des utilisateurs spécifiques.
Vous avez besoin d'aide pour nettoyer les comptes fantômes ou les organisations gratuites non autorisées.
Les utilisateurs rencontrent une erreur de dépassement de sièges malgré le fait que votre contrat dispose de sièges disponibles.

Contactez [email protected] avec le domaine de votre organisation, l'adresse e-mail de l'utilisateur affecté et des captures d'écran de vos mappages d'attributs.

Décalage d'e-mail SSO/SCIM — Google Workspace