Configuração do Microsoft Entra ID para provisionar usuários em diretórios LDAP

  • Artigo

A documentação a seguir fornece informações de configuração e tutorial que demonstram como provisionar usuários do Microsoft Entra ID em um diretório LDAP.

Este documento descreve as etapas que você precisa executar para provisionar e desprovisionar automaticamente os usuários do Microsoft Entra ID em um diretório LDAP. O documento mostra como você pode provisionar usuários no AD LDS como um diretório LDAP de exemplo, mas você pode provisionar em qualquer um dos servidores de diretório LDAP com suporte mencionados nas seções a seguir. Não há suporte para o provisionamento de usuários no Active Directory Domain Services por meio desta solução.

Para obter detalhes importantes sobre o que faz esse serviço, como ele funciona e as perguntas frequentes, confira Automatizar o provisionamento e o desprovisionamento de usuários para aplicativos SaaS com o Microsoft Entra ID e arquitetura de provisionamento de aplicativos locais. O vídeo a seguir fornece uma visão geral do provisionamento local.

Pré-requisitos para provisionar usuários em um diretório LDAP

Pré-requisitos do local

  • Um aplicativo que usa um servidor de diretório para consultar usuários.
  • Um diretório de destino, diferente dos Serviços de Domínio Active Directory, no qual os usuários podem ser criados, atualizados e excluídos. Por exemplo, Serviços Lightweight do Active Directory (AD LDS). Essa instância de diretório não deve ser um diretório usado também para provisionar usuários no Microsoft Entra ID, pois ter ambos os cenários pode criar um loop com o Microsoft Entra Connect.
  • Um computador com pelo menos 3 GB de RAM para hospedar um agente de provisionamento. O computador deve ter o Windows Server 2016 ou uma versão posterior do Windows Server, com conectividade com o diretório de destino e conectividade de saída com login.microsoftonline.com, outros Microsoft Online Services e domínios doAzure. Um exemplo é uma máquina virtual do Windows Server 2016 hospedada na IaaS do Azure ou por trás de um proxy.
  • O .NET Framework 4.7.2 precisa ser instalado.
  • Opcional: embora não seja necessário, é recomendável baixar o Microsoft Edge para Windows Server e usá-lo em vez do Internet Explorer.

Servidor de diretório LDAP com suporte

O Conector depende de diversas técnicas para detectar e identificar o servidor LDAP. O Conector usa Root DSE, o nome e a versão do fornecedor e inspeciona o esquema para localizar objetos exclusivos e atributos presentes em determinados servidores LDAP.

  • OpenLDAP
  • Microsoft Active Directory Lightweight Directory Services
  • Directory Server 389
  • Apache Directory Server
  • IBM Tivoli DS
  • Isode Directory
  • NetIQ eDirectory
  • Novell eDirectory
  • Open DJ
  • Open DS
  • Oracle (antigo Sun ONE) Directory Server Enterprise Edition
  • RadiantOne Virtual Directory Server (VDS)

Para obter mais informações, confira a referência do Conector LDAP Genérico.

Requisitos de nuvem

  • Um locatário do Microsoft Entra com Microsoft Entra ID P1 ou Premium P2 (ou EMS E3 ou E5).

    O uso desse recurso requer licenças de P1 do Microsoft Entra ID. Para encontrar a licença certa para seus requisitos, confira Comparar recursos do Microsoft Entra ID com disponibilidade geral.

  • A função Administrador de Identidade Híbrida para configuração do agente de provisionamento e as funções Administrador de Aplicativos ou Administrador de Aplicativos de Nuvem para configuração do provisionamento no portal do Azure.

  • Os usuários do Microsoft Entra a serem provisionados para o diretório LDAP já devem ser preenchidos com os atributos que serão exigidos pelo esquema do servidor de diretório e são específicos para cada usuário. Por exemplo, se o servidor de diretório exigir que cada usuário tenha um número exclusivo entre 10000 e 30000 como seu número de ID de Usuário para dar suporte a uma carga de trabalho POSIX, você precisará gerar o número de um atributo existente no usuário ou estender o esquema do Microsoft Entra e preencher esse atributo nos usuários no escopo do aplicativo baseado em LDAP. Consulte Extensibilidade do Graph para saber como criar extensões de diretório adicionais.

Mais recomendações e limitações

Os marcadores a seguir são mais recomendações e limitações.

  • Não é recomendável usar o mesmo agente para sincronização de nuvem e provisionamento de aplicativo local. A Microsoft recomenda usar um agente separado para sincronização de nuvem e outro para o provisionamento de aplicativo local.
  • Para o AD LDS, os usuários não podem ser provisionados com senhas no momento. Portanto, será necessário desabilitar a política de senha do AD LDS ou provisionar os usuários em um estado desabilitado.
  • Para outros servidores de diretório, uma senha aleatória inicial pode ser definida, mas não é possível provisionar uma senha de usuário do Microsoft Entra em um servidor de diretório.
  • Não há suporte para o provisionamento de usuários do Microsoft Entra ID para o Active Directory Domain Services.
  • Não há suporte para o provisionamento de usuários do LDAP no Microsoft Entra ID.
  • Não há suporte para grupos de provisionamento e associações de usuário em um servidor de diretório.

Selecionar perfis de execução

Ao criar a configuração para que o conector interaja com um servidor de diretório, você primeiro configurará o conector para ler o esquema do seu diretório, mapear esse esquema para o do Microsoft Entra ID e, em seguida, configurar a abordagem que o conector deve usar continuamente, através de perfis de execução. Cada perfil de execução que você configurar especifica como o conector gerará solicitações LDAP para importar ou exportar dados do servidor de diretório. Antes de implantar o conector em um servidor de diretório existente, você precisará conversar com o operador do servidor de diretório na sua organização sobre o padrão de operações que serão realizadas com o servidor de diretório dele.

  • Após a configuração, quando o serviço de provisionamento for iniciado, ele realizará automaticamente as interações configuradas no perfil de execução de Importação Completa. Nesse perfil de execução, o conector lerá todos os registros de usuários do diretório, usando uma operação de Pesquisa LDAP. Esse perfil de execução é necessário para que, posteriormente, se o Microsoft Entra ID precisar fazer uma alteração para um usuário, o Microsoft Entra ID atualizará um objeto existente para o usuário no banco de dados, em vez de criar um novo objeto para esse usuário.

  • Sempre que alterações são feitas no Microsoft Entra ID, como atribuir um novo usuário ao aplicativo ou atualizar um usuário existente, o serviço de provisionamento executará as interações LDAP no perfil de execução da Exportação. No perfil de execução Exportar, o Microsoft Entra ID emitirá solicitações LDAP para adicionar, modificar, remover ou renomear objetos no diretório, a fim de trazer o conteúdo do diretório em sincronia com Microsoft Entra.

  • Se o diretório der suporte, você também poderá configurar opcionalmente um perfil de execução de Importação Delta. Nesse perfil de execução, o Microsoft Entra ID lerá as alterações feitas no diretório, exceto pelo Microsoft Entra ID, desde a última importação completa ou delta. Esse perfil de execução é opcional, pois o diretório pode não ter sido configurado para dar suporte a uma importação delta. Por exemplo, se sua organização estiver usando OpenLDAP, OpenLDAP deverá ter sido implantado com o recurso de sobreposição de log de acesso habilitado.

Determinar como o Conector do LDAP do Microsoft Entra interagirá com o servidor de diretório

