Skip to main content

Cambio de métodos de autenticación

Puedes modificar la manera en que GitHub Enterprise Server se autentica con tus cuentas existentes en cualquier momento.

Las cuentas de usuario de tu instancia de GitHub Enterprise Server se mantienen al cambiar el método de autenticación y los usuarios seguirán iniciando sesión en la misma cuenta, siempre y cuando su nombre de usuario no cambie.

Si el nuevo método de autenticación modifica los nombres de usuario, se crearán nuevas cuentas. Como administrador, puede cambiar el nombre de los usuarios mediante la configuración de administrador del sitio o mediante la API de administración de usuarios.

Otras cuestiones que deberías tener en cuenta son las siguientes:

  • Contraseñas: si empieza a usar la autenticación integrada para la instancia, los usuarios deben establecer una contraseña una vez completado el cambio.

  • Administradores del sitio: los privilegios administrativos se controlan mediante el proveedor de identidades cuando se usa SAML y se pueden controlar mediante la pertenencia a grupos cuando se usa LDAP.

  • Pertenencia a equipos: solo LDAP permite controlar la pertenencia a equipos desde el servidor de directorios.

  • Suspensión de usuarios: cuando se usa LDAP para autenticarse, el acceso a GitHub Enterprise Server se puede controlar mediante grupos restringidos. Después de cambiar a LDAP, si se configuran grupos restringidos, los usuarios existentes que no estén en uno de esos grupos serán suspendidos. La suspensión ocurrirá cuando inicien sesión o durante la siguiente sincronización LDAP.

  • Pertenencia a grupos: cuando se usa LDAP para autenticarse, los usuarios se suspenden o se anula su suspensión automáticamente en función de la pertenencia a grupos restringidos y el estado de la cuenta con Active Directory.

  • Autenticación de Git: SAML y CAS solo admiten la autenticación de Git mediante HTTP o HTTPS con un personal access token. No se admite la autenticación de contraseña a través de HTTP o HTTPS. LDAP admite la autenticación de Git basada en contraseña de forma predeterminada, pero se recomienda deshabilitar ese método y forzar la autenticación con un personal access token o una clave SSH.

  • Autenticación de API: SAML y CAS solo admiten la autenticación de API con un personal access token. No se admite la autenticación básica.

  • Autenticación en dos fases: Cuando se usa SAML o CAS, la autenticación en dos fases no se admite ni se administra en la instancia de GitHub Enterprise Server, pero es posible que un proveedor de autenticación externo sí la admita. No está disponible la implementación de la autenticación de dos factores en organizaciones. Para más información sobre cómo aplicar la autenticación en dos fases en las organizaciones, consulta "Requerir autenticación en dos fases en la organización".

  • Autenticación de reserva para usuarios sin cuenta en tu proveedor de autenticación externo: puedes invitar a los usuarios a autenticarse en tu instancia de GitHub Enterprise Server sin agregarlos a tu proveedor de identidades. Para más información, consulta Permitir la autenticación integrada de los usuarios ajenos al proveedor.