Мы реконфигурируем приложение SPNE GO / Kerberos SSO для использования AES128 / AES256 вместо шифров со слабым шифрованием DES и RC4.
В некоторые дни go я опубликовал подготовительный вопрос: Теперь у нас есть конкретная ошибка.
Токен, предоставленный функции, недействителен.
Компоненты:
Back-end Kerberos Windows Active Directory
Сервер приложений использует чистый Java GSSAPI и работает на Windows сервере.
Клиент работает на Windows 10 и записан в Java , Он имеет 2 реализации SPNE GO / SSO:
- pure Java GSSAPI
- native Windows SSPI через Waffle и JNA.
Мы можем переключить реализацию SSO клиента по конфигурации. Поскольку SSPI и GSSAPI совместимы, в любом случае сервер остается чистым Java GSSAPI.
Клиент и сервер используют протокол SPNE GO, но поддерживают только Kerberos, а не NTLM.
В «старой» настройке с использованием enctype RC4 клиент успешно прошел проверку подлинности и успешно проверяет токен SPNE GO в ответе от сервера, используя GSSAPI или SSPI.
Новый конфигурация:
Затем мы внесли изменения в конфигурацию клиента, сервера, SPN и т. д. c, удалив RC4 / DES и включив AES128.
После этого изменения:
1) klist показывает, что у клиента есть TGT AES128 для SPN сервера.
2) Использование GSSAPI: клиент успешно аутентифицирован сервером и успешно проверяет токен SPNE GO в ответе от сервера -> OK.
3) Использование SSPI: клиент успешно аутентифицирован сервером, но не может проверить токен SPNE GO в ответе se с сервера -> НЕ ОК.
Проблема:
Вместо этого мы получаем ошибку: «Токен, предоставленный функции, недействителен».
Чтение вафельного кода указывает на то, что эта ошибка, вероятно, происходит от Secure32.dll https://github.com/Waffle/waffle/blob/0c6f832222b59537847281adf7d2959583809dff/Source/WindowsAuthProvider/Secur32.cs
«Неверный» токен начинается с «oY…», обозначая KRB_AP_REP, и выглядит очень похоже на токены, созданные с помощью RC4, за исключением того, что он немного длиннее.
Поскольку токен можно проверить с помощью GSSAPI, я достаточно уверен, что он действителен. Вместо этого мы подозреваем, что проблема заключается в конфигурации Windows 10 Workstation или пользователя.
Поиск в поиске ошибки приводит к некоторым попаданиям, но ни один из них не имеет прямого отношения к SSPI / SPNE GO SSO. Я не хочу взламывать случайные настройки реестра без более ясного понимания того, что мы меняем. например,
TLS 1.2 - токен, предоставленный функции, недействителен
SQL Ошибка сервера после обновления: токен, предоставленный функции, недействителен
Есть идеи?
Примечание. Хотя в настоящее время работает чистый клиент GSSAPI, этот параметр будет d ie, если активирован Windows Credential Guard (таким образом, блокируется доступ к TGT). , Как только это произойдет, SSPI станет единственным жизнеспособным решением.
Обновление
Мы провели утро, используя Wireshark для анализа запросов и ответов, и обнаружили следующее:
Запрос от клиента, использующего GSSAPI
- negTokenInit / MechTypes -> содержит только 1 тип мех: для KRB5
Запрос от клиента с использованием SSPI
- negTokenInit / MechTypes -> содержит 4 типа мехов: для KRB5, MS KRB5, NEGOEX и NTLMSSP
Ответ от GSSAPI на запрос GSSAPI с использованием AES128 (токен ОК)
- Этот токен ответа имеет длину 32 символа и идентичен тому, который был получен в моей среде разработки Linux. например,
oRQwEqADCgEAoQsGCSgGSIb3EgECAg ==
Ответ от GSSAPI на запрос SSPI с использованием RC4 (токен ОК)
Wireshark -> TODO: учитывая, что токен намного длиннее, чем тот, который был сделан для запроса GSSAPI. Будет интересно посмотреть, что в нем содержится.
Длина этого токена ответа составляет 320 символов. например,
oYHrMIHooA… CZKm8y + Kx8sow ==
Ответ от GSSAPI на запрос SSPI с использованием AES128 (токен НЕ ОК)
Wireshark не показывает этот ответ с использованием фильтра Http - даже если клиент получает ответ в c. тело. Wireshark показывает только ответ в виде пакетов TCP / IP. Мы подозреваем, что Wireshark имеет ту же проблему, что и SSPI, при обработке его как токен SPNE GO.
Этот токен ответа имеет длину 328 символов, т.е. на 8 символов длиннее, чем эквивалентный выше RC4 , например,
oYHzMIHwoA… 4AE6jfTHu + U2qMMestyHKpH
Мы изначально подозревали, что этот токен мог быть искажен (например, обрезан) «в пути» , но может доказать, что токен был идентичен по длине перед добавлением сервером в заголовки ответа к полученному клиентом заголовку.
Токен берется непосредственно из GSSAPI, перед тем как кодируется в base64 и добавляется в заголовки ответа.
byte token[] = gssContext.acceptSecContext(gssapiData, offset, gssapiData.length);
Мы обновили сервер приложений с Oracle Java 8u45 до AdoptOpenJDK 11.0.6, но это ничего не изменило.