Configurando a ID do Microsoft Entra para provisionar usuários em um diretório LDAP para autenticação do Linux

Artigo
01/30/2025

A documentação a seguir é um tutorial que demonstra como controlar o acesso a um sistema Linux. O Microsoft Entra provisiona os usuários em um diretório LDAP local que é confiável para aquele sistema Linux. Isso permite que os usuários façam logon em um sistema Linux que depende desse diretório LDAP para autenticação de usuário. Quando um usuário é removido da ID do Microsoft Entra, ele não é mais capaz de fazer logon em um sistema Linux.

Nota

O cenário descrito neste artigo só é aplicável a sistemas Linux existentes que já dependem de um módulo LDAP do NSS (Name Services Switch) ou módulo LDAP do PAM (Pluggable Authentication Modules) para identificação e autenticação do usuário. VMs Linux no Azure, ou que são habilitadas para o Azure Arc, devem ser integradas à autenticação do Microsoft Entra. Agora você pode usar a ID do Microsoft Entra como uma plataforma de autenticação principal e uma autoridade de certificação para acessar por SSH uma VM Linux usando a ID do Microsoft Entra e a autenticação baseada em certificado OpenSSH, conforme descrito em Faça logon em uma máquina virtual Linux no Azure usando a ID do Microsoft Entra e o OpenSSH.

Para outros cenários envolvendo o provisionamento de usuários em diretórios LDAP, exceto para autenticação do Linux, consulte configurando a ID do Microsoft Entra para provisionar usuários em diretórios LDAP.

Pré-requisitos para provisionar usuários em um diretório LDAP para autenticação do Linux

Este artigo pressupõe que o servidor LDAP já está presente no ambiente local, usado por um ou mais sistemas Linux ou outros POSIX para autenticação de usuário.

Diagrama que mostra a arquitetura do provisionamento local do Microsoft Entra ID em um servidor de diretório LDAP.

Pré-requisitos locais

Um servidor Linux ou outro servidor POSIX que responde em um servidor de diretório usando um módulo PAM ou NSS.
Um servidor de diretório LDAP que dá suporte ao esquema POSIX, como OpenLDAP, no qual os usuários podem ser criados, atualizados e excluídos. Para saber mais sobre os servidores de diretório com suporte, consulte a Referência do conector LDAP genérico.
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. Ele também deve ter conectividade com o servidor de diretório de destino e conectividade de saída com login.microsoftonline.com, outros Microsoft Online Services e domínios do Azure. Um exemplo é uma máquina virtual do Windows Server 2016 hospedada no IaaS do Azure ou por trás de um proxy. O .NET Framework 4.7.2 precisa ser instalado nesse servidor.
Opcional: embora não seja necessário, é recomendável baixar Microsoft Edge para Windows Server e usá-lo no local do Internet Explorer.

Requisitos de nuvem

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

Usar esse recurso requer licenças do Microsoft Entra ID P1. Para encontrar a licença certa para seus requisitos, consulte Comparar recursos do Microsoft Entra ID em disponibilidade geral.
A função de administrador de identidade híbrida para a configuração do agente de provisionamento.
As funções Administrador de Aplicativos ou Administrador de Aplicativos de Nuvem para configurar o provisionamento no portal do Azure ou no centro de administração do Microsoft Entra.
O esquema do servidor de diretório requer atributos específicos para que cada usuário do Microsoft Entra seja provisionado no diretório LDAP e esses atributos já devem ser preenchidos. Em particular, cada usuário precisa ter um número exclusivo como seu número de ID de usuário. Antes de implantar o agente de provisionamento e atribuir usuários ao diretório, você precisa gerar esse número de um atributo existente no usuário ou estender o esquema do Microsoft Entra. Em seguida, você pode popular esse atributo para os usuários dentro do escopo. Consulte Extensibilidade do Graph para saber como criar extensões de diretório adicionais.

Mais recomendações e limitações

