[samba] Fwd: libwbclient от samba и sssd

[Alexander Bokovoy]

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 это заведомая диверсия.
> >>
> >> Вопрос о намерениях - это отдельный вопрос. Обычно всё объясняется
> >> недопониманием технических деталей. Тем более, так сделано в Fedora. А
> >> у нас, как у них.
> >>
> >> Тем не менее... у нас пакет gssntlmssp, вытягивает за собой
> >> libwbclient-sssd даже на сервере, где уже, вроде как, установлен
> >> /usr/lib64/samba-dc/libwbclient.so.0.13 (в пакете samba-DC-libs), но
> >> для него альтернативы не используются. Предполагается, что в samba и
> >> samba-DC эта библиотека собирается практически одинаково.
> >>
> >> При этом "... libwbclient-sssd не реализует аутентификацию по NTLMSSP".
> >> И тогда возникает вопрос: "Есть смысл в альтернативах при таком раскладе?"
> >>
> >> Если есть, то нужно уточнить для чего и поправить зависимости для
> >> пакета gssntlmssp, от которого зависят плагины pidgin-sipe и
> >> telepathy-sipe.
> >> $ apt-cache whatdepends gssntlmssp
> >> gssntlmssp-0.6.0-alt1.qa1
> >>   gssntlmssp-devel-0.6.0-alt1.qa1
> >>     Требует: gssntlmssp = 0.6.0-alt1.qa1
> >>   i586-gssntlmssp.32bit-0.6.0-alt1.qa1
> >>     Требует: gssntlmssp = 0.6.0-alt1.qa1
> >>   telepathy-sipe-1.20.1-alt1
> >>     Требует: gssntlmssp
> >>   pidgin-sipe-1.20.1-alt1
> >>     Требует: gssntlmssp
> >>
> >> Хотя, в принципе, получается, что для сервера можно тогда ничего не
> >> менять, потому что gssntlmssp нужен только на клиентах, где вполне
> >> может использоваться sssd и libwbclient-sssd. И при этом остаётся
> >> другой вопрос: "Совместим ли gssntlmssp с libwbclient-sssd?"
> > Нет, gssntlmssp не может работать через libwbclient-sssd.
> >
> > gssntlmssp нужен там, где не используется инфраструктура Kerberos,
> > потому что в противном случае выбора модуля gss-ntlmssp не произойдет.
> > Это означает, что либо клиент, либо сервер не включены в домен AD или
> > FreeIPA. В этом случае использовать libwbclient-sssd смысла никакого
> > нет.
> >
> > Основная проблема в том, что пакетные зависимости не дают возможность
> > корректно выразить все эти конфигурации.
> 
> Да, спасибо, Александр. Я уже открыл два 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
>   opennx-0.16.e-alt30
>   wcmcommander-0.20.0-alt1
>   vlc-plugin-smb-2.2.4-alt1
>   sssd-ad-1.14.1-alt1.M80P.1
>   smbnetfs-0.5.3a-alt2.1
>   python3-module-smbc-1.0.15.3-alt1.1
>   python-module-smbc-1.0.15.3-alt1.1
>   mpv-0.16.0-alt2
>   libmpv1-0.16.0-alt2
>   mplayer-1.1.1-alt16
>   mencoder-1.1.1-alt16
>   xine2-plugin-samba-1.2.6-alt2
>   xine-plugin-samba-1.1.21-alt7
>   kodi-16.1-alt0.M80P.1
>   kdebase-kio-3.5.13.2-alt7.3
>   kde5-kio-extras-16.08.3-alt0.M80P.1
>   kde4base-runtime-core-16.04.1-alt2
>   gvfs-backend-smb-1.28.3-alt1
>   libgnustep-SMBKit-20140126-alt2.cvs20140126
>   gnome-vfs-module-smb-1:2.24.4-alt10
>   gnome-control-center-3.20.2-alt0.M80P.1
>   fuse-smb-0.8.7-alt4
>   libcsync-0.50.6-alt1
> 
> И всё это хозяйство куда обращается за списками пользователей и
> группами? Правильно, не явно, к winbind'у. А при использовании sssd у
> нас его может и не быть. Хотя можно себе представить, что запущены
> оба.
> 
> 
> И какое же решение мы принимаем?
> Правильно, мы делаем параллельную реализацию без всякого "хлама"
> (только NSS от sssd плюс трансляция SID'ов в UID'ы и никакого PAM от
> winbind):
> /* Authenticate a user with cached credentials */
> wbcErr wbcCredentialCache(struct wbcCredentialCacheParams *params,
>                           struct wbcCredentialCacheInfo **info,
>                           struct wbcAuthErrorInfo **error)
> {
>     if (error != NULL) {
>         *error = NULL;
>     }
> 
>     WBC_SSSD_NOT_IMPLEMENTED;
> }
> 
> И, по умолчанию, если 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.

