O Active Directory

Usando Catch-todas as sub-redes no Active Directory

John Policelli

Visão geral:

• O localizador do controlador de domínio
• A topologia de hub e spoke
• Implementação de uma sub-rede catch-tudo

Conteúdo

Como os clientes localizar controladores de domínio
O problema
A sub-rede Catch-tudo
Quebra automática para cima

Em um mundo ideal, os usuários são direcionados para o controlador de domínio apropriado (DC) para autenticação do Active Directory. No entanto, isso não é necessariamente o caso na maioria das organizações devido a informações de sub-rede IP não sendo corretamente definidas no Active Directory. Como resultado, um número de usuários autenticar em um controlador de domínio arbitrário, que não é ideal para autenticação do Active Directory.

Neste artigo, forneço uma possível solução para garantir que os usuários localizem o DC apropriado para autenticação quando informações de sub-rede IP não é totalmente definidas no Active Directory.

Como os clientes localizar controladores de domínio

Quando um computador tenta localizar um controlador de domínio, um processo chamado o localizador de controlador de domínio (Localizador) é iniciado, portanto, o controlador de domínio do Active Directory apropriado pode ser localizado. Localizador usa as informações que é armazenado no Active Directory e DNS para tentar localizar um controlador de domínio com as funções desejadas e que está localizada em um site mais próximo ao cliente.

O localizador usa informações definida no recipiente de configuração no domínio raiz da floresta, que é replicado para cada controlador de domínio na floresta. Objetos de site, objetos de sub-rede e objetos de servidor de controlador de domínio são todos imperativas para o localizador localizar o controlador de domínio mais próximo de um computador cliente. Objetos de site são usados para representar sites do Active Directory. Objetos de sub-rede são usados para representar os segmentos de endereço IP e são associados ao objeto de site apropriado. Objetos de servidor de controlador de domínio são usados para representar os controladores de domínio e estão associados a um objeto de site.

Os controladores de domínio do Active Directory registram registros DNS que especificam o site no qual reside o controlador de domínio. O número de registros DNS que cada controlador de domínio registra depende das funções que tem o controlador de domínio. Por exemplo, um controlador de domínio é um servidor de catálogo global irá registrar um registro de DNS adicional que anuncia próprio como tal. Da mesma forma, um controlador de domínio que possua função de mestre de operações registrará um registro DNS que anuncia próprio como isso.

O processo de um computador cliente localizar um controlador de domínio é da seguinte maneira:

1. O Localizador é iniciado no computador cliente como uma chamada de procedimento remoto (RPC) para o serviço Logon de rede local.
2. O cliente coleta as informações necessárias à seleção de um controlador de domínio e passa as informações para o serviço de logon de rede.
3. O serviço de logon de rede no computador cliente usa as informações coletadas para criar uma consulta para enviar para o DNS para identificar o controlador de domínio apropriado.
4. O serviço de logon de rede no computador cliente envia um datagrama para controladores de domínio descobertos.
5. O serviço de diretório intercepta a consulta e passa para o serviço Logon de rede no controlador de domínio.
6. O serviço de logon de rede no controlador de domínio consulta o endereço IP do cliente na sua tabela de mapeamento de sub-rede para o site por localizar o objeto de sub-rede que mais parecido com o endereço IP do cliente e, em seguida, retorna as seguintes informações para o cliente: o nome do site no qual o cliente está localizado ou o site que mais parecido com o endereço IP do cliente; o nome do site em que o controlador de domínio atual está localizado; e um bit que indica se o CD encontrado está localizado no site mais próximo ao cliente.
7. O cliente inspeciona as informações para determinar se ele deve tentar localizar um controlador de domínio melhor. A decisão é tomada da seguinte maneira: se o controlador de domínio retornado estiver no site mais próximo, o cliente usa esse controlador de domínio; se o cliente tiver encontrado um controlador de domínio no site no qual o controlador de domínio declara o cliente está localizado, o cliente usa esse controlador de domínio; se o controlador de domínio for não no site mais próximo, o cliente atualiza suas informações de site e envia uma nova consulta DNS para localizar um novo controlador de domínio no site. Se a segunda consulta for bem-sucedida, o novo controlador de domínio é usado. Se a segunda consulta falhar, o controlador de domínio original será usado.
8. Se o domínio que está sendo consultado pelo cliente for o mesmo que o domínio ao qual o computador está associado, o site no qual o computador reside é armazenado no Registro no computador cliente.
9. Após o cliente localiza um controlador de domínio, a entrada do controlador de domínio é armazenada em cache. Se o controlador de domínio não estiver no site ideal, o cliente libera o cache depois de quinze minutos e descarta a entrada de cache. Em seguida, ele tenta encontrar um controlador de domínio ideal no mesmo site como o cliente.