Os marcadores a seguir trazem 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 o uso de um agente separado para sincronização de nuvem e um para provisionamento de aplicativo local.
No momento, para o AD LDS, os usuários não podem ser provisionados com senhas. Portanto, você precisa 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 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 LDAP para o Microsoft Entra ID.
Não há suporte para o provisionamento de grupos e associações de usuário a um servidor de diretório.

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

Antes de implantar o conector em um servidor de diretório existente, você precisa discutir com o operador do servidor de diretório na organização como se integrar ao servidor dele. As informações a serem coletadas 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.
As regras de hierarquia de diretório e nome diferenciado de base do contexto de nomenclatura.
Como associar usuários no servidor de diretório a usuários na ID do Microsoft Entra.
O que deve acontecer quando um usuário deixa de estar no escopo do 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 na ID do Microsoft Entra. Para implantações que envolvem a integração da ID do Microsoft Entra 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 OpenLDAP.

Definição da 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 via 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	`cn=admin,dc=contoso,dc=lab`
senha para o conector se autenticar 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	`inetOrgPerson`
classes de objeto auxiliares para um usuário no servidor de diretório	Mapeamentos de atributo da página Provisionamento no portal do Azure	`posixAccount` e`shadowAccount`
atributos a serem preenchidos em um novo usuário	Página Selecionar Atributos do Assistente de Configuração e mapeamentos de atributo da página Provisionamento do portal do Azure	`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 para estar imediatamente abaixo `DC=Contoso,DC=lab`
atributos para correlacionar usuários entre a ID do Microsoft Entra e o servidor de diretório	Mapeamentos de atributo da página Provisionamento no portal do Azure	`mail`
comportamento de desprovisionamento quando um usuário sai do escopo no Microsoft Entra	Página 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 porta 389 ou 636. Exceto quando o servidor de diretório está co-localizado com o conector no mesmo Windows Server ou você está usando a segurança em 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 oferece suporte para conectar-se a um servidor de diretório na porta 389 e usar o Start TLS para habilitar o TLS dentro da sessão. O conector também dá suporte à conexão a um servidor de diretório na porta 636 para LDAPS – LDAP via TLS.

Você precisa ter uma conta identificada para o conector se autenticar no servidor de diretório já configurada nesse servidor. Essa conta normalmente é 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 escrita 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 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 inetOrgPersone, 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ê define 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.

Você provavelmente também configurará mapeamentos para alguns dos atributos opcionais dessas classes. Um servidor de diretório OpenLDAP com o esquema POSIX para dar suporte à autenticação do Linux 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 em seu servidor de diretório, na qual cada objeto para um usuário está localizado imediatamente abaixo 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á há um usuário no servidor de diretório correspondente a um usuário do Microsoft Entra. Cada diretório LDAP tem um nome diferenciado que é exclusivo para cada objeto no servidor de diretório, no entanto, esse nome diferenciado geralmente não está presente para os usuários na 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 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, não apenas atualizar ou excluir usuários existentes, você também precisará determinar como os sistemas Linux que usam esse servidor de diretório lidam com a autenticação. Alguns sistemas podem consultar a chave pública ou o certificado SSH de um usuário 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 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, pois a ID do Microsoft Entra não dá suporte ao provisionamento da senha do Microsoft Entra de um usuário.

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 na ID do Microsoft Entra, a ID do Microsoft Entra enviará uma operação de exclusão para o servidor de diretório. Também pode ser interessante que o Microsoft Entra ID atualize o objeto no servidor de diretório quando um usuário sai do escopo de poder usar o aplicativo. Esse comportamento depende do aplicativo que usará o servidor de diretório, já que muitos diretórios, como OpenLDAP, podem não ter uma maneira padrão de indicar que a conta de um usuário está inativada.

Instalar e configurar o Agente de Provisionamento do Microsoft Entra Connect

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

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

Saia do portal e execute o instalador do agente de provisionamento, concorde com os termos de serviço e selecione Instalar.
Aguarde o assistente de configuração do agente de provisionamento do Microsoft Entra e selecione Avançar.
Na etapa Selecionar Extensão, selecione Provisionamento de aplicativo local e Avançar.
O agente de provisionamento usa o navegador da Web do sistema operacional para exibir uma janela pop-up para você se autenticar na 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 sites da Microsoft à lista de sites confiáveis do navegador para permitir que o JavaScript seja executado corretamente.
Forneça credenciais para um administrador do Microsoft Entra quando você for solicitado a autorizar. O usuário precisa ter, no mínimo, a função Administrador de Identidade Híbrida.
Selecione Confirmar para confirmar a configuração. Quando a instalação for bem-sucedida, você poderá selecionar Sair e fechar o instalador do Pacote do Agente de Provisionamento.

Configurar o aplicativo ECMA local

De volta ao portal, na seção Conectividade Local, selecione o agente que você implantou e selecione Atribuir Agente(s).
Mantenha essa janela do navegador aberta, conforme você concluir a próxima etapa de configuração usando o assistente de configuração.

Configurar o certificado de Host de Conector da ECMA do Microsoft Entra

No Windows Server em que o agente de provisionamento está instalado, selecione com o botão direito do mouse o 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.
Depois que a Configuração do Host de Conector da 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 é autoassinado como parte da raiz confiável. A SAN corresponde ao nome do host.
Selecione Salvar.

Nota

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 de expirar.

Configurar o 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. Use as informações a seguir para orientá-lo em sua configuração.

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 segredo, 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]$_})
```
Se você ainda não fez isso, inicie o Assistente de Configuração do Microsoft ECMA2Host no menu iniciar.
Selecione Novo Conector.

