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

Два механізми дають на Mac однаковий приємний результат і поводяться зовсім по-різному під капотом. Один отримує квитки Kerberos через розширення SSO і передає їх застосункам, що беруть участь. Другий підтримує сесію браузера в постачальника ідентичності й дозволяє вебзастосункам її визнавати. Вони різняться тим, що їм потрібно в мережі, як довго діють їхні облікові дані та що відбувається в мить падіння тунелю.

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

Шлях на основі квитків залежить від домену Kerberos, центру розподілу ключів і годинника, узгодженого з ним. Шлях браузера залежить від доступного постачальника ідентичності, cookie або токена та застосунку, який довіряє цьому видавцю. Обидва можна налаштувати на запуск під час входу, тому їх плутають з однією й тією самою функцією. Застосунки вирішують, який із двох прийняти, і 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. У неї є видавець, час життя токена й шлях оновлення, а її режими відмови — це переспрямування, які ніколи не завершуються, і cookie, які приватне вікно відкидає. Ставитися до неї як до заміни шляху квитків безпечно лише там, де сам застосунок приймає цього видавця. Копіювання відповіді автентифікації з порталу VPN до незв'язаної служби — не інтеграція, хоч би яким зручним здавався цей обхід.

Коли розгорнуто обидва механізми, задокументуйте, які застосунки використовують який, бо розмова з підтримкою залежить від цього. Користувач, який повідомляє, що ввійшов, але не може відкрити файловий ресурс, описує дві системи, і відповідь — шлях квитків узагалі не запускався. Користувач, який відкриває ресурс, але не портал інтранету, описує зворотне, і згадка механізму в заявці економить один круг питань.

Пройдіть послідовність, а не частини

Пройдіть весь ланцюг звичайним зареєстрованим обліковим записом: локальний вхід, тунель, отримання квитків, потім одна реальна операція проти служби. Повторіть це після перепідключення тунелю й після навмисної зміни пароля, бо кожен із цих випадків задіює іншу частину логіки часу життя. Проходження кожного етапу окремо — не те саме, що робочий ланцюг. Ланцюг — це те, що відчуває користувач, і саме його має покривати приймальний тест.

Запишіть власника профілю, метод автентифікації VPN, шлях виявлення домену й зіставлення застосунків розширення в одному місці. Саме цей запис робить потік відтворюваним для того, хто його не будував. Потім перевірте збій, з яким ви найімовірніше зіткнетеся, протермінований квиток при опущеному тунелі, і переконайтеся, що клієнт відновлюється без перезавантаження, бо розгортання, яке працює лише з холодного старту, не завершене.

Позначте також власника кожного етапу, бо домен Kerberos, про який ніхто не дбає, стає застарілим. Ланцюг, який ніхто не може описати, — це ланцюг, який ніхто не може налагодити.