curl: как использовать Kerberos вместо аутентификации NTLM в Windows?

Я пытаюсь подключиться к службе Livy REST под защитой Kerberos. В Linux CentoS curl отлично работает с negotiate, после получения билета Kerberos kinit соединение через

curl --negotiate -u : http://service_link

Проблема, с которой я столкнулся, заключается в попытке сделать то же самое на удаленном рабочем столе Windows. Я использую MIT Kerberos для Windows, который успешно выполняет kinit. Однако curl, по-видимому, использует билеты NTLM SSL вместо Kerberos, что приводит к следующей ошибке:

AuthenticationFilter: Authentication exception: org.apache.hadoop.security.authentication.client.AuthenticationException

Я пробовал использовать официальную версию curl для Windows со следующими функциями (curl --version):

Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP HTTP2 HTTPS-proxy

и версия curl 0.8.0:

Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM SPNEGO SSL SSPI libz

Оба они используют NTLM SLL при согласовании.

Вопрос. Можно ли принудительно использовать Kerberos вместо NTLM? Можно ли отладить Negotiator, чтобы узнать, ищет ли (и где) он билеты Kerberos (и, возможно, не видит)?

Что касается Kerberos, похоже, он хранит таблицы ключей в своем API, поэтому я установил для переменной среды KRB5CCNAME значение API:Initial default ccache; klist видит билет, но может curl нужно уточнить?

Кроме того, есть ли альтернативные методы curl для такого соединения с защитой Kerberos?


rest curl hadoop kerberos livy
person runr    schedule 23.06.2017    source источник

Ответы (2)


arrow_upward
1
arrow_downward

http://service_link — глупый URL-адрес для Kerberos. Поскольку это имя с одной меткой, клиент будет искать билет службы только в своей области по умолчанию. Лучше всего использовать и полное доменное имя, чтобы можно было проанализировать хост и сопоставить доменную часть с областью.

Кроме того, в вашем сообщении нет упоминания SPN. Если curl может угадать правильный KDC для связи, вам необходимо зарегистрировать SPN HTTP/service_link в учетной записи, которая запускает аутентификацию на вашем веб-сервере.

Наконец, использовали ли вы Fiddler или что-то подобное, чтобы подтвердить, что ваш веб-сервер отправляет обратно заголовок WWW-Authenticate:negotiate? curl имеет настройки прокси.

Вы не можете принудительно использовать Kerberos, если все настройки неверны. ЕСЛИ они правы, curl попытается сделать это первым и добьется успеха. В зависимости от того, что не так, он может попробовать Curb, а затем вернуться к NTLM.

person markgamache    schedule 23.06.2017
comment
Спасибо за ваш ответ, сошел с рельсов из-за других проблем, поэтому проголосовал только за. - person runr; 14.07.2017
comment
Ссылка на сервис дурацкая, так как я туннелирую к ней через ssh, хотя смена в hosts не помогает. Не через Fiddler, а через --verbose в curl я вижу, что сервер отправляет обратно заголовок Negotiate. Поэтому я думаю, что проблема связана с правильной регистрацией SPN HTTP/service_link, поскольку я не знаком с ней и, вероятно, упускаю некоторые настройки. - person runr; 14.07.2017

arrow_upward
0
arrow_downward

Имя службы и связанное с ней имя участника-службы имеют решающее значение для понимания проверки подлинности Kerberos и могут быть довольно сложными. Чтобы понять проблему, вы должны понимать, что вызов, который возвращается с веб-сервера (или прокси-сервера), по сути, мне нравится Kerberos, ДАЙТЕ МНЕ БИЛЕТ ... Веб-сервер не предлагает никаких подсказок относительно того, какие билеты он будет подготовлен. принять, а также не говорит клиенту, как получить подходящий.

Таким образом, клиент должен определить имя службы (ожидаемое имя участника-службы), а затем ему нужна конфигурация Kerberos, которая сообщает ему, как получить подходящие билеты (если не из своего локального домена Kerberos).

Таким образом, для клиента, обращающегося к http://www.github.com/, SPN будет HTTP/www. github.com, но сначала клиенту нужно проверить это имя, чтобы увидеть, как оно разрешается. На самом деле это CNAME, который разрешается через github.com, тогда фактическим SPN будет HTTP/github.com, а затем клиенту необходимо проверить свою конфигурацию Kerberos, чтобы увидеть, находится ли имя в чужом домене Kerberos (что добавляет дополнительные сложности). Для локального домена kerberos клиент представляет krbtgt/ @ своей локальной службе выдачи билетов Kerberos, запрашивая билет для SPN HTTP/github.com @ ‹LOCAL_DOMAIN›.

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

Если веб-служба, к которой вы подключились, на самом деле является локальной подделкой github.com и принимает билеты из вашего локального домена, тогда это может сработать. Но для веб-сайта за пределами вашей локальной среды в игру вступят дополнительные сложности, связанные с иностранным доменом Kerberos, конфигурацией и доверительными отношениями.

Даже в вашей локальной среде клиент должен иметь возможность получить правильное имя участника-службы из имени, используемого для доступа к целевому ресурсу, а имя участника-службы должно быть зарегистрировано и связано с веб-службой (чтобы он мог расшифровывать билеты Kerberos, когда они представлены).

person Nick    schedule 12.02.2021