Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.
GitHub AE is currently under limited release.

GitHub AE を初期化する

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

初期化について

Enterprise を初期化する前に、GitHub AE を購入する必要があります。 詳細については、GitHub's Sales team にお問い合わせください。

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

:

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

  • パスワード マネージャーで GitHub AE の初期ユーザー名とパスワードを安全に保存します。 GitHub AEがSAML IdPと通信できないためにEnterpriseにサインインできない場合は、SAML SSOの設定を更新するためのGitHub AEへのアクセスを支援してくれるGitHub Supportに連絡してください。 詳細については、「Receiving help from GitHub Support」 (GitHub Support からヘルプを受ける) を参照してください。

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

前提条件

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

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

: IdP で専用のマシン ユーザー アカウントを作成して使用し、GitHub AE 上の最初の Enterprise 所有者アカウントに関連付ける必要があります。 このユーザアカウントの認証情報は、パスワードマネージャに安全に保存してください。 詳しくは、「Enterprise 用の SCIM を使用したユーザーのプロビジョニングを構成する」を参照してください。

サインインして 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 構成の [保存] ボタン
  7. ある人をエンタープライズ所有者にするには、IdP からアクセスを委任する必要があります。 Azure AD と SCIM を使用する場合は、エンタープライズ所有者ロールをユーザーに割り当てます。 他の IdP の場合、IdP のユーザー アカウントに対して、SAML アサーションの administrator 属性を、true の値を指定して含めます。 Enterprise 所有者の詳細については、「Enterprise におけるロール」を参照してください。 Azure AD を使用した認証とプロビジョニングの詳細については、「Azure AD を使用したエンタープライズの認証とプロビジョニングの構成」を参照してください。

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 サポート連絡先構成の [保存] ボタン