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

Artigo
12/16/2024

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 confiável por esse sistema Linux. Isso permite que os usuários façam login em um sistema Linux que depende desse diretório LDAP para autenticação do usuário. Quando um usuário é removido do Microsoft Entra ID, ele não é mais capaz de fazer login em um sistema Linux.

Observação

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

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

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

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

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

Pré-requisitos locais

Um 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 suporta o esquema POSIX, como OpenLDAP, no qual os usuários podem ser criados, atualizados e excluídos. Para obter mais informações sobre servidores de diretório suportados, consulte o Generic LDAP Connector reference.
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 do Microsoft Online Services e domínios 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 nesse servidor.
Opcional: Embora não seja necessário, é recomendável baixar Microsoft Edge para Windows Server e usá-lo no lugar do Internet Explorer.

Requisitos da nuvem

Um tenant da Microsoft Entra com 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 seus requisitos, consulte Comparar recursos geralmente disponíveis do Microsoft Entra ID.
A função Administrador de Identidade Híbrida para configurar o agente de provisionamento.
As funções de Administrador de Aplicativos ou Administrador de Aplicativos na 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 cada usuário do Microsoft Entra a ser provisionado para o diretório LDAP, e esses atributos já devem estar preenchidos. Em particular, cada usuário é obrigado a 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 a partir de um atributo existente no usuário ou estender o esquema do Microsoft Entra. Em seguida, pode definir esse atributo para os utilizadores em questão. Consulte a seção Extensibilidade do Gráfico para aprender a 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 é recomendado 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.
Atualmente, para o AD LDS, os usuários não podem ser provisionados com senhas. Portanto, é necessário desativar a política de senha 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 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.

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ê precisa discutir com o operador do servidor de diretório em sua organização como integrar com seu servidor de diretório. As informações a recolher 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órios.
Como associar usuários no servidor de diretório com usuários no Microsoft Entra ID.
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 OpenLDAP.

Definição de configuração	Onde o valor é definido	Valor de exemplo
Nome do host do servidor de diretório	Assistente de configuração página de conectividade	`APP3`
Número da porta do servidor de diretório	Assistente de configuração página de conectividade	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 junto ao servidor de diretório	Assistente de Configuração página de conectividade	`cn=admin,dc=contoso,dc=lab`
Senha para o conector autenticar-se no servidor de diretório	Assistente de configuração página de conectividade
Classe de objeto estrutural para um usuário no servidor de diretório	Assistente de configuração Tipos de objeto página	`inetOrgPerson`
classes de objeto auxiliares para um usuário no servidor de diretório	Atributos de mapeamento da página de provisionamento no portal do Azure	`posixAccount` e`shadowAccount`
atributos a serem preenchidos em um novo usuário	O assistente de configuração página Selecionar Atributos e o portal do Azure página de provisionamento Mapeamentos de atributos	`cn`, `gidNumber`, `homeDirectory`, `mail`, `objectClass`, `sn`, `uid`, `uidNumber`, `userPassword`
Hierarquia de nomenclatura exigida pelo servidor de diretório	Mapeamentos de atributos da página de provisionamento do 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 no Microsoft Entra ID e no servidor de diretório	Mapeamentos de atributos da página de provisionamento do portal do Azure	`mail`
comportamento de desprovisionamento quando um utilizador fica fora do escopo no Microsoft Entra ID	Assistente de configuração página de desprovisionamento	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ê precisa 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 utilizador representado por uma classe de objetos estrutural, como inetOrgPerson, e, opcionalmente, por classes de objetos 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 quaisquer classes 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 suportar a autenticação 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 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 um 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 então 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 envolve 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 sistemas Linux que usam esse servidor de diretório lidam com a autenticação. Alguns sistemas 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, pois 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 estiver configurado e o Microsoft Entra ID tiver estabelecido uma ligação entre um utilizador no Microsoft Entra ID e um utilizador no diretório, seja para um utilizador já no diretório ou um novo utilizador, o Microsoft Entra ID poderá provisionar alterações de atributos do utilizador do Microsoft Entra no diretório.

