PAM Winbind expirou a senha

2

Temos a configuração do Winbind / Kerberos no RHEL para autenticação do AD. Trabalhando bem, no entanto, notei que quando uma senha expirou, recebemos um aviso, mas o acesso ao shell ainda é concedido.

Qual é a maneira correta de lidar com isso? Podemos dizer ao PAM para fechar a sessão assim que a senha expirar?

Exemplo:

login as: ad-user
[email protected]'s password:
Warning: password has expired.
[ad-user@server ~]$ 

Conteúdo do /etc/pam.d/system-auth:

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_krb5.so use_first_pass
auth        sufficient    pam_winbind.so use_first_pass
auth        required      pam_deny.so

account     [default=2 success=ignore] pam_succeed_if.so quiet uid >= 10000000
account     sufficient    pam_succeed_if.so user ingroup AD_Admins debug
account     requisite     pam_succeed_if.so user ingroup AD_Developers debug
account     required      pam_access.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_krb5.so
account     [default=bad success=ok user_unknown=ignore] pam_winbind.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_krb5.so use_authtok
password    sufficient    pam_winbind.so use_authtok
password    required      pam_deny.so

session     [default=2 success=ignore] pam_succeed_if.so quiet uid >= 10000000
session     sufficient    pam_succeed_if.so user ingroup AD_Admins debug
session     requisite     pam_succeed_if.so user ingroup AD_Developers debug
session     optional      pam_mkhomedir.so umask=0077 skel=/etc/skel
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_krb5.so
    
por kernelpanic 07.11.2013 / 17:55

1 resposta

0

Precisamos saber o numérico uid do usuário que você está registrando para saber com certeza. O que segue é especulação.

Bloqueios de autorização geralmente acontecem dentro da pilha account , então vamos começar olhando lá. Entradas que terminam a pilha do módulo são imediatamente suspeitas. Eu não vejo done em qualquer lugar aqui, então as linhas com sufficient são as que precisamos focar. Isso nos permite focar nessas linhas no topo da pilha:

account     [default=2 success=ignore] pam_succeed_if.so quiet uid >= 10000000
account     sufficient    pam_succeed_if.so user ingroup AD_Admins debug
account     requisite     pam_succeed_if.so user ingroup AD_Developers debug
account     required      pam_access.so
account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
  • Se o uid numérico for < = 10000000 e um membro do grupo AD_Admins, a pilha da conta será encerrada com a linha de sucesso 2.
  • Se o usuário tiver uma entrada em /etc/passwd além do LDAP, a pilha da conta será encerrada com êxito na linha 6.
  • Se o uid numérico for < 500, a pilha da conta terminará com sucesso na linha 7. (isso provavelmente não é o culpado devido à sua verificação de > = 500 na pilha auth )

Todos os cenários acima resultarão na conclusão da pilha da conta antes das verificações contábeis de pam_krb5.so e pam_windbind.so .

    
por 08.11.2013 / 02:06

Tags