Antes de implantar o conector em um servidor de diretório existente, você precisará discutir com o operador do servidor de diretório na sua organização como se integrar ao servidor de diretório. As informações que você coletará incluem as informações de rede de como se conectar ao servidor de diretório, como o conector deve se autenticar no servidor de diretório, qual esquema o servidor de diretório selecionou para modelar usuários, o nome diferenciado de base do contexto de nomenclatura e as regras de hierarquia de diretório, como associar usuários no servidor de diretório a usuários no Microsoft Entra ID e o que deve acontecer quando um usuário sai do escopo no Microsoft Entra ID. A implantação desse conector pode exigir alterações na configuração do servidor de diretório, bem como alterações de configuração no Microsoft Entra ID. Para implantações que envolvem a integração do Microsoft Entra ID com um servidor de diretório de terceiros em um ambiente de produção, recomendamos que os clientes trabalhem com o fornecedor do servidor de diretório ou um parceiro de implantação para obter ajuda, diretrizes e suporte para essa integração. Este artigo usa os seguintes valores de exemplo para dois diretórios, para AD LDS e para OpenLDAP.

Definição de configuração Onde o valor é definido Valor de exemplo
nome do host do servidor de diretório Página Conectividade do assistente de configuração APP3
número da porta do servidor de diretório Página Conectividade do assistente de configuração 636. Para LDAP sobre SSL ou TLS (LDAPS), use a porta 636. Para Start TLS, use a porta 389.
conta para que o conector se identifique com o servidor de diretório Página Conectividade do assistente de configuração Para AD LDS, CN=svcAccountLDAP,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab e, para OpenLDAP, cn=admin,dc=contoso,dc=lab
senha para que o conector se autentique no servidor de diretório Página Conectividade do assistente de configuração
classe de objeto estrutural para um usuário no servidor de diretório Página Tipos de Objeto do assistente de configuração Para AD LDS, User e, para OpenLDAP, inetOrgPerson
classes de objeto auxiliar para um usuário no servidor de diretório mapeamentos de atributo da página Provisionamento no portal do Azure Para OpenLDAP com o esquema POSIX, posixAccount eshadowAccount
atributos a serem preenchidos em um novo usuário Mapeamentos de atributo da página Selecionar Atributos do assistente de configuração e da página Provisionamento Para AD LDS msDS-UserAccountDisabled, userPrincipalName, displayName a para OpenLDAP cn, gidNumber, homeDirectory, mail, objectClass, sn, uid, uidNumber, userPassword
hierarquia de nomenclatura exigida pelo servidor de diretório mapeamentos de atributo da página Provisionamento no portal do Azure Defina o DN de um usuário recém-criado como sendo imediatamente abaixo de CN=CloudUsers,CN=App,DC=Contoso,DC=lab para AD LDS e DC=Contoso,DC=lab para OpenLDAP
atributos para correlacionar usuários no Microsoft Entra ID e no servidor de diretório mapeamentos de atributo da página Provisionamento no portal do Azure Para o AD LDS, não configurado pois esse exemplo é para um diretório inicialmente vazio e ou OpenLDAP, mail
comportamento de desprovisionamento quando um usuário sai do escopo no Microsoft Entra Página de Desprovisionamento do assistente de configuração Excluir o usuário do servidor de diretório

O endereço de rede de um servidor de diretório é um nome do host e um número da porta TCP, normalmente porta 389 ou 636. As conexões de rede do conector para um servidor de diretório precisam ser protegidas usando SSL ou TLS, exceto no caso de o servidor de diretório estar localizado junto com o conector no mesmo Windows Server ou se você estiver usando a segurança em nível de rede. O conector dá suporte à conexão com um servidor de diretório na porta 389 e ao usar Iniciar TLS para habilitar o TLS na sessão. O conector também dá suporte à conexão com um servidor de diretório na porta 636 para LDAPS – LDAP por TLS.

Você precisará ter uma conta identificada para o conector se autenticar no servidor de diretório já configurado no servidor de diretório. Normalmente, essa conta é identificada com um nome diferenciado e tem uma senha ou certificado de cliente associado. Para executar operações de importação e exportação nos objetos no diretório conectado, a conta do conector deve ter permissões suficientes no modelo de controle de acesso do diretório. O conector precisa ter permissões de gravação para conseguir exportar e de permissões de leitura para importar. Configuração das permissões é executada dentro das experiências de gerenciamento da própria pasta de destino.

Um esquema de diretório especifica as classes de objeto e os atributos que representam uma entidade do mundo real no diretório. O conector dá suporte a um usuário que está sendo representado com uma classe de objeto estrutural, como inetOrgPerson, e, opcionalmente, classes de objeto auxiliares adicionais. Para que o conector possa provisionar usuários no servidor de diretório, durante a configuração no portal do Azure você definirá mapeamentos do esquema do Microsoft Entra para todos os atributos obrigatórios. Isso inclui os atributos obrigatórios da classe de objeto estrutural, quaisquer superclasses dessa classe de objeto estrutural e os atributos obrigatórios de qualquer classe de objeto auxiliar. Além disso, você provavelmente também configurará mapeamentos para alguns atributos opcionais dessas classes. Por exemplo, um servidor de diretório OpenLDAP pode exigir um objeto para que um novo usuário tenha atributos como o exemplo a seguir.

dn: cn=bsimon,dc=Contoso,dc=lab
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: bsimon
gidNumber: 10000
homeDirectory: /home/bsimon
sn: simon
uid: bsimon
uidNumber: 10011
mail: bsimon@contoso.com
userPassword: initial-password

As regras de hierarquia de diretório implementadas por um servidor de diretório descrevem como os objetos de cada usuário se relacionam entre si e com objetos existentes no diretório. Na maioria das implantações, a organização optou por ter uma hierarquia simples no seu servidor de diretório, na qual cada objeto para um usuário está localizado imediatamente embaixo de um objeto base comum. Por exemplo, se o nome diferenciado de base para o contexto de nomenclatura em um servidor de diretório for dc=contoso,dc=com, um novo usuário terá um nome diferenciado como cn=alice,dc=contoso,dc=com. No entanto, algumas organizações podem ter uma hierarquia de diretório mais complexa. Nesse caso, você precisará implementar as regras ao especificar o mapeamento de nome diferenciado para o conector. Por exemplo, um servidor de diretório pode esperar que os usuários estejam em unidades organizacionais por departamento. Portanto, um novo usuário teria um nome diferenciado como cn=alice,ou=London,dc=contoso,dc=com. Como o conector não cria objetos intermediários para unidades organizacionais, todos os objetos intermediários que a hierarquia de regras do servidor de diretório espera já devem existir no servidor de diretório.

Em seguida, você precisará definir as regras de como o conector deve determinar se já existe um usuário no servidor de diretório correspondente a um usuário do Microsoft Entra. Cada diretório LDAP tem um nome diferenciado exclusivo para cada objeto no servidor de diretório. No entanto, esse nome diferenciado geralmente não está presente para usuários no Microsoft Entra ID. Em vez disso, uma organização pode ter um atributo diferente, como mail ou employeeId, no seu esquema de servidor de diretório que também está presente nos seus usuários no Microsoft Entra ID. Em seguida, quando o conector está provisionando um novo usuário em um servidor de diretório, o conector pode pesquisar se já existe um usuário nesse diretório que tenha um valor específico desse atributo e criar apenas um novo usuário no servidor de diretório, se um não estiver presente.

Se o cenário envolver a criação de novos usuários no diretório LDAP e não apenas atualizar ou excluir usuários existentes, você também precisará determinar como os aplicativos que usam esse servidor de diretório lidarão com a autenticação. A abordagem recomendada é que os aplicativos usem um protocolo de federação ou logon único, como SAML, OAuth ou OpenID Connect, para se autenticar no Microsoft Entra ID e dependerem apenas do servidor de diretório para atributos. Tradicionalmente, os diretórios LDAP podiam ser usados por aplicativos para autenticar usuários verificando uma senha, mas esse caso de uso não é possível para autenticação multifator ou quando o usuário já tiver sido autenticado. Alguns aplicativos podem consultar a chave pública SSH de um usuário ou o certificado do diretório, o que pode ser apropriado para os usuários que já possuem credenciais desses formulários. No entanto, se o aplicativo que depende do servidor de diretório não der suporte a protocolos de autenticação modernos ou credenciais mais fortes, você precisará definir uma senha específica do aplicativo ao criar um usuário no diretório, pois o Microsoft Entra ID não dá suporte ao provisionamento da senha de um usuário do Microsoft Entra.

