Como realizar uma migração de domínio do Active Directory no Dell Security Server

• O Dell Security Management Server (antigo Dell Data Protection | Enterprise Edition) está ativo e o domínio foi associado.
• Um domínio existente foi adicionado à seção "domain" no console da IU Web.
• Os endpoints foram ativados no servidor.
• Uma migração de domínio é necessária.
• Nós estamos planejando migrar também o histórico de SID dos objetos do AD.
• Os endpoints têm conectividade total com o servidor e podem recuperar políticas no domínio antigo, antes de iniciar o processo de migração de domínio.
• Os dados criptografados nos endpoints podem ser totalmente acessados e os endpoints estão ativados, mas é possível desativá-los e reativá-los. Podemos confirmar que as ativações estão ocorrendo sem nenhum problema usando um WSDeactivate rápido de quaisquer endpoints.

As etapas gerais não são muito complexas, mas é necessário entender que, se todo o processo não for executado corretamente, os dados poderão ser perdidos ou uma recuperação de máquinas poderá ser necessária. Por fim, embora esse processo possa ser realizado em qualquer versão do Dell Security Management Server e client, a Dell Technologies recomenda ter pelo menos o servidor 8.5 e o client 8.3.0 instalados, pois várias melhorias foram feitas a partir dessas versões para facilitar o processo geral de migração no Dell Security Management Server. Veja abaixo uma visão geral do funcionamento de todo o processo e algumas das preocupações mais relevantes.

A primeira etapa é entender se uma migração de domínio é necessária. Por exemplo, em uma situação em que uma empresa está migrando para o Office 365, é suficiente adicionar um alias e defini-lo como o UPN principal para os usuários do AD. Essa não é uma migração de domínio real e nenhuma outra ação é necessária no Dell Data Protection | Enterprise Edition Server, além de adicionar o novo alias à lista de alias de domínio, na seção Settings, Domain Alias List. Se um novo domínio for criado e os objetos do AD precisarem ser movidos do antigo domínio desativado para o novo, uma migração de domínio deverá ser planejada.

Sempre que uma migração de domínio for planejada, a primeira etapa é considerar também a migração do histórico de SID. Para fazer com que a migração de domínio seja bem-sucedida no Dell Security Management Server, é necessário preservar o histórico de SID. Caso contrário, os objetos do AD serão considerados novos no Dell Security Management Server e, consequentemente, não poderemos aproveitar as mesmas chaves de criptografia após a reativação. A Dell precisa migrar o histórico de SID. Não dedicaremos tempo à forma como uma migração de domínio é realizada, pois essa não é uma tarefa do Dell Data Protection | Encryption. No entanto, há várias ferramentas da Microsoft relacionadas a ADMT que permitem que uma organização migre um domínio A para um domínio B. Conforme mencionado acima, uma migração do histórico de SID é necessária para mantermos a persistência em termos de chaves. A migração do histórico de SID significa que estamos adicionando a pré-migração de SID do usuário antigo ao atributo de histórico de SID no AD, garantindo a continuidade nos objetos migrados.

Como regra no AD:

• Quando qualquer objeto é renomeado, o valor do atributo objectSID (o SID) não é alterado. Quando você move um objeto de um domínio para outro, o objectSID deve ser alterado, pois uma parte dele é específica ao domínio, e o SID antigo é adicionado ao SIDHistory atributo (supondo que isso seja migrado). Você pode visualizar SIDHistory usando ADSI Edit (é possível exibir como hexadecimal ou decimal). Se não houver valores, não há histórico de SID algum ou o objeto nunca foi movido de outro domínio.
• SIDhistory só está disponível durante a migração de contas entre domínios ou florestas.

Abaixo está uma captura de tela de como determinar se o SIDHistory foi migrado usando o editor de atributos:

Depois de confirmarmos que o SIDHistory de usuários e máquinas migrados também foi movido, poderemos prosseguir com a configuração do Dell Security Management Server. Se precisar de mais informações sobre como realizar uma migração de domínio e sobre como preservar o histórico de SID, consulte a seguinte documentação da Microsoft:

• https://www.microsoft.com/en-us/download/details.aspx?id=19188
• https://technet.microsoft.com/en-us/library/cc974332(v=ws.10).aspx
• https://technet.microsoft.com/en-us/library/cc974384(v=ws.10).aspx

Veja abaixo o que acontece durante uma migração de domínio no Dell Security Management Server.

1. No client:
   • Resolvemos o UPN de usuários para o SID. Procuramos o SID no arquivo de cofre. Não o encontramos.
   • Decidimos que esse é um novo usuário e entramos em contato com o Security Server, transmitindo a senha do UPN como uma solicitação de ativação típica.
2. No servidor:
   • Recebemos a solicitação de ativação. Entramos em contato com o Active Directory e procuramos o UPN. Em seguida, fizemos a triagem do usuário. Como parte desse processo de triagem, observamos que o SID na tabela Entity não corresponde ao SID no AD. Examinamos o SIDHistory para encontrar o SID em nossa tabela Entity. Se não o encontrarmos, lançaremos uma exceção e a ativação falhará, pois já temos esse SCID. Se o encontrarmos, atualizaremos a tabela Entity com o novo SID (no UID, a primeira parte é o domínio; atualizaremos essa parte e também parte do domínio do endpoint).
   • Em seguida, transmitiremos as chaves antigas, a política, o DCID etc. para o client (como se fosse uma reativação).
3. De volta ao client:
   • O endpoint recebe essas informações e adiciona uma entrada ao arquivo credsys.vlt, informando que o usuário está ativado e conectado normalmente.

Um ponto-chave do Dell Security Management Server é entender se um novo domínio deve ser adicionado à IU Web para fazer com que tudo funcione com usuários novos e antigos durante a ativação ou reativação.

Em uma migração de domínio, não adicionaremos o novo domínio ao console do Dell Security Management Server SE o domínio raiz primário do domínio antigo e do novo migrado estiver lá. Basta adicionar o novo domínio na forma de um alias na seção "Settings" > "Domain Alias List". (e estamos supondo que haja uma confiança bidirecional entre o domínio primário e o novo domínio secundário.) A conta de serviço do domínio raiz deve ser possivelmente configurada no domínio pai. Se, em vez disso, migrarmos um domínio A.local para B.local e os dois domínios não forem secundários do mesmo domínio raiz ou caso pertençam a uma floresta diferente, precisaremos que um novo domínio seja adicionado ao nosso console, pois devemos vincular todos os endpoints existentes ao novo domínio e a uma nova conta de serviço.

A compreensão dos itens acima sobre como configurar o Dell Security Management Server corretamente é um ponto-chave. Se fizermos a configuração conforme especificado, enfrentaremos vários problemas após a migração. É essencial entender o tipo de confiança existente entre esses domínios e seus domínios raiz (se houver) e qual é a lista de domínios atuais no console do Dell Security Management Server. A regra é simples: ter algum tipo de confiança entre o domínio primário/secundário e, em seguida, ter o domínio raiz e os aliases em vigor no Dell Data Protection | Enterprise Edition Server é o suficiente. Caso contrário, precisaremos adicionar o máximo de domínios secundários ao Dell Security Management Server como seus subdomínios reais. Essa regra também se aplica à migração de domínio.

Por fim, de forma geral, *nunca* devemos adicionar um domínio secundário e um domínio primário ao mesmo tempo, pois tornar o mesmo usuário potencialmente visível em ambos os níveis tornará tudo muito difícil para nós. E a remoção de domínio (ainda) não é uma tarefa totalmente compatível com o Dell Security Management Server.

Se o client estiver na v8.2.1 ou anterior e o servidor estiver na v8.3.1 ou anterior, WSDeactivate será uma etapa necessária, pois não renomeamos automaticamente a parte do domínio do endpoint no servidor. Isso não se aplica às compilações mais recentes do Dell Security Management Server ou endpoint.

Os domínios antigos não podem ser removidos do banco de dados do Dell Security Management Server de modo manual ou por meio do console. Isso ocorre porque o Dell Security Management Server procura um usuário ou grupo e, em seguida, determina se ele é membro do domínio. Dessa forma, quando um domínio é removido, todos os objetos que fazem parte desse domínio também devem ser removidos. Nenhuma dessas opções é compatível neste momento. A Dell está fazendo pesquisas para alterar esse comportamento em versões futuras do Dell Security Management Server, embora, neste momento, essa não seja uma tarefa compatível ou viável. Nota adicional: se optarmos por marcar (manualmente) o domínio como removido no banco de dados, começaremos a receber um erro, que será exibido nos logs do servidor a cada 15 minutos para todos os usuários e grupos órfãos associados.

Se o Shield for desinstalado em um endpoint migrado, as mesmas etapas necessárias para aplicar uma reativação normal (sem domínio) ao mesmo ID do Shield serão necessárias aqui. Em arquivos criptografados comuns, devemos aplicar o mesmo DCID ao registro antes de permitir que o endpoint seja reativado no Dell Data Protection | Enterprise Edition Server ou no Dell Security Management Server. Em caso de dúvidas, entre em contato com a equipe de suporte técnico para obter mais ajuda.

Não, uma nova licença de domínio não é necessária a partir do Dell Data Protection | Enterprise Edition Server 8.x. Nas versões mais antigas do Dell Data Protection | Enterprise Edition Server, uma nova licença ainda é necessária. Entre em contato com a equipe de suporte técnico para obter mais informações.