Возможна ли эта настройка Kerberos / AD?
У нас есть немного сложная настройка IDAM:
Т.е. компьютер и браузер конечного пользователя находятся в одной сети с родительским AD, а наше приложение на основе Jetty и AD, с которым он может взаимодействовать (локальный AD), находятся в другой.
Между двумя AD существует двустороннее доверие. Браузер в родительской сети имеет локальный домен на надежных сайтах.
Настройка сервера Jetty выглядит следующим образом:
- он использует файл keytab, созданный для принципала в локальной AD
- он работает как служба Windows под пользователем, определенным в локальном AD
- область, отображение домена и области и kdc определены в отношении домена локальной AD
- он использует spnego - isInitiator имеет значение false; doNotPrompt верно; storeKey верно
Проблема в:
- в качестве теста доступ к серверу из браузера внутри локальной сети (т.е. связанный с локальной AD) работает - Информация об отладке Kerberos отображается в журналах, я вижу правильное согласование Kerberos в HTTP-трафике, и пользователь входит в систему автоматически. Блестяще.
тем не мение, доступ к серверу из браузера в родительской сети (именно так и будут делать наши пользователи) не работает! Браузер возвращает ошибку 401, но затем запрашивает учетные данные, которые при вводе дают пустой экран. Затем щелчок по адресной строке и нажатие Enter выполняет одно из двух, в зависимости от того, предназначены ли учетные данные для удаленного или локального AD:
- локальные учетные данные AD, затем войдите в систему нормально, с Kerberos с нуля в журналах (запрос GET, ответ 401 unauth, запрос заголовков Kerberos и т. д.)
- удаленные учетные данные AD не входят в систему (запрос GET, ответ 401 unauth, что выглядит как заголовок NTLM:
Authorization: Negotiate <60 or so random chars>)
В любом случае, подсказка неверна!
Есть ли объяснение этим симптомам? Может ли наша установка делать то, что мы хотим?
Что касается приведенного выше описания, то оно может быть неверным: любая конфигурация, которую я упомянул относительно сервера Jetty, должна быть точной, как и я. Я рад предоставить более подробную информацию. Любая конфигурация, относящаяся к AD или к родительскому сетевому браузеру, является потенциально подозрительной, потому что она не находится под моим контролем, и мне сообщили о конфигурации, а не лично.
Не видя захвата пакета, я бы предположил, что HTTP / www.website.com SPN необходимо зарегистрировать в учетной записи, в которой запущено приложение. Команда Microsoft Directory Services опубликовала отличный пост, состоящий из нескольких частей, посвященный этой теме по следующему URL-адресу.
Запустите захват пакетов (netmon, wirehark) от клиента в каждой среде, чтобы определить, какое имя участника-службы ищется. Как только это будет определено, используйте setspn cmd, чтобы зарегистрировать его в учетной записи, в которой запущено приложение.
FWIW, Kerberos работает только в локальной сети. Если кому-то нужен доступ там, где контроллеры домена недоступны, вам следует рассмотреть возможность использования единого входа, например Shibboleth или ADFS.
РЕДАКТИРОВАТЬ: как упоминалось @ Alex-H, браузеры должны быть настроены на автоматическую аутентификацию через Kerberos.
- Internet Explorer - хотя статья TechNet не предназначена специально для вашего приложения, шаги те же.
- Fire Fox - то же, что и ссылка IE, не точное совпадение, но шаги такие же.
Наконец, это обычная проблема при развертывании Microsoft Sharepoint. Они хотят, чтобы единый вход через Kerberos происходил незаметно после аутентификации пользователей в домене. Таким образом, если приведенные выше ответы не решают вашу проблему, попробуйте проверить их форумы, например:
Попробуйте 1-й вариант из браузера, в котором не включен NTLM (Chrome / Firefox). Похоже, проблема в том, что у вас включена предварительная аутентификация, и возможно, что двустороннее доверие может отсутствовать.
Для предварительной аутентификации смотрите здесь https://support.microsoft.com/en-us/kb/2749007 и тут https://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html.