[samba] Fwd: libwbclient от samba и sssd

Evgeny Sinelnikov sin на altlinux.ru
Ср Ноя 30 18:44:34 MSK 2016 

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

30 ноября 2016 г., 0:04 пользователь Alexander Bokovoy <ab на samba.org> написал:
> On ti, 29 marras 2016, Evgeny Sinelnikov wrote:
>> 29 ноября 2016 г., 17:03 пользователь Alexander Bokovoy <ab на samba.org> написал:
>> > On ti, 29 marras 2016, Evgeny Sinelnikov wrote:
>> >> 29 ноября 2016 г., 14:34 пользователь Michael Shigorin
>> >> <mike на altlinux.org> написал:
>> >> > On Tue, Nov 29, 2016 at 02:05:45PM +0300, Evgeny Sinelnikov wrote:
>> >> >> Таким образом имеет смысл разобраться с зависимостями и решить
>> >> >> - стоит ли вообще использовать альтернативы, если у нас имеются
>> >> >> пакеты, которые зависят от функционала, реализованного только в
>> >> >> заданной версии libwbclient?
>> >> >
>> >> > Для библиотек с различным ABI это заведомая диверсия.
>> >>
[...]
>> >
>> > Основная проблема в том, что пакетные зависимости не дают возможность
>> > корректно выразить все эти конфигурации.
>>
>> Да, спасибо, Александр. Я уже открыл два git репозитория:
>> - у нас:
>> http://git.altlinux.org/gears/s/sssd.git
>> http://git.altlinux.org/gears/g/gssntlmssp.git
>> - и в апстриме:
>> https://git.fedorahosted.org/git/sssd.git
>> https://git.fedorahosted.org/git/gss-ntlmssp.git
>>
>> Посмотрел код и всё понял. Возможно, это просто. Но мне это не кажется
>> очевидным. Поэтому я переформулирую, а вы поправьте, если я ошибся.
>>
>> Вариант использования (aka "use case") для libwbclient-sssd следующий:
>> - мы хотим уйти от старого хлама (вроде NTLM) и оставить чистый Kerberos;
>> - мы установили на клиенте аутентификацию и авторизацию через sssd;
>> - но, кроме PAM и NSS, у нас есть на клиенте Samba:
>>  + как клиент, если мы обращаемся за шарами, например;
>>  + как сервер, если сами что-то шарим;
>> - и вот сборках, этой самой Samba, этот хлам (от которого мы хотели
>> избавиться) имеется в клиентской стороне в недрах библиотеки
>> libwbclient;
>> - и мы, волевым решением, пытаемся от неё избавиться...
>>
>> И тут выясняется, что:
>>
>> $ ldd /usr/lib64/libsmbclient.so.0 | grep libwbclient
>>         libwbclient.so.0 => /usr/lib64/libwbclient.so.0 (0x00007f77c4963000)
>> $ rpm -qf /usr/lib64/libsmbclient.so.0
>> libsmbclient-4.5.1-alt1
>> $ apt-cache whatdepends libsmbclient | grep -v libsmbclient
>>   samba-libs-4.5.1-alt1
[...]
>>
>> И, по умолчанию, если libwbclient-sssd установлена, у нас работает именно она.
>>
>> Таким образом, мы получаем не диверсию, а планомерное выпиливание
>> нежелательного функционала. Потенциально уязвимого и небезопасного
>> наследия, которое тянется со времён NT4. То есть для совместимости с
>> доменами до Windows 2000 и... внимание, с доменами на базе Samba3.
>
> Женя, ты смотришь в правильное место, но делаешь совершенно неверные
> выводы. Особенно на предмет "планомерного выпиливания".
>
> Пойми простую вещь: winbindd сочетает в себе функционал трех больших
> областей. В идеале они все должны быть разделены на три разных демона:
>  - преобразование identity (SID to name / IDs, name to IDs, IDs to name,
>    IDs to SID, name to SID) для групп и пользователей
>
>  - проксирование аутентификации контроллеру домена по запросу
>    пользовательского приложения
>
>  - обработка топологии доверительных отношений между доменами и лесами
>
> По крайней мере две из трех этих задач требуют в определенных
> конфигурациях работу в кластерном режиме.
>
> К этому нужно добавить, что и другие компоненты Samba содержат тот же
> код, который присутствует в winbindd, в частности, касательно
> аутентификации. Это традиционно smbd и libsmbclient. У первого есть
> режим fallback, когда winbindd не запущен или возвращает ошибку. Второй
> и не рассчитан на работу с winbindd.
>
> Проблема в том, что winbindd рос исторически и архитектурно представляет
> собой отнюдь не стройную систему, которую можно разделить на отдельные
> компоненты, взаимодействующие между собой посредством четко определенных
> интерфейсов. Над таким разделением мы работаем и пытаемся договориться
> (Samba Team, SUSE, Red Hat, Sernet, ...) уже больше пяти лет. Воз и ныне
> там, потому что для всех участников такое разделение пусть и важно, но
> не так приоритетно, как другие приоритетные задачи. Из последних --
> Microsoft выпустила обновление принтерной подсистемы в конце лета с
> целью закрыть часть известных ошибок безопасности и всё, не только
> принт-сервера на Самбе перестали работать после обновления Windows, но и
> некоторые крупные внедрения Windows у некоторых крупных заказчиков
> Microsoft перестали работать.
>
> Печатью в Samba занимаются ровно 10% от двух человек. Эти два человека
> теперь вынуждены ближайшие несколько месяцев с нуля писать поддержку
> новой версии системы печати. Это значит, что задачи, над которыми они
> могли бы работать всё это время, простаивают -- многопоточность в SMB
> 3.1, Samba AD с MIT Kerberos, рефакторинг winbindd и так далее, там
> много чего по списку.
>
> Приложения, который используют libsmbclient, могут работать через
> Kerberos, поэтому там особой проблемы в корпоративной среде пока нет.
> libsmbclient и вовсе не требует wbclient для своих задач, так что
> для ситуаций, когда эти же приложения на этой же машине должны
> использовать NTLMSSP для доступа к удаленному ресурсу, проблемы нет.
>
> Проблема возникает там, где локальное серверное приложение хочет
> проверить аутентификацию пришедшего к нему по сети клиентского
> приложения. В этом случае член домена должен делать проксирование
> аутентификации контролеру домена с использованием защищенного канала
> между членом домена и контроллером домена. Этот канал называется secure
> channel и обладает неприятным свойством эксклюзивности -- между членом
> домена и контроллером домена в один момент времени может быть установлен
> только один secure channel.
>
> Именно реализацией консолидированного доступа к secure channel
> занимается winbindd. Как только удастся выделить эту подсистему в
> отдельного демона, libwbclient-sssd сразу научится поддерживать
> аутентификацию.
>
> Речь не идет о "выпиливании" старых технологий. Их выпиливает Microsoft,
> которая очень хочет избавиться от NTLMSSP и всего предыдущего, но не
> может. Речь идет о том, есть области применения, где NTLMSSP не
> появляется от слова совсем и по факту эксплуатации во многих
> организациях эти области занимают 90% в области Idenity Management и
> примерно 20% в области storage. Вот такая странная раскладка -- Red Hat
> Storage не может перейти на использование SSSD в том числе и из-за этой
> ситуации, а в случае Red Hat Identity Management за пять лет, что я
> работают над FreeIPA, количество заказчиков, где NTLMSSP нужен кровь из
> носа, не настолько велико, чтобы эта задача мешала унификации на основе
> SSSD.
>
> Тем не менее, работа запланирована и ведется. К сожалению, реальность
> гораздо печальнее, чем планы.
>

