Início > Active Directory, Directory Services, Sites and Services, Windows Server, Windows Server 2003/R2, Windows Server 2008/R2, Windows Server 2012/R2 > Active Directory – Entendendo o conceito de Sites e qual a sua importância

Active Directory – Entendendo o conceito de Sites e qual a sua importância

julho 5, 2014

Olá pessoALL,

Hoje eu vou falar um pouco sobre um conceito que definitivamente é muito importante para quem trabalha com o gerenciamento de Directory Services e que precisa estar muito bem consolidado. O conceito de Sites do Active Directory e sua importância.

É comum encontrarmos em nosso dia a dia, uma infraestrutura de IT separada fisicamente, distribuída entre várias localizações e interconectadas por enlaces de comunicação dedicados.

Para quem trabalha com redes, o conceito de “site” representa uma localização física de sua infraestrutura ou pelo menos uma porção onde ela está localizada.

Podemos concordar que uma infraestrutura de rede é composta pela localização física de um site e os enlaces de comunicação que interconectam este site a todo o resto do mundo, aos outros sites que fazem parte da infraestrutura e que parte desta é composta por servidores que desempenham algum tipo de função.

Uma destas funções é Active Directory Domain Services. O AD DS é uma solução altamente utilizada por instituições de todos os tipos e em suas mais variadas formas.

Há instituições que possuem infraestruturas de AD DS centralizada, concentrando todo o seu serviço de diretório em um único site, independente se há outros sites remotamente que necessitam deste tipo de serviço.

Também há instituições que possuem infraestrutura de AD DS distribuídas entre seus sites com servidores locais interconectados através de seus enlaces de comunicação.

A forma como uma infraestrutura de serviço de diretório é implementada depende do tipo de necessidade que pode justificar ou não termos uma infraestrutura centralizada ou distribuída entre os sites.

Da mesma forma como em uma rede, o Active Directory usa o mesmo conceito para representar sua infraestrutura de serviço de diretório por dois objetos chamados Sites e Site Links.

Quando falamos sobre Active Directory Sites, estamos falando sobre objetos em um diretório localizado no contexto Default Naming chamado Configuration (CN=Configuration, DC=Forest Root Domain). Estes objetos são usados com os seguintes objetivos:

  • Gerenciar o tráfego de replicação
  • Facilitar a localização de serviços

Para acessar o diretório Configuration utilize o ADSIEDIT, selecione a opção Select a well known Naming Context: no bloco Connection Point e escolha Configuration no menu drop-down.

Qual é o tráfego de replicação no Active Directory?

Uma replicação do Active Directory é o processo de transferência de qualquer alteração efetuada entre controladores de domínio. Quando você cria um grupo, o controlador de domínio onde você executou está alteração faz a inclusão desta nova informação em sua base do Active Directory.

Após a alteração ser efetivada no Active Directory do controlador de domínio, ela precisa ser enviada para os demais controladores de domínio que compõem o seu serviço de diretório para que sua infraestrutura fique integra e com informações atualizadas.

Por padrão, o Active Directory define dois tipos redes dentro de sua infraestrutura:

  • Highly Connected (podemos chamar de enlaces de alto custo para o tráfego de dados)
  • Less Highly Connected (podemos chamar de enlaces de baixo custo para o tráfego de dados)

Por padrão, uma alteração feita no Active Directory deveria ser replicada para todos os outros controladores de domínio dentro uma rede Highly Connected imediatamente, mas nem sempre você irá desejar que este tipo de comportamento ocorra sem nenhum controle.

Certamente você irá desejar que o seu tráfego de replicação do Active Directory use um enlace de menor custo ou até mesmo um enlace que não comprometa a produtividade de seu negócio para otimizar a performance, reduzir custo e gerenciar o consumo de banda.

O que é a localização de serviços no Active Directory?

Presumindo que existam pelo menos dois controladores de domínio em sua infraestrutura, cada controlador de domínio deve oferecer os mesmos serviços de autenticação e acesso de diretório que qualquer outro controlador de domínio oferece.

Quando falamos de localização de serviços no Active Directory, há dois exemplos práticos para que você entenda este tipo de função:

  • Localização de impressoras
  • Localização serviços de diretório

