Como consultar o Active Directory a partir de uma máquina não associada ao domínio?

Use o construtor DirectoryEntry com caminho LDAP explícito, nome de usuário (no formato DOMÍNIO\Usuário ou usuario@dominio.com) e senha. Certifique-se de que o DNS esteja configurado para resolver o nome de domínio do AD, que as portas 389 (LDAP) e 88 (Kerberos) estejam abertas e que as credenciais tenham acesso de leitura ao diretório.

Quais portas precisam estar abertas para conectividade com o Active Directory?

No mínimo: TCP/UDP 389 (LDAP), TCP 636 (LDAPS), TCP/UDP 88 (Kerberos), TCP 445 (SMB), TCP/UDP 53 (DNS) e TCP 135 mais as portas RPC dinâmicas 49152-65535 para comunicação com o controlador de domínio.

O domínio especificado não existe ou não pôde ser contatado

Q: O que causa o erro 'The specified domain either does not exist or could not be contacted'?

Este erro ocorre quando uma máquina não consegue localizar ou se comunicar com um controlador de domínio do Active Directory. Causas comuns incluem configuração DNS incorreta (a máquina não consegue resolver o nome do domínio para o endereço IP de um DC), regras de firewall bloqueando as portas LDAP 389/636 ou a porta Kerberos 88, a máquina não estar associada ao domínio ao tentar autenticação de domínio, ou credenciais incorretas passadas no código .NET usando DirectoryEntry ou DirectorySearcher.

Compreendendo o erro

A mensagem de erro “The specified domain either does not exist or could not be contacted” é lançada pelo namespace System.DirectoryServices no .NET quando o aplicativo não consegue estabelecer uma conexão com um controlador de domínio do Active Directory. Este é um problema comum ao executar consultas do Active Directory a partir de máquinas que não estão associadas ao domínio ou de ambientes com restrições de rede entre o cliente e o controlador de domínio.

O erro geralmente ocorre ao usar as classes DirectoryEntry, DirectorySearcher ou PrincipalContext:

// This works on a domain-joined machine but may fail on a non-domain machine
DirectoryEntry entry = new DirectoryEntry("LDAP://example.com");
DirectorySearcher searcher = new DirectorySearcher(entry);
searcher.Filter = "(samaccountname=jsmith)";
SearchResult result = searcher.FindOne(); // Throws the error

Causas comuns

1. Falha na resolução DNS

A causa mais frequente é que a máquina cliente não consegue resolver o nome de domínio do Active Directory para o endereço IP de um controlador de domínio. O Active Directory depende fortemente do DNS — especificamente dos registros SRV que informam aos clientes onde encontrar os controladores de domínio.

2. Bloqueio de rede/firewall

Mesmo que o DNS resolva corretamente, firewalls entre o cliente e o controlador de domínio podem bloquear as portas necessárias para comunicação LDAP, Kerberos ou RPC.

3. Máquina não associada ao domínio sem credenciais adequadas

Uma máquina que não está associada ao domínio não possui uma conta de computador ou confiança implícita com o domínio. Você deve fornecer credenciais explicitamente no seu código.

4. Caminho LDAP ou nome de domínio incorretos

Um erro de digitação no nome de domínio ou caminho LDAP, ou usar um nome NetBIOS quando apenas nomes DNS estão disponíveis (ou vice-versa).

5. Controlador de domínio indisponível

O controlador de domínio de destino pode estar inativo, sobrecarregado ou inacessível devido a problemas de roteamento.

Diagnosticando o problema

Etapa 1: Verificar a resolução DNS

A partir da máquina cliente, teste se o nome do domínio é resolvido:

nslookup example.com
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.com

A consulta de registro SRV é crítica — isso é exatamente o que as classes DirectoryServices do .NET usam para localizar controladores de domínio. Se esta consulta não retornar resultados, a conectividade com o Active Directory falhará.

# PowerShell alternative
Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.example.com" -Type SRV

Se a resolução DNS falhar, configure as definições DNS da máquina cliente para apontar para um servidor DNS que hospede as zonas integradas ao AD (normalmente o próprio controlador de domínio):

# Set DNS server to the domain controller
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses "10.0.1.10","10.0.1.11"