Тем не менее, работа запланирована и ведется. К сожалению, реальность
гораздо печальнее, чем планы.

> В принципе, всё что использует gssntlmssp не имеет смысла использовать
> совместно с sssd и тем более странно, что при его установке
> вытягивается именно libwbclient-sssd, а не обычный libwbclient. Вот
> это надо исправить, я думаю, явной зависимостью.
> 
> Всё это понятно, если почитать код, но мне не кажется очевидным.
> 
> ____________________________
> 
> Далее... Какое же решение мы принимаем по поводу альтернативы для
> libwbclient и libwbclient-sssd?
> 
> - Мейнтенить sssd и samba - получается, нужно совместно.
> - А на клиентской стороне стараться использовать только libwbclient-sssd и sssd.
> 
> И... тогда получается, что у нас всё даже почти правильно.
> Но apt не должен никогда вытягивать libwbclient-sssd, по умолчанию,
> для любых клиентов, кроме sssd. И только, когда sssd установлен,
> должен вытягиваться libwbclient-sssd и заменять собой libwbclient.
> 
> И ещё... в связи с этим возникают следующие вопросы:
> - Так ли на надёжен libwbclient-sssd? Где и когда нам может
> потребоваться winbind? Есть такие конфигурации?
Если машина выступает в роли файлового сервера в домене, то должна
использоваться связка smbd+winbindd. Плюс к этому можно запустить SSSD
на системном уровне, но без libwbclient-sssd, потому что winbindd
сделает всю работу. Для интеграции SSSD и Samba есть idmap модуль от
SSSD. Единственное, что он сейчас не представляет, это обработка builtin
identities, которые нужны Samba для проверки привилегий при удаленном
администрировании.

Тут есть еще и отдельная задача синхронизации Samba/winbindd с внешними
средствами ввода в домен. Скажем, просто так ввести Samba в домен
FreeIPA не получится. После же обычного ввода в домен средствами
ipa-client-install (ipa-join, etc) у нас будут ключи Kerberos в
/etc/krb5.keytab, но не будет plain-text пароля машинной учетной записи
в secrets.tdb для Samba. К сожалению, Samba генерирует каждый раз
необходимые ключи из plain-text пароля, а не использует единожды
сгенерированные и доступные из /etc/krb5.keytab.

Эта задача будет решаться в ближашие месяцы. По факту, необходимо
научить Samba хранить уже готовые ключи из /etc/krb5.keytab (ключ в
формате arcfour-hmac и есть NT hash) в secrets.tdb и синхронизировать их
между собой, выбирая тот, у которого kvno больше. Хранение в secrets.tdb
необходимо для того, чтобы кластерная Samba работала. В случае, если мы
всё это реализуем, для члена домена не будет никакой необходимости
использовать plain-text пароль машинной учетной записи.


> - Как быть с использованием libwbclient-sssd (и sssd, вообще) на
> серверном узле, где установлен контроллер домена из пакета samba-DC?
> Ведь тогда, вообще, все клиенты нужно линковать с
> /usr/lib64/libwbclient.so.0, кроме внутренних.
>  - И где граница? smbclient - это же тогда внешний клиент, или как?
SSSD можно использовать на контроллере домена, без проблем. Только не
нужно устанавливать libwbclient-sssd.


> 
> ____________________________
> 
> В итоге, возникают более сложные вопросы:
> - Какие, конкретно, конфигурации "пакетные зависимости не дают
> возможность корректно выразить"? Мне непонятно.
Что непонятно?

У нас есть четыре основных конфигурации, 

- 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.

Это всё простые и очевидные моменты, которые известны разработчикам и от
реализации их нас ограничивает только отсутствие времени. Помощь
приветствуется.

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

-- 
/ Alexander Bokovoy