Kerberos SSO і VPN на Mac: параўнайце два шляхі ўваходу

Два механізмы даюць на Mac аднолькавы зручны вынік, але пад капотам паводзяць сябе зусім па-рознаму. Адзін атрымлівае білеты Kerberos праз пашырэнне SSO і перадае іх удзельным праграмам. Другі трымае сесію браўзера ў пастаўшчыка ідэнтычнасці і дазваляе вэб-праграмам яе прымаць. Яны розняцца ў тым, што ім патрэбна ў сетцы, як доўга жывуць іх уліковыя дадзеныя і што адбываецца ў момант падзення тунелю.

Два механізмы, адзін экран уваходу

Шлях на аснове білетаў залежыць ад дамена Kerberos, цэнтра размеркавання ключоў і гадзінніка, які з ім узгоджаны. Шлях браўзера залежыць ад дасяжнага пастаўшчыка ідэнтычнасці, кукі або токена і праграмы, якая давярае гэтаму эмітэнту. Абодва можна наладзіць на запуск пры ўваходзе, таму іх і блытаюць з адной і той жа функцыяй. Праграмы вырашаюць, які з двух яны прымаюць, і 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, за якім ніхто не сочыць, становіцца састарэлым. Ланцуг, які ніхто не можа апісаць, — гэта ланцуг, які ніхто не можа адладзіць.