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 домен за кој никој не се грижи станува застарен. Синџир што никој не може да го опише е синџир што никој не може да го отстрани грешката.