Pesquisei vários sites e tutoriais, mas não consegui encontrar uma resposta para o meu problema.
Configurei o OpenLDAP 2.4 em uma máquina OpenSUSE 12.3 com uma sobreposição de política de senha. O cliente é uma máquina Linux Mint 17.1 com pacotes libnss-ldap e libpam-ldap instalados. O cliente e o servidor estão configurados para usar TLS com certificados autoassinados (o servidor funciona como uma CA e assina seu próprio certificado). Tudo funciona bem até eu adicionar o atributo pwdReset: TRUEa um usuário.
Minha intenção éforçar o usuário a alterar sua senha no próximo login. Porém, após definir este atributo o usuário não pode mais autenticar: se eu tentar 'su' (ou fazer login com) o usuário recebo o erro "Falha de autenticação". Além disso, o syslog mostra as seguintes mensagens:
Mar 4 07:27:11 client-desktop nslcd[3198]: [90cde7] <authc="johndoe"> ldap_result() failed: Insufficient access: Operations are restricted to bind/unbind/abandon/StartTLS/modify password
Mar 4 07:27:11 client-desktop nslcd[3198]: [dcc233] <authc="johndoe"> cn=John Doe,ou=people,cd=domain,dc=com: lookup failed: Invalid credentials
Essas mensagens me informam que as credenciais do usuário não são mais válidas, o que é razoável, já que eu redefini sua senha, mas o usuário não é avisado sobre a necessidade de alterar sua senha ou qualquer outra coisa. Além disso, quero evitar o uso de utilitários openldap como ldappasswd, pois os clientes não são especialistas. Portanto, quero que eles continuem usando o comando passwd típico para alterar suas próprias senhas. Pelo menos, isso é possível quando pwdReset não está definido. Além disso, posso obter esse comportamento definindo o shadowLastChangeatributo como 0, mas gostaria de fazer tudo com políticas de senha, pois também estou tentando impor o uso de senhas de pelo menos 8 caracteres. A propósito, esse recurso funciona perfeitamente.
Este é um trecho do meu DN base para que você possa verificar se estou faltando alguma coisa. Observe que pwdResetestá definido como TRUE no usuário e pwdMustChangea variável está definida como TRUE na própria política.
# John Doe, people, domain.com
dn: cn=John Doe,ou=people,dc=domain,dc=com
cn: John Doe
sn: Doe
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
uid: johndoe
uidNumber: 1003
gidNumber: 1000
homeDirectory: /home/johndoe
loginShell: /bin/bash
userPassword: e1NTSEF9VWFSMDVsSGNIWFMxcnJ5VzBtaWRkOHFmTDE1ai9RYlQ=
pwdReset: TRUE # This attribute only appears if I explicitly request it
# policies, domain.com
dn: ou=policies,dc=domain,dc=com
objectClass: top
objectClass: organizationalUnit
ou: policies
(Os seguintes atributos pertencem a cn=default,ou=policies mas por algum motivo eles não aparecem a menos que eu escreva algo aqui)
pwdInHistory: 3
pwdLockout: TRUE
pwdMaxFailure: 3
pwdLockoutDuration: 30
pwdMustChange: TRUE
pwdSafeModify: FALSE
pwdAllowUserChange: TRUE
pwdFailureCountInterval: 0
pwdGraceAuthNLimit: 0
E esta é a configuração do meu backend e das políticas de senha:
# {1}hdb, config
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=domain,dc=com
olcAccess: {0}to attrs=userPassword by self write by * auth
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to attrs=userPKCS12 by self read by * none
olcAccess: {3}to * by * read
olcRootDN: cn=admin,dc=domain,dc=com
olcRootPW: {SSHA}############## omited
olcDbCacheSize: 10000
olcDbCheckpoint: 1024 5
olcDbConfig: {0}set_cachesize 0 15000000 1
olcDbConfig: {1}set_lg_regionmax 262144
olcDbConfig: {2}set_lg_bsize 2097152
olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE
olcDbConfig: {4}set_lk_max_locks 30000
olcDbConfig: {5}set_lk_max_objects 30000
olcDbIDLcacheSize: 30000
olcDbIndex: objectclass eq
[...more indexes...]
# {0}ppolicy, {1}hdb, config
dn: olcOverlay={0}ppolicy,olcDatabase={1}hdb,cn=config
objectClass: top
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {0}ppolicy
olcPPolicyDefault: cn=default,ou=policies,dc=domain,dc=com
olcPPolicyHashCleartext: TRUE
(Os dois atributos a seguir também pertencem a {0}ppolicy)
olcPPolicyUseLockout: FALSE
olcPPolicyForwardUpdates: FALSE
Espero que alguém possa lançar alguma luz sobre isso. Qualquer ajuda é extremamente apreciada!
Cumprimentos
Editar:
Fiz algumas modificações na política padrão para obter informações sobre o que estava impedindo a autenticação do usuário. Percebi que se pwdMustChangeestiver definido como TRUE e pwdResettambém como TRUE (este na entrada do usuário), a autenticação do usuário falhará com o erro 'su: Falha de autenticação'. Porém, se pwdResetfor TRUE e pwdMustChangefor FALSE, eu faço login quantas vezes quiser com esse usuário. Acho que ter duas variáveis para isso é inútil e contra-intuitivo. Em vez disso, uma única variável deve ser usada apenas na entrada do usuário, como você quiser chamá-la pwdResetou pwdMustChange.
Responder1
As políticas no servidor LDAP não equivalem necessariamente às políticas do sistema operacional. Você parece estar imaginando uma estrutura onde você define essa propriedade overflay e oSOfica ciente da necessidade de alterar a senha, mas como você pode ver não é assim que funciona.
Para acionar um prompt no sistema operacional, um módulo de contabilidade (normalmente PAM) precisa observar a condição. A sobreposição de política de senha do OpenLDAP não é um padrão POSIX. Ao contrário do que acontece quando você ajusta as shadowpropriedades de um usuário para definir a política, pam_unixnão tem conhecimento desses atributos que está configurando. O mesmo não pode ser dito do próprio servidor OpenLDAP. Isso resulta em um bloqueio do usuário porque o usuário não consegue se autenticar no servidor Linux e não possui informações suficientes sobre o LDAP (como você mesmo observou) para trabalhar diretamente com o servidor LDAP para alterar sua senha.
Se você deseja acionar prompts de alteração de senha no sistema operacional, esta não é a ferramenta certa para o trabalho. Eu pessoalmente recomendo que você se familiarize com os shadowatributos relevantes, armazene-os no LDAP se eles precisarem ser gerenciados centralmente e use-os para acionar os comportamentos que você está procurando.
Na pam_unix(8)página de manual:
O componente de conta executa a tarefa de estabelecer o status da conta e senha do usuário com base nos seguintes elementos shadow: expire, last_change, max_change, min_change, warning_change. Neste último caso, poderá aconselhar o usuário sobre a alteração de sua senha ou, através do retorno PAM_AUTHTOKEN_REQD, adiar o atendimento ao usuário até que este estabeleça uma nova senha. As entradas listadas acima estão documentadas na página de manual shadow(5). Caso o registro do usuário não contenha uma ou mais dessas entradas, a verificação de sombra correspondente não é realizada.