Por fim, você precisará concordar com o comportamento de desprovisionamento. Quando o conector está configurado e o Microsoft Entra ID estabeleceu um vínculo entre um usuário no Microsoft Entra ID e um usuário no diretório, seja ele um usuário que já está no diretório ou um novo usuário, o Microsoft Entra ID pode provisionar alterações de atributo do usuário do Microsoft Entra no diretório. Se um usuário atribuído ao aplicativo for excluído do Microsoft Entra ID, então o Microsoft Entra ID enviará uma operação de exclusão para o servidor do diretório. Também pode ser interessante que o Microsoft Entra ID atualize o objeto no servidor de diretório quando um usuário sair do escopo de poder usar o aplicativo. Esse comportamento depende do aplicativo que usará o servidor de diretório, pois muitos diretórios, como OpenLDAP, podem não ter uma maneira padrão de indicar que a conta de um usuário está inativada.

Preparar o diretório LDAP

Se você ainda não tiver um servidor de diretório e quiser experimentar esse recurso, Preparar o Lightweight Directory Services do Active Directory para provisionamento do Microsoft Entra ID mostra como criar um ambiente de teste do AD LDS. Se você já tiver outro servidor de diretório implantado, poderá ignorar esse artigo e continuar instalando e configurando o host do conector ECMA.

Instalar e configurar o agente de provisionamento do Microsoft Entra Connect

Se você já baixou o agente de provisionamento e o configurou para outro aplicativo local, continue lendo na próxima seção.

  1. Entre no portal do Azure.
  2. Acesse Aplicativos empresariais e selecione Novo aplicativo.
  3. Pesquise o aplicativo ECMA local, dê um nome ao aplicativo e selecione Criar para adicioná-lo ao seu locatário.
  4. Do menu, navegue até a página de Provisionamento do seu aplicativo.
  5. Selecione Introdução.
  6. Na página Provisionamento, altere o modo para Automático.

Captura de tela da seleção Automática.

  1. Em Conectividade local, selecione Baixar e instalar e selecione Aceitar termos e baixar.

Captura de tela do local do download para o agente.

  1. Saia do portal e abra o instalador do agente de provisionamento, concorde com os termos de serviço e selecione Instalar.
  2. Aguarde o assistente de configuração do agente de provisionamento do Microsoft Entra e selecione Avançar.
  3. Na etapa Selecionar Extensão, selecione Provisionamento de aplicativo local e, em seguida, selecione Avançar.
  4. O agente de provisionamento usará o navegador da Web do sistema operacional para exibir uma janela pop-up para você e potencialmente se autenticar no Microsoft Entra ID e, potencialmente, também no provedor de identidade da sua organização. Se você estiver usando o Internet Explorer como navegador no Windows Server, talvez seja necessário adicionar os sites da Microsoft à lista de sites confiáveis do navegador para permitir que o JavaScript seja executado corretamente.
  5. Forneça credencial para um administrador do Microsoft Entra quando solicitado a autorizar. O usuário deve ter a função de Administrador de Identidade Híbrida ou de Administrador Global.
  6. Selecione Confirmar para confirmar a configuração. Depois que a instalação for bem-sucedida, você poderá selecionar Sair e também fechar o instalador do pacote do agente de provisionamento.

Configurar o dispositivo ECMA local

  1. De volta ao portal, na seção Conectividade Local, selecione o agente que você implantou e selecione Atribuir Agente(s).

    Captura de tela que mostra como selecionar e atribuir e agente.

  2. Mantenha essa janela do navegador aberta, conforme você conclui a próxima etapa de configuração usando o assistente de configuração.

Configurar o certificado de host do conector ECMA do Microsoft Entra

  1. No Windows Server em que o agente de provisionamento está instalado, clique com o botão direito do mouse no Assistente de Configuração do Microsoft ECMA2Host no menu Iniciar e execute como administrador. A execução como administrador do Windows é necessária para que o assistente crie os logs de eventos do Windows necessários.
  2. Depois que a Configuração de Host do Conector do ECMA for iniciada, se essa for a primeira vez que você executa o assistente, ele solicitará que você crie um certificado. Deixe a porta padrão 8585 e selecione Gerar certificado para gerar um certificado. O certificado gerado automaticamente será autoassinado como parte da raiz de confiança. A rede SAN corresponde ao nome do host. Captura de tela que mostra a definição de suas configurações.
  3. Selecione Salvar.

Observação

Se você optou por gerar um novo certificado, registre a data de validade do certificado para garantir que você agende para retornar ao assistente de configuração e gere novamente o certificado antes que ele expire.

Configurar um conector LDAP genérico

