Início > Active Directory, Directory Services, DNS, Windows Server, Windows Server 2003/R2, Windows Server 2008/R2, Windows Server 2012/R2 > Active Directory – Monitorando o uso de um controlador de domínio antes de decomissioná-lo

Active Directory – Monitorando o uso de um controlador de domínio antes de decomissioná-lo

julho 27, 2014

Olá pessoALL,

Hoje eu vou falar um pouco sobre um processo muito importante no ciclo de vida de um controlador de domínio. O seu decomissionamento.

Para quem não conhece o termo “decomissionar”, abaixo está uma breve explicação sobre o significado do termo comissionar:

Comissionar: Define-se como o conjunto de técnicas e procedimentos de engenharia aplicados de forma integrada a uma unidade ou planta industrial, visando torná-la operacional, dentro dos requisitos de desempenho especificados em projeto. Seu objetivo central é assegurar a transferência da unidade industrial do construtor para o operador de forma ordenada e segura, certificando a sua operabilidade em termos de segurança, desempenho, confiabilidade e rastreabilidade de informações.

Da mesma forma que em um processo de engenharia, comissionar um controlador de domínio significa seguir um conjunto de técnicas e procedimentos que garantem sua completa operabilidade ao ser colocado em ambiente de produção.

Sabendo o que significa o processo de comissionar, decomissionar um controlador de domínio significa seguir um conjunto de técnicas e procedimentos que garantem sua completa inoperabilidade ao ser retirado do ambiente de produção sem que nenhum impacto seja gerado.

Pode parecer trivial o processo, mas não se engane com esta falsa sensação de segurança, pois decomissionar um controlador de domínio requer muita atenção e um processo de avaliação para identificar se há ou não recursos utilizando-o.

Por experiência profissional, poucas pessoas possuem um processo de decomissionamento de controladores de domínio bem elaborado, seja por completo desconhecimento, seja por completa negligência, etc.

Pensando neste tipo de situação eu resolvi escrever este post para esclarecer alguns pontos e mostrar o que é preciso ser feito para se obter as informações necessárias para se realizar um decomissionamento seguro de um controlador de domínio.

Antes de prosseguirmos, vamos entender o que pode levar o decomissionamento de um controlador de domínio.

É natural a migração de controladores de domínio para novos servidores, seja pelo fim do ciclo de vida do hardware atual, seja por limitações de hardware, etc.

Não será sempre que um controlador de domínio será mantido em conjunto com o novo, mesmo sendo uma boa prática ter ao menos 2 controladores de domínio para garantir que não existe um único ponto de falha para os serviços de diretório.

Comumente, novos controladores de domínio são inseridos com nomes e endereços IP diferentes dos atuais que atendem as solicitações dos clientes do serviço de diretório. Da mesma forma como o processo de decomissionamento, inserir um novo controlador de domínio e desligar o atual pode parecer trivial, mas não é.

Por que o processo de decomissionamento de um controlador de domínio requer atenção e um processo bem estruturado?

Falando de forma geral, pois este tipo de procedimento dever ser seguido para qualquer dispositivo que seja decomissionado, antes de indisponibilizar um determinado dispositivo você precisa garantir que ele não está recebendo nenhuma demanda de trabalho para as funções/serviços que ele oferece.

Agora, falando especificamente de um controlador de domínio, você precisa garantir que o mesmo não está sendo usado por nenhuma aplicação e/ou recebendo solicitações para os serviços que ele suporta, como por exemplo, consultas para o serviço de resolução de nomes (DNS).

Você precisa verificar e garantir que as FSMOs do controlador de domínio atual sejam movidas para o novo controlador de domínio antes de desligá-lo se o mesmo hospedar uma ou mais FSMOs.

A função de DNS, quando não integrada ao Active Directory, precisa ser transferida para o novo controlador de domínio.

