На работе поставили задачу - сделать в уже имеющемся java веб-приложении сквозную авторизацию с Windows учеткой (Active Directory).
Сейчас работает следующая связка tomcat 7.0.56+spnego_r7 (+nginx proxy) на linux (RHEL), jdk 8_20. Все неплохо работает, логин Windows получает servlet - request.getUserPrincipal(). Но все работает только для пользователей (AD) с несколькими группами (2-3 memberOf).

Для пользователей с большим количеством групп (memberOf) в браузерах (IE, Chrome, Firefox) вылазит ошибка “ERR::UNEXPECTED”: provisional headers are shown. Логи пусты, хоть я и выставил следующие параметры:

-Dsun.security.krb5.debug=true -Dsun.security.spnego.debug=all

И

<init-param>
<param-name>spnego.logger.level</param-name>
<param-value>1</param-value>
</init-param>

Но в логах все равно показываются только успешные попытки аутентификации. Ошибок нет.

Я повышал buffers, header в nginx и tomcat до 64k (так же ради эксперимента повышал до 1 мб, но потом вернул назад). Выставил MaxTokenSize в Windows реестре на необходимый максимум.
Пробовал так же различные связки версий JDK и tomcat. И все равно не работает, пробовал различные вариации

Может кто подскажет, что поправить, чтобы успешно аутентифицировались пользователи и с большим количеством привязанных групп?

Все стопорится на 7 пункте, а именно при импортировании полученного токена в браузер. В klist при заходе на сайт ключ появляется.

Но потом в браузере красуется следующее «Provisional headers are shown» - обычно такое сообщение выходит, когда какое-то расширение браузера блокирует запросы/контент.
Но данный скриншот сделан в режиме инкогнито, где все расширения заблокированы, тем более это происходит во всех браузерах.
https://drive.google.com/file/d/0Bxqnx1qVPbX6dGtoS0M0RjltUHM/view

При логировании nginx так же видно, что пользователь отправляет пустые хедеры (в случае если пользователь состоит в большом количестве групп). Т.е. нужный header Authorization даже не доходит до nginx, tomcat.

При успешной аутентификации получается так:
https://drive.google.com/file/d/0Bxqnx1qVPbX6c0xnZmxWcHlWeGM/view

Есть у кого какие мысли, почему браузер не может получить ключ, хотя он уже получет от AD?

ivanra, выставил -Dhttp.nonProxyHosts="*.rt.ru" - не помогло.
Вообще сервер приложений, nginx и kdc находятся во внутренней сети, так что они изначально без прокси общаются.

Мне непонятно, почему браузер не помещает в request header ключ, хотя пользователь его получает при заходе на сайт (видно в klist). Может на сервере AD есть какие-то волшебные настройки? Админы же говорят, что ничего не знают.

Меня если честно напрягает данная задача, т.к. затуп в ней не в программистской, а в админской части. Но надо как-то решать...

ivanra, да, обход прокси настроен.

ivanra, да, из фото же видно, что сам браузер почему-то не отправляет хедер в случае, если пользователю прикреплено много групп (от 10). И я не знаю, как браузер получает хеш из kerberos ключа, все это инкапсулировано. В итоге на сервере поэтому и нет ошибочных логов, т.к. он попросту не видит, что ему что-то приходит.

yelena, все что вы описали - инкапсулировано от моих глаз, и почти никак не зависит от моих действий. js в явном виде (именно на этой странице) нет. Код страницы - обычный сервлет, внутри которого вызывается getUserPrincipalName (метод тоже "из коробки"). Остальное все делается с помощью spnego и самого AD, ну и встроенных в Windows клиента процессов по синхронизации работы браузеров и kerberos/AD. Если рассматривать случай, когда аутентификация не проходит, то (как видно по фото) никаких особо полезных логов в Networke браузера нет, пробовал в различных браузерах.

Настройка spnego: krb5.conf, login.conf, web.xml - стандартная. И как я уже упоминал, с количеством групп не более 3 - пускает.

Большие хедеры к nginx/tomcat проходят, проверял вручную.

ivanra, вот именно, что он ничего не отправляет, пишет только "provisional headers are shown". Показывал я это уже админам. Молчат, не хотят разбираться. Точнее говорят, что это я "чего то наколбасил" такого, что не работает. Но сервлет по этому url'у очень прост.
Видимо ждут, когда сроки начнут гореть, а начальство из Москвы начнет негодовать :-)

Я понимаю, если бы совсем ничего не работало. Но работает же прекрасно с некоторыми пользователями.

yelena, я разработчик приложения (но не браузера, и не клиента SPNEGO и не протокола Kerberos) и подробно расписал весь процесс. Я бы сам рад подебажить, но оно не дебажится и все тут. Дебажить я умею, и есть опыт дебага js, java, pl/sql.