Dependendo das opções escolhidas, algumas das telas do assistente podem não estar disponíveis e as informações podem ser um pouco diferentes. Para os fins desta configuração de exemplo, o provisionamento de usuários com a classe de objeto User é mostrado para AD LDS e a classe de objeto inetOrgPerson para OpenLDAP. Use as seguintes informações para orientações na configuração.

  1. Gere um token secreto que será usado para autenticar o Microsoft Entra ID no conector. Ele deve ter 12 caracteres mínimos e exclusivos para cada aplicativo. Se você ainda não tiver um gerador de segredos, poderá usar um comando do PowerShell, como o seguinte, para gerar um exemplo de cadeia de caracteres aleatória.

    -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})

  2. Se você ainda não fez isso, inicie o Assistente de Configuração do Microsoft ECMA2Host no menu Iniciar.

  3. Selecione Novo Conector. Captura de tela que mostra a escolha de um Novo Conector.

  4. Na página Propriedades, preencha as caixas com os valores especificados na tabela que segue a imagem e selecione Avançar. Captura de tela que mostra a inserção das propriedades.

    Propriedade Valor
    Nome O nome escolhido para o conector, que deve ser exclusivo em todos os conectores em seu ambiente. Por exemplo, LDAP.
    Temporizador de sincronização síncrona (minutos) 120
    Token secreto Insira seu token secreto aqui. Ela deve ter no mínimo 12 caracteres.
    DLL de extensão Para obter um conector LDAP genérico, selecione Microsoft.IAM.Connector.GenericLdap.dll.

  5. Na página Conectividade, você configurará como o Host do Conector ECMA se comunicará com o servidor de diretório e definirá algumas das opções de configuração. Preencha as caixas com os valores especificados na tabela que segue a imagem e selecione Avançar. Aos selecionar Avançar, o conector consultará o servidor de diretório para sua configuração. Captura de tela que mostra a página Conectividade.

    Propriedade Descrição
    Host O nome do host no qual o servidor LDAP está localizado. Esta amostra usa APP3 como o nome do host de exemplo.
    Porta O número da porta TCP. Se o servidor de diretório estiver configurado para LDAP por SSL, use a porta 636. Para Start TLS ou se você estiver usando a segurança em nível de rede, use a porta 389.
    Tempo-limite da conexão 180
    Associação Essa propriedade especifica como o conector será autenticado no servidor de diretório. Com a configuração Basic ou com a configuração SSL ou TLS e nenhum certificado de cliente configurado, o conector enviará uma associação simples LDAP para autenticar com um nome diferenciado e uma senha. Com a configuração SSL ou TLS e um certificado do cliente especificado, o conector enviará uma associação SASL do LDAP EXTERNAL para autenticar com um certificado de cliente.
    Nome do Usuário Como o Conector ECMA se autenticará no servidor de diretório. Neste exemplo, para AD LDS, o nome de usuário de exemplo é CN=svcAccount,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab e, para OpenLDAP, cn=admin,dc=contoso,dc=lab
    Senha A senha do usuário em que o Conector ECMA se autenticará no servidor de diretório.
    Realm/Domínio Essa configuração só será necessária se você tiver selecionado Kerberos como a opção Associação para fornecer o Realm/Domínio do usuário.
    Certificado As configurações nesta seção são usadas apenas se você selecionar SSL ou TLS como a opção Associação.
    Aliases de atributo A caixa de texto aliases de atributo é usada para atributos definidos no esquema com a sintaxe RFC4522. Esses atributos não podem ser detectados durante a detecção de esquema, e o Conector precisa de ajuda com a identificação esses atributos. Por exemplo, se o servidor de diretório não publicar userCertificate;binary e você quiser provisionar esse atributo, a seguinte cadeia de caracteres deverá ser inserida na caixa aliases de atributo para identificar corretamente o atributo userCertificate como um atributo binário: userCertificate;binary. Se não precisar de nenhum atributo especial que não esteja no esquema, você poderá deixar isso em branco.
    Incluir atributos operacionais Marque a caixa de seleção Include operational attributes in schema para incluir também os atributos criados pelo servidor de diretório. Entre esses atributos estão, por exemplo, quando o objeto foi criado e hora da última atualização.
    Incluir atributos extensíveis Marque a caixa de seleção Include extensible attributes in schema se objetos extensíveis (RFC4512/4.3) forem usados no servidor de diretório. Habilitar essa opção permite que todos os atributos sejam usados em todos os objetos. A seleção dessa opção torna o esquema muito grande. Portanto, a menos que o diretório conectado esteja usando esse recurso, a recomendação é manter a opção desmarcada.
    Permitir seleção manual de âncora Deixe essa opção desmarcada.

    Observação

    Se houver problemas ao tentar se conectar e não conseguir prosseguir para a página Global, verifique se a conta de serviço no AD LDS ou outro servidor de diretório estão habilitados.

  6. Na página Global, você configurará o nome diferenciado do log de alterações delta, se necessário, e os recursos LDAP adicionais. A página é preenchida previamente com as informações fornecidas pelo servidor LDAP. Examine os valores mostrados e selecione Avançar.

    Propriedade Descrição
    Mecanismos SASL com suporte A seção superior mostra informações fornecidas pelo próprio servidor, incluindo a lista de mecanismos SASL.
    Detalhes do certificado do servidor Se SSL ou TLS tiver sido especificado, o assistente exibirá o certificado retornado pelo servidor de diretório. Confirme se o emissor, o assunto e a impressão digital são para o servidor de diretório correto.
    Recursos obrigatórios encontrados O Conector também verifica se os controles obrigatórios estão presentes no Roots DSE. Se esses controles não estiverem listados, será apresentado um aviso. Alguns diretórios LDAP não listam todos os recursos no DSE raiz e é possível que o conector funcione sem problemas mesmo que exista um aviso.
    Controles com suporte As caixas de seleção dos controles com suporte controlam o comportamento de determinadas operações
    Importação de delta O DN de log de alterações é o contexto de nomenclatura usado pelo log de alterações delta, por exemplo, cn=changelog. Esse valor deve ser especificado para que seja possível fazer a importação de delta.
    Atributo de código de acesso Se o servidor de diretório der suporte a um atributo de senha ou hash de senha diferente, você poderá especificar o destino para alterações de senha.
    Nomes de partição Na lista de partições adicionais, é possível adicionar outros namespaces não detectados automaticamente. Por exemplo, essa configuração poderá ser usada se vários servidores formarem um cluster lógico para importação simultânea. Assim como o Active Directory pode ter vários domínios em uma floresta, mas todos compartilharem um esquema, o mesmo pode ser simulado inserindo os namespaces adicionais nessa caixa. Cada namespace pode importar de servidores diferentes e ainda ser configurada na página Configurar Partições e Hierarquias.

  7. Na página Partições, mantenha o padrão e selecione Avançar.

  8. Na página Perfil de execução, verifique se a caixa de seleção Exportar e a caixa de seleção Importação completa estão selecionadas. Em seguida, selecione Avançar. Captura de tela que mostra a página Perfis de Execução.

    Propriedade Descrição
    Exportação Perfil de execução que exportará dados para o servidor de diretório LDAP. Esse perfil de execução é necessário.
    Importação completa Perfil de execução que importará todos os dados das fontes LDAP especificadas anteriormente. Esse perfil de execução é necessário.
    Importação delta Perfil de execução que importará apenas as alterações de LDAP desde a última importação completa ou delta. Habilite esse perfil de execução somente se você tiver confirmado que o servidor de diretório atende aos requisitos necessários. Para obter mais informações, confira a referência do Conector LDAP Genérico.

  9. Na página Exportar, deixe os padrões inalterados e clique em Avançar.

  10. Na página Importação completa, deixe os padrões inalterados e clique em Avançar.

  11. Na página DeltaImport, se estiver presente, deixe os padrões inalterados e clique em Avançar.

  12. Na página Tipos de Objeto, marque as caixas e selecione Avançar.

    Propriedade Descrição
    Objeto de destino Esse valor é a classe de objeto estrutural de um usuário no servidor de diretório LDAP. Por exemplo, inetOrgPerson para OpenLDAP ou User para AD LDS. Não especifique uma classe de objeto auxiliar neste campo. Se o servidor de diretório exigir classes de objeto auxiliares, eles serão configurados com os mapeamentos de atributo no portal do Azure.
    Âncora Os valores desse atributo deve ser exclusivo para cada objeto no diretório de destino. O serviço de provisionamento do Microsoft Entra consultará o host do conector ECMA usando esse atributo após o ciclo inicial. Para o AD LDS, use ObjectGUID e para outros servidores de diretório, consulte a tabela a seguir. Observe que o nome diferenciado pode ser selecionado como -dn-. Atributos com vários valores, como o atributo uid no esquema OpenLDAP, não podem ser usados como âncoras.
    Atributo de Consulta Esse atributo deve ser o mesmo que a Âncora, como objectGUID se o AD LDS for o servidor de diretório ou _distinguishedName se OpenLDAP.
    DN O distinguishedName do objeto de destino. Manter -dn-.
    Gerado automaticamente unchecked

    A tabela a seguir lista os servidores LDAP e a âncora usada:

    Diretório Âncora
    Microsoft AD LDS e AD GC objectGUID. É necessário usar a versão do agente 1.1.846.0 ou superior para o ObjectGUID ser usado como âncora.
    Directory Server 389 dn
    Apache Directory dn
    IBM Tivoli DS dn
    Isode Directory dn
    Novell/NetIQ eDirectory GUID
    Open DJ/DS dn
    Open LDAP dn
    Oracle ODSEE dn
    RadiantOne VDS dn
    Sun One Directory Server dn

  13. O host ECMA descobre os atributos compatíveis com o diretório de destino. Você pode escolher quais atributos deseja expor ao Microsoft Entra ID. Em seguida, esses atributos podem ser configurados no portal do Azure para provisionamento. Na página Selecionar Atributos, adicione todos os atributos na lista suspensa, um de cada vez, que são necessários como atributos obrigatórios ou que você deseja provisionar de Microsoft Entra ID. Captura de tela mostrando a página Selecionar Atributos.
    A lista suspensa Atributo mostra os atributos descobertos no diretório de destino que não foram escolhidos no uso anterior da página Selecionar Atributos do assistente de configuração.

    Verifique se a caixa de seleção Treat as single value está desmarcada para o atributo objectClass e, se userPassword estiver sendo definida, não pode ser selecionada ou verificada para o atributo userPassword.

    Se você estiver usando OpenLDAP com o esquema inetOrgPerson, configure a visibilidade para os atributos a seguir.

    Atributo Tratar como valor único
    cn S
    mail S
    objectClass
    sn S
    userPassword Y

    Se você estiver usando OpenLDAP com o esquema POSIX, configure a visibilidade para os atributos a seguir.

    Atributo Tratar como valor único
    _distinguishedName
    -dn-
    export_password
    cn S
    gidNumber
    homeDirectory
    mail S
    objectClass
    sn S
    uid S
    uidNumber
    userPassword S

    Depois que todos os atributos relevantes forem adicionados, selecione Avançar.

  14. Na página Desprovisionamento, você pode especificar se deseja que o Microsoft Entra ID remova os usuários do diretório quando eles saírem do escopo do aplicativo. Nesse caso, em Desabilitar fluxo, selecione Excluir e, em Excluir fluxo, selecione Excluir. Se Set attribute value for escolhido, os selecionados na página anterior não estarão disponíveis para seleção na página Desprovisionamento.

