Opções de infraestrutura de identidade paralela e combinada

A Microsoft oferece uma variedade de tecnologias e soluções para a integração entre diferentes componentes locais e na nuvem da infraestrutura de identidade. É comum que os clientes não saibam as quais são as tecnologias mais ideais e que possam pensar incorretamente que "a versão mais recente de uma tecnologia cobre todos os cenários das versões anteriores".

Este artigo cobre cenários complexos, como o descrito abaixo, que sua empresa pode enfrentar e que requerem a combinação de suas informações de identidade. Idealmente, uma organização com uma única fonte de RH, uma única floresta do Active Directory e um único locatário do Microsoft Entra integrados às mesmas pessoas em cada um deles terá a melhor experiência de identidade no Microsoft Online Services. No entanto, na prática, um cliente corporativo pode nem sempre estar em uma situação em que isso seja possível. Por exemplo, o cliente pode estar passando por uma fusão ou precisando de isolamento para alguns usuários ou aplicativos. Quando há diversos locatários de RH, AD ou Microsoft Entra, o cliente precisa decidir se deseja combiná-los em menos instâncias um mantê-los em paralelo.

Veja a seguir alguns cenários e requisitos comuns, de acordo com os comentários de nossos clientes.

Cenários que surgem para identidades de diversas nuvens e organizações

• Fusões e aquisições (M&A): refere-se a uma situação em que, geralmente, a Empresa A compra a Empresa B.
• Rebranding – Alteração no nome ou na marca de uma empresa e, normalmente, alteração no nome de domínio de email.
• Consolidação de locatários do Microsoft Entra ID ou do Office 365 – Empresas com mais de um locatário do Office 365 podem querer combiná-los devido à conformidade ou a requisitos históricos.
• Consolidação de domínio ou floresta do Active Directory – Empresas que estão avaliando a realização de uma consolidação de domínio ou floresta do Active Directory.
• Desinvestimentos – Quando uma divisão ou grupo de negócios de uma empresa é vendido ou se torna independente.
• Privacidade de informações do usuário – Quando empresas têm requisitos que impedem que determinados dados (atributos) sejam mantidos visíveis publicamente e que autorizam somente usuários ou grupos delegados corretos a lê-los, alterá-los e atualizá-los.

Requisitos que se originam desses cenários

• Reúna todos os dados de usuários e grupos em um único lugar, incluindo email e disponibilidade de status para agendamento de reuniões, criando uma central ou um diretório universal.
• Mantenha um nome de usuário e credenciais únicos e reduza a necessidade de inserir nomes de usuário e senhas em todos os aplicativos implementando o logon único.
• Simplifique a integração de usuário para que ela não demore semanas ou meses.
• Prepare a organização para futuras aquisições e demandas de gerenciamento de acesso.
• Habilite e melhore a colaboração e a produtividade entre empresas.
• Reduza a probabilidade de uma violação de segurança ou de uma exfiltração dos dados com políticas de segurança implantadas de maneira centralizada e consistente!

Cenários não abordados neste artigo

• M&A Parcial. Por exemplo, uma organização compra parte de outra.
• Desinvestimento ou divisão de organizações
• Renomeação de organizações.
• Empreendimentos conjuntos ou parceiros temporários

Este artigo descreve diversos ambientes de identidade de diversas nuvens ou organizações, incluindo cenários de M&A aos quais a Microsoft oferece suporte hoje, além de descrever como uma organização pode selecionar as tecnologias ideais de acordo com a abordagem de consolidação adotada.

Opções de consolidação para um cenário de M&A hipotético

As seções a seguir cobrem quatro cenários principais e hipotéticos de M&A:

Suponha que a Contoso seja um cliente corporativo cuja TI tenha um único sistema de RH (local), uma única floresta do Active Directory e um único locatário do Microsoft Entra ID para aplicativos funcionando conforme o esperado. Os usuários são trazidos do sistema de RH para o Active Directory e são projetados no Microsoft Entra ID e direcionados aos aplicativos SaaS. Este cenário é ilustrado com o diagrama abaixo, cujas setas mostram o fluxo de informações de identidade. O mesmo modelo também se aplica a clientes com um sistema de RH em nuvem, como o Workday ou o SuccessFactors, que provisiona o Active Directory, não somente a clientes que usam o MIM (Microsoft Identity Manager).

