Я настраиваю систему, в которой все ИТ-ресурсы доступны через одну пару пароль пользователя, будь то доступ к оболочке на серверах, вход в домен Samba, WiFi, OpenVPN, Mantis и т. Д. (С доступом к определенным службам, управляемым членством в группе или полями объекта пользователя). Поскольку в нашей сети есть личные данные, нам необходимо реализовать устаревание пароля в соответствии с Директивой ЕС о защите данных (или, вернее, ее польской версией).
Проблема заключается в том, что учетные записи Samba и POSIX в LDAP используют различную информацию о хешировании паролей и устаревании. Хотя синхронизация самих паролей проста ( ldap password sync = Yes
in-in smb.conf
), добавление устаревания пароля в микс разрушает ситуацию: Samba не обновляет shadowLastChange. Вместе с obey pam restrictions = Yes
созданием системы, в которой пользователь Windows не может изменить устаревший пароль, но если я его не использую, домашние каталоги не будут создаваться автоматически. Альтернативой является использование расширенной операции LDAP для смены пароля, но smbk5pwd
модуль также не устанавливает ее. Что еще хуже, сопровождающий OpenLDAP не будет обновлять его / принимать исправления, так как это поле считается устаревшим.
Итак, мой вопрос, что является лучшим решением? Каковы их плюсы и минусы?
Использовать LDAP
ppolicy
и устаревание внутреннего пароля LDAP?- Насколько хорошо это работает с модулями NSS, PAM, samba, другими системами?
- Нужно ли настраивать модули NSS и PAM специальным образом, чтобы использовать ppolicy, а не shadow?
- Работает ли GOsa² с ppolicy?
- Существуют ли другие инструменты администрирования, которые могут работать с
ppolicy
LDAP -enabled?
Взломайте скрипт изменения пароля, который обновляет поле в LDAP. (оставляя возможность того, что пользователь сам обновит поле без изменения пароля)
Ответы:
Я написал свой собственный оверлей OpenLDAP, вызываемый
shadowlastchange
для обновленияshadowLastChange
атрибута при каждом изменении пароля EXOP. Активируется вslapd.conf
:Я настроил
smb.conf
изменить пароли через EXOP:Затем для каждой учетной записи установите
shadowMax
количество дней, в течение которых пароль действителен. Модули OpenLDAP позаботятся обо всем остальном!источник
ppolicy
илиsmbk5pwd
наложения в Debian сжимающей OpenLDAP сделать обновлениеshadowLastChange
. Yay для Debian!В качестве временного промежутка я создал скрипт для Samba, который будет обновлять
shadowLastChange
изменение пароля:В конфиге Samba он должен быть
unix password sync
установлен наyes
,passwd chat
установить на*OK*
иpasswd program
выше сценарий с"%u"
параметром param.Учетная запись, указанная в,
LDAP_USER
должна быть создана в LDAP и иметь права на чтениеuid
для всех пользователей Samba и право на записьshadowLastChange
.источник
(работа продолжается, подробности я добавлю позже)
Хорошие новости всем! У меня все работает, более или менее ..., в среде тестирования ...:
ppolicy
,not24get
иpasswdqc
)smbk5pwd
). Примечание. Проверка качества с помощью Samba и ppolicy неочевидна:password check script
(pwqcheck -1
отpasswdqc
) необходимо выполнить те же проверки, что и LDAP, или пользователь получит разрешение «Отказано» вместо «Слишком простой пароль, попробуйте другой».pam_mkhomedir
uid
в записи группы, поэтому приложения, ожидающие либо NIS (большая часть «UNIXy»), либо RFC2307bis схема (большая часть «предназначенная для AD»), работают просто отлично.Единственная проблема заключается в том, что отключение учетной записи требует использования инструментов CLI (или написания скрипта GOsa postmodify), иначе учетная запись не будет заблокирована на уровне LDAP, только для PAM и Samba. Срок действия пароля по-прежнему будет принудительно установлен, поэтому это не большая проблема.
источник
Я получил ответ от одного из разработчиков GOsa. В настоящее время GOsa никоим образом не поддерживает оверлей ppolicy.
источник