Observação

Se usar Definir valor do atributo, lembre-se de que somente valores boolianos são permitidos.

  1. Selecione Concluir.

Verifique se o serviço ECMA2Host está em execução e pode ler do servidor de diretório

Siga estas etapas para confirmar se o host do conector foi iniciado e leu quaisquer usuários existentes do servidor de diretório para o host do conector.

  1. No servidor que executa o host do conector ECMA do Microsoft Entra, clique em Iniciar.
  2. Selecione executar se necessário e, em seguida, insira services.msc na caixa.
  3. Na lista Serviços, verifique se Microsoft ECMA2Host está presente e em execução. Se ele não estiver em execução, selecione Iniciar. Captura de tela que mostra que o serviço está em execução.
  4. Se você iniciou o serviço recentemente e tem muitos objetos de usuário no servidor de diretório, aguarde vários minutos para que o conector estabeleça uma conexão com o servidor de diretório.
  5. No servidor que executa o host do conector ECMA do Microsoft Entra, inicie o PowerShell.
  6. Altere para a pasta em que o host ECMA foi instalado, como C:\Program Files\Microsoft ECMA2Host.
  7. Altere para o subdiretório Troubleshooting.
  8. Execute o script TestECMA2HostConnection.ps1 nesse diretório, conforme mostrado no exemplo a seguir, e forneça como argumentos o nome do conector e o valor ObjectTypePath de cache. Se o host do conector não estiver escutando na porta TCP 8585, talvez você também precise fornecer o argumento -Port. Quando solicitado, digite o token secreto configurado para esse conector. 
    PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> $cout = .\TestECMA2HostConnection.ps1 -ConnectorName LDAP -ObjectTypePath cache; $cout.length -gt 9
Supply values for the following parameters:
SecretToken: ************
  9. Se o script exibir uma mensagem de erro ou aviso, verifique se o serviço está em execução e o nome do conector e o token secreto correspondem aos valores configurados no assistente de configuração.
  10. Se o script exibir a saída False, o conector não viu nenhuma entrada no servidor de diretório de origem para usuários existentes. Se essa for uma nova instalação do servidor de diretório, esse comportamento deverá ser esperado e você poderá continuar na próxima seção.
  11. No entanto, se o servidor de diretório já contiver um ou mais usuários, mas o script tiver exibido False, esse status indica que o conector não pode ler no servidor de diretório. Se você tentar provisionar, talvez o Microsoft Entra ID não corresponda corretamente os usuários nesse diretório de origem aos usuários no Microsoft Entra ID. Aguarde vários minutos até que o host do conector conclua a leitura de objetos do servidor de diretório existente e execute novamente o script. Se a saída continuar sendo False, verifique a configuração do conector e as permissões no servidor de diretório estão permitindo que o conector leia os usuários existentes.

Testar a conexão do Microsoft Entra ID com o host do conector

  1. Retorne à janela do navegador da Web em que você estava configurando o provisionamento de aplicativos no portal.

    Observação

    Se a janela tiver atingido o tempo limite, você precisará selecionar novamente o agente.

    1. Entre no portal do Azure.
    2. Acesse Aplicativos empresariais e o selecione Aplicativo ECMA local.
    3. Clique em Provisionamento.
    4. Se Introdução for exibido, altere o modo para Automático, na seção Conectividade Local, selecione o agente que você acabou de implantar e selecione Atribuir Agentes e aguarde dez minutos. Caso contrário, acesse Editar Provisionamento.

  2. Na seção Credenciais de administrador, insira a URL a seguir. Substitua a parte connectorName pelo nome do conector especificado host ECMA, como LDAP. Se você tiver fornecido um certificado de sua autoridade de certificação para o host ECMA, substitua localhost pelo nome do host do servidor em que o host ECMA está instalado.

    Propriedade Valor
    URL do Locatário https://localhost:8585/ecma2host_connectorName/scim

  3. Insira o valor do Token Secreto que você definiu quando criou o conector.

    Observação

    Se você acabou de atribuir o agente para o aplicativo, aguarde 10 minutos para que o registro seja concluído. O teste de conectividade não funcionará até a conclusão do registro. Forçar a conclusão do registro do agente reiniciando o agente de provisionamento no servidor pode acelerar o processo de registro. Vá para o servidor, pesquise por serviços na barra de pesquisa do Windows, identifique o serviço Agente de provisionamento do Microsoft Entra Connect, clique com o botão direito do mouse no serviço e reinicie.

  4. Selecione Testar Conexão e aguarde um minuto.

  5. Depois que o teste de conexão for bem-sucedido e indicar que as credenciais fornecidas estão autorizadas para habilitar o provisionamento, selecione Salvar.
    Captura de tela que mostra o teste de um agente.

Estenda o esquema do Microsoft Entra (opcional)

Se o servidor de diretório exigir atributos adicionais que não fazem parte do esquema do Microsoft Entra padrão para os usuários, ao provisionar, você poderá configurar para fornecer valores desses atributos de uma constante, de uma expressão transformada de outros atributos do Microsoft Entra ou estendendo o esquema do Microsoft Entra.

Se o servidor de diretório exigir que os usuários tenham um atributo, como uidNumber para o esquema POSIX do OpenLDAP, e esse atributo ainda não fizer parte do esquema do Microsoft Entra para um usuário e precisar ser exclusivo para cada usuário, você precisará gerar esse atributo de outros atributos do usuário por meio de uma expressão, ou usar o recurso de extensão de diretório para adicionar esse atributo como uma extensão.

Se os usuários forem originados no Active Directory Domain Services e tiverem o atributo nesse diretório, você poderá usar o Microsoft Entra Connect ou a sincronização na nuvem do Microsoft Entra Connect para configurar que o atributo deve ser sincronizado do Active Directory Domain Services para o Microsoft Entra ID. Dessa forma, ele estará disponível para provisionamento para outros sistemas.

Se os usuários se originarem no Microsoft Entra, para cada novo atributo que você precisar armazenar em um usuário, você precisará definir uma extensão de diretório. Em seguida, atualize os usuários do Microsoft Entra que estão planejados para serem provisionados, para dar a cada usuário um valor desses atributos.

Configurar o mapeamento de atributo