Na página Propriedades, preencha as caixas com os valores especificados na tabela que segue a imagem e selecione Avançar.

Propriedade	Valor
Nome	O nome que você escolheu para o conector, que deve ser único entre todos os conectores no seu ambiente. Por exemplo, `LDAP`.
Temporizador de sincronização automática (minutos)	120
Token secreto	Insira seu token secreto aqui. Deve ter no mínimo 12 caracteres.
DLL da extensão	Para o conector LDAP genérico, selecione Microsoft.IAM.Connector.GenericLdap.dll.

Na página de Conectividade, você configura a comunicação do Host de Conector da ECMA com o servidor de diretório e define algumas das opções de configuração. Preencha as caixas com os valores especificados na tabela que segue a imagem e selecione Próximo. Quando você seleciona Avançar, o conector consulta o servidor de diretório para obter a configuração.

Propriedade	Descrição
Anfitrião	O nome do host em que o servidor LDAP está localizado. Este exemplo 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 de conexão	180
Associação	Essa propriedade especifica como o conector se autentica no servidor de diretório. Com a configuração de `Basic`, ou com a configuração `SSL` ou `TLS` sem um certificado de cliente configurado, o conector envia uma vinculação simples LDAP para autenticar com um nome distinto e uma senha. Com a configuração de `SSL` ou `TLS` e um certificado de cliente especificado, o conector envia uma vinculação `EXTERNAL` SASL LDAP para autenticar-se usando um certificado de cliente.
Nome de Usuário	Como o Conector ECMA se autentica no servidor de diretório. Neste exemplo, `cn=admin,dc=contoso,dc=lab`
Senha	A senha do usuário com o qual o Conector ECMA se autentica no servidor de diretório.
Reino/Domínio	Essa configuração é necessária apenas se você selecionou `Kerberos` como opção de Associação para fornecer o Realm/Domínio do usuário.
Certificado	As configurações nesta seção só serão usadas se você tiver selecionado `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 a sintaxe RFC4522. Esses atributos não podem ser detectados durante a detecçã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ê quiser provisionar esse atributo, a seguinte cadeia de caracteres deverá ser inserida na caixa de 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	Selecione a caixa de seleção `Include operational attributes in schema` para incluir também atributos criados pelo servidor de diretório. Eles incluem atributos como quando o objeto foi criado e a hora da última atualização.
Incluir atributos extensíveis	Selecione 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. 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 não selecionada.
Permitir seleção de âncora manual	Deixe-a desmarcada.

Nota

Se você tiver um problema ao tentar se conectar e não puder prosseguir para a página Global, verifique se a conta de serviço no servidor de diretório está habilitada.

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

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, a entidade e a impressão digital são do 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á apresentado. Alguns diretórios LDAP não listam todos os recursos no DSE raiz e é possível que o conector funcione sem problemas mesmo se um aviso estiver presente.
Controles com suporte	As caixas de seleção de controles com suporte 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 que seja possível fazer a importação delta. Se você não precisar implementar a importação delta, esse campo poderá ficar em branco.
Atributo de senha	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 namespaces adicionais não detectados automaticamente. Por exemplo, essa configuração poderá ser usada se vários servidores comporem um cluster lógico, que deve ser importado ao mesmo tempo. Assim como o Active 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 ainda está configurado na página Configurar Partições e Hierarquias.

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

Na página Perfis de Execução, verifique se as caixas de seleção Exportar e Importação completa estão selecionadas. Em seguida, selecione Próximo.

Propriedade	Descrição
Exportação	Execute o perfil que exporta dados para o servidor de diretório LDAP. Este perfil de execução é necessário.
Importação completa	Execute o perfil que importa todos os dados de fontes LDAP especificadas anteriormente. Este perfil de execução é necessário.
Importação delta	Execute o perfil que importa apenas as alterações do LDAP realizadas 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 saber mais, confira a Referência do Conector LDAP Genérico.

Na página Exportar, deixe os padrões inalterados e selecione Avançar.
Na página Importação Completa, deixe os padrões inalterados e selecione Avançar.
Na página DeltaImport, se estiver presente, deixe os padrões inalterados e selecione Avançar.

Na página Tipos de Objeto, preencha as caixas e selecione Próximo.

Propriedade	Descrição
Objeto de destino	Esse valor é a classe de objeto estrutural de um usuário no servidor de diretório LDAP. Use `inetOrgPerson`e 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 devem ser exclusivos para cada objeto no diretório de destino. O serviço de provisionamento do Microsoft Entra consulta o host do conector ECMA usando esse atributo após o ciclo inicial. Normalmente, use o nome diferenciado, que pode ser selecionado como `-dn-`. Atributos de vários valores, como o atributo `uid` no esquema OpenLDAP, não podem ser usados como âncoras.
Atributo de consulta	Este atributo deve ser o mesmo que a Âncora.
DN	O distinguishedName do objeto de destino. Mantenha `-dn-`
Gerado automaticamente	desmarcado.

O host ECMA descobre os atributos compatíveis com o diretório de destino. Você pode escolher quais desses atributos você deseja expor à 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 obrigatórios ou que você deseja provisionar do Microsoft Entra ID.
A lista suspensa Atributo mostra os atributos que foram descobertos no diretório de destino e 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 definido, não poderá ser selecionado ou estará marcado para o atributo userPassword.

Configure a visibilidade para os atributos a seguir.

Atributo	Tratar como valor único
_distinguishedName
-dn-
export_password
cn	S
gidNumber
homeDirectory
correio	S
objectClass
sn	S
Identificador Único (UID)	S
uidNumber
senhaDoUsuário	S

Depois que todos os atributos relevantes tiverem sido adicionados, selecione Próximo.

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 Desabilitarde fluxo, selecione Excluire, 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 atributo definir valor esteja ciente de que somente valores booleanos são permitidos.

Selecione Concluir.

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

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

No servidor que executa o host do conector ECMA do Microsoft Entra, clique em Iniciar.
Selecione executar se necessário e insira services.msc na caixa.
Na lista de Serviços, verifique se Microsoft ECMA2Host está presente e em execução. Se não estiver em execução, selecione Iniciar.
Se você iniciou o serviço recentemente e tem muitos objetos de usuário no servidor de diretório, aguarde vários minutos até que o conector estabeleça uma conexão com o servidor de diretório.
No servidor que executa o Microsoft Entra ECMA Connector Host, inicie o PowerShell.
Altere para a pasta em que o host ECMA foi instalado, como C:\Program Files\Microsoft ECMA2Host.
Altere para o subdiretório Troubleshooting.
Execute o script TestECMA2HostConnection.ps1 nesse diretório, conforme mostrado, e forneça como argumentos o nome do conector e o valor ObjectTypePathcache. Se o host do conector não estiver escutando na porta TCP 8585, talvez você 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: ************
```
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.
Se o script exibir a saída False, isso significa que o conector não encontrou 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 será esperado e você poderá continuar na próxima seção.
No entanto, se o servidor de diretório já contiver um ou mais usuários, mas o script exibiu False, esse status indica que o conector não pôde ler do 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 se as permissões no servidor de diretório estão configuradas para permitir que o conector leia os usuários existentes.

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

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

