Cliente LDAP Linux (Ubuntu vs CentOS) para 389-ds - política de senha

3

389-ds no servidor Ubuntu 12.04 instalado e funcionando. Ativou Fine-grained password policies e User must change password after reset para a árvore inteira. Criado o usuário de teste posteriormente.

Login do cliente CentOS: o usuário é solicitado a alterar sua senha: You are required to change your password immediately.

Login do cliente Ubuntu: o usuário efetua login, não solicita .

Arquivos de configuração do cliente CentOS copiados para o cliente Ubuntu, precisamente /etc/pam_ldap.conf (no Ubuntu, isto é /etc/ldap.conf), /etc/nslcd.conf, /etc/openldap/ldap.conf (no Ubuntu /etc/ldap/ldap.conf) - sem dados.

Ambos os clientes autenticam com sucesso, ambos podem alterar senhas de usuários.

Todos os logins são logins de terminal, não há interface gráfica envolvida.

PAM em ambos os clientes:

  1. Ubuntu:

    • /etc/pam.d/common-account

      account [success=2 new_authtok_reqd=done default=ignore]
      pam_unix.so account [success=1 default=ignore] pam_ldap.so account requisite pam_deny.so account required
      pam_permit.so

    • /etc/pam.d/common-auth

      auth [success=2 default=ignore] pam_unix.so nullok_secure auth [success=1 default=ignore] pam_ldap.so use_first_pass auth
      requisite pam_deny.so auth required
      pam_permit.so auth optional pam_cap.so

    • /etc/pam.d/common-password

      password [success=2 default=ignore] pam_unix.so obscure sha512 password [success=1 user_unknown=ignore default=die]
      pam_ldap.so try_first_pass password requisite
      pam_deny.so password required
      pam_permit.so password optional pam_gnome_keyring.so

  2. CentOS

    • /etc/pam.d/system-auth-ac

      #%PAM-1.0 auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass auth
      required pam_deny.so

      account required pam_unix.so broken_shadow account
      sufficient pam_localuser.so account sufficient
      pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required
      pam_permit.so

      password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so

      session optional pam_keyinit.so revoke session required
      pam_limits.so session optional pam_mkhomedir.so session
      [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional
      pam_ldap.so

    • /etc/pam.d/passwd-auth-ac

      #%PAM-1.0 auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite
      pam_succeed_if.so uid >= 500 quiet auth sufficient
      pam_ldap.so use_first_pass auth required pam_deny.so

      account required pam_unix.so broken_shadow account
      sufficient pam_localuser.so account sufficient
      pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required
      pam_permit.so

      password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so

      session optional pam_keyinit.so revoke session required
      pam_limits.so session optional pam_mkhomedir.so session
      [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional
      pam_ldap.so

Uma diferença é que no Ubuntu eu não tenho o cracklib instalado. Eu pretendo fazê-lo mais tarde, agora estou apenas testando.

Gostaria de saber se o cliente LDAP do Ubuntu ingressa no Windows AD, como ele recebe notificações de expiração de senha dele. Deve ser algo parecido, mas não consigo entender.

Como fazer com que o cliente Ubuntu honre / obedeça as políticas de senha? Por que não vejo o prompt You are required to change your password immediately. ao fazer login, já que a mesma configuração funciona com o CentOS?

Obrigado!

Boas festas!

    
por grs 21.12.2012 / 21:47

1 resposta

1

Eu tenho brincado com o 389-ds no Ubuntu para um projeto de trabalho e me deparei com o mesmo problema.

Não tenho certeza sobre como copiar a configuração do CentOS - não tinha uma caixa à mão.

Mas quando eu olhei e li no PAM, tudo ficou no arquivo /etc/pam.d/common-account .

pam_unix.so estava acima de pam_ldap.so, e também tinha [success = 2 default = ignore], o que significa que se ele pular as próximas duas regras, e para qualquer outra coisa, ignore a linha.

Agora, como as contas LDAP são contas UNIX válidas, uma vez que adicionamos o ldap ao /etc/nsswitch.conf , esta regra retornará sucesso e o módulo pam_ldap.so nunca seja executado.

Para contornar isso, meu /etc/pam.d/common-account agora é assim:

# here are the per-package modules (the "Primary" block)
account [success=1 default=bad]  pam_succeed_if.so user ingroup auth-access quiet
account [success=reset default=bad]  pam_succeed_if.so uid <= 500 quiet
account [success=2 user_unknown=ignore default=ok]      pam_ldap.so
account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so
# here's the fallback if no module succeeds
account requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

Como você pode ver, também adicionei algumas regras para permitir que usuários no grupo LDAP "auth-access" ou usuários do sistema com UID abaixo de 500 sejam vistos como contas válidas.

E para explicar um pouco:

Nós atingimos a primeira regra

account [success=1 default=bad]  pam_succeed_if.so user ingroup auth-access quiet

O que é bem-sucedido se o usuário estiver nesse grupo e, em caso afirmativo, omitiremos a próxima linha que sabemos que falhará (ele é um usuário LDAP válido, portanto, não terá um UID do sistema abaixo de 500) - se não der certo, retorne uma falha (ruim).

Em seguida, a próxima regra, se não foi ignorada

account [success=reset default=bad]  pam_succeed_if.so uid <= 500 quiet

Portanto, se isso ocorrer (porque o UID está abaixo de 500), redefina o valor da falha definido pelo módulo acima, porque eles não farão parte desse grupo LDAP.

E a parte importante

account [success=2 user_unknown=ignore default=ok]      pam_ldap.so

Verifique se o servidor LDAP tem o status da conta - se for bem-sucedido, sabemos que um usuário LDAP é um usuário UNIX válido, portanto, siga em frente e pule as próximas duas linhas (para nos levar ao pam_permit.so e deixar o login do usuário) . Se o usuário é desconhecido para o servidor LDAP, ignore esta linha e vá para a próxima - e para todos os outros status, "ok" significa que está ok para passar esses códigos de retorno como está, o que irá passar coisas como senha expirada, etc .

E então:

account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so

Não somos um usuário LDAP válido se atingirmos essa regra, portanto, verifique se somos um usuário do sistema válido. Se for bem-sucedido, pule a próxima 1 linha (nos leva a pam_permit.so). Caso contrário, ignore, o que nos levará a pam_deny.so.

Espero que ajude a explicar um pouco mais - o documento que me ajudou, se não fui muito fácil de entender, foi: link

Atenciosamente, iamacarpet

    
por 11.08.2013 / 23:04