Faaala galera, 100%?!
Quem nunca esqueceu a senha do admin local de uma estação?! Quem nunca já teve a senha de administrador local vazada em algum momento!? Isso já rolou comigo e tenho certeza que também já aconteceu contigo! Além desse fator o gerenciamento de usuários locais com permissões administrativas é um belo desafio para qualquer administrador de redes por conta da sensibilidade desse acesso. Por boa prática de segurança, cada estação deveria ter uma senha única, mas…venhamos e convenhamos, não é tão simples assim!
Pensando nisso, a Microsoft lançou lá em 2015 um recurso chamado LAPS (Local Administrator Password Management). Esse recurso é pouquíssimo utilizado (ao menos em minha breve pesquisa nenhum, das 10 pessoas que perguntei, utilizam a solução). A função desse cara é facilitar sua vida em relação ao gerenciamento de credenciais locais e garantir que não exista UMA única senha padrão para o usuário administrador local das estações de seu ambiente.
“Blz Nathan, mas e ai, eu terei de documentar 1 senha para cada computador em minha rede?!” – Calm down, padawan!!!!
Como comentei acima o LAPS facilita sua vida e todo o gerenciamento das senhas fica a cargo e documentado no AD!!! SIM, no AD! Ao realizar a instalação e configuração do recurso dois campos são adicionados ao Schema do AD e, em um deles, a senha do administrador local estará disponível. Além disso existe a questão da alteração periódica dessas senhas garantindo assim mais proteção ainda para seu ambiente!
“Ok, mas qual seria o risco de manter uma única senha para o admin local das estações?!”
Simples, se um computador for comprometido, todas as demais estações serão! Com o LAPS isso não aconteceria, visto que cada estação terá uma senha única, randomicamente gerada!
Como funciona?!
O funcionamento do LAPS é simples, a princípio. O AD, como centralizador de gerenciamento de credenciais, passa ter um atributo específico nas contas de computador onde a senha e o tempo de vida da senha local serão controlados. Como “core” dessa solução temos uma DLL que deve ser registrado no lado do computador cliente, possibilitando esse controle a partir do AD.
Do lado do servidor, temos apenas a expansão do Schema do AD contendo os campos que citei acima, o ms-Mcs-AdmPwd e ms-Mcs-AdmPwdExpirationTime. Esses dois campos vão dizer a senha e o tempo que ela ainda tem de vida. Do lado cliente é instalado um agent ou registrada uma dll para que esse tipo de comunicação ocorra.
De forma bem simplificada, o que acontece é:
- Com a nova extensão e GPO no lado do servidor o cliente recebe a informação de que agora a senha será gerenciada pelo AD (Lembrando que o cliente deve ter o lado dele configurado seja por instalação do agente.msi ou registro da dll).
- O cliente verifica que existem alterações e passa a respeita-la.
- De tempo em tempo a verificação dos atributos é realizada e, se o tempo de senha tiver expirado, uma nova credencial é gerada e o cliente consulta e atribui a nova senha ao administrador
Provavelmente você deve estar se perguntando como essa senha viaja de uma ponta a outra! Simples, tudo é feita via Kerberos, com encriptação padrão do AD.
Olha a figurinha ai pra facilitar o entendimento;
O que vou ganhar com isso? (Resumão)
- Segurança
- Senhas geradas de forma aleatória e com tempo de vida
- Mitigação de ataques PtH (Pass-the-hash)
- Armazenamento das credenciais feitas em atributos do AD que podem ter ACL granular
- Transporte de credenciais utilizando Kerberos
- Gerenciamento
- Gerenciamento de tempo, complexidade e comprimento de senha local
- Possibilidade de forçar o reset da senha local via AD
- Proteção contra deleção de conta de computador
- GUI e PowerShell cmdlets para gerenciamento facilitado
- Implantação SUPER simples
O que preciso para fazer tudo isso funcionar?
- AD acima do 2003
- Clientes acima do Windows XP
- Powershell acima do 2.0
- .NET Framework 4.0
E a instalação?!
Então, essa parte vai ficar para o próximo artigo! Nele vou mostrar o passo a passo para instalação da solução e obviamente alguns testes!
Espero que tenha te mostrado algo novo e que tenha curtido! Até o próximo artigo!
Grande abraço! \,,/
Muito legal essa matéria.
Fiquei com dúvida em uma coisa, é possível definir que somente um grupo de usuários X poderá acessar um grupo de máquinas X?
Tipo assim, máquinas de usuários vips(diretoria) quero que somente um número reduzido de analistas tenham acesso para dar suporte.
Olá Heloiza, como vai?
Não, esse tipo de controle ainda não existe.
Abraço
Ola Nathan Boa Noite
Excelente artigo!
Essa solução também é usada ou recomendada para gerenciar as senhas de contas locais(administrador) em servidores membros do domínio? Se essa não servir qual melhor prática adotar?
Abraço
Olá Valério, como vai?
Sim, desde que seu servidor não seja um DC conseguirá utilizar essa solução.
Abraço
Obrigado Nathan!!
Muito bom o artigo Nathan.
Abs.
José Carlos
Agradeço e visita José!