Nesta semana, na empresa em que trabalho, a equipe que administra as políticas de segurança do AD (MS Active Directory) atualizou as regras de segurança, aplicando a atualização obrigatória de senhas a cada 6 meses (para todas as contas). Em nossa equipe, voltada para infraestrutura de rede (firewall, proxy, roteamento e ativos de rede), o padrão tem sido trabalhar com Desktop Linux, sem integração direta com domínio. Obviamente, fomos afetados, pois nossas senhas expiraram.
Não integramos nossas estações porque entendemos que o único efeito prático e real seria possibilitar o acesso compartilhado das estações – algo que não desejamos. É evidente que as estações pertencem a empresa, mas lidamos com informação sensível e de acesso restrito. Logo, não faz o menor sentido – e nem seguro – “possibilitar” o acesso público ou compartilhado. Outra razão é que, em nosso ambiente, não existe suporte oficial para Desktop Linux. Com isto, nos responsabilizamos pelo funcionamento do sistema e aplicações que adotamos. Também personalizamos o ambiente segundo a nossa necessidade.
Resolvi explicar esta situação porque é um assunto que costuma ser questionado e mal compreendido. Futuramente, demonstrarei como integrar um servidor Linux ao domínio e alternativas de configuração (raramente a integração precisa ser total).
Fomos afetados também porque a navegação é controlada por servidores Proxy Squid (que administramos) com autenticação baseada no AD (métodos NEGOTIATE, NTLM e Basic) e o comunicador interno é o MS Lync, por exemplo. Inicialmente, perdemos o acesso.
Alguns colegas de trabalho optaram por acessar um Desktop Windows e solicitar a troca da senha. Porém, como o procedimento será periódico, preferi optar por alguma solução nativa no Linux, sem precisar ajustar a configuração de nosso Desktop.
O primeiro link que encontrei foi:
https://lists.samba.org/archive/samba/2015-April/190903.html
As dicas são interessantes, mas também recebi uma resposta “LANMAN password changes are disabled” para o comando smbpasswd -U <usuário>.
Em seguida, a partir de um dos proxies, tentei alterar minha senha com a ferramenta samba-tool:
root@proxyn:~# samba-tool user password -U <usuário> -W <domínio> Password for [<domínio>\<usuário>]: New Password: Retype Password: ERROR: Failed to change password : samr_ChangePasswordUser3 for '<domínio>\<usuário>' failed: NT_STATUS_PASSWORD_RESTRICTION
Solicitei a troca de senha através do proxy para aproveitar a configuração do Samba. De acordo com a resposta do servidor, entendi que são eventos distintos. Ou seja, solicitei a troca de senha para uma conta com senha expirada. Seguindo o thread da lista de discussão do Samba é possível perceber que a senha pode ser trocada com o comando kpasswd.
Ainda assim, ao tentar validar minha conta diretamente via Kerberos, o sistema detectou que a senha havia expirado e possibilitou a troca! 😉
Funcionou com o comando kinit <usuário>@<realm>
Simples!
Caro, autor do artigo….entendi tudo que vc escreveu, mas somente uma coisa não consegui entender do que se trata “realm” no comando kinit @
O realm é uma representação kerberos do seu sufixo de pequisa (domínio de rede).
É sensitivo ao caso – normalmente expresso em maiúsculo.
Se o seu sufixo de pesquisa DNS for domain.local, normalmente o seu realm será DOMAIN.LOCAL.