Компания Likewise Software открывает Likewise Open

Всё прекрасно работало в SuSE 10.2 и прекрасно работает в текущей SuSE 10.3 на практической ванильной Samba и ванильном PAM.

Очередной велосипед?

Доверить оффтопику свой пароль от Linux'а. Да ни в жисть!

а может оно работает на libnss-ldap + libpam-ldap?

Ну, плюс ко всему, ещё kerberos до кучи.. что-то изперечисленного, возможно в комбинациях..

>Комания
   ^^

> Всё прекрасно работало в SuSE 10.2 и прекрасно работает в текущей SuSE 10.3 на практической ванильной Samba и ванильном PAM.

Ты просто не работал с _по_настоящему_большими директориями. Winbind - унылое *****. Причем оффтопик тут впереди планеты всей.

Проект однозначно позитивный, хотя бы потому, что автоматизирует настройку связки Kerberos + LDAP. По настоящему он мало что решает, ибо требуется еще свой gss-api, которого в пакете нет. Поэтому набор приложений, которые поддерживают подобнуб аутентификацию крайне ограничен.

> Ты просто не работал с _по_настоящему_большими директориями. Winbind - унылое *****. Причем оффтопик тут впереди планеты всей.

Likewise Open -- это ветка Winbindd в Samba 3, которую поддерживает для своей компании Gerry Carter, член Samba Team и текущий релиз-менеджер Samba. Эти исправления со временем войдут в основную Samba, но поскольку не все они архитектурно оправданы, их будут перерабатывать.

Прошу прощения, LDAP тама нету. Winbind + Kerberos.

> чем это решение отличается от авторизации через samba/winbidd и модулей PAM не уточняется.

Не знаю, чем отличается, а Вы пробовали работать с windindd? Как Вам такая "особенность" - при перезапуске winbindd полностью утрачивается база uid/guid, выданных пользователям при первичном входе в систему, что приводит к причудливым глюкам вроде случайной смены владельцев каталогов в /home? Я уж не говорю, что некоторые закрытые программы вроде Adobe Acrobat Reader вообще отказываются запускаться у пользователей, вошедших в систему через winbindd (ошибка определения uid). Эту систему еще не смотрел, но если хотя бы одна из этих "особенностей" исправлена, то это большое достижение.

С уважением, Сергей.

> Likewise Open -- это ветка Winbindd в Samba 3, которую поддерживает для своей компании Gerry Carter, член Samba Team и текущий релиз-менеджер Samba. Эти исправления со временем войдут в основную Samba, но поскольку не все они архитектурно оправданы, их будут перерабатывать.

Тут не в winbind как таковом дело. Дело в том, что наш любимый NSS имеет примерно 3 комманды getpwent, setpwent, endpwent для работы с пользовательской информации. Причем, как нетрудно включив мосг догадаться, для поиска только _информации_о_пользователе ты можешь сделать в среднем N/2 операций. Нука заведи 100 000 000 энтрей в директории и погляди на жуткие тормоза. Причем это не будет зависеть от "красоты" Winbind. Это убогость NSS. И Джерри Эллисон тут прав.

> при перезапуске winbindd полностью утрачивается база uid/guid, выданных пользователям при первичном входе в систему, что приводит к причудливым глюкам вроде случайной смены владельцев каталогов в /home?

Можно по-подробнее и в bugzila.samba.org? Можете на русском, я пойму. Вместе с конфигурационными файлами и описанием своей среды. Такое поведение ненормально для правильно настроенной системы и не наблюдается у разработчиков и во внедрениях, в которых они участвуют.

> Не знаю, чем отличается, а Вы пробовали работать с windindd? Как Вам такая "особенность" - при перезапуске winbindd полностью утрачивается база uid/guid, выданных пользователям при первичном входе в систему, что приводит к причудливым глюкам вроде случайной смены владельцев каталогов в /home? Я уж не говорю, что некоторые закрытые программы вроде Adobe Acrobat Reader вообще отказываются запускаться у пользователей, вошедших в систему через winbindd (ошибка определения uid). Эту систему еще не смотрел, но если хотя бы одна из этих "особенностей" исправлена, то это большое достижение.

Согласен с предыдущим докладчиком. Winbind в его текущес состоянии - унылое гогно. Совсем энтерпрайз - взять LDAP, Kerberos + MSFU и замутить "православную" аутентификацию без костылей.

Однако для случаев, когда поставить MSFU на AD не дадут, любое решение лучше winbind

> Вы пробовали работать с windindd? Как Вам такая "особенность" - при перезапуске winbindd полностью утрачивается база uid/guid, выданных пользователям при первичном входе в систему, что приводит к причудливым глюкам вроде случайной смены владельцев каталогов в /home?

Не наблюдал. Имею пачку Linux компьютеров, которые авторизуются через winbindd.

Кто знает рабочую кофу самбы смотрящей через пам в ДС, который синхронизируется с АД. Рабочую даже в ситуации пропадпния связи с АД? С двусторонней синхронизацией паролей...

много велосипедов хороших и разных...

> Кто знает рабочую кофу самбы смотрящей через пам в ДС, который синхронизируется с АД. Рабочую даже в ситуации пропадпния связи с АД? С двусторонней синхронизацией паролей...

Такая "самба" называется Red Hat Directory Server. Они умеют двунаправленную репликацию с AD. Только стоит некисло и требует установки модуля на AD. Но принципиально решаемо

