Arquitetura de provisionamento de identidade de aplicativo local do Microsoft Entra
Descrição geral
O diagrama a seguir mostra uma visão geral de como funciona o 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 seu ambiente local.
- O host ECMA (Extensible Connectivity) Connector converte solicitações de provisionamento da ID do Microsoft Entra em solicitações feitas ao seu aplicativo de destino. Ele serve como um gateway entre o Microsoft Entra ID e seu aplicativo. Você pode usá-lo para importar conectores ECMA2 existentes usados com o Microsoft Identity Manager. O host ECMA não é necessário se você tiver criado um aplicativo SCIM ou gateway SCIM.
- O serviço de provisionamento do Microsoft Entra serve como mecanismo de sincronização.
Nota
A sincronização do Microsoft Identity Manager não é necessária. Mas você pode usá-lo para criar e testar seu conector ECMA2 antes de importá-lo para o host ECMA. O conector ECMA2 é específico para MIM, onde o host ECMA é específico para uso com o agente de provisionamento.
Requisitos de firewall
Não é necessário abrir conexões de entrada para a rede corporativa. Os agentes de provisionamento usam apenas conexões de saída para o serviço de provisionamento, o que significa que não há necessidade de abrir portas de firewall para conexões de entrada. Você também não precisa de uma rede de perímetro (DMZ) porque 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 ECMA Connector Host tem várias áreas que usa para obter provisionamento local. O diagrama abaixo é um desenho conceitual que apresenta essas áreas individuais. A tabela abaixo descreve as áreas em mais detalhes.
Área | Description |
---|---|
Pontos finais | Responsável pela comunicação e transferência de dados com o serviço de provisionamento 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 ECMA Connector Host e a fonte de dados local |
Lógica de negócio | Usado para coordenar todas as atividades do ECMA Connector Host. O tempo de sincronização automática é configurável no host ECMA. Isso está na página de propriedades. |
Sobre atributos de âncora e nomes distintos
As informações a seguir são fornecidas para explicar melhor os atributos de âncora e os nomes distintos, particularmente usados pelo conector genéricoSQL.
O atributo anchor é um atributo exclusivo de um tipo de objeto que não é alterado e representa esse objeto no cache na memória do ECMA Connector Host.
O nome distinto (DN) é um nome que identifica exclusivamente um objeto indicando sua localização atual na hierarquia de diretórios. Ou com SQL, na partição. O nome é formado pela concatenação do atributo anchor na raiz da partição de diretório.
Quando pensamos em DNs tradicionais em um formato tradicional, por exemplo, Ative 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 é plana, não hierárquica, o DN precisa estar já presente em uma das tabelas ou criado a partir das informações que fornecemos ao ECMA Connector Host.
Isso pode ser conseguido marcando Autogenerated na caixa de seleção ao configurar o conector genericSQL. Quando você escolhe DN a ser gerado automaticamente, o host ECMA gera um DN em um formato LDAP: CN=<anchorvalue,OBJECT>=<type>. Isso também pressupõe que o DN esteja Âncora desmarcado na página Conectividade.
O conector genericSQL espera que o DN seja preenchido 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 ECMA Connector Host atualmente suporta apenas o tipo de objeto USER, o OBJECT=<type> será OBJECT=USER. Assim, o DN para um usuário com um valor de âncora de ljacobson seria:
CN=ljacobson,OBJECT=USUÁRIO
Fluxo de trabalho de criação de usuários
O serviço de provisionamento do Microsoft Entra consulta o ECMA Connector Host para ver se o usuário existe. Ele usa o atributo matching como filtro. Esse atributo é definido no portal do Azure em Aplicativos empresariais -> Provisionamento local -> provisionamento -> correspondência de atributos. É denotado pelo 1 para a precedência correspondente. Você pode definir um ou mais atributos correspondentes e priorizá-los com base na precedência. Se você quiser alterar o atributo de correspondência, você também pode fazê-lo.
O ECMA Connector Host recebe a solicitação GET e consulta seu cache interno para ver se o usuário existe e foi importado. Isso é feito usando o(s) atributo(s) correspondente(s) 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 ECMA verificará seu cache em busca de uma correspondência até encontrar uma.
Se o usuário não existir, o ID do Microsoft Entra fará uma solicitação POST para criar o usuário. O ECMA Connector Host 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 de tipos de objeto. Essa âncora será usada pelo Microsoft Entra ID para consultar o ECMA Connector Host para solicitações futuras e subsequentes.
Se ocorrer uma alteração com 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 mude sem quebrar o vínculo entre o usuário no Microsoft Entra ID e no aplicativo.
Práticas recomendadas do agente
- O uso do mesmo agente para o recurso de provisionamento local junto com a sincronização na nuvem Workday / SuccessFactors / Microsoft Entra Connect não é suportado no momento. Estamos trabalhando ativamente para oferecer suporte ao provisionamento local no mesmo agente que os outros cenários de provisionamento.
-
- Evite todas as formas de inspeção em linha nas comunicações TLS de saída entre agentes e o Azure. Este tipo de inspeção em linha causa degradação do fluxo de comunicação.
- O agente deve se comunicar com o Azure e seu aplicativo, para que o posicionamento do agente afete 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. Cada conexão pode ser otimizada por:
- Reduzir a distância entre as duas extremidades do salto.
- Escolher a rede certa para atravessar. Por exemplo, atravessar uma rede privada em vez da Internet pública pode ser mais rápido devido a ligações dedicadas.
- O agente e o ECMA Host dependem de um certificado para comunicação. O certificado autoassinado gerado pelo host ECMA só deve ser usado para fins de teste. O certificado autoassinado expira em dois anos por padrão e não pode ser revogado. A Microsoft recomenda o uso de um certificado de uma CA confiável para casos de uso de produção.
Elevada 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 1 agente ativo e 1 agente passivo (configurado, mas parado, não atribuído ao aplicativo corporativo no Entra) por data center.
Ao fazer um failover, é recomendável fazer o seguinte:
- Pare o agente ativo (A).
- Cancele 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 2 agentes ativos por aplicativo.
Perguntas sobre o agente de provisionamento
Algumas perguntas comuns são respondidas aqui.
Como posso saber a versão do meu agente de provisionamento?
- Entre no servidor Windows onde o agente de provisionamento está instalado.
- Vá para Painel de Controle>Desinstalar ou alterar um programa.
- Procure a versão que corresponde à entrada para o Microsoft Entra Connect Provisioning Agent.
Posso instalar o agente de provisionamento no mesmo servidor que executa o Microsoft Entra Connect ou o Microsoft Identity Manager?
Sim. Você pode instalar o agente de provisionamento no mesmo servidor que executa o Microsoft Entra Connect ou o Microsoft Identity Manager, mas eles não são necessários.
Como configuro o agente de provisionamento para usar um servidor proxy para comunicação HTTP de saída?
O agente de provisionamento oferece suporte ao uso de proxy de saída. Você pode configurá-lo editando o arquivo de configuração do agente C:\Arquivos de Programas\Microsoft Azure AD Connect Provisioning Agent\AADConnectProvisioningAgent.exe.config. Adicione as seguintes linhas nele no final do arquivo imediatamente antes da tag de fechamento </configuration>
. Substitua as variáveis [proxy-server]
pelo [proxy-port]
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 posso garantir que o agente de provisionamento possa se comunicar com o locatário do Microsoft Entra e que nenhum firewall esteja bloqueando as portas exigidas pelo agente?
Você também pode verificar se todas as portas necessárias estão abertas.
Como desinstalo o agente de provisionamento?
- Entre no servidor Windows onde o agente de provisionamento está instalado.
- Vá para Painel de Controle>Desinstalar ou alterar um programa.
- Desinstale os seguintes programas:
- Agente de provisionamento do Microsoft Entra Connect
- Microsoft Entra Connect Agent Updater
- Pacote do Agente de Provisionamento do Microsoft Entra Connect
Histórico do agente de provisionamento
Este artigo lista as versões e recursos do Microsoft Entra Connect Provisioning Agent que foram lançados. A equipe do Microsoft Entra atualiza regularmente o Agente de Provisionamento com novos recursos e funcionalidades. Certifique-se de não usar o mesmo agente para provisionamento local e sincronização na nuvem/provisionamento orientado por RH.
A Microsoft fornece suporte direto para a versão mais recente do agente e uma versão anterior.
Ligação para transferência
O provisionamento de aplicativos locais foi implementado no agente de provisionamento e está disponível no portal. Consulte a instalação do agente de provisionamento.
1.1.892.0
20 de maio de 2022 - lançado para download
Problemas corrigidos
- Adicionamos suporte para exportar alterações em atributos inteiros, o que beneficia os clientes que usam o conector LDAP genérico.
1.1.846.0
11 de abril de 2022 - lançado para download
Problemas corrigidos
- Adicionamos suporte para ObjectGUID como âncora para o conector LDAP genérico ao provisionar usuários no AD LDS.