У нас есть немного сложная установка IDAM:
Т.е. компьютер и браузер конечного пользователя находятся в одной сети с родительским AD, а наше приложение на базе Jetty и AD, с которым оно может общаться (локальное AD), находятся в другой.
Между двумя AD существует двустороннее доверие. Браузер в родительской сети имеет локальный домен на доверенных сайтах.
Настройка сервера Jetty выглядит следующим образом:
- он использует файл keytab, сгенерированный против принципала в локальной AD
- он работает как служба Windows под пользователем, определенным в локальной AD
- область, отображение области-домена и kdc определяются для домена локальной AD
- он использует spnego - isInitiator имеет значение false; doNotPrompt верно; storeKey это правда
Проблема в:
- как тест, доступ к серверу из браузера внутри локальной сети (т.е. связанной с местным AD) работает - Kerberos отладочная информация появляется в журналах, я могу видеть правильное согласование Kerberos в HTTP - трафике, а пользователь подписывается автоматически , Brilliant.
однако доступ к серверу из браузера внутри родительской сети (именно так будут поступать наши пользователи) не работает! Браузер возвращает 401 unauth, но затем запрашивает учетные данные, которые при вводе дают пустой экран. Затем, нажав в адресной строке и нажав Enter, можно выполнить одно из двух действий, в зависимости от того, используются ли учетные данные для удаленной или локальной AD:
- Локальные учетные данные AD, затем войдите в систему, с Kerberos с нуля в журналах (GET-запрос, 401 unauth-ответ, запрос заголовков Kerberos и т. д.)
- учетные данные удаленных AD не войти (запрос GET, 401 несанкц ответ, что выглядит как заголовок NTLM:
Authorization: Negotiate <60 or so random chars>)
В любом случае, тот факт, что это подсказывает, неверен!
Есть ли объяснение этим симптомам? Может ли у нас установка сделать то, что мы хотим?
Что касается приведенного выше описания, это может быть неверно: любая конфигурация, которую я упомянул относительно сервера Jetty, должна быть точной, как я это сделал. Я рад предоставить более подробную информацию. Любая конфигурация, касающаяся либо AD, либо родительского сетевого браузера, потенциально подозрительна, потому что она не находится под моим контролем, и мне сообщили о конфигурации, а не видел ее для себя.
источник
Ответы:
Не видя захвата пакета, я бы предположил, что имя участника- службы HTTP / www.website.com необходимо зарегистрировать в учетной записи, на которой запущено приложение. У службы каталогов Microsoft есть отличная статья, посвященная этой теме, по следующему адресу:
https://blogs.technet.microsoft.com/askds/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1/
Запустите захват пакетов (netmon, wireshark) от клиента в каждой среде, чтобы определить, какое имя SPN ищется. Как только это будет определено, используйте команду setspn, чтобы зарегистрировать ее в учетной записи, на которой запущено приложение.
FWIW, Kerberos работает только в локальной сети. Если кому-то нужен доступ там, где контроллеры домена недоступны, вам следует рассмотреть возможность использования единого входа, такого как Shibboleth или ADFS.
РЕДАКТИРОВАТЬ: как упоминалось @ alex-h , браузеры должны быть настроены для автоматической аутентификации через Kerberos.
Наконец, это общая проблема с развертываниями Microsoft Sharepoint. Они хотят, чтобы единый вход через Kerberos происходил тихо, когда пользователи прошли аутентификацию в домене. Таким образом, если приведенные выше ответы не решают вашу проблему, попробуйте проверить их форумы, такие как следующие:
Kerberos в Chrome, Safari или FireFox
источник
Пожалуйста, попробуйте первый из браузера, в котором не включен NTLM (Chrome / Firefox). Кажется, проблема в том, что у вас включена предварительная аутентификация, и возможно, что двустороннее доверие может отсутствовать.
Для предварительной аутентификации посмотрите здесь https://support.microsoft.com/en-us/kb/2749007 и здесь https://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html ,
источник