Tempo de leitura: 5 minutos
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, onde 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 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.
Leia também: Qual tipo de disco escolher em máquinas virtuais no Hyper-V?
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 orientaçã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.
E 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 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 nestas 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.
Leia também: Você sabe a diferença entre Azure Active Directory e Windows Server Active Directory?
Deve-se considerar ainda 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.
Seja qual for a necessidade de segurança da sua empresa, a Infomach possui a solução ideal para você. Nossos especialistas tem desenhado e implementado projetos das 4 diferentes camadas de segurança para empresas de todos os tamanho em 23 estados do Brasil. Clique aqui para conversar com um consultor especializado ou ligue 0800 494 9001.
