Partilhar via

Configurando o ID do Microsoft Entra para provisionar usuários em diretórios LDAP

  • Artigo

A documentação a seguir fornece informações de configuração e tutorial demonstrando 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 ID do Microsoft Entra em um diretório LDAP. O documento ilustra como você pode provisionar usuários no AD LDS como um diretório LDAP de exemplo, mas pode provisionar em qualquer um dos servidores de diretório LDAP suportados mencionados nas seções a seguir. Não há suporte para o provisionamento de usuários nos Serviços de Domínio Ative Directory por meio dessa solução.

Para obter detalhes importantes sobre o que esse serviço faz, como funciona e perguntas frequentes, consulte Automatizar o provisionamento e o desprovisionamento de usuários para aplicativos SaaS com o Microsoft Entra ID e a 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 no 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 Ative Directory, no qual os usuários podem ser criados, atualizados e excluídos. Por exemplo, Ative Directory Lightweight Services (AD LDS). Esta instância de diretório não deve ser um diretório que também é usado para provisionar usuários no Microsoft Entra ID, porque 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 com conectividade de saída para login.microsoftonline.com, outros domínios do Microsoft Online Services e do Azure . Um exemplo é uma máquina virtual do Windows Server 2016 hospedada no Azure IaaS ou atrás de um proxy.
  • O .NET Framework 4.7.2 precisa ser instalado.
  • Opcional: embora não seja necessário, recomenda-se baixar o Microsoft Edge para Windows Server e usá-lo no local do Internet Explorer.

Servidores de diretório LDAP suportados

O conector depende de várias técnicas para detetar e identificar o servidor LDAP. O conector usa o DSE raiz, nome/versão do fornecedor e inspeciona o esquema para encontrar objetos e atributos exclusivos conhecidos por existirem em determinados servidores LDAP.

  • OpenLDAP
  • Serviços LDS do Microsoft Ative Directory
  • 389 Servidor de diretório
  • Servidor de diretório Apache
  • IBM Tivoli DS
  • Diretório Isode
  • eDirectory NetIQ
  • Novell eDirectory
  • DJ aberto
  • Abrir DS
  • Oracle (anteriormente Sun ONE) Directory Server Enterprise Edition
  • Servidor de diretório virtual RadiantOne (VDS)

Para obter mais informações, consulte a referência do conector LDAP genérico.

Requisitos da nuvem

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

    O uso desse recurso requer licenças do Microsoft Entra ID P1. Para encontrar a licença certa para os requisitos, consulte Comparar as funcionalidades geralmente disponíveis do Microsoft Entra ID.

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

  • Os usuários do Microsoft Entra a serem provisionados para o diretório LDAP já devem estar 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 esse número a partir 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 gráfica para saber como criar extensões de diretório adicionais.

Mais recomendações e limitações

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

  • Não é recomendável usar o mesmo agente para sincronização na nuvem e provisionamento de aplicativos locais. A Microsoft recomenda o uso de um agente separado para sincronização na nuvem e outro para provisionamento de aplicativos locais.
  • Para o AD LDS atualmente, os usuários não podem ser provisionados com senhas. Assim, terá de desativar a política de palavra-passe para o AD LDS ou provisionar os utilizadores num estado desativado.
  • Para outros servidores de diretório, uma senha aleatória inicial pode ser definida, mas não é possível provisionar a senha de um usuário do Microsoft Entra para um servidor de diretório.
  • Não há suporte para o provisionamento de usuários do Microsoft Entra ID para os Serviços de Domínios do Ative Directory.
  • Não há suporte para o provisionamento de usuários do LDAP para o Microsoft Entra ID.
  • Não há suporte para o provisionamento de grupos e associações de usuários a um servidor de diretório.

Seleção de perfis de execução

Ao criar a configuração para que o conector interaja com um servidor de diretório, você configurará primeiro para que o conector leia 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, por meio 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á discutir com o operador do servidor de diretório em sua organização o padrão de operações que serão executadas com seu servidor de diretório.

  • Após a configuração, quando o serviço de provisionamento for iniciado, ele executará automaticamente as interações configuradas no perfil de execução de Importação Completa . Neste perfil de execução, o conector será lido em todos os registros para 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 esse usuário no diretório, em vez de criar um novo objeto para esse usuário.

  • Sempre que forem feitas alterações no ID do Microsoft Entra, 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 Exportar . 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 o Microsoft Entra ID.

  • Se o diretório oferecer suporte a ele, você também poderá, opcionalmente, configurar um perfil de execução Delta Import . Neste perfil de execução, o ID do Microsoft Entra lerá as alterações feitas no diretório, exceto pelo ID do Microsoft Entra, 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 suportar uma importação delta. Por exemplo, se sua organização estiver usando OpenLDAP, o OpenLDAP deve ter sido implantado com o recurso de sobreposição de log de acesso habilitado.

