Início > Active Directory Modules for Windows Powershell, Windows PowerShell > PoSh – Como criar/renomear/alterar a senha de uma conta de usuário local remotamente

PoSh – Como criar/renomear/alterar a senha de uma conta de usuário local remotamente

fevereiro 18, 2016

Olá pessoALL,

Hoje nós vamos falar sobre um processo que pode ser necessário no dia a dia de quem cuida de estações de usuários e até mesmo servidores, mas que não é tão prático mesmo usando PowerShell por não existir um command let até o momento para esta necessidade: a criação de objetos locais como uma conta de usuário.

Quero informar também que nos posts relacionados a Windows PowerShell eu irei deixar de colocar códigos substituindo-os por imagens. O motivo é simples e único: não se aprende uma linguagem sem praticar e principalmente sem digitar os códigos!

Meu objetivo é incentivar o uso desta nova linguagem, forçar literalmente quem tem e quem não tem interesse em aprender o uso deste recurso poderoso no dia sem limitar-se a pesquisas no google e tomar este tipo de ação somente em casos onde o conhecimento realmente acabou.

Portanto, say good bye to copy and paste and welcome to the real world right now!

Introdução

Em nosso dia a dia é comum automatizarmos tarefas para ganharmos tempo e agilidade como resposta a determinados eventos, demandas, etc. O uso de PowerShell ou qualquer outro tipo de linguagem para produzir uma automação é um grande passo para melhorarmos nossa rotina de trabalho.

Iniciar um serviço, interromper um processo, apagar um arquivo entre outras necessidades podem se tornar tarefas diárias e executa-las manualmente pode ser uma ação dispendiosa. Então, é natural que você comece a pensar em automatizar uma tarefa diária e prevista.

O cenário

Vamos imaginar que o nosso cenário é composto por vários servidores/computadores membros e que não há uma ferramenta de automação e gerenciamento de senhas como Microsoft LAPS, SCCM, etc.

Vamos assumir também que por questões de segurança você precisa renomear e alterar a senha da conta built-in de todos os servidores/computadores membros do domínio.

Entenda “vários servidores/computadores membros” como algo acima de uma centena. Executar uma tarefa como esta manualmente poderia levar um tempo considerável e consumir mão de obra que você poderia estar dedicando a operações que realmente precisam ser feitas individualmente.

Automatizar este tipo de operação pode ser a resposta para otimizar o tempo e também a chave para criar até mesmo um mecanismo de troca de senha periódico para mitigar o risco de alguém descobrir a senha da conta built-in.

Mesmo sendo uma boa prática, muitas empresas ainda não usam uma abordagem como a oferecida pelo Microsoft LAPS para assegurar que o comprometimento de uma estação de trabalho não gere o comprometimento de todos as outras.

Ao longo dos anos em que eu venho atuando no mercado de IT eu vi e continuo vendo poucas empresas seguindo este tipo de boa prática e o que mais encontramos são contas de usuário locais com a mesma senha e contas não renomeadas.

Voltando ao foco deste post, seu time de segurança identificou vulnerabilidades e solicitou a você a alteração do nome da conta administrator para outro nome determinado internamente e que a senha de cada conta seja única.

Por uma questão técnica, processual, de tempo ou qualquer outra, você fica impossibilitado de implementar o Microsoft LAPS que você encontrou pesquisando sobre o assunto e você precisa de algo rápido e que lhe garanta tempo para poder se sentir confortável para implementar uma solução como Microsoft LAPS.

É aqui que o Microsoft Windows PowerShell pode te ajudar se você souber como utiliza-lo a seu favor.

A solução

Para iniciarmos a construção da nossa solução alternativa baseada em PowerShell para o Microsoft LAPS, precisamos ter em mente que não há um command let próprio para manipularmos contas de usuários e grupos locais.

Para ser possível esta ação, será necessário utilizar um método de conexão via ADSI para manipularmos os objetos de conta de usuário remotamente para o que desejamos – criar, alterar e redefinir a senha.