Кроме страданий и боли, меня теперь настигла ещё и печаль...

Честно говоря, я пока не вполне понимаю - есть ли у нас хоть какое-то
"количество заказчиков, где NTLMSSP нужен кровь из носа?" Наверное
есть, но нужны конкретные варианты использования.

Я бы предпочёл ограничить объём поддерживаемых конфигураций до 100%
работающих, вместо бесконечного количества конфигураций потенциально
не работающих. Не исключая возможности преобразовать первое во второе,
путём установки дополнительных пакетов.

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

Так вот, если грубо, я вижу следующие конфигурации, которые мы сейчас
предлагаем и пробуем (для security = ads):
- NSS(WINBIND), PAM(WINBIND), AD клиент (Сетевой логин + Доступ к
шарам), -libwbclient-sssd, +libwbclient (и winbindd)
- NSS(WINBIND), PAM(WINBIND), Samba сервер (Файловый сервер в
инфраструктуре AD), -libwbclient-sssd, +libwbclient (и winbindd)
- NSS(WINBIND), PAM(WINBIND), SambaDC сервер (Контроллер домена AD),
-libwbclient-sssd, +libwbclient (и winbindd)

При этом, основные проблемы возникают на клиентах с winbind'ом. А не
явное вытягивание libwbclient-sssd, ещё и как более приоритетной
альтернативы, ломает нам всё.