Nota

Se a janela tiver atingido o tempo limite, selecione o agente novamente.
1. Entre no portal do Azure.
2. Acesse Aplicativos empresariais e o Aplicativo ECMA local.
3. Selecione Provisionamento.
4. Se Introdução for exibido, altere o modo para Automático. Na seção Conectividade Local, selecione o agente que acabou de implantar, selecione Atribuir Agentes e aguarde dez minutos. Caso contrário, acesse Editar Provisionamento.
Na seção de credenciais de administrador , insira a seguinte URL. Substitua a parte connectorName 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 em que o host ECMA está instalado.

Propriedade Valor

URL do locatário https://localhost:8585/ecma2host_connectorName/scim
Insira o valor do Token Secreto que você definiu quando criou o conector.

Nota

Se você acabou de atribuir o agente ao 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 o registro do agente a ser concluído reiniciando o agente de provisionamento em seu 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 Microsoft Entra Connect Provisioning Agent, selecione o serviço com o botão direito do mouse e reinicie.
Selecione Testar Conexão e aguarde um minuto.
Quando o teste de conexão for bem-sucedido e indicar que as credenciais fornecidas estão autorizadas a habilitar o provisionamento, selecione Salvar.

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

Estender o esquema do Microsoft Entra

Se o servidor de diretório exigir atributos adicionais que não fazem parte do esquema padrão do Microsoft Entra para usuários, ao provisionar você pode 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 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 use o recurso de extensão de diretório para adicionar esse atributo como uma extensão.

