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

SSO/SCIM メール不一致 — Okta

概要: Claudeはメールを主要な識別子として使用し、SSO ログインをプロビジョニングされたシートにマッチングします。Okta では、SCIM プロビジョニングと SSO はアプリの別々のセクションで設定され、異なる Okta ユーザープロフィールフィールドからメールを取得できます。このガイドでは、不一致を特定して修正する方法について説明します。

症状

ユーザーが SSO 経由で Claude for Enterprise にアクセスしようとする際に、以下の 1 つ以上の問題が発生する可能性があります:

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

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

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

  • Claude Code 認証エラー — Claude Code CLI がメール不一致エラーを表示します。

これが発生する仕組み

Okta ユーザープロフィールには、ID を表す複数のフィールドが含まれています。SCIM プロビジョニング(プロビジョニング → アプリへ)と SAML/OIDC SSO(サインオン)は独立して設定されます:

Okta 属性

典型的な値

一般的に使用される場所

user.login

testuser1 または [email protected]

デフォルト SCIM userName マッピング。時々 NameID

user.email

SAML/OIDC メールクレーム(推奨)

appuser.email

ユーザーメールのアプリレベルオーバーライド

カスタムアプリレベル属性マッピング

一般的な不一致:SCIM が user.login を使用する一方、SAML が user.email を送信します。Claude は完全な文字列一致を必要とします。

一般的な混乱: Okta の SCIM 属性マッピングと SAML 属性ステートメントは 2 つの異なるタブに存在します — SCIM の場合はプロビジョニング → アプリへ、SSO の場合はサインオンです。両方を確認する必要があります。

診断手順

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

  1. SCIM メールを確認: Okta 管理コンソールで、アプリケーション → [Claude アプリ] → プロビジョニング → アプリへ → 属性マッピングに移動します。email(または Claude 側でメールにマップされる場合は userName)の行を見つけます。列は、送信される Okta 式またはフィールドを表示します。

  2. SSO メール(SAML)を確認: アプリケーション → [Claude アプリ] → サインオン → SAML 設定 → 編集 → 属性ステートメントに移動します。emailという名前の属性を見つけます。列は、ログイン時にアサートされる Okta フィールドを表示します。

  3. SSO メール(OIDC)を確認: アプリケーション → [Claude アプリ] → サインオン → OpenID Connect ID トークンに移動し、クレームセクションでメールクレームを確認します。

  4. SCIM と SSO の値が異なる Okta フィールドを参照している場合、不一致が確認されました。

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

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

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

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

ステップ 3 — Okta ユーザープロフィールを直接確認する

影響を受けた個別ユーザーについて、実際のフィールド値を確認します:

  1. ディレクトリ → ユーザー → [ユーザー] → プロフィールに移動します。

  2. ログインメールフィールドの値を比較します。異なる場合、ログインメールを使用するマッピングは不一致を生成します。

解決方法

両方のマッピングを同じ Okta フィールドに合わせる

最も安全な修正は、SCIM と SSO の両方に user.email を使用することです。このフィールドは Okta の正規メールアドレスを含むためです。

  1. SCIM マッピングを更新: プロビジョニング → アプリへ → 属性マッピングで、email(または userName)ソースを user.email に変更します。

  2. SSO クレーム(SAML)を更新: サインオン → SAML 設定 → 属性ステートメントで、email属性値を user.email に変更します。

  3. SSO クレーム(OIDC)を更新: サインオン → OpenID Connect ID トークン → クレームで、メールクレームを user.email にマップするように更新します。

  4. 保存をクリックします。

完全な再同期を強制する

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

  1. プロビジョニング → アプリへで、同期を強制をクリックして、割り当てられたすべてのユーザーの完全な再評価をトリガーします。

  2. または、対象ユーザーの場合:プロビジョニング → ユーザーをプッシュ → 影響を受けたユーザーを選択 → 今すぐプッシュ

  3. Okta システムログ(レポート → システムログ)でプロビジョニングエラーを確認します。

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

修正後のクリーンアップ

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

  • 不正な無料アカウント:修正前に組織の作成が制限されていなかった場合、一部のユーザーが誤って無料の個人 Claude アカウントを作成している可能性があります。Anthropic サポートに連絡して、これらを削除してもらいます。

  • ゴーストアカウント(間違ったメールシート):元々プロビジョニングされたアカウント(間違ったメール付き)がエンタープライズ組織に存在し、使用できないシートを占有している可能性があります。Anthropic サポートに連絡して、これらのゴーストアカウントをデプロビジョニングしてもらいます。

  • シート可用性:ゴーストアカウントがすべての契約済みシートを占有している場合、マッピングが修正された後でも、新しいログインはシート不足エラーで失敗します。この場合はサポートに連絡してください。

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

将来の発生を防ぐ:エンタープライズ設定で「組織作成を制限」を有効にします。これにより、まだプロビジョニングされていないユーザーが誤って無料の個人アカウントを作成するのを防ぎます。

検証

修正とクリーンアップを完了した後、以下を確認します:

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

  2. 影響を受けたユーザーに claude.ai のブラウザクッキーをクリアしてから、SSO 経由でログインするよう依頼します。エラーなしでエンタープライズワークスペースに直接ランディングする必要があります。

  3. ユーザーが誤って無料アカウントを作成していないことを確認します — 組織の作成が制限されている場合、ブロックされたユーザーは個人アカウントにランディングするのではなく、明確なエラーが表示されます。

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

一般的な落とし穴

落とし穴

解決方法

管理者が SAML クレームを更新しますが、SCIM 属性マッピング(またはその逆)を忘れます

両方を更新する必要があります。SCIM マッピングはプロビジョニング → アプリへの下にあります。SAML クレームはサインオン → SAML 設定の下にあります。

user.login に一部のユーザーのユーザー名(メールではない)が含まれています

両方を user.email に切り替え、すべてのユーザーのメールフィールドが入力されていることを確認します。

増分同期が実行されますが、メールが更新されません

属性マッピング変更後、同期を強制またはユーザーをプッシュする必要があります。

アプリレベルプロフィール属性(appuser.email)がユーザープロフィール(user.email)と異なります

アプリレベル属性マッピングがユーザープロフィール値をオーバーライドしているかどうかを確認します。

メールが更新されましたが、ユーザーはまだログインできません

不正な無料組織またはゴーストアカウントを探します。ブラウザクッキーをクリアして再試行します。問題が解決しない場合は Anthropic サポートに連絡してください。

OIDC と SAML アプリが Claude の別々の Okta アプリです

一部の組織は両方を設定しています。両方のアプリで属性の整合性を確認してください。

Anthropic サポートに連絡する場合

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

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

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

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

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

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