新しい ID プロバイダーまたはテナントへの Enterprise の移行

Security Assertion Markup Language(SAML)または OpenID Connect(OIDC)と SCIM を最初に構成した後、Enterprise が新しい ID プロバイダー(IdP)またはテナントを認証とプロビジョニングに使用する場合、新しい構成に移行できます。

この機能を使用できるユーザーについて

Enterprise owners and people with administrative access to your IdP can migrate your enterprise to a new IdP or tenant.

GitHub Enterprise Cloud で Enterprise Managed Users を使用するエンタープライズ アカウントで使用できます。 「Enterprise Managed Users について」をご覧ください。

この記事の内容

IdP とテナント間の移行について

Enterprise Managed Usersを使用するとき、Enterprise を IdP の新しいテナントまたは別の ID 管理システムに移行する必要がある場合があります。 たとえば、テスト環境から運用環境に移行する準備ができていたり、会社が新しい ID システムを使用することを決定したりしている場合があります。

新しい認証とプロビジョニングの構成に移行する前に、準備の前提条件とガイドラインを確認してください。 移行の準備ができたら、Enterprise の認証とプロビジョニングを無効にしてから、両方とも再構成します。 既存の構成を認証とプロビジョニングのために編集することはできません。

前提条件

  • GitHub Enterprise Cloudの使用を開始したとき、マネージド ユーザーを含む Enterpriseを作成することを選択している必要があります。 詳しくは、「GitHub Enterprise Cloud の Enterprise の種類の選択」を参照してください。
  • 外部 ID 管理システムからEnterprise Managed Usersと統合するための要件を確認して理解する必要があります。 構成とサポートを簡略化するため、"舗装されたパス"統合に 1 つのパートナー IdP を使用できます。 または、Security Assertion Markup Language(SAML) 2.0 とクロスド メイン ID 管理システム(SCIM) 2.0 規格に準拠するシステムを使用して認証を構成することもできます。 詳しくは、「Enterprise Managed Users について」をご覧ください。
  • Enterpprise の認証と SCIM プロビジョニングを既に構成している必要があります。

移行の準備

認証とプロビジョニング用に新しい構成に移行するには、まず Enterprise の認証とプロビジョニングを無効にする必要があります。 既存の構成を無効にする前に、次の考慮事項を確認してください。

  • GitHubは、Enterprise のマネージド ユーザー アカウントに関連付けられた SCIM レコードをリセットします。 移行する前に、正規化された SCIM userName 属性の値が新しい環境でマネージド ユーザー アカウントに対して変わらないかどうかを判断します。 詳しくは、「外部認証のユーザー名に関する考慮事項」をご覧ください。

    • 移行後も正規化された SCIM userName 値が変わらない場合、ご自身で移行を完了できます。
    • 移行後に正規化された SCIM userName 値が変わる場合は、GitHub による移行のサポートが必要になります。 詳しくは、「正規化された SCIM userName 値が変わる場合の移行」をご覧ください。

  • 移行が完了するまで、ID 管理システムのEnterprise Managed Usersのアプリケーションからユーザーやグループを削除しないでください。

  • GitHub Enterprise Cloudは、Enterprise のマネージド ユーザー アカウントに関連付けられたpersonal access tokensまたは SSH キーを削除します。 再構成後の移行期間を計画し、その期間中に外部統合に対して新しい認証情報を作成して提供できます。

  • GitHub Enterprise Cloudは、GitHubと IdP グループのチーム間の接続を削除し、移行後に接続を復帰させません。 また、GitHubはチームからすべてのメンバーを削除し、チームが IdP に接続されない状態にします。 ID 管理システムでグループを使用して組織またはライセンスへのアクセスを管理する場合、中断が発生する可能性があります。 GitHubは、移行前にREST API を使用してチーム接続とグループ メンバーシップをリストし、後で接続を復帰させることをお勧めします。 詳しくは、REST API ドキュメントの「外部グループの REST API エンドポイント」をご覧ください。

新しい IdP またはテナントへの移行

新しい IdP またはテナントに移行するには、次のタスクを完了する必要があります。

  1. 一致する SCIM userName 属性を検証する。
  2. シングル サインオンのリカバリー コードをダウンロードする。
  3. 現在の IdP でプロビジョニングを無効にする。
  4. Enterprise の認証とプロビジョニングを無効にする。
  5. Enterprise のメンバーの保留を検証する。
  6. 認証とプロビジョニングを再構成する。