Mobilidade é um processo muito comum hoje em dia com o uso de dispositivos portáteis. Comumente viajamos entre sites diferentes onde conectamos nossos portáteis a rede local para termos acesso aos serviços disponíveis.

É comum o uso de impressoras para a produção de documentos por pessoas que passam muito tempo se movimentando entre sites e se lembrar de todas as impressoras disponíveis em cada site para fazer uso pode não ser uma tarefa fácil, tão pouco desejada de se fazer por quem quer a facilidade de localizar uma impressora de forma rápida e prática.

Para tornar a vida dos usuários mais fácil, e possível disponibilizar uma impressora baseada em sua localização em conjunto com um site do Active Directory.

Outro fator importante sobre a localização de serviços está relacionado com onde um computador cliente busca informações como serviço de diretório, DNS, etc.

Durante o processo de logon, o Windows é automaticamente direcionado para o controlador de domínio de seu site evitando um tráfego desnecessário em seus enlaces de dados e somente irá fazer uso destes enlaces, caso o controlador de domínio local não responda a solicitação do serviço, pois ele ira localizar o controlador de domínio mais próximo e com menor custo.

Como planejar sites do Active Directory?

Esta uma das perguntas que você irá se fazer quando estiver gerenciando uma infraestrutura de serviço de diretório, mas como determinar quando é ou não necessário à criação de um site no Active Directory?

Existem casos e casos e não há como determinar neste momento se é ou não necessário à criação em seu caso, pois será necessário avaliar alguns critérios para isto.

Um dos critérios, mas que ainda sim pode não significar que há necessidade da criação de um site, é se houver dois sites físicos e cada site possuir um controlador de domínio.

Obviamente, se existe um controlador de domínio por site, certamente o número de usuários justificou este tipo de solução, já que não é justificável colocar um controlador de domínio em um escritório contendo 10 usuários apenas.

Este detalhe é algo a se considerar, pois um grande número de usuários podem demandar um alto tráfego de consultas LDAP/DNS e também existem aplicações que fazem uso destas mesmas consultas.

Outro fator importante é o enlace de dados que interconecta os sites. Pode não ser interessante ter apenas um site lógico entre dois sites físicos, pois o uso de um enlace de dados no caso de um enlace lento poderia gerar problemas de produtividade para o negócio de sua empresa.

Outro critério essencial é a localização de serviços. Se houver a necessidade de se ter serviços baseados em uma localização, considere a criação de um site.

O número de serviços oferecidos localmente (impressoras, acesso a arquivos, etc.) para os usuários também é um fator que pode justificar o uso de um controlador de domínio local em um site, mas pode não ser a solução de outros problemas, como por exemplo, imagine que você tenha uma infraestrutura de arquivos na matriz e um controlador de domínio local em um site.

Se o enlace de dados entre a matriz o site for interrompido, de nada adiantará o controlador de domínio local, pois o acesso aos arquivos na matriz também estará comprometido. Agora, se os recursos acessados estão localizados no site, um controlador de domínio local iria garantir que todos os usuários não sintam a queda do enlace de dados entre a matriz e o site remoto.

Aproveitando o assunto sobre a interrupção do enlace de comunicação entre as localidades, outro fator que determinaria a necessidade do uso de um controlador de domínio local seria o tempo que os usuários da localidade podem ficar sem este serviço.

Pense da seguinte forma: se meu escritório remoto A que contem X usuários ficar impossibilitado de realizar suas tarefas diárias devido ao serviço de diretório estar interrompido na localidade, qual será o meu prejuízo? Quanto tempo os usuário podem ficar neste tipo de condição?

Este tipo de pergunta justifica ou não a necessidade de um controlador de domínio local em seu site remoto.

Tenha sempre em mente que a grande maioria dos serviços de rede que você faz uso em seu dia a dia utiliza processos de autenticação e autorização para garantir ou negar o acesso de um determinado recurso para um usuário e caso um controlador de domínio não possa ser consultado, o acesso ao recurso não será possível.

Quais são os componentes de um site no Active Directory?

Em linhas gerais, uma infraestrutura de sites possui os seguintes componentes configurados:

  • Subnet: representa a porção lógica de rede de um site, por exemplo, 10.10.10.0/28.
  • Site link: representa um link lógico dentro do Active Directory que o orienta como a replicação deve ser feita e para quem. Pode ser do tipo IP ou SMTP.
  • Site: representa a localização dos servidores e serviços de diretório no Active Directory.