No caso em que um computador cliente usa um endereço IP que não está representado na tabela de mapeamento de sub-rede para o site, o controlador de domínio retorna um nome de site NULL e o cliente usará o controlador de domínio retornado, que pode residir em qualquer site do Active Directory.

O problema

Se o controlador de domínio não é possível determinar o site mais próximo, devido às informações de sub-rede IP não sejam definidas no Active Directory, autenticação, em seguida, usa um controlador de domínio que não é ideal.

a Figura 1 ilustra um design de site do exemplo do Active Directory que utiliza uma topologia hub e spoke. Usuários que fazem logon em um computador que está em uma das sub-redes que são definidas no Active Directory são direcionados para um controlador de domínio em seu site mais próximo do Active Directory para autenticação. No entanto, os usuários que fizerem logon partir de um computador que esteja na outra sub-rede, por exemplo 10.1.4.0/24, são direcionados para um controlador de domínio arbitrário.

Figura 1 Criar site de topologia de hub e spoke de exemplo

A correção apropriada para resolver esse problema, é claro, é definir as sub-redes adicionais no Active Directory e associá-los o site apropriado. No entanto, as organizações (especialmente médias e grandes empresas) muitas vezes problemas de face obter as informações necessárias para adicionar esses sub-redes adicionais para o Active Directory. Mais especificamente, os administradores do Active Directory geralmente ficar atento a existência das sub-redes adicionais por meio de erros e arquivos de log, mas não souber qual office físico nestas sub-redes pertencem a, impedindo que identifica o site para associar a sub-rede com.

A sub-rede Catch-tudo

Uma solução mais prática para o problema é usar uma ou mais sub-redes catch-tudo no Active Directory. Uma sub-rede catch-tudo é uma sub-rede do Active Directory que é usada para capturar a autenticação de clientes que estão em sub-redes que não são definidas no Active Directory. Uma sub-rede catch-tudo é essencialmente um super-subnet.

Conforme mostrado na Figura 1 , a sub-rede 10.1.1.0/24 é definida no Active Directory e associada com o site do Active Directory Toronto. Digamos que você perceber que um número de clientes em sub-redes 10.1.4.0/24 e 10.1.5.0/24 estiver autenticando em relação ao Active Directory. Você acredita que nestas sub-redes estejam no escritório Toronto baseado no prefixo (10.1.x.x). Você deseja garantir que os computadores nestas sub-redes, bem como quaisquer outras sub-redes que usam o prefixo 10.1.x.x, autenticar em um controlador de domínio no site Toronto. Portanto, você criar uma sub-rede catch-tudo, que usa o prefixo 10.1.0.0/16, para direcionar a autenticação de todas as sub-redes você acha que a ser localizado no escritório Toronto, e você garantir que a autenticação usa um controlador de domínio no site Toronto. O mapeamento de sub-rede catch-tudo para esse exemplo é mostrado no texto vermelho na Figura 2 .

A Figura 2 com uma sub-rede catch-todos os sites de hub

