libcurl обсудить fallback to ntlm

Question

Я бы хотел, чтобы 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 

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

Любые идеи?

Answer 1

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

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

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. 

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

Answer 2

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

ответ ниже,

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

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

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

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

Должен ли libcurl отказаться от NTLM?

Нет ...

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

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

В качестве такого Libcurl не нужно делать падение назад, само по себе, так как SPNEGO связи будет обрабатывать его для нас ;-)

Могу ли я сделать что-то еще не так?

Мы устранили ряд вопросов в 7.38.0, касающихся ведения переговоров с основными из которых являются:

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

s такие, я бы порекомендовал вам:

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

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