Alterando o Domínio nos Desktops Windows

Se você já teve que reinstalar um SAMBA (mantendo o mesmo nome do Domínio) e os Desktops Windows tiveram que ser reingressados no domínio e ao logar no Desktop Windows percebeu que os Perfis de Usuários não foram preservados então continue lendo esse artigo, pois descrevo a solução que encontrei para estes problemas e disponibilizo um "script" que resolve estes problemas.

Aos apressados: baixe o change-domain.zip e descompacte dentro do compartilhamento \\SERVIDOR\netlogon. Dois arquivos são extraídos:

• Permissions-To-NewDomain.vbs - o script propriamente dito (escrito em VBscript)
• SetACL.EXE - um aplicativo que faz o papel do CACLS.EXE (nativo do Windows) com mais opções. É um GPL e está disponível em http://setacl.sourceforge.net/html/examples.html

Após ter ingressado o Windows no DOMAIN-A, logue com um usuário do grupo "Domain Admins" e não como "Administrador" local. Dê dois cliques no script e aguarde o relatório de migração ser exibido. É isso mesmo, um relatório com os perfis convertidos ao novo domínio e (principalmente) os comandos executados no Windows será mostrado automaticamente pelo editor de textos padrão Windows (NOTEPAD).

Aos interessados em entender o problema detalho abaixo minha experiência:

Imaginemos a seguinte situação:

1. você instala um SAMBA para atuar como PDC do domínio DOMAIN-A
2. cria diversos usuários (USER-A, USER-B, ..., USER-N)
3. ingressa diversas máquinas nesse domínio (MACHINE-A, MACHINE-B, ..., MACHINE-N)
4. tudo funciona perfeitamente bem, até que um dia o servidor apresenta um problema sério de Hardware e não tem salvação, ou seja, foi pro lixo.
5. você tem backups diários de todos os dados compartilhados pelo samba, incluindo os usuários/senhas do Linux e do Samba ( /etc/passwd - /etc/shadow - /etc/samba/smbpasswd ) e as configurações do samba ( /etc/samba/smb.conf )
6. imediatamente você instala um novo servidor e restaura todo o seu backup
7. ao tentar logar no Windows você recebe uma mensagem: XXX
8. seus usuários estão achando que você não fez o backup/restore corretamente, pois ao logar com o mesmo usuário/senha as informações do Perfil do Usuário logado não são as mesmas de antes do problema do servidor. A impressão do usuário é que ele simplesmente PERDEU TUDO (isso inclui o Papel de Parede, Meus Documentos, Meus Favoritos, etc ).
9. o pior de tudo é que você tem certeza que os arquivos foram restaurados corretamente, e apesar de os usuários terem a mesma identificação anterior (nome, ID, GID, etc), os perfis não foram aproveitados, causando um grande aborrecimento aos usuários e consequentemente ao administrador desse domínio.

Normalmente isso acontece quando NÃO se preserva o SID do domínio antigo. Isso se deve ao fato de o Windows "enchergar" cada recurso (Usuário, Máquina, Impressora) como um SID e não pelo nome. O usuário quer uma solução rápida para o problema dele, pois no perfil antigo tinham todas as informações e arquivos que o usuário precisa no seu dia-a-dia.

Se você está mudando nome de domínio para DOMAIN-B, além do problema dos perfis acima, você terá que ingressar todos os desktops nesse novo domínio.

Uma das soluções espartanas para resolver o problema do usuário USER-X é copiar os arquivos de perfil antigo (C:\Documents and Settings\User_X) para o novo perfil criado (.C:\Documents and Settings\User_X.DOMAIN). Mas essa solução é demorada e tem que ser repetida para cada perfil de usuário em todas as máquinas, gerando um trabalho enorme para o administrador.

O que descobri quando o usuário USER-Y se loga nesse domínio:

• tudo fica mais complicado se o usuário USER-Y não for um membro do grupo "Domain Admins" (Administradores de Domínio) e sim um usuário sem privilégios adminstrativos ( essa todos sabem )
• que o Windows trata tudo através do SID ( essa quase todo mundo já sabia );
• que ao se logar no Windows uma chave de registro é criada e é associa da ao SID desse usuário no domínio ( essa muita gente já sabia)
• que dentro dessa entrada de registro tem um caminho (PATH) que indica qual é o diretório desse usuário ( essa algumas pessoas já imaginavam)
• que dentro desse diretório tem um arquivo (NTUSER.DAT) que contém as informações do perfil desse usuário ( essa tenho quase certeza que poucos sabiam)
• que esse arquivo tem uma estrutura de REGistro interna que pode ter as permissões alteradas através do regedit, ou seja, pode-se abrir o NTUSER.DAT, alterar as permissões internas e fechá-lo novamente. Esse truque eu custei para entender, principalmente porque não sou usuário de Desktop Windows e não tenho prática diária com esses truques do Windows/RegEdit ( essa eu acredito que a maioria nem imaginava e não irá compreender de primeira )

Pois bem, a solução consiste em:

1. varrer todas as entradas de registro referentes aos Perfis;
2. para cada entrada efetuar uma cópia desse registro com o novo SID;
3. dar permissões NTFS totais para esse nova entrada no perfil (simulando um login) no PATH do perfil antigo;
4. dar permissões NTFS totais no conteúdo do NTUSER.DAT para essa nova entrada no perfil. Para isso necessitamos através do REGEDIT, clicar no HKEY_USERS e através do menu "Carregar seção", navegar até o arquivo NTUSER.DAT do perfil desejado, informar um nome de chave temporária a ser criada (pode ser qualquer nome) pela carga desse NTUSER.DAT, setar as permissões NTFS nessa nova entrada no registro que foi carregada e por último "Descarregar seção" temporária criada;
5. dessa forma não altero nenhuma entrada no registro, eu simplesmente adiciono novas entradas e altero algumas permissões NTFS no sistema de arquivos e no perfil do usuário. Assim tenho garantida a "volta" para o domínio antigo caso seja necessário (imaginemos que o servidor problemático tinha era um problema de OSMAR Contato que foi resolvido).

Se você está se perguntando porque um blog relacionado ao ldap tem essa matéria publicada, eu respondo: porque certamente será útil para alguém, mesmo para aqueles que já estejam utilizando ldap como backend do samba (aliás, é essa é configuração que estou utilizando atualmente).