Nesta seção, você configurará o mapeamento entre os atributos do usuário Microsoft Entra e os atributos selecionados anteriormente no assistente de configuração do Host do ECMA. Posteriormente, quando o conector criar um objeto em um servidor de diretório, os atributos de um usuário do Microsoft Entra serão enviados por meio do conector para o servidor de diretório para fazer parte desse novo objeto.

  1. No centro de administração do Microsoft Entra, em Aplicativos empresariais, selecione o aplicativo ECMA local e selecione a página Provisionamento.

  2. Selecione Editar provisionamento.

  3. Expanda Mapeamentos e selecione Provisionar usuários do Microsoft Entra. Se essa for a primeira vez que você configurou os mapeamentos de atributo para esse aplicativo, haverá apenas um mapeamento presente, para um espaço reservado.

  4. Para confirmar se o esquema do servidor do diretório está disponível no Microsoft Entra ID, marque a caixa de seleção Mostrar opções avançadas e selecione Editar lista de atributos para ScimOnPremises. Verifique se todos os atributos selecionados no assistente de configuração estão listados. Caso contrário, aguarde vários minutos para que o esquema seja atualizado, selecione Mapeamento de atributos na linha de navegação e, em seguida, selecione Editar lista de atributos para ScimOnPremises novamente para recarregar a página. Depois de ver os atributos listados, cancele essa página para retornar à lista de mapeamentos.

  5. Cada usuário em um diretório deve ter um nome diferenciado exclusivo. Você pode especificar como o conector deve construir um nome diferenciado usando um mapeamento de atributo. Selecione Adicionar Novo Mapeamento. Use os valores no exemplo a seguir para criar o mapeamento, alterando os nomes diferenciados na expressão para corresponder ao da unidade organizacional ou de outro contêiner no diretório de destino.

    • Tipo de mapeamento: expressão
    • Expressão, se estiver provisionando no AD LDS: Join("", "CN=", Word([userPrincipalName], 1, "@"), ",CN=CloudUsers,CN=App,DC=Contoso,DC=lab")
    • Expressão, se estiver provisionando no OpenLDAP: Join("", "CN=", Word([userPrincipalName], 1, "@"), ",DC=Contoso,DC=lab")
    • Atributo de destino: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:-dn-
    • Aplicar este mapeamento: somente durante a criação do objeto

  6. Se o servidor de diretório exigir que vários valores de classe de objeto estrutural ou valores de classe de objeto auxiliares sejam fornecidos no atributo objectClass, adicione um mapeamento a esse atributo. Para este exemplo de provisionamento no AD LDS, o mapeamento do objectClass não é necessário, mas pode ser necessário para outros servidores de diretório ou outros esquemas. Para adicionar um mapeamento para objectClass, selecione Adicionar Novo Mapeamento. Use os valores no exemplo a seguir para criar o mapeamento, alterando os nomes de classe de objeto na expressão para corresponder aos do esquema de diretório de destino.

    • Tipo de mapeamento: expressão
    • Expressão, se estiver provisionando o esquema inetOrgPerson: Split("inetOrgPerson",",")
    • Expressão, se estiver provisionando o esquema POSIX: Split("inetOrgPerson,posixAccount,shadowAccount",",")
    • Atributo de destino: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:objectClass
    • Aplicar este mapeamento: somente durante a criação do objeto

  7. Se você estiver provisionando no AD LDS e houver um mapeamento de userPrincipalName para PLACEHOLDER, clique nesse mapeamento e edite-o. Use os valores abaixo para atualizar o mapeamento.

    • Tipo de mapeamento: direto
    • Atributo de origem: userPrincipalName
    • Atributo de destino: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPrincipalName
    • Precedência de correspondência: 1
    • Aplicar este mapeamento: somente durante a criação do objeto

  8. Se você estiver provisionando no AD LDS, adicione um mapeamento para isSoftDeleted. Selecione Adicionar Novo Mapeamento. Use os valores abaixo para criar o mapeamento.

    • Tipo de mapeamento: direto
    • Atributo de origem: isSoftDeleted
    • Atributo de destino: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:msDS-UserAccountDisabled

  9. Para cada um dos mapeamentos na tabela a seguir para o servidor de diretório, selecione Adicionar Novo Mapeamento e especifique os atributos de origem e destino. Se você estiver provisionando em um diretório existente com usuários existentes, será necessário editar o mapeamento para o atributo que é comum para definir a Correspondência de objetos usando este atributo para aquele atributo. Saiba mais sobre o mapeamento de atributos aqui.

    Para AD LDS:

    Tipo de mapeamento Atributo de origem Atributo de destino
    Direto displayName urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:displayName

    Para OpenLDAP:

    Tipo de mapeamento Atributo de origem Atributo de destino
    Direto displayName urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:cn
    Direto surname urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:sn
    Direto userPrincipalName urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:mail

    Para o OpenLDAP com o esquema POSIX, você também precisará fornecer os atributos gidNumber, homeDirectory, uid e uidNumber. Cada usuário requer um uid exclusivo e um uidNumber exclusivo. Normalmente, o homeDirectory é definido por uma expressão derivada do userID do usuário. Por exemplo, se o uid de um usuário for gerado por uma expressão derivada de seu nome de entidade de usuário, o valor do diretório base desse usuário poderá ser gerado por uma expressão semelhante também derivada do nome principal do usuário. E, dependendo do seu caso de uso, talvez você queira que todos os usuários estejam no mesmo grupo, portanto, atribuiria o gidNumber de uma constante.

    Tipo de mapeamento Atributo de origem Atributo de destino
    Expression ToLower(Word([userPrincipalName], 1, "@"), ) urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uid
    Direto (atributo específico ao seu diretório) urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uidNumber
    Expression Join("/", "/home", ToLower(Word([userPrincipalName], 1, "@"), )) urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:homeDirectory
    Constante 10000 urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:gidNumber

  10. Se estiver provisionando em um diretório diferente do AD LDS, adicione um mapeamento a urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword que define uma senha aleatória inicial para o usuário. Para o AD LDS, não há mapeamento para userPassword.

  11. Selecione Salvar.

Verificar se os usuários a serem provisionados para o aplicativo têm os atributos necessários no Microsoft Entra ID

Se houver pessoas que tenham contas de usuário existentes no diretório LDAP, você precisará garantir que a representação do usuário do Microsoft Entra tenha os atributos necessários para correspondência.

Se você estiver planejando criar novos usuários no diretório LDAP, precisará garantir que as representações do Microsoft Entra desses usuários tenham os atributos de origem exigidos pelo esquema de usuário do diretório de destino.

Você pode usar os cmdlets do PowerShell do Microsoft Graph para automatizar a verificação de usuários para os atributos necessários.

Por exemplo, suponha que o provisionamento exigiu que os usuários tivessem três atributos DisplayName, surname e extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty. Você pode usar o cmdlet Get-MgUser para recuperar cada usuário e verificar se os atributos necessários estão presentes. Observe que o cmdlet Get-MgUser do Graph v1.0 não retorna por padrão nenhum dos atributos de extensão de diretório de um usuário, a menos que os atributos sejam especificados na solicitação como uma das propriedades a serem retornadas.

$userPrincipalNames = (
 "alice@contoso.com",
 "bob@contoso.com",
 "carol@contoso.com" )

$requiredBaseAttributes = ("DisplayName","surname")
$requiredExtensionAttributes = ("extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty")

$select = "id"
foreach ($a in $requiredExtensionAttributes) { $select += ","; $select += $a;}
foreach ($a in $requiredBaseAttributes) { $select += ","; $select += $a;}

foreach ($un in $userPrincipalNames) {
   $nu = Get-MgUser -UserId $un -Property $select -ErrorAction Stop
   foreach ($a in $requiredBaseAttributes) { if ($nu.$a -eq $null) { write-output "$un missing $a"} }
   foreach ($a in $requiredExtensionAttributes) { if ($nu.AdditionalProperties.ContainsKey($a) -eq $false) { write-output "$un missing $a" } }
}

