Назад | Перейти на главную страницу

OpenLDAP, Samba и устаревание пароля

Я настраиваю систему, в которой все ИТ-ресурсы доступны через одну пару пользователь-пароль, будь то доступ к оболочке на серверах, вход в домен Samba, WiFi, OpenVPN, Mantis и т. Д. (С доступом к определенным службам, управляемым по членству в группе или полям объекта пользователя). Поскольку у нас есть личные данные в нашей сети, нам необходимо реализовать устаревание пароля в соответствии с Директивой ЕС о защите данных (или, скорее, ее польской версией).

Проблема в том, что учетные записи Samba и POSIX в LDAP используют разную информацию о хэшировании паролей и устаревании. Хотя синхронизировать сами пароли несложно ( ldap password sync = Yes в smb.conf), добавление устаревания пароля к этому мешает: Samba не обновляет shadowLastChange. Вместе с obey pam restrictions = Yes создает систему, в которой пользователь Windows не может изменить устаревший пароль, но если я его не использую, домашние каталоги не будут созданы автоматически. Альтернативой является использование расширенной операции LDAP для смены пароля, но smbk5pwd модуль тоже не устанавливает его. Что еще хуже, сопровождающий OpenLDAP не будет обновлять его / принимать исправления, поскольку это поле считается устаревшим.

Итак, мой вопрос: какое решение лучше? Каковы их преимущества и недостатки?

  1. Использовать LDAP ppolicy а внутреннее устаревание пароля LDAP?

    1. Насколько хорошо он работает с модулями NSS, PAM, самбой, другими системами?
    2. Нужно ли настраивать модули NSS и PAM особым образом для использования ppolicy, а не shadow?
    3. Делает GOsa² работать с ppolicy?
    4. Есть ли другие инструменты администрирования, которые могут работать с ppolicy-подключен LDAP?

  2. Составьте сценарий изменения пароля, который обновляет поле в LDAP. (оставляя возможность, что пользователь сам обновит поле без изменения пароля)

(в работе, подробности добавлю позже)

Всем хорошие новости! У меня все это работает, более или менее ... в тестовой среде ...:

  1. Политика паролей (как по качеству, так и по времени) применяется на уровне OpenLDAP (благодаря ppolicy, not24get и passwdqc)
  2. Пароли синхронизируются между Samba и POSIX обоими способами (благодаря smbk5pwd). Примечание. Проверка качества с помощью Samba и ppolicy не очевидна: password check script (pwqcheck -1 из passwdqc) необходимо выполнить те же проверки, что и LDAP, иначе пользователь получит сообщение Permission Denied вместо «Слишком простой пароль, попробуйте другой».
  3. И PAM, и Samba предупреждают пользователя, что срок действия пароля скоро истечет.
  4. Каталоги пользователей являются создано с использованием pam_mkhomedir
  5. GOsa² реализация вставок RFC2307bis (и связанной схемы) uid для группировки записей, поэтому приложения, ожидающие либо NIS (большая часть «UNIXy»), либо схемы RFC2307bis (большинство «разработанных для AD» приложений) работают нормально.

Единственная проблема заключается в том, что для отключения учетной записи требуется использование инструментов CLI (или написания сценария postmodify GOsa), иначе учетная запись не будет заблокирована на уровне LDAP, только для PAM и Samba. Срок действия пароля по-прежнему будет принудительным, так что это не большая проблема.

В качестве временной остановки я создал сценарий для Samba, который обновит shadowLastChange при смене пароля:

#!/bin/sh
# script to update shadowLastChange when samba updates passwords
# it's not needed when using 'passwd', it does update the field,
# even if pam_ldap is using LDAP Extented Operation to change password

LDAP_MODIFY="/usr/bin/ldapmodify"
LDAP_SEARCH="/usr/bin/ldapsearch"
LDAP_USER="uid=shadow-update,ou=Services,dc=example,dc=com"
LDAP_PASSWORD="change-me"
LDAP_HOST="localhost"

# get date
SLC=$((`date '+%s'` / 24 / 3600))

# get user login name
user=$1

# find user's DN
dn=$($LDAP_SEARCH -x -h $LDAP_HOST -LLL -b dc=example,dc=com "(uid=$user)" dn)
dn=${dn#dn:}

# check if DN is not base64 encoded
if [ "${dn:0:1}" = ":" ]; then
        # update password change date
        echo "dn:$dn
changetype: modify
replace: shadowLastChange
shadowLastChange: $SLC" | cat | $LDAP_MODIFY -x -h "$LDAP_HOST" \
 -D "$LDAP_USER" -w "$LDAP_PASSWORD" > /dev/null 2>&1
else
        # update password change date
        echo "dn: $dn
changetype: modify
replace: shadowLastChange
shadowLastChange: $SLC" | cat | $LDAP_MODIFY -x -h "$LDAP_HOST" \
 -D "$LDAP_USER" -w "$LDAP_PASSWORD" > /dev/null 2>&1
fi

err=$?

if [ ! $err -eq 0 ]; then
   echo "error: can't update shadowLastChange: $err"
   echo "`date`: shadow.sh: can't update shadowLastChange: $err"\
       >> /var/log/shadow-update.log
   exit;
fi

echo OK

В конфиге Samba нужно unix password sync установлен в yes, passwd chat установлен в *OK* и passwd program в сценарий выше с "%u" как парам.

Аккаунт, указанный в LDAP_USER необходимо создать в LDAP и предоставить разрешения на чтение uid всех пользователей Samba и право писать shadowLastChange.

Я написал свой собственный оверлей OpenLDAP под названием shadowlastchange обновить shadowLastChange всякий раз, когда происходит изменение пароля EXOP. Он активируется в slapd.conf:

moduleload smbk5pwd
moduleload shadowlastchange
...

database bdb
...
overlay smbk5pwd
overlay shadowlastchange

Я настроил smb.conf для смены паролей через EXOP:

ldap passwd sync = Only

Затем для каждой учетной записи установите shadowMax к количеству дней, в течение которых пароль действителен. Об остальном позаботятся модули OpenLDAP!

Получил ответ от одного из разработчиков GOsa. В настоящее время GOsa никак не поддерживает наложение ppolicy.