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

Artigo
02/13/2024

A documentação a seguir é um tutorial demonstrando como controlar o acesso a um sistema Linux. Isso é implementado pelo Microsoft Entra provisionando usuários em um diretório LDAP local de confiança desse sistema Linux, para que esses usuários possam fazer logon posteriormente em um sistema Linux que depende desse diretório LDAP para autenticação de usuários. E quando um usuário é removido do Microsoft Entra ID, ele não consegue mais fazer logon em um sistema Linux.

Observação

O cenário descrito neste artigo só é aplicável a sistemas Linux existentes que já dependem de um módulo LDAP Name Services Switch (NSS) ou Pluggable Authentication Modules (PAM) para identificação e autenticação do usuário. As VMs Linux no Azure ou habilitadas para o Azure Arc devem ser integradas à autenticação do Microsoft Entra. Você já pode usar o Microsoft Entra ID como uma plataforma de autenticação básica e uma autoridade de certificação para entrar com o SSH em uma VM do Linux usando o Microsoft Entra ID e a autenticação baseada em certificado OpenSSH, conforme descrito em Entrar em uma máquina virtual do 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, além da autenticação do 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 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 sistemas POSIX para autenticação do usuário.

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

Pré-requisitos do local

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 oferece suporte ao esquema POSIX, como OpenLDAP, no qual os usuários podem ser criados, atualizados e excluídos. Para obter mais informações, confira 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, com conectividade com o servidor do diretório de destino e conectividade de saída com login.microsoftonline.com, outros Microsoft Online Services e domínios doAzure. Um exemplo é uma máquina virtual do Windows Server 2016 hospedada na IaaS do Azure ou por trás de um proxy. O .NET Framework 4.7.2 precisa ser instalado nesse servidor.
Opcional: embora não seja necessário, é recomendável baixar o Microsoft Edge para Windows Server e usá-lo em vez do Internet Explorer.

Requisitos de nuvem

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

O uso desse recurso requer licenças de P1 do Microsoft Entra ID. Para encontrar a licença certa para seus requisitos, confira Comparar recursos do Microsoft Entra ID com disponibilidade geral.
Função Administrador de Identidade Híbrida para configurar o agente de provisionamento.
As funções de Administrador de Aplicativo ou Administrador de Aplicativo de Nuvem para configurar o provisionamento no portal do Azure ou no Centro de administração do Microsoft Entra.
Os usuários do Microsoft Entra a serem provisionados para o diretório LDAP já devem ser preenchidos com os atributos que serão exigidos pelo esquema do servidor de diretório e são específicos para cada usuário. 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ê precisaria gerar esse número a partir de um atributo existente no usuário ou estender o esquema do Microsoft Entra e preencher esse atributo nos usuários no escopo. Consulte Extensibilidade do Graph para saber como criar extensões de diretório adicionais.

Mais recomendações e limitações

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

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

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

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