Determine como o Microsoft Entra LDAP Connector 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 em sua organização como integrar com o 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 autenticar-se no servidor de diretório, qual esquema o servidor de diretório selecionou para modelar usuários, o nome distinto base do contexto de nomenclatura e as regras de hierarquia de diretório, como associar usuários no servidor de diretório com 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 ID do Microsoft Entra. 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 seu fornecedor de servidor de diretório ou com um parceiro de implantação para obter ajuda, orientação 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 no servidor de diretório Página Conectividade do assistente de configuração Para AD LDS e OpenLDAP, CN=svcAccountLDAP,CN=ServiceAccounts,CN=App,DC=contoso,DC=labcn=admin,dc=contoso,dc=lab
Senha para o conector autenticar-se 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 OpenLDAP inetOrgPerson
classes de objeto auxiliares para um usuário no servidor de diretório Mapeamentos de atributos de página de provisionamento do portal do Azure Para OpenLDAP com o esquema POSIX, posixAccount eshadowAccount
atributos a serem preenchidos em um novo usuário Assistente de configuração Página Selecionar atributos e mapeamentos de atributos da página de provisionamento do portal do Azure Para AD LDS msDS-UserAccountDisabled, userPrincipalNamedisplayName , e para OpenLDAP cn, gidNumber, homeDirectory, mail, objectClass, sn, uid, uidNumber, ,userPassword
Hierarquia de nomenclatura exigida pelo servidor de diretório Mapeamentos de atributos de página de provisionamento do portal do Azure Defina o DN de um usuário recém-criado para estar imediatamente abaixo CN=CloudUsers,CN=App,DC=Contoso,DC=lab para AD LDS e DC=Contoso,DC=lab OpenLDAP
atributos para correlacionar usuários no Microsoft Entra ID e no servidor de diretório Mapeamentos de atributos de página de provisionamento do portal do Azure Para AD LDS, não configurado como este exemplo é para um diretório inicialmente vazio, e para OpenLDAP, mail
comportamento de desprovisionamento quando um usuário sai do escopo no Microsoft Entra ID 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 de host e um número de porta TCP, normalmente a porta 389 ou 636. Exceto quando o servidor de diretório está colocalizado com o conector no mesmo Windows Server, ou quando você está usando segurança de nível de rede, as conexões de rede do conector para um servidor de diretório precisam ser protegidas usando SSL ou TLS. O conector suporta a conexão a um servidor de diretório na porta 389 e o uso do Start TLS para habilitar o TLS dentro da sessão. O conector também suporta a conexão a um servidor de diretório na porta 636 para LDAPS - LDAP sobre TLS.

Você precisará ter uma conta identificada para que o conector se autentique no servidor de diretório já configurado no servidor de diretório. Esta conta é normalmente identificada com um nome distinto e tem uma palavra-passe 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 dentro do modelo de controle de acesso do diretório. O conector precisa ter permissões de gravação para poder exportar e permissões de leitura para poder importar. A configuração de permissão é executada dentro das experiências de gerenciamento do próprio diretório de destino.

Um esquema de diretório especifica as classes de objeto e atributos que representam uma entidade do mundo real no diretório. O conector suporta um usuário 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 quaisquer classes de objeto auxiliar. Além disso, você provavelmente também configurará mapeamentos para alguns dos 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 os objetos existentes no diretório. Na maioria das implantações, a organização optou por ter uma hierarquia simples em seu servidor de diretório, na qual cada objeto para cada usuário está localizado imediatamente abaixo de um objeto base comum. Por exemplo, se o nome distinto base para o contexto de nomeação em um servidor de diretório for dc=contoso,dc=com , um novo usuário terá um nome distinto como cn=alice,dc=contoso,dc=com. No entanto, algumas organizações podem ter uma hierarquia de diretórios mais complexa, caso em que você precisará implementar as regras ao especificar o mapeamento de nome distinto 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 distinto como cn=alice,ou=London,dc=contoso,dc=com. Como o conector não cria objetos intermediários para unidades organizacionais, quaisquer objetos intermediários esperados pela hierarquia de regras do servidor de diretório já devem existir no servidor de diretório.

Em seguida, você precisará definir as regras de como o conector deve determinar se já há um usuário no servidor de diretório correspondente a um usuário do Microsoft Entra. Cada diretório LDAP tem um nome distinto que é exclusivo para cada objeto no servidor de diretório, no entanto, esse nome distinto geralmente não está presente para os usuários no ID do Microsoft Entra. Em vez disso, uma organização pode ter um atributo diferente, como mail ou employeeId, em seu esquema de servidor de diretório que também está presente em 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á há um usuário nesse diretório que tenha um valor específico desse atributo e só criar um novo usuário no servidor de diretório se um não estiver presente.

Se o seu cenário envolver a criação de novos usuários no diretório LDAP, não apenas a atualização ou exclusão de 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 SSO, como SAML, OAuth ou OpenID Connect para se autenticarem no Microsoft Entra ID e dependam apenas do servidor de diretório para atributos. Tradicionalmente, os diretórios LDAP podem 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á foi autenticado. Alguns aplicativos podem consultar a chave pública SSH ou o certificado de um usuário a partir do diretório, o que pode ser apropriado dos usuários que já possuem credenciais desses formulários. No entanto, se o seu aplicativo que depende do servidor de diretório não oferecer suporte a protocolos de autenticação modernos ou credenciais mais fortes, você precisará definir uma senha específica do aplicativo ao criar um novo usuário no diretório, já que o Microsoft Entra ID não oferece suporte ao provisionamento da senha do Microsoft Entra de um usuário.

Finalmente, você precisará concordar com o comportamento de desprovisionamento. Quando o conector é configurado e o Microsoft Entra ID estabeleceu um link entre um usuário no Microsoft Entra ID e um usuário no diretório, seja para um usuário já 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 no ID do Microsoft Entra, o ID do Microsoft Entra enviará uma operação de exclusão para o servidor de diretório. Você também pode desejar 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 desejar experimentar esse recurso, Preparar os Serviços LDS do Ative Directory para provisionamento a partir da ID do Microsoft Entra mostra como criar um ambiente AD LDS de teste. 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. Inicie sessão no portal do Azure.
  2. Vá para Aplicativos corporativos 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. No menu, navegue até a página Provisionamento do seu aplicativo.
  5. Selecione Introdução.
  6. Na página Provisionamento, altere o modo para Automático.

Captura de ecrã a mostrar a seleção de Automático.

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

Captura de tela do local de 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 selecione Avançar.
  4. O agente de provisionamento usará o navegador da Web do sistema operacional para exibir uma janela pop-up para você se autenticar na ID do Microsoft Entra 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 sites da Microsoft à lista de sites confiáveis do navegador para permitir que o JavaScript seja executado corretamente.
  5. Forneça credenciais para um administrador do Microsoft Entra quando você for solicitado a autorizar. O usuário deve ter pelo menos a função de Administrador de Identidade Híbrida .
  6. Selecione Confirmar para confirmar a configuração. Quando a instalação for bem-sucedida, você poderá selecionar Sair e também fechar o instalador do Pacote do Agente de Provisionamento.

Configurar o aplicativo ECMA local

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

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

  2. Mantenha esta janela do navegador aberta enquanto conclui a próxima etapa de configuração usando o assistente de configuração.

Configurar o certificado Microsoft Entra ECMA Connector Host

  1. No Windows Server onde 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 do Host do Conector ECMA for iniciada, se esta 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 confiável. A SAN corresponde ao nome do host. Captura de ecrã que mostra a definição das suas definições.
  3. Selecione Guardar.

Nota

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

Configurar um conector LDAP genérico

