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

Artigo
02/13/2024

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

Nota

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 são habilitadas para 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 Entrar 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 ID do Microsoft Entra para provisionar usuários em diretórios LDAP.

Pré-requisitos para provisionar usuários em um diretório LDAP para autenticação 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 no local

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 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 de diretório de destino e com conectividade de saída para login.microsoftonline.com, outros domínios do Microsoft Online Services e do Azure . Um exemplo é uma máquina virtual do Windows Server 2016 hospedada no Azure IaaS ou atrás de um proxy. O .NET Framework 4.7.2 precisa ser instalado nesse servidor.
Opcional: Embora não seja necessário, recomenda-se baixar o Microsoft Edge para Windows Server e usá-lo no local do Internet Explorer.

Requisitos da nuvem

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

O uso desse recurso requer licenças do Microsoft Entra ID P1. Para encontrar a licença certa para os requisitos, consulte Comparar as funcionalidades geralmente disponíveis do Microsoft Entra ID.
A função Administrador de Identidade Híbrida para configurar o agente de provisionamento.
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.
Os usuários do Microsoft Entra a serem provisionados para o diretório LDAP já devem estar preenchidos com os atributos que serão exigidos pelo esquema do servidor de diretório e são específicos para cada usuário. 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 gráfica para saber como criar extensões de diretório adicionais.

Mais recomendações e limitações

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

Não é recomendável usar o mesmo agente para sincronização na nuvem e provisionamento de aplicativos locais. A Microsoft recomenda o uso de um agente separado para sincronização na nuvem e outro para provisionamento de aplicativos locais.
Para o AD LDS atualmente, os usuários não podem ser provisionados com senhas. Portanto, você precisará desabilitar a política de senha para o AD LDS ou provisionar os usuários em um estado desabilitado.
Para outros servidores de diretório, uma senha aleatória inicial pode ser definida, mas não é possível provisionar a senha de um usuário do Microsoft Entra para um servidor de diretório.
Não há suporte para o provisionamento de usuários do LDAP para o ID do Microsoft Entra.
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ê precisará discutir com o operador do servidor de diretório em sua organização como integrar com o servidor de diretório. As informações que você coletará incluem as informações de rede de como se conectar ao servidor de diretório, como o conector deve autenticar-se no servidor de diretório, qual esquema o servidor de diretório selecionou para modelar usuários, o nome distinto base do contexto de nomenclatura e as regras de hierarquia de diretório, como associar usuários no servidor de diretório com usuários no Microsoft Entra ID, e o que deve acontecer quando um usuário sai do escopo no Microsoft Entra ID. A implantação desse conector pode exigir alterações na configuração do servidor de diretório, bem como alterações de configuração no ID do Microsoft Entra. Para implantações que envolvem a integração do Microsoft Entra ID com um servidor de diretório de terceiros em um ambiente de produção, recomendamos que os clientes trabalhem com seu fornecedor de servidor de diretório ou com um parceiro de implantação para obter ajuda, orientação e suporte para essa integração. Este artigo usa os seguintes valores de exemplo para OpenLDAP.

Definição de configuração	Onde o valor é definido	Valor de exemplo
Nome do host do servidor de diretório	Página Conectividade do assistente de configuração	`APP3`
Número da porta do servidor de diretório	Página Conectividade do assistente de configuração	636. Para LDAP sobre SSL ou TLS (LDAPS), use a porta 636. Para `Start TLS`, use a porta 389.
conta para que o conector se identifique no servidor de diretório	Página Conectividade do assistente de configuração	`cn=admin,dc=contoso,dc=lab`
Senha para o conector autenticar-se no servidor de diretório	Página Conectividade do assistente de configuração
Classe de objeto estrutural para um usuário no servidor de diretório	Página Tipos de Objeto do assistente de configuração	`inetOrgPerson`
classes de objeto auxiliares para um usuário no servidor de diretório	Mapeamentos de atributos de página de provisionamento do portal do Azure	`posixAccount` e ainda`shadowAccount`
atributos a serem preenchidos em um novo usuário	Assistente de configuração Página Selecionar atributos e mapeamentos de atributos da página de provisionamento do portal do Azure	`cn`, `gidNumber`, `homeDirectory`, , `mail`, `snobjectClass`, `uid`, `uidNumber`,`userPassword`
Hierarquia de nomenclatura exigida pelo servidor de diretório	Mapeamentos de atributos de página de provisionamento do portal do Azure	Defina o DN de um usuário recém-criado para estar imediatamente abaixo `DC=Contoso,DC=lab`
atributos para correlacionar usuários no Microsoft Entra ID e no servidor de diretório	Mapeamentos de atributos de página de provisionamento do portal do Azure	`mail`
comportamento de desprovisionamento quando um usuário sai do escopo no Microsoft Entra ID	Página de desprovisionamento do assistente de configuração	Excluir o usuário do servidor de diretório

