Arquitetura de provisionamento de identidade de aplicativo local do Microsoft Entra

Visão geral

O diagrama a seguir mostra uma visão geral sobre como funciona o provisionamento de aplicativos locais.

Diagrama que mostra a arquitetura de provisionamento de aplicativos locais.

Há três componentes principais para provisionar usuários em um aplicativo local:

O agente de provisionamento fornece conectividade entre o Microsoft Entra ID e o seu ambiente local.
O host do Conector de Conectividade Extensível (ECMA) converte as solicitações de provisionamento do Microsoft Entra ID nas solicitações feitas ao seu aplicativo de destino. Ele atua como um gateway entre o Microsoft Entra ID e o seu aplicativo. Ele permite importar conectores ECMA2 existentes que são usados com o Microsoft Identity Manager. O host ECMA não será necessário caso você tenha criado um aplicativo SCIM ou um gateway SCIM.
O serviço de provisionamento do Microsoft Entra atua como o mecanismo de sincronização.

Observação

A sincronização do Microsoft Identity Manager não é necessária. No entanto, você pode usá-la para criar e testar seu conector ECMA2 antes de importá-lo para o host ECMA. O conector ECMA2 é específico para o MIM, em que o host ECMA é específico para uso com o agente de provisionamento.

Requisitos de firewall

Não é necessário abrir as conexões de entrada para a rede corporativa. Os agentes de provisionamento utilizam apenas conexões de saída com o serviço de provisionamento, o que significa que não há necessidade de abrir portas de firewall para conexões de entrada. Também não é preciso ter uma DMZ (rede de perímetro), pois todas as conexões são de saída e ocorrem por um canal seguro.

Os pontos de extremidade de saída necessários para os agentes de provisionamento são detalhados aqui.

Arquitetura do Host do Conector ECMA

O Host do Conector ECMA tem várias áreas que ele usa para alcançar o provisionamento local. O diagrama a seguir é um desenho conceitual que apresenta essas áreas individuais. A tabela a seguir descreve cada essas áreas em mais detalhes.

Área	Descrição
Pontos de extremidade	Responsável pela comunicação e pela transferência de dados com o serviço de provisionamento do Microsoft Entra
Cache na memória	Usado para armazenar os dados importados da fonte de dados local
Sincronização automática	Fornece sincronização de dados assíncrona entre o Host do Conector ECMA e a fonte de dados local
Lógica de negócios	Usado para coordenar todas as atividades do Host do Conector ECMA. O tempo da Sincronização Automática é configurável no host ECMA. Isso está na página de propriedades.

Sobre os atributos de âncora e nomes diferenciados

As informações a seguir são fornecidas para explicar melhor os atributos de âncora e os nomes diferenciados usados pelo conector genericSQL.

O atributo de âncora é um atributo exclusivo de um tipo de objeto que não altera nem representa esse objeto no cache do Host do Conector ECMA na memória.

O DN (nome diferenciado) é um nome que identifica exclusivamente um objeto indicando o local atual dele na hierarquia de diretórios. Ou com SQL, na partição. O nome é formado concatenando o atributo de âncora e a raiz da partição de diretório.

Quando pensamos nos DNs tradicionais em um formato tradicional, por exemplo, Active Directory ou LDAP, pensamos em algo semelhante a:

CN=Lola Jacobson,CN=Users,DC=contoso,DC=com

No entanto, para uma fonte de dados como SQL, que é simples, não hierárquica, o DN precisa estar presente em uma das tabelas ou ser criado com base nas informações que fornecemos para o Host do Conector ECMA.

Isso pode ser obtido marcando a caixa de seleção Gerado automaticamente ao configurar o conector genericSQL. Quando você escolhe um DN a ser gerado automaticamente, o host ECMA gerará um DN em um formato LDAP: CN=<anchorvalue>,OBJECT=<type>. Isso também pressupõe que o DN é Âncora está desmarcada na página Conectividade.

O conector genericSQL espera que o DN seja populado usando um formato LDAP. O conector SQL genérico está usando o estilo LDAP com o nome do componente "OBJECT=". Isso permite que ele use partições (cada tipo de objeto é uma partição).

Como o Host do Conector ECMA, no momento, dá suporte apenas ao tipo de objeto USER, o OBJECT=<type> será OBJECT=USER. Portanto, o DN para um usuário com um valor de âncora de ljacobson seria:

