Somente leitura de controlador de domínio para local de teste independente / externo

Question

Em um piscar de olhos: um cliente precisa testar um sistema de CRM habilitado para Active Directory que consiste em um SQL 2008 Server e um Windows 2008 Standard Server (o servidor de aplicativos). Tanto quanto sei, o Active Directory é necessário para a autenticação do usuário final e para a autenticação de aplicativo para SQL.

Precisamos extrair esses dois servidores do ambiente de domínio atual e configurá-los em uma instalação de teste que tenha conectividade com a Internet, mas que não esteja no domínio ( foo.local ) ou em qualquer domínio desse tipo; eles são apenas um monte de estações de trabalho em um grupo de trabalho no momento.

Meu pensamento inicial foi configurar um túnel IPSec para a localização do cliente para / do recurso de teste, mas estou querendo saber se a sobreposição da sub-rede LAN seria um problema (firewalls pfSense aqui) para gerenciar e / ou se alterar o Endereços IP dos dois servidores ( FOOAPP e FOOSQL ) para uma sub-rede diferente para evitar a sobreposição causariam algum sofrimento no AD (ou seja, o controlador de domínio não "saberia" quem são esses servidores).

Meu outro pensamento foi configurar um Controlador de Domínio Somente Leitura e trazê-lo para a instalação de testes, mas a partir da minha leitura superficial dos documentos do technet, parece que ele precisa ser capaz de falar com o domínio de localização do cliente controlador (es).

Por fim, sei que você pode autenticar uma estação de trabalho off-line com credenciais em cache: isso funcionaria com um servidor membro? Estou assumindo que não como a autenticação SQL que ocorre entre FOOAPP e FOOSQL provavelmente não utiliza o cache, mas, por favor, me ilumine, se não.

Alguma outra opção?

ESCLARECIMENTO

Esses servidores não estão sendo usados na produção no momento. Enquanto eles se juntam ao domínio do cliente, não há dados nele e ninguém está usando; eles são apenas servidores membros ociosos no momento. O banco de dados SQL será carregado com dados de teste e usado para treinamento, mas os colocaremos de volta no local do cliente e, assim, em produção após a conclusão desse período de treinamento do usuário / aceitação final (com os dados de teste removidos) .

Não podemos fazer o teste / treinamento no local porque seria muito prejudicial para o escritório do cliente e eles não têm uma grande sala de reuniões para acomodar os grupos de teste / treinamento.

EDITAR

Eu acho que isso tudo pode ser destilado em duas perguntas:

1. O que acontece com um controlador de domínio (Somente leitura | Gravável) quando é isolado de outros controladores de domínio?

2. O Active Directory "se preocupa" com endereços IP? i.e. talvez eu possa colocar esses dois servidores em uma sub-rede diferente temporariamente e configurar um túnel IPSec para que esses servidores e estações de trabalho na instalação de teste possam se comunicar com o domínio no escritório do cliente.

Answer 1

O Active Directory funciona por padrão em um modo replicação multimaster , em que cada controlador de domínio é autoritário independentemente para o (s) domínio (s) que gerencia. Assim, os DCs de teste ainda poderão manipular logins e receber atualizações (mudanças de senha e similares) mesmo quando desconectados. Os dois conjuntos de DCs (os vivos e os que estão no local de teste) vão divergir lentamente ao longo do tempo, mas isso é apenas um problema se você pretende convergi-los depois.

Esta é minha sugestão para lidar com este cenário:

1. Faça um backup de estado do sistema completo de cada controlador de domínio de teste antes de realocá-los.
2. Reposicione os DCs de teste e faça com que eles se instalem (junte-se às estações de trabalho no domínio, crie usuários, etc.).
3. Execute seus testes.
4. Quando você estiver pronto para restaurar os DCs para o serviço de produção, faça um restauração não autoritativa dos backups de estado do sistema que você tirou anteriormente. Isso irá redefinir os DCs para o estado anterior do sistema (é claro).
5. Retorne os DCs de teste à rede original e ligue-os novamente. Eles reconhecerão que suas cópias dos dados do Active Directory estão lamentavelmente desatualizadas (devido à antiga USNs ) e começar a enviar solicitações de replicação para os DCs de produção que estiveram lá o tempo todo.

Answer 2

Como isso é apenas para testes, você considerou a execução de uma VM em uma das máquinas e configurá-la como uma DC? Algo como o Virtualbox, apesar de não ser uma boa escolha para uso em produção, faria bem neste caso.

    

Answer 3

1) Quando um DC padrão é isolado de outros DCs no domínio, ele continuará a executar todas as suas funções, porque cada AD DC é capaz de trabalhar sozinho; você só terá problemas se precisar de acesso a uma das funções FSMO (como executar uma extensão de esquema ou ficar sem RIDs para novos usuários), mas isso só acontece em algumas situações muito específicas que você provavelmente não executará em um ambiente de teste. É claro que, se você realizar qualquer modificação no AD em um dos dois segmentos (como criar uma conta de usuário ou mesmo alterar uma senha), isso não será replicado para o outro ... e se você planeja reconectá-los , você provavelmente encontrará conflitos de replicação.

Isso não se aplica aos RODCs: se um deles estiver isolado do resto da rede e você não tiver nenhum DC gravável disponível (mesmo por meio de um link WAN), a maioria das funções do AD não estará disponível; você não poderá criar / modificar qualquer coisa , e isso, é claro, inclui unir computadores ao domínio, gerenciar grupos de angs de contas de usuários, etc.

2) O AD se preocupa com os endereços IP para duas coisas: replicar dados e localizar o controlador de domínio disponível "mais próximo" para evitar tráfego desnecessário da WAN; ambas as funções dependem da definição de sites, sub-redes e links de sites. Se você quiser configurar um link de WAN para um local com um endereçamento IP diferente da sua LAN principal e colocar um controlador de domínio nesse local, será necessário definir um site e uma sub-rede no console de Serviços e Sites do Active Directory; isso permitirá que o AD gerencie a replicação entre os DCs no local principal e no local, e também informará aos servidores e clientes nesse local para falar com o DC local.

    

Answer 4

Veja o que eu proporia:

Configure uma rede isolada no host ESXi atual. Clone os servidores existentes necessários para o teste e coloque-os na rede isolada. Se necessário, você pode analisar as funções FSMO no DC isolado, pois ele é isolado da rede de produção e não terá ramificações para a rede de produção. Participe de um cliente de teste no domínio isolado e realize seu teste.

Esta parece ser a solução mais fácil para mim.

    

Answer 5

Um problema que você deve considerar ao mover um DC para o modo off-line (na rede de produção) é que, se estiver fora da rede de produção por mais tempo que ele, ele pode conter objetos que foram removidos do rede de produção (conhecido como objetos remanescentes) e pode haver problemas de consistência quando é reconectado à rede de produção. Eu experimentei esses problemas e não foi bonito.

Não precisa ser problemático se você resolver alguns problemas no processo. Se o domínio era originalmente Windows 2000 e atualizado para 2003, a idade da marca de exclusão é de 60 dias, em que, se começou como um domínio do Windows 2003, a idade da marca de exclusão é de 180 dias. Você pode alterar a idade da marca para exclusão, mas isso exige que você execute o ADSIedit ou outra ferramenta para modificar diretamente a partição do Serviço de Diretório do Active Directory e não sei se você ficaria confortável com isso ou não. (o caminho é: CN = Serviços de Diretório, CN = Windows NT, CN = Serviços, CN = Configuração, DC = seudominio, DC = yourdomainsuffix) Isso fará com que o Active Directory ocupe mais espaço em seus DCs, pois eles manterão < em> all removeu objetos por mais tempo antes de excluí-los completamente.

Antes de desconectar o DC externo, certifique-se de sincronizar a hora para minimizar qualquer desvio de tempo enquanto estiver fora do local. A parte importante é quando reconectar, você deve primeiro configurar consistência de replicação rígida nos DCs da rede de produção anterior para reintroduzir o off site DC (usando a ferramenta Repadm com a opção / regkey) e certifique-se de configurar o DC externo para uma restauração não-autoritativa , também anterior à reconexão, para que o novo SYSVOL seja replicado assim que possível.