OpenLDAP, Samba i starzenie się haseł

Konfiguruję system, w którym wszystkie zasoby IT są dostępne za pośrednictwem pojedynczej pary hasła użytkownika, czy to dostępu do powłoki na serwerach, logowania do domeny Samby, WiFi, OpenVPN, Mantis itp. (Z dostępem do określonych usług zarządzanych według członkostwa w grupie lub pól obiektu użytkownika). Ponieważ mamy dane osobowe w naszej sieci, musimy wdrożyć starzenie się hasła, zgodnie z unijną dyrektywą o ochronie danych (a raczej jej polską wersją).

Problem polega na tym, że konta Samba i POSIX w LDAP używają różnych danych mieszania i starzenia się haseł. Podczas synchronizacji haseł sami łatwo (the ldap password sync = Yesw smb.conf), dodając hasło starzenia do przerwy mix rzeczy: Samba nie aktualizuje shadowLastChange. Razem z obey pam restrictions = Yestworzy system, w którym użytkownik systemu Windows nie może zmienić wieku hasła, ale jeśli go nie użyję, katalogi domowe nie zostaną utworzone automatycznie. Alternatywą jest użycie rozszerzonej operacji LDAP do zmiany hasła, ale smbk5pwdmoduł też tego nie ustawia. Co gorsza, opiekun OpenLDAP nie zaktualizuje go / nie zaakceptuje poprawek, ponieważ to pole jest uważane za przestarzałe.

Moje pytanie brzmi: jakie jest najlepsze rozwiązanie? Jakie są ich zalety i wady?

1. Używać ppolicystarzenia się LDAP i wewnętrznego hasła LDAP?

   1. Jak dobrze działa z modułami NSS, PAM, samba, innymi systemami?
   2. Czy moduły NSS i PAM muszą być skonfigurowane w specjalny sposób, aby używać ppolicy, a nie cienia?
   3. Czy GOsa² działa z ppolicy?
   4. Czy istnieją inne narzędzia administracyjne, które mogą współpracować z ppolicywłączonym LDAP?

2. Zhakuj razem skrypt zmiany hasła, który aktualizuje pole w LDAP. (pozostawiając możliwość, że sam użytkownik zaktualizuje pole bez zmiany hasła)

Napisałem własną nakładkę OpenLDAP, shadowlastchangeaby zaktualizować shadowLastChangeatrybut za każdym razem, gdy nastąpi zmiana hasła EXOP. Jest aktywowany w slapd.conf:

moduleload smbk5pwd
moduleload shadowlastchange
...

database bdb
...
overlay smbk5pwd
overlay shadowlastchange

Skonfigurowałem smb.confzmianę hasła przez EXOP:

ldap passwd sync = Only

Następnie dla każdego konta ustaw shadowMaxliczbę dni ważności hasła. Moduły OpenLDAP zajmują się resztą!

Jako stop-gap stworzyłem skrypt dla Samby, który zaktualizuje shadowLastChangezmianę hasła:

#!/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

W konfiguracji Samby należy unix password syncustawić na yes, passwd chatustawić na *OK*i passwd programpowyżej skryptu za pomocą "%u"parametru param.

Konto określone w LDAP_USERmusi zostać utworzone w LDAP i mieć uprawnienia do odczytu uidwszystkich użytkowników Samby oraz prawo do zapisu shadowLastChange.

(praca w toku, szczegóły dodam później)

Dobre wieści wszyscy! Wszystko to działa mniej więcej ... w środowisku testowym ...:

1. Polityka hasło (oba jakości-i time-wise) jest wymuszane na poziomie OpanLDAP (dzięki ppolicy, not24geti passwdqc)
2. Hasła są synchronizowane między Sambą i POSIX na dwa sposoby (dzięki smbk5pwd). Uwaga: Sprawdzanie jakości za pomocą Samby i ppolicy nie jest oczywiste: password check script( pwqcheck -1z passwdqc) musi wykonać te same kontrole, które wykonuje LDAP, w przeciwnym razie użytkownik otrzyma Odmowę dostępu zamiast „Zbyt łatwe hasło, spróbuj innego”.
3. Zarówno PAM, jak i Samba ostrzegają użytkownika, że ​​hasło wkrótce wygaśnie.
4. Katalogi użytkowników są tworzone za pomocąpam_mkhomedir
5. Implementacja GOsa² RFC2307bis (i powiązanego schematu) wstawia się uiddo wpisów grup, więc aplikacje oczekujące albo NIS (większość rzeczy „UNIXy”), albo RFC2307bis (większość aplikacji „zaprojektowanych dla AD”) działają dobrze.

Jedynym problemem jest to, że wyłączenie konta wymaga użycia narzędzi CLI (lub napisania skryptu postmodify GOsa), w przeciwnym razie konto nie zostanie zablokowane na poziomie LDAP, tylko dla PAM i Samby. Wygaśnięcie hasła będzie nadal egzekwowane, więc nie jest to duży problem.

Mam odpowiedź od jednego z programistów GOsa. W tej chwili GOsa w żaden sposób nie obsługuje nakładki ppolicy.