Se os usuários tiverem origem no Active Directory Domain Services e tiverem o atributo nesse diretório, você poderá usar o Microsoft Entra Connect ou a sincronização de nuvem do Microsoft Entra Connect. Isso configurará o atributo a ser sincronizado do Active Directory Domain Services com a ID do Microsoft Entra, disponibilizando-o para provisionamento para outros sistemas.

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

Configurar mapeamento de atributo

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. Posteriormente, quando o conector cria um objeto em um servidor de diretório, os atributos de usuário do Microsoft Entra são enviados por meio do conector para o servidor de diretório para fazer parte desse novo objeto.

No centro de administração do Microsoft Entra, em Aplicativos empresariais, selecione o Aplicativo ECMA local e a página Provisionamento.
Selecione Editar provisionamento.
Expanda Mapeamentos e selecione Provisionar usuários do Microsoft Entra. Se essa for a primeira vez que você configura os mapeamentos de atributos para esse aplicativo, haverá apenas um mapeamento presente como espaço reservado.
Para confirmar se o esquema do servidor de diretório está disponível no Microsoft Entra ID, selecione a caixa de seleção Mostrar opções avançadas e selecione Editar lista de atributos do 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, depois selecione Mapeamento de Atributos na barra 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.
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 a seguir para criar o mapeamento, alterando os nomes diferenciados na expressão para corresponder ao da unidade organizacional ou de outro contêiner em seu diretório de destino.
- Tipo de mapeamento: expressão
- Expressão: 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
Se o servidor de diretório exigir vários valores de classe de objeto estrutural ou valores de classe de objeto auxiliar, a serem fornecidos no atributo objectClass, adicione um mapeamento a esse atributo. Para adicionar um mapeamento para objectClass, selecione Adicionar Novo Mapeamento. Use os valores a seguir para criar o mapeamento, alterando os nomes de classe de objeto na expressão para corresponder ao esquema de diretório de destino.
- Tipo de mapeamento: expressão
- 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