Coletar usuários existentes do diretório LDAP

Muitos diretórios LDAP, como o Active Directory, incluem um comando que dá saída em uma lista de usuários.

  1. Identifique os usuários nesse diretório que estão no escopo de serem usuários do aplicativo. Essa escolha dependerá da configuração do aplicativo. Para alguns aplicativos, qualquer usuário que exista em um diretório LDAP é um usuário válido. Outros aplicativos podem exigir que o usuário tenha um atributo específico ou seja membro de um grupo nesse diretório.

  2. Execute o comando que recupera esse subconjunto de usuários do diretório LDAP. Confirme se a saída inclui os atributos dos usuários que serão usados para correspondência com o Microsoft Entra ID. Exemplos desses atributos são ID do funcionário, nome da conta e endereço de email.

    Por exemplo, esse comando no Windows usando o programa csvde do AD LDS produziria um arquivo CSV no diretório atual com o atributo userPrincipalName de cada pessoa no diretório:

    $out_filename = ".\users.csv"
csvde -f $out_filename -l userPrincipalName,cn -r "(objectclass=person)"

  3. Se necessário, transfira o arquivo CSV que contém a lista de usuários para um sistema que tem os cmdlets do PowerShell do Microsoft Graph instalados.

  4. Agora que você tem uma lista de todos os usuários obtidos do aplicativo, você poderá fazer a correspondência desses usuários do armazenamento de dados do aplicativo com os usuários no Microsoft Entra ID. Antes de prosseguir, examine as informações sobre a correspondência de usuários nos sistemas de origem e de destino.

Recuperar as IDs dos usuários no Microsoft Entra ID

Esta seção mostra como interagir com o Microsoft Entra ID usando cmdlets do PowerShell do Microsoft Graph.

Na primeira vez que sua organização usar esses cmdlets nesse cenário, você precisará ter a função de Administrador global para permitir que o PowerShell do Microsoft Graph seja usado no seu locatário. As interações subsequentes podem usar uma função com privilégios inferiores, como:

  • Administrador de Usuário, caso preveja a criação de usuários.
  • Administrador de aplicativos ou Administrador de governança de identidade, caso esteja apenas gerenciando atribuições de função de aplicativos.

  1. Abra o PowerShell.

  2. Se você ainda não tiver os módulos do PowerShell do Microsoft Graph instalados, instale o módulo Microsoft.Graph.Users e os demais usando este comando:

    Install-Module Microsoft.Graph

    Se você já tiver os módulos instalados, verifique se está usando uma versão recente:

    Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications

  3. Conecte-se ao Microsoft Entra ID:

    $msg = Connect-MgGraph -ContextScope Process -Scopes "User.ReadWrite.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"

  4. Se esta for a primeira vez que você usa este comando, talvez seja necessário dar consentimento para que as ferramentas de linha de comando do Microsoft Graph acessem essas permissões.

  5. Leia a lista de usuários obtida do armazenamento de dados do aplicativo na sessão do PowerShell. Se a lista de usuários estiver em um arquivo CSV, você poderá usar o cmdlet Import-Csv do PowerShell e fornecer o nome do arquivo da seção anterior como argumento.

    Por exemplo, se você tiver um arquivo chamado Users-exported-from-sap.csv que foi obtido do SAP Cloud Identity Services e ele estiver localizado no diretório atual, insira este comando.

    $filename = ".\Users-exported-from-sap.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8

    Nesse outro exemplo: se você estiver usando um banco de dados ou diretório e o arquivo se chamar users.csv e também estiver localizado no diretório atual, insira este comando:

    $filename = ".\users.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8

  6. Escolha a coluna do arquivo users.csv que corresponderá a um atributo de um usuário no Microsoft Entra ID.

    E se você estiver usando o SAP Cloud Identity Services, o mapeamento padrão será o atributo userName do SAP SCIM com o atributo userPrincipalName do Microsoft Entra ID:

    $db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"

    Outro exemplo seria se você estiver usando um banco de dados ou diretório, pode haver usuários em um banco de dados em que o valor na coluna denominada EMail é o mesmo valor do atributo userPrincipalName do Microsoft Entra:

    $db_match_column_name = "EMail"
$azuread_match_attr_name = "userPrincipalName"

  7. Recupere as IDs desses usuários no Microsoft Entra ID.

    O script do PowerShell a seguir usa os valores $dbusers, $db_match_column_name e $azuread_match_attr_name especificados anteriormente. Ele consultará o Microsoft Entra ID para localizar um usuário que tenha um atributo com um valor correspondente para cada registro no arquivo de origem. Se o arquivo obtido do SAP Cloud Identity Services, do banco de dados ou do diretório tiver muitos usuários, prepare-se para aguardar alguns minutos até que o script seja concluído. Se você não tiver um atributo no Microsoft Entra ID que tenha o valor e precisar usar contains ou outra expressão de filtro, será necessário personalizar esse script e o da etapa 11 abaixo para usar uma expressão de filtro diferente.

    $dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

  8. Exiba os resultados das consultas anteriores. Veja se algum do usuário que está no SAP Cloud Identity Services, no banco de dados ou no diretório não pôde ser encontrado no Microsoft Entra ID, devido a erros ou correspondências faltando.

    O seguinte script do PowerShell exibirá as contagens de registros que não foram localizados:

    $dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Error "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

  9. Quando o script for concluído, ele indicará um erro se houver registros da fonte de dados não localizados no Microsoft Entra ID. Se nem todos os registros de usuários do armazenamento de dados do aplicativo puderem ser localizados no Microsoft Entra ID, será necessário investigar os registros que não corresponderam e por quê.

    Por exemplo, o endereço de email e o userPrincipalName de alguém podem ter sido alterados no Microsoft Entra ID sem que a propriedade mail correspondente tenha sido atualizada na fonte de dados do aplicativo. Ou talvez o usuário já tenha deixado a organização, mas ainda continue na fonte de dados do aplicativo. Ou pode haver uma conta de fornecedor ou de superadministrador na fonte de dados do aplicativo que não corresponda a nenhuma pessoa específica no Microsoft Entra ID.

  10. Se houver usuários que não foram localizados no Microsoft Entra ID ou que não estavam ativos e prontos para entrar, mas você quer que eles tenham o acesso revisado ou seus atributos atualizados no SAP Cloud Identity Services, no banco de dados ou no diretório, você precisará atualizar o aplicativo ou a regra de correspondência, ou então atualizar ou criar usuários do Microsoft Entra para eles. Para mais informações sobre quais alterações fazer, confira gerenciar mapeamentos e contas de usuário em aplicativos que encontraram correspondência com os usuários no Microsoft Entra ID.

    Se você optar por criar usuários no Microsoft Entra ID, poderá criar usuários em massa usando:

    Verifique se os novos usuários foram preenchidos com os atributos necessários para que o Microsoft Entra ID combine-os posteriormente com os usuários existentes no aplicativo e com os atributos exigidos pelo Microsoft Entra ID, incluindo userPrincipalName, mailNickname e displayName. O userPrincipalName deve ser único entre todos os usuários no diretório.

    Por exemplo, é possível ter usuários em um banco de dados em que o valor na coluna EMail é o valor que você quer usar como o nome UPN do Microsoft Entra, o valor na coluna Alias contém o apelido de email do Microsoft Entra ID e o valor na coluna Full name contém o nome de exibição do usuário:

    $db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"

    Depois, você pode usar este script para criar usuários do Microsoft Entra para aqueles que estão no SAP Cloud Identity Services, no banco de dados ou no diretório que não correspondem aos usuários no Microsoft Entra ID. Observe que talvez seja necessário modificar esse script para adicionar outros atributos do Microsoft Entra necessários em sua organização ou, se $azuread_match_attr_name não for mailNickname nem userPrincipalName, para fornecer esse atributo do Microsoft Entra.

    $dbu_missing_columns_list = @()
$dbu_creation_failed_list = @()
foreach ($dbu in $dbu_not_matched_list) {
   if (($null -ne $dbu.$db_display_name_column_name -and $dbu.$db_display_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_user_principal_name_column_name -and $dbu.$db_user_principal_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_mail_nickname_column_name -and $dbu.$db_mail_nickname_column_name.Length -gt 0)) {
      $params = @{
         accountEnabled = $false
         displayName = $dbu.$db_display_name_column_name
         mailNickname = $dbu.$db_mail_nickname_column_name
         userPrincipalName = $dbu.$db_user_principal_name_column_name
         passwordProfile = @{
           Password = -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
         }
      }
      try {
        New-MgUser -BodyParameter $params
      } catch { $dbu_creation_failed_list += $dbu; throw }
   } else {
      $dbu_missing_columns_list += $dbu
   }
}

  11. Quando adicionar os usuários ausentes ao Microsoft Entra ID, execute o script da etapa 7 novamente. Em seguida, execute o script da etapa 8. Verifique se não há nenhum erro relatado.

    $dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

$dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Warning "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count -ne 0) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

Atribuir usuários a um aplicativo

Agora que o host do conector ECMA do Microsoft Entra está se comunicando com o Microsoft Entra ID e o mapeamento do atributo foi configurado, é possível passar para a configuração de quem está no escopo do provisionamento.

Importante

Se você se conectou pela função Administrador de Identidade Híbrida, saia do serviço e entre com uma conta que tenha a função de Administrador de Aplicativos, Administrador de Aplicativos de Nuvem ou Administrador Global para esta seção. A função Administrador de Identidade Híbrida não tem permissões para atribuir usuários a aplicativos.

Se houver usuários no diretório LDAP, será necessário criar atribuições de função de aplicativo para esses usuários no Microsoft Entra ID. Para saber mais sobre como criar atribuições de função de aplicativo em massa usando New-MgServicePrincipalAppRoleAssignedTo, consulte como controlar os usuários existentes de um aplicativo no Microsoft Entra ID.

Caso contrário, se o diretório LDAP estiver vazio, selecione um usuário de teste no Microsoft Entra ID que tem os atributos exigidos e será provisionado para o servidor de diretório do aplicativo.

  1. Verifique se o usuário selecionará tem todas as propriedades que serão mapeadas para os atributos necessários do esquema do servidor de diretório.
  2. No portal do Azure, selecione Aplicativos Empresariais.
  3. Selecione o aplicativo ECMA local.
  4. À esquerda, em Gerenciar, selecione Usuários e grupos.
  5. Selecione Adicionar usuário/grupo. Captura de tela que mostra a adição de um usuário.
  6. Em Usuários, selecione Nenhum Selecionado. Captura de tela que mostra Nenhum Selecionado.
  7. Selecione um usuário à direita e escolha o botão Selecionar.
    Captura de tela que mostra a opção Selecionar usuários.
  8. Selecione Atribuir. Captura de tela que mostra Atribuir usuários.

Testar o provisionamento

Agora que seus atributos estão mapeados e o usuário inicial está atribuído, você pode testar o provisionamento sob demanda com um de seus usuários.

  1. No servidor que executa o host do conector ECMA do Microsoft Entra, clique em Iniciar.

  2. Insira run e depois services.msc na caixa.

  3. Na lista Serviços, verifique se o serviço do Agente de Provisionamento do Microsoft Entra Connect e os serviços do Microsoft ECMA2Host estão em execução. Caso não esteja, selecione Iniciar.

  4. No portal do Azure, selecione Aplicativos Empresariais.

  5. Selecione o aplicativo ECMA local.

  6. À esquerda, selecione Provisionamento.

  7. Selecionar Provisionar sob demanda.

  8. Pesquise um de seus usuários de teste e selecione Provisionamento. Captura de tela que mostra o teste de provisionamento sob demanda.

  9. Após vários segundos, a mensagem Êxito ao criar o usuário no sistema de destino será exibida, com uma lista dos atributos do usuário. Caso apareça um erro, confira a solução de problemas de erros de provisionamento.

Iniciar o provisionamento de usuários

Depois que o teste de provisionamento sob demanda for bem-sucedido, adicione os usuários restantes.

  1. No portal do Azure, selecione Testar este aplicativo.
  2. À esquerda, em Gerenciar, selecione Usuários e grupos.
  3. Verifique se todos os usuários estão atribuídos à função de aplicativo.
  4. Altere de volta para a página de configuração de provisionamento.
  5. Verifique se o escopo está definido apenas para usuários e grupos atribuídos, altere o status de provisionamento para Ativado e clique em Salvar.
  6. Aguarde alguns minutos até que o provisionamento comece. Isso poderá levar até 40 minutos. Depois que o provisionamento do trabalho estiver concluído, conforme descrito na próxima seção,

Erros ao solucionar problemas de provisionamento

Se um erro for exibido, selecione Exibir logs de provisionamento. Procure no log uma linha na qual o Status é Falha e clique nessa linha.

Se a mensagem de erro for Falha ao criar o Usuário, verifique os atributos mostrados nos requisitos do esquema de diretório.

Para obter mais informações, mude para a guia Solução de problemas e Recomendações.

Se a mensagem de erro da solução de problemas indicar que um valor de objectClass é invalid per syntax, certifique-se de que o mapeamento de atributo de provisionamento para o atributo objectClass inclua apenas nomes de classes de objeto reconhecidas pelo servidor do diretório.

Para outros erros, confira solução de problemas de provisionamento de aplicativos locais.

Se você quiser pausar o provisionamento para este aplicativo, na página de configuração de provisionamento, poderá alterar a status de provisionamento para Desativado e selecionar Salvar. Isso impedirá a execução do serviço de provisionamento no futuro.

Verifique se os usuários foram provisionados com êxito

Depois de aguardar, verifique o servidor de diretório para garantir que os usuários estejam sendo provisionados. A consulta executada no servidor de diretório dependerá dos comandos que o servidor de diretório fornece.

As instruções a seguir ilustram como verificar o AD LDS.

  1. Abra o Gerenciador do Servidor e selecione o AD LDS à esquerda.
  2. Clique com o botão direito do mouse na instância do AD LDS e selecione ldp.exe do pop-up. Captura de tela do local da ferramenta Ldp.
  3. Na parte superior do ldp.exe, selecione Conexão e Conectar.
  4. Insira as informações a seguir e clique em OK.
    • Servidor: APP3
    • Porta: 636
    • Marque a caixa SSL Captura de tela mostrando a conexão Ldp para verificação de usuários.
  5. Na parte superior, em Conexão, selecione Associar.
  6. Deixe os padrões e clique em OK.
  7. Na parte superior, selecione Exibição e Árvore
  8. Em BaseDN, insira CN=App,DC=contoso,DC=lab e clique em OK.
  9. À esquerda, expanda o DN e clique em CN=CloudUsers,CN=App,DC=contoso,DC=lab. Você deve ver os usuários que foram provisionados do Microsoft Entra ID. Captura de tela mostrando a associação Ldp para usuários.

As instruções a seguir ilustram como verificar o OpenLDAP.

  1. Abra uma janela de terminal com um shell de comando no sistema com OpenLDAP.
  2. Digite o comando ldapsearch -D "cn=admin,dc=contoso,dc=lab" -W -s sub -b dc=contoso,dc=lab -LLL (objectclass=inetOrgPerson)
  3. Verifique se o LDIF resultante inclui os usuários provisionados do Microsoft Entra ID.

Próximas etapas