Nesse artigo vou descrever porque não utilizar no Active Directory domínios .LOCAL ou .INTERNO. 

Um fato interessante

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, 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. 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.

Se você gostou desse artigo, deixe seu comentário abaixo, assim poderemos interagir e saber sua opinião. Você também pode compartilhar esse artigo, além de seguir nossas páginas nas redes sociais para acompanhar os novos artigos.