O endereço de rede de um servidor de diretório é um nome de host e um número de porta TCP, normalmente a porta 389 ou 636. Exceto quando o servidor de diretório está colocalizado com o conector no mesmo Windows Server, ou quando você está usando segurança de nível de rede, as conexões de rede do conector para um servidor de diretório precisam ser protegidas usando SSL ou TLS. O conector suporta a conexão a um servidor de diretório na porta 389 e o uso do Start TLS para habilitar o TLS dentro da sessão. O conector também suporta a conexão a um servidor de diretório na porta 636 para LDAPS - LDAP sobre TLS.

Você precisará ter uma conta identificada para que o conector se autentique no servidor de diretório já configurado no servidor de diretório. Esta conta é normalmente identificada com um nome distinto e tem uma palavra-passe ou certificado de cliente associado. Para executar operações de importação e exportação nos objetos no diretório conectado, a conta do conector deve ter permissões suficientes dentro do modelo de controle de acesso do diretório. O conector precisa ter permissões de gravação para poder exportar e permissões de leitura para poder importar. A configuração de permissão é executada dentro das experiências de gerenciamento do próprio diretório de destino.

Um esquema de diretório especifica as classes de objeto e atributos que representam uma entidade do mundo real no diretório. O conector suporta um usuário sendo representado com uma classe de objeto estrutural, como inetOrgPerson, e, opcionalmente, classes de objeto auxiliares adicionais. Para que o conector possa provisionar usuários no servidor de diretório, durante a configuração no portal do Azure, você definirá mapeamentos do esquema do Microsoft Entra para todos os atributos obrigatórios. Isso inclui os atributos obrigatórios da classe de objeto estrutural, quaisquer superclasses dessa classe de objeto estrutural e os atributos obrigatórios de quaisquer classes de objeto auxiliar. Além disso, você provavelmente também configurará mapeamentos para alguns dos atributos opcionais dessas classes. 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 , 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 lidarão 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 é configurado e o Microsoft Entra ID estabeleceu um link entre um usuário no Microsoft Entra ID e um usuário no diretório, seja para um usuário já no diretório ou um novo usuário, o Microsoft Entra ID pode provisionar alterações de atributo do usuário do Microsoft Entra no diretório. Se um usuário atribuído ao aplicativo for excluído no ID do Microsoft Entra, o ID do Microsoft Entra enviará uma operação de exclusão para o servidor de diretório. Você também pode desejar que o Microsoft Entra ID atualize o objeto no servidor de diretório quando um usuário sair do escopo de poder usar o aplicativo. Esse comportamento depende do aplicativo que usará o servidor de diretório, pois muitos diretórios, como OpenLDAP, podem não ter uma maneira padrão de indicar que a conta de um usuário está inativada.

Instalar e configurar o Agente de Provisionamento do Microsoft Entra Connect

Inicie sessão no portal do Azure.
Vá para Aplicativos corporativos e selecione Novo aplicativo.
Pesquise o aplicativo ECMA local, dê um nome ao aplicativo e selecione Criar para adicioná-lo ao seu locatário.
No menu, navegue até a página Provisionamento do 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 & download.

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

Configurar o aplicativo ECMA local