Subnet

Subnet ou subrede é uma porção de endereços IPs disponíveis em sua rede que representa uma localidade remota ou até mesmo local, mas segmentada como, por exemplo, andares em um edifício.

Digamos por exemplo que existam duas localidades remotas conectadas por um enlace de dados e que cada uma possui um segmento de rede distinto como de 10.10.10.1 a 10.10.10.14 para a localidade A e de 10.10.10.17 a 10.10.10.30 para a localidade B.

Para representarmos estes dois segmentos para o Active Directory, seria necessário criar duas subnets usando uma notação chamada CIDR (Classless Inter-Domain Routing) para representar as subredes da localidade A e B que usa o endereço de rede + o número de bits da máscara de rede para respresentar a porção de endereços IPs roteáveis do segmento.

Qual seria o endereço CIDR para os segmentos de rede das localidades A e B? Para a localidade A o CIDR do segmento de rede seria 10.10.10.0/28 e para a localidade B seria 10.10.10.16/28.

Tendo em mãos o CIDR dos segmentos de rede envolvidos, este seria o resultado da criação de subredes para quatro sites:

adds-sites-and-services-0001

Na imagem anterior nós temos quatro segmentos de rede criados, cada um associado à localidade que ele representa como podemos ver na coluna Site no painel de visualização direito.

adds-sites-and-services-0002

Site Link

Um site link representa a uma conexão ou link lógico entre dois ou mais sites no Active Directory. Quando criamos um novo site link é necessário informar pelo menos dois sites que farão parte deste link lógico.

Por padrão, quando você cria o primeiro domínio em uma floresta é criado um site link chamado DEFAULTIPSITELINK. Todo novo site criado é associado a este site link padrão caso você não tenha removido ou renomeado o mesmo.

Devido ao comportamento descrito no parágrafo anterior, mesmo que você crie uma subrede e um site para separar logicamente suas localidades, caso você não tenha criado site links específicos para as localidades você não terá uma segmentação de replicação, pois como todos os sites estariam usando o DEFAULTIPSITELINK, todos os sites estariam replicando entre eles.

Pensando como um administrador de redes, seria necessário segmentar corretamente a comunicação entre os sites informando ao Active Directory quem pode se comunicar com quem. Como realizar esta segmentação?

Digamos que há quatro sites (LONDON, MANCHESTER, LIVERPOOL e YORK) interconectados por enlaces e que cada um possui um custo para o tráfego de dados.

Vamos assumir que o site LONDON possui o maior custo no enlace e que ele deverá apenas replicar com o site MANCHESTER, pois existe um enlace entre estes dois sites apenas. Todos os outros dois sites possuem enlaces de menor custo e que podem ser usado para replicar alterações entre ambos, com o site MANCHESTER, mas não devem replicar com LONDON, pois não possuem um enlace para este site.

A configuração para este tipo de situação ficaria da seguinte forma:

adds-sites-and-services-0003

adds-sites-and-services-0004

Além do custo por enlace, haverá momentos em que você terá que definir custos para o cada site link. A título de exemplo, vamos imaginar que exista um enlace de dados entre YORK e LONDON, mas que este enlace de dados seja lento (9.6 Kbps).

Digamos que exista um site link chamado LONDON_TO_YORK interconectando os sites e que o custo deste site link também seja de 100 como nos exemplos anteriores. Os site links LONDON_TO_MANCHESTER e MANCHESTER_TO_YORK possuem o custo de 100.

Por questões de confiabilidade, você deseja que o enlace de dados entre YORK e LONDON não seja utilizado e que este tráfego seja feito primeiramente entre YORK e MANCHESTER (1024 Kbps) e em seguida entre MANCHESTER e LONDON (1024 Kbps).

Se o custo de cada site link for o padrão (100), a replicação ocorrerá pelo menor caminho possível, indiferente do enlace de dados ser lento ou não, pois este é o comportamento padrão.

Como resolver este problema? Neste exemplo, o que nós podemos fazer é alterar o custo do site link, tal como ocorre quando precisamos configurar custos de rotas em roteadores.

Vamos usar a tabela a seguir fornecida pela Microsoft como boas práticas para a configuração do custo para site links.

