Azure AD SCIM設定 — SCIM Azureプロビジョニングガイド

前提条件

• 管理者アクセスを持つAzure ADテナント
• SecureCodingHub組織管理者アカウント
• SSOの構成 (推奨ですが必須ではありません)

ステップ1 — SCIMトークンを生成

ステップ2 — Azure ADでプロビジョニングを構成

ステップ3 — 属性マッピングを構成

Azure ADプロビジョニング構成で次の属性が正しくマップされていることを確認してください。SecureCodingHubはユーザーごとに単一のEmailフィールドを保存することに注意してください — userPrincipalName → userNameマッピングとmail → emails[work].valueマッピングの両方が最終的に同じフィールドに解決されます。テナントでuserPrincipalNameとmailが異なる場合は、ユーザーがサインインする値を両方とも指すように構成してください。

ステップ4 — プロビジョニングを開始

ステップ5 — 確認

Azure AD SCIMのデプロイ前チェックリスト

2つの初期決定が、Azure AD SCIMデプロイの残りを形作ります。1つ目は、ギャラリーアプリケーションを使用するか、非ギャラリーエンタープライズアプリケーションを使用するかです。SecureCodingHubは現在Microsoft Entraアプリケーションギャラリーにリストされていないため、New applicationスクリーンから非ギャラリーエンタープライズアプリを作成します。これは通常のサポートされるパスです。ギャラリーアプリは存在するときに便利ですが、SCIMプロビジョニングが機能するために必須ではなく、手動セットアップにより、クレーム名と割り当てスコープの制御が得られます。

2つ目の決定は、プロビジョニングと割り当ての関係です。Entra IDでのプロビジョニングは自動的にアクセスと等しくありません。Provisioningブレードでプロビジョニングを構成しますが、ユーザーはUsers and groupsでアプリケーションに割り当てられた場合にのみ同期されます。割り当てステップをスキップすると、プロビジョニングサイクルが実行され、ゼロの変更を報告し、これがしばしば1時間の無駄な調査につながります。Provisioningブレードのスコープ設定が割り当て戦略と一致することを確認してください: Sync only assigned users and groupsは、テナント内のすべてのライセンスユーザーをSecureCodingHubに着地させたいわけではない場合の安全なデフォルトです。

同期が停止した場合

Azure ADは、SCIMエンドポイントから繰り返しエラーを見ると、プロビジョニングジョブを隔離します。隔離バナーはProvisioningブレードの上部に表示され、停止した同期の最も一般的な原因です。原因はいくつかのバケットに分かれます。認証失敗は典型的な最初の隔離です: SecureCodingHubで再生成または取り消されたSCIMトークンがまだAzure ADに貼り付けられている。SecureCodingHubで新しいトークンを生成し、Secret Tokenフィールドに貼り付け、Test Connectionが成功するまでクリックし、Restart provisioningをクリックして隔離をクリアします。

スキーマの不一致は2つ目のバケットです。属性マッピングテーブルをカスタマイズし、エンドポイントが公開しないSCIM属性を参照する場合、Azure ADはスキーマエラーをログに記録し、処理を停止します。SCIM概要ページで確認されたデフォルトマッピングに戻し、ベースラインが機能した後にのみカスタムマッピングを追加します。3つ目のバケットはレート制限です: 非常に大きなテナントは初期サイクル中に分あたりの制限に達する可能性があり、Azure ADはこれをサービスエラーとして解釈します。これを疑う場合は、初期同期をより小さな割り当てグループにスコープし、完了させてから、割り当てを拡張します。