GitHub AE を初期化する

初期化について

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

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

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

前提条件

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

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

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

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

IdP を Enterprise に接続する

GitHub AE の認証を設定するには、GitHub AE に SAML IdP の詳細を提供する必要があります。 GitHub は、IdP として Azure AD を使用することを推奨しています。 詳しくは、「Enterprise IAM での SAML の使用」を参照してください。

1. [ID プロバイダーの設定] の右側にある [構成] をクリックします。
2. [Sign on URL] で、SAML IdP の URL をコピーして貼り付けます。
3. [Issuer] の下に、SAML IdP の発行者 URL をコピーして貼り付けます。
4. [Public certificate] の下で、SAML IdP の公開証明書をコピーして貼り付けます。
5. [SAML 構成のテスト] をクリックして、入力した情報が正しいことを確認します。
6. [保存] をクリックします。
7. ある人をエンタープライズ所有者にするには、IdP からアクセスを委任する必要があります。 Azure AD と SCIM を使用する場合は、エンタープライズ所有者ロールをユーザーに割り当てます。 他の IdP の場合、IdP のユーザー アカウントに対して、SAML アサーションの administrator 属性を、true の値を指定して含めます。 Enterprise 所有者について詳しくは、「Enterprise におけるロール」を参照してください。 Azure AD を使った認証とプロビジョニングの詳細については、「Azure AD を使用して Enterprise の認証とプロビジョニングを設定する」を参照してください。

Enterprise のポリシーを設定する

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

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

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

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

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

メール設定

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

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

2. [メールを有効にする] を選択します。 これにより、アウトバウンドメールとインバウンドメールの両方が有効になりますが、インバウンドメールが動作するようにするには、DNS 設定を行う必要があります。 詳しくは、「通知のためのメール設定」を参照してください。

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

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

4. no-reply メール アドレスへの着信メールをすべて破棄したい場合には、 [no-reply メール アドレスへのメールの破棄] を選択してください。

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

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

7. [保存] をクリックします。