Um requisito para que nossa solução funcione perfeitamente é ter a regra Windows Management Instrumentation (WMI) habilitada no Windows Firewall dos clientes, pois sem esta exceção, parte do processo irá falhar e você receberá a mensagem de RPC Server is unavailable.

O processo de criação de um conta de usuário é extremamente simples e parecido com o usado em VBScript. O código abaixo faz a criação de um usuário chamado ServiceDesk e atribui a senha P@$$w0rd em um computador chamado USNYC001-W0001:

PoSh-CreateLocalUserOnRemoteComputer0001

Como podemos ver na imagem anterior, o processo de criação de usuário é simples. Agora, vamos ver como é possível renomear a conta ServiceDesk para WKSAdmin na próxima imagem de código:

PoSh-CreateLocalUserOnRemoteComputer0002

Na imagem acima nós utilizamos outro meio. No lugar do ADSI foi utilizada uma classe WMI chamada Win32_UserAccount para se conectar ao computador USNYC001-W0001 e renomear o objeto ServiceDesk encontrado usando o método Rename da classe.

Por fim, vamos ver como é possível alterar a senha de uma conta existente usando ADSI:

PoSh-CreateLocalUserOnRemoteComputer0003

Como pode ver na imagem anterior, o processo de redefinir a senha de uma conta de usuário local é semelhante ao de criação com apenas algumas diferenças sutis como o objeto de conexão e o método SetPassword.

Já sabemos o que precisamos saber para criarmos nosso LAPS particular, mas ainda falta a lógica, então, vamos assumir neste momento que você tenha um domínio e que todas as estações de trabalho estejam em uma estrutura de OUs organizada. Não vamos pensar em servidores neste momento, mas em resolver a demanda.

Vamos supor que os computadores que serão alvos da ação estão localizados dentro abaixo da OU OU=COMPUTERS,OU=NA,OU=NSFW_CORP,DC=nosafeforwork,DC=net, então para listarmos os objetos que precisamos, vamos usar o command let Get-ADComputer.

O resultado do command let Get-ADComputer será armazenado em uma variável e se houver conteúdo nesta variável, verificará se a conta administrator existe, caso sim, renomeia a conta para WKSAdmin e em seguida, altera a senha da conta, caso não, subentendesse que a conta já possui o nome correto e somente altera a senha da conta WKSAdmin.

Parece ser fácil falando, mas também é fácil de se fazer em código:

PoSh-CreateLocalUserOnRemoteComputer0004

O código acima atende ao que o time de segurança pediu, mas, temos dois problemas aqui:

  1. estamos usando o nome da conta e infelizmente, há empresas que não usam o idioma do sistema operacional em estações de trabalho em inglês.
  2. a senha está definida (hard coded) no código e o objetivo é que cada estação tenha uma senha individual.

Como resolver ambos os problemas? Para resolvermos a primeira questão, nós vamos utilizar um atributo que possui dois conjuntos de informações imutáveis, não importa o idioma do sistema operacional, o SID. O SID de uma conta built-in é composto por S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-500.

Resumindo, temos dois conjuntos de dados S-1-5-21- e -500 que serão encontrados somente na conta built-in em qualquer sistema operacional. Sabemos o começo e o final da string que forma o SID, mas como obter o restante dos três conjuntos de números aleatórios que completa o SID?

Neste tipo de situação, nós vamos resolver isso com expressões regulares ou RegEx! Usando uma expressão regular eu irei validar o inicio e o fim da string, não importando o que há nos três conjuntos numéricos. Se a string for composta por S-1-5-21-QualquerConjunto-QualquerConjunto-QualquerConjunto-500, ela será verdadeira.

Para conseguirmos este resultado usando um expressão regular, tudo o que precisamos fazer é:

S-1-5-21-\d+\-\d+\-\d+\-500

