Porque não se deve utilizar no Active Directory domínios terminados com “.local” ou “.interno”.

Um fato interessante que percebo em várias implantações do Active Directory, realizadas algumas vezes por “especialistas” é o uso do nome da organização seguido do sufixo “.local”, “.interno”, “.lan” ou “.intra”, sem falar em outras variações possíveis para o FQDN (Fully Qualified Domain Name) do Active Directory. O mais comum é o “.local”, a origem dessa prática provavelmente vem do Windows 2008 Small Business Server, que por padrão criava o nome do domínio como “.local”. Logo muitos acreditam que esta é a melhor prática, só que o modelo do Small Business Server (que concentra Windows Server, Exchange, SQL Server em um mesmo servidor), foi projetado para ser implantado em pequenas empresas em que a pessoa que está implantando não tem o conhecimento técnico necessário para realizar uma implantação complexa com vários servidores.

Alguns profissionais, justificam que como “.local” não um TLD (Top Level Domain) válido, isso torna a implementação segura contra ataques externos, o que de fato não procede. Primeiramente você não deve expor seu Active Directory para a Internet, usualmente o seu servidor deve estar em um segmento de rede protegido por Firewall. Outro motivo é que se o  servidor estiver exposto, tanto faz se ele está com um TLD válido ou não, para o atacante isso não fará muita diferença.

Outras justificativas, incluem o gerenciamento complexo do DNS, portanto seria mais fácil usar o “.local”. Em partes esta justificativa procede, porém volto a dizer você não deve utilizar os mesmos servidores DNS externos para resolução de nomes internos, até mesmo pelo fato de concepção, o ideal é que o servidor de DNS interno esteja no segmento de rede interno e o servidor de DNS externo esteja em uma DMZ ou algo do tipo, expor o DNS interno publicamente é um risco elevado. Se a organização usa BIND (por exemplo, DNS no Linux) é possível configurar duas zonas com o mesmo nome e com respostas diferentes (conforme a origem da requisição). Mas o ideal no Active Directory é que o DNS seja provido pelos próprios controladores de domínio, afinal o Active Directory é fortemente baseado no DNS.

Vamos voltar um pouco no tempo, no início dos anos 2000, quando o Active Directory surgiu pela primeira vez com o Windows Server 2000, naquela época a Microsoft disponibilizou um guia de melhores práticas para desenho do Active Directory (Best Practices Active Directory Design for Managing Windows Networks), sei que são recomendações de 15 anos atrás, mas continuam válidas. A recomendação é que o domínio do Active Directory (vou me referir simplesmente AD) seja definido com o mesmo nome do seu domínio registrado no “registro.br” ou qualquer outra entidade de registro que garanta a unicidade do nome. Logo se trabalho na organização Exemplo LTDA e o domínio de Internet é exemplo.com.br logo devo usar o mesmo no AD, outra alternativa é utilizar um subdomínio, como ad.exemplo.com.br.

Mas enfim, quais os problemas se eu quiser continuar utilizando “.local” ou outras variações? Bem você poderá ter problemas caso sua organização venha a se fundir com outra, ser adquirida ou comprar outra organização que por azar pode possuir o mesmo domínio no AD com a terminação “.local”. Sei que essa possibilidade é remota, então vou lhe fornecer mais um motivo: Existe uma orientação do CA/Browser Fórum que não recomenda a emissão de certificados emitidos por uma autoridade certificadora para domínios não válidos (https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf). Ok, sei que os defensores da prática podem alegar que ainda será possível gerar certificados auto-assinados no AD e distribuí-los para as máquinas, mas penso que o melhor caminho é seguir as práticas recomendadas.

Outra questão que merece antenção, vejo que estas implementações “.local” (e suas variações) o nome NetBios por muitas vezes é denominado AD ou SERVER, ou seja quando o usuário vai efetuar logon, teremos algo semelhante a: AD\fulano.siclano. Voltando a nossa organização Exemplo LTDA, seria mais elegante utilizar o nome “EXEMPLO” e termos algo como: EXEMPLO\fulano.siclano.

Deve-se considerar que você pode ter problemas utilizando FQDN’s personalizados, se você algum dia precisar implantar DNSSEC, poderá ter problemas, sem contar que os equipamentos da Apple utilizam o serviço Bonjour de descoberta e configuração automática de dispositivos que por sua vez usa o sufixo ”. local” nativamente, talvez isso possa gerar problemas, caso o diretor (ou outro colaborador) da organização prefira trabalhar utilizando um dispositivo da Apple na sua rede.


Contato Infomach

A Infomach fornece soluções de segurança da informação e infraestrutura para que empresas possam criar, inovar e crescer.

