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, о котором никто не заботится, устаревает. Цепочка, которую никто не может описать, — это цепочка, которую никто не может отладить.