メインコンテンツにスキップ

SSO/SCIM Email Mismatch — Ping Identity

概要: Claudeはメールアドレスをプライマリ識別子として使用し、SSOログインをプロビジョニング済みシートにマッチングします。Ping Identityの製品(PingOneおよびPingFederate)は柔軟で階層化された属性設定を備えています。SCIMプロビジョニングとSAML/OIDC SSOが異なるユーザー属性から取得する場合、不一致がアクセスをブロックします。

症状

SSOを介してClaude for Enterpriseにアクセスしようとする際、ユーザーは以下の1つ以上の症状を経験する可能性があります:

  • 「アカウント作成がブロックされています」 — ユーザーはSSOで認証されますが、Claudeはマッチングするプロビジョニング済みアカウントを見つけることができません。

  • 無料の個人アカウントにランディング — 組織の作成が制限されていない場合、ユーザーはエンタープライズ組織全体をバイパスします。

  • 「メールアドレスを確認してください」の不一致 — SSOコールバックに、ユーザーがログイン時に入力したメールアドレスと異なるメールアドレスが表示されます。

  • Claude Code認証エラー — Claude Code CLIは認証フロー中にメールアドレスの不一致エラーを表示します。

これが発生する仕組み

Ping Identityの製品は、複数のレベル(ディレクトリ、IdPアダプター、SPコネクター、アプリケーション)で細かい属性マッピングを可能にします。SCIMとSSOはこれらのレイヤーを通じて異なるパスをたどることができ、異なるメール値がClaudeに到達する結果になります:

Ping属性

典型的な値

一般的に使用される用途

email(PingOne)

SCIMとSAML/OIDCの両方に推奨

username(PingOne)

testuser1または[email protected]

デフォルトログイン識別子。メールアドレスと異なる場合があります

IdPアダプター属性(PingFederate)

アダプタータイプ(LDAP、HTMLフォームなど)によって異なります

PingFederateのアイデンティティソース

LDAP mail属性

PingFederateのディレクトリソースメール

LDAP sAMAccountNameまたはuid

従業員IDまたは短いユーザー名の場合があります

誤ってメールアドレスにマッピングされることがあります

カスタム母集団属性

環境ごとに定義されたカスタムフィールド

高度なPingOne設定

Claudeは、SCIMでプロビジョニングされたメールアドレスとSSOで主張されたメールアドレスの間で完全な文字列一致を必要とします。

PingFederateに関する注記: PingFederateの属性契約システムは特に複雑です — メールアドレスは複数のレイヤーを通過できます(LDAP → IdPアダプター → アダプター契約 → SPコネクター → アサーション)。任意のレイヤーでの不一致により、間違った値がClaudeに到達します。値をエンドツーエンドで追跡してください。

診断手順

ステップ1 — 不一致を確認する(PingOne)

  1. SCIM属性マッピングを確認: PingOne管理画面で、接続 → アプリケーション → [Claudeアプリ] → 属性マッピングに移動します。emails[primary].valueまたはemailにマッピングされた属性を見つけます。ソースとして使用されるPingOneユーザー属性をメモします。

  2. SSO属性マッピングを確認: 同じアプリで、SAMLまたはOIDCタブに移動し、emailにマッピングされた属性またはクレームを見つけます。そのソース属性をメモします。

  3. SCIMとSSOが異なるPingOne属性を参照している場合、不一致を確認しました。

ステップ1(代替)— 不一致を確認する(PingFederate)

  1. PingFederate管理コンソールで、ClaudeのSP接続を見つけます。

  2. 属性契約の充足で、email属性を見つけ、そのソースをIdPアダプターまたはLDAPデータストアまでさかのぼって追跡します。

  3. 別途、ClaudeのためのアウトバウンドプロビジョニングチャネルまたはSCIMプロビジョニングコネクターをチェックし、送信されるメール属性のソースを追跡します。

  4. 2つの追跡が異なるディレクトリ属性につながる場合、不一致を確認しました。

ステップ2 — 問題の範囲を特定する

これが1人の影響を受けたユーザーか、システム全体の問題かを判断します:

  • ほとんどまたはすべてのプロビジョニング済みユーザーが同じメールアドレス形式の不一致を共有している場合、これはシステム的な属性マッピングの問題です。修正はIdPのSCIM属性マッピングにあります。

  • 1~2人のユーザーのみが影響を受けている場合、問題はそれらのユーザーアカウントに固有の可能性があります。ユーザープロファイルを直接確認してください。

ステップ3 — 特定のユーザーの属性値を確認する

  1. PingOne: アイデンティティ → ユーザー → [ユーザー]に移動し、ユーザー名メールフィールドの値を比較します。

  2. LDAPを使用したPingFederate: ユーザーのLDAPレコードを確認し、mailuserPrincipalNamesAMAccountName、およびアダプターマッピングで使用されている他の属性を比較します。