Comentários

  1. Fabiano Rocha disse:

    Arles, boa tarde!
    Meu nome é Fabiano Rocha, também atuo no mesmo segmento a mais 10 anos. Trabalho na Máxima Sistemas (somos parceiros) a alguns anos junto ai com o Antônio. Estou ajudando um outro parceiro, onde o mesmo acaba de contratar um novo site com hospedagem na Locaweb, virou seu site no último fim de semana, vou usar nome fictício para não expor. Seu site empresa.com.br tem o mesmo nome no domínio interno e externo. Estão com problemas na rede interna para ter acesso a algumas aplicações que rodam junto com o site, como abertura de chamados, webservice com licenças, etc… Como informou em seu post: ” A recomendação é que o domínio do Active Directory seja definido com o mesmo nome do seu domínio registrado no “registro.br” ou qualquer outra entidade de registro que garanta a unicidade do nome. Logo se trabalho na organização Exemplo LTDA e o domínio de Internet é exemplo.com.br logo devo usar o mesmo no AD.” Existe alguma recomendação da Microsoft que faz referencia a isto?
    Deixo aqui ressalvas! E mesmo com todo seu conhecimento, respeito, mas não concordo!
    Comentou ainda que, “.local” padrão dos Sistemas Operacionais Small Business deve ser implantado em pequenas empresas e em que a pessoa que está implantando não tem o conhecimento técnico necessário para realizar uma implantação complexa com vários servidores.

    Como assim? Temos um grupo de TI aqui em Goiânia e a opinião é unânime, todos recomendam nome no domínio interno diferente do domínio externo.

    Neste parceiro, qual seria a solução? Como ficaria a configuração do DNS interno e externo?

    Att,

    Fabiano Rocha

    1. Luiz Henrique Lemes de Andrade disse:

      Olá Fabiano, bom dia. Meu nome é Luiz Andrade, atuo em infraestrutura de TI a mais de 10 anos e minha opinião e implementações sempre foi utilizar o sufixo “.local”.
      Sobre o caso que você comentou, eu recomendo criar registros do tipo HOST na zona “empresa.com.br” apontando para o endereço externo ou interno do recurso, conforme necessário. Ex. Site empresa.com.br no ip 213.12.56.98, Intranet intranet.empresa.com.br no ip 192.168.0.10

    2. Arles Sant Ana disse:

      Fabiano,

      Desclupe não responder antes. Vamos a sua dúvida:
      Referências:
      How DNS Support for Active Directory Works (https://technet.microsoft.com/pt-br/library/cc759550(v=ws.10).aspx)
      Namespace planning for DNS (https://technet.microsoft.com/en-us/library/cc759036(v=ws.10).aspx)
      Best Practice Active Directory Design for Managing Windows Networks (https://technet.microsoft.com/en-us/library/bb727085.aspx)
      Livro: MCSE: Windows Server 2003 Active Directory and Network Infrastructure Design Study Guide (70-297) página 114.

      Usar o FQDN único é tão comum que quando você usa o Azure AD, se seu domínio for .local ou outro, você terá que criar um SPN com o seu domínio publico para realizar a integração do seu AD local com o Azure. O problema que você mencionou é facilmente resolvido com a utilização de dois DNS servers, um para resoluções externas e outro integrado ao seu AD para resoluções internas. Como eu mencionei no artigo não é uma boa prática colocar o servidor DNS que responde pelo seu domínio no AD para responder consultas DNS externas.
      Veja as referências que informei acima, elas podem ajudar

      Se ainda persistir dúvidas, por favor me informe que tentarei esclarecer.

    3. Arles Santana disse:

      Fabiano,

      Desclupe não responder antes. Vamos a sua dúvida:
      Referências:
      How DNS Support for Active Directory Works (https://technet.microsoft.com/pt-br/library/cc759550(v=ws.10).aspx)
      Namespace planning for DNS (https://technet.microsoft.com/en-us/library/cc759036(v=ws.10).aspx)
      Best Practice Active Directory Design for Managing Windows Networks (https://technet.microsoft.com/en-us/library/bb727085.aspx)
      Livro: MCSE: Windows Server 2003 Active Directory and Network Infrastructure Design Study Guide (70-297) página 114.

      Usar o FQDN único é tão comum que quando você usa o Azure AD, se seu domínio for .local ou outro, você terá que criar um SPN com o seu domínio publico para realizar a integração do seu AD local com o Azure. O problema que você mencionou é facilmente resolvido com a utilização de dois DNS servers, um para resoluções externas e outro integrado ao seu AD para resoluções internas. Como eu mencionei no artigo não é uma boa prática colocar o servidor DNS que responde pelo seu domínio no AD para responder consultas DNS externas.
      Veja as referências que informei acima, elas podem ajudar

      Se ainda persistir dúvidas, por favor me informe que tentarei esclarecer.

    4. Alvaro Rodrigues disse:

      Olá Fabiano, boa tarde!

      Na realidade, eu tb discordo (ou concordo parcialmente) com o artigo. A Microsoft não recomenda que se use o mesmo nome do domínio externo, mas sim um subdomínio deste domínio externo. Neste artigo da Technet estas informações podem ser conferidas: https://social.technet.microsoft.com/wiki/contents/articles/34981.active-directory-best-practices-for-internal-domain-and-network-names.aspx

      Eu particularmente utilizei por muitos anos o domínio “.local”, mas após a leitura deste pequeno artigo e de verificar as referencias contidas nele, passei a utilizar tb o que é recomendado.

      By the way, ótimo artigo Arles. Na realidade se não fosse por ele eu ainda estaria fazendo a coisa errada. Obrigado!!

  2. Enio Basso disse:

    Gostei do artigo Arles!

    Já conheci várias empresas que caíram nessa armadilha do .local e .interno, criada pelo AD.

    Vejo o uso do domínio DNS único com as seguinte perspectiva:

    – Endereços internos e externos com domínio DNS único, como empresa.com.br, facilitam a utilização pelos funcionários. Antes mesmo de uma pessoa trabalhar na empresa, ela já acessou a mesma para enviar um CV. 🙂

    – Os usuários acessam as informações através de 3G, Wifi e VPN, com domínios DNS únicos o “roaming” é a transparente.

    – As empresas devem ter sempre 2 DNS Servers, um interno e outro externo, pois nem todos os serviços/servidores vão estar expostos na Internet, mas os funcionários
    vão fazer uso destes serviços externos e internos.

    – Aplicações e soluções de Single-Sign-On utilizam cookies/sessões, que por sua vez necessitam domínios de Internet.

    – Os devices disponíveis na rede não seguem mais a regra Wintel, hoje é comum encontrar nas empresas MacOs, Linux, Android, iOS e outros BYOD. O padrão para eles todos é domínio DNS.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *