Ir al contenido principal

¿Cómo configurar el SSO/SAML en lemlist?

Al terminar este tutorial, sabrás cómo configurar el SSO para tu equipo en lemlist, verificar y gestionar los dominios de tu empresa, decidir si quieres imponer el SSO y conectar Microsoft Entra ID, Okta o Google como proveedor de inicio de sesión de tu organización.

Nota: Esta función solo está disponible en el plan Enterprise.

El SSO permite que tu equipo inicie sesión con el proveedor de identidad de tu empresa en lugar de gestionar contraseñas directamente en lemlist. Además, da a los administradores más control sobre el acceso por dominio, la obligatoriedad del inicio de sesión y la autenticación entre aplicaciones en todo el ecosistema de Lempire.

¿Por qué es importante?

El SSO hace que el acceso sea más seguro y fácil de gestionar, porque tus usuarios se autentican a través del proveedor de identidad que ya usa tu organización. También reduce los problemas relacionados con contraseñas, te permite controlar qué dominios pueden acceder a tu equipo y admite el inicio de sesión en lemlist, lemwarm y lemcal.

Antes de empezar

  • Debes saber cómo acceder a la configuración de tu equipo en lemlist.

  • Necesitas ser administrador del equipo en lemlist para configurar el SSO.

  • Necesitas permisos de administrador en tu proveedor de identidad si usas Microsoft Entra ID u Okta.

  • Debes tener claro qué dominios de Email de tu empresa quieres proteger con SSO.

Importante: Si no eres administrador del equipo, la opción de SSO aparece desactivada.

Proveedores de identidad compatibles

  • Microsoft Entra ID: usa SAML 2.0. Tú proporcionas la App Federation Metadata URL y lemlist extrae automáticamente el certificado y el endpoint de inicio de sesión.

  • Okta: usa SAML 2.0. Tú proporcionas la Okta metadata URL y completas el mismo flujo basado en SAML.

  • Google: usa Google OAuth, no SAML. La configuración es más sencilla y no requiere una URL de metadatos.

Fase 1: Inicia el asistente de configuración de SSO

  1. Abre lemlist y ve a la configuración de tu equipo.

    Aquí es donde los administradores del equipo pueden gestionar los controles de inicio de sesión a nivel de organización.

  2. Busca Log in with your organization (SSO) y abre el flujo de configuración.

    Así se abre el asistente guiado para configurar tu proveedor, tus dominios y las opciones de obligatoriedad.

  3. Elige tu proveedor: Microsoft Entra, Okta o Google.

    Esta elección determina si completas una configuración SAML o una configuración de Google OAuth.

Fase 2: Añade y verifica tus dominios

Tus dominios determinan qué usuarios pueden autenticarse con el inicio de sesión de tu organización. lemlist admite varios dominios por organización.

  1. Añade el dominio o los dominios de Email que deben usar SSO, por ejemplo, acme.com.

    Así lemlist sabe qué usuarios pertenecen a tu organización a efectos del SSO.

  2. Verifica la propiedad de cada dominio antes de activarlo.

    Esto evita que otro equipo reclame un dominio que no le pertenece.

Elige un método de verificación

Puedes verificar cada dominio de una de estas dos formas:

  • Verificación por Email: introduce una dirección de Email de ese dominio, por ejemplo, [email protected], y haz clic en el enlace de verificación que se envía a esa dirección. El enlace caduca en 15 minutos.

  • Verificación por DNS TXT: añade un registro TXT llamado _lemlist-challenge.yourdomain.com y usa como valor el token que se muestra durante la configuración. Cuando el registro se haya propagado, haz clic en Verify.

Dato útil: Un dominio debe estar verificado antes de activarse para el SSO.

Gestiona los dominios verificados

Después de la verificación, puedes:

  • Ver tus dominios verificados

  • Añadir más dominios

  • Eliminar dominios

  • Configurar SAML bypass por dominio

Usa SAML bypass cuando sea necesario

SAML bypass es un interruptor por dominio que permite iniciar sesión con contraseña además del SSO para ese dominio concreto. Es útil para cuentas de administrador de respaldo o cuentas de servicio que puedan necesitar acceso sin SSO.

Fase 3: Revisa el impacto en el equipo antes de la activación

