OpenLDAP, Samba e password aging

Question

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 o acesso ao shell nos servidores, o login no domínio Samba, WiFi, OpenVPN, Mantis, etc. serviços específicos regidos pelos campos de associação de grupo ou objeto do usuário). Como temos dados pessoais em nossa rede, precisamos implementar o envelhecimento da senha, de acordo com 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 de hashing e envelhecimento de senhas diferentes. Embora a sincronização das próprias senhas seja fácil (o ldap password sync = Yes in smb.conf ), a adição da quebra de senha à mistura interrompe as coisas: O Samba não atualiza shadowLastChange. Juntamente com obey pam restrictions = Yes cria um sistema no qual um usuário do Windows não pode alterar senhas antigas, mas se eu não usá-las, diretórios pessoais não serão criados automaticamente. A alternativa é usar o uso da operação estendida LDAP para alteração de senha, mas o módulo smbk5pwd também não o define. O que é pior, o mantenedor do OpenLDAP não irá atualizá-lo / aceitar patches, pois esse campo é considerado obsoleto.

Então, minha pergunta é: qual é a melhor solução? Quais são os altos e baixos deles?

1. Use o LDAP ppolicy e o envelhecimento interno da senha LDAP?

   1. Como funciona bem 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, não o shadow?
   3. O GOsa² trabalha com o ppolicy?
   4. Existem outras ferramentas administrativas que podem funcionar com o ppolicy -enabled LDAP?

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

Answer 1

(trabalho em andamento, adicionarei detalhes mais tarde)

Boas notícias a todos! Eu tenho a coisa toda funcionando, mais ou menos ..., em um ambiente de testes ...:

1. A política de senha (com qualidade e tempo) é aplicada no nível do OpenLDAP (graças a ppolicy , not24get e passwdqc )
2. As senhas são sincronizadas entre o Samba e o POSIX nos dois sentidos (graças a smbk5pwd ). Observação: a verificação de qualidade com o Samba e a política paga não é óbvia: o password check script ( pwqcheck -1 de passwdqc ) precisa executar as mesmas verificações que o LDAP ou o usuário receberá uma Permissão negada em vez de "Senha muito fácil, tente diferente".
3. O PAM e o Samba avisam ao usuário que a senha expirará em breve.
4. Os diretórios de usuário são criados usando pam_mkhomedir
5. Implementação do GOsa² do RFC2307bis (e esquema associado) insere uid em entradas de grupos, portanto, aplicativos que esperam NIS (a maioria do material "UNIXy") ou RFC2307bis (a maioria dos aplicativos "projetados para AD") funcionam bem.

O único problema é que desabilitar uma conta requer o uso de ferramentas CLI (ou escrever o script GOsa postmodify) ou a conta não será bloqueada no nível LDAP, apenas para o PAM e o Samba. A expiração da senha ainda será aplicada, por isso não é um grande problema.

    

Answer 2

Eu escrevi minha própria sobreposição do OpenLDAP chamada shadowlastchange para atualize o atributo shadowLastChange sempre que ocorrer uma alteração de senha EXOP. Está ativado em slapd.conf :

moduleload smbk5pwd
moduleload shadowlastchange
...

database bdb
...
overlay smbk5pwd
overlay shadowlastchange

Eu configurei smb.conf para alterar as senhas via EXOP:

ldap passwd sync = Only

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

    

Answer 3

Como um intervalo, criei um script para o Samba que atualizará o shadowLastChange na alteração de 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 de unix password sync definido como yes , passwd chat definido como *OK* e passwd program para o script acima com "%u" como parâmetro.

Uma conta especificada em LDAP_USER precisa ser criada no LDAP e com permissões para ler uid de todos os usuários do Samba e o direito de escrever shadowLastChange .

    

Answer 4

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