Kerberos SSO i VPN al Mac: compareu els dos camins d'inici de sessió

Dos mecanismes produeixen el mateix resultat agradable en un Mac i es comporten de manera completament diferent per dins. Un obté tiquets Kerberos mitjançant una extensió SSO i els lliura a les aplicacions participants. L'altre manté una sessió de navegador amb un proveïdor d'identitat i deixa que les aplicacions web l'acceptin. Es diferencien en què necessiten a la xarxa, quant duren les seves credencials i què passa en el moment que el túnel cau.

Dos mecanismes, una pantalla d'inici de sessió

El camí basat en tiquets depèn d'un domini Kerberos, d'un centre de distribució de claus i d'un rellotge que hi concordin. El camí del navegador depèn d'un proveïdor d'identitat accessible, d'una galeta o testimoni i d'una aplicació que confiï en aquest emissor. Tots dos es poden configurar perquè s'iniciïn en entrar, i per això es confonen amb la mateixa funció. Les aplicacions decideixen quin dels dos accepten, i un Mac pot executar legítimament tots dos alhora.

Compareu-los preguntant què comprova l'aplicació quan un usuari l'obre. Un servei de fitxers unit al domini Kerberos vol un tiquet de servei, i cap quantitat de sessió de navegador no el satisfarà. Una aplicació web darrere d'un proveïdor d'identitat modern vol el testimoni d'aquest proveïdor i ignora completament el tiquet Kerberos. Quan sabeu quina comprovació es fa, les preguntes de desplegament es tornen concretes en lloc de generals.

Què necessita l'extensió Kerberos a la xarxa

La guia de l'extensió SSO de Kerberos d'Apple descriu l'autenticació nativa d'Active Directory amb obtenció proactiva de tiquets, aparellada amb comptes locals en lloc d'una unió al domini. El que no pot fer és inventar un camí cap als controladors de domini. El Mac necessita un resolutor que respongui als registres de servei de Kerberos i una ruta que hi arribi a través del túnel aprovat. Un perfil que s'instal·la net no demostra res fins que el domini es pot descobrir realment des del client.

Comproveu el descobriment abans de comprovar les credencials: els registres SRV del domini Kerberos s'han de resoldre, i les adreces que retornen han de ser accessibles un cop la VPN estigui engegada. El temps importa tant com l'accessibilitat, perquè Kerberos rebutja peticions d'un rellotge que s'ha desviat més enllà de la seva tolerància, i l'error que produeix sembla una fallada d'autenticació. Un Mac que no pot arribar a una font de temps mentre el túnel està caigut tornarà a fallar en el moment que es recuperi. Arregleu la font de temps com a part del desplegament, no com una resposta a un incident.

klist
sudo sntp -sS time.apple.com

La VPN per aplicació decideix si l'extensió pot funcionar

Un túnel complet encamina-ho tot i amaga aquest problema. Una configuració per aplicació només encamina les aplicacions nomenades al perfil de VPN, i l'extensió SSO és ella mateixa un procés que necessita la xarxa per obtenir tiquets. Si no és al mapatge, l'inici de sessió local té èxit, el túnel s'aixeca per al navegador i l'obtenció de tiquets continua fallant.

Llegiu la configuració de la VPN i llisteu cada aplicació que ha de cobrir, i després afegiu el component SSO mitjançant el mecanisme de mapatge documentat en lloc d'endevinar un identificador de paquet. Mapejar el client visible i no el component que hi ha darrere és la versió clàssica d'aquest error. Mantingueu el mapatge al mateix perfil gestionat que l'extensió, perquè un canvi en un no pugui invalidar l'altre en silenci. Proveu-ho amb un usuari que no hagi iniciat mai sessió en aquell Mac, perquè un tiquet a la memòria cau pot fer que un camí trencat sembli sa, i torneu a provar-ho després d'un canvi de contrasenya.

Una sessió d'identitat al navegador és un contracte diferent

Una sessió de navegador no té domini Kerberos, ni tiquet de servei, ni tolerància de rellotge en el sentit de Kerberos. Té un emissor, un temps de vida del testimoni i un camí de refresc, i les seves maneres de fallar són redireccions que mai no es completen i galetes que una finestra privada descarta. Tractar-la com a substitut del camí de tiquets només és segur quan l'aplicació mateixa accepta aquest emissor. Copiar una resposta d'autenticació del portal de la VPN en un servei no relacionat no és integració, per convenient que sembli la drecera.

Quan tots dos mecanismes estan desplegats, documenteu quines aplicacions en fan servir quin, perquè la conversa de suport en depèn. Un usuari que diu que ha iniciat sessió però no pot obrir un recurs compartit de fitxers descriu dos sistemes, i la resposta és que el camí de tiquets no es va executar mai. Un usuari que pot obrir el recurs però no el portal d'intranet descriu el contrari, i nomenar el mecanisme al tiquet estalvia una ronda de preguntes.

Recorreu la seqüència, no les peces

Recorreu tota la cadena amb un compte inscrit corrent: inici de sessió local, túnel, obtenció de tiquets i després una operació real contra un servei. Repetiu-ho després que el túnel es reconnecti i després d'un canvi de contrasenya deliberat, perquè cadascun d'aquests casos exerceix una part diferent de la lògica de vida útil. Que cada etapa passi per si sola no és el mateix que la cadena funcioni. La cadena és el que l'usuari experimenta, i és el que ha de cobrir el cas d'acceptació.

Enregistreu el propietari del perfil, el mètode d'autenticació de la VPN, el camí de descobriment del domini i el mapatge d'aplicacions de l'extensió en un sol lloc. Aquest registre és el que fa el flux reproduïble per algú que no el va construir. Després comproveu la fallada que més probablement trobareu, un tiquet caducat mentre el túnel està caigut, i confirmeu que el client es recupera sense reiniciar, perquè un desplegament que només funciona des d'un inici en fred no està acabat.

Anoteu també el propietari de cada etapa, perquè un domini Kerberos que ningú no manté es converteix en un domini obsolet. Una cadena que ningú no pot descriure és una cadena que ningú no pot depurar.