Самба не может называтся редхат АД. Я использую Sun DS с синхронизацией паролей. Линукс хосты отлично авторизутся в лдап и без запроса пароля посещают шары CIFS. Вин юзера получают access denied. Пробовал и Федора ДС ака Редхат ДС. Тестикулы теже. Затык в методах авторизации. Когда ДС остается изолированым от АД вин клиентам негде брать НТпассворд и ЛМпассворд. ДС хранит только мд5 хэш. Из известных мне костылей это авторизовать винхосты не в АД, а в лдап или костыль заполнения НТпассворд и ЛМпассворд.

З.Ы. может кто еще новые ядреные сервисы CIFS пробовал в опенсолярке? Там должно это решаться на уровне пам и гссапи...

в зюзе есть вход в домен искаропки. Правда никагда не пробовал - и бо нафиг здалось.

Странно.

Я уже год на работе захожу к себе на машину рабочую по логину из AD.

А можно, хоть тут, рассказ как вам это удалось?

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

Просто сам использую winbindd, и всякие adobe acrobat вполне неплохо работают. И машину часто перезагружаю, и никогда проблем с правами не было.

Где же эти сказочники с кривыми руками прячутся, у которых не работет winbind, куда-то съезжают права? Как советовали ранее - идите в bugzila. Только боюсь, что действуя нормальными руками разработчики это повторить не смогут.

Из недостатков на сегодняшний момент отмечу только два: медленная работа при большом AD (проблемы nss), не кэшируется аутентификация локально (проблемы когда AD не доступен) - но и это решаемо новым модулем nss-ldpad.

> Самба не может называтся редхат АД. Я использую Sun DS с синхронизацией паролей. Линукс хосты отлично авторизутся в лдап и без запроса пароля посещают шары CIFS. Вин юзера получают access denied. Пробовал и Федора ДС ака Редхат ДС. Тестикулы теже.

Забыл поставить теги <sarcasm> Такая "самба" </sarcasm>

Суть в следующем. AD - не более чем извращенная связка LDAP + Kerberos. Соответственно, единичные линуксовые клиенты неплохо аутентифицируются в самой AD.

Если задача стоит масштабного использования Linux в гетерогенной среде, то здесь полезно сделать "юзабельные" механизмы хранения пользовательской информации и аутентификации, родной для Линукса. По опыту - Red Hat/Fedora Directory Server единственные умею это с синком паролей. В случае желания использовать SSO, родной Kerberos AD должен работать без существенных затыков.

Можно попробовать поднять "родной" линуксовый барбос, но в этом случае острием встает проблема синка пародей в LDAP и в Kerberos.

> в зюзе есть вход в домен искаропки. Правда никагда не пробовал - и бо нафиг здалось.

Видели мы этот "Вход в домен". Ничего интересного, просто настроенный winbind из коробки.

> Из недостатков на сегодняшний момент отмечу только два: медленная работа при большом AD (проблемы nss), не кэшируется аутентификация локально (проблемы когда AD не доступен) - но и это решаемо новым модулем nss-ldpad.

Не понял? nss-ldpad это что? Это чтоле для использования AD-шных пародей через pam_unix.so?

Где на это чудо взглянуть можно?

> Из недостатков на сегодняшний момент отмечу только два: медленная работа при большом AD (проблемы nss), не кэшируется аутентификация локально (проблемы когда AD не доступен) - но и это решаемо новым модулем nss-ldpad.

Оффлайновая работа winbindd давно реализована в 3.2, части ее можно видеть в Likewise Open.

> Всё прекрасно работало в SuSE 10.2 и прекрасно работает в текущей SuSE 10.3 на практической ванильной Samba и ванильном PAM.

Прекрасно, говорите? А как при таком раскладе в той же SuSE 10.2 назначить доменному пользователю локальные права на данном десктопе? Искал, спрашивал - никто толком не знает. Буду благодарен за компетентную информацию.

>Прекрасно, говорите?

На самом деле я силюсь представить сцерий когда это нужно - и не могу. Могу представить вообще какой-то специальный случай типа публичного терминала - но чтобы пользователю надо было как-то более сужать права дальше хомяка - просветите на счет сценариев?

>На самом деле я силюсь представить сцерий когда это нужно - и не могу.

Речь идёт о вполне насущных проблемах. Например, пользователь вошёл в систему под доменным логином и хочет смонтировать CD. Как ему дать на это право?

> Например, пользователь вошёл в систему под доменным логином и хочет смонтировать CD. Как ему дать на это право?

Какие-то ужасы рассказываете - Fedora 8 с _в_ключенным SeLinux - всё монтируется - и CD, и Flash. (Авторизация через winbindd).

>Как ему дать на это право?

Включить в группу?

>Включить в группу?

Именно. В этом и вопрос - как включить в ЛОКАЛЬНУЮ группу ДОМЕННОГО (winbind) пользователя?

P.S. Насколько помню, через groupmod нечто подобное прокатило, но всех вопросов не сняло. По крайней мере, проблема с DBUS при монтировании вроде осталась нерешённой.

>Именно. В этом и вопрос - как включить в ЛОКАЛЬНУЮ группу ДОМЕННОГО (winbind) пользователя?

Создать в домене группу с тем же id не прокатит?