Skip to main content

GitHub AE を初期化する

GitHub AE の初期設定を完了して Enterprise で使用できるようにします。

初期化について

Enterprise を初期化する前に、GitHub AE を購入する必要があります。 詳細については、GitHub の営業チーム にお問い合わせください。

GitHub AE を購入後、Enterprise を初期化するユーザのメールアドレスとユーザ名を入力するように求められます。 GitHub Enterprise サポート の専任のテクニカルアカウントマネージャーが Enterprise オーナーのアカウントを作成し、Enterprise オーナーにメールを送信して GitHub AE にログイン後、初期化を完了します。 指定した情報が、ID プロバイダーの目的の Enterprise 所有者の情報と一致していることを確認します。 Enterprise 所有者の詳細については、「Enterprise におけるロール」を参照してください。

:

  • 初期化を完了する前に GitHub AE の初期パスワードの有効期限が切れた場合は、招待メールからいつでもパスワード リセットを要求できます。

  • パスワード マネージャーで GitHub AE の初期ユーザー名とパスワードを安全に保存します。 If you can't sign into your enterprise because GitHub AE can't communicate with your SAML IdP, you can contact GitHub Support, who can help you access GitHub AE to update the SAML SSO configuration. For more information, see "Receiving help from GitHub Support."

初期化中に、Enterprise オーナーは Enterprise に名前を付け、SAML SSO を設定し、Enterprise 内のすべての Organization のポリシーを作成して、ユーザのサポート連絡先を設定します。

前提条件

初期化を開始するにあたり、GitHub から招待メールを受け取ります。 GitHub AE を構成する前に、次の前提条件を確認してください。

  1. your enterprise を初期化するには、SAML アイデンティティプロバイダ (IdP) が必要です。 GitHub AEは、ユーザ認証にSAML SSOを使用します。 GitHub AEへのアクセスは、SAML 2.0標準をサポートするIdPから集中管理できます。 初期化中に IdP を Enterprise に接続するには、IdP のエンティティ ID (SSO) URL、発行者 ID URL、公開署名証明書 (Base64 エンコード) が必要です。 詳細については、Enterprise の ID およびアクセス管理に関するページを参照してください。

    : GitHub AE上の最初のEnterpriseオーナーアカウントと関連づけるための、専用のマシンユーザアカウントをIdPで作成して使用してください。 このユーザアカウントの認証情報は、パスワードマネージャに安全に保存してください。

  2. 人をEnterpriseのオーナーにするには、所有権をIdPで委任しなければなりません。 IdP のユーザー アカウントに対して、SAML アサーションの administrator 属性を、値を true にして含めます。 Enterprise 所有者の詳細については、「Enterprise におけるロール」を参照してください。

サインインして Enterprise に名前を付ける

  1. ようこそメールの指示に従って、Enterprise にアクセスします。
  2. パスワードの変更 の下に資格情報を入力し、パスワードの変更 をクリックします。
  3. [Enterprise アカウントの名前を入力してください] の下に会社の名前を入力し、 [保存して続行] をクリックします。 Enterprise に名前を付けるための [保存して続行] ボタン

IdP を Enterprise に接続する

GitHub AE の認証を設定するには、GitHub AE に SAML IdP の詳細を提供する必要があります。 GitHub は、IdP として Azure AD を使用することを推奨しています。 詳細については、「ID プロバイダーで認証とプロビジョニングを設定する」を参照してください。

  1. [ID プロバイダーの設定] の右側にある [構成] をクリックします。 IdP 構成の [構成] ボタン
  2. [Sign on URL] で、SAML IdP の URL をコピーして貼り付けます。 SAML IdP のサインオン URL のテキスト フィールド
  3. [Issuer] の下に、SAML IdP の発行者 URL をコピーして貼り付けます。 SAML IdP の発行者 URL のテキスト フィールド
  4. [Public certificate] の下で、SAML IdP の公開証明書をコピーして貼り付けます。 SAML IdP の公開証明書のテキスト フィールド
  5. [SAML 構成のテスト] をクリックして、入力した情報が正しいことを確認します。 [SAML 構成のテスト] ボタン
  6. [保存] をクリックします。 IdP 構成の [保存] ボタン

Enterprise のポリシーを設定する