Se um usuário atribuído ao aplicativo for excluído no Microsoft Entra ID, o Microsoft Entra ID enviará uma operação de exclusão para o servidor de diretório. Você também pode querer que o Microsoft Entra ID atualize o objeto no servidor de diretório quando um utilizador sair do âmbito de utilização da aplicação. 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.

Instalar e configurar o Agente de Provisionamento do Microsoft Entra Connect

Entre no portal do Azure.
Vá para aplicações empresariais e selecione Nova aplicação.
Pesquise o aplicativo ECMA local aplicativo, dê um nome ao aplicativo e selecione Criar para adicioná-lo ao seu locatário.
No menu, navegue até à página de Provisionamento do seu aplicativo.
Selecione Começar.
Na página de Provisionamento , altere o modo para Automático .

Em Conectividade Local , selecione Transferir e instalare depois selecione Aceitar termos para & transferir.

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.
No passo Selecionar Extensão, selecione Provisionamento de Aplicação no Local e, em seguida, selecione 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 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.
Forneça credenciais para um administrador do Microsoft Entra quando você for solicitado a autorizar. É necessário que o utilizador tenha pelo menos a função Administrador de Identidade Híbrida.
Selecione Confirmar para confirmar a configuração. Quando a instalação for bem-sucedida, poderá selecionar Saire também fechar o pacote de instalação 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, em seguida, selecione Atribuir Agente(s).
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

No Windows Server onde 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 do Conector ECMA for iniciada, se esta for a primeira vez que você executa o assistente, ele solicita 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 cadeia de confiança. A SAN corresponde ao nome do host.
Selecione Salvar.

Observação

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 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 guiá-lo em sua configuração.

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]$_})
```
Se ainda não tiver feito 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 se segue à imagem e selecione Avançar.

Propriedade	Valor
Nome	O nome escolhido para o conector, que deve ser exclusivo em todos os conectores em seu ambiente. Por exemplo, `LDAP`.
Temporizador de sincronização 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.

Na página de conectividade, você configurará como o ECMA Connector Host se comunica 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 consulta o servidor de diretório para sua configuração.

Propriedade	Descrição
Anfitrião	O nome do host onde o servidor LDAP está localizado. Este exemplo usa `APP3` como o nome de host de exemplo.
Porto	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.
Tempo limite de conexão	180
Vinculação	Esta propriedade especifica como o conector se autentica no servidor de diretório. Com a configuração `Basic`, ou com a configuração `SSL` ou `TLS` e nenhum certificado de cliente configurado, o conector envia uma ligação simples LDAP para autenticar com um nome distinto e uma senha. Com a configuração `SSL` ou `TLS` e um certificado de cliente especificado, o conector envia uma associação de `EXTERNAL` SASL LDAP para autenticar com um certificado de cliente.
Nome de Utilizador	Como o ECMA Connector se autentica no servidor de diretório. Neste exemplo, `cn=admin,dc=contoso,dc=lab`
Palavra-passe	A palavra-passe do utilizador que o ECMA Connector utiliza para se autenticar no servidor de directó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.
Certidão	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 de aliases de atributos é utilizada para atributos definidos no esquema usando a 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 caixa de seleção `Include operational attributes in schema` 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 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 desmarcada.
Permitir a seleção manual de âncoras	Deixe desmarcado.

Observação

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

Propriedade	Descrição
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` tiver sido especificado, o assistente exibirá o certificado retornado pelo servidor de diretório. Confirme se o emissor, o assunto e a impressão digital são para o servidor de diretório correto.
Recursos obrigatórios encontrados	O conector também verifica se os controles obrigatórios estão presentes no 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	Os controlos suportados, as caixas de seleção, controlam o comportamento de determinadas operações.
Delta Importação	O DN do log de alterações é o contexto de nomenclatura usado pelo log de alterações delta, por exemplo, cn=changelog. Este valor deve ser especificado para realizar a importação delta. Se você não precisar implementar a importação delta, esse campo poderá ficar em branco.
Atributo de palavra-passe	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 é adicionalmente 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 Executar Perfis, verifique se a caixa de seleção Exportar e a caixa de seleção Importação Completa estão ambas selecionadas. Em seguida, selecione Avançar.

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 total	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 alterações do LDAP desde a última importação completa ou delta. Só habilite esse perfil de execução 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 Generic LDAP Connector.

