Dos mecanismos producen el mismo resultado amable en un Mac y se comportan de forma completamente distinta por debajo. Uno obtiene tiques Kerberos mediante una extensión SSO y los entrega a las aplicaciones participantes. El otro mantiene una sesión de navegador con un proveedor de identidad y permite que las aplicaciones web la acepten. Difieren en lo que necesitan en la red, en cuánto duran sus credenciales y en qué ocurre en el momento en que cae el túnel.

Dos mecanismos, una pantalla de inicio de sesión

La ruta basada en tiques depende de un dominio Kerberos, un centro de distribución de claves y un reloj que concuerde con él. La ruta del navegador depende de un proveedor de identidad accesible, una cookie o un token y una aplicación que confíe en ese emisor. Ambas pueden configurarse para empezar al iniciar sesión, por eso se confunden con la misma función. Las aplicaciones deciden cuál de las dos aceptan, y un Mac puede ejecutar legítimamente las dos a la vez.

Compárelas preguntando qué comprueba la aplicación cuando un usuario la abre. Un servicio de archivos unido al dominio Kerberos quiere un tique de servicio, y ninguna cantidad de sesión de navegador lo satisfará. Una aplicación web detrás de un proveedor de identidad moderno quiere el token de ese proveedor e ignora por completo el tique Kerberos. Una vez que sabe qué comprobación ocurre, las preguntas de despliegue se vuelven concretas en lugar de generales.

Qué necesita la extensión Kerberos en la red

La guía de la extensión Kerberos SSO de Apple describe la autenticación nativa de Active Directory con obtención proactiva de tiques, emparejada con cuentas locales en lugar de una unión al dominio. Lo que no puede hacer es inventar una ruta hacia los controladores de dominio. El Mac necesita un resolutor que responda a los registros de servicio Kerberos y una ruta que llegue a ellos a través del túnel aprobado. Un perfil que se instala limpiamente no demuestra nada hasta que el dominio puede descubrirse realmente desde el cliente.

Compruebe el descubrimiento antes de comprobar las credenciales: los registros SRV del dominio Kerberos deben resolverse, y las direcciones que devuelven deben ser accesibles una vez que la VPN está activa. El tiempo importa tanto como la accesibilidad, porque Kerberos rechaza solicitudes de un reloj que se ha desviado más allá de su tolerancia, y el error que produce parece un fallo de autenticación. Un Mac que no puede llegar a una fuente de tiempo mientras el túnel está caído volverá a fallar en el momento en que se recupere. Corrija la fuente de tiempo como parte del despliegue y no como respuesta a un incidente.

klist
sudo sntp -sS time.apple.com

La VPN por aplicación decide si la extensión puede funcionar

Un túnel completo enruta todo y oculta este problema. Una configuración por aplicación enruta solo las aplicaciones nombradas en el perfil de VPN, y la extensión SSO es ella misma un proceso que necesita la red para obtener tiques. Si no está en la asignación, el inicio de sesión local tiene éxito, el túnel se levanta para el navegador y la obtención de tiques sigue fallando.

Lea la configuración de la VPN y enumere cada aplicación que debe cubrir, luego añada el componente SSO mediante el mecanismo de asignación documentado en lugar de adivinar un identificador de paquete. Asignar el cliente visible y no el componente que hay detrás es la versión clásica de este error. Mantenga la asignación en el mismo perfil gestionado que la extensión, para que un cambio en una no pueda invalidar silenciosamente la otra. Pruebe con un usuario que nunca haya iniciado sesión en ese Mac, porque un tique en caché puede hacer que una ruta rota parezca sana, y luego pruebe de nuevo tras un cambio de contraseña.

Una sesión de identidad en el navegador es otro contrato

Una sesión de navegador no tiene dominio Kerberos, ni tique de servicio, ni tolerancia de reloj en el sentido de Kerberos. Tiene un emisor, una vida útil del token y una ruta de refresco, y sus modos de fallo son redirecciones que nunca se completan y cookies que una ventana privada descarta. Tratarla como sustituto de la ruta de tiques solo es seguro donde la aplicación misma acepta a ese emisor. Copiar una respuesta de autenticación del portal de la VPN a un servicio no relacionado no es integración, por conveniente que parezca el atajo.

Cuando ambos mecanismos están desplegados, documente qué aplicaciones usan cuál, porque la conversación de soporte depende de ello. Un usuario que informa que ha iniciado sesión pero no puede abrir un recurso compartido de archivos describe dos sistemas, y la respuesta es que la ruta de tiques nunca se ejecutó. Un usuario que puede abrir el recurso pero no el portal de intranet describe lo contrario, y nombrar el mecanismo en el tique ahorra una ronda de preguntas.

Recorra la secuencia, no las piezas

Recorra toda la cadena con una cuenta inscrita corriente: inicio de sesión local, túnel, obtención de tiques y luego una operación real contra un servicio. Repítalo después de que el túnel se reconecte y después de un cambio de contraseña deliberado, porque cada uno de esos casos ejercita una parte distinta de la lógica de vida útil. Que cada etapa pase por sí sola no es lo mismo que la cadena funcione. La cadena es lo que el usuario experimenta, y es lo que debe cubrir el caso de aceptación.

Registre el propietario del perfil, el método de autenticación de la VPN, la ruta de descubrimiento del dominio y la asignación de aplicaciones de la extensión en un solo lugar. Ese registro es lo que hace el flujo reproducible por alguien que no lo construyó. Luego compruebe el fallo que más probablemente encontrará, un tique caducado mientras el túnel está caído, y confirme que el cliente se recupera sin reiniciar, porque un despliegue que solo funciona desde un arranque en frío no está terminado.

Anote también el propietario de cada etapa, porque un dominio Kerberos que nadie mantiene se convierte en obsoleto. Una cadena que nadie puede describir es una cadena que nadie puede depurar.

Artículos relacionados