Kerberos SSO e VPN sul Mac: confrontate i due percorsi di accesso

Due meccanismi producono lo stesso risultato amichevole su un Mac e si comportano in modo del tutto diverso sotto la superficie. Uno ottiene ticket Kerberos tramite un’estensione SSO e li consegna alle applicazioni partecipanti. L’altro mantiene una sessione del browser presso un provider di identità e lascia che le applicazioni web la rispettino. Differiscono in ciò che richiedono sulla rete, in quanto durano le loro credenziali e in ciò che accade nel momento in cui il tunnel cade.

Due meccanismi, una schermata di accesso

Il percorso basato sui ticket dipende da un dominio Kerberos, da un centro di distribuzione delle chiavi e da un orologio che concordi con esso. Il percorso del browser dipende da un provider di identità raggiungibile, da un cookie o token e da un’applicazione che si fida di quell’emittente. Entrambi possono essere configurati per avviarsi all’accesso, ed è per questo che vengono confusi con la stessa funzione. Le applicazioni decidono quale dei due accettano, e un Mac può eseguire legittimamente entrambi insieme.

Confrontateli chiedendo che cosa verifica l’applicazione quando un utente la apre. Un servizio file associato al dominio Kerberos vuole un ticket di servizio, e nessuna quantità di sessione del browser lo soddisfarà. Un’applicazione web dietro un provider di identità moderno vuole il token di quel provider e ignora del tutto il ticket Kerberos. Una volta che sapete quale verifica avviene, le domande di distribuzione diventano specifiche invece che generali.

Che cosa serve all’estensione Kerberos sulla rete

La guida all’estensione Kerberos SSO di Apple descrive l’autenticazione nativa di Active Directory con acquisizione proattiva dei ticket, abbinata ad account locali invece che a un binding di dominio. Ciò che non può fare è inventare un percorso verso i controller di dominio. Il Mac ha bisogno di un resolver che risponda ai record di servizio Kerberos e di una rotta che li raggiunga attraverso il tunnel approvato. Un profilo che si installa pulito non dimostra nulla finché il dominio non può essere realmente scoperto dal client.

Verificate la scoperta prima di verificare le credenziali: i record SRV del dominio Kerberos devono risolversi, e gli indirizzi che restituiscono devono essere raggiungibili una volta che la VPN è attiva. Il tempo conta quanto la raggiungibilità, perché Kerberos rifiuta le richieste di un orologio che ha superato la sua tolleranza, e l’errore che ne deriva sembra un fallimento di autenticazione. Un Mac che non raggiunge una fonte di tempo mentre il tunnel è abbassato fallirà di nuovo nel momento in cui torna. Correggete la fonte di tempo come parte della distribuzione, non come risposta a un incidente.

klist
sudo sntp -sS time.apple.com

La VPN per applicazione decide se l’estensione può funzionare

Un tunnel completo instrada tutto e nasconde questo problema. Una configurazione per applicazione instrada solo le applicazioni nominate nel profilo VPN, e l’estensione SSO è essa stessa un processo che ha bisogno della rete per ottenere i ticket. Se non è nella mappatura, l’accesso locale riesce, il tunnel sale per il browser e l’acquisizione dei ticket fallisce comunque.

Leggete la configurazione della VPN e listate ogni applicazione che dovrebbe coprire, poi aggiungete il componente SSO tramite il meccanismo di mappatura documentato invece di indovinare un bundle identifier. Mappare il client visibile e non il componente dietro di esso è la versione classica di questo errore. Tenete la mappatura nello stesso profilo gestito dell’estensione, così che una modifica a uno non possa invalidare silenziosamente l’altro. Provate con un utente che non ha mai effettuato l’accesso su quel Mac, perché un ticket in cache può far sembrare sano un percorso rotto, poi provate di nuovo dopo un cambio di password.

Una sessione d’identità nel browser è un contratto diverso

Una sessione del browser non ha dominio Kerberos, né ticket di servizio, né tolleranza dell’orologio nel senso di Kerberos. Ha un emittente, una durata del token e un percorso di aggiornamento, e le sue modalità di guasto sono reindirizzamenti che non si completano mai e cookie che una finestra privata scarta. Trattarla come sostituto del percorso dei ticket è sicuro solo dove l’applicazione stessa accetta quell’emittente. Copiare una risposta di autenticazione dal portale VPN a un servizio non correlato non è integrazione, per comoda che sembri la scorciatoia.

Quando entrambi i meccanismi sono distribuiti, documentate quali applicazioni usano quale, perché la conversazione di supporto dipende da questo. Un utente che riferisce di essere connesso ma di non poter aprire una condivisione file sta descrivendo due sistemi, e la risposta è che il percorso dei ticket non è mai stato eseguito. Un utente che può aprire la condivisione ma non il portale intranet descrive l’opposto, e nominare il meccanismo nel ticket risparmia un giro di domande.

Percorrete la sequenza, non i pezzi

Percorrete l’intera catena con un normale account registrato: accesso locale, tunnel, acquisizione dei ticket, poi una vera operazione su un servizio. Ripetetela dopo che il tunnel si è riconnesso e dopo un cambio di password deliberato, perché ciascuno di questi casi esercita una parte diversa della logica di durata. Il fatto che ogni fase passi da sola non è lo stesso della catena che funziona. La catena è ciò che l’utente vive, ed è ciò che il caso di accettazione deve coprire.

Registrate il proprietario del profilo, il metodo di autenticazione VPN, il percorso di scoperta del dominio e la mappatura delle applicazioni dell’estensione in un unico posto. È quel registro che rende il flusso riproducibile da qualcuno che non l’ha costruito. Poi verificate il guasto che incontrerete più probabilmente, un ticket scaduto mentre il tunnel è abbassato, e confermate che il client si riprende senza riavvio, perché una distribuzione che funziona solo da un avvio a freddo non è finita.

Annotate anche il proprietario di ogni fase, perché un dominio Kerberos che nessuno mantiene diventa obsoleto. Una catena che nessuno può descrivere è una catena che nessuno può eseguire il debug.