Na página Exportar, deixe as configurações padrão inalteradas e selecione Avançar.
Na página de Importação Completa, deixe os padrões inalterados e selecione Avançar.
Na página DeltaImport, se aplicável, deixe as definições padrão inalteradas e selecione Avançar.

Na página Tipos de Objeto, preencha as caixas e selecione Seguinte.

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, 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 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	Esse atributo deve ser o mesmo que a Âncora.
DN	O nomeDistinto do objeto de destino. Continue `-dn-`.
Gerado automaticamente	não verificado

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 ID do Microsoft Entra.
A lista suspensa Atributo mostra qualquer atributo que foi descoberto no diretório de destino e não foi escolhido no uso anterior do assistente de configuração página Selecionar atributos.

Certifique-se de que a caixa de seleção Treat as single value está desmarcada para o atributo objectClass e, se userPassword estiver a ser definida, deve ser não selecionável ou estar marcada para o atributo userPassword.

Configure a visibilidade para os seguintes atributos.

Atributo	Tratar como valor único
_nomeDistinto
-DN-
export_password
CN	Y
gidNumber
homeDirectório
correio	Y
objectClass
SN	Y
Identificador Único	Y
número de identificação único (uidNumber)
senha do utilizador	Y

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

Na página Desprovisionamento, pode especificar se deseja que o Microsoft Entra ID remova os utilizadores do diretório quando estiverem fora do escopo da aplicação. Em caso afirmativo, em Desativar 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.

Observação

Se você usar o valor do atributo set esteja ciente de que apenas valores booleanos são permitidos.

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 identificou todos os usuários existentes do servidor de diretório.

No servidor que executa o Microsoft Entra ECMA Connector Host, selecione Iniciar.
Selecione a opção executar, se necessário, e depois digite 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 recentemente o serviço e tem muitos objetos de usuário no servidor de diretório, aguarde alguns 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.
Mude para a pasta onde o host ECMA foi instalado, como C:\Program Files\Microsoft ECMA2Host.
Mude 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ê também precise fornecer o argumento -Port. Quando solicitado, digite o token secreto configurado para esse conector.
```
PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> $cout = .\TestECMA2HostConnection.ps1 -ConnectorName LDAP -ObjectTypePath cache; $cout.length -gt 9
Supply values for the following parameters:
SecretToken: ************
```
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, 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.
No entanto, se o servidor de diretório já contiver um ou mais utilizadores, mas o script exibiu False, esse estado indica que o conector não conseguiu ler do servidor de diretório. Se tentar efetuar o provisionamento, então o Microsoft Entra ID pode não corresponder corretamente os utilizadores nesse diretório de origem com os utilizadores 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 conector e se as permissões no servidor de diretório estão a permitir que o conector leia os utilizadores existentes.

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

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

Observação

Se a janela tiver expirado, você precisará selecionar novamente o agente.
1. Entre no portal do Azure.
2. Vá para aplicações empresariais e a aplicação ECMA no local .
3. Selecione de provisionamento .
4. Se Introdução for exibida, altere o modo para Automático, na seção de 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.
Na seção de credenciais de administrador, insira o 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 onde o host ECMA está instalado.

Propriedade Valor

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

Observação

Se você acabou de atribuir o agente para o aplicativo, aguarde 10 minutos para que o registro seja concluído. O teste de conectividade não funcionará até 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, selecione com o botão direito do mouse o serviço e reinicie.
Selecione Testar Conexãoe aguarde um minuto.
Após o teste de conexão ser bem-sucedido e indicar que as credenciais fornecidas estão autorizadas a ativar 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 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 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 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. Isso configurará o atributo a ser sincronizado dos Serviços de Domínio Ative Directory para o ID do Microsoft Entra, tornando-o disponível para provisionamento para outros sistemas.

Se os usuários forem originários do 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 programados para serem provisionados, atribuindo um valor a cada usuário 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 cria um objeto em um servidor de diretório, os atributos de usuário do Microsoft Entra são enviados através do conector para o servidor de diretório para fazer parte desse novo objeto.

