Kerberos SSO для внутреннего портала: входим без пароля через Active Directory

У клиента внутренний портал на базе ASP.NET - согласование договоров, заявки на закупки, HR-запросы. Портал живёт в интранете, все пользователи - в домене Active Directory. При этом каждый раз при открытии портала браузер выдавал форму с полями логин/пароль. Сотрудники вводили доменные учётные данные вручную, иногда ошибались, иногда вводили старый пароль после смены - техподдержка регулярно получала тикеты «не могу войти на портал».

Задача очевидная: настроить Kerberos SSO, чтобы браузер на доменной машине автоматически передавал тикет аутентификации и пользователь попадал на портал сразу, без ввода пароля.

Что нужно для работы Kerberos SSO

Kerberos в доменной среде работает через билеты (tickets), которые выдаёт KDC - контроллер домена. Когда пользователь логинится в Windows, он уже получает TGT (Ticket Granting Ticket). Браузер может использовать его, чтобы запросить билет для конкретного сервиса и передать его серверу. Сервер проверяет билет через AD - и всё, аутентификация произошла без пересылки пароля.

Для этого нужно три вещи:

• SPN (Service Principal Name) на учётной записи, под которой работает пул приложения IIS. Без SPN KDC не знает, для кого выдавать билет.
• Negotiate-аутентификация включена на IIS. Negotiate - это механизм, который предлагает сначала Kerberos, а при неудаче откатывается к NTLM.
• Браузер настроен доверять зоне интранета и передавать credentials автоматически. В IE это работает из коробки при правильных настройках зоны, Firefox - отдельная история.

Настройка на стороне сервера

Портал запускается под доменной учётной записью svc-portal (не NetworkService - это принципиально, у NetworkService SPN нет смысла регистрировать отдельно, там своя логика через имя компьютера). Регистрируем SPN:

setspn -A HTTP/portal.company.local svc-portal
setspn -A HTTP/portal svc-portal

Оба варианта нужны: один для полного FQDN, второй на случай обращения по короткому имени.

На IIS: Windows Authentication включаем, Forms Authentication выключаем. В настройках Windows Authentication - providers: Negotiate стоит первым, NTLM вторым. Negotiate первым - это важно, иначе будет сразу NTLM без попытки Kerberos.

Проверяем, что аутентификация реально Kerberos, а не NTLM, через klist на клиентской машине после первого входа - там должен появиться тикет для HTTP/portal.company.local.

Проблема с Firefox

IE и Chrome (который использует WinAPI) заработали сразу. Firefox - нет. Браузер честно предлагал форму с паролем, как будто Kerberos и не было.

Проблема известная: Firefox не доверяет Windows Negotiate по умолчанию. Нужно явно указать, каким серверам разрешено получать credentials. Это делается через about:config:

• network.negotiate-auth.trusted-uris - список доменов, которым Firefox передаёт Kerberos-тикет. Прописали portal.company.local.
• network.automatic-ntlm-auth.trusted-uris - то же для NTLM fallback.

Управлять этим через Group Policy напрямую нельзя - Firefox не читает GPO. Варианта два: либо раскатать нужный prefs.js через скрипт при логоне, либо использовать Firefox ADM-шаблон, который сторонние разработчики публикуют отдельно. Выбрали первый вариант - скрипт логона, который проверяет наличие настройки и дописывает если нет. Работает, но требует перезапуска Firefox если тот уже был открыт.

NTLM fallback и почему он важен

Kerberos требует, чтобы клиент и сервер были в одном домене или в доменах с доверием. Если пользователь заходит на портал с машины вне домена (например, с личного ноутбука через VPN), Kerberos не сработает. Именно для этого NTLM стоит вторым в списке провайдеров.

NTLM хуже Kerberos по безопасности - передаёт хеш пароля, уязвим к relay-атакам - но для внутренней сети это приемлемый компромисс для небольшого числа нестандартных клиентов. Полностью отключать NTLM не стали: часть подрядчиков работает с личных машин.

Важный момент: при Negotiate IIS сам выбирает Kerberos или NTLM в зависимости от того, что предложил браузер. Для администратора это удобно - не нужно вести два раздельных механизма.

Делегирование Kerberos - следующий шаг

После запуска SSO всплыл новый запрос: портал сам ходит в SQL Server от имени пользователя (не под сервисной учёткой). Для этого нужна Kerberos delegation - сервер должен иметь право «выступать от имени» аутентифицированного пользователя при запросах к бэкенду. Это constrained delegation, настраивается в свойствах учётной записи в AD.

Пока это отложено - требует тщательной проверки, что делегирование не даст лишних прав. Но сам механизм уже понятен.

Итог

Основной результат: сотрудники на доменных машинах заходят на портал без ввода пароля. Тикеты в техподдержку «не могу войти» прекратились - не считая пары случаев с Firefox, где пользователи не перезапустили браузер после изменения настроек.

Из сопровождения инфраструктуры вывод практический: Kerberos SSO - это не сложно, если понимать три ключевых компонента (SPN, Negotiate на IIS, настройки браузера). Большинство проблем при внедрении приходит именно от Firefox и от неправильно зарегистрированных SPN - setspn -L svc-portal покажет что зарегистрировано, это первое место для диагностики если что-то не работает.