Les comptes d’utilisateur sur votre instance GitHub Enterprise Server sont conservés lorsque vous modifiez la méthode d’authentification, et les utilisateurs continuent à se connecter au même compte tant que leur nom d’utilisateur ne change pas.
Si la nouvelle méthode d’authentification modifie les noms d’utilisateur, de nouveaux comptes sont créés. En tant qu’administrateur, vous pouvez renommer des utilisateurs via les paramètres d’administration du site ou l’’API Administration des utilisateurs.
Les autres problèmes que vous devez prendre en compte sont les suivants :
-
Mots de passe : Si vous passez à l’authentification intégrée pour votre instance, les utilisateurs doivent définir un mot de passe une fois la modification terminée.
-
Administrateurs de site : Les privilèges d’administration sont contrôlés par votre fournisseur d’identité lorsque vous utilisez SAML et peuvent être contrôlés par l’appartenance au groupe lorsque vous utilisez LDAP.
-
Appartenance à l’équipe : Seul LDAP vous permet de contrôler l’appartenance à l’équipe à partir de votre serveur d’annuaire.
-
Suspension d’utilisateur : Lorsque vous utilisez LDAP pour vous authentifier, l’accès à GitHub Enterprise Server peut être contrôlé via des groupes restreints. Après avoir basculé vers LDAP, si des groupes restreints sont configurés, les utilisateurs existants qui ne se trouvent pas dans l’un de ces groupes sont suspendus. Une suspension se produit lorsqu’ils se connectent ou lors de la prochaine synchronisation LDAP.
-
Appartenance au groupe : Lorsque vous utilisez LDAP pour l’authentification, les utilisateurs sont automatiquement suspendus et rétablis en fonction de l’appartenance à un groupe restreint et de l’état du compte avec Active Directory.
-
Authentification Git : SAML et CAS prennent uniquement en charge l’authentification Git via HTTP ou HTTPS à l’aide d’un personal access token. L’authentification par mot de passe via HTTP ou HTTPS n’est pas prise en charge. LDAP prend en charge l’authentification Git par défaut basée sur un mot de passe, mais nous vous recommandons de désactiver cette méthode et de forcer l’authentification via un personal access token ou une clé SSH.
-
Authentification d’API : SAML et CAS prennent uniquement en charge l’authentification d’API à l’aide d’un personal access token. L’authentification de base n’est pas prise en charge.
-
Authentification à 2 facteurs : Lorsque vous utilisez SAML ou CAS, l’authentification à deux facteurs n’est pas prise en charge ou gérée sur l’instance GitHub Enterprise Server, mais elle peut être prise en charge par le fournisseur d’authentification externe. L’authentification à 2 facteurs n’est pas disponible pour les organisations. Pour plus d’informations sur l’application de l’authentification à 2 facteurs dans les organisations, consultez « Exiger l’authentification à deux facteurs dans votre organisation ».
-
Authentification de secours pour les utilisateurs sans compte sur votre fournisseur d’authentification externe : Vous pouvez inviter des utilisateurs à s’authentifier auprès de votre instance GitHub Enterprise Server sans les ajouter à votre fournisseur d’identité. Pour plus d’informations, consultez « Autorisation d’authentification intégrée pour les utilisateurs extérieurs à votre fournisseur ».