Antes de activar el SSO, lemlist comprueba cómo afecta a los miembros actuales de tu equipo.

  1. Revisa a los usuarios cuyas direcciones de Email coinciden con alguno de tus dominios de SSO.

    Estos usuarios usarán el SSO a partir del momento en que esté activo.

  2. Revisa a los usuarios cuyas direcciones de Email no coinciden con tus dominios de SSO.

    Durante la configuración, lemlist puede mostrarte estos usuarios para que los elimines del equipo antes de la activación.

Importante: Si el dominio de Email de un usuario no coincide con los dominios de SSO configurados, es posible que se le elimine del equipo durante la configuración.

Fase 4: Elige el nivel de obligatoriedad del SSO

Puedes decidir si el SSO es opcional u obligatorio para los usuarios cuyo dominio coincide.

Si Force SSO está activado

  • Los usuarios con un dominio de SSO coincidente deben iniciar sesión con SSO

  • El inicio de sesión con contraseña y con OAuth queda bloqueado para esos usuarios

  • Los dominios con SAML bypass activado pueden seguir iniciando sesión con contraseña

  • Se puede seguir retomando una sesión ya existente

Si Force SSO no está activado

  • Los usuarios pueden iniciar sesión con SSO o con métodos tradicionales, como contraseña o inicio de sesión con Google o Microsoft

Buena práctica: Deja Force SSO desactivado mientras haces pruebas. Cuando hayas confirmado tu proveedor, tus dominios y las asignaciones, puedes imponer el SSO a los usuarios cuyo dominio coincide.

Fase 5: Completa la configuración específica de tu proveedor

Configura el SSO con Microsoft Entra ID

  1. Abre el centro de administración de Microsoft Entra y ve a Enterprise applications > All applications.

  2. Crea una nueva aplicación para lemlist.

    Así tendrás una aplicación empresarial dedicada para gestionar el acceso con SSO.

  3. Selecciona SAML como método de inicio de sesión.

  4. En la configuración de SAML, copia los valores de tu equipo desde lemlist y pégalos en Microsoft Entra.

    • Pega el Identifier (Entity ID) de lemlist en el campo Identifier (Entity ID) de Entra

    • Pega la Reply URL de lemlist en el campo Reply URL (Assertion Consumer Service URL) de Entra

  5. Copia la App Federation Metadata URL de Microsoft Entra y pégala en el campo correspondiente de lemlist.

    lemlist usa esta URL para extraer automáticamente el certificado y el endpoint de inicio de sesión.

  6. Asigna los usuarios o grupos adecuados a la aplicación.

    Esto determina quién puede acceder realmente a lemlist a través de Entra.

Configura el SSO con Okta

  1. Inicia sesión en tu panel de administración de Okta y ve a Applications > Applications.

  2. Haz clic en Create App Integration y elige SAML 2.0.

  3. Crea la integración de lemlist y avanza por las pantallas de configuración.

  4. Copia los valores de tu equipo desde lemlist en Okta.

    • Pega la Single sign-on URL de lemlist en el campo Single sign-on URL de Okta

    • Pega el Identifier (Entity ID) de lemlist en el campo Audience URI (SP Entity ID) de Okta

  5. Añade estas declaraciones de atributos en Okta:

    • firstName → user.firstName

    • lastName → user.lastName

    • email → user.email

  6. Termina el flujo de configuración de Okta y copia la App Federation Metadata URL de Okta en lemlist.

  7. Asigna los usuarios o grupos correspondientes a la aplicación de Okta.

Importante: Si un usuario no está asignado a la aplicación de Okta o Microsoft Entra, es posible que no pueda acceder a lemlist aunque el SSO esté bien configurado.

Configura el inicio de sesión de la organización con Google

  1. Selecciona Google como proveedor en el asistente de configuración.

  2. Completa la configuración de autenticación de Google en lemlist.

    A diferencia de Entra y Okta, Google usa OAuth en lugar de SAML, por lo que no se necesita ninguna URL de metadatos.

  3. Termina el paso de configuración específico de Google y guarda la configuración.

Fase 6: Prueba el flujo de inicio de sesión

