Kerberos SSO i VPN na Macu: porównaj dwie ścieżki logowania

Dwa mechanizmy dają na Macu ten sam przyjazny wynik, a pod spodem zachowują się zupełnie inaczej. Jeden pobiera bilety Kerberos przez rozszerzenie SSO i przekazuje je uczestniczącym aplikacjom. Drugi utrzymuje sesję przeglądarki u dostawcy tożsamości i pozwala aplikacjom web ją honorować. Różnią się tym, czego potrzebują w sieci, jak długo ważne są ich poświadczenia i co dzieje się w chwili, gdy tunel pada.

Dwa mechanizmy, jeden ekran logowania

Ścieżka oparta na biletach zależy od domeny Kerberos, centrum dystrybucji kluczy i zegara, który się z nim zgadza. Ścieżka przeglądarki zależy od osiągalnego dostawcy tożsamości, pliku cookie lub tokenu oraz aplikacji, która ufa temu wystawcy. Oba można skonfigurować tak, by startowały przy logowaniu, dlatego bywają mylone z tą samą funkcją. Aplikacje decydują, którą z dwóch akceptują, a Mac może legalnie uruchamiać obie jednocześnie.

Porównaj je, pytając, co aplikacja sprawdza, gdy użytkownik ją otwiera. Usługa plików przyłączona do domeny Kerberos chce biletu usługi i żadna ilość sesji przeglądarki jej nie zadowoli. Aplikacja web za nowoczesnym dostawcą tożsamości chce tokenu tego dostawcy i całkowicie ignoruje bilet Kerberos. Gdy wiesz, która kontrola zachodzi, pytania o wdrożenie stają się konkretne, a nie ogólne.

Czego rozszerzenie Kerberos potrzebuje w sieci

Przewodnik Apple po rozszerzeniu Kerberos SSO opisuje natywne uwierzytelnianie Active Directory z proaktywnym pozyskiwaniem biletów, połączone z kontami lokalnymi zamiast przyłączenia do domeny. Czego nie potrafi, to wymyślić drogi do kontrolerów domeny. Mac potrzebuje resolvera, który odpowiada na rekordy usług Kerberos, i trasy, która dociera do nich przez zatwierdzony tunel. Profil, który instaluje się czysto, niczego nie dowodzi, dopóki domeny nie można faktycznie odkryć z klienta.

Sprawdź odkrywanie, zanim sprawdzisz poświadczenia: rekordy SRV domeny Kerberos muszą się rozwiązać, a adresy, które zwracają, muszą być osiągalne po podniesieniu VPN. Czas jest równie ważny jak osiągalność, ponieważ Kerberos odrzuca żądania od zegara, który odchylił się poza tolerancję, a błąd, który to daje, wygląda jak niepowodzenie uwierzytelniania. Mac, który nie dotrze do źródła czasu, gdy tunel jest wyłączony, ponownie zawiedzie w chwili jego powrotu. Napraw źródło czasu jako część wdrożenia, a nie jako reakcję na incydent.

klist
sudo sntp -sS time.apple.com

VPN dla poszczególnych aplikacji decyduje, czy rozszerzenie może działać

Pełny tunel kieruje wszystko i ukrywa ten problem. Konfiguracja dla poszczególnych aplikacji kieruje tylko aplikacje nazwane w profilu VPN, a rozszerzenie SSO samo jest procesem, który potrzebuje sieci, by pobrać bilety. Jeśli nie ma go w mapowaniu, lokalne logowanie się udaje, tunel wstaje dla przeglądarki, a pozyskanie biletów nadal zawodzi.

Przeczytaj konfigurację VPN i wypisz każdą aplikację, którą ma obejmować, następnie dodaj komponent SSO przez udokumentowany mechanizm mapowania, a nie przez zgadywanie identyfikatora pakietu. Zmapowanie widocznego klienta, a nie komponentu za nim, to klasyczna wersja tego błędu. Trzymaj mapowanie w tym samym profilu zarządzanym co rozszerzenie, aby zmiana w jednym nie mogła po cichu unieważnić drugiego. Testuj z użytkownikiem, który nigdy nie logował się na tym Macu, ponieważ buforowany bilet może sprawić, że zepsuta ścieżka wygląda zdrowo, a potem przetestuj ponownie po zmianie hasła.

Sesja tożsamości w przeglądarce to inna umowa

Sesja przeglądarki nie ma domeny Kerberos, biletu usługi ani tolerancji zegara w sensie Kerberos. Ma wystawcę, czas życia tokenu i ścieżkę odświeżania, a jej tryby awarii to przekierowania, które nigdy się nie kończą, i pliki cookie, które okno prywatne odrzuca. Traktowanie jej jako zamiennika ścieżki biletów jest bezpieczne tylko tam, gdzie sama aplikacja akceptuje tego wystawcę. Kopiowanie odpowiedzi uwierzytelniania z portalu VPN do niepowiązanej usługi nie jest integracją, choćby skrót wydawał się wygodny.

Gdy oba mechanizmy są wdrożone, udokumentuj, które aplikacje używają którego, bo rozmowa ze wsparciem od tego zależy. Użytkownik, który zgłasza, że jest zalogowany, ale nie może otworzyć udziału plikowego, opisuje dwa systemy, a odpowiedź brzmi, że ścieżka biletów nigdy nie zadziałała. Użytkownik, który otwiera udział, ale nie portal intranetowy, opisuje sytuację odwrotną, a nazwanie mechanizmu w zgłoszeniu oszczędza jedną rundę pytań.

Przejdź sekwencję, nie części

Przejdź cały łańcuch ze zwykłym zarejestrowanym kontem: logowanie lokalne, tunel, pozyskanie biletu, a potem jedna rzeczywista operacja wobec usługi. Powtórz to po ponownym połączeniu tunelu i po celowej zmianie hasła, ponieważ każdy z tych przypadków ćwiczy inną część logiki czasu życia. To, że każdy etap przechodzi osobno, nie jest tym samym co działający łańcuch. Łańcuch jest tym, czego doświadcza użytkownik, i to musi obejmować przypadek akceptacyjny.

Zapisz właściciela profilu, metodę uwierzytelniania VPN, ścieżkę odkrywania domeny i mapowanie aplikacji rozszerzenia w jednym miejscu. Ten zapis czyni przepływ odtwarzalnym przez kogoś, kto go nie budował. Następnie sprawdź awarię, na którą najprawdopodobniej się natkniesz, wygasły bilet przy wyłączonym tunelu, i potwierdź, że klient wraca do sprawności bez restartu, bo wdrożenie, które działa tylko od zimnego startu, nie jest skończone.

Zanotuj też właściciela każdego etapu, bo domena Kerberos, o którą nikt nie dba, staje się przestarzała. Łańcuch, którego nikt nie potrafi opisać, to łańcuch, którego nikt nie potrafi debugować.