libcurl договаривается об отступлении к ntlm

Я бы хотел, чтобы libcurl откатился на NTLM, когда Kerberos недоступен.

Я использую эту настройку,

// explicit
curl_easy_setopt(_curl, CURLOPT_HTTPAUTH, CURLAUTH_NTLM | CURLAUTH_GSSNEGOTIATE);
// or any
curl_easy_setopt(_curl, CURLOPT_HTTPAUTH, CURLAUTH_ANY);

что на самом деле происходит, так это то, что сервер отправляет поддерживаемые схемы

<= recv header: HTTP/1.1 401 Unauthorized
<= recv header: Content-Length: 0
text: Server Microsoft-HTTPAPI/2.0 is not blacklisted
<= recv header: Server: Microsoft-HTTPAPI/2.0
<= recv header: WWW-Authenticate: Negotiate
<= recv header: WWW-Authenticate: NTLM

но клиент отправляет только токен согласования

text: Server auth using GSS-Negotiate with user ''
=> send header: POST /daas/services/hello HTTP/1.1
Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBgEEAYI3AgIKBgkqhkiC9xI...TC1NT0JMR0VS
User-Agent: libcurl-agent/1.0
Host: localhost:8008
Accept: */*
Content-Length: 328
Expect: 100-continue
Content-Type: multipart/form-data; boundary=------------------------19e8c490d70b39c1
....

Поскольку я еще не определил SPN, я ожидаю, что резервный NTLM будет работать, но я получаю это

<= recv header: HTTP/1.1 401 Unauthorized
<= recv header: Content-Length: 0
text: Server Microsoft-HTTPAPI/2.0 is not blacklisted
<= recv header: Server: Microsoft-HTTPAPI/2.0
text: Authentication problem. Ignoring this.
<= recv header: WWW-Authenticate: Negotiate oYIBHDCCAAAAPRwBFAFIAAgAEA.....BvAG0ABQAcAGMAb
<= recv header: Date: Fri, 26 Sep 2014 16:16:24 GMT
text: HTTP error before end of send, stop sending
<= recv header:
text: Closing connection 2

Я думал, что клиент должен отправить несколько возможных токенов и позволить серверу выбрать, на что ответить.

Есть идеи?

0

Решение

Нет; клиент должен отправить Лучший механизм, не предполагается отправлять все механизмы.

Эти механизмы не являются «запасными вариантами» в том смысле, что если один механизм выйдет из строя, он попробует второй, затем третий и т. Д. Это было бы ошибочной оптимизацией для случая, когда сервер объявляет, что он поддерживает согласование, но на самом деле это не так. , Это будет превращаться в нечто вроде:

Server: Hi, I suppose Negotiate, NTLM, Digest and Basic
Client: Okay, here's some Negotiate credentials
Server: Sorry! Either your credentials do not authenticate you, or whomever you authenticated as does not have authorization to view this page.
Client: Okay, well, what if I give you the same credentials, only in NTLM form
Server: What difference does that make?  You still can't come in.
Client: What about Digest?
Server: What do you mean, digest?  What makes you think that if I rejected your Negotiate and your NTLM credentials that suddenly your digest credentials will be any different?
Client: Well, here's the same credentials with Basic
Server: Okay, seriously, just go away.

Проще говоря, ваш сервер не настроен должным образом: если вы объявляете Negotiate, клиенты будут предоставлять учетные данные для переговоров с расчетом на их поддержку. Клиенты будут не вернуться к другим схемам в надежде, что они будут поддержаны.

0

Другие решения

Я на самом деле пошел и зарегистрировался в списке рассылки libcurl и получил ответ довольно быстро,

ответ ниже,

Я пытаюсь использовать libcurl для подключения к веб-серверу, который поддерживает
оба, но некоторые клиенты не могут делать Kerberos.

Когда вы говорите, что некоторые клиенты не могут делать Kerberos, что вы имеете в виду и какое ограничение у вас есть, которое не позволяет использовать его? Это ограничение означает, что libcurl не может или не должен использовать Kerberos?

Я устанавливаю CURLOPT_HTTPAUTH в CURLAUTH_GSSNEGOTIATE |
CURLAUTH_NTLM

а) Какую версию libcurl вы используете? Исходя из результатов, это выглядит как версия до 7.38.0 — если это так, вы можете игнорировать мои вопросы до этого, включая этот раздел, и перейти к моим комментариям по поводу обновления 😉
б) Какую платформу вы используете? Windows, Linux и т.д …
c) Если вы используете Windows, используете ли вы версию libcurl, скомпилированную для Windows SSPI, или версию, скомпилированную с библиотекой GSS-API (например, MIT Kerberos или Heimdal)?

Должен ли libcurl вернуться к NTLM?

Нет …

К сожалению, я не являюсь одним из наших экспертов по HTTP, поэтому я могу ошибаться, но я попытаюсь ответить на вопрос с моей шляпой аутентификации curl и некоторыми ограниченными знаниями HTTP 😉

Насколько я понимаю, механизм аутентификации Negotiate (SPNEGO) попытается выполнить Kerberos, а затем в случае сбоя Kerberos обратится к NTLM в рамках своего взаимодействия с сервером. Таким образом, вы увидите только заголовки «WWW-Authorization: Negotiate» и «WWW-Authenticate: Negotiate» от клиента и сервера соответственно, а не комбинацию предыдущих и «WWW-Authorization: NTLM» и «WWW-Authenticate: NTLM». ».

Так как такой libcurl не нужно делать отступление, как таковое, поскольку коммуникация SPNEGO справится с этим для нас 😉

Я делаю что-то еще не так?

В 7.38.0 мы исправили ряд проблем, связанных с ведением переговоров, основными из которых были:

  • Мы не использовали правильный SPNEGO OID при компиляции с библиотекой GSS-API
  • Откат к NTLM не был выполнен, если Kerberos потерпел неудачу
  • Устаревший CURLAUTH_GSSNEGOTIATE и введенный CURLAUTH_NEGOTIATE

Поэтому я бы порекомендовал вам:

  • Обновление до 7.38.0
  • Используйте CURLAUTH_NEGOTIATE вместо CURLAUTH_GSSNEGOTIATE | CURLAUTH_NTLM

будет проверять и обновлять …

0

По вопросам рекламы [email protected]