Em seguida, a Contoso começou a se fundir com a Litware, que anteriormente executava a própria TI de maneira independente. A equipe de TI da Contoso cuidará da fusão e espera continuar com os aplicativos da Contoso inalterados, mas deseja que os usuários da Litware tenham acesso a eles e colaborem com esses aplicativos. Para os aplicativos da Microsoft, SaaS de terceiros e personalizados, o estado final deve consistir nos usuários da Contoso e da Litware conceitualmente com acesso aos mesmos dados.

A primeira decisão da equipe de TI é o grau de combinação da infraestrutura. É possível optar por não confiar em nenhuma infraestrutura de identidade da Litware. Também é possível considerar o uso da infraestrutura da Litware e a conversão ao longo do tempo, minimizando a interrupção do ambiente da Litware. Em alguns casos, o cliente pode desejar manter a infraestrutura de identidade existente da Litware independente e não convergente, ainda a utilizando para dar aos funcionários da Litware acesso aos aplicativos da Contoso.

Se o cliente optar por manter alguma parte ou toda a infraestrutura de identidade da Litware, haverá compensações quanto ao uso do Active Directory Domain Services ou do Microsoft Entra ID da Litware para fornecer aos usuários da Litware acesso aos recursos da Contoso. Esta seção examina as opções viáveis, com base no que a Contoso usaria para os usuários da Litware:

• Cenário A ─ Não usar nenhuma infraestrutura de identidade da Litware.
• Cenário B – Usar as florestas do Active Directory da Litware, mas não o Microsoft Entra ID da Litware (se houver um)
• Cenário C – use o Microsoft Entra ID da Litware.
• Cenário D – Usar a infraestrutura de identidade da Litware pertencente a uma empresa diferente da Microsoft (se a Litware não estiver usando o Active Directory/Microsoft Entra ID)

A tabela a seguir resume cada opção e as tecnologias necessárias para o cliente atingir esses resultados, além das restrições e dos benefícios de cada uma delas.

Detalhes da tabela

• O funcionário se esforça para prever a experiência e o trabalho extra necessários para implementar a solução em uma organização.
• O esforço operacional consiste em tentar prever o custo e o trabalho necessários para manter a solução em execução.
• Os recursos de privacidade e dados mostram se a solução permite o suporte para localização geográfica e limites de dados.
• O isolamento mostra se a solução oferece a capacidade de separar ou delegar modelos de administrador.
• Os recursos de colaboração mostram o nível de colaboração ao qual a solução pode dar suporte; soluções mais integradas fornecem maior fidelidade ao trabalho em equipe.
• O modelo de administração de TI mostra se o modelo de administração precisa ser centralizado ou pode ser descentralizado.
• Limitações: quaisquer questões de desafios que sejam pertinentes.

Árvore de decisão

Use a árvore de decisão a seguir para decidir qual cenário funcionaria melhor para sua organização.

O restante deste documento tratará de quatro cenários de A a D com diversas opções de suporte.

Cenário A – Se a Contoso não quiser depender da infraestrutura de identidade existente da Litware

Para esta opção, a Litware pode não ter nenhum sistema de identidade (por exemplo, uma pequena empresa) ou o cliente pode querer desligar a infraestrutura dela. Também é possível que o cliente queira mantê-la para uso dos funcionários da Litware na autenticação em aplicativos da empresa, mas fornecer a eles novas identidades como parte da Contoso. Por exemplo, se Alice Smith fosse uma funcionária da Litware, ela poderia ter duas identidades – Alice@litware.com e ASmith123@contoso.com. Essas identidades seriam inteiramente distintas uma da outra.

Opção 1 – Combinar em um único sistema de RH

Normalmente, os clientes trariam os funcionários da Litware para o sistema de RH da Contoso. Essa opção faria com que esses funcionários recebessem contas e o acesso correto aos diretórios e aplicativos da Contoso. Assim, um usuário da Litware teria uma nova identidade da Contoso que poderia ser usada para solicitar acesso aos aplicativos corretos dessa empresa.

Opção 2 – Manter o sistema de RH da Litware

Às vezes, a convergência dos sistemas de RH não é possível, pelo menos não a curto prazo. Em vez disso, o cliente conectaria o sistema de provisionamento, como o MIM, para ler ambos os sistemas de RH. Neste diagrama, o RH principal é o ambiente existente da Contoso e o segundo RH é a adição da Litware à infraestrutura geral.

O mesmo cenário também seria possível com a entrada do Microsoft Entra Workday ou do SuccessFactors – a Contoso poderia trazer os usuários da fonte de RH do Workday da Litware para junto dos funcionários existentes da Contoso.

Resultados da consolidação de toda a infraestrutura de identidade

• Infraestrutura de TI reduzida, um único sistema de identidade para gerenciar, sem requisitos de conectividade de rede, exceto por um sistema de RH.
• Experiência administrativa e de usuário final consistente

Restrições da consolidação de toda a infraestrutura de identidade

• Todos os dados necessários aos funcionários da Contoso que são de origem da Litware devem ser migrados para o ambiente da Contoso.
• Quaisquer aplicativos da Litware integrados ao Active Directory ou ao Microsoft Entra necessários para a Contoso devem ser reconfigurados para o ambiente da empresa. Essa reconfiguração pode exigir alterações na configuração, nos grupos usados para o acesso ou até mesmo nos próprios aplicativos.

Cenário B ─ Se a Contoso quiser manter as florestas do Active Directory da Litware, mas não usar o Microsoft Entra ID da Litware

A Litware pode contar com muitos aplicativos existentes que são baseados no Active Directory e, portanto, a Contoso pode querer manter as identidades dos funcionários da Litware no AD existente. Um funcionário da Litware usaria sua identidade existente para a autenticação dos recursos existentes e para a autenticação dos recursos da Contoso. Nesse cenário, a Litware não tem identidades de nuvem no Microsoft Online Services – ou a Litware não era cliente do Microsoft Entra e nenhum dos ativos de nuvem da Litware seria compartilhado com a Contoso, ou a Contoso migrou os ativos de nuvem da Litware para fazer parte do locatário da Contoso.

Opção 3 ─ Relação de confiança entre a floresta e a floresta adquirida

Usando uma relação de confiança de floresta do Active Directory, a Contoso e a Litware podem conectar seus domínios do Active Directory. Essa relação de confiança permite que os usuários da Litware autentiquem os aplicativos da Contoso integrados ao Active Directory. Além disso, o Microsoft Entra Connect também pode ler o conteúdo da floresta do Active Directory da Litware para que os usuários da empresa se autentiquem nos aplicativos da Contoso integrados ao Microsoft Entra. Esta topologia de implantação requer uma rota de rede configurada entre os dois domínios, além de conectividade de rede TCP/IP entre qualquer usuário da Litware e o aplicativo da Contoso integrado ao Active Directory. Também é simples configurar relações de confiança bidirecionais, para que os usuários da Contoso possam acessar os aplicativos da Litware integrados ao AD (quando presentes).

Resultado da criação da relação de confiança de floresta

• Todos os funcionários da Litware podem autenticar os aplicativos da Contoso integrados ao Active Directory ou ao Microsoft Entra, e a Contoso pode usar as ferramentas atuais baseadas no AD para gerenciar a autorização.

Restrições da criação da relação de confiança de floresta

• Requer conectividade TCP/IP entre os usuários que ingressaram no domínio de uma floresta e os recursos ingressados na outra.
• Requer que os aplicativos baseados no Active Directory que estão na floresta da Contoso sejam compatíveis com diversas florestas

Opção 4 ─ Configurar o Microsoft Entra Connect para a floresta adquirida sem relação de confiança de floresta

Um cliente também pode configurar o Microsoft Entra Connect para ler conteúdos de outra floresta. Essa configuração permite que os usuários da Litware se autentiquem nos aplicativos da Contoso integrados ao Microsoft Entra, mas não fornece para eles o acesso aos aplicativos da Contoso integrados ao AD DS – esses aplicativos da Contoso não reconhecem os usuários da Litware. A topologia de implantação requer conectividade de rede TCP/IP entre os controladores de domínio do Microsoft Entra Connect e da Litware. Por exemplo, se o Microsoft Entra Connect estiver em uma VM IaaS da Contoso, também seria necessário estabelecer um túnel para a rede da Litware.

Resultado do uso do Microsoft Entra Connect para provisionar um locatário

• Todos os funcionários da Litware podem autenticar os aplicativos da Contoso integrados ao Microsoft Entra.

Restrições do uso do Microsoft Entra Connect para provisionar um locatário

• Requer conectividade TCP/IP entre os domínios do Microsoft Entra Connect da Contoso e do Active Directory da Litware.
• Não permite que os usuários da Litware tenham acesso aos aplicativos da Contoso baseados no Active Directory

Opção 5 ─ implantar a sincronização na nuvem do Microsoft Entra Connect na floresta adquirida

O provisionamento de nuvem do Microsoft Entra Connect remove o requisito de conectividade de rede, mas só é possível ter um vínculo entre o Active Directory e o Microsoft Entra ID para um determinado usuário com sincronização na nuvem. Os usuários da Litware podem autenticar os aplicativos da Contoso integrados ao Microsoft Entra, mas não os aplicativos da Contoso integrados ao Active Directory. Essa topologia não requer conectividade TCP/IP entre os ambientes locais da Litware e da Contoso.

Resultado da implantação da sincronização na nuvem do Microsoft Entra Connect na floresta adquirida

• Todos os funcionários da Litware podem autenticar os aplicativos da Contoso integrados ao Microsoft Entra.

Restrições do uso da sincronização na nuvem do Microsoft Entra Connect na floresta adquirida

• Não permite que os usuários da Litware tenham acesso aos aplicativos da Contoso baseados no AD

Cenário C ─ se a Contoso quiser manter o Microsoft Entra ID da Litware

A Litware pode ser um cliente do Microsoft Online Services ou do Azure ou pode contar com um ou mais aplicativos baseados no Microsoft Entra ID. Nesse caso, a Contoso pode querer manter as identidades dos funcionários da Litware para acesso a esses recursos. Um funcionário da Litware usaria sua identidade existente para a autenticação dos recursos existentes e para a autenticação dos recursos da Contoso.

Esse cenário é adequado nos casos em que:

• A Litware tem um amplo investimento no Azure ou no Microsoft Online Services, como vários locatários do Office 365, o que acarretaria custos ou tempo para migrar para outro locatário.
• A Litware pode ser lançada no futuro ou é uma parceria que funcionará de maneira independente.
• A Litware não tem infraestrutura local

Opção 6 ─ Manter provisionamento paralelo e SSO para aplicativos em cada Microsoft Entra ID

Uma opção possível é que cada Microsoft Entra ID forneça SSO de maneira independente e provisione os usuários do diretório deles para o aplicativo de destino. Por exemplo, se a TI da Contoso estivesse usando um aplicativo como o Salesforce, forneceria à Litware direitos administrativos para criar usuários na mesma assinatura do Salesforce.

Resultado do provisionamento paralelo

• Os usuários podem autenticar aplicativos com sua identidade existente, sem fazer alterações na infraestrutura da Contoso.

Restrições do provisionamento paralelo

• Com a federação, é necessário que os aplicativos ofereçam suporte a diversos provedores de federação para a mesma assinatura.
• Não é possível para os aplicativos da Microsoft, como o Office ou o Azure
• A Contoso não tem visibilidade no Microsoft Entra ID do acesso dos usuários da Litware ao aplicativo

Opção 7 ─ Configurar contas B2B para usuários do locatário adquirido

Se a Litware estiver executando o próprio locatário, a Contoso poderá ler os usuários dele e, por meio da API de B2B, convidar cada um desses usuários para o locatário da Contoso. (Esse processo de convite em massa pode ser feito por meio do Conector de grafo do MIM, por exemplo.) Se a Contoso também tiver aplicativos baseados no AD que deseja disponibilizar aos usuários da Litware, o MIM também poderá criar usuários no Active Directory que serão mapeados para os UPNs dos usuários do Microsoft Entra, a fim de que o proxy do aplicativo possa executar o KCD em nome de uma declaração de um usuário da Litware no Active Directory da Contoso.