De volta ao portal, na seção Conectividade Local, selecione o agente implantado e 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, 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 do Host do Conector ECMA for iniciada, se esta for a primeira vez que você executa o assistente, ele solicitará que você crie um certificado. Deixe a porta padrão 8585 e selecione Gerar certificado para gerar um certificado. O certificado gerado automaticamente será autoassinado como parte da raiz confiável. A SAN corresponde ao nome do host.
Selecione Guardar.

Nota

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

Configurar 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 segue a imagem e selecione Avançar.

Property	valor
Nome	O nome escolhido para o conector, que deve ser exclusivo em todos os conectores em seu ambiente. Por exemplo, `LDAP`.
Temporizador de sincronização automática (minutos)	120
Token secreto	Introduza o seu token secreto aqui. Deve ter no mínimo 12 caracteres.
Extensão DLL	Para o conector LDAP genérico, selecione Microsoft.IAM.Connector.GenericLdap.dll.

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

Property	Descrição
Host	O nome do host onde o servidor LDAP está localizado. Este exemplo usa `APP3` como nome de host de exemplo.
Porta	O número da porta TCP. Se o servidor de diretório estiver configurado para LDAP sobre SSL, use a porta 636. Para `Start TLS`, ou se estiver a utilizar segurança ao nível da rede, utilize a porta 389.
Limite de Tempo da Ligação	180
Enlace	Esta propriedade especifica como o conector será autenticado no servidor de diretório. Com a `Basic` configuração, ou com a `SSL` configuração ou `TLS` e nenhum certificado de cliente configurado, o conector enviará uma associação simples LDAP para autenticar com um nome distinto e uma senha. Com a `SSL` configuração ou `TLS` e um certificado de cliente especificado, o conector enviará uma associação SASL `EXTERNAL` LDAP para autenticar com um certificado de cliente.
Nome de Utilizador	Como o ECMA Connector se autenticará no servidor de diretório. Neste exemplo, `cn=admin,dc=contoso,dc=lab`
Palavra-passe	A senha do usuário que o ECMA Connector irá autenticar-se no servidor de diretório.
Reino/Domínio	Essa configuração só será necessária se você tiver selecionado `Kerberos` como a opção Vinculação, para fornecer o Realm/Domain do usuário.
Certificado	As configurações nesta seção só são usadas se você selecionou `SSL` ou `TLS` como a opção Vinculação.
Aliases de atributo	A caixa de texto aliases de atributo é usada para atributos definidos no esquema com sintaxe RFC4522. Esses atributos não podem ser detetados durante a deteção de esquema e o conector precisa de ajuda para identificar esses atributos. Por exemplo, se o servidor de diretório não publicar `userCertificate;binary` e você desejar provisionar esse atributo, a seguinte cadeia de caracteres deverá ser inserida na caixa aliases de atributo para identificar corretamente o atributo userCertificate como um atributo binário: `userCertificate;binary`. Se você não precisar de nenhum atributo especial que não esteja no esquema, poderá deixar isso em branco.
Incluir atributos operacionais	Marque a `Include operational attributes in schema` caixa de seleção para incluir também atributos criados pelo servidor de diretório. Isso inclui atributos como quando o objeto foi criado e a hora da última atualização.
Incluir atributos extensíveis	Marque a caixa de `Include extensible attributes in schema` seleção se objetos extensíveis (RFC4512/4.3) forem usados no servidor de diretório. Habilitar essa opção permite que todos os atributos sejam usados em todos os objetos. Selecionar essa opção torna o esquema muito grande, portanto, a menos que o diretório conectado esteja usando esse recurso, a recomendação é manter a opção desmarcada.
Permitir a seleção manual de âncoras	deixe esta opção desselecionada.

Nota

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