Quando a função de DHCP estiver presente você precisa alterar em todos os escopos DHCP para o endereço IP do novo controlador de domínio antes de desligar o antigo. Tenha em mente que também é uma boa idéia reduzir o Lease Time (tempo de concessão) para um tempo mais curto.

Perceba que se você não fizer isso e seu parque possuir centenas ou milhares de membros, o processo de troca será trabalhoso e caso ocorra algum problema, terá que ser refeito com um tempo maior.

Reduzir o Lease Time permitirá que você entregue a configuração rapidamente e caso tenha que realizar o rollback para o controlador de domínio antigo, isto será feito em pouco tempo.

É preciso garantir que todos os objetos alterados no controlador de domínio a ser decomissionado sejam replicados para o novo controlador antes de desligá-lo.

É preciso garantir que o novo controlador de domínio seja um Global Catalog (GC) ou que existam outros controladores de domínio com esta função, caso contrário, os usuários não serão capazes de efetuar o logon em seu domínio.

Não se esqueça de dispositivos como Gateways que podem ter configurações internas direcionadas para este controlador de domínio e até mesmo a função de DHCP entregando este endereço IP em pequenos escritórios, sites, etc.

Abaixo eu vou listar alguns links que podem ajudar no momento da migração:

Retornando ao assunto sobre o uso dos serviços de um controlador de domínio, infelizmente é comum encontrarmos programadores que inserem em seus códigos informações como o endereço IP de um servidor específico. Este tipo de ação pode gerar um problema caso o endereço IP seja alterado futuramente.

Aplicações como ERP’s entre outras suportam comunicação LDAP para que estas façam consulta sobre informações como grupos, contas de usuário, entre outros atributos em seu domínio para permitir o recurso de SSO (Single Sign On).

Computadores/servidores clientes podem ter configurado em suas interfaces de rede o endereço IP do servidor de DNS atual, função esta que normalmente é suportada pelo controlador de domínio.

Até mesmo dispositivos de rede podem ter em suas configurações de rede apontamentos para controladores de domínio/DNS.

Como vimos anteriormente, diversos recursos podem consumir os serviços oferecidos por um controlador de domínio e ser capaz de determinar quem está fazendo uso destes recursos podem ser a diferença entre um decomissionamento bem sucedido ou não.

Deixando de lado um pouco os motivos para se ter um processo de decomissionamento bem elaborado, vamos ver como é possível obter estas informações.

Em primeiro lugar, as informações sobre o uso do serviço de diretório em um controlador de domínio não estão disponíveis de forma legível, tão pouco habilitadas por padrão.

Para obter estas informações você precisa habilitar um recurso que se chama Event Tracing For Windows (ETW) e que permite obter informações sobre atividades e eventos no sistema operacional através de um Data Collector Set (DCS).

Um DCS é um recurso que permite a coleta de estatísticas relacionadas ao desempenho entre outras informações em um sistema operacional para análise, seja esta análise feita com uma ferramenta nativa do Windows ou de terceiros.

Para construirmos o nosso DCS baseado em ETW abra o console Performance Monitor (perfmon.msc). Com o console aberto, espanda o container Data Collector Sets > User Defined e em seguida, clique com o botão direito sobre o mesmo e escolha New > Data Collector Set.

adds-decommision-monitoring-0001

De ao DCS o nome que você achar correto, marque a opção Create Manually (Advanced) e clique em Next.

adds-decommision-monitoring-0002

Selecione a opção Create Data Logs, marque a opção Event Trace Data e clique em Next.

adds-decommision-monitoring-0003

Na próxima etapa, clique no botão Add… ao lado direito para que a janela de Event Trace Providers seja mostrada.

Perceba que existem vários providers que permitem obter dados de diversas funções/serviços e para este caso nós vamos utilizar 3 deles:

  • Active Directory Domain Services: Core
  • Active Directory: Kerberos KDC
  • NTLM Security Protocol

adds-decommision-monitoring-0004

adds-decommision-monitoring-0005

adds-decommision-monitoring-0006

