Kerberos SSO și VPN pe Mac: comparați cele două căi de autentificare

Două mecanisme produc același rezultat prietenos pe un Mac și se comportă complet diferit dedesubt. Unul obține bilete Kerberos printr-o extensie SSO și le predă aplicațiilor participante. Celălalt menține o sesiune de browser la un furnizor de identitate și lasă aplicațiile web să o accepte. Ele diferă prin ce au nevoie în rețea, cât durează acreditările lor și ce se întâmplă în momentul în care tunelul cade.

Două mecanisme, un singur ecran de autentificare

Calea bazată pe bilete depinde de un domeniu Kerberos, de un centru de distribuție a cheilor și de un ceas care este de acord cu el. Calea browserului depinde de un furnizor de identitate accesibil, de un cookie sau token și de o aplicație care are încredere în acel emitent. Ambele pot fi configurate să pornească la autentificare, motiv pentru care sunt confundate cu aceeași funcție. Aplicațiile decid pe care dintre cele două îl acceptă, iar un Mac poate rula legitim ambele simultan.

Comparați-le întrebând ce verifică aplicația atunci când un utilizator o deschide. Un serviciu de fișiere alăturat domeniului Kerberos vrea un bilet de serviciu, iar nicio cantitate de sesiune de browser nu îl va satisface. O aplicație web din spatele unui furnizor de identitate modern vrea tokenul acelui furnizor și ignoră complet biletul Kerberos. Odată ce știți ce verificare are loc, întrebările de implementare devin specifice în loc de generale.

Ce are nevoie extensia Kerberos în rețea

Ghidul Apple pentru extensia Kerberos SSO descrie autentificarea nativă Active Directory cu obținere proactivă de bilete, împerecheată cu conturi locale în loc de o legare la domeniu. Ceea ce nu poate face este să inventeze o cale către controlerele de domeniu. Mac-ul are nevoie de un resolver care răspunde înregistrărilor de serviciu Kerberos și de o rută care ajunge la ele prin tunelul aprobat. Un profil care se instalează curat nu demonstrează nimic până când domeniul nu poate fi într-adevăr descoperit de la client.

Verificați descoperirea înainte de a verifica acreditările: înregistrările SRV ale domeniului Kerberos trebuie să se rezolve, iar adresele returnate trebuie să fie accesibile după ce VPN-ul este pornit. Timpul contează la fel de mult ca accesibilitatea, deoarece Kerberos respinge cererile de la un ceas care a derapat peste toleranța sa, iar eroarea produsă arată ca o eșec de autentificare. Un Mac care nu poate ajunge la o sursă de timp cât timp tunelul este oprit va eșua din nou în momentul în care acesta revine. Remediați sursa de timp ca parte a implementării, nu ca răspuns la un incident.

klist
sudo sntp -sS time.apple.com

VPN-ul pe aplicație decide dacă extensia poate funcționa

Un tunel complet rutează tot și ascunde această problemă. O configurație pe aplicație rutează doar aplicațiile numite în profilul VPN, iar extensia SSO este ea însăși un proces care are nevoie de rețea pentru a obține bilete. Dacă nu este în mapare, autentificarea locală reușește, tunelul urcă pentru browser și obținerea biletelor eșuează în continuare.

Citiți configurația VPN și listați fiecare aplicație pe care ar trebui să o acopere, apoi adăugați componenta SSO prin mecanismul de mapare documentat, nu ghicind un identificator de pachet. Maparea clientului vizibil și nu a componentei din spatele lui este versiunea clasică a acestei greșeli. Păstrați maparea în același profil administrat ca extensia, astfel încât o modificare la unul să nu îl invalideze silențios pe celălalt. Testați cu un utilizator care nu s-a autentificat niciodată pe acel Mac, deoarece un bilet din cache poate face o cale ruptă să pară sănătoasă, apoi testați din nou după o schimbare de parolă.

O sesiune de identitate în browser este un alt contract

O sesiune de browser nu are domeniu Kerberos, bilet de serviciu și nici toleranță a ceasului în sensul Kerberos. Are un emitent, o durată de viață a tokenului și o cale de reîmprospătare, iar modurile ei de eșec sunt redirecționări care nu se termină niciodată și cookie-uri pe care o fereastră privată le aruncă. Tratarea ei ca înlocuitor pentru calea biletelor este sigură doar acolo unde aplicația însăși acceptă acel emitent. Copierea unui răspuns de autentificare din portalul VPN într-un serviciu nelegat nu este integrare, oricât de comod ar părea scurtătură.

Când ambele mecanisme sunt implementate, documentați care aplicații îl folosesc pe care, deoarece conversația de asistență depinde de asta. Un utilizator care raportează că este autentificat dar nu poate deschide o partajare de fișiere descrie două sisteme, iar răspunsul este că calea biletelor nu a rulat niciodată. Un utilizator care poate deschide partajarea dar nu portalul intranet descrie inversul, iar numirea mecanismului în tichet economisește o rundă de întrebări.

Parcurgeți secvența, nu piesele

Parcurgeți întregul lanț cu un cont înregistrat obișnuit: autentificare locală, tunel, obținere de bilete, apoi o operație reală asupra unui serviciu. Repetați după ce tunelul se reconectează și după o schimbare deliberată de parolă, deoarece fiecare dintre aceste cazuri exersează o altă parte a logicii duratei de viață. Faptul că fiecare etapă trece de una singură nu este același lucru cu lanțul care funcționează. Lanțul este ceea ce experimentează utilizatorul și este ceea ce trebuie să acopere cazul de acceptare.

Înregistrați proprietarul profilului, metoda de autentificare a VPN-ului, calea de descoperire a domeniului și maparea aplicațiilor extensiei într-un singur loc. Acea înregistrare face fluxul reproductibil de către cineva care nu l-a construit. Apoi verificați eșecul pe care cel mai probabil îl veți întâlni, un bilet expirat cât timp tunelul este oprit, și confirmați că clientul își revine fără repornire, deoarece o implementare care funcționează doar de la un start la rece nu este terminată.

Notați și proprietarul fiecărei etape, deoarece un domeniu Kerberos de care nimeni nu se ocupă devine învechit. Un lanț pe care nimeni nu îl poate descrie este un lanț pe care nimeni nu îl poate depana.