Definição de configuração	Onde o valor é definido	Valor de exemplo
nome do host do servidor de diretório	Página Conectividade do assistente de configuração	`APP3`
número da porta do servidor de diretório	Página Conectividade do assistente de configuração	636. Para LDAP sobre SSL ou TLS (LDAPS), use a porta 636. Para `Start TLS`, use a porta 389.
conta para que o conector se identifique com o servidor de diretório	Página Conectividade do assistente de configuração	`cn=admin,dc=contoso,dc=lab`
senha para que o conector se autentique no servidor de diretório	Página Conectividade do assistente de configuração
classe de objeto estrutural para um usuário no servidor de diretório	Página Tipos de Objeto do assistente de configuração	`inetOrgPerson`
classes de objeto auxiliar para um usuário no servidor de diretório	mapeamentos de atributo da página Provisionamento no portal do Azure	`posixAccount` e`shadowAccount`
atributos a serem preenchidos em um novo usuário	Mapeamentos de atributo da página Selecionar Atributos do assistente de configuração e da página Provisionamento	`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 ficar imediatamente abaixo de `DC=Contoso,DC=lab`
atributos para correlacionar usuários no Microsoft Entra ID e no servidor de diretório	mapeamentos de atributo da página Provisionamento no portal do Azure	`mail`
comportamento de desprovisionamento quando um usuário sai do escopo no Microsoft Entra	Página de Desprovisionamento do assistente de configuração	Excluir o usuário do servidor de diretório

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

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

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

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

As regras de hierarquia de diretório implementadas por um servidor de diretório descrevem como os objetos de cada usuário se relacionam entre si e com objetos existentes no diretório. Na maioria das implantações, a organização optou por ter uma hierarquia simples no seu servidor de diretório, na qual cada objeto para um usuário está localizado imediatamente 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á houver um usuário no servidor de diretório correspondente a um usuário do Microsoft Entra. Cada diretório LDAP tem um nome diferenciado exclusivo para cada objeto no servidor de diretório. No entanto, esse nome diferenciado geralmente não está presente para usuários no Microsoft Entra ID. Em vez disso, uma organização pode ter um atributo diferente, como mail ou employeeId, no seu esquema de servidor de diretório que também está presente nos seus usuários no Microsoft Entra ID. Em seguida, quando o conector está provisionando um novo usuário em um servidor de diretório, o conector pode pesquisar se já existe um usuário nesse diretório que tenha um valor específico desse atributo e criar apenas um novo usuário no servidor de diretório, se um não estiver presente.

Se o cenário envolver a criação de novos usuários no diretório LDAP e não apenas atualizar ou excluir usuários existentes, você também precisará determinar como os sistemas Linux que usam esse servidor de diretório lidarão com a autenticação. Alguns sistemas podem consultar a chave pública SSH de um usuário ou o certificado do diretório, o que pode ser apropriado para os usuários que já possuem credenciais desses formulários. No entanto, se o aplicativo que depende do servidor de diretório não der suporte a protocolos de autenticação modernos ou credenciais mais fortes, você precisará definir uma senha específica do aplicativo ao criar um usuário no diretório, pois o Microsoft Entra ID não dá suporte ao provisionamento da senha de um usuário do Microsoft Entra.

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

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.
Do menu, navegue até a página de Provisionamento do seu 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, em seguida, selecione Avançar.
O agente de provisionamento usará o navegador da Web do sistema operacional para exibir uma janela pop-up para você e potencialmente se autenticar no Microsoft Entra ID e, potencialmente, também no provedor de identidade da sua organização. Se você estiver usando o Internet Explorer como navegador no Windows Server, talvez seja necessário adicionar os sites da Microsoft à lista de sites confiáveis do navegador para permitir que o JavaScript seja executado corretamente.
Forneça credencial para um administrador do Microsoft Entra quando solicitado a autorizar. O usuário deve ter, no mínimo, a função Administrador de Identidade Híbrida.
Selecione Confirmar para confirmar a configuração. Depois que a instalação for bem-sucedida, você poderá selecionar Sair e também fechar o instalador do pacote do agente de provisionamento.

Configurar o dispositivo ECMA local

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ê conclui a próxima etapa de configuração usando o assistente de configuração.

Configurar o certificado de host do conector ECMA do Microsoft Entra

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

Observação

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

Configurar o conector LDAP genérico

Dependendo das opções escolhidas, algumas das telas do assistente podem não estar disponíveis e as informações podem ser um pouco diferentes. Use as seguintes informações para orientações na 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 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 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 escolhido para o conector, que deve ser exclusivo em todos os conectores em seu ambiente. Por exemplo, `LDAP`.
Temporizador de sincronização síncrona (minutos)	120
Token secreto	Insira seu token secreto aqui. Ela deve ter no mínimo 12 caracteres.
DLL de extensão	Para obter um conector LDAP genérico, selecione Microsoft.IAM.Connector.GenericLdap.dll.

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

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

Observação

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

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

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

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

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

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

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

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

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

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

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

Configure a visibilidade para os seguintes atributos.

Atributo Tratar como valor único

_distinguishedName

-dn-

export_password

cn S

gidNumber

homeDirectory

mail S

objectClass

sn S

uid S

uidNumber

userPassword S

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

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

Observação

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

Selecione Concluir.

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

Siga estas etapas para confirmar se o host do conector foi iniciado e identificou todos 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, em seguida, insira services.msc na caixa.
Na lista 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 para que o conector estabeleça uma conexão com o servidor de diretório.
No servidor que executa o host do conector ECMA do Microsoft Entra, 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 abaixo, e forneça como argumentos o nome do conector e o ObjectTypePath valor cache. Se o host do conector não estiver escutando na porta TCP 8585, talvez você também precise fornecer o 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 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 essa for uma nova instalação do servidor de diretório, esse comportamento deverá ser esperado e você poderá continuar na próxima seção.
No entanto, se o servidor de diretório já contiver um ou mais usuários, mas o script tiver exibido False, esse status indica que o conector não pode ler no servidor de diretório. Se você tentar provisionar, talvez o Microsoft Entra ID não corresponda corretamente os usuários nesse diretório de origem aos usuários no Microsoft Entra ID. Aguarde vários minutos até que o host do conector conclua a leitura de objetos do servidor de diretório existente e execute novamente o script. Se a saída continuar sendo False, verifique a configuração do conector e as permissões no servidor de diretório estão permitindo que o conector leia os usuários existentes.

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

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

Observação

Se a janela tiver atingido o tempo limite, você precisará selecionar novamente o agente.
1. Entre no portal do Azure.
2. Acesse Aplicativos empresariais e o selecione Aplicativo ECMA local.
3. Clique em Provisionamento.
4. Se Introdução for exibido, altere o modo para Automático, na seção Conectividade Local, selecione o agente que você acabou de implantar e selecione Atribuir Agentes e aguarde dez minutos. Caso contrário, acesse Editar Provisionamento.
Na seção Credenciais de administrador, insira a URL a seguir. Substitua a parte connectorName pelo nome do conector especificado host ECMA, como LDAP. Se você tiver fornecido um certificado de sua autoridade de certificação para o host ECMA, substitua localhost pelo nome do host do servidor em que o host ECMA está instalado.

Propriedade Valor

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

Observação

Se você acabou de atribuir o agente para o aplicativo, aguarde 10 minutos para que o registro seja concluído. O teste de conectividade não funcionará até a conclusão do registro. Forçar a conclusão do registro do agente reiniciando o agente de provisionamento no servidor pode acelerar o processo de registro. Vá para o servidor, pesquise por serviços na barra de pesquisa do Windows, identifique o serviço Agente de provisionamento do Microsoft Entra Connect, clique com o botão direito do mouse no serviço e reinicie.
Selecione Testar Conexão e aguarde um minuto.
Depois que o teste de conexão for bem-sucedido e indicar que as credenciais fornecidas estão autorizadas para habilitar o provisionamento, selecione Salvar.

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

Estenda o esquema do Microsoft Entra

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

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

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

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

Configurar o mapeamento de atributo

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

No centro de administração do Microsoft Entra, em Aplicativos empresariais, selecione o aplicativo ECMA local e selecione 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ê configurou os mapeamentos de atributo para esse aplicativo, haverá apenas um mapeamento presente, para um espaço reservado.
Para confirmar se o esquema do servidor do diretório está disponível no Microsoft Entra ID, marque a caixa de seleção Mostrar opções avançadas e selecione Editar lista de atributos para ScimOnPremises. Verifique se todos os atributos selecionados no assistente de configuração estão listados. Caso contrário, aguarde vários minutos para que o esquema seja atualizado, selecione Mapeamento de atributos na linha de navegação e, em seguida, selecione Editar lista de atributos para ScimOnPremises novamente para recarregar a página. Depois de ver os atributos listados, cancele essa página para retornar à lista de mapeamentos.
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 abaixo para criar o mapeamento, alterando os nomes diferenciados na expressão para corresponder ao da unidade organizacional ou de outro contêiner no diretório de destino.
- Tipo de mapeamento: expressão
- Expressão: 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 auxiliares sejam fornecidos no atributo objectClass, adicione um mapeamento a esse atributo. Para adicionar um mapeamento para objectClass, selecione Adicionar Novo Mapeamento. Use os valores abaixo para criar o mapeamento, alterando os nomes de classe de objeto na expressão para corresponder aos do esquema de diretório de destino.
- Tipo de mapeamento: expressão
- Expressão, se estiver provisionando o esquema 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 Mapeamento e especifique os atributos de origem e destino. Se você estiver provisionando em um diretório existente com usuários existentes, será necessário editar o mapeamento para o atributo que é comum para definir Correspondência de objetos usando este atributo para aquele 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 usuário requer um uid exclusivo e um uidNumber exclusivo. Normalmente, o homeDirectory é definido por uma expressão derivada do userID do usuário. Por exemplo, se o uid de um usuário for gerado por uma expressão derivada de seu nome de entidade de usuário, o valor do diretório base desse usuário poderá ser gerado por uma expressão semelhante também derivada do nome principal do usuário. E, dependendo do seu caso de uso, talvez você queira que todos os usuários estejam no mesmo grupo, portanto, atribuiria o gidNumber de uma constante.

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

Adicione um mapeamento que urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword defina uma senha aleatória inicial para o usuário.
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 do usuário do Microsoft Entra tenha os atributos necessários para correspondência.

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

Confirmando usuários via PowerShell

Depois de atualizar os usuários no Microsoft Entra ID, você pode usar os cmdlets do PowerShell do Microsoft Graph para automatizar a verificação de usuários para os atributos necessários.

Por exemplo, suponha que o provisionamento exigiu que os usuários tivessem três atributos DisplayName, surname e extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty. Esse terceiro atributo será 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 não retorna por padrão nenhum dos atributos de extensão de diretório de um usuário, a menos que os atributos sejam especificados na solicitação como uma das propriedades a serem retornadas.

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

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

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

Abra o PowerShell.
Se você ainda não tiver os módulos do PowerShell do Microsoft Graph instalados, instale o módulo Microsoft.Graph.Users e os demais usando este comando:
```
Install-Module Microsoft.Graph
```
Se você já tiver os módulos instalados, verifique se está usando uma versão recente:
```
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
```

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 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 os usuários nesse diretório que estão no escopo de serem usuários da autenticação do Linux. Essa escolha 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 recupere esse subconjunto de usuários do diretório LDAP em um arquivo CSV. Confirme se a saída inclui os atributos dos usuários que serão usados para correspondência com o Microsoft Entra ID. Exemplos desses atributos são ID do funcionário, nome da conta ou uid e endereço de email.
Se necessário, transfira o arquivo CSV que contém a lista de usuários para um sistema que tem os cmdlets do PowerShell do Microsoft Graph instalados.
Agora que você tem uma lista de todos os usuários obtidos do diretório, você poderá fazer 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.

Recuperar as IDs dos usuários no Microsoft Entra ID

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

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

Abra o PowerShell.
Se você ainda não tiver os módulos do PowerShell do Microsoft Graph instalados, instale o módulo Microsoft.Graph.Users e os demais usando este comando:
```
Install-Module Microsoft.Graph
```
Se você já tiver os módulos instalados, verifique se está usando uma versão recente:
```
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
```

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 este comando, talvez seja necessário dar consentimento para que as ferramentas de linha de comando do Microsoft Graph acessem 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 Import-Csv do PowerShell e fornecer o nome do arquivo da seção anterior como argumento.

Por exemplo, se você tiver um arquivo chamado Users-exported-from-sap.csv que foi obtido do SAP Cloud Identity Services e ele estiver localizado no diretório atual, insira este comando.
```
$filename = ".\Users-exported-from-sap.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Nesse outro exemplo: se você estiver usando um banco de dados ou diretório e o arquivo se chamar users.csv e também estiver localizado no diretório atual, insira este comando:
```
$filename = ".\users.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Escolha a coluna do arquivo users.csv que corresponderá a um atributo de um usuário no Microsoft Entra ID.

E se você estiver usando o SAP Cloud Identity Services, o mapeamento padrão será o atributo userName do SAP SCIM com o atributo userPrincipalName do Microsoft Entra ID:
```
$db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"
```
Outro exemplo seria se você estiver usando um banco de dados ou diretório, pode haver usuários em um banco de dados em que o valor na coluna denominada EMail é o mesmo valor do atributo userPrincipalName do Microsoft Entra:
```
$db_match_column_name = "EMail"
$azuread_match_attr_name = "userPrincipalName"
```

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

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

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

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

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

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

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

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

Por exemplo, o endereço de email e o userPrincipalName de alguém podem ter sido alterados no Microsoft Entra ID sem que a propriedade mail correspondente tenha sido atualizada na fonte de dados do aplicativo. Ou talvez o usuário já tenha deixado a organização, mas ainda continue na fonte de dados do aplicativo. Ou pode haver uma conta de fornecedor ou de superadministrador na fonte de dados do aplicativo que não corresponda a nenhuma pessoa específica no Microsoft Entra ID.
Se houver usuários que não foram localizados no Microsoft Entra ID ou que não estavam ativos e prontos para entrar, mas você quer que eles tenham o acesso revisado ou seus atributos atualizados no SAP Cloud Identity Services, no banco de dados ou no diretório, você precisará atualizar o aplicativo ou a regra de correspondência, ou então atualizar ou criar usuários do Microsoft Entra para eles. Para mais informações sobre quais alterações fazer, confira gerenciar mapeamentos e contas de usuário em aplicativos que encontraram correspondência com os usuários no Microsoft Entra ID.

Se você optar por criar usuários no Microsoft Entra ID, poderá criar usuários em massa usando:
- 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 os novos usuários foram preenchidos com os atributos necessários para que o Microsoft Entra ID combine-os posteriormente com os usuários existentes no aplicativo e com os atributos exigidos pelo Microsoft Entra ID, incluindo userPrincipalName, mailNickname e displayName. O userPrincipalName deve ser único entre todos os usuários no diretório.

Por exemplo, é possível ter usuários em um banco de dados em que o valor na coluna EMail é o valor que você quer usar como o nome UPN do Microsoft Entra, o valor na coluna Alias contém o apelido de email do Microsoft Entra ID e o valor na coluna Full name contém o nome de exibição do usuário:
```
$db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"
```
Depois, você pode usar este script para criar usuários do Microsoft Entra para aqueles que estão no SAP Cloud Identity Services, no banco de dados ou no diretório que não correspondem aos usuários no Microsoft Entra ID. Observe que talvez seja necessário modificar esse script para adicionar outros atributos do Microsoft Entra necessários em sua organização ou, se $azuread_match_attr_name não for mailNickname nem userPrincipalName, para fornecer esse atributo do Microsoft Entra.
```
$dbu_missing_columns_list = @()
$dbu_creation_failed_list = @()
foreach ($dbu in $dbu_not_matched_list) {
   if (($null -ne $dbu.$db_display_name_column_name -and $dbu.$db_display_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_user_principal_name_column_name -and $dbu.$db_user_principal_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_mail_nickname_column_name -and $dbu.$db_mail_nickname_column_name.Length -gt 0)) {
      $params = @{
         accountEnabled = $false
         displayName = $dbu.$db_display_name_column_name
         mailNickname = $dbu.$db_mail_nickname_column_name
         userPrincipalName = $dbu.$db_user_principal_name_column_name
         passwordProfile = @{
           Password = -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
         }
      }
      try {
        New-MgUser -BodyParameter $params
      } catch { $dbu_creation_failed_list += $dbu; throw }
   } else {
      $dbu_missing_columns_list += $dbu
   }
}
```

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

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

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

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

Atribuir usuários ao aplicativo no Microsoft Entra ID

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

Importante

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

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

Verifique se o usuário selecionará tem todas as propriedades que serão mapeadas para os atributos necessários do esquema do servidor de diretório.
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 escolha o botão Selecionar.
Selecione Atribuir.

Testar o provisionamento

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

No servidor que executa o host do conector ECMA do Microsoft Entra, clique em Iniciar.
Insira run e depois services.msc na caixa.
Na lista Serviços, verifique se o serviço do Agente de Provisionamento do Microsoft Entra Connect e os serviços do Microsoft ECMA2Host estão em execução. Caso não esteja, selecione Iniciar.
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 Provisionamento.
Após vários segundos, a mensagem Êxito ao criar o usuário no sistema de destino será exibida, com uma lista dos atributos do usuário. Caso apareça um erro, confira a solução de problemas de erros de provisionamento.

Iniciar o provisionamento de usuários

Depois que o teste de provisionamento sob demanda for bem-sucedido, adicione os usuários restantes. Para saber mais sobre como criar atribuições de função de aplicativo em massa usando New-MgServicePrincipalAppRoleAssignedTo, consulte como controlar os usuários existentes de um aplicativo no Microsoft Entra ID.

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

Erros ao solucionar problemas de provisionamento

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

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

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

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

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

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

Verifique se os usuários foram provisionados com êxito

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

As instruções a seguir ilustram como verificar o 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 do Microsoft Entra ID.

Próximas etapas

Para obter detalhes importantes sobre o que faz esse serviço, como ele funciona e as perguntas frequentes, confira Automatizar o provisionamento e o desprovisionamento de usuários para aplicativos SaaS com o Microsoft Entra ID e arquitetura de provisionamento de aplicativos locais.

Compartilhar via

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

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

Pré-requisitos do local

Requisitos de nuvem

Mais recomendações e limitações

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

Instalar e configurar o agente de provisionamento do Microsoft Entra Connect

Configurar o dispositivo ECMA local

Configurar o certificado de host do conector ECMA do Microsoft Entra

Configurar o conector LDAP genérico

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

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

Estenda o esquema do Microsoft Entra

Configurar o mapeamento de atributo

Verifique se os usuários a serem provisionados para o diretório têm 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

Testar o provisionamento

Iniciar o provisionamento de usuários

Erros ao solucionar problemas de provisionamento

Verifique se os usuários foram provisionados com êxito

Próximas etapas

Comentários

Recursos adicionais