Прошу прощения, если есть что-то действительно прямое. Я ошибаюсь в этом - мне очень трудно найти много информации о GSSAPI и JAAS.GSSAPI Дефектный билет
Я пишу программу, которая делает запрос на сервер IIS и выполняет аутентификацию с использованием Kerberos.
У меня две виртуальные машины: первый - это контроллер домена Active Directory. Другой другой - это сервер IIS.
С моей машины, я запускаю программу, которая использует GSSAPI и JAAS для аутентификации. Это довольно сильно основано на the Oracle tutorials for GSSAPI, так как на данном этапе я просто пытаюсь обнять его. Он регистрируется с использованием KrbLoginModule, чтобы создать объект, основанный на определенном тестовом пользователе из домена, который, как представляется, работает нормально. В сетевой трассе есть AS-REQ, AS-REP, TGS-REQ и TGS-REP (которые, если я прав, как и должно быть) между моей машиной и VM контроллера домена.
Моя программа затем использует тему, сгенерированную выше, для запуска некоторого кода GSSAPI, который в основном основан на code from the GSSAPI/JAAS tutorial. Он создает имена/учетные данные/контекст без каких-либо ошибок, но когда он пытается установить контекст, все начинает идти не так.
Первоначально я делал петлю контекста, как это делается в учебнике (связанный выше), но когда он попытался начать читать маркер с сервера (т.е. token = new byte[inStream.readInt()];) length Int он читал, было огромным (1213486160, немногие раз я проверяю это - казалось, что это было каждый раз). Это вызвало OutOfMemoryError.
Затем я начал использовать «поточную версию» initSecContext, которая принимает поток ввода и вывода (я дал потоки ввода/вывода сокета, который я открыл для своего сервера, - я предполагаю, что это то, что он хочет). Сначала это выглядит очень хорошо. Он устанавливает одну итерацию, но когда вы пытаетесь обернуть/развернуть сообщения, все снова начнет ошибаться. При попытке развернуть сообщение, он выдает ошибку:
org.ietf.jgss.GSSException, major code: 10, minor code: 0
major string: Defective token
minor string: Bad token tag: 7284
Трассировка сети для этого показывает сообщение TCP с той же длины, что и знак генерируется (я предполагаю, что это будет обернут двоеточие послал). Затем есть ICMP-переадресация. Я не уверен, что это ничего, но я подумал, что упомянул об этом (я заметил, что он содержит почти все первое сообщение TCP).
Затем есть ответ HTTP. Это 400 Bad Request. В теле ответа говорится, что это неверный глагол (я предполагаю, когда он говорит, что это слово имеет значение, как «GET» или «POST и т. Д.»). Трассировка также отмечает, что это подтверждение для первый TCP-сообщение. С небольшим количеством поисковых запросов я обнаружил a guy who had a similar problem. Оказалось, что речь шла о борьбе с антивирусами с заголовками отправленного запроса (возможно, это связано с перенаправлением?).
Тогда еще несколько TCP-сообщений (три в строке) с моей машины (они содержат данные, которые я отправляю в сообщении с помощью метода wrap), за которым следует сообщение с длиной = 0 TCP с сервера.
Итак, m не уверен, что это может быть (возможно, это перенаправление, но это не кажется вероятным).
UPDATE:
Я бегу это на другой VM (на том же домене Active Directory), но она по-прежнему получать HTTP 400 Bad Request ответ. В отличие от ранее, теперь определенно используется Kerberos (выше, он отправлял запросы NTLM).
Сетевая трассировка показывает запрос и ответы AS и TGS, а затем отправляется билет. Затем сервер IIS отбрасывает 400 Bad Request (опять же, неверный глагол). Существует незначительная разница: ответ «плохого запроса» больше не подтверждается отправкой маркера, хотя есть пустое сообщение TCP, которое появляется непосредственно перед 400.
Программа по-прежнему считает, что ее контекст установлен, но если вы пытаетесь обернуть сообщение, он порывает с:
General failure, unspecified at GSSAPI level
minor string: Error in method wrap, error: java.net.SocketException:
Unrecognized Windows Sockets error: 0: socket write error
UPDATE:
Как уже упоминалось ранее, когда я прочитал в маркере с initSecContext, я ожидаю длину первого (т.е. token = new byte[inStream.readInt()];) на основе учебника. Я получаю 1213486160, который вызвал OutOfMemoryError. Я понял, что 1213486160 - это 0x48545450, который в ASCII является «HTTP». Поэтому я прочитал следующую группу символов, а «ответный токен» - это HTTP 400 Bad Request.
Это заставляет меня задаться вопросом, должен ли я читать целое число для длины, как показано в учебнике. Я чувствую, что этот вопрос несколько иной, поэтому я сделал new question here. Это может быть и не проблема (например, не то, что заставляет его отправлять «Bad Request» в первую очередь), поэтому я оставлю этот вопрос открытым.
ДРУГОЙ UPDATE:
Так что я смотрел на маркер, который получает выплюнуть от initSecContext и закодированной в Base64, это YII ... (т.е. Обсуди маркер).
Я также рассмотрел сетевой трассу, когда я вхожу в систему через chrome и после сообщений AS и TGS, он отправляет HTTP-запрос GET с заголовком авторизации: Negotiate YII ..... , в отличие от моей программы, которая отправляет TCP-сообщение с длиной токена, а затем токен.
Это говорит о том, что мне не нужно делать шаг контекста установки (по крайней мере, как показано в учебнике) или что мне нужно захватить токен и отправить его в HTTP-запросе, а не прямое TCP-сообщение. Есть ли кто-нибудь (или какие-либо примеры людей - я, похоже, не могу найти что-либо действительно), которые использовали GSSAPI/Kerberos для аутентификации для IIS, которые могут это подтвердить?
Я был тем, кто только что голосовал за ваш вопрос. Отличная деталь. Теперь мой вопрос к вам: вы сказали, что у вас есть две виртуальные машины: первый из них - контроллер домена Active Directory, а другой - сервер IIS. Просто проверьте здесь - ваша клиентская машина также присоединилась к этому домену Active Directory? Это должно быть для проверки подлинности Kerberos. «Дефектный токен» обычно означает, что клиентская машина отправила токен аутентификации NTLM, в то время как серверу нужен Kerberos. –
Это не тот же домен, но в настоящее время он использует контроллер домена для своего DNS. Я не уверен, что это что-то значит, но когда я перехожу к «местоположению» сервера IIS в Chrome, он, похоже, использует Kerberos (все AS/TGS-REQ/REP и т. Д.). – dram
Теперь я просто дважды проверял Chrome, и он использует NTLM! Возможно, я недавно что-то изменил - я изо всех сил пытался заставить его работать, и попробовал кучу разных вариантов конфигурации, а потом избавился от кучки, когда я получил его на работу. Я бы сказал, это, наверное, так. – dram