Dependendo das opções selecionadas, algumas das telas do assistente podem não estar disponíveis e as informações podem ser ligeiramente diferentes. Para 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 informações a seguir para guiá-lo em sua configuração.

  1. Gere um token secreto que será usado para autenticar o ID do Microsoft Entra no conector. Deve ter um mínimo de 12 caracteres e ser único para cada aplicação. 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 ainda não tiver feito 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 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 ecrã que mostra a introdução de propriedades.

    Property 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 automática (minutos) 120
    Token secreto Introduza o seu token secreto aqui. Deve ter no mínimo 12 caracteres.
    Extensão DLL Para o conector LDAP genérico, selecione Microsoft.IAM.Connector.GenericLdap.dll.

  5. Na página Conectividade, você configurará como o ECMA Connector Host 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 se segue à imagem e selecione Avançar. Quando você seleciona Avançar, o conector consultará o servidor de diretório para sua configuração. Captura de ecrã que mostra a página Conectividade.

    Property Descrição
    Host O nome do host onde o servidor LDAP está localizado. Este exemplo usa APP3 como nome de host de exemplo.
    Porta O número da porta TCP. Se o servidor de diretório estiver configurado para LDAP sobre SSL, use a porta 636. Para Start TLS, ou se estiver a utilizar segurança ao nível da rede, utilize a porta 389.
    Limite de Tempo da Ligação 180
    Enlace Esta propriedade especifica como o conector será autenticado no servidor de diretório. Com a Basic configuração, ou com a SSL configuração ou TLS e nenhum certificado de cliente configurado, o conector enviará uma associação simples LDAP para autenticar com um nome distinto e uma senha. Com a SSL configuração ou TLS e um certificado de cliente especificado, o conector enviará uma associação SASL EXTERNAL LDAP para autenticar com um certificado de cliente.
    Nome de Utilizador Como o ECMA Connector 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
    Palavra-passe A senha do usuário que o ECMA Connector irá autenticar-se no servidor de diretório.
    Reino/Domínio Essa configuração só será necessária se você tiver selecionado Kerberos como a opção Vinculação, para fornecer o Realm/Domain do usuário.
    Certificado As configurações nesta seção só são usadas se você selecionou SSL ou TLS como a opção Vinculação.
    Aliases de atributo A caixa de texto aliases de atributo é usada para atributos definidos no esquema com sintaxe RFC4522. Esses atributos não podem ser detetados durante a deteção de esquema e o conector precisa de ajuda para identificar esses atributos. Por exemplo, se o servidor de diretório não publicar userCertificate;binary e você desejar 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 você não precisar de nenhum atributo especial que não esteja no esquema, poderá deixar isso em branco.
    Incluir atributos operacionais Marque a Include operational attributes in schema caixa de seleção para incluir também atributos criados pelo servidor de diretório. Isso inclui atributos como quando o objeto foi criado e a hora da última atualização.
    Incluir atributos extensíveis Marque a caixa de Include extensible attributes in schema seleção 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. Selecionar essa 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 a seleção manual de âncoras deixe esta opção desselecionada.

    Nota

    Se tiver um problema ao tentar estabelecer ligação e não conseguir prosseguir para a página Global , certifique-se de que a conta de serviço no AD LDS ou no outro servidor de diretório está ativada.

  6. Na página Global, você configurará o nome distinto do log de alterações delta, se necessário, e recursos LDAP adicionais. A página é pré-preenchida com as informações fornecidas pelo servidor LDAP. Reveja os valores apresentados e, em seguida, selecione Seguinte.

    Property Description
    Mecanismos SASL suportados 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 foi 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 DSE raiz. Se esses controles não estiverem listados, um aviso será exibido. Alguns diretórios LDAP não listam todos os recursos no DSE raiz e é possível que o conector funcione sem problemas, mesmo que um aviso esteja presente.
    Controles suportados As caixas de seleção de controles suportados controlam o comportamento de determinadas operações
    Importação Delta O DN do 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 poder fazer a importação delta.
    Atributo de senha Se o servidor de diretório oferecer suporte a um atributo de senha diferente ou hash de senha, você poderá especificar o destino para alterações de senha.
    Nomes de partições Na lista de partições adicionais, é possível adicionar namespaces adicionais não detetados automaticamente. Por exemplo, essa configuração pode ser usada se vários servidores comporem um cluster lógico, que deve ser importado ao mesmo tempo. Assim como o Ative Directory pode ter vários domínios em uma floresta, mas todos os domínios compartilham um esquema, o mesmo pode ser simulado inserindo os namespaces adicionais nesta caixa. Cada namespace pode importar de servidores diferentes e é configurado 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 Executar Perfis, verifique se a caixa de seleção Exportar e a caixa de seleção Importação completa estão marcadas. Em seguida, selecione Seguinte. Captura de ecrã que mostra a página Executar Perfis.

    Property Description
    Exportar Execute o perfil que exportará dados para o servidor de diretório LDAP. Este perfil de execução é necessário.
    Importação total Execute o perfil que importará todos os dados de fontes LDAP especificadas anteriormente. Este perfil de execução é necessário.
    Importação Delta Execute o perfil que importará apenas as alterações do 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, consulte 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 houver, deixe os padrões inalterados e clique em Avançar.

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

    Property Description
    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, elas serão configuradas com os mapeamentos de atributos no portal do Azure.
    Âncora Os valores desse atributo devem ser exclusivos 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 AD LDS, use ObjectGUID, e para outros servidores de diretório, consulte a tabela a seguir. Observe que o nome distinto pode ser selecionado como -dn-. Atributos de vários valores, como o uid atributo 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 o OpenLDAP.
    DN O distinguishedName do objeto de destino. Manter -dn-.
    Gerado automaticamente não verificado

    A tabela a seguir lista os servidores LDAP e a âncora que está sendo usada:

    Diretório Âncora
    Microsoft AD LDS e AD GC objectGUID. Você deve estar usando a versão do agente 1.1.846.0 ou superior para ObjectGUID ser usado como âncora.
    389 Servidor de diretório DN
    Diretório Apache DN
    IBM Tivoli DS DN
    Diretório Isode DN
    Novell/NetIQ eDirectory GUID
    Abra o DJ/DS DN
    Abrir LDAP DN
    Oracle ODSEE DN
    RadiantOne VDS DN
    Servidor de diretório Sun One DN

  13. O host ECMA descobre os atributos suportados pelo diretório de destino. Você pode escolher quais desses atributos deseja expor ao ID do Microsoft Entra. 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 a partir do Microsoft Entra ID. Captura de tela que mostra a página Selecionar Atributos.
    A lista suspensa Atributo mostra qualquer atributo que foi descoberto no diretório de destino e não foi escolhido no uso anterior da página Selecionar Atributos do assistente de configuração.

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

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

    Atributo Tratar como valor único
    CN Y
    correio Y
    objectClass
    sn Y
    userPassword Y

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

    Atributo Tratar como valor único
    _distinguishedName
    -DN-
    export_password
    CN Y
    gidNumber
    homeDirectório
    correio Y
    objectClass
    sn Y
    uid Y
    uidNumber
    userPassword Y

    Depois que todos os atributos relevantes tiverem sido 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. Em caso afirmativo, em Desativar fluxo, selecione Excluir e, em Excluir fluxo, selecione Excluir. Se Set attribute value for escolhido, os atributos selecionados na página anterior não estarão disponíveis para seleção na página Desprovisionamento.

