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
Я думал, что клиент должен отправить несколько возможных токенов и позволить серверу выбрать, на что ответить.
Есть идеи?
Решение
Нет; клиент должен отправить Лучший механизм, не предполагается отправлять все механизмы.
Эти механизмы не являются «запасными вариантами» в том смысле, что если один механизм выйдет из строя, он попробует второй, затем третий и т. Д. Это было бы ошибочной оптимизацией для случая, когда сервер объявляет, что он поддерживает согласование, но на самом деле это не так. , Это будет превращаться в нечто вроде:
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, клиенты будут предоставлять учетные данные для переговоров с расчетом на их поддержку. Клиенты будут не вернуться к другим схемам в надежде, что они будут поддержаны.
Другие решения
Я на самом деле пошел и зарегистрировался в списке рассылки 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
будет проверять и обновлять …