Да все описание проблемы мутное какое-то.
Вот понятно, что браузер, т.е. клиентская часть какого-то веб-приложения, должна отправить определенный заголовок куда-то, но не отправляет.
При этом эта самая клиентская часть должна до того этот заголовок откуда-то получить.
Все эти операции выполняются по протоколу http.
И все ответы и запросы видны в консоли браузера.
И на джава скрипт, который сначала что-то от кого-то принимает, а потом отдает в другое место тоже можно посмотреть.

Сначала надо посмотреть на то, что было принято. Прежде чем шуметь о том, что оно почему-то не пересылается дальше.
Чем оно отличается от того, что нормально принимается и пересылается (по содержимому).

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

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

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

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

Ну что значит "инкапсулировано от моих глаз"? Вы говорите, что есть какой-то "сервлет, внутри которого вызывается getUserPrincipalName". Я, извините, не понимаю, на каком этапе цепочки он принимает запрос и извлекает оттуда UserPrincipalName.

Но я четко понимаю, что в браузере видны сгенерированные веб-страницы. И если запрос со страницы куда-то уходит и ответ откуда-то приходит, то можно в консоли браузера посмотреть на полученный откуда-то там ключ, когда он получен в браузере.
Это 100%. Я понимаю, что этот "хороший" ключ отличается от "плохого" ключа.

Если вы дебажить свое приложение не будете, то вы с места не сдвинетесь.

Blazkowicz, CORS тут пока ни при чем. У него тестовый стенд не меняется и в некоторых случаях авторизация проходит удачно.

В общем, уже понятно, что этот человек это приложение не разрабатывал, но пытается им пользоваться. Наверное, админ. Может, вернуть приложение разработчикам, указав на проблему, чтобы они его протестировали сами?

ivanrayelena,
придется обращаться к разработчикам браузера ))

Может быть, а может быть и нет. Сижу читаю, как это все настраивается. Только если бы в приведенном автором тему случае это вообще не работало, то не у него бы одного.