Etapa 2: Testar a conectividade de rede

Verifique se as portas necessárias estão abertas entre o cliente e o controlador de domínio.

Portas necessárias para o Active Directory:

Porta	Protocolo	Serviço
53	TCP/UDP	DNS
88	TCP/UDP	Kerberos
135	TCP	RPC Endpoint Mapper
389	TCP/UDP	LDAP
445	TCP	SMB
636	TCP	LDAPS (SSL)
3268	TCP	Global Catalog
3269	TCP	Global Catalog SSL
49152-65535	TCP	RPC dinâmico

Teste a conectividade com as portas críticas:

# Test LDAP port
Test-NetConnection -ComputerName dc01.example.com -Port 389

# Test Kerberos port
Test-NetConnection -ComputerName dc01.example.com -Port 88

# Test LDAPS port
Test-NetConnection -ComputerName dc01.example.com -Port 636

# Test DNS
Test-NetConnection -ComputerName dc01.example.com -Port 53

Etapa 3: Usar nltest para verificar a descoberta do controlador de domínio

Na máquina cliente (se estiver associada ao domínio):

nltest /dsgetdc:example.com

A saída esperada deve mostrar o nome do DC, endereço e site. Se este comando falhar, a máquina não consegue localizar um controlador de domínio.

Para uma máquina não associada ao domínio, você pode testar com:

nltest /dsgetdc:example.com /force

Etapa 4: Executar dcdiag no controlador de domínio

No próprio controlador de domínio, execute diagnósticos para garantir que os serviços do AD estejam funcionando corretamente:

dcdiag /v

Preste atenção a estes testes:

Connectivity — Verifica a resolução DNS e a conectividade LDAP
Replications — Verifica a saúde da replicação
Services — Verifica se os serviços relacionados ao AD estão em execução
KnowsOfRoleHolders — Confirma o conhecimento dos papéis FSMO

Etapa 5: Verificar os serviços do Active Directory

No controlador de domínio, certifique-se de que estes serviços estejam em execução:

Get-Service -Name "NTDS","DNS","KDC","Netlogon" | Select-Object Name, Status

Todos os serviços devem mostrar o status Running.

Correção para código .NET em máquinas não associadas ao domínio

Fornecer credenciais explícitas

Ao conectar-se de uma máquina que não está no domínio, você deve fornecer credenciais explicitamente:

// Correct approach for non-domain machines
string ldapPath = "LDAP://dc01.example.com/DC=example,DC=com";
string username = "EXAMPLE\\serviceaccount";  // or "serviceaccount@example.com"
string password = "SecurePassword123";

DirectoryEntry entry = new DirectoryEntry(ldapPath, username, password, AuthenticationTypes.Secure);

DirectorySearcher searcher = new DirectorySearcher(entry);
searcher.Filter = "(samaccountname=jsmith)";
searcher.PropertiesToLoad.Add("displayName");
searcher.PropertiesToLoad.Add("mail");

SearchResult result = searcher.FindOne();
if (result != null)
{
    Console.WriteLine(result.Properties["displayName"][0]);
}

Usar um controlador de domínio específico

Em vez de depender da descoberta de DC baseada em DNS, conecte-se a um controlador de domínio específico:

// Connect directly to a known DC by hostname or IP
string ldapPath = "LDAP://10.0.1.10/DC=example,DC=com";
DirectoryEntry entry = new DirectoryEntry(ldapPath, username, password, AuthenticationTypes.Secure);

Usar PrincipalContext com conexão explícita

Para .NET 3.5 e posterior, PrincipalContext fornece uma API mais limpa:

using System.DirectoryServices.AccountManagement;

// Connect to a specific domain with explicit credentials
PrincipalContext ctx = new PrincipalContext(
    ContextType.Domain,
    "dc01.example.com",          // Domain controller
    "DC=example,DC=com",         // Container
    ContextOptions.Negotiate,     // Authentication method
    "EXAMPLE\\serviceaccount",   // Username
    "SecurePassword123"          // Password
);

