samba + unix accounts

Поставил я на новый сервер Lenny, завел там с полтора десятка пользователей. И нужно теперь развести, согласно данной заказчиком бумажке, этих пользователей по различным samba-шарам, с учетом указаний видимости/невидимости тех или иных общих каталогов. Умолчальный для меня способ - завести согласно списку unix-пользователей список smb-пользователей и уже средствами samba-ы развесить нужные разрешения. Однако лень. В итоге брожения по Сети на предмет поиска идеи упрощения своей тяжелой и неказистой жизни привели к следующим выводам:

1) как вариант, использовать существующие учетки системных (/etc/passwd, /etc/shadow) пользователей, авторизуясь, тем самым, через PAM. Однако тут есть существенные грабли. Как выяснилось практически и теоретически, механизм обмена аутентификационными данными у PAM и samba шифруются разными алгоритмами, и поэтому отправить самбу к PAM'у можно (obey pam restrictions = no), но бессмысленно - хеши паролей не совпадут  со всеми вытекающими. Чтобы  это обойти, требуется дополнительно отключать шифрование паролей со стороны сервера (encrypt passwords = no) и принуждать smb-клиентов отсылать пароль в plaintext, что запрещено по умолчанию как в linux, так в windows. Для этого smbclient следует запускать с указанием альтернативного конфиг-файла, в котором записано следующее (рецепт отсюда): 

[globals]
    client lanman auth = yes
    client plaintext auth = yes

В случае win-клиента необходимо поправить реестр, запустив такой reg-файл:

REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkStation\parameters]
"EnablePlainTextPassword"=dword:00000001

Или вручную, в Администрировании - рецепт тут.
Таким образом, клиент, желающий аутентифицироваться будет отправлен к PAM'у, где его будет ждать

auth    required        pam_unix.so nullok_secure

2) Можно утащить все в LDAP и c помощью того же PAM'а авторизовывать всех и вся. Рецептов - вал. Такой способ я считаю единственно верным в достаточно большой компании со сложной инфраструктурой и, возможно, частыми изменениями учетных данных и прав доступа. Внеся необходимые изменения в одном месте, получаем изменения во всех точках, касающихся авторизации.
3) Миграционно-ленивый метод. Здесь мы не выступаем против разграничения  /etc/passwd и smbpasswd. С другой стороны, мы противимся мартышкиному труду вбивания n-ного количества пользователей два раза, с последующим слежением (при необходимости) за синхронизацией изменений. Используя libpam-smbpass, мы будем создавать базу smbpasswd из существующей /etc/passwd постепенно. Тут можно поступить двояко. Или введя дополнительно в PAM следующее условие:

auth    optional        pam_smbpass.so  migrate

Таким образом, внеся это в common-auth, мы получим создание smbpasswd-записи для аутентифицирующегося пользователя в любом сервисе, использующем common-auth (login, ssh, proxy...). А так как для введения сервера "в бой" мне придется как минимум единожды залогиниться в систему всеми пользователями, то задача решится сама собой.
Или, с другой стороны, можно дополнительно к использовать первый способ. Такой сценарий идеален для миграции с шар "всё всем" на шары "каждому по потребностям" без геморроя и возмущенных звонков пользователей. Включил на месяц, а потом прикрыл plaintext-лавочку. И секурность соблюдена, и нервы в порядке.
Также необходимо добавить в common-password следующую запись:

password        optional        pam_smbpass.so nullok use_authtok try_first_pass

Это даст нам возможность автоматической синхронизации учетных данных при смене пароля unix-аккаунта. Раз уж мы используем одинаковые аутентификационные данные для работы в unix -среде и доступа на smb-ресурсы, то подобная синхронизация необходима.