Nota

Se você usar o valor do atributo set, lembre-se de que somente valores booleanos são permitidos.

  1. Selecione Concluir.

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

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

  1. No servidor que executa o Microsoft Entra ECMA Connector Host, selecione Iniciar.
  2. Selecione Executar , se necessário, e digite services.msc na caixa.
  3. Na lista Serviços, verifique se o Microsoft ECMA2Host está presente e em execução. Se 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 recentemente o serviço e tem muitos objetos de usuário no servidor de diretório, aguarde alguns minutos para que o conector estabeleça uma conexão com o servidor de diretório.
  5. No servidor que executa o Microsoft Entra ECMA Connector Host, inicie o PowerShell.
  6. Mude para a pasta onde o host ECMA foi instalado, como C:\Program Files\Microsoft ECMA2Host.
  7. Mude 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 ObjectTypePath valor cache. Se o host do conector não estiver escutando na porta TCP 8585, talvez você também precise fornecer o -Port argumento. 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 se 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 esta for uma nova instalação do servidor de diretório, esse comportamento é esperado e você pode continuar na próxima seção.
  11. No entanto, se o servidor de diretório já contém um ou mais usuários, mas o script exibido False, esse status indica que o conector não pôde ler do servidor de diretório. Se você tentar provisionar, o Microsoft Entra ID pode não corresponder corretamente os usuários nesse diretório de origem com os usuários no Microsoft Entra ID. Aguarde alguns minutos para que o host do conector termine de ler objetos do servidor de diretório existente e execute novamente o script. Se a saída continuar a ser False, verifique a configuração do seu 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 ID do Microsoft Entra com o host do conector

  1. Retorne à janela do navegador da Web onde você estava configurando o provisionamento do aplicativo no portal.

    Nota

    Se a janela tiver expirado, você precisará selecionar novamente o agente.

    1. Inicie sessão no portal do Azure.
    2. Vá para Aplicativos corporativos e o 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 Agente(s) e aguarde 10 minutos. Caso contrário, vá para Editar provisionamento.

  2. Na secção Credenciais de administrador, introduza o seguinte URL. Substitua a connectorName parte pelo nome do conector no host ECMA, como LDAP. Se você forneceu um certificado de sua autoridade de certificação para o host ECMA, substitua localhost pelo nome do host do servidor onde o host ECMA está instalado.

    Property valor
    URL do locatário https://localhost:8585/ecma2host_connectorName/scim

  3. Insira o valor de Token secreto que você definiu quando criou o conector.

    Nota

    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é que o registro seja concluído. 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, procure serviços na barra de pesquisa do Windows, identifique o serviço Microsoft Entra Connect Provisioning Agent , 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 a habilitar o provisionamento, selecione Salvar.
    Captura de tela que mostra o teste de um agente.

Estender o esquema do Microsoft Entra (opcional)