No centro de administração do Microsoft Entra, em Aplicações empresariais, selecione a aplicação ECMA local e, em seguida, selecione a página de Provisionamento.
Selecione Provisionamento de edição.
Expanda Mapeamentos e selecione Provisionar usuários do Microsoft Entra . Se esta for a primeira vez que você configura os mapeamentos de atributos para este aplicativo, há apenas um mapeamento presente como um espaço reservado.
Para confirmar que 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.
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 seguintes valores 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: 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 que vários valores de classe de objeto estrutural, ou valores de classe de objeto auxiliar, sejam fornecidos no atributo objectClass, adicione um mapeamento a esse atributo. Para adicionar um mapeamento para objectClass, selecione Adicionar Novo Mapeamento. Use os seguintes valores 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, ao 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

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 estiver a fazer o provisionamento num diretório existente com utilizadores existentes, precisa de editar o mapeamento para o atributo que é comum de modo a definir os objetos Match usando esse atributo para esse atributo. Saiba mais sobre o mapeamento de atributos aqui.

Para OpenLDAP com o esquema POSIX, você também precisará fornecer os atributos gidNumber, homeDirectory, uid e uidNumber. Cada utilizador necessita de um uid único e de um uidNumberúnico. 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 a partir de uma constante.

Tipo de mapeamento	Atributo Source	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 para o 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 ao urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword que defina uma senha aleatória inicial para o usuário.
Selecione Salvar.

Garantir que os usuários a serem provisionados para o diretório tenham os 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 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. Cada utilizador necessita de um uid único e de um uidNumberúnico.

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ê precisa armazenar em um usuário, você definirá uma extensão de diretório. Em seguida, atualizar os de usuários do Microsoft Entra que estão planejados para serem provisionados, para dar a cada usuário um valor desses atributos.

Confirmando usuários via PowerShell

Depois de atualizar os utilizadores no Microsoft Entra ID, pode usar os cmdlets do Microsoft Graph PowerShell para automatizar uma verificação para garantir que os utilizadores possuam todos os atributos necessários.

Por exemplo, suponha que seu provisionamento exigisse 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 Graph v1.0 Get-MgUser, 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 Microsoft Graph PowerShell cmdlets.

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 Aplicações ou Administrador de Governança de Identidade, se estiveres apenas a gerir atribuições de função de aplicação.

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

Conecte-se ao Microsoft Entra ID:

$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 de 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. Esta escolha dependerá da configuração do seu 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 recupere esse subconjunto de usuários do diretório LDAP em um arquivo CSV. Certifique-se de que a saída inclui os atributos dos usuários que são usados para correspondência com o Microsoft Entra ID. Exemplos desses atributos são ID do funcionário, nome ou uidda conta e endereço de e-mail.
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 você tem uma lista de todos os usuários obtidos do diretório, você fará a correspondência entre esses usuários do diretório e os usuários no Microsoft Entra ID. Antes de continuar, revise as informações sobre usuários correspondentes 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 cmdlets.

Administrador de usuários, se você prevê a criação de novos usuários.
Administrador de Aplicações ou Administrador de Governança de Identidade, se estiveres apenas a gerir atribuições de função de aplicação.

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

Conecte-se ao Microsoft Entra ID:

