Агент — перехватчик трафика на Windows. Он заворачивает соединения приложений на прокси-сервер и передаёт данные для аутентификации. В корпоративной среде стандарт — Kerberos. Доменный вход без пароля. Требование безопасности. Пока не начинаешь это тестировать.

В ручном режиме проверка Kerberos занимала часы. Нужно было поднять домен, выпустить keytab, настроить SPN, получить тикет и убедиться, что Агент передал его на прокси. Одна опечатка в krb5.conf — и трафик падал с 407 Proxy Authentication Required. Разбираться в логах вручную — боль.

Мы автоматизировали этот ад.

Библиотеки, на которых всё держится

requests-kerberos — главный инструмент. Позволяет отправлять HTTP-запросы с Kerberos-тикетом. HTTPKerberosAuth(mutual_authentication=OPTIONAL) подхватывает тикет из кэша и передаёт его в заголовке Authorization.

pywinrm[kerberos] — управление Windows-клиентом. Доменный вход вместо пароля. Нужен, чтобы проверить состояние Агента и очистить тикет-кэш через klist purge.

Fabric — SSH к Linux-нодам, где живёт KDC. Выпуск keytab, настройка SPN, проверка krb5.conf.

allure-pytest — отчёты. По каждому кейсу видно, на каком шаге тикет сломался.

Кейс №1. Проверка успешной Kerberos-аутентификации

Задача: убедиться, что Агент передаёт тикет на прокси, и трафик проходит.

Сценарий:

1. На Linux-ноде через Fabric проверяем, что keytab выпущен и SPN совпадает с rcmd/domain.local@test.com. 2. На Windows-клиенте через pywinrm очищаем старый кэш тикетов: klist purge. 3. Выполняем requests.get(“http://example.org”, auth=HTTPKerberosAuth(…)). 4. Смотрим код ответа. Если 200 — тикет ушёл, Агент передал его, прокси пустил. Если 407 — где-то разрыв.

Проблема: тест падал на этапе получения тикета, если KDC был недоступен. Добавили ретраи. Через три попытки тикет появлялся. Без ретраев тест считался упавшим, хотя проблема была в сети.

Кейс №2. Истечение срока действия тикета (TTL)

Kerberos-тикет живёт ограниченное время. Если Агент держит соединение дольше, чем TTL, тикет протухает. Прокси возвращает 401. Пользователь теряет доступ.

Автоматизация:

1. Запрашиваем тикет с коротким TTL (например, 60 секунд). 2. Отправляем запрос через Агент. 3. Ждём 70 секунд. 4. Повторяем запрос с тем же тикетом.

Ожидаем 401. Если получаем 200 — значит, Агент не проверяет срок действия тикета. Это дыра.

На практике мы ловили именно эту гонку. Тикет истекал быстрее, чем проходил запрос. Тест выявлял разницу в секундах. Без автоматизации такое не заметить.

Кейс №3. Fallback на NTLM при отсутствии Kerberos

Kerberos работает не всегда. Гибридные среды, старые приложения, неверные SPN. Агент должен уметь переключаться на NTLM. Проверяем.

Сценарий:

1. Настраиваем прокси-сервер только на NTLM. 2. Убеждаемся, что Kerberos-тикет отсутствует. 3. Отправляем запрос через Агент. 4. Ждём 200, а не 407.

Если Агент не умеет в fallback, трафик падает. Тест это ловит.

Кейс №4. Проверка конфигурации KDC

Опечатка в krb5.conf или неверный SPN — типичная причина сбоев. Автоматизируем проверку.

1. Через Fabric читаем krb5.conf на Linux-ноде. 2. Сверяем realm, KDC-адрес и шифрование (aes256-cts-hmac-sha1-96). 3. Если параметры не совпадают — тест падает с понятным сообщением.

Так мы ловим ошибки конфигурации до того, как они попадут в прод.

Итог

Четыре кейса. Автоматизация убирает ручной перебор и оставляет факты. requests-kerberos даёт тикет, pywinrm чистит кэш, Fabric проверяет KDC, allure-pytest собирает единую картину в виде отчёта.

p.s уточню у коллег, могу ли показать код фреймворка без ущерба для продукта, чтобы более предметно писать посты без абстракции 😅