Arquitetura de provisionamento de identidade de aplicativo local do Azure AD (versão prévia)

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 Azure AD (Active Directory) e seu ambiente local.
  • O host ECMA converte as solicitações de provisionamento do Azure AD em solicitações feitas ao seu aplicativo de destino. Ele atua como um gateway entre o Azure AD 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 Azure AD 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 ECMA antes de importá-lo para o host ECMA.

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.

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.

Host do conector ECMA

Área Descrição
Pontos de extremidade Responsável pela comunicação e pela transferência de dados com o serviço de provisionamento do Azure AD
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, no caso de 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.

Caixa O DN é Âncora desmarcada

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

  1. O serviço de provisionamento do Azure AD 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 AD 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. Atributo correspondente

  2. 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 Azure AD enviará uma solicitação GET para cada atributo e o host do ECMA verificará seu cache para obter uma correspondência até encontrar um.

  3. Se o usuário não existir, o Azure AD produzirá uma solicitação POST para criar o usuário. O Host do Conector ECMA responderá de volta ao Azure AD 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 Azure AD para consultar o Host do Conector ECMA para solicitações futuras e subsequentes.

  4. Se uma alteração ocorrer para o usuário no Azure AD, o Azure AD 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 Azure Active Directory e no aplicativo.

Melhores práticas do agente

  • No momento, não há suporte para o uso do mesmo agente para o recurso de provisionamento local com o Workday/SuccessFactors/Sincronização na nuvem do Azure AD Connect. 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.

Perguntas sobre o agente de provisionamento

Veja a seguir a resposta para algumas perguntas comuns.

Como saber a versão do agente de provisionamento?

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

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

Sim. Sim, você pode instalar o agente de provisionamento no mesmo servidor que executa o Azure AD 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 Azure AD 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?

  1. Conecte-se ao servidor Windows no qual o agente de provisionamento está instalado.
  2. Acesse Painel de controle>Desinstalar ou alterar um programa.
  3. Desinstale os programas a seguir:
    • Agente de Provisionamento do Microsoft Azure AD Connect
    • Atualizador do Agente do Microsoft Azure AD Connect
    • Pacote do Agente de Provisionamento do Microsoft Azure AD Connect

Histórico do agente de provisionamento

Este artigo lista as versões e recursos do agente de provisionamento do Azure Active Directory Connect que foram lançados. A equipe do Azure AD atualiza regularmente o agente de provisionamento com novos recursos e funcionalidades. Certifique-se de não usar o mesmo agente para provisionamento local e provisionamento controlado por RH/Sincronização de Nuvem.

A Microsoft fornece suporte direto para a versão mais recente do agente e uma versão anterior.

Você pode baixar a última versão do agente usando este link.

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.

Próximas etapas