El noventa por ciento de las brechas aún comienzan con una credencial robada, y los directorios on-premises siguen siendo el objetivo principal. Active Directory cumple 25 años este año, pero la mayoría de los stacks de identidad empresarial todavía dependen de tickets Kerberos emitidos por controladores de dominio que sus auditores apenas comprenden. El resultado: arquitecturas híbridas donde Entra ID se sitúa sobre el AD heredado, Seamless SSO abre vectores de ataque silenciosos y ADFS persiste a pesar de la silenciosa deprecación de Microsoft.
Esta guía va más allá de los manuales de los fabricantes. Encontrará un marco de decisión de protocolos que asigna Kerberos, SAML, OIDC y FIDO2 a casos de uso on-prem concretos, una ruta pragmática para organizaciones sin licencias P1/P2, recetas de hardening para la delegación Kerberos y una matriz de compliance para NIS2, GDPR y PCI-DSS 8.x. El objetivo: ofrecer a arquitectos y CISOs la claridad técnica para asegurar el inicio de sesión único en entornos híbridos sin reconstruir el directorio.
Qué significa realmente el SSO on-prem en un entorno híbrido
Mecánica fundamental: Kerberos, LDAP, SAML y OIDC frente a Active Directory
El inicio de sesión único on-prem comienza en la Local Security Authority. Cuando un usuario inicia sesión, la LSA solicita un Ticket-Granting Ticket a un controlador de dominio localizado y luego intercambia tickets de servicio para cada recurso on-prem. Entra Connect o Cloud Sync replica hacia arriba el UPN, el SAM Account Name y los atributos de dominio, de modo que un dispositivo unido a Entra recibe su Primary Refresh Token junto con la sugerencia de dominio on-prem. Desde allí, el dispositivo accede a recursos compartidos, impresoras y aplicaciones LOB mediante Kerberos o NTLM a través del DC localizado.
SAML y OIDC gestionan las aplicaciones web federadas, pero el directorio de referencia permanece on-prem. El DC sigue siendo la autoridad para sesiones RDP, thick clients, segmentos SCADA/OT y cargas de trabajo air-gapped donde ningún IdP en la nube tiene visibilidad.
Por qué Seamless SSO se considera un riesgo de seguridad
Seamless SSO se apoya en la cuenta de equipo AZUREADSSOACC$ en Active Directory. Su clave Kerberos nunca rota por defecto, lo que expone al tenant a la falsificación de Silver Ticket: un atacante con el hash puede emitir tickets de servicio válidos para cualquier usuario federado. Microsoft recomienda ahora migrar a Cloud Kerberos Trust, llaves de seguridad FIDO2 o autenticación basada en certificados para un acceso resistente al phishing.
Elección del protocolo: Matriz de decisión para SSO on-prem
Comparativa directa: Kerberos, SAML, OIDC, LDAP, FIDO2
La elección del protocolo determina su superficie de ataque durante la próxima década. La matriz puntúa cada opción según los criterios que importan a un arquitecto de seguridad que despliega SSO on-prem.
| Criterio | Kerberos | SAML | OIDC | LDAP | FIDO2 |
|---|---|---|---|---|---|
| Compatibilidad con apps heredadas | Alta | Media | Baja | Alta | Media (con puente AD) |
| Resistencia al phishing | Baja | Baja | Media | Baja | Alta |
| Preparación para entornos híbridos | Media | Alta | Alta | Baja | Alta |
| Capacidad sin conexión | Sí | No | No | Sí | Sí |
| Coste de licencia | Incluido | Variable | Bajo | Incluido | Solo hardware |
| Complejidad de despliegue | Media | Alta | Media | Baja | Baja |
| Granularidad de auditoría | Media | Alta | Alta | Baja | Alta |
Veredictos: thick clients → Kerberos; SaaS web → SAML u OIDC; RDP/RemoteApp → Kerberos + FIDO2; redes OT → LDAP + puente FIDO2.
Diagrama de decisión y combinación de protocolos
Combinar protocolos de forma deliberada. Mantener Kerberos para recursos integrados en Windows, SAML para SaaS federado mediante proxy a AD, FIDO2 como autenticador universal. Aplicar una higiene estricta de SPN, claims UPN coherentes y una única cookie de sesión para evitar solicitudes de autenticación duplicadas.
Tres arquitecturas de SSO on-prem sin ADFS ni Entra ID P1/P2
Arquitectura 1 — Solo Kerberos con Active Directory nativo
Aproveche lo que el controlador de dominio ya ofrece: SPNs registrados con setspn, Windows-Integrated Authentication en IIS y Group Policy distribuyendo listas blancas de navegadores. Sin IdP adicional, sin dependencia de la nube. La cobertura se limita a las aplicaciones de intranet que hablan Kerberos o NTLM.
Arquitectura 2 — Proxy SAML enlazado con AD para SaaS y aplicaciones web heredadas
Un appliance SAML ligero enlazado con AD para SaaS y aplicaciones web heredadas (Keycloak, SimpleSAMLphp, Shibboleth) lee usuarios mediante LDAP, emite aserciones para SaaS y actúa como intermediario de OIDC para aplicaciones modernas. Sin Entra Connect, sin Intune, sin licencias P1/P2. El despliegue se completa en días sobre una sola VM.
Arquitectura 3 — Puente de autenticación FIDO2 + AD para SSO sin contraseña
El patrón Hideez Server para SSO sin contraseña con FIDO2 + AD combina llaves FIDO2 con un puente de autenticación on-prem que emite tickets Kerberos tras la verificación respaldada por hardware. Cubre el inicio de sesión en Windows, RDP y la delegación a aplicaciones heredadas. La inscripción, la recuperación de llaves y la consola de administración funcionan localmente.
Seguridad del SSO on-prem: Autenticación resistente al phishing y hardening de Kerberos
Llaves de hardware FIDO2 y hardening de la delegación Kerberos
La integración de llaves de hardware sigue un camino predecible: registrar la credencial FIDO2 en el objeto de usuario, habilitar la emulación de tarjeta inteligente y dejar que Kerberos PKINIT emita un TGT después de que la llave desbloquee el certificado. YubiKey, Token2 y Hideez Key cubren el inicio de sesión en Windows y RDP mediante el mismo flujo.
El hardening de Kerberos es innegociable. Deshabilitar la delegación sin restricciones en todo el bosque, aplicar únicamente AES-256, auditar los SPN con setspn -X y colocar cada identidad de Nivel 0 en el grupo Protected Users. Esto neutraliza el Kerberoasting, la falsificación de golden ticket y las rutas de DCSync.
Aplicar Zero Trust sobre el SSO on-prem
El controlador de dominio permanece; la confianza implícita, no. Añadir MFA contextual en el IdP, enviar señales de postura del dispositivo desde el agente de endpoint, proteger las acciones de administración con elevación just-in-time y reevaluar las sesiones ante cambios de riesgo. El directorio sigue funcionando; la verificación se vuelve continua.
Resolución de problemas, migración desde ADFS y compliance
Fallos más frecuentes y comandos de diagnóstico
La mayoría de los incidentes de SSO on-prem se deben a seis fallos recurrentes. Los timeouts de DCLocator aparecen cuando el cliente no puede alcanzar un DC con escritura; compruebe con nltest /dsgetdc:contoso.corp.com y verifique la afinidad de sitio. Los errores de resolución NETBIOS con STATUS_BAD_VALIDATION_CLASS 0xc00000a7 indican que la aplicación envió contoso\user en lugar de un UPN; fuerce la sintaxis user@contoso.corp.com. Las discrepancias de UPN rompen las aserciones SAML, el desfase de reloj Kerberos superior a 5 minutos invalida los tickets (audite con w32tm /monitor), los SPN duplicados impiden la emisión de tickets (setspn -X los detecta) y las cadenas de certificados rotas matan PKINIT. Use klist purge y luego klist para inspeccionar los tickets en caché.
Migración desde ADFS y correspondencia con NIS2, GDPR, HIPAA, PCI-DSS
Retirar ADFS por fases: inventariar las partes de confianza, clasificar por protocolo (WS-Fed frente a SAML u OIDC), seleccionar el stack objetivo, ejecutar la coexistencia y luego hacer el corte. Mapear los controles a NIS2 Art. 21, GDPR Art. 32, HIPAA §164.312(a)(2)(i) y PCI-DSS 8.3–8.5.
Preguntas Frecuentes
¿Puedo configurar SSO on-prem sin ADFS ni la licencia completa de Microsoft Entra ID P1/P2?
Sí. Un diseño basado únicamente en Kerberos respaldado por Active Directory proporciona inicio de sesión único para estaciones de trabajo unidas al dominio sin ningún nivel en la nube. Para aplicaciones modernas, combine un proxy SAML ligero o un proveedor de identidad on-prem con AD como fuente de directorio. Hideez Server combinado con llaves FIDO2 cubre el inicio de sesión en Windows, RDP y recursos heredados sin Entra ID P1/P2.
¿Qué llaves de hardware FIDO2 admiten SSO on-prem sin contraseña con Active Directory?
Cualquier autenticador certificado FIDO2 funciona, incluidos Hideez Key, YubiKey y Feitian. Para AD on-prem, la llave debe admitir el flujo de verificación de usuario WebAuthn y estar emparejada con un servidor que intermedie tickets Kerberos tras la atestación.
¿Cómo acceden los dispositivos unidos únicamente a Entra a los recursos compartidos on-prem y a las aplicaciones heredadas?
A través de Cloud Kerberos Trust o un servidor de autenticación on-prem que emite TGTs tras la verificación FIDO2, proporcionando al dispositivo una sesión Kerberos válida para rutas UNC y aplicaciones integradas en Windows.
¿Listo para retirar ADFS y desplegar SSO resistente al phishing en su entorno híbrido? Reserve una demo técnica con el equipo de Hideez o explore el programa de partners de Hideez para ofrecer acceso sin contraseña FIDO2 a sus clientes.