Search Icon

    Configurar Microsoft SSO en la plataforma Vemco: guía paso a paso

    Configurar Microsoft SSO en la plataforma Vemco: guía paso a paso

    Es jueves, el piloto de analítica de tráfico arranca el lunes y el responsable de seguridad acaba de añadir una condición: nadie entra en el portal de Vemco con usuario y contraseña locales; el acceso será exclusivamente mediante Microsoft SSO con Entra ID. Tiene tres días, el portal de Entra abierto en una pestaña y el correo del proveedor en otra. Esta guía recorre exactamente ese trabajo: qué pedir, qué configurar, en qué orden probar y cómo interpretar los errores que aparecerán. Si busca el contexto estratégico y los criterios de compra, ya existe una lista de verificación de SSO para licitaciones de Office 365; aquí solo hablamos de la configuración.

    Qué necesita tener a mano antes de empezar

    • Un rol adecuado en Entra ID: Administrador de aplicaciones o Administrador de aplicaciones en la nube como mínimo. Si va a aplicar acceso condicional, además Administrador de acceso condicional y una licencia Entra ID P1 en el tenant.
    • Los datos del Service Provider: confirme con el equipo de Vemco Group qué protocolo utiliza la integración en su despliegue (SAML 2.0 u OIDC) y solicite los metadatos correspondientes: Entity ID y URL de ACS en SAML, o los redirect URIs en OIDC. También pregunte qué atributo esperan como identificador del usuario; casi siempre es el correo o el UPN.
    • Un grupo de seguridad para el piloto: cree un grupo con tres o cuatro usuarios reales de distintos perfiles (un administrador del portal, un analista, un responsable de tienda). Lo usará para la asignación inicial.
    • Un UPN limpio: si el usuario tiene un UPN distinto de su correo principal, decida ya cuál se enviará como identificador. Es la causa más común de que el SSO «funcione» pero cree un usuario duplicado en el destino.

    Paso a paso: configurar Microsoft SSO en Entra ID

    El flujo es el mismo que para cualquier aplicación federada; lo específico de Vemco son los valores que intercambiará con el proveedor.

    • 1. Registrar la Enterprise Application. En Entra ID vaya a Aplicaciones empresariales, Nueva aplicación. Si existe una integración predefinida en la galería, úsela; si no, cree una aplicación personalizada «que no esté en la galería». Póngale un nombre reconocible para el helpdesk, por ejemplo «Vemco – Analítica de tráfico (PROD)».
    • 2. Elegir el método de inicio de sesión único. En el menú Inicio de sesión único seleccione SAML. Si el proveedor le indicó OIDC, haga en su lugar un Registro de aplicación, añada los redirect URIs y genere una credencial: un certificado es preferible a un client secret, que caduca y hay que rotar a mano.
    • 3. Configuración básica de SAML. Introduzca el Identificador (Entity ID) y la URL de respuesta (ACS) que le facilitó Vemco. Si le dieron una URL de inicio de sesión, añádala también: habilita el flujo iniciado por el SP, que es el que usará la mayoría de la gente al escribir la URL del portal en el navegador.
    • 4. Atributos y claims. Verifique que el identificador de usuario único (NameID) coincide con lo acordado, normalmente user.mail o user.userprincipalname. Añada givenname, surname y email. Si el portal gestiona roles desde el IdP, añada el claim de grupos o un claim de rol y acuerde con el proveedor el valor exacto que esperan para cada perfil.
    • 5. Exportar el certificado y los metadatos. Descargue el certificado de firma en Base64 y la URL de metadatos de federación, y envíelos al equipo de Vemco Group junto con la URL de inicio de sesión y el identificador de Entra. Hasta que ellos los carguen en su lado, el flujo no funcionará aunque Entra lo marque todo en verde.
    • 6. Asignar el grupo piloto. En Usuarios y grupos, asigne el grupo de seguridad creado antes. No asigne usuarios individuales: cuando llegue el despliegue completo cambiará el grupo por uno dinámico por departamento y no tendrá que tocar la aplicación.
    • 7. Acceso condicional. Cree una política que apunte a esta aplicación con MFA obligatoria. Aplíquela primero en modo «Solo informe» durante el piloto y pase a «Activado» tras validar que ningún usuario del piloto queda bloqueado por un dispositivo o una ubicación inesperados.

    Pruebas: qué validar antes de cerrar el login local

    El botón «Probar» de Entra solo verifica la mitad del recorrido. Haga estas comprobaciones con cada usuario del piloto, en una ventana de incógnito y anotando el resultado:

    • Flujo iniciado por el IdP: entre desde myapps.microsoft.com y pulse el icono de la aplicación. Debe aterrizar autenticado en el portal.
    • Flujo iniciado por el SP: escriba directamente la URL del portal. Debe redirigir a Microsoft, autenticar y volver. Si este flujo falla y el anterior funciona, falta la URL de inicio de sesión o el proveedor no la tiene configurada.
    • Identidad y rol correctos: compruebe en el portal que el usuario creado tiene el correo esperado y el perfil acordado. Un usuario que entra pero sin permisos indica un claim de rol mal mapeado.
    • Revocación: quite a un usuario del grupo asignado, espere la propagación y confirme que ya no puede entrar. Este es el motivo por el que se hace todo esto; no lo dé por supuesto.
    • Registros de inicio de sesión: revise en Entra ID los Sign-in logs de la aplicación y confirme que cada intento aparece con el resultado correcto y la política de acceso condicional aplicada.

    Solo cuando las cinco pruebas pasan para todos los perfiles tiene sentido pedir al proveedor que desactive el inicio de sesión local. Hágalo en una fecha anunciada y mantenga una cuenta de emergencia excluida del acceso condicional, monitorizada por su SOC, durante al menos el primer mes.

    Errores habituales y cómo leerlos

    • AADSTS50105 («el usuario no está asignado a un rol para la aplicación»). El usuario no pertenece a ningún grupo asignado a la Enterprise Application. Llega al helpdesk como «el SSO no funciona» y se pierden horas revisando certificados. Es el primer punto del runbook de nivel 1.
    • AADSTS50011 (URL de respuesta no coincide). La ACS que le dio el proveedor y la que introdujo difieren en una barra final, en http frente a https o en un subdominio de entorno (test frente a prod). Compárelas carácter a carácter.
    • AADSTS700016 (aplicación no encontrada en el directorio). El proveedor tiene cargado un identificador de Entra de otro tenant, típicamente del entorno de pruebas. Pida que verifiquen el tenant ID.
    • Entra autentica, el portal rechaza. Casi siempre un NameID distinto del esperado o un certificado aún no cargado en el lado del proveedor. Descargue la respuesta SAML con una extensión de navegador y compruebe qué atributo se está enviando.
    • Todo deja de funcionar meses después. El certificado SAML de Entra caduca a los tres años por defecto. Cree una alerta con 60 días de antelación y un propietario nominal de la integración el mismo día del go-live, no cuando ocurra.

    Un último detalle que no es de configuración: al federar la plataforma de analítica también estará dando acceso a datos. En el caso de Vemco Group se trata de recuentos agregados y anonimizados conforme al RGPD, sin identificación personal, lo que facilita que el DPO apruebe el despliegue en paralelo a la revisión de seguridad. Si su organización exige cloud privado, confírmelo con el proveedor antes de registrar la aplicación, porque los metadatos del Service Provider cambian según el entorno.

    Preguntas frecuentes

    ¿Cuánto tarda la configuración del inicio de sesión único Microsoft para una sola aplicación?
    El trabajo técnico en Entra ID se hace en una tarde si tiene los metadatos del proveedor. El tiempo real lo marcan el intercambio de datos con el proveedor y una semana de piloto con usuarios reales antes de cerrar el login local.

    ¿Necesito Entra ID P1 para que funcione el SSO?
    No para la federación en sí: el inicio de sesión único con aplicaciones empresariales está disponible en los planes estándar de Microsoft 365. P1 es necesario si quiere aplicar acceso condicional a la aplicación, y P2 si necesita revisiones de acceso.

    ¿El SSO elimina automáticamente al usuario en el portal cuando se da de baja?
    No. Bloquea el acceso, pero la cuenta sigue existiendo en el destino. Si el proveedor soporta SCIM, actívelo para automatizar altas, cambios y bajas; si no, programe una reconciliación trimestral de cuentas y deje constancia para auditoría.

    ¿Está preparando la integración de la plataforma de Vemco Group con su tenant de Entra ID? Hable con el equipo de Vemco Group para confirmar el protocolo de su despliegue, los metadatos del Service Provider y las opciones de cloud gestionado o privado en vemcogroup.com/contact-us.

    Join Our Newsletter Community Today!

    Form-right