Available Bandwidth Cost
9.6 Kbps 1042
19.2 Kbps 798
38.4 Kbps 644
56 Kbps 586
64 Kbps 567
128 Kbps 486
256 Kbps 425
512 Kbps 378
1024 Kbps 340
2048 Kbps 309
4096 Kbps 283
Formula: 1024/log(Kbps)
1024/log(8192) = 262

De posse destes valores, para garantirmos que a replicação ocorra da forma como esperamos, o custo do site link LONDON_TO_YORK seria configurado como 1042, o site link LONDON_TO_MANCHESTER com 340 e o site link MANCHESTER_TO_YORK com 340.

Por padrão, o KCC usa o site link com menor custo para replicar dados entre sites.

Como o objetivo é evitar o enlace de dados entre YORK e LONDON, seria apenas necessário configurar o site link MANCHESTER_TO_YORK com um valor superior de 300. Como já assumimos que os outros site links possuem o custo de 100 cada, o que no final gera um custo de 200 com a soma

Criar cada site link mostrados anteriormente já é suficiente para resolver o nosso problema? Quase…

O que falta então? Há um detalhe muito importante e que normalmente não é levado em consideração no momento de efetuar a configuração deste recurso, a conexão física que interconecta cada site.

Como informado anteriormente, foi descrito que o site LONDON possui um enlace de dados conectando LONDON ao site MANCHESTER e que MANCHESTER possui enlaces de dados conectando-o a todos os outros sites.

Resumindo, o site MANCHESTER pode ser considerado uma ponte entre o site LONDON e os sites LIVERPOOL e YORK.

Mas o que este detalhe interfere em nossa configuração? Para entendermos qual é a importância deste detalhe relacionado ao enlace de dados, precisamos entender como funciona a criação da topologia de replicação do Active Directory.

Felizmente a topologia de replicação intrasite do Active Directory não precisa ser criada manualmente por quem configura as subredes, site links e sites, pois este processo é feito automaticamente por um componente do Active Directory chamado KCC ou Knowledge Consistency Checker.

Este componente irá garantir que a topologia de replicação intrasite do Active Directory seja criada da melhor forma possível definindo que não haverá mais do que três saltos entre quaisquer dois controladores de domínio dentro do mesmo site.

O KCC é responsável por avaliar e criar objetos de conexão de duplo sentido entre os controladores de domínio dentro de um site. Ele também é responsável por gerenciar objetos de conexão, como por exemplo, quando um novo controlador de domínio é inserido, removido ou deixa de responder em um site para manter a consistência da replicação entre os controladores de domínio.

Enquanto o KCC gerencia objetos de conexão intrasite o ISTG ou Intersite Topology Generator, que também é parte do KCC gerencia a replicação intersite usando as configurações existentes em cada site link que foi mostrado anteriormente.

OK! Se o KCC e o ISTG gerenciam estas replicações, por que ainda falta algo a ser feito e eu tenho que me preocupar com a questão dos enlaces de dados disponíveis entre os sites?

Simples! Por padrão o KCC assume que todos os controladores de domínio dentro de um site estão conectados diretamente por uma conexão, seja ela local ou não e isto se aplica também ao ISTG para a conexão entre os sites.

Este processo garante que você tenha transitividade entre sites que podem ou não estar conectados fisicamente, pois se o site A está conectado ao site B e o site B está conectado ao site C, o ISTG assume que o site A está conectado ao site C.

Se isto é verdade, ao assumir que todos os sites estão conectados por enlaces de dados diretamente, o ISTG pode gerar uma inconsistência criando bridge connections entre dois servidores em sites distintos e isto pode causar a duplicidade de zonas integradas ao Active Directory, problemas de replicação, etc.

Além dos possíveis problemas, deixar que o Active Directory assuma que existe um topologia de rede altamente conectada pode resultar em replicações desnecessárias ou indesejadas, uma vez que você pode desejar controlar de onde e para onde os objetos são replicados em sua infraestrutura.

Como já sabemos das possíveis questões que podemos ter com o uso do ISTG para gerar conexões dinâmicas e automáticas entre os sites, como podemos resolver isto? Este é um passo muito simples. Apenas clique com o botão direito sobre o container IP em Inter-Site Transports e desmarque a opção Bridge All Site Links.

