新しい 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 の認証とプロビジョニングを無効にしてから、両方とも再構成します。 既存の構成を認証とプロビジョニングのために編集することはできません。

Enterprise の認証が無効になっている場合、Enterprise の マネージド ユーザー アカウント に関連付けられている既存の SCIM ID は GitHub によって削除されます。 Enterprise 管理ユーザーがいる Enterprise の認証を無効にした場合の影響の詳細については、「Enterprise Managed User の認証を無効にする」を参照してください。

移行の最後に認証とプロビジョニングが再構成された後、ユーザーとグループは新しい IdP またはテナントから再プロビジョニングする必要があります。 ユーザーが再プロビジョニングされると、新しい IdP またはテナントの SCIM ID を既存の Enterprise マネージド ユーザー アカウントにリンクするために、GitHub により、正規化された SCIM userName 属性値が Enterprise 内の GitHub ユーザー名 (_[shortcode] より前の部分) と比較されます。 詳しくは、「外部認証のユーザー名に関する考慮事項」をご覧ください。

前提条件

  • 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 の認証とプロビジョニングを無効にする必要があります。 既存の構成を無効にする前に、次の考慮事項を確認してください。

  • 移行する前に、正規化された SCIM userName 属性の値が新しい環境でマネージド ユーザー アカウントに対して変わらないかどうかを判断します。 新しい IdP またはテナントからプロビジョニングされた SCIM ID が既存の Enterprise 管理ユーザー アカウントに適切にリンクされるようにするには、このようなユーザーの正規化された SCIM userName 属性値を同じまま維持する必要があります。 詳しくは、「外部認証のユーザー名に関する考慮事項」をご覧ください。

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

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

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

  • Enterprise で認証が無効になっている場合、以下の移行手順の一部として、Enterprise 内の SCIM でプロビジョニングされたすべてのグループは、GitHub によって削除されます。 詳しくは、「Enterprise Managed User の認証を無効にする」をご覧ください。

これらの SCIM でプロビジョニングされた IdP グループのいずれかが Enterprise 内のチームにリンクされている場合、GitHub 上のこれらのチームと IdP グループ間のリンクは削除されます。移行後にこれらのリンクが自動的に復元されることはありません。 また、以前にリンクされていたチームからすべてのメンバーは GitHub によって削除されます。 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 Managed User の認証を無効にする」をご覧ください。
  3. GitHub による Enterprise のメンバーの一時停止、リンクされた SCIM ID の削除、SCIM でプロビジョニングされた IdP グループの削除が完了するまで、最長 1 時間かかります。

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

GitHub Enterprise 設定で認証を無効にすると、GitHub により、Enterprise 内のすべての マネージド ユーザー アカウント (セットアップ ユーザー アカウントを除く) は一時停止されます。 Enterprise のメンバーの一時停止は、GitHub で検証できます。

  1. Enterprise の保留にされたメンバーを表示します。 詳しくは、「Enterprise の人を表示する」をご覧ください。
  2. Enterprise 内のすべてのマネージド ユーザー アカウントがまだ一時停止されていない場合は、次の手順に進む前に、GitHub で引き続き待機し、監視してください。

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

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

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

7.ユーザーとグループが新しい IdP またはテナントから再プロビジョニングされていることを確認します

  1. マネージド ユーザー アカウント の一時停止を解除し、GitHub へのサインインを許可するには、ユーザーを新しい IdP またはテナントから再プロビジョニングする必要があります。 これにより、新しい IdP またはテナントの SCIM ID が既存の Enterprise マネージド ユーザー アカウントにリンクされます。 Enterprise マネージド ユーザーがサインインするには、リンクされた SCIM ID が必要です。
    • IdP ユーザー アカウントを再プロビジョニングするときに、ユーザーが新しい IdP テナントから SCIM ID に正常にリンクされている場合は、Enterprise 設定のページに SSO identity linked リンクが表示され、SCIM 属性を含む SCIM identity セクションが表示されます。 詳しくは、「Enterprise の人を表示する」をご覧ください。
    • Enterprise 監査ログで関連する external_identity.* および user.unsuspend イベントをレビューすることもできます。 詳細については、「エンタープライズの監査ログ イベント」を参照してください
  2. 新しい IdP またはテナントからもグループを再プロビジョニングする必要があります。
  3. IdP グループが Enterprise に再プロビジョニングされると、管理者は必要に応じてそのグループを Enterprise 内のチームにリンクできます。

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

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