$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 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 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 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
```
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 será o atributo SAP SCIM userName com o atributo ID do Microsoft Entra 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, você pode ter usuários em um banco de dados onde o valor na coluna chamada 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 no Microsoft Entra ID.

O script PowerShell a seguir usa os valores $dbusers, $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 não tiveres um atributo no Microsoft Entra ID que tenha o valor necessário e precisares usar uma expressão de filtro contains ou outra, vais precisar personalizar este script e aquele 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 }
}

Veja os resultados das consultas anteriores. Veja se algum dos utilizadores no SAP Cloud Identity Services, o banco de dados ou o diretório não pôde ser localizado no Microsoft Entra ID, devido a erros ou a correspondências inexistentes.

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

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 Microsoft Entra ID sem que sua propriedade mail correspondente 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.
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:
- Um ficheiro CSV, conforme descrito em criação em massa de utilizadores no centro de administração do Microsoft Entra
- O cmdlet New-MgUser
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 exclusivo entre todos os utilizadores do diretório.

Por exemplo, você pode ter usuários em um banco de dados onde o valor na coluna chamada 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 mailNickname nem userPrincipalName, para fornecer esse atributo do Microsoft Entra.
```
$dbu_missing_columns_list = @()
$dbu_creation_failed_list = @()
foreach ($dbu in $dbu_not_matched_list) {
   if (($null -ne $dbu.$db_display_name_column_name -and $dbu.$db_display_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_user_principal_name_column_name -and $dbu.$db_user_principal_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_mail_nickname_column_name -and $dbu.$db_mail_nickname_column_name.Length -gt 0)) {
      $params = @{
         accountEnabled = $false
         displayName = $dbu.$db_display_name_column_name
         mailNickname = $dbu.$db_mail_nickname_column_name
         userPrincipalName = $dbu.$db_user_principal_name_column_name
         passwordProfile = @{
           Password = -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
         }
      }
      try {
        New-MgUser -BodyParameter $params
      } catch { $dbu_creation_failed_list += $dbu; throw }
   } else {
      $dbu_missing_columns_list += $dbu
   }
}
```

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 usuários ao aplicativo no Microsoft Entra ID

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 Aplicativo 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, consulte governando os usuários existentes de um aplicativo no Microsoft Entra ID.

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

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.
No portal do Azure, selecione aplicações empresariais.
Selecione a aplicação local ECMA .
À 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.
Agora selecione Atribuir.

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.

No servidor onde está a correr o Microsoft Entra ECMA Connector Host, selecione Iniciar.
Digite executar e digite services.msc na caixa.
Na lista de Serviços , verifique se o serviço Agente de Provisionamento do Microsoft Entra Connect e os serviços Microsoft ECMA2Host estão em execução. Caso contrário, selecione Iniciar.
No portal do Azure, selecione aplicações empresariais.
Selecione a aplicação aplicação ECMA local.
À esquerda, selecione Provisionamento.
Selecione Provisionamento sob demanda.
Procure um dos seus utilizadores de teste e selecione Provision.
Após alguns segundos, aparecerá a mensagem Usuário criado com êxito no do sistema de destino, com uma lista dos atributos do usuário. Se aparecer um erro, em vez disso, consulte a secção 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. Para saber mais sobre como criar atribuições de função de aplicativo em massa usando New-MgServicePrincipalAppRoleAssignedTo, consulte governando 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.
Certifique-se de que todos os usuários estejam atribuídos à função do aplicativo.
Volte para a página de configuração de provisionamento.
Verifique se o escopo está definido como somente utilizadores e grupos atribuídos, altere o estado de aprovisionamento para Ativadoe selecione Guardar.
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 Ver logs de provisionamento. Procure no log uma linha na qual o Status é Falhae selecione nessa linha.

Se a mensagem de erro for Falhou na criação do utilizador, verifique se os atributos mostrados correspondem aos requisitos do esquema de diretório.

Para mais informações, aceda ao separador Resolução de Problemas & Recomendações.

Se a mensagem de erro de resolução de problemas incluir que um valor de objectClass é invalid per syntax, verifique se o mapeamento do atributo de provisionamento para o atributo objectClass 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 do provisionamento para Desativadoe 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 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 da ID do Microsoft Entra.

Próximos passos

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

Partilhar via

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

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

Pré-requisitos locais

Requisitos da nuvem

Mais recomendações e limitações

Determine como o Microsoft Entra LDAP Connector 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 Microsoft Entra ECMA Connector Host

Configurar o conector LDAP genérico

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

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

Estender o esquema do Microsoft Entra

Configurar mapeamento de atributos

Garantir que os usuários a serem provisionados para o diretório tenham os atributos necessários

Confirmando usuários via PowerShell

Coletar usuários existentes do diretório LDAP

Recuperar as IDs dos usuários no Microsoft Entra ID

Atribuir usuários ao aplicativo no Microsoft Entra ID

Provisionamento de teste

Comece a provisionar usuários

Solução de problemas de erros de provisionamento

Verifique se os usuários foram provisionados com êxito

Próximos passos

Comentários

Recursos adicionais