お使いの GitHub Enterprise Server インスタンス のユーザー アカウントは、認証方式を変更しても保存され、ユーザーはユーザー名が変更されない限り、同じアカウントにログインし続けることができます。
新しい認証方式でユーザ名が変更される場合、新しいアカウントが作成されます。 管理者は、サイト管理者設定かユーザー管理 API を利用することでユーザーの名前を変更できます。
他に考慮しなければならない問題には以下があります。
-
パスワード: インスタンスに組み込みの認証を使用するように切り替える場合、ユーザーは変更が完了した後にパスワードを設定する必要があります。
-
サイト管理者: 管理特権は、SAML を使用する場合は ID プロバイダーによって制御されます。LDAP を使用する場合はグループ メンバーシップによって制御できます。
-
チーム メンバーシップ: LDAP でのみ、ディレクトリ サーバーからチーム メンバーシップを制御できます。
-
ユーザーの一時停止: 認証に LDAP を使う場合、GitHub Enterprise Server へのアクセスは_制限グループ_経由で制御できます。 LDAPに切り替えた後、制限グループが設定されているなら、既存のユーザでこれらのグループのいずれかに属してないユーザは一時停止されます。 一時停止は、ユーザがログインするか、次のLDAP Syncの間に生じます。
-
グループ メンバーシップ: LDAP を使用して認証を行うと、制限付きグループ メンバーシップ、アカウントの状態、Active Directory に基づいて、ユーザーが自動的に中断され、中断解除されます。
-
Git 認証: SAML と CAS では、personal access token を使用した HTTP または HTTPS 経由の Git 認証のみがサポートされます。 HTTPあるいはHTTPS経由でのパスワード認証はサポートされていません。 LDAP では既定でパスワードベースの Git 認証がサポートされていますが、その方法を無効にし、personal access token または SSH キーを使用する認証を強制することをお勧めします。
-
API 認証: SAML と CAS では、personal access token を利用した API 認証のみがサポートされています。 Basic認証はサポートされていません。
-
2 要素認証: SAML あるいは CAS を使う場合、GitHub Enterprise Server インスタンスで 2 要素認証はサポートあるいは管理されませんが、外部の認証プロバイダがサポートしている可能性があります。 Organizationでの2要素認証の強制はできません。 組織での 2 要素認証の適用については、「Organization で 2 要素認証を要求する」を参照してください。
-
外部認証プロバイダーのアカウントがないユーザーに対するフォールバック認証: 使用中の ID プロバイダーに追加することなく、ユーザーを お使いの GitHub Enterprise Server インスタンス で認証するよう招待できます。 詳しくは、「使用しているプロバイダーの外部ユーザーのためのビルトイン認証の許可」を参照してください。