true_engineering Feb 27 2018 at 14:51

Анатомия .NET Core: как мы настроили NTLM под Linux

8 min

16K

True Engineering corporate blog .NET *Development for Linux *

Tutorial

+26

Comments 12

Veikedo Feb 27 2018 at 15:20

Не пробовали в CoreFx закомитить переключалку способа аутентификации?

true_engineering Feb 28 2018 at 14:27

Переключалка не выглядит правильным способом решения проблемы. Скорее всего, HttpClient в связке с CurlHandler должен при неудачном Negotiate-запросе пробовать следующий вариант. Скоро закинем вопрос на github.

zaq1xsw2cde3vfr4 Feb 28 2018 at 06:14

Запиливание сервисов Windows под Linux и наоборот — это как забивать шурупы молотком. При этом извращения в сфере IT считается нормой, а ситуация с шурупами почему-то всех возмущает.

lioncub Feb 28 2018 at 08:02

Может необходимость? Если бизнес потребует закручивать гвозди, то поверьте будут закручивать.

zaq1xsw2cde3vfr4 Feb 28 2018 at 20:12

Ситуация скорее выглядит так — IT специалист ответственный за принятие решения по выбору ПО принимает решение на основании закидонов своих внутренних тараканов, а не потребностей бизнеса. Результатом таких обоснований выбора оказывается, что цена слишком высока и бизнес не готов столько платить. И тут начинаются извращения типа контроллер домена на самбе и т.д.

lioncub Feb 28 2018 at 06:15

Почему NTLM, а не сразу безопасный Kerberos? У которого кстати поддержка Linux, Windows намного лучше.

true_engineering Feb 28 2018 at 14:28

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

kefirr Mar 1 2018 at 16:56

Только что прочитал, что libcurl выпиливают в .NET Core 2.1:
https://blogs.msdn.microsoft.com/dotnet/2018/02/27/announcing-net-core-2-1-preview-1/

Интересно, что как это обернётся для вас :)

true_engineering Mar 2 2018 at 08:40

Ваша новость одновременно и печалит, и радует ;)

dotnetdonik Mar 7 2018 at 09:51

Ну так приватный код на то и приватный, что б не через рефлексию его дёргать в продакшин коде.
Кстати, такой вопрос чем все- таки обусловлена использования Linux контейнера для интеграции с wcf, ntlm?

true_engineering Mar 7 2018 at 11:52

Поскольку Kubernetes для Windows — все еще сомнительная перспектива, мы нацелены на использование Linux.

Rast1234 Mar 7 2018 at 20:26

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

У нас в организации есть Dynamics CRM и к ней сгенерирован OData-клиент штатными средствами Visual Studio. В организации используются свои сертификаты.
Создаем контейнер из microsoft/aspnetcore, как в шаблонах Студии. Сначала нарвались на System.Net.Http.CurlException: Peer certificate cannot be authenticated with given CA certificates. Добавление сертов через update-ca-certificates не помогло, libcurl в образе почему-то упорно игнорирует системное хранилище.
Окей, есть переменные SSL_CERT_DIR и SSL_CERT_FILE, но приложение, вызывающее libcurl, должно само передавать их. Dotnet core научился это делать с версии 2.1, которая еще в preview.

Обновляем SDK до 2.1 preview1, VS до 15.6 preview 7, и не забываем в докерфайле обновить базовый образ: microsoft/aspnetcore:2.1.0-preview1, и добавляем в докерфайл переменные с путями к сертификатам.

После этого получаем System.Net.Http.CurlException: SSL peer certificate or SSH remote key was not OK. Оказывается, SSL_CERT_DIR почему-то ничего не дает, поэтому придется упаковать все сертификаты в один .pem файл и указать его в SSL_CERT_FILE (разработчик curl называет это "bundle", пример есть на его сайте). Это решает все проблемы с сертификатами.

А еще OData-клиент в .net core нормально работает c NTLM под линуксом, а под windows падает с DataServiceClientException: HTTP Error 401 - Unauthorized: Access is denied. Я завел баг, но ответа нет, и к сожалению OData-клиент не так хорошо поддается расширяемости, как WCF…
Пока решил обойтись тем, что под Windows (на машинах разработчиков, у кого не настроен докер) приложение будет запускаться на полном .net Framework, для этого есть multi target: в .csproj нужно написать <TargetFrameworks>net471;netcoreapp2.0</TargetFrameworks>. Но тогда разваливается билд, т.к. поддержка этой фичи еще фиговая и студия не знает, что делать с docker-проектом при сборке net471. Если выгрузить этот проект, то все собирается и работает нормально на полном фреймворке.