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