Após inserir os ETWs informados anteriormente, clique em Next. Nesta etapa você pode aceitar a localização padrão do arquivo .ETL que será gerado ou então alterá-lo para o local de sua preferência.

É importante dizer que a localização do arquivo pode ser gerar um problema de falta de espaço no volume onde ele for armazenado, pois dependendo da quantidade de solicitações de serviços enviadas para o controlador de domínio, este arquivo pode se tornar gigantesco em um curto espaço de tempo.

A título de exemplo, este arquivo pode obter o tamanho de 100MB em apenas 5 minutos, então, ao habilitar este tipo de recurso em um controlador de domínio pela primeira vez, tenha em mente que você terá que monitorar o crescimento deste arquivo para não correr o risco de ocupar todos o espaço livre disponível, caso escolha uma unidade de disco com pouco espaço.

Após definir a localização do arquivo, clique em Finish para concluir a criação do nosso DCS para monitorar quem está utilizando o serviço de diretório deste controlador de domínio.

Espanda agora o container User Defined, clique com o botão direito sobre o DCS que acabamos de criar e escolha Properties.

adds-decommision-monitoring-0007

Selecione a guia Stop Condition e defina o espaço de tempo cujo o DCS estará em execução até ser interrompido, neste caso de testes, eu vou escolher um interválo pequeno (20 minutos) marcando a opção Overall duration para mostrar os dados que serão coletados no final. Clique em Apply e OK para finalizar a configuração do DCS.

adds-decommision-monitoring-0008

Clique então com o botão direito sobre o DCS criado e escolha a opção Start para iniciar a coleta das informações que precisamos.

adds-decommision-monitoring-0009

Para interpretar o conteúdo de um arquivo .ETL você precisará realizar alguns passos para exportar as informações primeiramente, pois por se tratar de um arquivo em formato binário, não é possível ler suas informações de forma amigavel.

Para exportar o conteúdo do arquivo .ETL do nosso DCS nós vamos utilizar um utilitário chamado tracerpt para convertermos o arquivo .ETL em .CSV.

Crie na raíz C: do controlador de domínio o diretório TraceCSVFiles.

Sobre o controlador de domínio onde você executou o DCS, abra o Command Prompt (cmd) com privilégio elevados e altere o diretório atual para C:\TraceCSVFiles com o comando cd \TraceCSVFiles.

Execute então o comando abaixo para converter o arquivo ETL gerado.

  • tracerpt -l “File\Location.etl” -of CSV

adds-decommision-monitoring-0010

Como mostrado na imagem anterior, dois arquivos foram gerados no diretório C:\TraceCSVFiles:

  • Dumpfile: dumpfile.csv
  • Summary: summary.txt

Se abrirmos o arquivo dumpfile.csv com um editor de texto simples como o Notepad você verá algo semelhante a isto:

adds-decommision-monitoring-0011

Em seguida, se abrirmos o arquivo summary.txt com o mesmo editor de texto, você verá as seguintes informações:

adds-decommision-monitoring-0012

Apenas com a verificação do arquivo dumpfile.csv é possível identificar se há ou não computadores/servidores membros utilizando o serviço de diretório no controlador de domínio, mas o mesmo está cheio de outros eventos que não são necessário para esta identificação.

Por conta do volume de informação que não é interessante para efetuarmos esta análise e também para facilitar a vida de quem precisa executá-la, o time de Directory Services da Microsoft criou e disponibilizou um planilha que faz esta filtragem e traz como resultado final apenas as informações que precisamos.

Esta planilha pode ser baixada aqui: Import-DC_Info.zip

Como você pode utilizar esta planilha? Após baixá-la para seu disco local, extraia o arquivo Import-DC_Info.xlsm para o mesmo diretório onde os arquivos dumpfile.csv e summary.txt estão localizados. Não se esqueça que você precisará do Microsoft Office instalado para executar a planilha, então, copie os arquivos dumpfile.csv e summary.txt para uma estação de trabalho com o Microsoft Office instalado.

