Skip to main content

Modification des méthodes d’authentification

Vous pouvez changer la façon dont GitHub Enterprise Server authentifie vos comptes existants à tout moment.

Les comptes d’utilisateur sur your GitHub Enterprise Server instance 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 à 2 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 your GitHub Enterprise Server instance sans les ajouter à votre fournisseur d’identité. Pour plus d’informations, consultez « Autorisation de l’authentification intégrée pour les utilisateurs en dehors de votre fournisseur ».