Share via

Arquitetura de provisionamento de identidade de aplicativo local do Microsoft Entra

  • Artigo

Descrição geral

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

Diagram that shows the architecture for on-premises application provisioning.

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.

ECMA connector host

Á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 gerará 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.

DN is Anchor unchecked

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 âncora de ljacobson seria:

CN=ljacobson,OBJECT=USUÁRIO

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

  1. 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. Matching attribute

  2. 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 um.

  3. 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 responderá 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 de tipos de objeto. Essa âncora será usada pelo Microsoft Entra ID para consultar o ECMA Connector Host para solicitações futuras e subsequentes.

  4. 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.

Perguntas sobre o agente de provisionamento

Algumas perguntas comuns são respondidas aqui.

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

  1. Entre no servidor Windows onde o agente de provisionamento está instalado.
  2. Vá para Painel de controle>desinstalar ou alterar um programa.
  3. 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?

  1. Entre no servidor Windows onde o agente de provisionamento está instalado.
  2. Vá para Painel de controle>desinstalar ou alterar um programa.
  3. 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.

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.

Próximos passos