A expressão acima verifica se o resultado combina ou não com a expressão regular. \d+ indica um ou mais números seguidos de hífen (\-). Precisamos também garantir que a conta encontrada é a conta local e não a conta de domínio caso exista.

Para diferenciarmos as contas, vamos usar o atributo Domain que possui o nome do computador local como valor para a conta local. Portanto, vamos substituir o código como mostrado na imagem a seguir.

PoSh-CreateLocalUserOnRemoteComputer0005

Já temos a solução para a questão relacionada ao nome da conta built-in, agora resta a senha individual.

Quando estamos falando de geração de senhas com PowerShell, há algumas abordagens simples e outras bem mais robustas. Um abordagem simples seria o uso de um método – [System.Web.Security.Membership]::GeneratePassword() – encontrado na classe .NET [System.Web].

O único problema desta solução rápida é a validação de complexidade, pois não há como garantir que o resultado do método atenda a política de senha atual do domínio onde a alteração de senha será feita.

Há métodos bem mais complexos para gerar uma senha que atenda ao requisitos de complexidade, scripts disponíveis na Internet, etc. e abaixo está a minha solução para criarmos uma senha que atenda a seguinte necessidade:

  • comprimento de senha de 15 caracteres;
  • pelo menos 1 número na senha;
  • pelo menos 1 ou 9 letras minusculas;
  • pelo menos 1 letra maiúscula;
  • pelo menos 1 caractere especial.

PoSh-CreateLocalUserOnRemoteComputer0006

O código acima cria uma senha baseada em todas as letras do alfabeto (minúsculas e maiúsculas), números (0 à 9) e com caracteres especiais definidos na string abcdefghiklmnprstuvwxyzABCDEFGHKLMNPRSTUVWXYZ1234567890!@#%&*-+;:, com o comprimento de 15 caracteres.

Em seguida são feitas validações da senha criada pela função para verificar se ela atende aos requisitos de complexidade já informados anteriormente. Enquanto a senha não atender a todas as condições, ela não é retornada pela função.

Em resumo, eu criei um gerador de senhas complexas simples com PowerShell. Pretty cool, huh? This is the PoSh Guy, you know!?

O resultado da união destes recursos está na imagem abaixo:

PoSh-CreateLocalUserOnRemoteComputer0007

Estamos chegando quase no final. Mas ainda falta alguma coisa? Sim! Perceba que até agora não há uma forma de saber qual senha foi atribuída a conta built-in e nós precisamos desta informação para acessar o sistema operacional usando a conta WKSAdmin posteriormente.

Então para concluirmos vamos inserir uma simples linha que irá criar um arquivo CSV contendo o nome do computador e a senha que foi atribuída a conta WKSAdmin no processo. Para isto vamos utilizar o command let Add-Content como solução para:

  • criar um arquivo de nome WorkStations_dd_MM_yyyy-hh_mm_ss.txt;
  • adicionar o nome do computador e a senha atribuída a conta WKSAdmin

Abaixo está o resultado final do nosso script de gerenciamento de conformidade para a conta local built-in em nossas estações de trabalho:

PoSh-CreateLocalUserOnRemoteComputer0008

Conclusão

Neste post nós aprendemos como construir nossa própria solução de gerenciamento de senhas para estações de trabalho usando Windows PowerShell como base para realizarmos nossa atividade.

De uma forma bem simples de se adaptar, o script irá verificar todas as contas de computadores existentes em seu domínio com base em uma OU, consultar se a conta built-in possui não possui o nome padrão, neste caso WKSAdmin, renomear se necessário e então atribuir uma senha aleatória e complexa.

Como bônus, para consultar o arquivo criado de forma rápida via Windows PowerShell para localizar a senha de um computador específico, use o seguinte comando como mostrado na imagem abaixo:

PoSh-CreateLocalUserOnRemoteComputer0009

That’s it folks! Até o próximo tópico…

%d blogueiros gostam disto: