Nomes de usuário do Active Directory: por que o nome canônico varia? Posso fazer algo para torná-los uniformes?

Eu sou um administrador autodidata de uma rede do Active Directory de trabalho usada para logins do Windows em ~ 30 PCs. Eu herdei o sistema de outra pessoa que também não teve nenhum treinamento direto da Microsoft e, como resultado, estou no escuro em algumas coisas.

A própria rede possui uma única máquina com Windows Server 2008 R2 atuando como controlador de domínio, DNS, compartilhamento de arquivos etc. Os logins funcionam bem, mas eu estava vasculhando a lista de usuários enquanto desabilitava contas antigas e notei algo que não entendi direito. .

Aqui estão algumas contas de usuário de exemplo:

1. Nome de logon: john
   Nome: John
   Sobrenome: Smith
   Nome para exibição: John Smith
   Nome canônico do objeto: domain.com/Users/john

2. Nome de logon: bob
   Nome: Bob
   Sobrenome: Francês
   Nome para exibição: Bob French
   Nome canônico do objeto: domain.com/Users/Bob French

O controlador de domínio atual foi trocado por outro que costumava executar o Windows Server 2003. A primeira conta de exemplo foi criada quando a caixa do Server 2003 era DC, a segunda foi criada quando a caixa mais recente do Server 2008 R2 era o DC. Por que o nome canônico é diferente e faz alguma diferença?

Estou muito chateado pelo fato de minha lista de usuários no navegador do Active Directory ter metade das contas como 'primeiro nome' e metade como 'primeiro nome sobrenome'.

Posso fazer algo para tornar todos iguais sem quebrar as contas de trabalho?

O Active Directory realmente não se preocupa com o modo como o RDN do objeto de conta de usuário (a última parte do Nome Canônico) se relaciona com outras propriedades, como o Nome para Exibição ou o Nome de Logon - desde que o valor de cada atributo individual não viole o definição de esquema.

O comportamento do formulário "Novo usuário" nos Usuários e Computadores do Active Directory (assim como em vários outros diálogos) mudou significativamente entre o Windows Server 2003 e o Windows Server 2008 R2 - e é provavelmente por isso que eles não são consistentes

Você pode usar o PowerShell para mover as contas que não são do sistema, percorrer os usuários e renomeá-los para qualquer que seja o nome para exibição:

# Create new OU named RegularUsers
New-ADOrganizationalUnit -Name RegularUsers -Path "dc=domain,dc=com"

# Retrieve all users that are not critical system objects
$users = Get-ADUser -SearchBase "CN=Users,DC=domain,DC=com" -SearchScope OneLevel -Filter {-not(isCriticalSystemObject -like '*')}

# Go through each and move to the new OU
foreach($user in $users){
    Move-ADObject $user -TargetPath "OU=RegularUsers,DC=domain,DC=com"
}

# Retrieve all users in the new OU
$movedUsers = Get-ADUser -SearchBase "CN=Users,DC=domain,DC=com" -SearchScope OneLevel -Filter '*'

foreach($user in $movedUsers){
    # Test if Display Name and object Name is the same, if not - rename
    if($user.DisplayName -ne $user.Name)
    { 
        Rename-ADObject $user -NewName "$($user.DisplayName)" 
    }
}

Para a primeira etapa, você também pode destacar todas as contas de usuário no ADUC e arrastá-las e soltá-las para outro local.

O CN / DN de um objeto não é tão relevante, pois é usado apenas internamente pelo AD e em consultas LDAP; os usuários finais (e administradores) raramente vêem isso. Na verdade, ele muda sozinho quando você move objetos, porque inclui o caminho LDAP completo do objeto.

Se você deseja padronizá-lo, isso pode ser feito sem efeitos colaterais; a única coisa com a qual os usuários realmente se preocupam é o nome de logon e, desde que você não mude isso , eles continuarão a fazer logon normalmente.

Para alterá-lo, você pode usar o console do ADUC ou o comando PowerShell Rename-ADObject .

O comando dsmove deve poder alterar o nome canônico para você. Eu fiz isso em ambientes de teste, mas nunca em ambientes ativos, por isso aconselho a continuar com cautela.

Além disso, semi-relacionado, eu recomendaria a implementação de outro controlador de domínio para evitar dor de cabeça caso o seu único controlador de domínio ocorra.