新しい 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.

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

この記事で

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

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

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

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

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

前提条件

  • GitHub Enterprise Cloud の使用を開始するときは、マネージド ユーザーを含む Enterprise を作成することを選んでいる必要があります。 詳しくは、「GitHub Enterprise Cloud におけるエンタープライズ種別の選択」をご覧ください。
  • 外部 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は、企業のpersonal access tokensに関連付けられているマネージド ユーザー アカウントまたは SSH キーを削除します。 再構成後の移行期間を計画し、その期間中に外部統合に対して新しい認証情報を作成して提供できます。

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

これらの SCIM プロビジョニング IdP グループのいずれかが社内のチームにリンクされている場合、これにより、 GitHub グループと IdP グループ上のこれらのチーム間のリンクが削除され、移行後にこれらのリンクは自動的に復元されません。 GitHubでは、以前にリンクされたチームからすべてのメンバーも削除されます。 ID 管理システムでグループを使用して組織またはライセンスへのアクセスを管理する場合、中断が発生する可能性があります。 GitHub では、移行する前に REST API を使用してチーム接続とグループ メンバーシップを一覧表示し、後で接続を再開することをお勧めします。 詳細については、REST API ドキュメントの「外部グループの REST API エンドポイント」を参照してください。

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

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

  1. 一致する SCIM userName 属性を検証する。
  2. シングル サインオンのリカバリー コードをダウンロードする。
  3. 現在の IdP でプロビジョニングを無効にする。
  4. エンタープライズの認証を無効にします。
  5. エンタープライズ メンバーの停止を検証します。
  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 が貴社のメンバーの活動を停止し、関連する SCIM ID を削除し、SCIMでプロビジョニングされた IdP グループを削除するのを待ちます。

メモ

  • 認証を無効にした後、GitHubは、この記事の残りの手順に進む前に完了する必要がある複数のバックグラウンド タスクを実行します。 大企業の場合、これには数時間または数日かかる場合があります。
  • 完了を確認するには、エンタープライズの認証設定ページ (エンタープライズ設定→認証セキュリティ) に移動します。 タスクの実行中は、[OIDC 構成を有効にする] または [SAML 構成の追加] ボタンが無効になり、"以前の SAML プロバイダーが削除されています" のような警告が表示されます。

あなたの企業メンバーの停止を検証する

GitHubエンタープライズ設定で認証を無効にすると、GitHubは企業内のすべてのマネージド ユーザー アカウント (セットアップ ユーザー アカウントを除く) を一時停止します。 GitHubで企業のメンバーの一時停止を検証できます。

  1. Enterprise の保留にされたメンバーを表示します。 詳しくは、「企業内の従業員を表示する」をご覧ください。
  2. 企業内のすべての管理対象ユーザー アカウントがまだ中断されていない場合は、次の手順に進む前に、 GitHub で待機と監視を続行します。

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

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

  1. SAML または OIDC SSO を使用して認証を構成します。 詳しくは、「Enterprise Managed User の認証を構成する」をご覧ください。
  2. SCIM プロビジョニングを構成します。 詳しくは、「エンタープライズ マネージド ユーザー を管理するための SCIM プロビジョニングの構成」をご覧ください。

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

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

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

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