OGOwnGate

Kerberos и удалёнка: почему «бесшовный вход» умирает за пределами офиса

Windows Integrated Authentication (IWA / Kerberos) кажется магией в офисной сети: нажал на ссылку и ты внутри. Но стоит сотрудникам уйти на удалёнку, как билеты протухают, рассинхрон часов ломает всё, а сисадмины тонут в тикетах. Разбираем, почему будущее за OIDC.

Kerberos-билеты против современного веб-шлюза доступа

В офисе всё было идеально.

Сотрудник приходит на рабочее место, включает корпоративный моноблок на Windows, открывает браузер, кликает на ссылку внутреннего портала — и бац! Он уже авторизован. Никаких логинов, никаких паролей, никакой двухфакторки.

В глазах руководства это выглядит как магия: *«Вот он, настоящий корпоративный стандарт! Вот как должен работать Single Sign-On!»*.

Но наступает 2020 год, потом 2022-й, потом 2026-й. Половина компании переходит на гибридный график или полную удалёнку, программисты пересаживаются на MacBook Pro, дизайнеры работают с iPad, а сисадмины начинают сходить с ума.

Потому что за пределами физического офисного кабеля хвалёный Kerberos превращается в тыкву.

---

Как работала иллюзия: анатомия Integrated Windows Authentication

То, что пользователи привыкли называть «бесшовным входом» в Windows, технически называется SPNEGO / Kerberos.

Чтобы этот фокус сработал, в локальной сети компании непрерывно крутятся шестерёнки сложнейшего криптографического протокола, созданного в MIT ещё в конце 1980-х:

1. Компьютер должен быть введен в домен Active Directory.

2. При входе в Windows машина связывается с контроллером домена (KDC) по порту 88 и получает сакральный билет — Ticket Granting Ticket (TGT).

3. Когда браузер открывает внутренний сайт, он идёт к KDC, просит сервисный билет (ST) по имени службы (SPN), шифрует его и передаёт веб-серверу в заголовке Authorization: Negotiate YII....

4. Веб-сервер расшифровывает билет и пускает пользователя.

Пока все сидят в одном помещении и воткнуты в один коммутатор, эта схема действительно работает быстро и незаметно.

Проблемы начинаются в ту же секунду, когда сотрудник отключает сетевой шнур.

---

4 причины, почему Kerberos умирает на удалёнке

1. Требование прямой видимости порта 88

Чтобы выпустить или обновить билет Kerberos, ноутбук сотрудника обязан иметь прямой сетевой доступ к контроллеру домена (KDC) по порту 88 (TCP и UDP).

На домашнем Wi-Fi или мобильном интернете контроллер домена, естественно, недоступен.

Единственный способ оживить Kerberos — заставить сотрудника подключиться к корпоративному VPN. Но тут возникает парадокс курицы и яйца: чтобы скачать профиль VPN или зайти на портал самообслуживания, сотруднику уже нужен доступ, которого без VPN нет!

2. Рассинхронизация времени (Clock Skew)

В протокол Kerberos зашита жесткая защита от атак повторного воспроизведения (Replay Attacks).

Каждый билет имеет временную метку. Если системное время на домашнем компьютере сотрудника расходится со временем на контроллере домена больше чем на 5 минут (стандартное значение MaxClockSkew), контроллер домена безжалостно отбивает авторизацию с ошибкой:

KRB_AP_ERR_SKEW: Clock skew too great.

Сотрудник перезагружает роутер, переустанавливает браузер, но войти не может, потому что домашняя Windows синхронизировалась с сервером времени Microsoft, а доменный DC отстал на шесть минут.

3. Персональный ад для macOS и Linux

Попробуйте объяснить сеньор-разработчику на macOS, почему для входа в корпоративную вики он должен:

  • Открыть терминал;
  • Вбить заклинание kinit username@COMPANY.LOCAL;
  • Ввести доменный пароль;
  • Следить, чтобы билет в /tmp/krb5cc_* не протух через 10 часов;
  • Прописать сакральный параметр network.negotiate-auth.trusted-uris в скрытых настройках Firefox.

После третьего сбоя разработчик просто плюнет и попросит завести ему локальный пароль в обход домена.

4. Мобильные устройства вне игры

Смартфоны на iOS и Android сегодня являются основным рабочим инструментом для согласования документов и переписки.

Подружить мобильный Safari с доменным Kerberos без тяжелых зарубежных MDM-систем (вроде Microsoft Intune или MobileIron) практически невозможно. Для мобилок Kerberos — абсолютно чужеродный протокол.

---

Как это устроено в современном мире: переход на Web-SSO

Мир давно понял, что тащить сетевые протоколы 80-х годов через интернет — тупиковый путь.

Современный корпоративный доступ строится на базе OpenID Connect (OIDC) и веб-шлюза (OwnGate):

1. Работает везде через стандартный HTTPS (порт 443). Не нужен открытый порт 88, не нужен постоянный Full-Tunnel VPN в офис. Шлюз доступен через защищённое веб-соединение из любой точки планеты.

2. Иммунитет к рассинхрону часов. Шлюз валидирует криптографические подписи токенов, а не миллисекунды системных часов домашнего компьютера.

3. Одинаково удобно на любом устройстве. MacBook, ноутбук на Ubuntu, рабочий ПК на Windows, личный iPhone или корпоративный планшет — везде один и тот же предсказуемый вход в один клик.

4. Обязательный второй фактор (2FA). В Kerberos второй фактор прикрутить практически невозможно. В шлюзе OwnGate двухфакторная аутентификация встроена нативно: сотрудник подтверждает вход по биометрии или коду TOTP, защищая компанию от кражи паролей.

Оставьте Kerberos для аутентификации внутри локального Windows-домена при входе на контроллеры. Все веб-приложения, сервисы и удалённые рабочие места должны общаться через современный веб-шлюз. Это спасёт тысячи часов работы техподдержки и сделает жизнь удалённых сотрудников по-настоящему комфортной.

← Все статьи