解決方法

PingOne — 両方のマッピングをメール属性に合わせる

  1. 接続 → アプリケーション → [Claudeアプリ]で、属性マッピングを開きます。

  2. SCIM:emails[primary].valueがPingOneのメールアドレス属性にマッピングされていることを確認します。

  3. SAML/OIDC:email属性またはクレームもPingOneのメールアドレス属性にマッピングされていることを確認します。

  4. 変更を保存します。

PingFederate — すべてのレイヤーで属性契約を合わせる

  1. Claudeの場合のSP接続で、属性契約の充足に移動します。

  2. email属性を見つけます。そのソースが、SCIMアウトバウンドプロビジョニングチャネルで使用されている同じLDAPまたはデータストア属性であることを確認します。

  3. カスタムIdPアダプターを使用している場合、アダプターの契約に正規のメール属性が含まれており、SP接続に正しくマッピングされていることを確認します。

  4. SCIMプロビジョニングを更新して、同じソース属性を使用するようにします。

完全な再同期をトリガーする

重要 — 完全な同期が必要: 属性マッピングを変更した後、増分同期は既存のユーザーを更新しません。プロビジョニングサイクルの完全な再開始をトリガーする必要があります。

  1. PingOne: アプリのプロビジョニング設定で、完全なプロビジョニングサイクルをトリガーします。すべてのユーザーの完全な再プッシュを強制するために、プロビジョニングを無効にしてから再度有効にする必要がある場合があります。

  2. PingFederate: アウトバウンドプロビジョニングチャネルで完全な同期をトリガーします。プロビジョニングログをチェックして、更新されたメール値が送信されていることを確認します。

  3. ユーザーにログインを再試行するよう依頼する前に、更新されたメール値がプロビジョニングログに表示されていることを確認します。

修正後のクリーンアップ

属性マッピングを修正して完全な同期を完了した後、追加のクリーンアップが必要な場合があります:

  • 不正な無料アカウント: Anthropic Supportに連絡して、これらを削除してもらいます。

  • ゴーストアカウント(間違ったメールシート): Anthropic Supportに連絡して、これらのゴーストアカウントをプロビジョニング解除してもらいます。

  • シートの可用性: ゴーストアカウントがすべての契約シートを占有している場合、新しいログインは失敗します。サポートに連絡してください。

  • 影響を受けたユーザーの再追加: ゴーストアカウントが削除された後、ユーザーは再度招待またはプロビジョニングされる必要がある場合があります。

将来の発生を防ぐ: エンタープライズ設定で「組織の作成を制限」を有効にします。

検証

  1. プロビジョニング済みユーザーのサンプルをチェック — IdPのプロビジョニングログ内のメールアドレスがSSOが送信するメールアドレス形式と一致することを確認します。

  2. 影響を受けたユーザーにclaude.aiのブラウザーキャッシュをクリアしてから、SSOでログインするよう依頼します。

  3. ユーザーが誤って無料アカウントを作成していないことを確認します。

  4. Claude Codeが影響を受けた場合、ユーザーにclaude auth login --enterpriseを再実行してもらい、メールアドレスがエンタープライズシートと一致することを確認します。

一般的な落とし穴

落とし穴

解決方法

PingOneのusernameフィールドがemailの代わりに使用されている

SCIMマッピングをPingOneのメールアドレス属性に切り替えます。

PingFederate属性が契約レイヤー全体で不一致

メール属性をエンドツーエンドで追跡します:LDAPソース → IdPアダプター → アダプター契約 → SPコネクター → アサーション。

LDAP sAMAccountNameまたはuidがメールソースとしてマッピングされている

代わりにLDAP mail属性を使用します。

増分プロビジョニング同期が既存ユーザーを更新しない

属性マッピングを変更した後、完全な再同期が必要です。

PingFederateで属性契約が更新されたがSCIMコネクターが更新されていない

SP接続とアウトバウンドSCIMプロビジョニングチャネルの両方を独立して更新する必要があります。

メールアドレスはSCIMで更新されたがユーザーはまだログインできない

不正な無料組織またはゴーストアカウントをチェックします。ブラウザーキャッシュをクリアして再試行します。

Anthropic Supportに連絡する場合

  • SCIM属性とSSO属性が同じに見えるが、ユーザーはまだシートにアクセスできない。

  • 特定のユーザーについてClaudeがSCIMプロビジョニング中に記録したメールアドレスを確認する必要がある。

  • ゴーストアカウントまたは不正な無料組織のクリーンアップに関するヘルプが必要。

  • 契約に利用可能なシートがあるにもかかわらず、ユーザーがシート不足エラーに直面している。

[email protected]に、組織のドメイン、影響を受けたユーザーのメールアドレス、および属性マッピングのスクリーンショットを添えて連絡してください。

こちらの回答で解決しましたか?