Las pruebas te permiten confirmar que los usuarios correctos se redirigen al proveedor adecuado antes de implementar el SSO por completo.

  1. Guarda tu configuración de SSO en lemlist.

  2. Asigna un usuario de prueba en tu proveedor de identidad.

  3. Pide al usuario que vaya a la página de inicio de sesión con SSO en /sso.

  4. Introduce la dirección de Email de trabajo de un dominio verificado.

  5. Confirma que el usuario se redirige a Microsoft Entra, Okta o Google.

  6. Completa la autenticación y comprueba que el usuario inicia sesión en lemlist automáticamente.

¿Cómo inician sesión los usuarios invitados?

  • Si el SSO está activo en el equipo, los usuarios invitados reciben un Email que les indica que deben iniciar sesión con SSO.

  • Al hacer clic en el enlace de invitación, acceden directamente al flujo de inicio de sesión con SSO.

  • Tras autenticarse con las credenciales de su organización, inician sesión en lemlist.

Ejemplo práctico

Este es un modelo de implementación habitual para un equipo Enterprise:

  1. Añade acme.com y acme.co.uk como dominios de SSO.

  2. Verifica un dominio por Email y el otro mediante un registro DNS TXT.

  3. Mantén Force SSO desactivado durante las pruebas para que los usuarios puedan seguir iniciando sesión con su método anterior si lo necesitan.

  4. Activa SAML bypass en un dominio que utilice una cuenta de administrador de respaldo.

  5. Asigna un grupo piloto en Okta o Microsoft Entra y prueba el flujo a través de /sso.

  6. Cuando todo funcione, activa Force SSO para imponerlo por completo.

Este enfoque reduce el riesgo de bloqueos de acceso mientras el equipo avanza hacia una gestión centralizada del inicio de sesión.

Casos especiales y comportamientos importantes

Miembros del equipo y activación

  • Si un usuario ya está en el equipo y su dominio de Email coincide con el dominio de SSO, pierde su método de inicio de sesión anterior y debe usar SSO. No se cierra su sesión actual y no se le envía ningún Email para informarle del cambio.

  • Si un usuario no está en el equipo pero su dominio de Email coincide con el dominio de SSO, no ocurre nada. La obligatoriedad del SSO solo se aplica a los miembros actuales del equipo.

  • Si el dominio de Email de un usuario no coincide con el dominio de SSO, se le puede eliminar del equipo durante la configuración, pero su método de inicio de sesión en otros equipos no cambia.

  • Si algunos usuarios ya tenían una cuenta de lemlist que coincide con el dominio de SSO, sus cuentas se fusionan para que puedan iniciar sesión con SSO.

Invitaciones y acceso a equipos

  • Si un equipo con SSO invita a un usuario cuyo Email no coincide con el dominio de SSO, la invitación se bloquea.

  • Si un usuario de un equipo sin SSO recibe una invitación a un equipo con SSO, pierde los demás métodos de inicio de sesión y debe usar SSO a partir de ese momento. No se cierra su sesión y no se le envía ningún Email para informarle del cambio.

  • Si un usuario nuevo inicia sesión con SSO por primera vez, se añade automáticamente al equipo con SSO. No se crea un equipo aparte ni se requiere verificación por Email.

  • Los usuarios creados con SSO pueden unirse a otros equipos, salvo que Force SSO esté activado y los equipos de destino no usen también SSO con el mismo dominio verificado.

Contraseñas, magic links y cambios del Email de inicio de sesión

  • Si un usuario con SSO intenta restablecer su contraseña, el restablecimiento se bloquea con este error: "Your account is using Organization login (SSO), please contact your admin to reset your password."

  • Si un usuario con SSO hace clic en Get magic link, ve el mismo error. Los magic links están desactivados en las cuentas con SSO.

  • Si un usuario intenta cambiar su Email de inicio de sesión por uno que no coincide con el dominio de SSO, el campo de Email de inicio de sesión aparece desactivado en la configuración mientras el SSO esté activo en el equipo.

Comportamiento con varios equipos

  • Si un usuario pertenece a un equipo con SSO y a otro sin SSO, debe iniciar sesión con SSO, y ese inicio de sesión le da acceso a ambos equipos.

  • Si se elimina a un usuario del equipo con SSO en el proveedor de identidad, pero sigue en un equipo sin SSO, puede quedar bloqueado al iniciar sesión y necesitar ayuda del equipo de asistencia para recuperar el acceso.

  • Si un usuario abandona un equipo con SSO activado, pierde el inicio de sesión con SSO, pero su sesión no se cierra de inmediato. Recibe un Email con un enlace para crear una contraseña.

