Kerberos SSO и VPN на Mac: сравнете двата пътя за вход

Два механизма дават на Mac еднакъв приятен резултат и се държат напълно различно отдолу. Единият получава Kerberos билети чрез SSO разширение и ги предава на участващите приложения. Другият поддържа браузърна сесия при доставчик на самоличност и позволява на уеб приложенията да я приемат. Те се различават по това какво им е нужно в мрежата, колко дълго издържат удостоверенията им и какво се случва в мига, в който тунелът падне.

Два механизма, един екран за вход

Пътят с билети зависи от домейн на Kerberos, център за разпределение на ключове и часовник, който е съгласуван с тях. Пътят през браузъра зависи от достъпен доставчик на самоличност, бисквитка или токен и приложение, което се доверява на този издател. И двата могат да бъдат настроени да стартират при вход, поради което се бъркат с една и същa функция. Приложенията решават кой от двата приемат и Mac може законно да работи и с двата едновременно.

Сравнете ги, като попитате какво проверява приложението, когато потребител го отвори. Файлова услуга, присъединена към домейна на Kerberos, иска билет за услуга и никакво количество браузърна сесия няма да я задоволи. Уеб приложение зад модерен доставчик на самоличност иска токена на този доставчик и напълно игнорира Kerberos билета. Щом знаете коя проверка се извършва, въпросите за внедряването стават конкретни, а не общи.

Какво е нужно на Kerberos разширението в мрежата

Ръководството на Apple за Kerberos SSO разширението описва вградена автентикация с Active Directory с проактивно получаване на билети, съчетана с локални акаунти, а не с обвързване към домейна. Това, което не може, е да измисли път до контролерите на домейна. На Mac му трябва преобразувател, който отговаря на Kerberos служебните записи, и маршрут, който ги достига през одобрения тунел. Профил, който се инсталира чисто, не доказва нищо, докато домейнът не може действително да бъде открит от клиента.

Проверете откриването, преди да проверявате удостоверенията: SRV записите за домейна на Kerberos трябва да се разрешават, а адресите, които връщат, трябва да са достъпни, след като VPN е вдигнат. Времето е също толкова важно, колкото достъпността, защото Kerberos отхвърля заявки от часовник, излязъл извън допустимия си диапазон, и грешката изглежда като неуспешна автентикация. Mac, който не може да достигне източник на време, докато тунелът е свален, ще се провали отново в мига, в който той се върне. Оправете източника на време като част от внедряването, а не като реакция на инцидент.

klist
sudo sntp -sS time.apple.com

VPN за отделни приложения решава дали разширението може да работи

Пълният тунел маршрутизира всичко и скрива този проблем. Конфигурацията за отделни приложения маршрутизира само приложенията, посочени в VPN профила, а SSO разширението само по себе си е процес, който се нуждае от мрежата, за да получава билети. Ако го няма в съпоставянето, локалният вход успява, тунелът се вдига за браузъра, а получаването на билет все още се проваля.

Прочетете VPN конфигурацията и избройте всяко приложение, което тя трябва да покрива, след което добавете SSO компонента чрез документирания механизъм за съпоставяне, а не като гадаете идентификатор на пакет. Да съпоставите видимия клиент, а не компонента зад него, е класическата версия на тази грешка. Дръжте съпоставянето в същия управляван профил като разширението, за да не може промяна в едното тихо да обезсили другото. Тествайте с потребител, който никога не е влизал на този Mac, защото кеширан билет може да направи счупен път да изглежда здрав, след което тествайте отново след смяна на паролата.

Сесията за самоличност в браузъра е друг договор

Браузърната сесия няма домейн на Kerberos, няма билет за услуга и няма толеранс на часовника в смисъла на Kerberos. Тя има издател, срок на живота на токена и път за обновяване, а режимите ѝ на отказ са пренасочвания, които никога не завършват, и бисквитки, които частен прозорец изхвърля. Да я третирате като заместител на пътя с билети е безопасно само там, където приложението само приема този издател. Копирането на автентикационен отговор от VPN портала в несвързана услуга не е интеграция, колкото и удобен да изглежда този пряк път.

Когато и двата механизма са внедрени, документирайте кои приложения кой използват, защото разговорът с поддръжката зависи от това. Потребител, който съобщава, че е влязъл, но не може да отвори файлов ресурс, описва две системи и отговорът е, че пътят с билети никога не е стартирал. Потребител, който отваря ресурса, но не и интранет портала, описва обратното, а назоваването на механизма в заявката спестява един кръг въпроси.

Извървете последователността, а не частите

Извървете цялата верига с обикновен регистриран акаунт: локален вход, тунел, получаване на билет, след това една реална операция срещу услуга. Повторете след повторно свързване на тунела и след умишлена смяна на паролата, защото всеки от тези случаи задейства различна част от логиката на жизнения цикъл. Успешното преминаване на всеки етап поотделно не е същото като работеща верига. Веригата е това, което потребителят изживява, и тя е това, което приемният тест трябва да покрие.

Запишете собственика на профила, метода за автентикация на VPN, пътя за откриване на домейна и съпоставянето на приложенията на разширението на едно място. Този запис прави потока възпроизводим от човек, който не го е изградил. След това проверете отказа, който най-вероятно ще срещнете, изтекъл билет, докато тунелът е свален, и потвърдете, че клиентът се възстановява без рестартиране, защото внедряване, което работи само от студен старт, не е завършено.

Отбележете и собственика на всеки етап, защото домейн на Kerberos, за който никой не се грижи, става остарял. Верига, която никой не може да опише, е верига, която никой не може да диагностицира.