Configuração do Active Directory: Alguém pode explicar informações conflitantes?

Question

Se você olhar para as Práticas recomendadas da Microsoft para configurar uma nova floresta / domínio, elas serão algumas recomendações que entram em conflito com outras recomendações on-line e não são seguidas por nenhuma das empresas com as quais trabalhei.

Por exemplo, as práticas recomendadas especificam o uso de nomes DNS registrados com uma autoridade da Internet no namespace do Active Directory, porque eles são globalmente exclusivos. Em seguida, eles recomendam adicionar um prefixo ao nome DNS registrado para criar um novo nome subordinado. Por exemplo, se o nome da raiz do DNS for contoso.com, você deverá criar um nome de domínio raiz da floresta do Active Directory, como concorp.contoso.com ...

Em muitos lugares, vejo recomendações contra o uso de nomes registrados na Internet devido ao roteamento do tráfego da rede interna para o IP externo e problemas com compartilhamentos DFS. Também raramente vejo empresas usarem o esquema de nomenclatura "corp.company.com" para o domínio. Eles geralmente usam algo como "company.com" ou "company.local".

Por fim, as práticas recomendadas recomendam deixar o domínio raiz vazio para o gerenciamento do domínio e criar um único domínio filho global. Seguir esta prática resultaria em nomes de domínio como "domain.corp.company.com", que eu nunca vi implementado.

Existem razões pelas quais as melhores práticas não são seguidas ou estão sendo seguidas e eu simplesmente não estou olhando para a direita para ver a estrutura?

    

Answer 1

Pena que eu não estava acordado para a festa, né? Eu vou dar um jeito mesmo assim.

Eu lecionei aulas de MCSE por vários anos, e as recomendações da Microsoft sempre foram bastante consistentes entre seus vários materiais de treinamento.

• Não use um nome de domínio que você não possui para o seu nome de domínio do Active Directory (por exemplo, microsoft.com).

• Não use um FQDN para o domínio que outros servidores DNS já são autoritativos (por exemplo, company.com)

• Use um FQDN para o domínio globalmente exclusivo (por exemplo, ad.company.com, corp.company.com).

Acredito que a "recomendação" do TLD ".local" começou na época do Windows Small Business Server 2003. O TLD ".local" não é reservado pela ICANN, embora seja duvidoso, neste momento, que jamais seria usado "de verdade" na Internet (o protocolo Zeroconf também tem dependências do TLD ".local", acredito).

Eu já estive em muitos ambientes onde o "company.com" foi usado para o nome de Domínio do AD, necessitando de hacks estúpidos que envolviam a cópia manual de registros DNS dos servidores DNS da Internet nos servidores DNS que suportam o AD. Eu respondi a um monte de perguntas neste site que se resumem a essa pobre escolha de nome de domínio, fazendo com que os hacks tenham que ser implementados (ter que executar servidores web para redirecionamentos para o site "real" "company.com" em todos os sites). Controlador de domínio AD, etc.).

Não sei por que as empresas persistem em fazer o esquema de nomenclatura "company.com" para domínios do AD. Isso só cria problemas. Não há qualquer bom argumento porque você deve fazê-lo, e "vai contra" o princípio básico do DNS que apenas um conjunto de servidores DNS no mundo deve ser autoritativo para um determinado nome de domínio DNS . (Muitas vezes ouço o argumento "sufixo UPN". Se você quiser que os usuários tenham um sufixo UPN de "@ company.com", por exemplo, você pode fazer isso sem realmente nomear o domínio "company.com". os usuários podem ter sufixos UPN "@ whitehouse.gov" se você quiser, considerando o nome do domínio ...)

Sempre gostei de "ad.company.com".

A ideia de domínio "raiz vazia" é puramente uma construção política. Originalmente (período de tempo do W2K), a Microsoft promoveu a "raiz vazia" como uma maneira de isolar as preocupações de segurança entre partes de uma organização e, ao mesmo tempo, ter uma única infraestrutura de AD. Felizmente, eles desistiram dessa atitude (embora não tenham necessariamente voltado e corrigido todos os documentos que estavam errados), uma vez que foi demonstrado que qualquer membro de "Admins. Do Domínio" em qualquer domínio da floresta do AD pode, de forma justa. facilmente, tornar-se membros do grupo "Enterprise Admins".

Então, hoje em dia "raiz vazia" só é realmente usada para fins políticos. Eu diria que não há lugar para isso porque adiciona complexidade desnecessária (nunca, jamais, um ambiente de domínio múltiplo onde um ambiente de domínio único serve) e não oferece vantagens reais .

Se você deseja o isolamento de segurança entre as preocupações em sua organização, você deve usar uma implantação de várias florestas (que é absolutamente o tipo menos divertido de ambiente e deve ser evitado a todo custo).

    

Answer 2

O que você está descrevendo é direto das classes do MCSE.

Uma coisa a ter em mente sobre suas melhores práticas é que eles estão falando sobre experiências extraídas de implementações massivas do Active Directory.

Eu não quero assumir muito, mas com base na sua pergunta, eu estou supondo que você está no segmento SMB? Nem todas essas práticas recomendadas se aplicam necessariamente a esse espaço devido a questões de escala.

Com relação ao nome de domínio DNS, a sugestão de escolher um domínio "real" provavelmente se baseia em uma floresta do AD que também hospeda o Exchange. Essa configuração facilita o gerenciamento. Um método melhor é registrar o domínio real e, em seguida, alterar o TLD para .local para AD. Seu nome de domínio DNS do AD seria contoso.local e o nome "real" contoso.com. Em seguida, você configura um sufixo SPN alternativo para o nome real do Exchange. Soa como um aborrecimento, mas vale a pena não lidar com o DNS dividido, etc.

No que diz respeito a como lidar com o domínio raiz da floresta, a sugestão deles é baseada em uma segurança mais estritamente delineada para o gerenciamento de objetos dentro da floresta. Você pode ter limites organizacionais que exigem que determinados departamentos / unidades de negócios, etc. tenham um administrador de domínio para seu domínio. Existem outros benefícios, mas é provavelmente o mais comum.

    

Answer 3

Eu vou te dar os princípios que eu vou ...

1. Para um ambiente de domínio, use sempre um sufixo de domínio que não seja da Internet , ou seja .lan ou .local - isso pode se tornar realmente grande coisa muito rapidamente devido ao DNS. Digamos que você tenha seu site hospedado em outro local com alguns subdomínios, e seu site é company.com, e seu domínio do AD também é company.com. Suas estações de trabalho procuram www.company.com para ir para o seu site, mas o DNS do AD responde com um "não encontrado" porque acha que é a autoridade do company.com, e você não tem nenhuma máquina na rede chamada "www" . O cenário inverso é verdadeiro quando você tem usuários de VPN; seus usuários VPN podem tentar acessar myserver.company.com, mas a pesquisa DNS vai para o servidor DNS do seu site, em vez do servidor AD .... você começa a deriva. O sufixo .lan atenua isso.
2. Se você sabe que eventualmente terá filiais para dar suporte, o domínio raiz em branco faz sentido. Caso contrário, não há motivos para adicionar a complexidade adicional e o controlador de domínio adicional.

Answer 4

O chamado "domínio de espaço reservado de raiz" (raiz de floresta vazia) pode ser realmente útil em grandes organizações, onde os cenários de mesclagem / divisão são mais prováveis; Se você já tiver necessidade de criar outros domínios na floresta e passar para um modelo de administração mais descentralizado, é bom ter um local próprio para manter as contas administrativas em toda a floresta e as funções FSMO. Não é possível mover ou renomear o domínio raiz da floresta, portanto, se você pensar precisar de um nome distinto para essa finalidade, será necessário criá-lo desde o início.

Isso é completamente inútil para organizações pequenas, e também tem o custo adicional de exigir pelo menos dois servidores adicionais para atuar como DCs no segundo domínio.