Property	Description
Mecanismos SASL suportados	A seção superior mostra informações fornecidas pelo próprio servidor, incluindo a lista de mecanismos SASL.
Detalhes do certificado do servidor	Se `SSL` ou `TLS` foi especificado, o assistente exibirá o certificado retornado pelo servidor de diretório. Confirme se o emissor, o assunto e a impressão digital são para o servidor de diretório correto.
Recursos obrigatórios encontrados	O conector também verifica se os controles obrigatórios estão presentes no DSE raiz. Se esses controles não estiverem listados, um aviso será exibido. Alguns diretórios LDAP não listam todos os recursos no DSE raiz e é possível que o conector funcione sem problemas, mesmo que um aviso esteja presente.
Controles suportados	As caixas de seleção de controles suportados controlam o comportamento de determinadas operações
Importação Delta	O DN do log de alterações é o contexto de nomenclatura usado pelo log de alterações delta, por exemplo , cn=changelog. Esse valor deve ser especificado para poder fazer a importação delta. Se você não precisar implementar a importação delta, esse campo poderá ficar em branco.
Atributo de senha	Se o servidor de diretório oferecer suporte a um atributo de senha diferente ou hash de senha, você poderá especificar o destino para alterações de senha.
Nomes de partições	Na lista de partições adicionais, é possível adicionar namespaces adicionais não detetados automaticamente. Por exemplo, essa configuração pode ser usada se vários servidores comporem um cluster lógico, que deve ser importado ao mesmo tempo. Assim como o Ative Directory pode ter vários domínios em uma floresta, mas todos os domínios compartilham um esquema, o mesmo pode ser simulado inserindo os namespaces adicionais nesta caixa. Cada namespace pode importar de servidores diferentes e é configurado na página Configurar partições e hierarquias .

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 marcadas. Em seguida, selecione Seguinte.

Property	Description
Exportar	Execute o perfil que exportará dados para o servidor de diretório LDAP. Este perfil de execução é necessário.
Importação total	Execute o perfil que importará todos os dados de fontes LDAP especificadas anteriormente. Este perfil de execução é necessário.
Importação Delta	Execute o perfil que importará apenas as alterações do LDAP desde a última importação completa ou delta. Habilite esse perfil de execução somente se você tiver confirmado que o servidor de diretório atende aos requisitos necessários. Para obter mais informações, consulte a referência do conector LDAP genérico.

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 houver, deixe os padrões inalterados e clique em Avançar.

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