adds-sites-and-services-0005

Feita esta alteração em seu domínio, você estará evitando que conexões dinâmicas sejam criadas entre os sites que não estão conectados diretamente lhe permitindo um maior controle sobre de onde e para onde sua replicação estará fluindo.

É importante informar também que, caso a opção Bridge All Site Links esteja ativa, de nada irá adiantar a criação de site links como mostrado anteriormente, pois eles não terão efeito algum.

Sites

Um site do Active Directory representa um conjunto de servidores/serviços de sua empresa altamente conectados e toda alteração que ocorrer em qualquer membro deste site é replicada quase que instantaneamente para os outros membros do site.

Por padrão, ao instalar o primeiro controlador de domínio em uma floresta é criado um site chamado Default-First-Site-Name e todo controlador de domínio adicional inserido no domínio será colocado dentro deste site caso você não tenha configurado seus sites, subnets e site links.

Como boa prática, é recomendado que o site padrão seja renomeado para refletir o site de fato, mas você também pode removê-lo, se desejar, após criar seus sites, subnets e site links a partir do zero.

Vamos começar entendendo os objetos e propriedades existentes e cada nível do site YORK para saber qual é a função de cada um.

Clicando sobre o site YORK serão apresentadas as seguintes informações no painel de visualização direito:

adds-sites-and-services-0006

Neste nível você encontra as configurações relacionadas a todo o site YORK no objeto NTDS Site Settings e as subnets que estão associadas ao site nas propriedades do site.

adds-sites-and-services-0007

Em NTDS Site Settings serão encontradas as configurações do site relacionadas ao ISTG, agendamento de replicação intrasite e o uso do UGMC ou Universal Group Membership Caching.

adds-sites-and-services-0008

Tomando como exemplo a imagem anterior, vamos ver o que significa cada item da guia Site Settings.

  • Change Schedule: representa a configuração da frequência com que a replicação entre os servidores do site é feito e que por padrão é definida para uma vez a cada hora. Não é recomendado a alteração deste agendamento.

adds-sites-and-services-0009

  • Inter-Site Topology Generator: contem o controlador de domínio, neste caso do site YORK, que é responsável por criar conexões através do ISTG com outros sites.
  • Universal Group Member Caching (UGMC): elimina a necessidade de um controlador de domínio que não é um Global Catalog (GC) consultar um outro controlador de domínio que é um GC em outro site para poder autenticar usuários em seu site. É possível configurar também de onde o controlador de domínio obtém do cache usando a opção Refresh Cache From.

Clique sobre o diretório Servers para visualizarmos um sumário sobre os servidores que fazem parte do site YORK.

adds-sites-and-services-0010

Na imagem anterior podemos verificar algumas informações importantes sobre os servidores do site tais como se ele é um Bridgehead para um protocolo de comunicação ou mais (neste caso ele é um Bridgehead Server para o protocolo IP) e se ele possui a função de Global Catalog.

Um servidor que esteja definido como Bridgehead Server é responsável por realizar a ponte de comunicação entre o seu site e todos os outros sites com os quais ele deve se comunicar como definido nas configurações de site links.

No caso do site YORK, nós sabemos que a comunicação deve ser feita com LIVERPOOL e MANCHESTER como definido nos site links anteriormente.

adds-sites-and-services-0011

Como podemos saber qual é o controlador de domínio que atua como Bridgehead Server em um site caso existam diversos controladores de domínio?

A forma disponível na base de conhecimento da Microsoft informa que é necessário exibir alguns atributos para verificar esta informação, tal como é mostrado nos links a seguir.

http://technet.microsoft.com/en-us/library/cc816773(v=ws.10).aspx

http://technet.microsoft.com/en-us/library/cc816930(v=ws.10).aspx

No entanto, existe um módulo do Powershell disponível no link abaixo que permite listar está informação.

http://gallery.technet.microsoft.com/scriptcenter/780a2272-06f9-4895-827e-9f56bc9272c4

Para utilizar o módulo você precisará do .NET Framework 3.5 instalado e executar o comando Get-ADSite -Name YORK.

adds-sites-and-services-0012

Clique com o botão direito sobre o objeto do seu servidor, neste caso NYRK001DC0001 e escolha Properties.

adds-sites-and-services-0013

