Usuário do console bloqueado - problemas de pam?

Question

Estou tentando habilitar a autenticação AD para servidores Debian estáveis para permitir que os usuários efetuem logon via autenticação ssh no Windows AD. Tudo funciona bem e eu posso ssh para o servidor usando minhas credenciais do Windows, mas tenho notado esta mensagem no logon ssh remoto ao fazer logon como root:

Your account has been locked. Please contact your System administrator
Your account has been locked. Please contact your System administrator
Your account has been locked. Please contact your System administrator
Last login: Sat Jun 13 14:15:14 2009 from workstation1
server1:~#

Verifiquei se consigo fazer login via console local como root e oops, não consigo. O mesmo erro aparece. Isso poderia me chutar dolorosamente no futuro. Ao mesmo tempo, tentei a mesma configuração para o RedfHat e não tenho esse problema. Eu acredito que o problema está em algum lugar na minha configuração de pam, mas não consigo ver onde.googling por erro não me leva a lugar nenhum.

Abaixo estão os detalhes dos arquivos pam correspondentes no Debian e no redhat ...

Versão do Debian

conta comum

account sufficient      pam_winbind.so require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX
account sufficient      pam_winbind.so require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX
account sufficient      pam_winbind.so require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX
account required    pam_unix.so

common-auth

auth    sufficient      pam_winbind.so require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX
auth    sufficient      pam_winbind.so require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX
auth    sufficient      pam_winbind.so require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX
auth    required    pam_unix.so nullok_secure

sessão comum

session required        pam_mkhomedir.so skel=/etc/skel/ umask=0022
session sufficient      pam_winbind.so  require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX 
session sufficient      pam_winbind.so require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX
session sufficient      pam_winbind.so require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXX
session required    pam_unix.so

Arquivo de autenticação do sistema RedHat:

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        sufficient    pam_winbind.so use_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     sufficient    pam_winbind.so use_first_pass
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_winbind.so use_first_pass
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     required      pam_winbind.so    use_first_pass
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_mkhomedir.so skel=etc/skel/ umask=0027

/etc/pam.d/sshd

# PAM configuration for the Secure Shell service

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
auth       required     pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
auth       required     pam_env.so envfile=/etc/default/locale

# Standard Un*x authentication.
@include common-auth

# Disallow non-root logins when /etc/nologin exists.
account    required     pam_nologin.so

# Uncomment and edit /etc/security/access.conf if you need to set complex
# access limits that are hard to express in sshd_config.
# account  required     pam_access.so

# Standard Un*x authorization.
@include common-account

# Standard Un*x session setup and teardown.
@include common-session

# Print the message of the day upon successful login.
session    optional     pam_motd.so # [1]

# Print the status of the user's mailbox upon successful login.
session    optional     pam_mail.so standard noenv # [1]

# Set up user limits from /etc/security/limits.conf.
session    required     pam_limits.so

# Set up SELinux capabilities (need modified pam)
# session  required     pam_selinux.so multiple

# Standard Un*x password updating.
@include common-password

    

Answer 1

Pelo amor de $ {Diety}, não ajuste as common-* partes da pilha do PAM ao experimentar uma nova configuração de autenticação. É a maneira mais rápida e fácil de fazer Hole Hawg . Você poderia se desligar do sistema permanentemente por causa de um cenário de ovo e galinha: você está bloqueado para fora do sistema, mas precisa fazer login no sistema para fazer as alterações necessárias para evitar você seja bloqueado.

Considere experimentar em um único serviço, como o SSH (supondo que você tenha acesso ao console por perto). Depois de ter o serviço criado / configurado de acordo com seus requisitos exatos, não o aplique imediatamente nos arquivos common-* , em vez disso, considere o impacto que ele terá em outros serviços do sistema. Lembre-se, common-* age como um "pega-tudo" para a maioria das configurações e um único erro aqui significa uma visita ao CD de resgate para desbloqueá-lo novamente. Uma vez que você tenha uma boa noção de como a configuração irá interagir com diferentes serviços que dependem do (s) padrão (ões) do sistema, então aplique-a.

Outro ponto a ser considerado é que, se você estiver fazendo essa alteração em common-* para facilitar o SSO para todos os serviços na caixa, ele não capturará todos os serviços, alguns serviços terão sua própria configuração de autenticação e você precisará verificar isso também.

No que diz respeito às mensagens do console, o que aconteceu é que o winbind está entrando em contato com o controlador do AD, que está vendo tentativas excessivas de login com falha. Depois de 15 tentativas (que, acredito, é o número out-of-box que a MS usa), a conta é bloqueada por um período de tempo, a menos que um administrador desbloqueie a conta. É por isso que você está recebendo mensagens de "conta bloqueada" quando efetua login - a parte winbind de sua pilha está falhando nas tentativas de autenticação, e o processo "cai" na próxima etapa da pilha.

Eu ficaria muito preocupado com as configurações do seu winbind para determinar se a autenticação é realmente bem-sucedida, em primeiro lugar. Se você estiver enviando credenciais de um membro do domínio que o controlador AD não gosta, não importa se a senha está correta ou não - mais cedo ou mais tarde, a conta será bloqueada porque a solicitação é originária do que é percebido como um não membro do domínio. A primeira coisa a verificar seria a junção do winbind ao domínio, pois isso afetará se as credenciais forem analisadas. Eu também verificaria como sua conta administrativa é gerenciada pelo winbind - parece que lembro que havia uma ou duas configurações adicionais necessárias para garantir o comportamento adequado (vou desenterrá-las e reeditar quando eu as tiver ... )

Eu também recomendaria a configuração de uma senha secundária na caixa linux local, usando /etc/passwd , para que você tenha uma autenticação "fail-even". Se o serviço winbind não conseguir autenticar (e neste caso) /etc/passwd irá recolher a folga e permitir-lhe entrar. O facto de ainda poder entrar parece indicar que já o fez por definindo a senha local da mesma forma que a senha do AD para a conta que você está usando.

Considere também a instalação de outra válvula de segurança na forma de uma entrada sudo, para que uma única conta específica permita que você mude para a raiz via sudo su .