// Search for a user
UserPrincipal user = UserPrincipal.FindByIdentity(ctx, IdentityType.SamAccountName, "jsmith");
if (user != null)
{
    Console.WriteLine($"Name: {user.DisplayName}, Email: {user.EmailAddress}");
}

Tratar o erro de forma elegante

Sempre envolva as operações do AD em tratamento de exceções adequado:

try
{
    DirectoryEntry entry = new DirectoryEntry(ldapPath, username, password, AuthenticationTypes.Secure);

    // Force the connection to validate credentials
    object nativeObject = entry.NativeObject;

    DirectorySearcher searcher = new DirectorySearcher(entry);
    searcher.Filter = "(samaccountname=jsmith)";
    SearchResult result = searcher.FindOne();
}
catch (DirectoryServicesCOMException ex)
{
    // Specific AD errors
    Console.WriteLine($"AD Error: {ex.Message}, Extended: {ex.ExtendedErrorMessage}");
}
catch (System.Runtime.InteropServices.COMException ex)
{
    if (ex.ErrorCode == unchecked((int)0x8007054B))
    {
        Console.WriteLine("The specified domain does not exist or could not be contacted.");
        Console.WriteLine("Check DNS configuration and network connectivity to the domain controller.");
    }
}

Configurando o DNS na máquina cliente

Se a máquina cliente não estiver usando os servidores DNS corretos, as consultas ao Active Directory falharão independentemente das alterações no código.

Windows

:: Set DNS server via netsh
netsh interface ip set dns "Local Area Connection" static 10.0.1.10 primary
netsh interface ip add dns "Local Area Connection" 10.0.1.11 index=2

Verificar a configuração DNS

ipconfig /all | findstr "DNS Servers"

Adicionar um encaminhador condicional

Se o cliente usa uma infraestrutura DNS diferente, adicione um encaminhador condicional no servidor DNS para o domínio do AD:

# On the client's DNS server
Add-DnsServerConditionalForwarderZone -Name "example.com" -MasterServers "10.0.1.10","10.0.1.11"

Configuração de regras de firewall

Se houver um firewall entre o cliente e o controlador de domínio, abra as portas necessárias.

Firewall do Windows no controlador de domínio

# Allow LDAP
New-NetFirewallRule -DisplayName "AD LDAP" -Direction Inbound -Protocol TCP -LocalPort 389 -Action Allow
New-NetFirewallRule -DisplayName "AD LDAP UDP" -Direction Inbound -Protocol UDP -LocalPort 389 -Action Allow

# Allow LDAPS
New-NetFirewallRule -DisplayName "AD LDAPS" -Direction Inbound -Protocol TCP -LocalPort 636 -Action Allow

# Allow Kerberos
New-NetFirewallRule -DisplayName "AD Kerberos" -Direction Inbound -Protocol TCP -LocalPort 88 -Action Allow
New-NetFirewallRule -DisplayName "AD Kerberos UDP" -Direction Inbound -Protocol UDP -LocalPort 88 -Action Allow

# Allow Global Catalog
New-NetFirewallRule -DisplayName "AD GC" -Direction Inbound -Protocol TCP -LocalPort 3268 -Action Allow

Usando ADUC (Usuários e Computadores do Active Directory) remotamente

Se você precisa gerenciar o AD a partir de uma máquina que não está no domínio usando ADUC:

Instale as Ferramentas de Administração de Servidor Remoto (RSAT)
Abra o ADUC e selecione Ação > Conectar ao Domínio
Insira o FQDN do domínio (por exemplo, example.com)
Se solicitado, forneça credenciais de domínio

Se o ADUC mostrar o mesmo erro, a causa raiz é no nível de rede (DNS ou firewall), não relacionada ao código.

Resumo

O erro “specified domain either does not exist or could not be contacted” se resume à incapacidade da máquina cliente de localizar e se comunicar com um controlador de domínio. Comece verificando a resolução DNS dos registros SRV do domínio AD, depois teste a conectividade de rede nas portas 389, 636 e 88. Para aplicativos .NET em máquinas que não estão no domínio, sempre forneça credenciais explícitas no construtor DirectoryEntry e conecte-se a um controlador de domínio específico por nome de host ou IP. Use nltest e dcdiag para validar a saúde do ambiente Active Directory.