Поставил я на новый сервер 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-ресурсы, то подобная синхронизация необходима.