Em seguida execute a planilha com um duplo clique. Após aberta, você verá a seguinte informação:

adds-decommision-monitoring-0013

Clique no botão Import Files e as funções existentes na planilha faram todo o trabalho de filtrar os logs necessário.

Após a conclusão, você irá visualizar algo semelhante ao que estamos vendo nas imagens abaixo:

adds-decommision-monitoring-0014

Na imagem acima na aba LDAP é possível verificar o endereço IP de cada host que efetuou algum tipo de solicitação para o serviço de diretório e neste caso, o que precisamos prestar atenção é para as duas linhas destacadas, pois elas mostram que uma estação de trabalho chamada WLDN001IT0001 solicitou o serviço de autenticação para o controlador de domínio onde o trace foi executado.

adds-decommision-monitoring-0015

Na imagem acima na aba Kerberos é possível verificar quem solicitou (usuário, computador, etc.) um determinado serviço na coluna User e qual foi o tipo de serviço na coluna Service.

adds-decommision-monitoring-0016

Na imagem acima na aba NTLM você entrará o número de validações de usuários solicitadas para o controlador de domínio.

Com estas informações em mãos é possível eliminar qualquer impacto causado por recursos que podem deixar de funcionar sem o controlador de domínio, pois sabendo quais são os hosts que utilizam os serviços de diretório do mesmo é possível tratá-los para identificar se a origem é apenas uma estação de trabalho ou outro recurso como servidores membros, dispositivos que podem estar fazendo consultas LDAP.

Agora que já temos as informações sobre os hosts que estão utilizando o serviço de diretório no controlador de domínio a ser decomissionado é hora de verificarmos outra função extremamente importante e que trabalha de uma forma muito íntima com o Active Directory, o DNS.

Verificar se a função de DNS do controlador de domínio está atendendo a consultas de clientes é extremamente importante, principalmente quando você possui apenas um controlador de domínio, computadores/servidores membros com configurações de rede manuais, etc.

É muito importante você entender como funciona uma consulta DNS, tanto do lado do cliente, quanto do lado do servidor primeiramente. Muitas pessoas desconhecem o funcionamento deste recurso essencial para realizar o trobleshooting de problemas de conectividade.

Pensando em agregar um conhecimento maior a você eu sugiro a leitura destes artigos excelentes:

Voltando ao processo de decomissionamento do nosso controlador de domínio, nós precisamos garantir que todos os membros do domínio estejam efetuando suas consultas DNS para o controlador de domínio correto, caso contrário, você terá problema de autenticação entre outros.

O primeiro passo que eu recomendo ser feito caso você utilize o serviço de DHCP para fornecer endereços IP em sua rede é alterar a ordem dos servidores de DNS no escopo para que o novo controlador de domínio passe a ser o servidor de DNS preferencial e o controlador de domínio a ser decomissionado passe a ser o alternativo.

Aguarde então o tempo de concessão (por padrão é 8 dias) para que o os endereços IPs sejam renovados e a nova configuração de DNS seja aplicada aos clientes do DHCP.

Agora vamos nos concentrar nos clientes que ainda podem estar utilizando o DNS a ser decomissionado devido ao uso de configurações de rede manuais.

O primeiro passo que precisamo executar é ativar a coletar de logs do DNS para localizarmos o que nós desejamos: saber quem ainda continua utilizando-o para conultas DNS.

Abra o console de gerenciamento do DNS (dnsmgmt.msc). No painel de navegação esquerdo, clique com o botão direito sobre o nome do servidor de DNS e escolha Properties.

adds-decommision-monitoring-0017

Na janela de propriedades do DNS selecione a guia Debugging Log como mostrado na imagem abaixo:

adds-decommision-monitoring-0018

Por padrão o log não está habilitado no DNS, então vamos habilitá-lo como mostrado na imagem anterior para termos o registros das consultas feitas neste servidor de DNS. Marque a opção Log packet for debugging e então marque as opções como mostrado na imagem anterior.