ポリシーを設定すると、Enterprise のリポジトリと Organization の管理に制限が設定されます。 これらは、初期化プロセスの後に再設定できます。

  1. [Enterprise ポリシーの設定] の右側にある [構成] をクリックします。 ポリシー構成の [構成] ボタン
  2. [Default Repository Permissions] の下で、ドロップダウンメニューを使用して、Enterprise 内のリポジトリのデフォルトの権限レベルをクリックします。 個人、チーム、または Organization のメンバーとして、Organization への複数のアクセス手段がある場合、最上位の権限レベルが下位の権限レベルよりも優先されます。 必要に応じて、Enterprise 内の組織が既定のリポジトリのアクセス許可を設定できるようにするには、 [ポリシーなし] をクリックします。 既定のリポジトリ アクセス許可オプションのドロップダウン メニュー
  3. [Repository creation] の下で、メンバーにリポジトリの作成を許可するかどうかを選択します。 必要に応じて、Enterprise 内の組織がアクセス許可を設定できるようにするには、 [ポリシーなし] をクリックします。 Enterprise ポリシー構成用の [メンバーがリポジトリを作成できるようにする] ボタン
  4. [Repository forking] の下で、プライベートリポジトリと内部リポジトリのフォークを許可するかどうかを選択します。 必要に応じて、Enterprise 内の組織にアクセス許可の設定を許可するには、 [ポリシーなし] をクリックします。 リポジトリのフォーク アクセス許可オプションのドロップダウン メニュー
  5. [Repository invitations] の下で、メンバーまたは Organization のオーナーがコラボレータをリポジトリに招待できるかどうかを選択します。 必要に応じて、Enterprise 内の組織にアクセス許可の設定を許可するには、 [ポリシーなし] をクリックします。 リポジトリの招待アクセス許可オプションのドロップダウン メニュー
  6. [Default repository visibility] で、ドロップダウンメニューを使用して、新しいリポジトリのデフォルトの可視性設定をクリックします。 既定のリポジトリ可視性オプションのドロップダウン メニュー
  7. [Users can create organizations] の下で、ドロップダウンメニューを使用して、Enterprise のメンバーの Organization 作成アクセスを有効または無効にします。 組織の作成アクセス許可オプションのドロップダウン メニュー
  8. [Force pushes] の下で、ドロップダウンメニューを使用して、フォースプッシュを許可するかブロックするかを選択します。 強制プッシュ構成オプションのドロップダウン メニュー
  9. [Git SSH access] の下で、ドロップダウンメニューを使用して、Enterprise 内のすべてのリポジトリに対して Git SSH アクセスを有効にするかどうかを選択します。 Git SSH アクセス オプションのドロップダウン メニュー
  10. [保存] ボタンをクリックします。 Enterprise ポリシー構成の [保存] ボタン
  11. 必要に応じて、すべての選択をリセットするには、[Reset to default policies] をクリックします。 すべての既定のポリシーをリセットするためのリンク

内部のサポート連絡先を設定する

ユーザが内部のサポートチームに連絡する方法を設定できます。 これは、初期化プロセスの後に再設定できます。

  1. [内部サポート連絡先] の右側にある [構成] をクリックします。 内部サポート連絡先構成の [構成] ボタン
  2. [Internal support contact] の下で、Enterprise のユーザが URL またはメールアドレスを使用してサポートに連絡する方法を選択します。 次に、サポートの連絡先情報を入力します。 内部サポート連絡先 URL のテキスト フィールド
  3. [保存] をクリックします。 Enterprise サポート連絡先構成の [保存] ボタン

メール設定

これを初期化すると、初期化プロセス後に再設定できます。 詳細については、「通知のためのメールを設定する」を参照してください。

  1. [メール設定の構成] の右側にある [構成] をクリックします。 メール設定の構成の [構成] ボタン

  2. [メールを有効にする] を選択します。 これにより、アウトバウンドメールとインバウンドメールの両方が有効になりますが、インバウンドメールが動作するようにするには、DNS 設定を行う必要があります。 詳細については、「受信メールを許可するための DNS とファイアウォールの設定の構成」を参照してください。 メール設定の [有効にする] チェックボックス

  3. メールサーバーの設定を完了します。

    • [サーバー アドレス] フィールドに SMTP サーバーのアドレスを入力します。
    • [ポート] フィールドに、SMTP サーバーがメールの送信に使用するポートを入力します。
    • [ドメイン] フィールドに、SMTP サーバーから HELO 応答が送信されるドメイン名 (存在する場合) を入力します。
    • [認証] ドロップダウンで SMTP サーバーで使用される暗号化の種類を選択します。
    • [No-reply メール アドレス] フィールドに、すべての通知メールの [送信元] フィールドと [宛先] フィールドに使用するメール アドレスを入力します。
  4. no-reply メール アドレスへの着信メールをすべて破棄したい場合には、 [no-reply メール アドレスへのメールの破棄] を選択してください。 メール設定の [破棄] チェック ボックス

  5. [メール設定のテスト] をクリックします。 メール設定の [メール設定のテスト] ボタン

  6. [テスト メールの送信先] で、テスト用メールを送信するメール アドレスを入力し、 [テスト メールの送信] をクリックします。 メール設定の [テスト メールの送信] ボタン

  7. [保存] をクリックします。 Enterprise サポート連絡先構成の [保存] ボタン