お使いの GitHub Enterprise Server インスタンス のユーザー アカウントは、認証方式を変更しても保存され、ユーザーはユーザー名が変更されない限り、同じアカウントにログインし続けることができます。
新しい認証方式でユーザ名が変更される場合、新しいアカウントが作成されます。 管理者は、サイト管理者設定かユーザー管理 API を利用することでユーザーの名前を変更できます。
他に考慮しなければならない問題には以下があります。
-
パスワード: インスタンスに組み込みの認証を使用するように切り替える場合、ユーザーは変更が完了した後にパスワードを設定する必要があります。
-
サイト管理者: 管理特権は、SAML を使用する場合は ID プロバイダーによって制御されます。LDAP を使用する場合はグループ メンバーシップによって制御できます。
-
チーム メンバーシップ: LDAP でのみ、ディレクトリ サーバーからチーム メンバーシップを制御できます。
-
ユーザーの一時停止: 認証に LDAP を使う場合、GitHub Enterprise Server へのアクセスは_制限グループ_経由で制御できます。 LDAPに切り替えた後、制限グループが設定されているなら、既存のユーザでこれらのグループのいずれかに属してないユーザは一時停止されます。 一時停止は、ユーザがログインするか、次のLDAP Syncの間に生じます。
-
Group membership: LDAP を使用して認証すると、制限されたグループ メンバーシップとActive Directoryのアカウントの状態に基づいて、ユーザーは自動的に suspended および unsuspended になります。
-
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要素認証の強制はできません。 Organization での 2 要素認証の適用については、「Organization で 2 要素認証を要求する」を参照してください。
-
外部認証プロバイダーのアカウントがないユーザーに対するフォールバック認証: 使用中の ID プロバイダーにユーザーを追加することなく、ユーザーを お使いの GitHub Enterprise Server インスタンス で認証するよう招待できます。 詳しくは、「使用しているプロバイダーの外部ユーザーのためのビルトイン認証の許可」をご覧ください。
LDAP から SAML および SCIM への移行
現在 LDAP を使用していて、自動ユーザー プロビジョニングとプロビジョニング解除機能を有効にする場合は、SCIM プロビジョニングを使用して SAML 認証に移行できます。 これにより、一元化された認証を維持しながら、ユーザー ライフサイクル管理が強化されます。
移行の詳細な手順については、 SCIM を使用した LDAP から SAML への移行 を参照してください。