Консоль и Network грубо говоря пустые. Дебажил в Chrome и IE. На следующей неделе доберусь до Firefox, просто все это надо настраивать на машине (учетке) тех, у кого не работает авторизация. Под своей же учеткой мне напряжно просить каждый раз админа добавлять/удалять группы, т.к. сам процесс успешной LDAP аутентификации мне нужен, т.к. допиливаю другие части по интеграции.

Описываю алгоритм еще раз и прикладываю логи nginx'a со специальным логированием хедеров:

Вначале успешный случай (малое число групп):
1) Отправляем запрос на /ldapAuthentication, получаем 401 и response header: WWW-Authenticate: Negotiation, что дает клиенту знак, что надо пообщаться с AD взять ключ и прислать хеш.
2) Получив ключ от AD отправляется еще один запрос /ldapAuthentication с request header’ом: Authorization (внутри которого хеш ключа), получаем статус 200.

Вот как выглядит nginx лог для пользователя с малым числом групп.
10.6*.**.*** - - [10/Jul/2015:09:34:40 +0500] "GET /ldapAuthentication HTTP/1.1" 401 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.132 Safari/537.36" "-" "-" "Negotiate"
10.61.35.212 - - [10/Jul/2015:09:34:40 +0500] "GET /ldapAuthentication HTTP/1.1" 200 59 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.132 Safari/537.36" "-" "Negotiate YIIJWQYGKwYBBQUCoIIJTTCCCUmgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCCRMEggkPYIIJCwYJKoZIhvcSAQICAQBuggj6MIII9qADAgEFoQMCAQ6iBwMFACAAAACjggd/YYIHezCCB3egAwIBBaEKGwhVUi5SVC5SVaIkMCKgAwIBAqEbMBkbBEhUVFAbEWRldi1ib2Vpc3NkLnJ0LnJ1o4IHPDCCBzigAwIBF6EDAgEDooIHKgSCByYrszBq0JBaM3n9f1PNw9NupMHKYpDfGCJzNYltK5nYi7c9K5FzuW3/Srk/j5OQ2/Udau5/jmy0Rhr4e464iRmakNqw3O9A7qG5o6tiHXk9njyEf4ND9pYq/molZSsJpFe7Y13+G/+6M2wc3RUIty5cOMNJKGvFj3VtjgdG0r75ecBTWNNZBSjzkZFpo5/QNqS9Zsbe2RrtXSR9pssY9f5Ass5LKiH0YoTI+FJvcLoLpIGTJP65URSPnNqkqDNNWxE2Y5XGSHJS0nGUWBova0+d58iM8TuQq1AHEejF6NXsbKeI0xVIn5VNjRkj3GY4cz/gblhpnUt7X300dQHvKBj3g2z35Y34lV5f1g+12xnBFVxcwgJguhbc68CBjGHb1eGV5/KQZcFp2aYXEG24oB180d4NfnkXm3ZZp+kUAmmOBsl/sTkxBylk3kcFvLok9kuVtuNNJBwHGl5R5va5hTWDKqj4ObCwSAq/uJZNy6iCaabe+pxO0e7HQUwxE/EDSykyDdITDo/vLcEiaMArf/9JlQbalCnZQLxnwWw7CiDQYe4wuVhgO8US7NzolE0+zW2iPWL/6m8Fq7TS3pGVMQQBkdZ3gSPOeNaolgi0IY7nrV9R2Zcp15RXzK7MOB7dlyEyfrge7PJnZZPP+HaG2f13P3l3osjAsgU9gvX/LTJ7AygB2RA13bbH24jehnqdPWVVB+zjXXb1FJ94Xa36uFl/k8qBwSa8GqdDwAEYH9i4A0bKDoTbtHnKqwZNROAiSeCdg3cbM+3PCyKT8VIF91xFk/aAf2w2bBbz8M8Taa+VGRMChXDr27az8ouSJlAtwitJmWAJIsxIlHhQsycAbJBMUnI3IdDW9x1TLn2Ws3x+JJVRq+U8PL5aQ18s71q2xkY1aDjdJL8yPCZ8DE2AX4cnxVoSbAFTx7nV5aOoUFZfqIx4B8RrYNrS0y+HYC2Qlvcz7WUE/EztzCpwfjfCMi3jks7jTu+3vh9sfQvKE6IeF4fslLz8UM3pa9mUIE05h65wFmw18f9C2/go5bUdmkggFcMIIBWKADAgEXooIBTwSCAUvgvr7/hrKIRoJzNHj51WdLQU9nrPJ19oct2a+JKtIzr21ki35jXF+H5YEArhBCBDNSlOb5s5f7TGOzIq78OAB9O4GsL5z9XGrneZZjhK0/R5S+ULjcxcOYyYSLOnnBQhYK19ObGqJNVIwRUJ3sjuf9Le5ad6sA6HEeCTtGKrqgm3+/2f7PlDBW4PFX7obPwIA8LDxUPrSkXb5e7VuiMql+xnzDYgcW/HHOvDlO+V/qSzzWx1IimUuldiiEngfTbSbF1LYB6fM3pjzCPui/0581id5aUkE/WeMxQDWrw9Lr0v9MU2IV3r7hvzrhHJz3r5jD87zJ8n4HVdrUSA7SBuDKU8dFrznneDvVOMvtyjcQf1GrbDB4z+PzYekXjkXW+vC0zbA0HbhcLQticJZZG9BFXF3o03gMqqukR5p/SSxqa22rDzWm+GoOLmSt" "Negotiate oYHrMIHooAMKAQChCwYJKoZIhvcSAQIComkEZ2BlBgkqhkiG9WMFSgAwIBBaEDAgEPokgwRqADAgEXoj8EPfBByib2vY9GjX/r4+r5ovCHSYONPN6gV9XpS+9s0PHFlknbFDf+QhLZfAb1YwVKADAgEFoQMCAQ+iSDBGoAMCAReiPwQ98EHKJva9j0aNf+vj6vmi8IdJg4083qBX1elL72zQ8cWWSdsUN/5CEtl+ko3GN7+xepfdVGDXpGjrv8lIdg=="