Para cada um dos mapeamentos na tabela a seguir para o servidor de diretório, selecione Adicionar Novo Mapeamentoe 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 comum para definir a opção Corresponder objetos usando este atributo para o atributo. Saiba mais sobre mapeamento de atributos aqui.

Para 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 uidNumberexclusivo. 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
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`
Expressão	`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`
Expressão	`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`

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.
Selecione Salvar.

Verifique se os usuários a serem provisionados para o diretório têm atributos necessários

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 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. Cada usuário requer um uid exclusivo e um uidNumberexclusivo.

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

Se os usuários tiverem origem no Microsoft Entra ID, para cada novo atributo que precisar armazenar em um usuário, você 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 um deles um valor desses atributos.

Confirmando usuários por meio do PowerShell

Depois de atualizar os usuários no Microsoft Entra ID, você poderá usar os cmdlets do PowerShell do Microsoft Graph para automatizar a verificação de que os usuários têm todos 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. Este terceiro atributo é usado para conter o uidNumber. 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, por padrão, não retorna 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.

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 usa esses cmdlets para esse cenário, você precisa 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 uma função com privilégios inferiores, como:

Administrador de Usuários, se você prever 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.

Abra o PowerShell.
Se você não tiver os módulos Do Microsoft Graph PowerShell já instalados, instale o módulo Microsoft.Graph.Users e outros 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
```

Conecte-se à ID do Microsoft Entra:

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

Construa a lista de usuários e os atributos a serem verificados.

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

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

Consulte o diretório para cada um dos usuários.

$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

Identifique quais dos usuários nesse diretório estão no escopo de serem usuários com autenticação linux. Essa opção dependerá da configuração do sistema Linux. Para algumas configurações, qualquer usuário que exista em um diretório LDAP é um usuário válido. Outras configurações podem exigir que o usuário tenha um atributo específico ou seja membro de um grupo nesse diretório.
Execute um comando que recupera esse subconjunto de usuários do diretório LDAP em um arquivo CSV. Verifique se a saída inclui os atributos dos usuários que são usados para correspondência com a ID do Microsoft Entra. Exemplos desses atributos são ID do funcionário, nome da conta ou uide endereço de email.
Se necessário, transfira o arquivo CSV que contém a lista de usuários para um sistema com os cmdlets Microsoft Graph PowerShell instalados.
Agora que tem uma lista de todos os usuários obtidos do diretório, você fará a correspondência desses usuários do diretório 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.

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

Administrador de Usuários, se você prever 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.

Abra o PowerShell.
Se você não tiver os módulos Do Microsoft Graph PowerShell já instalados, instale o módulo Microsoft.Graph.Users e outros 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
```

Conecte-se à ID do Microsoft Entra:

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

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.
Leia a lista de usuários obtidos 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 do PowerShell Import-Csv e fornecer o nome do arquivo da seção anterior como um argumento.

Por exemplo, se o arquivo obtido do SAP Cloud Identity Services for nomeado Users-exported-from-sap.csv e estiver localizado no diretório atual, insira 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 for nomeado users.csv e estiver localizado no diretório atual, insira este comando:
```
$filename = ".\users.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Escolha a coluna do arquivo users.csv que corresponderá a um atributo de um usuário na ID do Microsoft Entra.

Se você estiver usando o SAP Cloud Identity Services, o mapeamento padrão será o atributo SAP SCIM userName com o atributo microsoft Entra ID userPrincipalName:
```
$db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"
```
Para outro exemplo, se você estiver usando um banco de dados ou diretório, poderá ter usuários em um banco de dados em que o valor na coluna denominada EMail é o mesmo valor que no atributo Microsoft Entra userPrincipalName:
```
$db_match_column_name = "EMail"
$azuread_match_attr_name = "userPrincipalName"
```

