Início > Active Directory, Auto Site Coverage, Directory Services, DNS, RODC, RWDC, Sites and Services, Windows Server, Windows Server 2003/R2, Windows Server 2008/R2, Windows Server 2012/R2 > Automatic Site Coverage – Mistério sobre registro DNS divergentes em sites sem DC ou com RODC

Automatic Site Coverage – Mistério sobre registro DNS divergentes em sites sem DC ou com RODC

maio 9, 2015

Olá pessoALL,

Neste post eu vou relatar um problema que na medida que alguns IT-Pros adotam o uso de RODCs em sites com pouca segurança podem encontrar no processo de autenticação e até mesmo o comportamento padrão ao criarem um site no Active Directory Sites and Services em um Domain Controller associado.

Antes de mais nada, vamos começar falando sobre um recurso nativo de Domain Controllers chamado Automatic Site Coverage.

Para entender no final o que de fato ocorreu nas situações informadas aqui é primordial que o IT-Pro responsável pelo gerenciamento de Directory Services entende literalmente o que é o Automatic Site Coverage.

De forma clara e objetiva, o recurso Automatic Site Coverage tem o objetivo de garantir que clientes possam localizar um Domain Controller o mais próximo possível de sua localidade para estabelecer seu processo de autenticação.

Mas como este recurso funciona? Vamos usar o cenário de sites abaixo para entender este funcionamento e resultado.

AutoSiteCoverage_0001

Como podemos visualizar na imagem anterior, existem três sites criados, cada um possui seu Domain Controller associado como esperado e com seus devidos objetos de conexão permitindo a replicação entre eles.

Também podemos visualizar na imagem abaixo como estas configurações estão disponíveis na zona DNS relativa ao domínio NoSafeForWork.local.

AutoSiteCoverage_0002

Para conhecimento, o comando usado para listar os registros DNS relacionados aos serviços de diretório em sites foi:

Get-WmiObject -Namespace root/MicrosoftDNS -q “Select * FROM MicrosoftDNS_SRvtype” | ?{($_.TextRepresentation -like “_ldap*” -OR $_.TextRepresentation -like “_gc*” -OR $_.TextRepresentation -like “_kerberos*” -AND $_.OwnerName -like “*._sites.*”)} | Sort-Object OwnerName | Ft -wrap -autosize OwnerName,TextRepresentation

Tendo conhecimento das informações atuais envolvidas neste cenário, vamos então supor que a empresa NoSafeForWork Inc. está realizando a abertura de uma nova planta na cidade de Sidney, Australia (AUSIDD) e terá seu próprio Data Center com seu Domain Controller e outros recursos locais.

PS: AU = Austrália, SID = Sidney e D = Data Center D

Vamos levar em consideração que a empresa NoSafeForWork Inc. ainda possui alguns Domain Controllers Windows Server 2003 em operação em processo de decomissionamento.

Vamos supor que o administrador responsável pelos serviços de Directory Services foi informado desta nova planta em andamento e o mesmo tomou a decisão de criar todas as estruturas necessárias no AD DS para alocar os objetos que serão criados em breve.

Como dito anteriormente, a planta AUSIDD terá seu próprio Domain Controller, logo o administrador criou o seguinte site, site link e subnet em Active Directory Sites and Services:

AutoSiteCoverage_0003

Como podemos visualizar, foram criados site links para permitir a replicação entre o novo site AUSIDD e os outros sites, uma subnet (10.10.10.208/28) que irá conter os hosts da planta e o site AUSIDD que receberá o Domain Controller da localidade futuramente.

Olhando da perspectiva do Active Directory Sites and Services, é possível imaginar que:

Não há nenhum Domain Controller associado ao site AUSIDD, portanto, não há como serviços de diretório serem fornecido a qualquer membro que faça esta solicitação sem que uma pesquisa recursiva seja feita no DNS.

Presumo que você esteja pensando: se não há um Domain Controller neste site, qualquer membro que esteja neste segmento de rede ao solicitar qualquer serviço de diretório fará um busca recursiva no DNS até que o Domain Controllers com menor custo até a localidade seja identificado e então forneça os serviços solicitados.

Você que pensou isso não está errado, apenas não está totalmente certo devido a operação de um mecanismo chamado Automatic Site Coverage.

Como dito no começo deste post, este recurso garante que clientes possam localizar um Domain Controller o mais próximo possível de sua localidade para estabelecer seu processo de autenticação baseado nos custos dos Site Links existentes no Active Directory Sites and Services.

Olhando para a última imagem é possível identificar que o Domain Controller com menor custo de comunicação com o novo site AUSIDD está no site USNYCB, então, o que ocorrerá de fato quando o Automatic Site Converage entrar em ação?