Property	Description
Objeto de destino	Esse valor é a classe de objeto estrutural de um usuário no servidor de diretório LDAP. 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 consultará o host do conector ECMA usando esse atributo após o ciclo inicial. Normalmente, use o nome distinto, que pode ser selecionado como `-dn-`. Atributos de vários valores, como o `uid` atributo no esquema OpenLDAP, não podem ser usados como âncoras.
Atributo de consulta	Esse atributo deve ser o mesmo que a Âncora.
DN	O distinguishedName do objeto de destino. Manter `-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 Microsoft Entra ID.
A lista suspensa Atributo mostra qualquer atributo que foi descoberto no diretório de destino e não foi escolhido no uso anterior da página Selecionar Atributos do assistente de configuração.

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

Configure a visibilidade para os seguintes atributos.

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

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

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

Nota

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

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 Executar , se necessário, e digite services.msc na caixa.
Na lista Serviços, verifique se o 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 para 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 como 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 -Port argumento. Quando solicitado, digite o token secreto configurado para esse conector.
```
PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> $cout = .\TestECMA2HostConnection.ps1 -ConnectorName LDAP -ObjectTypePath cache; $cout.length -gt 9
Supply values for the following parameters:
SecretToken: ************
```
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á contém um ou mais usuários, mas o script exibido False, esse status indica que o conector não pôde ler do servidor de diretório. Se você tentar provisionar, o Microsoft Entra ID pode não corresponder corretamente os usuários nesse diretório de origem com os usuários no Microsoft Entra ID. Aguarde alguns minutos para que o host do conector termine de ler objetos do servidor de diretório existente e execute novamente o script. Se a saída continuar a ser False, verifique a configuração do seu conector e as permissões no servidor de diretório estão permitindo que o conector leia os usuários existentes.

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

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

Nota

Se a janela tiver expirado, você precisará selecionar novamente o agente.
1. Inicie sessão no portal do Azure.
2. Vá para Aplicativos corporativos e o aplicativo ECMA local.
3. Clique em Provisionamento.
4. Se Introdução for exibido, altere o modo para Automático, na seção Conectividade Local , selecione o agente que você acabou de implantar e selecione Atribuir Agente(s) e aguarde 10 minutos. Caso contrário, vá para Editar provisionamento.
Na secção Credenciais de administrador, introduza o seguinte URL. Substitua a connectorName parte pelo nome do conector no host ECMA, como LDAP. Se você forneceu um certificado de sua autoridade de certificação para o host ECMA, substitua localhost pelo nome do host do servidor onde o host ECMA está instalado.

Property valor

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

Nota

Se você acabou de atribuir o agente para o aplicativo, aguarde 10 minutos para que o registro seja concluído. O teste de conectividade não funcionará até que o registro seja concluído. Forçar a conclusão do registro do agente reiniciando o agente de provisionamento no servidor pode acelerar o processo de registro. Vá para o servidor, procure serviços na barra de pesquisa do Windows, identifique o serviço Microsoft Entra Connect Provisioning Agent , clique com o botão direito do mouse no serviço e reinicie.
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 a habilitar o provisionamento, selecione Salvar.

Property	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, 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 para configurar que o atributo deve ser sincronizado dos Serviços de Domínio Ative Directory para o ID do Microsoft Entra, para que esteja disponível para provisionamento em outros sistemas.

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

Configurar mapeamento de atributos

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

No centro de administração do Microsoft Entra, em Aplicativos corporativos, 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 esta for a primeira vez que você configurou os mapeamentos de atributos para este aplicativo, haverá apenas um mapeamento presente, para um espaço reservado.
Para confirmar se o esquema do servidor de diretório está disponível no Microsoft Entra ID, marque a caixa de seleção Mostrar opções avançadas e selecione Editar lista de atributos para ScimOnPremises. Certifique-se de que todos os atributos selecionados no assistente de configuração estejam listados. Caso contrário, aguarde alguns minutos até que o esquema seja atualizado, selecione Mapeamento de Atributos na linha de navegação e, em seguida, selecione Editar lista de atributos para ScimOnPremises novamente para recarregar a página. Depois de ver os atributos listados, cancele esta página para retornar à lista de mapeamentos.
Cada usuário em um diretório deve ter um nome distinto exclusivo. Você pode especificar como o conector deve construir um nome distinto usando um mapeamento de atributo. Selecione Adicionar novo mapeamento. Use os valores abaixo 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 objectClass atributo, adicione um mapeamento a esse atributo. Para adicionar um mapeamento para objectClasso , 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 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 seu servidor de diretório, selecione Adicionar Novo Mapeamento e especifique os atributos de origem e destino. Se você estiver provisionando em um diretório existente com usuários existentes, precisará editar o mapeamento para o atributo que está em comum para definir os objetos Match usando esse atributo para esse atributo. Saiba mais sobre o mapeamento de atributos aqui.

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

Tipo de mapeamento	Atributo Source	Atributo de destino
Direct	`displayName`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:cn`
Direct	`surname`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:sn`
Direct	`userPrincipalName`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:mail`
Expression	`ToLower(Word([userPrincipalName], 1, "@"), )`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uid`
Direct	(atributo específico para o seu diretório)	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uidNumber`
Expression	`Join("/", "/home", ToLower(Word([userPrincipalName], 1, "@"), ))`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:homeDirectory`
Constante	`10000`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:gidNumber`

Adicione um mapeamento para urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword que defina uma senha aleatória inicial para o usuário.
Selecione Guardar.

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 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 único uid e um único uidNumber.

Confirmando usuários via PowerShell

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

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

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

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

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

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

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 serão usados para correspondência com o Microsoft Entra ID. Exemplos desses atributos são ID do funcionário, nome da conta ou uide 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 do 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 a correspondência de usuários nos sistemas de origem e de destino.

Recuperar as IDs dos usuários no Microsoft Entra ID

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

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

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

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 Import-Csv do PowerShell e fornecer o nome do arquivo da seção anterior como argumento.

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

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

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