Recupere as IDs desses usuários na ID do Microsoft Entra.

O script do PowerShell a seguir usa os valores $dbusers, $db_match_column_namee $azuread_match_attr_name especificados anteriormente. Ele consultará a 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 obtidos dos Serviços de Identidade de Nuvem do SAP de origem, do banco de dados ou do diretório, esse script poderá levar vários minutos para ser concluído. Se você não tiver um atributo no Microsoft Entra ID que contenha o valor necessário e precisar usar uma expressão de filtro como contains ou outra, será necessário personalizar este script e também 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 }
}

Exiba os resultados das consultas anteriores. Veja se algum dos usuários 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 script do PowerShell a seguir exibirá as contagens de registros que não estavam 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."

Quando o script for concluído, ele indicará um erro se algum registro da fonte de dados não estiver localizado na ID do Microsoft Entra. Se nem todos os registros de usuários do repositório de dados do aplicativo puderem ser localizados como correspondentes aos usuários no Microsoft Entra ID, você precisará investigar quais registros 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, o usuário pode já ter deixado a organização, mas ainda está na fonte de dados do aplicativo. Ou pode haver uma conta de fornecedor ou de superdministrador na fonte de dados do aplicativo que não corresponda a nenhuma pessoa específica na ID do Microsoft Entra.
Se houver usuários que não puderam estar localizados na ID do Microsoft Entra ou que não estavam ativos e capazes de entrar, mas você deseja ter seu acesso revisado ou seus atributos atualizados no SAP Cloud Identity Services, no banco de dados ou no diretório, você precisará atualizar o aplicativo, a regra de correspondência ou atualizar ou criar usuários do Microsoft Entra para eles. Para saber mais sobre quais alterações fazer, confira Gerenciar mapeamentos e contas de usuário em aplicativos que não encontraram correspondência com usuários no Microsoft Entra ID.

Se você escolher a opção de criar usuários na ID do Microsoft Entra, poderá criar usuários em massa usando:
- Um arquivo CSV, conforme descrito em Criar usuários em massa no centro de administração do Microsoft Entra
- O cmdlet New-MgUser
Verifique se esses novos usuários são preenchidos com os atributos necessários para que a ID do Microsoft Entra 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 em que o valor na coluna chamada EMail é o valor que você deseja usar como o Nome Principal do Usuário 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"
```
Em seguida, você pode usar esse script para criar usuários do Microsoft Entra para aqueles no SAP Cloud Identity Services, no banco de dados ou no diretório que não correspondeu aos usuários na ID do Microsoft Entra. 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 mailNickname nem userPrincipalName, a fim de 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
   }
}
```

Depois de adicionar usuários ausentes à ID do Microsoft Entra, execute o script da etapa 7 novamente. Em seguida, execute o script da etapa 8. Verifique se nenhum erro foi 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 ao aplicativo na ID do Microsoft Entra

Agora que o Host de Conector da ECMA do Microsoft Entra está se comunicando com o Microsoft Entra ID e o mapeamento de atributos foi configurado, é possível passar para a configuração de quem está no escopo do 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. Para saber mais sobre como criar atribuições de função de aplicativo em massa usando New-MgServicePrincipalAppRoleAssignedTo, confira Controlando os usuários existentes de um aplicativo no Microsoft Entra ID.

Se você ainda não quiser atualizar os usuários existentes no diretório LDAP, selecione um usuário de teste da ID do Microsoft Entra que tenha os atributos necessários e será provisionado para o servidor de diretório.

Garanta que o usuário a ser selecionado tenha todas as propriedades que serão mapeadas para os atributos necessários do esquema do servidor de diretório.
No portal do Azure, selecione Aplicativos empresariais.
Selecione o aplicativo ECMA local.
À esquerda, em Gerenciar, selecione Usuários e grupos.
Selecione Adicionar usuário/grupo.
Em Usuários, selecione Nenhum Selecionado.
Selecione um usuário à direita e selecione o botão Selecionar.
Selecione Atribuir.

Testar o provisionamento

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

No servidor que executa o Host de Conector da ECMA do Microsoft Entra, clique em Iniciar.
Insira run e services.msc na caixa.
Na lista de Serviços , verifique se o serviço de do Agente de Provisionamento do Microsoft Entra Connect e o serviço de Microsoft ECMA2Host estão em execução. Caso contrário, selecione Iniciar.
No portal do Azure, selecione Aplicativos Empresariais.
Selecione o Aplicativo ECMA local.
À esquerda, selecione Provisionamento.
Selecionar Provisionar sob demanda.
Pesquise um de seus usuários de teste e selecione Provisionar.
Após vários segundos, a mensagem Usuário criado com sucesso no sistema de destino será exibida, junto com uma lista dos atributos do usuário. Caso apareça um erro, confira 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. Para saber mais sobre como criar atribuições de função de aplicativo em massa usando New-MgServicePrincipalAppRoleAssignedTo, confira Controlando os usuários existentes de um aplicativo no Microsoft Entra ID.

No portal do Azure, selecione o aplicativo.
À esquerda, em Gerenciar, selecione Usuários e grupos.
Verifique se todos os usuários estão atribuídos à função de aplicativo.
Volte para a página de configuração de provisionamento.
Verifique se o escopo está definido apenas para usuários e grupos atribuídos, transforme o status de provisionamento em One selecione Salvar.
Aguarde vários minutos para que o provisionamento seja iniciado. Pode levar 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 exibido, selecione Exibir logs de provisionamento. Procure no log uma linha na qual o status é Falha e selecione essa linha.

Se a mensagem de erro for não foi possível criar Usuário, então verifique se os atributos exibidos estão de acordo com os 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 de solução de problemas incluir que um valor objectClass é invalid per syntax, verifique se o mapeamento de atributo de provisionamento para o atributo objectClass inclui apenas nomes de classes de objeto reconhecidas pelo servidor de diretório.

No caso de outros erros, confira solução de problemas do provisionamento de aplicativos locais.

Se você quiser pausar o provisionamento para este aplicativo, na página de configuração de provisionamento, poderá alterar o status de provisionamento para Desativare selecionar Salvar. Essa ação impede que o serviço de provisionamento seja executado no futuro.

Verificar se os usuários foram provisionados com êxito

Depois de aguardar, verifique o servidor de diretório para garantir que os usuários estão 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 OpenLDAP no Linux.

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

Próximas etapas

Para obter mais informações sobre o que o serviço de provisionamento faz, como ele funciona e perguntas frequentes, consulte Automatizar o provisionamento e o desprovisionamento de usuários para aplicativos SaaS com o Microsoft Entra ID e arquitetura de provisionamento de aplicativos local.

Compartilhar via

Configurando a ID do Microsoft Entra para provisionar usuários em um diretório LDAP para autenticação do Linux

Pré-requisitos para provisionar usuários em um diretório LDAP para autenticação do Linux

Pré-requisitos locais

Requisitos de nuvem

Mais recomendações e limitações

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

Instalar e configurar o Agente de Provisionamento do Microsoft Entra Connect

Configurar o aplicativo ECMA local

Configurar o certificado de Host de Conector da ECMA do Microsoft Entra

Configurar o conector LDAP genérico

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

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

Estender o esquema do Microsoft Entra

Configurar mapeamento de atributo

Verifique se os usuários a serem provisionados para o diretório têm atributos necessários

Confirmando usuários por meio do PowerShell

Coletar usuários existentes do diretório LDAP

Obter as IDs dos usuários no Microsoft Entra ID

Atribuir usuários ao aplicativo na ID do Microsoft Entra

Testar o provisionamento

Iniciar o provisionamento de usuários

Solução de problemas de erros de provisionamento

Verificar se os usuários foram provisionados com êxito

Próximas etapas

Comentários

Recursos adicionais