LDAP から SAML および SCIM への移行について
GitHub Enterprise Server インスタンスで現在 LDAP 認証が使用されている場合は、SCIM プロビジョニングを使用して SAML シングル サインオン (SSO) に移行して、ユーザー ライフサイクル管理機能を強化できます。 この移行により、ID プロバイダー (IdP) からユーザー アカウントを自動的にプロビジョニング、更新、プロビジョニング解除できます。
メモ
SAML または LDAP のどちらか一方だけを使用でき、両方は使用できません。
**前提条件:**
- GitHub Enterprise Server のサイト管理者である必要があります。
- SAML ID プロバイダーへの管理アクセス権が必要です。
- IdP は SAML 2.0 および SCIM 2.0 プロトコルをサポートする必要があります。
- 移行を開始する前に、インスタンスのバックアップを完了する必要があります。
SCIM プロビジョニングには前提条件として SAML 認証が必要であるため、この移行には次の 4 つの異なるフェーズが含まれます。
-
**SAML 認証への移行**: LDAP を SAML SSO に置き換えます。 -
**SAML をテストして確認**する: 認証が機能し、ユーザーが正しくリンクされていることを確認します。 -
**SCIM プロビジョニングを有効にする**: 自動化されたユーザー管理機能を追加します。 -
**SCIM をテストして確認**する: 既存のアカウントへのリンク ID のプロビジョニングを確認します。
このドキュメントでは、SAML 認証と SCIM プロビジョニングに関する知識を前提としています。 これらのトピックの詳細については、 Enterprise 向けの SAML シングルサインオンを設定する と GitHub Enterprise Server での SCIM を使用したユーザー プロビジョニングについて を参照してください。
1. LDAP と SCIM のユーザー作成パターンについて
移行を開始する前に、GitHub Enterprise Server での LDAP と SCIM によるユーザー管理の処理方法の主な違いを理解しておくことが重要です。
| 特性 | LDAP | SCIM |
|---|
**アプライアンスの構成** | 管理コンソールで、ユーザー ID 属性 (既定の `uid`) とその他の LDAP 設定を構成します。 この構成により、LDAP ユーザーと GitHub ユーザーの間でマップする方法が決まります。 LDAP の構成の詳細については、 [AUTOTITLE](/admin/managing-iam/using-ldap-for-enterprise-iam/using-ldap#ldap-attributes) を参照してください。 | 最初に SAML 認証を有効にしてから、認証トークンを使用して SCIM プロビジョニングを構成します。 |
|
ユーザー作成のタイミング | Just-In-Time: LDAP 認証が成功した後、ユーザーは最初のサインイン時に作成されます。 | 事前認証: ユーザーを認証するには、SCIM を使用してプロビジョニングする必要があります。 |
|
初期ユーザー名ソース | GitHubユーザー名は、セットアップ時に構成された正規化された LDAP 識別子に基づいています。 | GitHubユーザー名は、IdP の正規化された SCIM userName 値に基づいています。 |
|
ユーザー名の管理 | 柔軟: 管理者は、LDAP とは別GitHubユーザー名を変更できます。 ユーザー名は、LDAP マッピングによる認証を維持しながら、時間の経過と伴って LDAP 識別子から誤差が出る可能性があります。 「ユーザー名の参照」を参照してください。 | 厳密に言えば、GitHubユーザー名は常に、IdPから提供される正規化されたSCIM userNameに対応しています。 GitHub側でのユーザー名の変更は許可されていません。 |
|
ユーザー属性コントロール | ハイブリッド: LDAP によって管理される属性もあれば、アプライアンスで管理できる属性もあります。 | 完全な IdP 制御: すべてのユーザー属性は、IdP からの SCIM 更新によって管理されます。 |
|
認証フロー | GitHub Enterprise Server は、LDAP サーバーを使用して認証を行い、既存の LDAP マッピングを検索してユーザーを見つけます。 | SAML SSO 中に、認証用にプロビジョニングされたユーザーを見つけるために外部 ID 参照が実行されます。 |
|
主な特性 | GitHubユーザー データ (特にユーザー名) を LDAP サーバーとは別にアプライアンスで部分的に管理できるハイブリッド システム。 | 完全なIDプロバイダーによる制御: GitHubユーザーの状態は、IdPがSCIMを通じて送信する内容に完全に依存し、ユーザー名がソースシステムから逸れることはありません。 |
ユーザー名の正規化と互換性
GitHub Enterprise Server は、LDAP、SAML、SCIM の各プロトコルにわたって、一貫性のある方法で適用される特定の規則に基づきユーザー名を正規化します。 移行を成功させるには、これらの規則を理解することが重要です。
ユーザー名の正規化の詳細については、 AUTOTITLE を参照してください。
2. 移行を計画する
移行を開始する前に、現在のセットアップを理解し、ID プロバイダーを準備し、バックアップ アクセス方法を確立する必要があります。 計画フェーズは、スムーズな移行を確保するために不可欠です。
LDAP から SCIM へのマップの準備
移行の重要な課題は、LDAP と SCIM のユーザー管理アプローチの間のブリッジングです。
**LDAP ユーザー (既存の状態)**:
-
最初の作成以降に変更された可能性のある GitHub ユーザー名がある
-
ユーザー名の変更に関係なく、LDAP マッピングを使用して認証機能を保持する
**SCIM ユーザー (ターゲットの状態)**: -
認証前にプロビジョニングする必要がある
-
正規化された SCIM
userName値と一致するGitHubユーザー名が必要です -
SCIM ユーザー プロビジョニング中に、既存のGitHub アカウントを使用して外部 ID にリンクできますが、正規化された SCIM
userNameが既存の GitHub ユーザー名と一致する場合のみ
移行マッピングの要件
SCIM ID を既存の LDAP ユーザーに正常にリンクするには、インスタンス上のユーザーの現在の状態をキャプチャする必要があります。
-
**Export existing GitHub usernames**: サイト管理者インターフェイス、API、または CLI を使用して、インスタンス上の現在のGitHubユーザー名の完全な一覧を取得します。 ユーザー API の詳細については、「 [AUTOTITLE](/rest/users/users?apiVersion=2022-11-28#list-users)」を参照してください。 ユーザーをエクスポートするコマンド ライン ユーティリティの詳細については、「 [AUTOTITLE](/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities#ghe-user-csv)」を参照してください。 -
**IdP**内のGitHubユーザー名を実際のユーザーに対応付ける: 企業内の各GitHubユーザー名に対応するIDを決定します。 -
** SCIM `userName` 属性を構成します**: リンクする既存の GitHub ユーザー名と一致する `userName` 値を持つ SCIM ユーザーが IdP によってプロビジョニングされていることを確認します。 **Important**: マッピングのターゲットは常に、元の LDAP ユーザー ID やその他の識別子ではなく、インスタンスの**現在GitHubユーザー名**です。
計画に関する主な考慮事項
**重要な考慮事項:**
* ダウンタイムが必要: この移行では、認証設定を変更するためにメンテナンス期間中のダウンタイムが必要です。 * ユーザーへの影響: 移行後、ユーザーは LDAP 資格情報ではなく SAML IdP を使用して認証する必要があります。 * チーム メンバーシップ: LDAP チームの同期は、IdP でサポートされている場合、SCIM グループ プロビジョニングに置き換えられます。 LDAP マップされたチームは、該当する場合は適切な SCIM グループで更新する必要があります。
LDAP 構成の状態をキャプチャする
現在の LDAP セットアップを記録して、同等の SAML/SCIM マッピングを計画します。
- GitHub Enterprise Server の管理アカウントから、任意のページの右上隅にある をクリックします。
- [サイト管理者] ページにまだ表示されていない場合は、左上隅の [サイト管理者] をクリックします。1. [ Site admin] サイドバーで、[[Management Console]] をクリックします。1. [設定] サイドバーで [認証] をクリックします。
- 次の LDAP 設定を文書化します。 * ドメイン ベース と制限付きユーザー グループ * User ID 属性 (これはユーザー名GitHub作成するために使用されました) * プロファイル名、電子メール、およびその他の属性マッピング * Administrators グループの構成 * チーム同期の設定
- SCIM ID にリンクする既存のユーザーの一覧をインスタンスに保存していることを確認します。
3. SAML と SCIM に移行する
計画が完了したら、LDAP から SAML 認証への移行を開始できます。 これには、アイデンティティープロバイダーと GitHub Enterprise Server の両方で SAML を設定し、SCIM に進む前にその設定を慎重にテストすることが必要です。
**重要**: SAML を構成する場合は、SCIM を有効にする際に必要な手順の数を減らすために、"組み込み認証を使用したアカウントの作成を許可する" を有効にします。
SAML 認証の有効化
SAML 構成の詳細な手順については、 Enterprise 向けの SAML シングルサインオンを設定する を参照してください。
SAML を有効にした後、SCIM に進む前に認証システムをテストします。 インスタンスに対して構成された SAML アプリケーションに割り当てられている IdP アカウントがあれば、SSO ログインを正常に実行できることを確認します。
**SAML 認証が正しく機能するまで SCIM に進む必要はありません。**
SCIM プロビジョニングを有効にする
SAML 認証が正しく動作することを確認したら、SCIM を有効にしてユーザー管理を自動化できます。 SCIM は、GitHub Enterprise Server と ID プロバイダーの両方で構成する必要があります。
SCIM を有効にする詳細な手順については、 Migrating from LDAP to SAML with SCIM を参照してください。
SCIM プロビジョニングをテストする
SCIM プロビジョニングをテストして、SCIM プロビジョニングされたユーザーが既存のユーザー アカウントに正しくリンクされていることを確認します。
LDAP/SAML 移行のアカウントを既に持っているユーザーの場合:
- IdP で SCIM アプリケーションにユーザーを割り当てます。
-
**自動リンクの確認**: SCIM が既存のアカウントに自動的にリンクされていることを確認します。- ユーザーが同じユーザー名とアカウント データを保持する
- 重複するアカウントは作成されません
- SCIM ID は、エンタープライズ設定とサイト管理者インターフェイスでリンク済みとして表示されます。 詳しくは、「Enterprise へのユーザの SAML アクセスの表示および管理」をご覧ください。
-
**監査ログを確認**する: 既存のユーザーへのリンクが成功したことを示す `external_identity.scim_api_success` イベントと `external_identity.provision` イベントを探します。
インスタンス内にない新しいユーザーの場合:
-
**ユーザーの作成を確認**する: ユーザーが正しい属性を持つ GitHub Enterprise Server に表示されていることを確認します。 -
**認証のテスト**: 新しいユーザーが SAML 経由で認証できることを確認します。 -
**テスト属性の更新**: IdP でユーザー情報を更新し、変更の同期を確認します。 -
**プロビジョニング解除のテスト**: ユーザー アクセスを削除し、中断されていることを確認します。
SCIM をすべてのユーザーにロールアウトする
SCIM 経由でまだプロビジョニングされていない残りのユーザーの場合:
-
使用中の IdP 内にある GitHub Enterprise Server アプリケーションに対して、**ユーザーを段階的に割り当てます**。 -
**リンク プロセスを監視**する: ユーザー名の照合に基づいて自動リンクが成功するのを監視します。 -
**進行状況の追跡**: 監査ログを使用して、リンクの進行状況 `external_identity` イベントを監視します。 -
**競合に対処する**: 発生したユーザー名の競合またはマッピングの問題を解決します。
4. チームと組織のメンバーシップを更新する
移行後に LDAP グループ同期を使用してチーム メンバーシップを制御していた場合は、それらのチーム マッピングを SCIM グループに置き換えることができます。 既存のチームを再利用する場合は、IdP グループをリンクする前にすべてのチーム メンバーを削除する必要があります。
詳しくは、「ID プロバイダー グループを使用したチーム メンバーシップの管理」をご覧ください。