Do ponto de vista do Active Directory Sites and Services, você não terá alteração alguma, mas, do ponto de vista da zona DNS você verá uma mudança que irá refletir literalmente o que foi dito no parágrafo anterior. Como podemos então provar que o Automatic Site Coverage entrou em ação neste tipo de situação?

Usando o comando que já usamos anteriormente para listar os registros de serviços de diretório. Vamos executar novamente o mesmo comando e ver o que mudou desde a sua última execução.

AutoSiteCoverage_0004

Já podemos visualizar o novo site AUSIDD e seu diretório criado dentro da zona responsável pelo Directory Services em amarelo, mas o que significa a informação roxa a direita? Por que o registro do Domain Controller USNYCBDC-P0001 está associado ao site AUSIDD?

Bem, quando olhamos esta situação da perspectiva do processo Domain Controller Locator o resultado esperado seria uma consulta recursiva até a localização do Domain Controller mais próximo do site AUSIDD, no entanto, o recurso Automatic Site Coverage age de forma mais próativa neste tipo de situação registrando no DNS os registros de serviços de diretório necessários do Domain Controller mais próximo do site para que o clientes possam solicitar o serviço.

Esta ação otimiza o processo de descoberta por serviços de diretório, mas também pode causar uma determinada confusão por parte de administradores que não conhecem muito bem como este recurso funciona e também algumas situações específicas.

Vamos lembrar dois detalhes desta ambiente controlado que podem não estar sendo levados em consideração:

  1. Um ou mais RODCs na infraestrutura.
  2. Existência de um ou mais Windows Server 2003 atuando como Domain Controllers.

Você pode estar se perguntando: qual é ou quais são os problemas que podem ocorrem devido a estes dois pontos anteriormente relambrados?

Eis aqui uma situação comum que alguns administradores podem encontrar devido a esta combinação em que Automatic Site Converage não é levado em consideração:

  • você insere um RODC em sua infraestrutura em um site com pouca segurança (AUSIDD).
  • clientes deste site começam a utilizar os serviços de diretório.
  • o administrador de rede alerta você de que o uso do enlace de comunicação entre o site do AUSIDD e o site com menor custo (USNYCB) está elevado.
  • em conjunto é feito um monitoramento do que está sendo tráfegado neste enlace.
  • como resultado, você descobre que os clientes estão autenticando no RWDC localizado no site USNYCB e não no RODC localizado em AUSIDD.
  • o site USNYCB ainda possui um Domain Controller executando o Windows Server 2003 a ser decomissionado em breve.
  • você remove os registros que presume estarem registrados de forma errada na zona DNS.
  • após o próximo ciclo de replicação entre os sites você descobre que novamente o DC do site USNYCB registrou no DNS seus registros de serviço no site AUSIDD.

O que acontece de fato para que esta situação se mantenha desta forma causando normalmente uma certa confusão no profissional que gerencia os serviços de diretório?

Por padrão, o Windows Server 2003 não tem conhecimento do que é um RODC. Para que isso ocorra corretamente, é preciso instalar o pacote de compatibilidade deste KB.

Desde o Windows Server 2000, o recurso de Automatic Site Coverage está presente e age da forma como já informamos anteriormente neste tipo de situação.

Então como podemos evitar este tipo de situação? Existem 3 formas:

  1. aplicar o pacote de compatibilidade informado anteriormente.
  2. garantir que o Domain Controller do site mais próximo ao site onde o RODC reside esteja executando o Windows Server 2008 ou superior.
  3. desativar o recurso de Automatic Site Coverage no Domain Controller que está registrando os registros DNS de serviços de diretório no site onde o RODC está.

Com exceção das alteranativas 1 e 2 que são simples e auto explicativas, somente a opção 3 requer um pequeno passo a passo para desabilitar o recurso Automatic Site Coverage.

  1. Clique em Start > Run,digite regedit e pressione OK.
  2. Navegue até a subkey: HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters.
  3. Veriquei se o dado do tipo REG_DWORD chamado AutoSiteCoverage está presente.
  4. Se sim, duplo clique sobre o mesmo e atribua o valor zero (0).
  5. Caso não exista, clique em Edit > New > DWORD.
  6. Digite AutoSiteCoverage como nome do novo dado.
  7. Duplo clique sobre o novo dado e atribua o valor zero (0) para desabilitar ou um (1) para habilitar se for necessário.

Após realizar este simples procedimento, o recurso de Automatic Site Coverage será desativado no Domain Controller e você não experimentará mais a condição de registros na zona DNS dentro do diretório do site onde o RODC está localizado.

Após toda esta situação, o que nós podemos concluir? Bem, sempre leia e entenda muito bem todos os pontos referentes ao que se pretende fazer para garantir que o resultado esperado seja de fato o que ocorrerá.

Espero que a informação seja útil e que este tipo de situação não seja mais um mistério como é para muitos IT-Pros.

Até o próximo post…

%d blogueiros gostam disto: