Сброс к Kerberos при ведении переговоров: ошибки Kerberos для NTLM

Question

Я работаю с системой, которая реализует ограниченное делегирование для перехода на два хопа из Firefox 38.2.1 (или IE 11), доступ к веб-приложению .NET 4.5.1 в сети, запущенному на Windows Server 2012 (IIS 8.5) для SQL Server 2008 R2 на другом сервере. Сценарий делегирования функционирует: учетные данные пользователя AD передаются в базу данных на сервере отдельно от веб-сервера. DC - это Windows Server 2008 R2, и мы используем SPN.

Однако существуют такие сценарии, как отсутствие настройки конфигурации Firefox, где Kerberos завершится с ошибкой; и протокол проверки подлинности понижает до NTLM. Делегация больше не работает в течение определенного периода времени, пока не будет восстановлен протокол аутентификации Kerberos (некоторые источники говорят 5 минут, это больше похоже на 10-12 минут с нашим тестированием). Кроме того, неудавшееся делегирование влияет на всех пользователей, которые обращаются к приложению после понижения рейтинга протокола, вступает в силу до тех пор, пока Kerberos не будет автоматически восстановлен. Другими словами, их сеансы используют NTLM и блокируются от доступа к базе данных в течение 10-12 минут.

Есть ли способ с помощью кода (C#)/IIS/Firefox/IE или другого метода восстановить вручную протокол проверки подлинности на Kerberos, сократив тем самым окно, в котором используется протокол NTLM?

Answer 1

Я видел этот тип проблемы раньше. Я бы настоятельно советовал не пытаться решить это с помощью пользовательского кода, потому что тогда вам придется обнаруживать ошибки протокола и действовать соответственно и так далее. Такие усилия были бы нетривиальными. Вместо этого на самом деле было бы легче либо (1) разработать скриптовый метод для итерации всех машин, на которых установлен Firefox, и установить network.negotiate-auth.trusted-uris и network.negotiate-auth.delegation-uris, чтобы содержать имя вашего домена (см.: Configure Firefox to authenticate using SPNEGO and Kerberos) или (2) применять настройки Firefox (те, которые отображаются через about: config) через центральный сервер. Для № 2 см. Deploying Firefox in an enterprise environment. Мне нравится # 2 лучше, так как вы можете контролировать все пользовательские настройки Firefox таким образом.