OpenLDAP, Samba e envelhecimento de senhas

Estou configurando um sistema no qual todos os recursos de TI estão disponíveis através de um único par de senha de usuário, seja acesso ao shell nos servidores, efetuando logon no domínio Samba, WiFi, OpenVPN, Mantis etc. (com acesso a serviços específicos controlados por associação ao grupo ou campos de objeto do usuário). Como temos dados pessoais em nossa rede, precisamos implementar o envelhecimento da senha, conforme a Diretiva de Proteção de Dados da UE (ou melhor, a versão polonesa dela).

O problema é que as contas Samba e POSIX no LDAP usam informações diferentes de hash e envelhecimento de senhas. Enquanto sincronizar as senhas si é fácil (o ldap password sync = Yesno smb.conf), acrescentando senha envelhecimento à mistura breaks coisas: o Samba não atualizar shadowLastChange. Juntamente com obey pam restrictions = Yescria um sistema no qual um usuário do Windows não pode alterar a senha antiga, mas se eu não a usar, os diretórios pessoais não serão criados automaticamente. A alternativa é usar a operação estendida LDAP para alterar a senha, mas o smbk5pwdmódulo também não a define. O pior é que o mantenedor do OpenLDAP não o atualiza / aceita patches, pois esse campo é considerado obsoleto.

Então, minha pergunta é: qual é a melhor solução? Quais são as vantagens e desvantagens deles?

1. Usar o LDAP ppolicye o envelhecimento interno da senha LDAP?

   1. Como funciona com NSS, módulos PAM, samba e outros sistemas?
   2. Os módulos NSS e PAM precisam ser configurados de maneira especial para usar o ppolicy, e não a sombra?
   3. O GOsa² funciona com o ppolicy?
   4. Existem outras ferramentas administrativas que podem funcionar com ppolicyLDAP ativado?

2. Hackear um script de alteração de senha que atualize o campo no LDAP. (deixando a possibilidade de o próprio usuário atualizar o campo sem alterar a senha)

Eu escrevi minha própria sobreposição OpenLDAP chamada shadowlastchangepara atualizar o shadowLastChangeatributo sempre que ocorre uma alteração na senha do EXOP. É ativado em slapd.conf:

moduleload smbk5pwd
moduleload shadowlastchange
...

database bdb
...
overlay smbk5pwd
overlay shadowlastchange

Eu configurei smb.confpara alterar senhas via EXOP:

ldap passwd sync = Only

Em seguida, para cada conta, defina shadowMaxo número de dias em que uma senha é válida. Os módulos OpenLDAP cuidam do resto!

Como uma lacuna, criei um script para o Samba que atualizará a shadowLastChangealteração na senha:

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

Na configuração do Samba, ele precisa ser unix password syncdefinido como yes, passwd chatdefinido como *OK*e passwd programacima do script com "%u"como param.

Uma conta especificada em LDAP_USERprecisa ser criada no LDAP e receber permissões para ler uidtodos os usuários do Samba e o direito de escrever shadowLastChange.

(trabalho em andamento, adicionarei detalhes mais tarde)

Boas notícias, pessoal! Eu fiz a coisa toda funcionar, mais ou menos ..., em um ambiente de teste ...:

1. Política de senha (ambos Qualidade e tempo-wise) é aplicada em nível OpenLDAP (graças a ppolicy, not24gete passwdqc)
2. As senhas são sincronizadas entre o Samba e o POSIX nos dois sentidos (graças a smbk5pwd). Nota: A verificação da qualidade com o Samba e o ppolicy não é óbvia: o password check script( pwqcheck -1from passwdqc) precisa executar as mesmas verificações que o LDAP faz ou o usuário receberá uma permissão negada em vez de "Senha muito fácil, tente diferente".
3. O PAM e o Samba alertam o usuário que a senha expirará em breve.
4. Os diretórios do usuário são criados usandopam_mkhomedir
5. A implementação do GOsa² do RFC2307bis (e esquema associado) é inserida uidnas entradas do grupo; portanto, os aplicativos que esperam o esquema NIS (a maioria dos itens "UNIXy") ou o esquema RFC2307bis (a maioria dos aplicativos "projetados para AD") funcionam bem.

O único problema é que a desativação de uma conta requer o uso de ferramentas CLI (ou a escrita do script pós-modificação do GOsa) ou a conta não será bloqueada no nível LDAP, apenas para PAM e Samba. A expiração da senha ainda será aplicada, portanto não é um grande problema.

Eu tenho resposta de um dos desenvolvedores do GOsa. No momento, o GOsa não suporta sobreposição de ppolicy de forma alguma.