Práticas recomendadas para nomeação do Windows Active Directory?

Esta é uma pergunta canônica sobre a nomeação de domínio do Active Directory.

Depois de experimentar domínios do Windows e controladores de domínio em um ambiente virtual, percebi que ter um domínio do Active Directory nomeado de forma idêntica a um domínio DNS é uma má ideia (o que significa que ter example.comum nome do Active Directory não é bom quando temos o example.comnome do domínio registrado para uso como nosso site).

Essa pergunta relacionada parece apoiar essa conclusão , mas ainda não tenho certeza sobre quais outras regras existem para nomear domínios do Active Directory.

Existem práticas recomendadas sobre o que um nome do Active Directory deve ou não deve ser?

Este tem sido um tópico divertido de discussão sobre falha no servidor. Parece haver várias "visões religiosas" sobre o assunto.

Concordo com a recomendação da Microsoft : Use um subdomínio do nome de domínio da Internet já registrado da empresa.

Então, se você possui foo.com, use ad.foo.comou algo assim.

A coisa mais vil, a meu ver, é usar o nome de domínio da Internet registrado, literalmente, para o nome de domínio do Active Directory. Isso faz com que você seja forçado a copiar manualmente registros do DNS da Internet (como www) na zona DNS do Active Directory para permitir a resolução de nomes "externos". Eu já vi coisas totalmente tolas como o IIS instalado em todos os controladores de domínio de uma organização que executa um site que redireciona, para que alguém que entre foo.comno navegador seja redirecionado www.foo.compor essas instalações do IIS. Total disparate!

Usar o nome de domínio da Internet não oferece vantagens, mas cria "trabalho" toda vez que você altera os endereços IP aos quais os nomes de host externo se referem. (Tente usar DNS com balanceamento de carga geograficamente para os hosts externos e integrá-lo a essa situação de "DNS dividido" também! Gee-- isso seria divertido ...)

O uso desse subdomínio não tem efeito em coisas como entrega de email do Exchange ou sufixos de Nome Principal de Usuário (UPN), BTW. (Costumo ver as duas citadas como desculpas para usar o nome de domínio da Internet como o nome de domínio do AD.)

Eu também vejo a desculpa "muitas grandes empresas fazem isso". As grandes empresas podem tomar decisões estúpidas com a mesma facilidade (se não mais) do que as pequenas empresas. Não compro isso apenas porque uma grande empresa toma uma decisão ruim que de alguma forma faz com que seja uma boa decisão.

Existem apenas duas respostas corretas para esta pergunta.

1. Um subdomínio não utilizado de um domínio que você usa publicamente. Por exemplo, se sua presença pública na web for example.comseu AD interno, poderá ser chamado algo como ad.example.comou internal.example.com.

2. Um domínio de segundo nível não utilizado que você possui e não usa em nenhum outro lugar. Por exemplo, se sua presença na web pública for o example.comseu AD, poderá ser nomeado example.net desde que você tenha se registrado example.nete não o use em nenhum outro lugar!

Estas são suas únicas duas opções. Se você fizer outra coisa, estará se deixando aberto a muita dor e sofrimento.

Mas todo mundo usa .local!
Não importa. Você não deveria. Eu escrevi em blog sobre o uso de .local e outros TLDs inventados, como .lan e .corp . Sob nenhuma circunstância você deve fazer isso.

Não é mais seguro. Não são "práticas recomendadas", como algumas pessoas afirmam. E não tem nenhum benefício sobre as duas opções que propus.

Mas quero que o nome seja igual ao URL do meu site público, para que meus usuários estejam em example\uservez dead\user
Esta é uma preocupação válida, mas equivocada. Ao promover o primeiro controlador de domínio em um domínio, você pode definir o nome NetBIOS do domínio para o que quiser. Se você seguir meu conselho e configurar seu domínio ad.example.com, poderá configurar o nome NetBIOS do domínio examplepara que seus usuários façam logon como example\user.

Nas florestas e relações de confiança do Active Directory, você também pode criar sufixos UPN adicionais. Não há nada que o impeça de criar e definir @ example.com como o sufixo UPN principal para todas as contas em seu domínio. Quando você combina isso com a recomendação anterior do NetBIOS, nenhum usuário final verá o FQDN do seu domínio ad.example.com. Tudo o que eles vêem será example\ou @example.com. As únicas pessoas que precisam trabalhar com o FQDN são os administradores de sistemas que trabalham com o Active Directory.

Além disso, suponha que você use um espaço para nome DNS com horizonte dividido, o que significa que seu nome do AD é igual ao seu site público. Agora, seus usuários não podem acessar example.cominternamente, a menos que você os prefixe www.no navegador ou execute o IIS em todos os controladores de domínio (isso é ruim). Você também tem que selecionar doiszonas DNS não idênticas que compartilham um espaço para nome separado. É realmente mais complicado do que vale a pena. Agora imagine que você tem uma parceria com outra empresa e ela também tem uma configuração de DNS com horizonte dividido com o AD e a presença externa. Você tem um link de fibra particular entre os dois e precisa criar uma confiança. Agora, todo o seu tráfego para qualquer um dos sites públicos deles precisa atravessar o link privado em vez de sair pela Internet. Ele também cria todos os tipos de dores de cabeça para os administradores de rede dos dois lados. Evite isso. Confie em mim.

Mas mas ...
Sério, não há razão para não usar uma das duas coisas que sugeri. Qualquer outra maneira tem armadilhas. Não estou dizendo para você se apressar para alterar seu nome de domínio, se estiver funcionando e no lugar, mas se você estiver criando um novo AD, faça uma das duas coisas que recomendei acima.

Para ajudar na resposta da MDMarra:

Você deve nunca usar um nome DNS de rótulo único para o seu nome de domínio também. Isso estava / está disponível antes do Windows 2008 R2. Motivos / explicações podem ser encontradas aqui: Implantação e operação de domínios do Active Directory configurados usando nomes DNS de rótulo único | Suporte da Microsoft

Não se esqueça de NÃO usar palavras reservadas (uma tabela está incluída no link "Convenções de nomenclatura" na parte inferior desta postagem), como SYSTEM ou WORLD ou RESTRICTED.

Também concordo com a Microsoft no sentido de que você deve seguir duas regras adicionais (que ainda não foram definidas):

1. Você NÃO deve nomear seu domínio com base em algo que será alterado ou desatualizado. Os exemplos incluem nomear seu domínio após uma linha de produtos, sistema operacional ou qualquer outra coisa que provavelmente mude ao longo do tempo. Atenha-se a algo geográfico ou concreto o suficiente para fazer sentido 5 ou 10 anos depois.
2. Atenha-se com nomes curtos de 15 caracteres ou menos, isso permitirá que o nome NETBIOS seja facilmente o mesmo que o nome de domínio.

Finalmente, eu recomendaria que você pensasse a longo prazo, tanto quanto possível. As empresas passam por fusões e aquisições, mesmo pequenas empresas. Pense também em termos de obter ajuda / consulta externa. Use nomes de domínio, estrutura do AD etc., que serão explicáveis ​​para consultores ou pessoas aqui no SF sem muito esforço.

Links de conhecimento:

http://technet.microsoft.com/en-us/library/cc731265%28v=ws.10%29.aspx

http://support.microsoft.com/kb/909264

http://support.microsoft.com/kb/300684/en-us

Página de recomendação atual da Microsoft (W2k12) para o nome de domínio da floresta raiz

Não concordo em usar:

• example.com - por razões já indicadas em outras respostas

Eu poderia aceitar usar:

• ad.example.com - - por motivos já mencionados em outras respostas

Mas eu não faria isso sozinho ou o recomendaria. Durante a aquisição da empresa, a rebranding de todo o mundo se abre, especialmente quando a gerência naquele momento quer que as coisas mudem imediatamente. Renomeando migrações, as alterações são muito difíceis ou caras.

A melhor maneira que eu recomendaria é comprar um domínio irrelevante para o nome da empresa e também irrelevante para a marca da empresa. SIMPLE.CLOUD ou similar deve funcionar muito bem desde que você seja o proprietário.

Vi grandes empresas com 150 mil usuários usando o AD que ainda fazem referência a empresas antigas que compraram anos atrás ou empresas que mudaram de nome e, mesmo que não importe a longo prazo que você esteja usando \ login (se não puder use UPN) ainda parece ruim para a gerência que não entende por que não é trivial alterá-lo.

Eu sempre faço mydomain.local.

local não é um TLD válido, portanto nunca concorre com uma entrada DNS pública real.

Por exemplo, eu gosto de saber que web1.mydomain.localresolverá o IP interno de um servidor da Web, enquanto web1.mydomain.comresolverá o IP externo.