Parece que o seu grupo "Suporte de Desktop" possui direitos excessivos, o que permite que os membros sobrescrevam atributos em contas de computador existentes.
Não há funcionalidade específica para impedir a entrada de computadores com nomes existentes. Ao não delegar os direitos do grupo "Suporte à área de trabalho" para modificar objetos de computador existentes, você remove a capacidade de membros do grupo modificarem objetos de computador existentes.
Se eu fosse você, faria o seguinte:
-
Crie uma UO no seu Active Directory para as contas de computador recém-criadas "aterrissarem" (quando criadas com a funcionalidade padrão de junção de domínio da GUI no sistema operacional cliente). Vou chamar isso de UO "Novos computadores".
-
Redirecione o contêiner padrão "Computadores" para a unidade organizacional "Novos computadores" usando o utilitário
redircmp(a Microsoft tem detalhes de uso específicos ) -
Delegue os direitos de grupo "Suporte à área de trabalho" a "Criar objetos de computador" à UO "Novos computadores".
Os membros do grupo "Suporte de Desktop" poderão ingressar computadores no domínio e os objetos de computador recém-criados terminarão na UO "Novos computadores". Eles não irão, assumindo que você removeu as associações de usuários em qualquer grupo com privilégios mais altos, poderá modificar objetos de computador existentes e, portanto, não poderá ingressar computadores no domínio com nomes que são usados por computadores associados a o domínio já.
Editar:
Não consigo reproduzir o comportamento que você está vendo re: "... um erro sobre não poder alterar o nome DNS do domínio primário".
Esteja ciente de que as permissões padrão definidas nos objetos do computador quando você está testando o comportamento do produto. A conta que você usa para criar o objeto de computador é definida como o proprietário e a permissão concedida (como PROPRIETÁRIO CRIADOR) para o objeto recém-criado. Se você estiver usando a mesma conta para adicionar o computador "conflitante", essas permissões permitirão que você "quebre" a conta original do computador. Não estou ciente de nenhuma maneira de substituir esse comportamento. Sua melhor aposta para evitar que esse comportamento cause problemas seria redefinir programaticamente o proprietário em objetos de computador recém-criados para "Administradores" e reaplicar a ACL padrão (para remover as ACEs que se referem ao PROPRIETÁRIO CRIADOR original).
Eu entrei em uma máquina chamada "TEST-SVR01" para o meu domínio de teste usando um membro do meu grupo "Desktop Support". Depois que fiz isso, redefini a propriedade do objeto de computador TEST-SVR01 para "Administradores" e reapliquei as permissões padrão (usando o botão "Padrão" na caixa de diálogo de segurança "Avançado").
Eu tentei unir outra máquina chamada TEST-SVR01 ao domínio usando o mesmo usuário-membro "Desktop Support" e recebi a mensagem de erro "Acesso negado" durante a tentativa. O TEST-SVR01 original ainda tinha uma relação de confiança intacta com o domínio.
Não há no simples (ou, na minha opinião, aconselhável) maneira de tornar os membros do grupo "Domain Admins" incapazes de alterar as contas de computador existentes. Você provavelmente poderia fazer algo repugnante com as permissões "Negar", mas fará com que o produto se comporte de maneira muito diferente do padrão. Eu diria que você não deveria estar usando contas de membros do "Domain Admins" para unir computadores ao domínio. O princípio do menor privilégio dita que você só deve usar contas de membros do "Domain Admins" para executar funções para as quais seus direitos excessivos são necessários, e unir os computadores ao domínio não precisa desses direitos excessivos.