É possível informar um caminho para o arquivo de log gerado no campo File path and name no bloco Log File, mas isto não é necessário, pois ao deixar a caixa em branco, por padrão o arquivo dns.log localizado no diretório C:\Windows\System32\dns será alimentado com as informações.

Supondo que você tenha deixado a log sendo alimentado por alguns dias, vamos analisá-lo agora. A compreensão do arquivo não é nada ruim e pode ser feita perfeitamente sem a ajuda de utilitários, mas para facilitar a nossa vida, vamos utilizar um utilitário chamado WinDNSLogAnalyzer Tool para nos ajudar a ter uma leitura mais robusta.

Baixo o utilitário no link encontrado no parágrafo anterior e faça a instalação padrão. Após abrir o WinDNSLogAnalyzer Tool clique no link Configure settings no centro da janela do utilitário para informarmos o local do arquivo de log do DNS de onde ele irá obter as informações.

adds-decommision-monitoring-0019

A vantagem do uso do WinDNSLogAnalyzer Tool está nos gráficos que mostram o número de consultas feitas por cada host, o que foi consultado, os tipo de registros e o nome dos hosts que realizam a consulta. A desvantagem em seu uso está na falta da possibilidade de se exportar os dados consolidados por ele ao ler o arquivo de log e que ajudaria muito no momento de fazer a verificação.

adds-decommision-monitoring-0020

Como podemos visualizar na imagem abaixo, é possível identificar que o três computadores/servidores membros fizeram consultas DNS em Top Rows by Source IP.

De posse do nome dos hosts que estão fazendo algum tipo de consulta no DNS, você pode conectar nestes e verificar as configurações de rede para determinar quais servidores DNS estão configurados em todas as interfaces de rede existentes e certamente irá encontrar o que nós podemos visualizar nas imagens a seguir para os host WMCH001OP0001 e NEUR001DC0002, por exemplo:

adds-decommision-monitoring-0021

adds-decommision-monitoring-0022

No caso do do host WMCH001OP0001 nós identificamos que ainda existe um escopo de DHCP onde o endereço IP do DNS precisa alterado e no caso do host NEUR001DC0001, que neste caso é o próprio DC+DNS que iremos decomissionar, que as configurações de rede precisam ser alteradas caso o mesmo fosse um servidor membro.

Conclusão…

Ao longo deste post você aprendeu como fazer o decomissionamento de um controlador de domínio e DNS de forma segura monitorando sua utilização para identificar antes de efetivamente desligá-lo os recursos que ainda continuam fazendo uso de seus serviços.

Este processo visa garantir que nenhum recurso deixe de operar corretamente após o controlador de domínio e DNS serem decomissionados.

Tenha em mente também que este processo não significa que você possa reutilizar imediatamente este controlador de domíio para outra finalidade. É preciso criar um processo de quarentena, seja de 7 dias, 14 dias ou quanto tempo for necessário para que este decomissionamento seja feito de forma muito segura.

Mesmo efetuando todo este processo de obtenção de informações é possível que exista algum recurso que não esteja operando naquele momento em que você optou por levantar quem está utilizando de fato o controlador de domínio por alguma razão e você só irá notar quando isto deixar de funcionar corretamente por estar operacional.

Por este motivo, eu sugiro que seja feita uma quarentena para que, caso algo deixe de funcionar, você possa reestabelecer seu funcionamento no menor tempo possível religando o controlador de domínio.

Lembre-se, um controlador de domínio pode ficar de 60 a 180 dias (este valor depende da versão do sistema operacional e o valor do atributo Tombstone Lifetime) desligado sem que ele tenha problemas de sincronização, após isso, você não será capaz de obter as informações através da replicação de objetos dos outros controladores de domínio.

É isto caro leitor! Espero que a informação seja útil para o seu dia a dia e que o procedimento evite possívels problemas no processo de decomissionamento de seus controladores de domínio e DNS.

Até o próximo post…

%d blogueiros gostam disto: