Instalando no Servidor ou Estação de Administração

Antes de iniciar a instalação do LAPS, você deve definir se todos os computadores do seu domínio irão gerenciar as senhas de imediato (ou se você prefere criar uma OU piloto e migrar a solução para todos), e definir também, quem deve ter permissão de leitura dos atributos do AD (de preferência criar um grupo para isso).
O LAPS pode ser instalado em qualquer domino 2003 ou superior com .net framework 4 (recomendo também o Powershell v4 ou superior, ou Powershell v2 com suporte a assembly de .net v4). O setup pode ser baixado nesse link e a instalação é simples, dividido entre o pacote de gerenciamento (UI, Templates e Powershell) e a extensão da GPO, que deve ser instalada em todas as estações como veremos mais a diante.
O setup é Next, Next, Finish. Se você quiser instalar o módulo de gerenciamento, que vamos ver mais tarde, em outras estações de trabalho (do time de Help Desk, por exemplo) é só selecionar o módulo correspondente.

Após a instalação, a Interface fica instalada por padrão em: %Program Files%\LAPS.
A extensão da GPO fica instalada em: %ProgramFiles%\LAPS\CSE\AdmPwd.dll
Os policy templates ficam instalados, por padrão, em:

%WINDIR%\PolicyDefinitions\AdmPwd.admx, e
%WINDIR%\PolicyDefinitions\en-US\AdmPwd.adml.

Existem métodos de instalação manual nos clientes registrando a dll, que não vou entrar em detalhes, porque está bem coberto no manual.

Estendendo o Schema

Após a instalação do LAPS, o próximo passo é a extensão do schema do AD, para que os novos atributos possam ser utilizados pelo LAPS. Esses novos atributos são:

ms-Mcs-AdmPwd – Campo para senha em texto claro.
ms-Mcs-AdmPwdExpirationTime – Campo para armazenar a duração da senha

Uma curiosidade sobre o campo ExpirationTime, é que ele registra o tempo em intervalo de 100 nano segundos, contando a partir do 01/01/1601. Para estender o schema, abra uma sessão do Powershell e digite o comando:

Obs.: Apesar da documentação dizer que a versão mínima do Powershell é a 2.0, recomendo a atualização para a última (Management Framework 5.0), pois eu tive problemas com versões de assembly desatualizadas, que depois eu descobri que precisa configurar algumas opções do Powershell para funcionar (precisa permitir o Powershell 2.0 carregar o .NET 4).
O próximo comando é Update-AdmPwdADSchema

Olhando o output do comando, percebemos que foram criados dois novos atributos. 

Obs.: Se você tem RODC instalado no seu ambiente, dê uma lida em http://technet.microsoft.com/en-us/library/cc754794(v=WS.10).aspx

Removendo permissões de visualização desnecessárias

O próximo passo é permitir somente determinados grupos a terem permissão de leitura dos atributos de senha do AD. De nada adianta implementar o LAPS, se todos os usuários podem ver a senha, não é mesmo?
Usando o ADSIEdit, vamos modificar as permissões da OU, onde estão os nossos computadores gerenciados.
Escolha a OU que deseja modificar (se for usar mais de uma OU, você deverá repetir o processo em todas elas)
Vá em propriedades, Security e depois em advanced.
Selecione o Grupo que você NÃO quer que tenha permissão para ver as senhas.
Desmarque a opção All extended Rights (se não estiver marcado o grupo, significa que ele já não tem permissão para ver)

Dica: para ver quem, atualmente, tem permissão para ler os atributos de senha, é possível usar o modulo AdmPwd.ps:

Adicionando permissões de computador para escrever sua senha e data de expiração

Cada computador precisa ter permissão para escrever a sua senha e atualizar a sua data de expiração da senha. Isso é feito alterando a permissão da conta SELF. Vamos fazer isso via Powershell:

Set-AdmPwdComputerSelfPermission -OrgUnit “<Nome da OU>”

Adicionando Grupos para acesso aos atributos

Agora, vamos adicionar os grupos que terão acesso à leitura dos atributos da OU (no meu caso será o grupo HelpDesk Team)

Set-AdmPwdReadPasswordPermission -OrgUnit “<Nome da OU>” -AllowedPrincipals “<nome do usuário ou grupo (separados por vírgula) >”

Uma das funções do LAPS é a opção de o usuário credenciado forçar a troca de senha da estação de trabalho. Essa opção é concedida através do seguinte comando:

Set-AdmPwdResetPasswordPermission -OrgUnit “<Nome da OU>” -AllowedPrincipals “<nome do usuário ou grupo (separados por vírgula) >”

Criação da GPO e deploy para as estações de trabalho

O próximo passo, é criar uma GPO com o Template disponibilizado durante o setup e linkar com a(s) GPO(s) que iremos usar.
Editando a GPO, que no meu caso, é a mesma, temos um novo Template chamado LAPS:

São 4 configurações possíveis:

  • Enable local admin password management: Habilita ou não o gerenciamento de senha; deve ser habilitado para iniciar o gerenciamento.
  • Password settings: Define como será a complexidade de senha e prazo de expiração. Por padrão, a complexidade de senha está na configuração máxima (14 caracteres com Maiúsculas, Minúsculas, Números e Caracteres Especiais com expiração de 30 dias). Você pode alterar essas configurações conforme as necessidades, mas eu recomendo manter esse padrão.
  •  Name of administrator account to manage: Se você criou uma nova conta de administrador local nas estações de trabalho e DESABILITOU o usuário administrador padrão, informe neste campo o nome da nova conta de administrador. Atenção, NÃO habilite esta opção se você usa o administrador padrão ou se RENOMEOU a conta de administrador padrão, pois o LAPS usa o SID padrão do administrador, que não muda se renomearmos a conta.
  • Do not allow password expiration time longer than required by policy: Essa opção detecta se uma estação de trabalho está com data de expiração de senha superior ao definido no password settings (algum desavisado com permissão pode ir no AD e colocar a expiração de senha de uma determinada estação de trabalho para 365 dias, por exemplo). Caso seja identificado data de expiração superior ao definido no password settings (padrão 30 dias), a GPO automaticamente troca a senha da estação de trabalho e altera o campo da expiração de senha para o valor correto. 

Após a configuração das opções, linkamos a GPO à OU desejada e movemos as estações de trabalho que serão gerenciadas para a nova OU.

Instalação do módulo de extensão da GPO

 

Por fim, precisamos instalar o módulo de extensão da GPO, que será responsável por escrever as propriedades do Objeto no AD. A instalação pode ser feita via GPO, via script, via SCCM ou a sua solução de gerenciamento preferida ou manualmente. Vou fazer a instalação via GPO, que é a mais rápida de se fazer:
Edite a mesma GPO que você usou para criar as configurações e configure um novo deploy de aplicação:

Quando os clientes atualizarem suas políticas, a extensão será instalada automaticamente, podendo ser validada no Add/Remove Programs:

Depois do primeiro reboot após a instalação, a senha já é configurada no Objeto do AD:

Para facilitar a vida do seu time de HelpDesk e a sua também, a Microsoft criou uma UI bem prática, que mostra a senha da estação de trabalho sem ter que procurar o atributo do AD:

– E se um usuário espertinho tentar ver a senha sem ter o acesso?

Bom, a senha não aparece para ele:

– E se o usuário tentar ler o atributo via Console do AD ou Powershell?

O valor aparece como <not defined>.

Troubleshooting, log e audit

Se você seguiu todos os passos até aqui e não funcionou de primeira, não se preocupe, o LAPS possui logs para troubleshooting:
Event Viewer: O LAPS registra suas atividades no Application Log da estação de trabalho. Por padrão, somente erros são registrados, mas é possível alterar o nível de log dos eventos:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA}\ExtensionDebugLevel

0 Somente Erros, 1 Warning e Erros, 2 Verbose (registra tudo)

Verifique se você configurou as permissões da OU, senão erros de escrita na OU irão aparecer no Event log
Verifique se a extensão da GPO foi instalada corretamente, via painel de controle e consultando a chave de registro da extensão da GPO:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA}

Verifique também, se a Objeto do computador está na OU correta
Se você precisar auditar os acessos à leitura de senha dos objetos do AD, basta habilitar via powershell:

Após isso, todo novo acesso é registrado no Event Security do AD: