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.
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 em 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 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, especialmente usados pelo conector do 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 a caixa O DN é Âncora está desmarcada na página Conectividade.
O conector genericSQL espera que o DN seja populado usando um formato LDAP. O conector genericSQL 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 anchorvalue 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 portal do Azure 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 Host do Conector ECMA recebe a solicitação GET e consulta o cache interno dela para ver se o usuário existe e tem importação baseada. 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 responderá de volta ao Microsoft Entra ID com o HTTP 201 e fornecerá 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 para 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
- No momento, o uso do mesmo agente para o recurso de provisionamento local, juntamente com Workday/SuccessFactors/Microsoft Entra Connect, não tem suporte. Estamos trabalhando ativamente para dar suporte ao provisionamento local no mesmo agente que os outros cenários de provisionamento.
-
- Evite todas as formas de inspeção embutida em comunicações TLS de saída entre agentes e o Azure. Esse tipo de inspeção embutida causa degradação no 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. Cada conexão pode ser otimizada com:
- Reduzindo 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 e o Host ECMA 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 usar um certificado de uma AC confiável para casos de uso de produção.
Perguntas sobre o agente de provisionamento
Veja a seguir a resposta para algumas perguntas comuns.
Como 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
Histórico do agente de provisionamento
Este artigo lista as versões e recursos do Agente de Provisionamento do Microsoft Entra Connect que foram lançados. A equipe do Microsoft Entra atualiza regularmente o Agente de Provisionamento com novos recursos e funcionalidades. Verifique se você não usa o mesmo agente para provisionamento local e sincronização de nuvem/provisionamento controlado por RH.
A Microsoft fornece suporte direto para a versão mais recente do agente e uma versão anterior.
Link de download
O provisionamento de aplicativo local foi implantado no agente de provisionamento e está disponível no portal. Consulte instalar o agente de provisionamento.
1.1.892.0
20 de maio de 2022 – versão 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: versão para download
Problemas corrigidos
- Adicionamos suporte para ObjectGUID como uma âncora para o conector LDAP genérico ao provisionar usuários no AD LDS.