Задний план:
У нас есть проблема с одной сетью AD, которая проявляется только в IE или Chrome, когда компьютер, используемый для доступа к нашему веб-серверу, привязан к рассматриваемому AD. Маркер не передается, и в журналах сервера нет записей, связанных с согласованием маркера. Если мы используем Firefox и включаем параметры network.negotiate-auth, тогда пользователь может войти в систему без проблем, однако при использовании IE он получает сообщение об ошибке авторизации. Веб-сайт находится в зоне интрасети, и IWA проверяется (это контролируется GPO)
Если пользователи попытаются получить доступ к сайту с помощью IE или Chrome из-за пределов своего AD, они получат ожидаемое приглашение входа в систему аутентификации, а затем токен будет отправлен правильно.
Я разговаривал с администраторами сети, и они уверены, что для AD не требуется специальной конфигурации для обеспечения работы аутентификации Kerberos, но я не могу понять, почему аутентификация работает для шести других сетей AD и не работает в этой 1, если это не до Сама конфигурация AD.
Я что-то упускаю? Чем можно объяснить отказ от переговоров по токену?
[Примечание - это не срочно, и, поскольку я выхожу из офиса, отвечу на любые запросы для получения более подробной информации в понедельник]
Проблема заключалась в том, что токен отправлялся и автоматически предпринималась попытка согласования внутри сети AD, но это всегда приводило к сбою из-за шифрования, используемого при создании keytab.
Первоначально мы использовали -crypto DES-CBC-CRC но как только мы перешли на использование -crypto RC4-HMAC-NT проблема ушла.
Не эксперт в этом, но я склонен думать, что, если токены переговоров не обмениваются, проблема может заключаться в том, что приложение не имеет зарегистрированного SPN с именем пользователя, связанным с keytab.
Если это так, следующая команда, запущенная на сервере AD, может исправить это:
setspn –a HTTP / (yourhostname) (keytabusername)
например setspn -a HTTP / intranetappsrv.mycompany.com jbossaccount