Como resolver problemas de migração de inter-forest sIDHistory com a ADMTv2

Este artigo descreve como resolver problemas de migração de inter-forest sIDHistory com a ferramenta de migração do Active Directory versão 2 (ADMTv2).

Quando estiver a utilizar o ADMTv2 para migrar sIDHistory como parte de um utilizador inter-forest ou migração de grupos, é necessária com os requisitos de migração de base a configuração.

Por predefinição, sIDHistory, a palavra-passe e o objectGUID são todos preservados durante migrações dentro da floresta, mas isto não se verifica para clonagem inter-forest.

Porque não existe nenhum contexto de segurança incorporado para operações inter-forest, tem de tomar medidas para proteger a segurança das operações através de limites de floresta.

Configuração

Os requisitos básicos para operações de migração inter-forest são:

Utilizador básico baseada no assistente e migração de contas de grupo sem sIDHistory

• O domínio de origem tem de considerar fidedigno o domínio de destino.
• O domínio de origem deve estar a executar o Microsoft Windows NT 4.0 Service Pack 4 (SP4) ou posterior.
• O domínio de destino tem de estar no modo nativo do Microsoft Windows 2000 ou posterior.
• A conta de utilizador que está a executar o ADMTv2 tem de ter direitos de administrador no domínio de origem.
• A conta de utilizador ADMT tem de ter permissões para criar objectos de grupo ou utilizador no contentor de destino delegada.
• DNS (anfitrião) e a resolução de nomes de NetBIOS entre os domínios têm de existir.

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

• Êxito e falha de auditoria da gestão de conta para domínios de origem e de destino.
• Domínios de origem do Windows NT 4.0 chamar este utilizador e auditoria de gestão de grupo.
• Um grupo local vazio no domínio de origem com o nome {SourceNetBIOSDom} $ $ $.
• A chave de registo HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupport tem de ser definida para 1 no controlador de domínio primário do domínio de origem.
• O controlador de domínio primário do domínio de origem tem de reiniciar após a configuração do registo.
• Se o domínio de destino é um domínio do Windows 2000, Windows segurança requer as credenciais de utilizador com direitos de administrador no domínio de destino. Adicionar estas credenciais no assistente quando a migração de sIDHistory está activada.
  
  Para delegar MigrateSidHistory expandido para a direita num controlador de domínio do Microsoft Windows Server ou num computador que tem o pacote de ferramentas de administração do Windows Server 2003 instalado, siga estes passos:
  1. Clique em Iniciar, clique em Ferramentas administrativas e, em seguida, clique em computadores e utilizadores do Active Directory.
  2. Clique com o botão direito do rato no nome do domínio que pretende delegar MigrateSidHistory expandido para a direita a partir do e, em seguida, clique em Delegar controlo para abrir a janela do Assistente de delegação de controlo.
  3. Clique em seguinte, clique em Adicionar, introduza o nome do utilizador ou grupo que pretende adicionar na caixa de diálogo Seleccionar utilizadores, computadores ou grupos, clique em OK e, em seguida, clique em seguinte.
  4. Clique para seleccionar a opção de criar uma tarefa personalizada para delegar e, em seguida, clique em seguinte.
  5. Certifique-se de que a esta pasta, objectos existentes nesta pasta, e a criação de novos objectos nesta pasta opção está seleccionada e, em seguida, clique em seguinte.
  6. Certifique-se de que a opção Geral é seleccionada, clique em Migrar histórico do SID na lista permissões e, em seguida, clique em seguinte.
  7. Verifique se a informação está correcta e, em seguida, clique em Concluir.
• Se o domínio de destino for um domínio do Windows Server 2003, a segurança do Windows requer credenciais de utilizador com MigratesIDHistory delegada expandido direita ou direitos de administrador no domínio de destino.
• Sem sID a ser migrado poderão existir na floresta de destino, como um sID primário ou como um atributo sIDHistory de outro objecto.

Requisitos adicionais para migração de sIDHistory com a linha de comandos ou interfaces de scripts

• Quando inicia um utilizador ou grupo migração com a migração de sIDHistory a partir da linha de comando ou a partir de um script, o comando ou script tem de ser executado no controlador de domínio no domínio de destino.
• A conta de utilizador que está a executar a migração tem de ter direitos de administrador de origem e os domínios de destino.

Requisitos especiais para grupo mapeamento e Assistente de intercalação

• Se sIDHistory deve ser migrados durante grupo mapeamento e intercalar, o âmbito dos grupos de origem tem de corresponder ao âmbito do grupo destino.

Resolução de problemas

O passo mais básico que pode utilizar para resolver problemas de migração de inter-forest sIDHistory consiste em utilizar o Assistente de migração de contas de utilizador ou o Assistente de 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:

• O grupo local de $ $ $ {SourceNetBIOSDom} é criado.
• TcpipClientSupport no controlador de domínio primário de origem ou emulador do controlador de domínio principal está activado.
• Auditoria em ambos os domínios é activada.

Opcionalmente, ADMT pode reparar qualquer um destas dependências que não estão definidas. Para reparar ou configurar estas definições, a conta que é utilizada para executar a ferramenta ADMT tem de ter permissões suficientes em cada domínio respectivo para executar as tarefas.

Note que apenas o assistente executa estas verificações e correcções. As interfaces de scripts e linha de comandos não executam estas verificações e não funcionam sem configuração correcta.

Mensagens de erro comuns com a migração de inter-forest sIDHistory

Este erro indica um problema RPC onde a ferramenta de migração não é possível ligar para um ponto final RPC no controlador de domínio primário de origem. Causas possíveis incluem:

• TcpipClientSupport no controlador de domínio primário de origem ou emulador do controlador de domínio principal não foi activada.
• O controlador de domínio principal ou emulador do controlador de domínio principal não foi reiniciado depois TcpipClientSupport foi configurado.
• Resolução de nomes DNS ou NetBIOS não está a funcionar.

Este erro normalmente indica que um utilizador ou um grupo global ou universal com o nome de $ $ $ {SourceNetBIOSDom} já a existe. ADMT cria normalmente o grupo local esse nome, mas não é possível fazê-lo se já existir um principal de segurança com o nome. Este erro normalmente indica que a conta de utilizador que é utilizada para executar a ADMT não tem permissões suficientes para executar a migração em um ou ambos os domínios. Este erro no ficheiro Migration.log após uma migração de sIDHistory normalmente indica que o domínio de origem tiver configurado as fidedignidades que não existam no domínio de destino. Para resolver este problema, execute o Assistente de migração de fidedignidade para mapear as fidedignidades no domínio de origem e, em seguida, replicar as relações no domínio de destino.

Informações de sIDHistory adicionais

O sIDHistory é um atributo de valor múltiplo de principais de segurança no Active Directory podem conter valores até 850. O atributo sIDHistory para fornecer retro-compatibilidade com controladores de domínio que executem versões anteriores do Windows, só está disponível em domínios que são operar no nível funcional do modo nativo do Windows 2000 ou posterior.

Alguns produtos de outro fornecedor possibilitam activar sIDHistory nos domínios de modo misto. Estes reclamações não representam a utilização da API pública legítima. Os administradores de domínio que utilizam essas ferramentas risco colocando respectiva implementação do Active Directory com um estado não suportado.

Durante a migrações dentro da floresta, LDAP_Rename é responsável por mover objectos. Deste modo, objectos migrados retém dados de identificação importantes, incluindo o objectGUID e a palavra-passe. Não é o caso para migrações inter-forest, que chamar DSAddSidHistory para preencher o atributo no domínio de destino. Palavra-passe migração poderá ser activada para clonagem inter-forest, mas o objectGUID é sempre perdida durante este tipo de migração.

Em ambos os casos, os objectos migrados são atribuídos um novo sID pelo domínio de destino. O sID original é adicionado o atributo sIDHistory do objecto migrado no novo domínio. Depois de esta situação ocorre, o atributo sIDHistory poderá não ser modificado ou eliminado utilizando as ferramentas de administração do Active Directory padrão. Não é permitida porque o atributo sIDHistory é possuído pelo SAM. É possível limpar o sIDHistory utilizando um script ou uma ferramenta interna da Microsoft não público.

Note que o sIDHistory é uma ferramenta de transição e não se destina a existir indefinidamente anexado a principais de segurança. Apesar de migração do sIDHistory pode significativamente facilitar e simplificar o processo de migração de domínio, existem implicações de segurança importantes que devem ser consideradas antes de implementar o sIDHistory numa empresa de produção.

Um token de segurança 2000 Windows pode conter um máximo de 1,023 sIDs, incluindo o sIDHistory e agrupar sIDs. Kerberos também é limitado porque Kerberos do Windows 2000 tem uma memória intermédia 73 sID. Depois de aplicar o Windows 2000 Service Pack 2 (SP2), este tamanho pode ser duplicado por uma alteração de registo de toda a empresa. Que excedam estes limites viola a restrição de MaxTokenSize e pode conduzir a resultados imprevisíveis, incluindo falha de autenticação Kerberos e errático ou inexistente aplicação de políticas. Para evitar estes problemas, utilize conversão de segurança em vez de sIDHistory como solução a longo prazo para manter o acesso a recursos após uma migração de domínio.