Kerberos SSO e VPN no Mac: compare as dúas rutas de inicio de sesión

Dous mecanismos producen o mesmo resultado amigable nun Mac e compórtanse de xeito completamente distinto por baixo. Un obtén tíckets Kerberos mediante unha extensión SSO e entrégaos ás aplicacións participantes. O outro mantén unha sesión de navegador cun provedor de identidade e deixa que as aplicacións web a acepten. Diferéncianse no que necesitan na rede, en canto duran as súas credenciais e no que ocorre no momento en que cae o túnel.

Dous mecanismos, unha pantalla de inicio de sesión

A ruta baseada en tíckets depende dun dominio Kerberos, un centro de distribución de claves e un reloxo que concorde con el. A ruta do navegador depende dun provedor de identidade accesible, unha cookie ou un token e unha aplicación que confíe nese emisor. Ambas poden configurarse para comezar ao iniciar sesión, por iso se confunden coa mesma función. As aplicacións deciden cal das dúas aceptan, e un Mac pode executar lexitimamente as dúas á vez.

Compáraas preguntando que comproba a aplicación cando un usuario a abre. Un servizo de ficheiros unido ao dominio Kerberos quere un tícket de servizo, e ningunha cantidade de sesión de navegador o satisfará. Unha aplicación web detrás dun provedor de identidade moderno quere o token dese provedor e ignora por completo o tícket Kerberos. Unha vez que sabe que comprobación ocorre, as preguntas de despregamento vólvense concretas en lugar de xerais.

Que necesita a extensión Kerberos na rede

A guía da extensión Kerberos SSO de Apple describe a autenticación nativa de Active Directory con obtención proactiva de tíckets, emparellada con contas locais en lugar dunha unión ao dominio. O que non pode facer é inventar unha ruta cara aos controladores de dominio. O Mac necesita un resolutor que responda aos rexistros de servizo Kerberos e unha ruta que chegue a eles a través do túnel aprobado. Un perfil que se instala limpiamente non demostra nada ata que o dominio poida descubrirse realmente desde o cliente.

Comproba o descubrimento antes de comprobar as credenciais: os rexistros SRV do dominio Kerberos deben resolverse, e os enderezos que devolven deben ser accesibles unha vez que a VPN está activa. O tempo importa tanto como a accesibilidade, porque Kerberos rexeita solicitudes dun reloxo que se desviou máis alá da súa tolerancia, e o erro que produce parece un fallo de autenticación. Un Mac que non pode chegar a unha fonte de tempo mentres o túnel está caído volverá fallar no momento en que se recupere. Corrixe a fonte de tempo como parte do despregamento e non como resposta a un incidente.

klist
sudo sntp -sS time.apple.com

A VPN por aplicación decide se a extensión pode funcionar

Un túnel completo encamiña todo e agocha este problema. Unha configuración por aplicación encamiña só as aplicacións nomeadas no perfil de VPN, e a extensión SSO é ela mesma un proceso que necesita a rede para obter tíckets. Se non está no mapeo, o inicio de sesión local ten éxito, o túnel sobe para o navegador e a obtención de tíckets segue fallando.

Le a configuración da VPN e enumera cada aplicación que debe cubrir, despois engade o compoñente SSO mediante o mecanismo de mapeo documentado en lugar de adiviñar un identificador de paquete. Mapear o cliente visible e non o compoñente que hai detrás é a versión clásica deste erro. Mantén o mapeo no mesmo perfil xestionado que a extensión, para que un cambio nun non poida invalidar silenciosamente o outro. Proba cun usuario que nunca iniciase sesión nese Mac, porque un tícket na caché pode facer que unha ruta rota pareza san, e despois proba de novo tras un cambio de contrasinal.

Unha sesión de identidade no navegador é outro contrato

Unha sesión de navegador non ten dominio Kerberos, nin tícket de servizo, nin tolerancia de reloxo no sentido de Kerberos. Ten un emisor, unha vida útil do token e unha ruta de refresco, e os seus modos de fallo son redireccións que nunca se completan e cookies que unha ventá privada descarta. Tratala como substituto da ruta de tíckets só é seguro onde a propia aplicación acepta ese emisor. Copiar unha resposta de autenticación do portal da VPN a un servizo non relacionado non é integración, por conveniente que pareza o atallo.

Cando ambos mecanismos están despregados, documenta que aplicacións usan cal, porque a conversación de soporte depende diso. Un usuario que informa que iniciou sesión pero non pode abrir un recurso compartido de ficheiros describe dous sistemas, e a resposta é que a ruta de tíckets nunca se executou. Un usuario que pode abrir o recurso pero non o portal de intranet describe o contrario, e nomear o mecanismo no tícket aforra unha rolda de preguntas.

Percorre a secuencia, non as pezas

Percorre toda a cadea cunha conta inscrita corrente: inicio de sesión local, túnel, obtención de tíckets e despois unha operación real contra un servizo. Repíteo despois de que o túnel se reconecte e despois dun cambio de contrasinal deliberado, porque cada un deses casos exercita unha parte distinta da lóxica de vida útil. Que cada etapa pase por si soa non é o mesmo que a cadea funcione. A cadea é o que o usuario experimenta, e é o que debe cubrir o caso de aceptación.

Rexistra o propietario do perfil, o método de autenticación da VPN, a ruta de descubrimento do dominio e o mapeo de aplicacións da extensión nun só lugar. Ese rexistro é o que fai o fluxo reproducible por alguén que non o construíu. Despois comproba o fallo que máis probablemente atoparás, un tícket caducado mentres o túnel está caído, e confirma que o cliente se recupera sen reiniciar, porque un despregamento que só funciona desde un arranque en frío non está terminado.

Anota tamén o propietario de cada etapa, porque un dominio Kerberos que ninguén mantén convértese nun obsoleto. Unha cadea que ninguén pode describir é unha cadea que ninguén pode depurar.