A partir do objeto dos controladores de domínio do site você será capaz de configurar quem é o Bridgehead Server preferencial para determinado protocolo. No caso do controlador de domínio NYRK001DC0001, ele é o preferencial para o protocolo IP.

Você pode definir este tipo de configuração selecionando o protocolo disponível no lado esquerdo inferior e clicando em Add >> para movimentá-lo para o lado direito.

Outro fator importante sobre Bridgehead Servers é o fato de que por padrão o ISTG promove de forma dinâmica quem deverá ser o Bridgehead Server para um site. Isto pode ser um fator benéfico ou não, pois depende do ponto de vista da infraestrutura e de outros fatores.

Quando o ISTG está responsável por promover um controlador de domínio como Bridgehead Server para um site, caso exista mais de um controlador de domínio e o Bridgehead Server atual falhe, o ISTG irá promover outro controlador de domínio para assumir esta função e garantir que a replicação intersite não seja comprometida.

No entanto, seu ambiente pode ter políticas de segurança e/ou de tráfego de dados e que fará você decidir ter um Bridgehead Server definitivo para controlar o tráfego de dados e qual controlador de domínio pode se comunicar com outro controlador de domínio.

É importante entender que ao selecionar um protocolo de replicação (IP) como foi feito anteriormente, você estará informando ao ISTG que ele não deve promover nenhum outro controlador de domínio a Bridgehead Server.

Saiba também que você pode determinar manualmente mais de um controlador de domínio como Bridgehead Server se você decidir. Isto poderá evitar que sua replicação intersite fique comprometida caso um passe a ficar Off-line.

O que isto pode gerar? Se por alguma razão o controlador de domínio promovido manualmente como Bridgehead Server ficar Off-line e este for o único Bridgehead Server, você não terá a replicação intersites e caso não perceba isto o quanto antes para corrigir, você poderá ter problemas com o controlados de domínio do site.

Perceba que o uso do ISTG para gerar Bridgehead Server de forma dinâmica ou não é algo que será definido de acordo com o ambiente onde você estará configurando os sites e suas necessidades.

Clique agora sobre o objeto NTDS Settings abaixo do objeto do controlador de domínio.

adds-sites-and-services-0014

Veja que existem dois objetos de conexão criados automaticamente (Automatically Generated) pelo KCC. O que estes objetos representam?

Objetos de conexão dentro de NTDS Settings representam conexões de onde o controlador de domínio obtém alterações.

Podemos dizer então que o controlador de domínio NYRK001DC0001 faz o download das alterações feitas nos controladores de domínio NLVP001DC0001 e NEUR001DC0001.

É importante mencionar que objetos de conexão possuem apenas um sentido, o de entrada (download).

Como funciona o processo de replicação intrasite?

Como já informado anteriormente, o KCC é o responsável pelas conexões criadas entre os controladores de domínio dentro de cada site.

Uma replicação intrasite ocorre apenas entre os controladores de domínio dentro do mesmo site e é composta por dois processos:

  • Notification
  • Polling

Notification

O processo de notificação ocorre quando qualquer controlador de domínio dentro um site efetua uma alteração em alguma partição do Active Directory.

adds-sites-and-services-0015

Exemplo

O controlador de domínio NYRK001DC0002 faz uma alteração em uma partição do Active Directory, coloca esta alteração em uma fila, aguarda 15 segundos e começa a notificar seus parceiros de replicação através de seus objetos de conexão que ele possui uma alteração.

O controlador de domínio NYRK001DC0002 informar ao seu parceiro NYRK001DC0001 que ele possui uma alteração. O controlador de domínio NYRK001DC0001 após ser informado da alteração faz uma requisição para o NYRK001DC0002 enviar o que ele tem de novo.

O controlador de domínio NYRK001DC0002 aguarda 3 segundos após informar o NYRK001DC0001 para informar seu próximo parceiro de replicação caso exista mais objetos de conexão.

O controlador de domínio NYRK001DC0002 recebe a requisição e através do seu DRA (Directory Replication Agent) inicia o envio da atualização para o NYRK001DC0001.

Polling

O processo de Polling se consiste em questionar seus parceiros de replicação para saber se eles possuem alguma alteração para ser replicada ou não. Este processo ocorre uma vez a cada hora por padrão como já informado quando falamos sobre NTDS Site Settings anteriormente.

