Como fazer fallback para o servidor de login fora do site - ActiveDirectory

Question

Eu praticamente gasto todo o meu tempo no Linux \ Networking, no entanto, estou tentando configurar uma configuração de AD de vários sites. Não existe um site raiz ou algo assim, eu simplesmente tenho dois DCs no SiteA e um DC no SiteB. Todos eles se replicam entre si.

Estou fisicamente no SiteB. Antes de configurar os sites nos Serviços e sites do Active Directory, minha máquina de teste alternava entre SiteB-DC01 , SiteA-DC01 e SiteA-DC02 . Depois de configurar isso (sites e sub-redes), minhas máquinas SiteA estão usando os DCs do SiteA e minhas máquinas SiteB estão usando meus DCs do SiteB. Eu confirmo isso emitindo um echo %LOGONSERVER% .

Tudo isso é bom, mas ...

O que acontece quando o DC do SiteB cai? Para simular isso eu tirei o DC do SiteB e os clientes no SiteB reclamaram que No logon server could be found .

Eu tentei criar um registro _ldap SRV adicional em Forward Lookup Zones->DOMAIN->_sites->SiteB->_tcp sem sucesso. Eu defini a prioridade do SiteB DC como 0 e o SiteA DC como 1. Esta é a maneira correta de fazer isso?

Além disso, quais são as diferenças entre todos os diferentes locais de registro SRV? Não consegui encontrar muita documentação que tenho:

• DOMAIN- > Sites- > SITE_HERE- > _tcp
• DOMAIN- > _tcp
• _msdcs.DOMAIN- > dc- > _sites- > SITE_HERE- > _tcp
• _msdcs.DOMAIN- > dc- > _tcp

O senso comum me diria que o cliente (ele sabe em qual site está, pois está no registro) faria uma consulta DNS específica do site para localizar todos os DCs e escolher um para auth com base nas prioridades e pesos .

    

Answer 1

Seus clientes ... eles usam outros resolvedores de DNS além do controlador de domínio que você colocou offline? A redundância no Active Directory não adianta se seus clientes não tiverem nenhum servidor DNS de failover com o qual localizar um controlador de domínio alternativo ...

Pessoalmente, eu recomendaria a configuração de todos os membros de seu domínio para usar primeiro dois controladores de domínio em seu próprio site e, em seguida, um controlador de domínio de um site adjacente como um resolvedor de DNS terciário. (Os benefícios de usar resolvedores de DNS adicionais depois do terceiro caíram acentuadamente, na minha opinião.) Em produção, eu recomendaria dois controladores de domínio por site, mas é claro que em um ambiente de laboratório ou de desenvolvimento é compreensível ver apenas um CD por local. .

Em geral, aconselho contra a criação manual de registros SRV para controladores de domínio no Active Directory. Os DCs em um ambiente saudável devem registrar e manter seus próprios registros SRV.

Existe um recurso de "cobertura automática de sites" do Active Directory onde, quando o AD vê um site que não contém controladores de domínio, os DCs de sites adjacentes registram "seus registros SRV" nesse outro site, bem como na tentativa para fornecer cobertura para os clientes que podem estar nesse site ... Eu coloquei "utilmente" entre aspas porque o recurso pode causar confusão se você se perguntar como os registros chegaram lá.

Additionally, what are the differences between all of the different SRV record locations?

A zona _msdcs.forestname.com é replicada em toda a floresta e contém registros SRV que os clientes podem usar para localizar serviços de domínio em toda a floresta, como LDAP, catálogos globais, KDCs, etc.

A subzona _msdcs que está abaixo da zona domainname.forestname.com, aquela com o ícone "greyed out", é uma subzona delegada. Ele é delegado especificamente para esse domínio. Se você tiver uma floresta de domínio único, provavelmente não verá muita diferença, mas é muito mais fácil ver a diferença em uma floresta de vários domínios com uma estrutura complexa de DNS.