CN=ljacobson,OBJECT=USER

Fluxo de trabalho de criação de usuário

O serviço de provisionamento do Microsoft Entra consulta o Host do Conector ECMA para ver se o usuário existe. Ele usa o atributo correspondente como o filtro. O atributo é definido no centro de administração do Microsoft Entra em Aplicativos empresariais -> Provisionamento local -> provisionamento -> correspondência de atributos. Ele é indicado pelo 1 para a precedência da correspondência. Você pode definir um ou mais atributos correspondentes e priorizá-los com base na precedência. Se desejar alterar o atributo correspondente, também poderá fazer isso.
O ECMA Connector Host recebe a solicitação GET e consulta seu cache interno para verificar se o usuário existe e foi importado. Isso é feito usando os atributos correspondentes acima. Se você definir vários atributos correspondentes, o serviço de provisionamento do Microsoft Entra enviará uma solicitação GET para cada atributo e o host do ECMA verificará seu cache para obter uma correspondência até encontrar um.
Se o usuário não existir, o Microsoft Entra ID produzirá uma solicitação POST para criar o usuário. O Host do Conector ECMA responde ao Microsoft Entra ID com o HTTP 201 e fornece uma ID para o usuário. Essa ID é derivada do valor de âncora definido na página tipos de objeto. Essa âncora será usada pelo Microsoft Entra ID para consultar o Host do Conector ECMA nas solicitações futuras e subsequentes.
Se uma alteração ocorrer para o usuário no Microsoft Entra ID, o Microsoft Entra ID fará uma solicitação GET para recuperar o usuário usando a âncora da etapa anterior, em vez do atributo correspondente na etapa 1. Isso permite, por exemplo, que o UPN seja alterado sem quebrar o vínculo entre o usuário no Microsoft Entra ID e no aplicativo.

Melhores práticas do agente

- Evite todas as formas de inspeção embutida nas comunicações TLS de saída entre agentes e o Azure. Esse tipo de inspeção em linha degrada o fluxo de comunicação.
Como o agente precisa se comunicar com o Azure e com o seu aplicativo, a localização dele deve abranger a latência dessas duas conexões. Você pode minimizar a latência do tráfego de ponta a ponta otimizando cada conexão de rede. As maneiras de otimizar cada conexão incluem:
Reduzir a distância entre as duas extremidades do salto.
Escolhendo a rede certa para percorrer. Por exemplo, percorrer uma rede privada, em vez da Internet pública, pode ser mais rápido devido aos links dedicados.
O agente usa certificados para comunicação segura. Para obter detalhes sobre os dois certificados que o sistema usa, incluindo comportamento de expiração e recomendações para uso em produção, consulte o gerenciamento de certificados.

Gerenciamento de certificados

O provisionamento de aplicativo local depende de dois certificados distintos. Entender ambos os certificados ajuda você a planejar implantações de produção, monitorar a integridade do agente e evitar interrupções de serviço.

Certificado do Host do Conector ECMA

O Microsoft Entra Host do Conector ECMA expõe um ponto de extremidade HTTPS na porta 8585 (https://localhost:8585/ecma2host_<connectorName>/scim) que o agente de provisionamento chama. O certificado TLS que o Host do Conector ECMA usa protege esse endpoint. Quando você executa pela primeira vez o assistente de configuração Microsoft ECMA2Host, ele solicita que você crie um certificado selecionando Gerar certificado. O certificado gerado automaticamente é autoassinado, e o nome alternativo de assunto (SAN) do certificado corresponde ao nome do host.

Principais fatos sobre o certificado do Conector Host ECMA:

O certificado autoassinado destina-se apenas a testes. Ele expira em dois anos por padrão e não pode ser revogado. Microsoft recomenda usar um certificado emitido por uma AC (autoridade de certificação) confiável para uso em produção.
O assunto do certificado deve corresponder ao nome do host do servidor Windows em que o Host do Conector ECMA está instalado. Para obter mais informações, consulte certificados SSL.
Substitua certificados expirados manualmente. Vá para a guia Configurações do host ECMA para exibir a data de validade do certificado. Se o certificado tiver expirado, selecione Gerar certificado para criar um novo. Para obter diretrizes passo a passo, consulte Solucionar problemas de conexão de teste.

Certificado de registro do agente de provisionamento

O agente de provisionamento usa um certificado separado para se registrar no Microsoft Serviço de Identidade Híbrida (HIS) durante a instalação. O agente cria esse certificado durante a instalação e usa seu token Microsoft Entra para registrar o agente e o certificado com o Serviço de Registro HIS. Para obter mais informações sobre como o agente se registra com HIS, consulte a instalação do Agente.

Importante

A sincronização de nuvem documenta um cenário de limpeza relacionado: quando um agente de sincronização de nuvem foi desinstalado ou interrompido e seu certificado expira, o agente é permanentemente removido e não pode mais interagir com serviços Microsoft. Para obter mais informações, consulte a remoção do Agente do portal após a desinstalação. Para provisionamento de aplicativos locais, entre em contato com Microsoft suporte se precisar de diretrizes sobre o tempo de vida do certificado de registro ou procedimentos de recuperação.

Para minimizar o risco de interrupção do serviço:

Monitore a integridade do agente regularmente por meio do centro de administração do Microsoft Entra.
Planeje a substituição do certificado do Host do Conector ECMA antes que o certificado autoassinado expire após dois anos.
Para implantações de produção, substitua o certificado de Host do Conector ECMA autoassinado por um emitido por uma Autoridade Certificadora confiável.

Alta disponibilidade

As informações a seguir são fornecidas para cenários de alta disponibilidade/failover.

Para aplicativos locais que usam o conector ECMA: a recomendação é ter um agente ativo e um agente passivo (configurado, mas parado, não atribuído ao aplicativo empresarial no Microsoft Entra) por data center.

Ao fazer um failover, é recomendável fazer o seguinte:

Pare o agente ativo (A).
Cancelar a atribuição do agente A do aplicativo empresarial.
Reinicie o agente passivo (B).
Atribua o agente B ao aplicativo empresarial.

Para aplicativos locais que usam o conector SCIM: a recomendação é ter dois agentes ativos por aplicativo.

Perguntas sobre o agente de provisionamento

Veja a seguir a resposta para algumas perguntas comuns.

Como posso saber a versão do agente de provisionamento?

Conecte-se ao servidor Windows no qual o agente de provisionamento está instalado.
Acesse Painel de controle>Desinstalar ou alterar um programa.
Procure a versão correspondente à entrada Agente de provisionamento do Microsoft Entra Connect.

Posso instalar o agente de provisionamento no mesmo servidor que executa o Microsoft Entra Connect ou o Microsoft Identity Manager?

Sim. Sim, você pode instalar o agente de provisionamento no mesmo servidor que executa o Microsoft Entra Connect ou o Microsoft Identity Manager, mas isso não é necessário.

Como configurar o agente de provisionamento a fim de usar um servidor proxy para comunicação HTTP de saída?

O agente de provisionamento dá suporte ao uso do proxy de saída. Você pode configurá-lo editando o arquivo de configuração do agente C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\AADConnectProvisioningAgent.exe.config. Adicione as seguintes linhas no final do arquivo, pouco antes da marca de fechamento </configuration>. Substitua as variáveis [proxy-server] e [proxy-port] pelo nome do servidor proxy e pelos valores da porta.

 <system.net>
  <defaultProxy enabled="true" useDefaultCredentials="true">
    <proxy
     usesystemdefault="true"
     proxyaddress="http://[proxy-server]:[proxy-port]"
     bypassonlocal="true"
    />
   </defaultProxy>
 </system.net>

Como garantir a comunicação do agente de provisionamento com o locatário do Microsoft Entra e que nenhum firewall esteja bloqueando as portas exigidas por ele?

Verifique também se todas as portas necessárias estão abertas.

Como desinstalar o agente de provisionamento?

Conecte-se ao servidor Windows no qual o agente de provisionamento está instalado.
Acesse Painel de controle>Desinstalar ou alterar um programa.
Desinstale os programas a seguir:

Agente de provisionamento do Microsoft Entra Connect
Atualizador do Agente do Microsoft Entra Connect
Pacote do Agente de Provisionamento do Microsoft Entra Connect

Atualizações de agentes

Microsoft libera regularmente novas versões do agente de provisionamento com recursos, correções e atualizações. Para obter o histórico de versão atual e as notas de versão, consulte Microsoft Entra Connect Provisioning Agent: histórico de versão.