Este processo também é feito para garantir que seus parceiros de replicação realmente estão online.

Exemplo

O controlador de domínio NYRK001DC0002 questionar seu parceiro de replicação NYRK001DC0001 se ele possui alguma alteração. Caso o parceiro tenha alguma alteração em fila, ele inicia o processo de replicação.

Se o controlador de domínio NYRK001DC0001 não responder a consulta e este problema ocorrer por repetidas vezes, o NYRK001DC0002 irá lançar o seu KCC para que o mesmo refaça a verificação da topologia de replicação e caso o NYRK001DC0001 esteja realmente off-line, ele irá corrigir os objetos de conexão para que a replicação volte a ter um estado consistente.

Como funciona o processo replicação intersite?

Diferente do processo intrasite, a replicação intersite funciona apenas com o processo de Polling, ou seja, o controlador de domínio NYRK001DC0001 que o Bridgehead Server do site YORK questiona os controladores de domínio NLVP001DC0001 e NEUR001DC0001.

adds-sites-and-services-0016

Este processo ocorre a cada três horas (180 minutos) por padrão e pode ser alterado ao modificar o valor do campo Replicate Every nas propriedades do site link.

adds-sites-and-services-0017

É importante saber que o número em minutos pode ser configurado para no mínimo quinze (15) minutos como mostrado da imagem anterior.

Qual a frequência da replicação intersites?

Da mesma forma que você pode desejar segmentar a replicação entre sites, você também pode querer que esta replicação ocorra em determinados momentos do dia para não comprometer seus enlaces de dados em horários de pico em sua produção.

Por padrão a replicação intrasite ocorre vinte e quatro (24) horas por dia, sete dias na semana como podemos ver na imagem abaixo após clicar no botão Change Schedule.

adds-sites-and-services-0018

Configure a frequência de replicação de acordo com a sua necessidade usando a interface anterior.

Quais são o protocolos envolvidos na replicação?

Quando estamos falando de replicação de abjetos no Active Directory nós estamos falando de dois meios (protocolos) que podem ser usados:

  • IP
  • SMTP

IP

Embora ao visualizar o diretório Inter-Site Transports você veja o diretório IP abaixo representando o protocolo de replicação, o que está de fato por trás deste objeto é o DS-RPC ou Directory Service – Remote Procedure Call.

Este protocolo é usado para todas as replicações no nível de intrasite e é o protocolo padrão/preferencial para as replicações no nível de intersite.

SMTP

O protocolo SMTP ou Simple Mail Transport Protocol, mesmo estando disponível para uso, não é utilizado normalmente.

Quais são os benefícios de se ter Sites no Active Directory?

Ao longo deste artigo eu mencionei diversas vezes que o propósito dos sites no Active Directory é ter uma maior controle sobre a operação de replicação, tanto intrasite como intersite.

Outro benefício que foi mencionado, mas não informado como funciona de fato, foi o da localização de serviços.

Como funciona a localização de serviços?

Primeiramente, para entendermos a localização de serviços, você precisa entender que os clientes utilizando registro no DNS para se orientar onde e em qual recurso eles devem procurar um determinado serviço.

Se você é familiarizado com os registro de DNS, você já deve ter notado alguns específicos chamados SRV ou Service Locator Record.

Quando um controlador de domínio é adicionado a uma infraestrutura de serviço de diretório ele utiliza registros SRV no DNS para oferecer serviços como Kerberos, LDAP, Global Catalog, etc.

Um registro SRV é usado para informar que um serviço é eferecido por um determinado host, ou seja, informar que o serviço de LDAP esta disponível no controlador de domínio NYRK001DC0002.

adds-sites-and-services-0019

Um registro SRV é composto das seguintes informações:

  • DOMAIN: informa onde este serviço está localizado.
  • Service: informa o tipo de serviço oferecido pelo host (FTP, HTTP, LDAP, KERBEROS, etc.).
  • Protocol: informa o tipo de protocolo de comunicação do serviço (tcp, udp, etc.).
  • Priority: este campo é usado para definir a prioridade em que o serviço deve ser requisitado pelos clientes. Clientes tentarão requisitar serviço de controladores de domínio que possuem a menor número no campo Priority.
  • Weight: este é um mecanismo idêntico ao usado em registro do tipo MX (Enchange) e permite que seja feito um balanceamento de quantas solicitações o host irá atender quando clientes solicitam serviços.
  • Port number: informa a porta onde o serviço está esperando ser solicitado no host.
  • Host offering this service: possui um FQDN (Fully Qualified Domain Name) do host que oferece o serviço.

