Como solucionar problemas de migração de histórias entre florestas com o ADMTv2

2025-01-15

Este artigo descreve como solucionar problemas de migração de histórias entre florestas com a Ferramenta de Migração do Active Directory versão 2 (ADMTv2).

Número original do KB: 322970

Mais informações

Quando você está usando o ADMTv2 para migrar sIDHistory como parte de uma migração de usuário ou grupo entre florestas, a configuração é necessária com os requisitos de migração base.

Por padrão, sIDHistory, password e objectGUID são preservados durante migrações dentro da floresta, mas isso não é verdadeiro para a clonagem entre florestas.

Como não há um contexto de segurança interno para operações entre florestas, você deve tomar medidas para proteger a segurança das operações entre os limites da floresta.

Configuração

Os requisitos básicos para as operações de migração entre florestas são:

Migração básica de conta de usuário e grupo baseada em assistente sem sIDHistory

O domínio de origem deve confiar no domínio de destino.
A conta de usuário que está executando o ADMTv2 deve ter direitos de administrador no domínio de origem.
A conta de usuário do ADMT deve ter permissões delegadas para criar objetos de usuário ou grupo no contêiner de destino.
A resolução de nomes DNS (nome do host) e NetBIOS entre os domínios deve existir.

A migração do sIDHistory requer as seguintes dependências adicionais

Auditoria de sucesso e falha do gerenciamento de contas para domínios de origem e destino.
Os domínios de origem chamam isso de auditoria de gerenciamento de usuários e grupos.
Um grupo local vazio no domínio de origem chamado {SourceNetBIOSDom}$$$.
A HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupportchave do Registro deve ser definida como 1 no controlador de domínio primário do domínio de origem.
Você deve reiniciar o controlador de domínio primário do domínio de origem após a configuração do Registro.
A segurança do Windows requer credenciais de usuário com o direito estendido MigratesIDHistory delegado ou direitos de administrador no domínio de destino. Você adiciona essas credenciais no assistente quando a migração sIDHistory está ativada.

Para delegar o direito estendido MigrateSidHistory em um controlador de domínio ou em um computador que tenha o pacote de Ferramentas de Administração do Windows Server instalado, siga estas etapas:

Clique em Iniciar, Ferramentas Administrativas e em Usuários e Computadores do Active Directory.
Clique com o botão direito do mouse no nome do domínio do qual você deseja delegar o MigrateSidHistory estendido diretamente e clique em Delegar Controle para abrir a janela Assistente de Delegação de Controle .
Clique em Avançar, clique em Adicionar, digite o nome do usuário ou grupo que você deseja adicionar na caixa de diálogo Selecionar Usuários, Computadores ou Grupos , clique em OK e em Avançar.
Clique para selecionar a opção Criar uma tarefa personalizada para delegar e clique em Avançar.
Verifique se a opção Esta pasta, objetos existentes nesta pasta e criação de novos objetos nesta pasta está selecionada e clique em Avançar.
Verifique se a opção Geral está selecionada, clique em Migrar Histórico de SID na lista Permissões e clique em Avançar.
Verifique se as informações estão corretas e clique em Concluir.
- Nenhum sID a ser migrado pode existir na floresta de destino, seja como um sID primário ou como um atributo sIDHistory de outro objeto.

Requisitos adicionais para migrar sIDHistory com a linha de comando ou interfaces de script

Quando você inicia uma migração de usuário ou grupo com a migração sIDHistory da linha de comando ou de um script, o comando ou script deve ser executado no controlador de domínio no domínio de destino.
A conta de usuário que está executando a migração deve ter direitos de administrador nos domínios de origem e de destino.

Requisitos especiais para o assistente de mapeamento e mesclagem de grupos

Se sIDHistory for migrado durante o mapeamento e a mesclagem de grupos, o escopo dos grupos de origem deverá corresponder ao escopo do grupo de destino.

Solução de problemas

A etapa mais básica que você pode usar para solucionar problemas de migração de sIDHistory entre florestas é usar o Assistente de Migração de Conta de Usuário ou o Assistente de Migração de Conta de Grupo para executar uma migração de modo de teste.

Durante a migração do modo de teste, o ADMTv2 valida as seguintes dependências:

O grupo local {SourceNetBIOSDom}$$$ é criado.
TcpipClientSupport no controlador de domínio primário de origem ou no emulador do controlador de domínio primário está ativado.
A auditoria em ambos os domínios está ativada.

Opcionalmente, o ADMT pode reparar qualquer uma dessas dependências que não estejam definidas. Para reparar ou definir essas configurações, a conta usada para executar o ADMT deve ter permissões suficientes em cada domínio respectivo para realizar as tarefas.

Somente o assistente executa essas verificações e correções. A linha de comando e as interfaces de script não executam essas verificações e não funcionam sem a configuração correta.

Mensagens de erro comuns com a migração de histórias entre florestas

"O identificador é inválido (código de erro = 6)."

Esse erro indica um problema de RPC em que a ferramenta de migração não pode se associar a um ponto de extremidade RPC no controlador de domínio primário de origem. As possíveis causas incluem:

TcpipClientSupport no controlador de domínio primário de origem ou no emulador do controlador de domínio primário não foi ativado.
O controlador de domínio primário ou o emulador do controlador de domínio primário não foi reiniciado depois que TcpipClientSupport foi configurado.
A resolução de nomes DNS ou NetBIOS não está funcionando.

Não foi possível verificar a auditoria e o TcpipClientSupport em domínios. Não será capaz de migrar Sid's. O grupo local especificado não existe.

Esse erro normalmente indica que um usuário ou um grupo global ou universal com o nome {SourceNetBIOSDom}$$$ já existe. O ADMT normalmente cria o grupo local desse nome, mas não poderá fazer isso se já existir uma entidade de segurança com o nome.

Não foi possível verificar a auditoria e o TcpipClientSupport em domínios. Não será capaz de migrar Sid's. Acesso negado.

Esse erro normalmente indica que a conta de usuário usada para executar o ADMT não tem permissões suficientes para executar a migração em um ou ambos os domínios. Falha na pesquisa de nome de domínio, rc=1332. Nenhum mapeamento entre nomes de conta e IDs de segurança foi feito. Esse erro no arquivo Migration.log após uma migração com sIDHistory normalmente indica que o domínio de origem configurou relações de confiança que não existem no domínio de destino. Para resolver esse problema, execute o Assistente de Migração de Confiança para mapear as relações de confiança no domínio de origem e replique as relações no domínio de destino.

Informações adicionais sobre o sIDHistory

O sIDHistory é um atributo de vários valores de entidades de segurança no Active Directory que pode conter até 850 valores. Para fornecer compatibilidade com versões anteriores com controladores de domínio que executam versões anteriores do Windows, o atributo sIDHistory só está disponível em domínios que operam no nível funcional do Windows.

Alguns produtos de fornecedores terceirizados possibilitam ativar o sIDHistory em domínios de modo misto. Essas declarações não representam o uso legítimo de APIs públicas. Os administradores de domínio que usam essas ferramentas correm o risco de colocar a implantação do Active Directory em um estado sem suporte.

Durante as migrações intraflorestais, LDAP_Rename é responsável por mover objetos. Por isso, os objetos migrados retêm dados de identificação importantes, incluindo o objectGUID e a senha. Esse não é o caso de migrações entre florestas, que chamam DSAddSidHistory para preencher o atributo no domínio de destino. A migração de senha pode ser ativada para clonagem entre florestas, mas o objectGUID sempre é perdido durante esse tipo de migração.

Em ambos os casos, os objetos migrados recebem um novo sID pelo domínio de destino. O sID original é adicionado ao atributo sIDHistory do objeto migrado no novo domínio. Depois que isso ocorrer, o atributo sIDHistory não poderá ser modificado ou excluído usando as ferramentas de administração padrão do Active Directory. Isso não é permitido porque o atributo sIDHistory pertence ao SAM. É possível limpar o sIDHistory usando um script ou uma ferramenta interna não pública da Microsoft.

Observe que o sIDHistory é uma ferramenta de transição e não deve existir indefinidamente anexado a entidades de segurança. Embora a migração do sIDHistory possa facilitar e simplificar significativamente o processo de migração de domínio, há ramificações de segurança importantes que devem ser consideradas antes de implementar o sIDHistory em uma empresa de produção.

Um token de segurança do Windows pode conter no máximo 1.023 sIDs, incluindo sIDHistory e sIDs de grupo. O Kerberos também é limitado porque o Windows Kerberos tem um buffer de 73 sID. Esse tamanho pode ser duplicado por uma alteração no Registro em toda a empresa. Exceder esses limites viola a restrição MaxTokenSize e pode levar a resultados imprevisíveis, incluindo falha na autenticação Kerberos e aplicação errática ou inexistente de políticas. Para evitar esses problemas, use a Conversão de Segurança em vez de sIDHistory como a solução de longo prazo para manter o acesso a recursos após uma migração de domínio.