View a markdown version of this page

Modernização da zona DNS _msdcs - AWS Directory Service

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Modernização da zona DNS _msdcs

A modernização de uma _msdcs zona DNS é um pré-requisito obrigatório antes da criação do diretório Hybrid AD. Em ambientes modernos do Active Directory, _msdcs.<ForestRoot> é criado como uma zona replicada separada em toda a floresta armazenada na partição do ForestDnsZones aplicativo. Em ambientes legados originalmente criados no Windows NT 4.0 ou no Windows 2000 (e posteriormente atualizados), nunca _msdcs foi separado; ele existe simplesmente como um subdomínio padrão (subpasta) diretamente dentro do arquivo de zona do domínio pai.

Quando um novo controlador de domínio é promovido com o DNS instalado, seu processo de instalação procura a partição dedicada do _msdcs.<ForestRoot> aplicativo. Como ele não encontra uma zona autônoma, ele cria automaticamente uma nova _msdcs zona em branco localmente e reivindica autoridade sobre esse namespace. Isso impede completamente que o novo DC leia os registros do subdomínio legado na zona principal e atualiza a delegação do NS para apontar para si mesma.

O resultado é um conflito arquitetônico. Todos os clientes associados ao domínio agora são referenciados a um DC que tem uma _msdcs zona vazia, enquanto os registros reais do localizador de DC (_ldap._tcp.dc._msdcs,, registros do Catálogo Global_kerberos._tcp.dc._msdcs, CNAMEs do DC GUID) permanecem isolados no antigo subdomínio da zona principal, onde nenhum cliente pode acessá-los. Isso interrompe a autenticação Kerberos, a descoberta do LDAP e a localização do DC com reconhecimento do site em toda a floresta.

Design de zona _msdcs antigo versus moderno

Legado (subdomínio delegado)

Padrão no Windows Server 2000, 2003, 2008 e 2008 R2. Nesse design, _msdcs existe como um subdomínio delegado na zona principal. Os registros NS na zona principal apontam para DCs específicos como autoritativos para o namespace. _msdcs

Moderno (zona autônoma)

Padrão no Windows Server 2012 e versões posteriores. Nesse design, _msdcs.<forest> existe como sua própria AD-integrated zona, replicada para todos os DCs na floresta por meio da partição do ForestDnsZones aplicativo. Todos os DCs são autorizados e podem read/write gravar diretamente.

Como identificar o design da zona _msdcs

Você pode identificar o design _msdcs da sua zona executando o seguinte em qualquer controlador de domínio:

  1. Liste todas as zonas DNS e procure_msdcs:

    Get-DnsServerZone | Where-Object { $_.ZoneName -like "*_msdcs*" }

    Design moderno (nenhuma ação é necessária) — você verá uma _msdcs.<forest-name> lista como zona primária:

    ZoneName ZoneType IsAutoCreated IsDsIntegrated IsReverseLookupZone IsSigned -------- -------- ------------- -------------- ------------------- -------- _msdcs.premier.local Primary False True False False

    Design antigo (conversão necessária) — NÃO _msdcs.<forest-name> aparecerá na lista de zonas. Em vez disso, _msdcs existe somente como um subdomínio delegado na sua zona florestal. Você pode confirmar isso verificando os registros NS da delegação:

    Get-DnsServerResourceRecord -ZoneName "<forest-name>" -Name "_msdcs" -RRType NS

    Se isso retornar registros NS, seu ambiente usará o design de subdomínio delegado legado.

  2. Validação adicional — confirme o tipo de zona:

    # This will succeed on modern design Get-DnsServerZone -Name "_msdcs.<forest-name>" # If you get an error like "Zone _msdcs.<forest-name> was not found", you have the legacy design

Como modernizar a zona DNS _msdcs

Essas etapas devem ser executadas antes de iniciar a criação do diretório AWS Managed Microsoft AD Hybrid. Todas as etapas são executadas em controladores de domínio autogerenciados existentes com acesso ao Gerenciador de DNS com administrador de domínio e privilégios. DnsAdmins

  1. Crie a zona autônoma _msdcs

    Em um controlador de domínio autogerenciado existente:

    dnscmd localhost /ZoneAdd "_msdcs.<forest-name>" /DsPrimary /dp /forest

    Isso é criado _msdcs.<forest-name> como uma AD-integrated zona dedicada com escopo de Forest-wide replicação. Todos os DCs na floresta receberão uma cópia por meio da ForestDnsZones partição.

    Aguarde a propagação da replicação do AD:

    repadmin /syncall /AeD

    Verifique se a zona existe (executada em vários DCs):

    Get-DnsServerZone -Name "_msdcs.<forest-name>"
  2. Remova a delegação antiga da zona principal

    O antigo nó do _msdcs subdomínio e seus registros ainda existem na zona principal. Eles devem ser removidos para que as consultas de DNS sejam atendidas exclusivamente da nova zona autônoma.

    # Remove the _msdcs subtree (NS delegation + all child records) from the parent zone dnscmd localhost /NodeDelete <forest-name> _msdcs /tree /f
    Importante

    Execute essa etapa somente após confirmar que a zona autônoma foi criada com êxito na Etapa 1. Se você pular a Etapa 1, a exclusão dos registros antigos causará uma interrupção imediata.

  3. Forçar todos os DCs a registrar novamente os registros SRV

    Com o subdomínio antigo removido e a nova zona autônoma estabelecida, todos os DCs devem registrar novamente seus registros localizadores na nova zona.

    Execute o seguinte em cada controlador de domínio local:

    # Flush DNS cache ipconfig /flushdns # Restart Netlogon — this triggers re-registration of all SRV, CNAME, and A records net stop netlogon net start netlogon # Force host record registration ipconfig /registerdns
  4. Verificar

    Aguarde de 5 a 10 minutos pela replicação e, em seguida, verifique:

    Confirme os registros preenchidos na nova zona autônoma:

    Get-DnsServerResourceRecord -ZoneName "_msdcs.<forest-name>" -RRType SRV

    Você deve ver_ldap._tcp.dc,, _kerberos._tcp.dc_ldap._tcp.gc, e registros específicos do site para todos os DCs locais.

    Confirme se a resolução de DNS funciona de ponta a ponta:

    Resolve-DnsName "_ldap._tcp.dc._msdcs.<forest-name>" -Type SRV Resolve-DnsName "_kerberos._tcp.dc._msdcs.<forest-name>" -Type SRV

    Todos os DCs locais devem aparecer nos resultados.

    Confirme se a delegação antiga saiu da zona principal:

    Get-DnsServerResourceRecord -ZoneName "<forest-name>" -Name "_msdcs" -RRType NS -ErrorAction SilentlyContinue

    Isso não deve retornar nada.

    Para obter mais informações sobre a modernização de _msdcs zonas DNS, consulte Como dividir e migrar registros DNS de domínio secundário para uma zona DNS dedicada no site do blog Microsoft Core Infrastructure and Security.

Solução de problemas

Se a nova zona autônoma permanecer vazia após a Etapa 3:

O Netlogon não pode se registrar novamente se acreditar que os registros já existem. Forçar um novo registro limpo:

# Delete the Netlogon DNS registration cache Remove-Item "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DnsAvoidRegisterRecords" -ErrorAction SilentlyContinue # Restart Netlogon again net stop netlogon net start netlogon

Se os registros ainda não aparecerem, crie manualmente os registros críticos usando os valores da zona principal antiga (disponíveis no backup ou em outros DCs que os armazenaram em cache):

# Example: SRV record for LDAP DC locator Add-DnsServerResourceRecord -ZoneName "_msdcs.<forest-name>" -Name "_ldap._tcp.dc" -Srv -DomainName "dc1.<forest-name>" -Priority 0 -Weight 100 -Port 389 # Example: SRV record for Kerberos DC locator Add-DnsServerResourceRecord -ZoneName "_msdcs.<forest-name>" -Name "_kerberos._tcp.dc" -Srv -DomainName "dc1.<forest-name>" -Priority 0 -Weight 100 -Port 88

Se os aplicativos continuarem falhando após a conversão:

Limpe os caches de DNS nos servidores de aplicativos e máquinas clientes afetados:

ipconfig /flushdns

As entradas negativas do cache DNS (do período de interrupção) podem persistir por até 900 segundos (15 minutos) antes de expirar.