Estes registros são adicionados em locais específicos na estrutura de diretórios do DNS como podemos ver a seguir.

adds-sites-and-services-0020

Na imagem anterior, nós podemos visualizar os registro no nível de domínio localizado em Forward Lookup Zones\nosafeforwork.local\_tcp.

Este diretório contém todos os registros SRV de todos os controladores de domínio do domínio nosafeforwork.local.

Como você deve ter percebido na imagem anterior, nossa estrutura de sites existe da mesma forma na estrutura de diretório do DNS e é a partir dela que a localização de serviços ocorre.

adds-sites-and-services-0021

Quando um computador/servidor membro precisa solicitar serviços no site YORK ele usa os registros SRV localizados no diretório Forward Lookup Zones\nosafeforwork.local\_sites\YORK\_tcp para saber quem oferece determinado tipo de serviço.

Como um cliente localiza um controlador de domínio?

Vamos imaginar que você precisa neste momento ingressar um novo computador no domínio NOSAFEFORWORK.LOCAL que pertence ao site de YORK. Você ingressa o computador no domínio corretamente e o reinicia para completar a tarefa. O que ele faz para localizar o controlador de domínio de seu site?

  1. O novo cliente solicita para o DNS todos os controladores de domínio no domínio NoSafeForWork.local através dos registros SRV localizados em Forward Lookup Zones\nosafeforwork.local\_tcp.
  2. Cliente faz uma solicitação de serviço de LDAP para todos os controladores de domínio retornados no passo um (1).
  3. O primeiro controlador de domínio que responder a solicitação de serviço LDAP verifica qual é o endereço IP do cliente solicitando o serviço.
  4. O mesmo controlador de domínio verifica se existem subnets definidas para sites no Active Directory.
  5. O controlador de domínio informa para o cliente que solicitou o serviço de LDAP que ele pertence ao site YORK.
  6. O cliente armazena em seu registro as informações sobre o site que ele pertence.
  7. O cliente faz uma solicitação para o DNS de todos os controladores de domínio através do registros SRV localizados no diretório Forward Lookup Zones\nosafeforwork.local\_sites\YORK\_tcp.
  8. O cliente solicita o serviço LDAP para todos os controladores de domínio retornados no passo sete (7).
  9. O primeiro controlador de domínio no site YORK que responder a solicitação do cliente faz a autenticação do mesmo para validar suas credencias, acessos, etc.
  10. O cliente cria uma afinidade com o controlador de domínio que respondeu a sua solicitação para futuras solicitações.
  11. Você reinicia o cliente.
  12. O cliente tenta solicitar o serviço de LDAP para o controlador de domínio que atendeu a sua solicitação pela última vez pela afinidade criada.
  13. O controlador de domínio não responde a solicitação por estar off-line.
  14. O cliente verifica as informações sobre o site armazenadas no registro.
  15. O cliente faz uma solicitação de serviço para todos os controladores de domínio em seu site.
  16. Os passos nove e dez são repetidos novamente.

Estes são os passos que um computador cliente membro de um domínio executa para ser autenticado pelo Active Directory.

Quando você possui sites, subnets e site links configurados corretamente, você tem como resultado a redução no overhead entre seus enlaces de dados que interconectam seus sites fisicamente.

Clientes em um sites usarão os recursos dentro de seu site para solicitar serviços e somente no caso de nenhum dos controladores de domínio responder a solicitação de serviço o cliente tentará localizar outro controlador de domínio próximo ao seu site para efetuar sua autenticação.

Conclusão

Podemos ver que a administração de sites e serviços do Active Directory é um processo perfeitamente estrutura e que pode ajudar quem administra serviço de diretório no momento de segmentar o tráfego de dados e maximizar o uso de seus enlaces.

Espero que estas informações tenham muito valor em seu dia proporcionando um maior entendimento de como este tipo de recurso pode afetar, seja de forma benéfica ou maléfica, a sua infraestrutura.

%d blogueiros gostam disto: