ID do artigo: 322970 - Última revisão: sexta-feira, 2 de março de 2007 - Revisão: 7.4

Como solucionar problemas de migração de sIDHistory entre florestas com ADMTv2

Dica do SistemaEste artigo aplica-se a um sistema operativo diferente do que está a utilizar. Foi desactivado o conteúdo do artigo, que pode não ser relevante para si.

Nesta página

Expandir tudo | Recolher tudo

Sumário

Este artigo descreve como solucionar problemas de migração de sIDHistory entre florestas com a ferramenta de migração do Active Directory versão 2 (ADMTv2).

Mais Informações

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

Por padrão, sIDHistory, senha e objectGUID são todos preservados durante migrações entre florestas, mas isso não é verdadeiro para clonagem entre florestas.

Porque não há nenhum contexto de segurança interna para operações entre florestas, deve tomar medidas para proteger a segurança de operações entre os limites da floresta.

Configuração

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

Usuário básico com base no assistente e migração de conta de grupo sem sIDHistory

  • Domínio de origem deve confiar no domínio de destino.
  • Domínio de origem deve estar executando o Microsoft Windows NT 4.0 Service Pack 4 (SP4) ou posterior.
  • O domínio de destino deve estar no modo nativo do Microsoft Windows 2000 ou posterior.
  • A conta de usuário que está executando ADMTv2 deve ter direitos de administrador no domínio de origem.
  • A conta de usuário a ADMT deve ter delegado permissões criar objetos de grupo ou usuário no recipiente de destino.
  • DNS (nome do host) e resolução de nome NetBIOS entre os domínios devem existir.

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

  • Sucesso e Falha de auditoria de gerenciamento de conta para domínios de origem e destino.
  • Domínios de origem do Windows NT 4.0 chamam esse usuário e auditoria de gerenciamento de grupo.
  • Um grupo local vazio no domínio de origem é denominado {SourceNetBIOSDom} $ $ $.
  • Chave do Registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupport 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.
  • Se o domínio de destino é um domínio do Windows 2000, Windows segurança requer credenciais de usuário com direitos de administrador no domínio de destino. Adicionar essas credenciais no Assistente quando a migração de sIDHistory está ativada.

    Para delegar MigrateSidHistory estendido direita em um controlador de domínio do Microsoft Windows Server ou em um computador que possui o pacote de ferramentas de administração do Windows Server 2003 instalado, execute essas etapas:
    1. Clique em Iniciar, clique em Ferramentas administrativas e clique em Active Directory Users and Computers.
    2. Clique com o botão direito do mouse no nome do domínio que você deseja delegar MigrateSidHistory estendida a partir do direito e, em seguida, clique em Delegar controle para abrir a janela do Assistente para delegação de controle.
    3. Clique em Avançar, clique em Adicionar, digite o nome de usuário ou grupo que você deseja adicionar na caixa de diálogo Selecionar usuários, computadores ou grupos, clique em OK e clique em Avançar.
    4. Clique para selecionar a opção de criar uma tarefa personalizada para delegar e clique em Avançar.
    5. Certifique-se de que Esta pasta, objetos existentes nesta pasta, e criação de novos objetos nesta pasta opção está selecionada e clique em Avançar.
    6. Certifique-se de que a opção Geral é selecionada, clique em Migrar histórico SID na lista permissões e clique em Avançar.
    7. Verifique se as informações estão corretas e clique em Concluir.
  • Se o domínio de destino é um domínio do Windows Server 2003, segurança do Windows requer credenciais de usuário com MigratesIDHistory delegada estendido direita ou direitos de administrador no domínio de destino.
  • Nenhum sID a ser migrado pode existir na floresta de destino, 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ê iniciar um usuário ou grupo migração com sIDHistory migração a partir 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 na origem e os domínios de destino.

Requisitos especiais para grupo de mapeamento e mesclagem de Assistente

  • Se sIDHistory for migrado durante o mapeamento e mesclagem de grupo, o escopo dos grupos de origem deve coincidir com o escopo do grupo de destino.

Solucionando 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 para migração de contas de grupo para executar uma migração de modo de teste.

Durante a migração de modo de teste, ADMTv2 valida as seguintes dependências:
  • Grupo local {SourceNetBIOSDom} $ $ $ é criado.
  • TcpipClientSupport no controlador de domínio primário de origem ou emulador de controlador de domínio primário está ativado.
  • Auditoria em ambos os domínios está ativado.
Opcionalmente, ADMT pode reparar qualquer essas dependências não definidas. Para reparar ou definir essas configurações, a conta usada para executar a ADMT deve ter permissões suficientes em cada domínio para executar as tarefas respectivo.

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

Mensagens de erro comuns com a migração de sIDHistory entre florestas

"O identificador é inválido (código de erro = 6)."
Este erro indica um problema RPC onde a ferramenta de migração não é possível vincular a um ponto de extremidade RPC no controlador de domínio primário de origem. Possíveis causas incluem:
  • TcpipClientSupport no controlador de domínio primário de origem ou emulador de controlador de domínio primário não foi ativado.
  • O controlador de domínio primário ou emulador de controlador de domínio primário não foi reiniciado após TcpipClientSupport foi configurado.
  • Resolução de nome DNS ou NetBIOS não está funcionando.
Não foi possível verificar a auditoria e TcpipClientSupport nos domínios. Não poderá migrar de SID. O grupo local especificado não existe.
Este erro normalmente indica que um usuário ou um grupo global ou universal com o nome de $ $ $ {SourceNetBIOSDom} já existe. ADMT normalmente cria o grupo local do nome, mas ele não pode fazê-lo se já existe uma entidade de segurança com o nome.
Não foi possível verificar a auditoria e TcpipClientSupport nos domínios. Não poderá migrar de SID. Acesso negado.
Este erro normalmente indica que a conta de usuário que é usada para executar a ADMT não tem permissões suficientes para executar a migração em um ou ambos os domínios.
Pesquisa de nome de domínio falhou; rc = 1332. Nenhum mapeamento entre nomes de conta e as identificações de segurança foi feito.
Esse erro no arquivo Migration.log após uma migração com sIDHistory geralmente indica que o domínio de origem tiver configurado as relações de confiança que não existem no domínio de destino. Para resolver esse problema, execute o Assistente para migração de confiança para mapear as relações de confiança no domínio de origem e replicar as relações no domínio de destino.

Informações adicionais sIDHistory

O sIDHistory é um atributo multivalorado de objetos de segurança no Active Directory pode armazenar até 850 valores. O atributo sIDHistory para fornecer compatibilidade com versões anteriores com controladores de domínio que estão executando versões anteriores do Windows, só está disponível em domínios que operam no nível funcional do modo nativo do Windows 2000 ou posterior.

Alguns produtos do fornecedor de terceiros tornam possível 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 usam tais ferramentas risco colocando sua implantação do Active Directory em um estado sem suporte.

Durante migrações entre florestas, LDAP_Rename é responsável por mover objetos. Devido a isso, os objetos migrados retém dados de identificação importantes, incluindo o objectGUID e a senha. Não é o caso para migrações entre florestas, que chamar DSAddSidHistory para preencher o atributo no domínio de destino. Senha migração pode ser ativada para clonagem entre florestas, mas o objectGUID sempre é perdido durante este tipo de migração.

Em ambos os casos, objetos migrados são atribuídos a um novo sID do domínio de destino. SID original é adicionado ao atributo sIDHistory de objetos migrados no novo domínio. Após isso ocorre, o atributo sIDHistory pode não ser modificado ou excluído usando as ferramentas de administração padrão do Active Directory. Isso não é permitido porque o atributo sIDHistory é de propriedade de SAM. É possível limpar o sIDHistory usando um script ou uma ferramenta interna da Microsoft não públicos.

Observe que o sIDHistory é uma ferramenta transitional e não deve existir indefinidamente anexadas a objetos de segurança. Embora a migração de sIDHistory pode significativamente facilitar e simplificar o processo de migração de domínio, há implicaçõ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 2000 Windows pode armazenar um máximo de 1,023 sIDs, incluindo o sIDHistory e grupo sIDs. Kerberos também é limitado porque Kerberos Windows 2000 tem um buffer de 73 sID. Após aplicar o Windows 2000 Service Pack 2 (SP2), esse tamanho pode ser duplicado por uma alteração de registro de toda a empresa. Exceder esses limites viola a restrição de MaxTokenSize e pode gerar resultados imprevisíveis, incluindo falha de autenticação Kerberos e aplicativo inexistente ou irregular das diretivas. Para evitar esses problemas, use a conversão de segurança em vez de sIDHistory como a solução a longo prazo para manter o acesso ao recurso após uma migração de domínio.

A informação contida neste artigo aplica-se a:
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
  • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
  • Microsoft Windows Server 2003, Enterprise Edition for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition for Itanium-Based Systems
Palavras-chave: 
kbmt kbactivedirectory kbhowto kbtshoot KB322970 KbMtpt
Tradução automáticaTradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 322970  (http://support.microsoft.com/kb/322970/en-us/ )