O script PowerShell a seguir usa os $dbusersvalores , $db_match_column_namee $azuread_match_attr_name especificados anteriormente. Ele consultará o ID do Microsoft Entra para localizar um usuário que tenha um atributo com um valor correspondente para cada registro no arquivo de origem. Se houver muitos usuários no arquivo obtido do banco de dados ou diretório de origem do SAP Cloud Identity Services, esse script pode levar vários minutos para ser concluído. Se você não tiver um atributo no Microsoft Entra ID que tenha o valor e precisar usar uma contains ou outra expressão de filtro, será necessário personalizar esse script e isso na etapa 11 abaixo para usar uma expressão de filtro diferente.

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

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

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

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

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

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

Por exemplo, o endereço de email de alguém e userPrincipalName podem ter sido alterados no ID do Microsoft Entra sem que sua propriedade correspondente mail tenha sido atualizada na fonte de dados do aplicativo. Ou, o usuário pode já ter saído da organização, mas ainda está na fonte de dados do aplicativo. Ou pode haver uma conta de fornecedor ou superadministrador na fonte de dados do aplicativo que não corresponda a nenhuma pessoa específica no Microsoft Entra ID.
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 arquivo CSV, conforme descrito em Criar usuários em massa 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 único entre todos os usuários no diretório.

Por exemplo, você pode ter usuários em um banco de dados onde o valor na coluna nomeada EMail é o valor que você deseja usar como o Nome principal do usuário do Microsoft Entra, o valor na coluna Alias contém o apelido de email do ID do Microsoft Entra e o valor na coluna Full name contém o nome para exibição do usuário:
```
$db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"
```
Em seguida, você pode usar esse script para criar usuários do Microsoft Entra para aqueles no SAP Cloud Identity Services, o banco de dados ou o diretório que não corresponderam aos usuários no Microsoft Entra ID. Observe que talvez seja necessário modificar esse script para adicionar atributos adicionais do Microsoft Entra necessários em sua organização, ou se o $azuread_match_attr_name não for nem mailNicknameuserPrincipalName, 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-MgServicePrincipalAppRoleAssignedToo , 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 Aplicativos corporativos.
Selecione o aplicativo ECMA local.
À esquerda, em Gerir, selecione Utilizadores 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 que executa o Microsoft Entra ECMA Connector Host, selecione Iniciar.
Digite executar e digite services.msc na caixa.
Na lista Serviços, verifique se o serviço Microsoft Entra Connect Provisioning Agent e os serviços Microsoft ECMA2Host estão em execução. Caso contrário, selecione Iniciar.
No portal do Azure, selecione Aplicativos corporativos.
Selecione o aplicativo ECMA local.
À esquerda, selecione Provisionamento.
Selecione Provisão sob demanda.
Procure um dos seus usuários de teste e selecione Provisionar.
Após alguns segundos, aparecerá a mensagem Usuário criado com êxito no sistema de destino, com uma lista dos atributos do usuário. Se, em vez disso, aparecer um erro, consulte Solução de problemas de erros de provisionamento.

Comece a provisionar usuários

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

No portal do Azure, selecione o aplicativo.
À esquerda, em Gerir, selecione Utilizadores 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 usuários e grupos atribuídos, ative o status de provisionamento e selecione Salvar.
Aguarde alguns minutos para que o provisionamento seja iniciado. Pode demorar até 40 minutos. Após a conclusão do trabalho de provisionamento, conforme descrito na próxima seção,

Solução de problemas de erros de provisionamento

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

Se a mensagem de erro for Falha ao criar usuário, verifique os atributos mostrados em relação aos requisitos do esquema de diretório.

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

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

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

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

Verifique se os usuários foram provisionados com êxito

Depois de aguardar, verifique o servidor de diretório para garantir que os usuários estejam sendo provisionados. A consulta que você executar ao servidor de diretório dependerá dos comandos fornecidos pelo servidor de diretório.

As instruções a seguir ilustram como verificar o 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 funciona e perguntas frequentes, consulte Automatizar o provisionamento e o desprovisionamento de usuários para aplicativos SaaS com o Microsoft Entra ID e a arquitetura de provisionamento de aplicativos locais.

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 no local

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