Дополнительно, лично я, использую ещё такую конфигурацию (для security = user):
- NSS(FILES), PAM(KRB5), Samba сервер (Файловый сервер в
инфраструктуре KRB5KDC) + SSH сервер (Удалённый доступ,
GSSAPIAuthentication yes), -libwbclient-sssd, +libwbclient (без
winbind)
- NSS(FILES), PAM(KRB5), SSH, CIFS и libsmbclient клиент (Клиент в
инфраструктуре KRB5KDC) + SSH сервер (Удалённый доступ,
GSSAPIAuthentication yes), -libwbclient-sssd, +libwbclient (без
winbind), +automount via cifs.upcall.
И хочу получить такую же, но с NSS(SSSD).


При этом, нам нужно добиться следующего:
 --- Уйти от неявной подмены libwbclient библиотекой libwbclient-sssd.
Либо путём гарантии, что она просто так не приедет по зависимости,
либо путём повышения приоритета альтернативы для libwbclient;
 --- Получить возможность установки и настройки дополнительных конфигураций:
- NSS(SSSD), PAM(SSSD), AD клиент (Сетевой логин + Доступ к шарам),
+libwbclient-sssd, -libwbclient (без winbindd)
- NSS(SSSD), PAM(SSSD), Samba сервер (Файловый сервер в инфраструктуре
AD), -libwbclient-sssd, +libwbclient (и winbindd)
- NSS(SSSD), PAM(SSSD), SambaDC сервер (Контроллер домена AD),
-libwbclient-sssd, +libwbclient (и winbindd)


Итого, мы получаем, что у нас бывают в AD следующие виды узлов с SSSD:
- "обычные клиенты" - без сервисов. На них можно сразу включать
PAM(SSSD) и NSS(SSSD), отключать winbind и устанавливать
libwbclient-sssd.
- "клиенты с обычными сервисами". Это "обычные клиенты", на которых мы
разместили дополнительные сервисы, с аутентификацией через Kerberos и
авторизацией через NSS(SSSD), например SSH. На них тоже можно сразу
включать SSSD, отключать winbind и устанавливать libwbclient-sssd.
- "клиенты с сервисами и Samba". Это такие "клиенты с обычными
сервисами", на которых мы решили установить Samba и что-то шарить. И
вот тут нам для чего-то становиться необходим winbind
- "обычные сервера". Это такие "серверные" решения, где даже PAM(SSSD)
и NSS(SSSD) включать необязательно, где нужны только сервисные
принципалы, а за авторизационной информацией сервисы могут и сами в
LDAP сходить, если надо.
- "необычные сервера". Это такие "обычные сервера", где включаются
PAM(SSSD) и NSS(SSSD) и где может оказаться необходим winbind, для
того, чтобы аутентифицировать и авторизовывать пользователей,
подключающихся по сети."
- "контроллеры домена" - это "клиенты с сервисами и Samba", на которых
установлена samba-DC, и вместо
 security = ADS,
указано
 server role = active directory domain controller

Таким образом:
"обычные клиенты" = "клиенты с обычными сервисами".
"необычные сервера" = "клиенты с сервисами и Samba".

Для "обычных клиентов" получаем NSS(SSSD), +libwbclient-sssd, -libwbclient.
Для "необычных серверов" получаем NSS(SSSD), -libwbclient-sssd,
+libwbclient (и winbindd).

Получается, что если мы хотим на "обычном клиенте" расшарить каталог,
то у нас клиент превращается в "необычный сервер", где требуется
запустить winbind и установить libwbclient вместо libwbclient-sssd. Но
это будет ещё не "контроллер домена", где вместо пакета samba
требуется установить пакет samba-DC.


[...]
>> ____________________________
>>
>> В итоге, возникают более сложные вопросы:
>> - Какие, конкретно, конфигурации "пакетные зависимости не дают
>> возможность корректно выразить"? Мне непонятно.
> Что непонятно?
>
> У нас есть четыре основных конфигурации,
>
> - NSS(SSSD), Samba сервер, -libwbclient-sssd, +libwbclient (и winbindd)
> - NSS(SSSD), FreeIPA клиент, +libwbclient-sssd, -libwbclient
> - NSS(SSSD), -libwbclient-sssd, -libwbclient
> - NSS(SSSD), -libwbclient-sssd, +libwbclient (и winbindd)
>
> Аналогичные комбинации можно построить и с nss_winbind/pam_winbind, но
> они будут уступать по функционалу этим четырем -- SSSD умеет гораздо
> больше в плане аутентификации и доставки сессии PAM, чем pam_winbindd. В
> первой комбинации достаточно заменить "Samba сервер" на любое серверное
> ПО, которому необходимо принимать NTLMSSP, например, веб-сервер с
> mod_auth_gssapi и gss-ntlmssp, по факту это смысл не изменит.
>
> Те конфигурации, где до сих пор невозможно использовать GSSAPI, нужно
> учить использовать GSSAPI, чтобы привести их к первой или четвертой.
> Например, FreeRADIUS не имеет модуля RLM для проверки аутентификации
> через GSSAPI. Есть модуль для Kerberos 5, есть модуль для вызова
> libwbclient wbcAuthenticateUser()-подобном API, есть модуль для работы
> через ntlm-auth.
>
> В Squid тоже стоило бы заменить вызов ntlm-auth на использование GSSAPI.
>
> Это всё простые и очевидные моменты, которые известны разработчикам и от
> реализации их нас ограничивает только отсутствие времени. Помощь
> приветствуется.