Se o servidor de diretório exigir atributos adicionais que não fazem parte do esquema padrão do Microsoft Entra para os usuários, então, ao provisionar, você poderá configurar para fornecer valores desses atributos a partir 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 OpenLDAP POSIX, e esse atributo ainda não fizer parte do seu esquema do Microsoft Entra para um usuário e deve ser exclusivo para cada usuário, então você precisará gerar esse atributo a partir 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 originários dos Serviços de Domínio Ative Directory e tiverem o atributo nesse diretório, você poderá usar a sincronização na nuvem do Microsoft Entra Connect ou do Microsoft Entra Connect para configurar que o atributo deve ser sincronizado dos Serviços de Domínio Ative Directory para o ID do Microsoft Entra, para que esteja disponível para provisionamento em outros sistemas.

Se os usuários forem originários do Microsoft Entra ID, 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 mapeamento de atributos

Nesta seção, você configurará o mapeamento entre os atributos do usuário do Microsoft Entra e os atributos selecionados anteriormente no assistente de configuração do Host ECMA. Mais tarde, quando o conector criar um objeto em um servidor de diretório, os atributos de um usuário do Microsoft Entra serão enviados através 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 corporativos, 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 esta for a primeira vez que você configurou os mapeamentos de atributos para este aplicativo, haverá apenas um mapeamento presente, para um espaço reservado.

  4. Para confirmar se o esquema do servidor de 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. Certifique-se de que todos os atributos selecionados no assistente de configuração estejam listados. Caso contrário, aguarde alguns minutos até 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 esta página para retornar à lista de mapeamentos.

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

    • Tipo de mapeamento: expressão
    • Expressão, se provisionamento no AD LDS: Join("", "CN=", Word([userPrincipalName], 1, "@"), ",CN=CloudUsers,CN=App,DC=Contoso,DC=lab")
    • Expressão, se provisionamento em 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 auxiliar, sejam fornecidos no objectClass atributo, adicione um mapeamento a esse atributo. Para este exemplo de provisionamento no AD LDS, o objectClass mapeamento do não é necessário, mas pode ser necessário para outros servidores de diretório ou outros esquemas. Para adicionar um mapeamento para objectClasso , 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 provisionar o esquema inetOrgPerson: Split("inetOrgPerson",",")
    • Expressão, se provisionar 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 correspondente: 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 seu 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, precisará editar o mapeamento para o atributo que está em comum para definir os objetos Match usando esse atributo para esse atributo. Saiba mais sobre o mapeamento de atributos aqui.

    Para o AD LDS:

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

    Para OpenLDAP:

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

    Para OpenLDAP com o esquema POSIX, você também precisará fornecer os gidNumberatributos , homeDirectoryuid e uidNumber . Cada usuário requer um único uid e um único uidNumber. Normalmente, o homeDirectory é definido por uma expressão derivada do ID de usuário do usuário. Por exemplo, se o uid de um usuário é gerado por uma expressão derivada de seu nome principal de usuário, então o valor para o diretório base desse usuário pode ser gerado por uma expressão semelhante também derivada de seu nome principal de usuário. E dependendo do seu caso de uso, você pode desejar que todos os usuários estejam no mesmo grupo, então atribuiria o gidNumber de uma constante.

    Tipo de mapeamento Atributo Source Atributo de destino
    Expression ToLower(Word([userPrincipalName], 1, "@"), ) urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uid
    Direct (atributo específico para o 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 que urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword defina uma senha aleatória inicial para o usuário. Para o AD LDS, não há mapeamento para userPassword.

  11. Selecione Guardar.

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

Se houver pessoas que tenham contas de usuário existentes no diretório LDAP, você precisará garantir que a representação de usuário do Microsoft Entra tenha os atributos necessários para a 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 Microsoft Graph PowerShell para automatizar a verificação dos usuários quanto aos atributos necessários.

Por exemplo, suponha que o provisionamento exigisse que os usuários tivessem três atributos DisplayNameesurname extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty. Você pode usar o Get-MgUser cmdlet para recuperar cada usuário e verificar se os atributos necessários estão presentes. Observe que o cmdlet Graph v1.0 Get-MgUser 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 Ative Directory, incluem um comando que gera uma lista de usuários.

  1. Identifique quais dos usuários nesse diretório estão no escopo de serem usuários do aplicativo. Essa escolha dependerá da configuração do seu 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. Certifique-se de que 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 e-mail.

    Por exemplo, este comando no Windows usando o programa AD LDS csvde produziria um arquivo CSV no diretório atual do sistema de arquivos com o userPrincipalName atributo 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 com os cmdlets do Microsoft Graph PowerShell instalados.

  4. Agora que você tem uma lista de todos os usuários obtidos do aplicativo, você fará a correspondência entre esses usuários do armazenamento de dados do aplicativo e os usuários no Microsoft Entra ID. Antes de continuar, revise 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 Microsoft Graph PowerShell .

Na primeira vez que sua organização usar esses cmdlets para esse cenário, você precisará estar em uma função de Administrador Global para permitir que o Microsoft Graph PowerShell seja usado em seu locatário. As interações subsequentes podem usar um papel menos privilegiado, como:

  • Administrador de usuários, se você prevê a criação de novos usuários.
  • Administrador de aplicativos ou administrador de governança de identidade, se você estiver apenas gerenciando atribuições de função de aplicativo.

  1. Abra o PowerShell.

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

    Install-Module Microsoft.Graph

    Se já tiver os módulos instalados, certifique-se de que está a utilizar 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 esse comando, talvez seja necessário consentir para permitir que as ferramentas de linha de comando do Microsoft Graph tenham 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 o arquivo obtido do SAP Cloud Identity Services tiver o nome Users-exported-from-sap.csv e estiver localizado no diretório atual, digite este comando.

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

    Para outro exemplo, se você estiver usando um banco de dados ou diretório, se o arquivo tiver o nome users.csv e estiver localizado no diretório atual, digite 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.

    Se você estiver usando o SAP Cloud Identity Services, o mapeamento padrão é o atributo userName SAP SCIM com o atributo userPrincipalNameID do Microsoft Entra:

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

    Para outro exemplo, se você estiver usando um banco de dados ou diretório, você pode ter usuários em um banco de dados onde o valor na coluna nomeada EMail é o mesmo valor que no atributo userPrincipalNameMicrosoft Entra :

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

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

    O script PowerShell a seguir usa os $dbusersvalores , $db_match_column_namee $azuread_match_attr_name especificados anteriormente. Ele consultará o ID do Microsoft Entra para localizar um usuário que tenha um atributo com um valor correspondente para cada registro no arquivo de origem. Se houver muitos usuários no arquivo obtido do banco de dados ou diretório de origem do SAP Cloud Identity Services, esse script pode levar vários minutos para ser concluído. Se você não tiver um atributo no Microsoft Entra ID que tenha o valor e precisar usar uma contains ou outra expressão de filtro, será necessário personalizar esse script e isso na 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. Veja os resultados das consultas anteriores. Veja se algum dos usuários no SAP Cloud Identity Services, o banco de dados ou o diretório não pôde ser localizado no ID do Microsoft Entra devido a erros ou correspondências ausentes.

    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 terminar, ele indicará um erro se algum registro da fonte de dados não estiver localizado no ID do Microsoft Entra. Se nem todos os registros de usuários do armazenamento de dados do aplicativo puderem ser localizados como usuários no Microsoft Entra ID, você precisará investigar quais registros não corresponderam e por quê.

    Por exemplo, o endereço de email de alguém e userPrincipalName podem ter sido alterados no ID do Microsoft Entra sem que sua propriedade correspondente mail tenha sido atualizada na fonte de dados do aplicativo. Ou, o usuário pode já ter saído da organização, mas ainda está na fonte de dados do aplicativo. Ou pode haver uma conta de fornecedor ou 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 puderam ser localizados no Microsoft Entra ID ou não estavam ativos e capazes de entrar, mas você deseja que seu acesso seja revisado ou seus atributos atualizados no SAP Cloud Identity Services, no banco de dados ou no diretório, será necessário atualizar o aplicativo, a regra de correspondência ou atualizar ou criar usuários do Microsoft Entra para eles. Para obter mais informações sobre qual alteração fazer, consulte Gerenciar mapeamentos e contas de usuário em aplicativos que não correspondem aos usuários no Microsoft Entra ID.

    Se você escolher a opção de criar usuários no Microsoft Entra ID, poderá criar usuários em massa usando:

    Certifique-se de que esses novos usuários sejam preenchidos com os atributos necessários para que a ID do Microsoft Entra os corresponda posteriormente aos usuários existentes no aplicativo e os atributos exigidos pela ID do Microsoft Entra, incluindo userPrincipalName, mailNickname e displayName. O userPrincipalName deve ser único entre todos os usuários no diretório.

    Por exemplo, você pode ter usuários em um banco de dados onde o valor na coluna nomeada EMail é o valor que você deseja usar como o Nome principal do usuário do Microsoft Entra, o valor na coluna Alias contém o apelido de email do ID do Microsoft Entra e o valor na coluna Full name contém o nome para 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"

    Em seguida, você pode usar esse script para criar usuários do Microsoft Entra para aqueles no SAP Cloud Identity Services, o banco de dados ou o diretório que não corresponderam aos usuários no Microsoft Entra ID. Observe que talvez seja necessário modificar esse script para adicionar atributos adicionais do Microsoft Entra necessários em sua organização, ou se o $azuread_match_attr_name não for nem mailNickname 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. Depois de adicionar quaisquer usuários ausentes ao Microsoft Entra ID, execute o script da etapa 7 novamente. Em seguida, execute o script a partir da etapa 8. Verifique se 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 utilizadores a uma aplicação

Agora que você tem o Microsoft Entra ECMA Connector Host conversando com o Microsoft Entra ID e o mapeamento de atributos configurado, você pode passar para configurar quem está no escopo para provisionamento.

Importante

Se você entrou usando uma função de Administrador de Identidade Híbrida, precisará sair e entrar com uma conta que tenha pelo menos a função de Administrador de Aplicativos 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 existentes no diretório LDAP, você deverá criar atribuições de função de aplicativo para esses usuários existentes no ID do Microsoft Entra. Para saber mais sobre como criar atribuições de função de aplicativo em massa usando New-MgServicePrincipalAppRoleAssignedToo , consulte Governando 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 do Microsoft Entra ID que tenha os atributos necessários e seja provisionado para o servidor de diretório do aplicativo.

  1. Certifique-se de que o usuário selecionará 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 corporativos.
  3. Selecione o aplicativo ECMA local.
  4. À esquerda, em Gerir, selecione Utilizadores e grupos.
  5. Selecione Adicionar usuário/grupo. Captura de ecrã que mostra a adição de um utilizador.
  6. Em Usuários, selecione Nenhum selecionado. Captura de tela que mostra Nenhum selecionado.
  7. Selecione um usuário à direita e selecione o botão Selecionar .
    Captura de tela que mostra Selecionar usuários.
  8. Agora selecione Atribuir. Captura de ecrã que mostra Atribuir utilizadores.

Provisionamento de teste

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

  1. No servidor que executa o Microsoft Entra ECMA Connector Host, selecione Iniciar.

  2. Digite executar e digite services.msc na caixa.

  3. Na lista Serviços, verifique se o serviço Microsoft Entra Connect Provisioning Agent e os serviços Microsoft ECMA2Host estão em execução. Caso contrário, selecione Iniciar.

  4. No portal do Azure, selecione Aplicativos corporativos.

  5. Selecione o aplicativo ECMA local.

  6. À esquerda, selecione Provisionamento.

  7. Selecione Provisão sob demanda.

  8. Procure um dos seus usuários de teste e selecione Provisionar. Captura de tela que mostra o teste de provisionamento sob demanda.

  9. Após alguns segundos, aparecerá a mensagem Usuário criado com êxito no sistema de destino, com uma lista dos atributos do usuário. Se, em vez disso, aparecer um erro, consulte Solução de problemas de erros de provisionamento.

Comece a provisionar usuários

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

  1. No portal do Azure, selecione o aplicativo.
  2. À esquerda, em Gerir, selecione Utilizadores e grupos.
  3. Certifique-se de que todos os usuários estejam atribuídos à função do aplicativo.
  4. Volte para a página de configuração de provisionamento.
  5. Verifique se o escopo está definido como somente usuários e grupos atribuídos, ative o status de provisionamento e selecione Salvar.
  6. Aguarde alguns minutos para que o provisionamento seja iniciado. Pode demorar até 40 minutos. Após a conclusão do trabalho de provisionamento, conforme descrito na próxima seção,

Solução de problemas de erros de provisionamento

Se um erro for mostrado, 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 usuário, verifique os atributos mostrados em relação aos requisitos do esquema de diretório.

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

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

Para outros erros, consulte Solução de problemas de provisionamento de aplicativos locais.

Se desejar pausar o provisionamento para este aplicativo, na página de configuração de provisionamento, você pode alterar o status de provisionamento para Desativado e selecionar Salvar. Essa ação impede que o serviço de provisionamento seja executado 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 que você executar ao servidor de diretório dependerá dos comandos fornecidos pelo servidor de diretório.

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

  1. Abra o Gerenciador do Servidor e selecione AD LDS à esquerda.
  2. Clique com o botão direito do rato na sua instância do AD LDS e selecione ldp.exe no pop-up. Captura de ecrã da localização da ferramenta LDP.
  3. Na parte superior da ldp.exe, selecione Conexão e Conexão.
  4. Insira as seguintes informações e clique em OK.
    • Servidor: APP3
    • Porta: 636
    • Marque a caixa SSL Captura de tela mostrando a conexão Ldp para verificar usuários.
  5. Na parte superior, em Conexão, selecione Vincular.
  6. Deixe os padrões e clique em OK.
  7. Na parte superior, selecione Exibir e Árvore
  8. Para o BaseDN, digite 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 seus usuários que foram provisionados a partir do Microsoft Entra ID. Captura de tela mostrando a vinculaçã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 a partir da ID do Microsoft Entra.

Próximos passos