Т.е. вначале сервер нас посылает за ключом, потом мы его отправляем и все норм.
Теперь рассмотрим лог неудачного запроса (с большим количеством групп):

10.6*.**.*** - - [10/Jul/2015:09:37:17 +0500] "GET /ldapAuthentication HTTP/1.1" 401 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.132 Safari/537.36" "-" "-" "Negotiate"
10.6*.**.*** - - [10/Jul/2015:09:37:17 +0500] "GET /ldapAuthentication HTTP/1.1" 401 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.132 Safari/537.36" "-" "-" "Negotiate"

Видно, что сервер вначале отправляет получать ключ от AD, но потом браузер присылает запрос без хеша ключа, и отказ. Почему браузер во втором запросе не отправляет ключ - загадка, т.к. этот ключ уже есть в списке полученных ключей klist.
Код моего приложения тут не при чем, т.к. все по сути работает "из коробки". Весь вопрос сводится к тому, что может где-то что то подкрутить в конфиге spnego/krb5.conf/login.conf, и главное, может что-то надо изменить в AD.

Petro123AlexeyKh24,
Сервлет вызывается по AJAX или как? В какой момент?

В данном конкретном случае при тестировании вызывается GET запросом, просто захожу по конкретному url в браузере. В приложении используется как GET запрос по AJAX, тоже нормально работает (для пользователей с небольшим количеством групп).

ivanraAlexeyKh24,

так может, у этих пользователей сервер приложений просто не включён в список доверенных узлов?

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

Blazkowicz У вас один домен используется как при аутентификации, так и в сервисах? CORS не настроен?

Домен один

BlazkowiczAlexeyKh24,

Не пробовали удалять группы по одной из групп пользователя? Может всё же дело в настройках одной какой-то группы, а не в количестве?

Если честно, то до такого экзотичного тестирования еще не доходили, но возможно скоро от безысходности придется попробовать. Вообще в SPNEGO у нас не настроена какая либо политика по группам, т.е. вход доступен всем, лишь бы ты был в домене.
А так были следующие тест-кейсы:
Мне добавили 40 доп тестовых групп - аутентификация перестала работать.
Создали учетку, копию блокируемой - не работает. Сократили количество до двух групп - работает.
Создали пустую учетку без групп - работает.

BlazkowiczAlexeyKh24Мне добавили 40 доп тестовых групп - аутентификация перестала работать.

Тут пишут что нужно 120 групп.
https://support.microsoft.com/en-us/kb/327825
А ещё пишут что MaxTokenSize надо править на всех компьютерах, вовлеченных в процесс. То есть контроллер домена тоже.

MaxTokenSize настроен.
И да, странно, предупреждение не выдает про Header too long.

ivanraв spnego протоколе группы точно не принимают участие. Это только аутентификация.
Другое дело, если группы у таких пользователей сильно ограниченные, например, для этих групп не настроены доверенные сервера (или, по крайней мере, сервер приложений не является доверенным). А браузер передает токен только доверенным серверам. В этом случае результат будет именно таким, как на 1-й картинке

Это уже поинтереснее предположение. Не очень разбираюсь в настройке групп в AD, в понедельник видимо будем мучать админа.
Но если им нет явного доступа к этому ресурсу, или он недоверенный - то почему в klist появляется ключ для конкретного пользователя и конкретного сайта?

С другой стороны, группы опять же влияют на размер хеша.
TokenSize = 1200 + 40d + 8s

yelena, да, спасибо за направление.

Попробую на след неделе chrome://net-internals/#events, Wireshark/TCPMon, ну и параметр реестра LogLevel.

В общем все волшебным образом заработало, когда сменили kdc ur.rt.ru на ks.rt.ru. Так что возможно проблема была именно в самом kdc Уральском. Так что моя совесть чиста :-)