Да... но всё это конкретные сервисы. Это не общий случай. Это
отдельные, специальные, выделенные узлы, где всё настраивается руками.
И если уже там нужен winbind или gssntlmssp для NTLM, то там, вполне
может быть, что и не будет никакого sssd.

Что у нас тут может быть? Сервисы с аутентификацией в домене, но не
через керберные ключи.
- Samba file server.
- Web-server.
- FreeRADIUS.
- Squid proxy.
- ...
От сюда и NTLM + Winbind, через который сервис обращается к DC, если
не умеет gssapi.


>> - Что мы хотим получить альтернативами, если библиотека, в заданный
>> момент, всё равно выбрана одна и вполне конкретная? Какие возможности?
>>
>> Я вижу только одну понятную возможность. Чтобы выпилить весь старый
>> хлам, нужно быстро уметь проверить - работает всё без него или нет. И
>> только в этом я пока вижу смысл именно альтернатив.
>
> Альтернативы -- это способ обойти ограничения механизма построения
> зависимостей на уровне RPM, которые по своей природе негибкие и без
> возможности распространения одной ветки выбора на всю цепочку затронутых
> пакетов каким-то очевидным способом.

Итак, у нас есть следующие варианты для SSSD и WINBIND:

Клиент не для AD:
1) NSS(SSSD), +sssd, -libwbclient-sssd, -libwbclient

Клиент или сервер для AD:
2) NSS(SSSD), -samba-winbind, +sssd, +sssd-ad, +libwbclient-sssd,
-libwbclient (без secure channel через winbind)
3) NSS(WINBIND), +samba-winbind, -sssd, -sssd-ad, -libwbclient-sssd,
+libwbclient (чистый winbind)
4) NSS(SSSD), +samba-winbind, +sssd, +sssd-ad, -libwbclient-sssd,
+libwbclient (sssd + winbind)

Тут стоит отметить, что
+sssd-ad, +libwbclient-sssd, -libwbclient =
на самом деле, у нас сейчас это пакеты
= sssd-ad + libsmbclient + libwbclient + libwbclient-sssd, где
libwbclient-sssd замещает libwbclient через альтернативы.

Контроллер домена:
5) NSS(WINBIND), samba-DC-winbind, -sssd, -sssd-ad, -libwbclient-sssd
6) NSS(SSSD) samba-DC-winbind, +sssd, +sssd-ad, -libwbclient-sssd

Последний вариант у нас не устанавливается, поскольку:
$ rpm -qf /usr/lib64/samba-dc/libwbclient.so.0.13
samba-DC-libs-4.5.1-alt0.M80P.1


apt> install sssd-ad
Чтобы выполнить эту операцию необходимы изменения, которые не были запрошены.
Следующие пакеты будут УДАЛЕНЫ:
  samba-DC samba-DC-common samba-DC-winbind samba-DC-winbind-clients
Следующие НОВЫЕ пакеты будут установлены:
  libbasicobjects libcares libcollection libdhash libhttp-parser
libini_config libjansson libnetapi libpath_utils libref_array
libsasl2-plugin-gssapi libsemanage
  libsepol libsmbclient libsss_idmap libsss_nss_idmap libustr
libwbclient samba-client-libs samba-common sssd sssd-ad sssd-client
sssd-krb5-common sssd-pac

________________________

Итого у нас три проблемы:
1) gssntlmssp должен жестко зависеть от libwbclient.
2) samba-winbind уже жестко зависит от libwbclient через цепочку
зависимостей и, по сути, должен конфликтовать с libwbclient-sssd.
3) из samba-DC-libs нужно либо выпиливать
/usr/lib64/samba-dc/libwbclient.so.0.13 в отдельный пакет
libwbclient-DC и добавлять его, как ещё одну альтернативу... Либо я
пока не понимаю как это разрулить.


-- 
Sin (Sinelnikov Evgeny)

Подробная информация о списке рассылки Samba