Notas de seguridad y para administradores de TI

  • Si un administrador de TI impide que un usuario acceda a lemlist mediante los grupos del proveedor de identidad, el usuario no puede iniciar sesión con SSO ni unirse al equipo de la empresa. Aun así, puede crear una cuenta independiente con otro método de inicio de sesión y abrir un equipo nuevo.

  • Varios equipos pueden configurar el SSO con el mismo dominio. No hay ninguna comprobación de unicidad entre equipos. Al iniciar sesión, el sistema encuentra todos los proveedores coincidentes en los equipos del usuario.

  • La propiedad del dominio se valida antes de poder activar el SSO, mediante verificación por Email o por DNS TXT.

  • Algunos errores de SSO y de restablecimiento de contraseña pueden revelar que una empresa usa lemlist. Por ahora, se trata de un riesgo asumido.

Solución de problemas y errores habituales

Problema: un usuario no puede acceder a lemlist con SSO

Causa: Es posible que el usuario no esté asignado a la aplicación en Okta o Microsoft Entra, o que su dominio de Email no coincida con un dominio verificado.

Solución:

  • Confirma que el usuario está asignado a la aplicación en tu proveedor de identidad

  • Comprueba que su Email de inicio de sesión coincide con uno de los dominios de SSO verificados

  • Verifica que se pegó la URL de metadatos correcta en lemlist

Problema: la verificación del dominio falla

Causa: Es posible que el enlace del Email haya caducado o que el registro DNS TXT aún no se haya propagado.

Solución:

  • Solicita un nuevo enlace de verificación por Email si el anterior caducó tras 15 minutos

  • Revisa bien el nombre del registro TXT y el valor del token

  • Espera a que se propague el DNS y vuelve a hacer clic en Verify

Problema: los usuarios se quedan sin acceso tras activar Force SSO

Causa: Se impuso el SSO antes de hacer pruebas o antes de configurar una vía de acceso de respaldo.

Solución:

  • Mantén Force SSO desactivado hasta terminar las pruebas

  • Usa SAML bypass en un dominio de administrador de confianza si necesitas un acceso de respaldo con contraseña

  • Confirma las asignaciones en el proveedor antes de implementar el SSO en todo el equipo

Problema: un usuario no puede restablecer la contraseña ni usar magic links

Causa: Su cuenta ahora se gestiona mediante el inicio de sesión de la organización.

Solución:

  • Pide al usuario que inicie sesión a través de /sso con su Email de trabajo

  • Pide al administrador del equipo que revise la configuración de SSO si el acceso sigue fallando

Problema: el Email de un miembro del equipo no coincide con ningún dominio de SSO

Causa: Su Email de inicio de sesión no pertenece a los dominios verificados de la organización.

Solución:

  • Revisa al usuario durante el asistente de configuración

  • Elimínalo del equipo si es necesario

  • Si necesitas que siga en el equipo, comprueba si hay que añadir otro dominio a la configuración de SSO

Preguntas frecuentes

¿Qué ocurre si cambio de Enterprise a un plan inferior?

Tu configuración de SSO se conserva, pero queda inactiva. Los usuarios tendrán que iniciar sesión con contraseña u OAuth hasta que el equipo vuelva al plan Enterprise.

¿Puedo tener SSO con SAML y con Google en el mismo equipo?

No. Cada equipo solo puede tener un proveedor de SSO configurado a la vez. Eliges Microsoft Entra, Okta o Google durante la configuración.

¿Puedo cambiar de proveedor después de la configuración?

Sí. Puedes volver a configurar el SSO repitiendo el asistente de configuración y seleccionando otro proveedor.

¿Hay alguna forma de probar el SSO antes de imponerlo?

Sí. Después de la configuración, deja Force SSO desactivado para que los usuarios puedan iniciar sesión con SSO o con métodos tradicionales mientras haces pruebas.

Artículos relacionados
¿Ha quedado contestada tu pregunta?