Portanto, quando um funcionário da Litware quiser acessar um aplicativo da Contoso, poderá fazer isso autenticando-se no próprio diretório, com a atribuição de acesso ao locatário do recurso.

Resultado da configuração de contas B2B para usuários de outro locatário

• Os usuários da Litware podem autenticar aplicativos da Contoso e a Contoso controla o acesso no locatário.

Restrições da configuração de contas B2B para usuários de outro locatário

• Requer uma conta duplicada para cada usuário da Litware que precisa de acesso aos recursos da Contoso.
• Requer que os aplicativos sejam compatíveis com B2B para SSO.

Opção 8 ─ Configurar B2B, mas com um feed de RH comum para ambos os diretórios

Em algumas situações, após a aquisição, a organização pode convergir para uma única plataforma de RH, mas ainda executar os sistemas de gerenciamento de identidade existentes. Nesse cenário, o MIM pode provisionar usuários em muitos sistemas do Active Directory, dependendo da parte da organização à qual o usuário está afiliado. Os usuários poderiam continuar usando o B2B para autenticar o diretório existente e ter uma GAL unificada.

Resultado da configuração de usuários convidados de B2B por meio de um feed de sistema de RH comum

• Os usuários da Litware podem se autenticar nos aplicativos da Contoso e a Contoso controla esse acesso no locatário.
• A Litware e a Contoso têm uma GAL unificada.
• Nenhuma alteração no Active Directory ou Microsoft Entra ID da Litware

Restrições da configuração de usuários convidados de B2B por meio de um feed de sistema de RH comum

• Requer mudanças no provisionamento da Contoso para também enviar os usuários ao Active Directory da Litware, além de conectividade entre os domínios da Litware e da Contoso.
• Requer que os aplicativos sejam compatíveis com B2B para SSO.

Cenário D ─ Se a Litware estiver usando uma infraestrutura que não é do Active Directory

Por fim, se a Litware estiver usando outro serviço de diretório, local ou na nuvem, a equipe de TI da Contoso ainda poderá configurar a autenticação dos funcionários da Litware e o acesso aos recursos da Contoso com a identidade existente deles.

Opção 9 ─ Usar a federação direta de B2B (versão prévia pública)

Neste cenário, presume-se que a Litware tenha:

• Alguns diretórios existentes, como o OpenLDAP, ou mesmo um banco de dados SQL ou um arquivo simples de usuários com endereços de email que podem ser compartilhados regularmente com a Contoso.
• Um provedor de identidade compatível com SAML, como o PingFederate ou o OKTA.
• Um domínio DNS roteado publicamente, como Litware.com, e usuários com endereços de email nesse domínio

Nessa abordagem, a Contoso configuraria uma relação de federação direta de seu locatário desse domínio para o provedor de identidade da Litware e, em seguida, leria regularmente as atualizações dos usuários da Litware no diretório deles para convidá-los ao Microsoft Entra ID da Contoso. Esta atualização pode ser feita com um conector de gráfico do MIM. Se a Contoso também tiver aplicativos baseados no Active Directory que serão disponibilizados aos usuários da Litware, o MIM também poderá criar usuários no Active Directory que serão mapeados para os UPNs dos usuários do Microsoft Entra, a fim de que o proxy do aplicativo possa executar KCD em nome de uma representação de um usuário da Litware no Active Directory da Contoso.

Resultado do uso da federação direta de B2B

• Os usuários da Litware se autenticam no Microsoft Entra ID da Contoso com o provedor de identidade existente e acessam a nuvem e os aplicativos Web locais da Contoso,

Restrições do uso da federação direta de B2B

• Requer que os aplicativos da Contoso sejam compatíveis com o SSO do usuário B2B.

Próximas etapas

• O que é a sincronização de nuvem do Microsoft Entra Connect
• Configurar o provisionamento de entrada para o Microsoft Entra ID
• Configurar a federação direta de B2B
• Opções de gerenciamento de usuário de diversos locatários
• O que é o provisionamento de aplicativo?