1. 一致する SCIM userName 属性を検証する

シームレスな移行を行う場合、新しい SCIM プロバイダーの SCIM userName 属性が、古い SCIM プロバイダーの属性と一致することを確認します。 これらの属性が一致しない場合は、「正規化された SCIM userName 値が変わる場合の移行」をご覧ください。

2. シングル サインオンのリカバリー コードをダウンロードする

Enterprise のシングル サインオン回復コードがまだない場合は、今すぐコードをダウンロードしてください。 詳しくは、「エンタープライズ アカウントのシングル サインオンの回復コードをダウンロードする」をご覧ください。

3. 現在の IdP でプロビジョニングを無効にする

  1. 現在の IdP で、Enterprise Managed Usersのアプリケーションでプロビジョニングを非アクティブ化します。
    • Entra ID を使用する場合は、アプリケーションの [プロビジョニング] タブに移動し、[プロビジョニングの停止] をクリックします。
    • Okta を使用する場合は、アプリケーションの [プロビジョニング] タブに移動し、 [統合] タブをクリックしてから、 [編集] をクリックします。 [API 統合を有効にする] の選択を解除します。
    • PingFederate を使う場合は、アプリケーションのチャネル設定に移動します。 [アクティブ化と概要] タブで、 [アクティブ] または [非アクティブ] をクリックしてプロビジョニングの状態を切り替えてから、 [保存] をクリックします。 プロビジョニングの管理の詳細については、PingFederate ドキュメントの「チャンネル設定のレビュー」と「チャンネルの管理」を参照してください。
    • 別の ID 管理システムを使用する場合、システムのドキュメント、サポート チーム、その他のリソースを確認してください。

4. Enterprise の認証とプロビジョニングを無効にする

  1. リカバリー コードを使用して、セットアップ ユーザーとして GitHub にサインインします。そのユーザー名は、お客様の企業のショートコードに _admin を付けたものです。 セットアップ ユーザーについて詳しくは、「Enterprise Managed Users の概要」をご覧ください。
  2. Enterprise の認証とプロビジョニングを無効にする。 詳しくは、「Enterprise Manged User の認証とプロビジョニングを無効にする」をご覧ください。
  3. GitHub Enterprise Cloudが Enterprise の SCIM レコードをリセットして Enterprise のメンバーを保留にするまで、最大 1 時間待ちます。

5. Enterprise のメンバーの保留を検証する

認証とプロビジョニングを無効にすると、GitHub Enterprise Cloudは Enterprise のすべてのマネージド ユーザー アカウントを保留にします。 Web UI を使用して Enterprise のメンバーの保留を検証できます。

  1. Enterprise の保留にされたメンバーを表示します。 詳しくは、「Enterprise の人を表示する」をご覧ください。

  2. Enterprise のすべてのメンバーがまだ保留にされていない場合、待ち続けて SCIM プロバイダーのログを確認します。

    • Entra ID を使用する場合、メンバーの保留が最大 40 分かかる場合があります。 個々のユーザーのプロセスを迅速化するには、Enterprise Managed Users のアプリケーションの [プロビジョニング] タブにある [オンデマンドでプロビジョニング] ボタンをクリックします。

6. 認証とプロビジョニングを再構成する

Enterprise のメンバーの保留を検証したら、認証とプロビジョニングを再構成します。

  1. SAML または OIDC SSO を使用して認証を構成します。 詳しくは、「Enterprise Managed User の認証を構成する」をご覧ください。
  2. SCIM プロビジョニングを構成します。 詳しくは、「Migrating your enterprise to a new identity provider or tenant」をご覧ください。

マネージド ユーザー アカウントを保留解除してGitHub Enterprise Cloudにログインできるようにするには、SCIM プロバイダーがアカウントを再プロビジョニングする必要があります。

正規化された SCIM userName 値が変わる場合の移行

正規化された SCIM userName 値が変わる場合は、GitHub で移行用に新しい Enterprise アカウントをプロビジョニングする必要があります。 サポートについては、営業チームにお問い合わせください。