Na maioria das organizações, as informações de sub-rede IP para escritórios remotos são comunicadas aos administradores do Active Directory. O intervalo normalmente existe para sub-redes IP para escritórios centrais, locais concentradores e centros de dados. A sub-rede catch-tudo pode ser usada para melhorar a autenticação no bem nesses casos. Uma vez que as sub-redes IP para escritórios remotos são relativamente estáticas, e você geralmente tem um bom entendimento nestas sub-redes, você pode criar uma sub-rede catch-tudo para todas as outras sub-redes.

Neste exemplo, você pode criar uma sub-rede catch-tudo, que usa o prefixo 10.0.0.0/8 capturar a autenticação de todas as sub-redes que você acha que não pertencem a um escritório remoto e certifique-se a autenticação usa um controlador de domínio no site Toronto central. O mapeamento de sub-rede catch-tudo para esse exemplo é mostrado no texto vermelho na Figura 3 . E você ainda pode usar várias sub-redes de catch-tudo, conforme mostrado na Figura 4 , se você desejar.

A Figura 3 uma sub-rede catch-todos para todos os locais

A Figura 4 com várias sub-redes catch-tudo

Observe na Figura 3 e 4 que as sub-redes catch-todos os usar um prefixo que sobrepõe os prefixos usados em sites remotos (10.0.0.0/8 aborda 10.1.1.0/24 por exemplo). Você deve estar se perguntando se a autenticação de computadores os escritórios remotos será ainda direcionada para um controlador de domínio no escritório remoto apropriado como resultado. A resposta é Sim. Quando sobrepostos sub-redes IP existirem no Active Directory, a sub-rede IP com a máscara de sub-rede menor correspondente é usada. Por exemplo, 10.1.1.0/24 será usado em vez de 10.0.0.0/8 se o computador tiver um endereço IP da sub-rede 10.1.1.5/24. No entanto, 10.1.1.1./32 será usado em vez de 10.1.1.0/24 para um computador que tem um endereço IP do 10.1.1.5.

Quebra automática para cima

Antes de prosseguir e implementar sub-redes catch-tudo, você precisará ser ciente de que o conceito de uma sub-rede catch-todos os não é adequado para todos os ambientes. A viabilidade de tal solução depende muito de seu esquema de endereçamento IP.

Nos exemplos que forneci aqui, o esquema de endereçamento de IP é bastante simples. No entanto, como o esquema de endereçamento IP se torna mais complexo, se a viabilidade de usando sub-redes catch-todos os tornará menos provável. Por exemplo, se seu ambiente constituída de vários segmentos de rede e a esquema de endereçamento IP não for seqüencial em cada local, ele será praticamente impossível criar sub-redes catch-tudo que irão fornecer nenhum valor. Como com todas as soluções, você precisará considerar o técnicas, comerciais e fatores ambientais específicos do seu ambiente ao determinar a viabilidade da implementação de sub-redes catch-todos os.

E observe que o uso de sub-redes catch-todos os não resolver o problema de falta sub-redes totalmente. Na verdade, se você introduzir sub-redes catch-tudo em seu ambiente, é ainda mais importante que você explicitamente defina todas as sub-redes conhecidas no Active Directory.

O uso de sub-redes catch-todos os irá aumentar o número de usuários que localizem o controlador de domínio mais próximo. No entanto, seu objetivo ainda deve ser endereçar a origem do problema e garantir que receberão as informações apropriadas para todas as adições, modificações e remoções de sub-redes da rede para que possa manter um design de site do Active Directory atualizado que fornece autenticação eficiente para todos os usuários.

John Policelli (MVP da Microsoft para Directory Services, MCTS MCSA com certificação, ITSM, iNet +, Network + e A +) é consultor de TI da concentra-se de soluções com uma década de sucesso combinado em arquitetura, segurança, planejamento estratégico e planejamento de recuperação de desastres. John passou os últimos anos de nove enfoca o gerenciamento de identidades e acesso e fornecer planejado liderança para alguns das instalações maiores do Active Directory no Canadá. John mantém um blog em http://policelli.com/blog.