Configurazione dell'ID Microsoft Entra per effettuare il provisioning degli utenti in una directory LDAP per l'autenticazione Linux

Articolo
02/13/2024

La documentazione seguente è un'esercitazione che illustra come gestire l'accesso a un sistema Linux. Questa operazione viene implementata dal provisioning degli utenti di Microsoft Entra in una directory LDAP locale considerata attendibile dal sistema Linux, in modo che tali utenti possano successivamente accedere a un sistema Linux che si basa su tale directory LDAP per l'autenticazione utente. E quando un utente viene rimosso da Microsoft Entra ID, successivamente non è più in grado di accedere a un sistema Linux.

Nota

Lo scenario descritto in questo articolo è applicabile solo ai sistemi Linux esistenti che si basano già su un modulo LDAP NSS (Name Services Switch) o Pluggable Authentication Modules (PAM) per l'identificazione e l'autenticazione dell'utente. Le macchine virtuali Linux in Azure o abilitate per Azure Arc devono essere integrate con l'autenticazione Microsoft Entra. È ora possibile usare Microsoft Entra ID come piattaforma di autenticazione principale e un'autorità di certificazione per ssh in una macchina virtuale Linux usando l'ID Microsoft Entra e l'autenticazione basata su certificati OpenSSH, come descritto in Accedere a una macchina virtuale Linux in Azure usando Microsoft Entra ID e OpenSSH.

Per altri scenari che coinvolgono il provisioning degli utenti in directory LDAP diverse dall'autenticazione Linux, vedere Configurazione di Microsoft Entra ID per il provisioning degli utenti nelle directory LDAP.

Prerequisiti per il provisioning degli utenti in una directory LDAP per l'autenticazione Linux

Questo articolo presuppone che il server LDAP sia già presente nell'ambiente locale, usato da uno o più sistemi Linux o altri sistemi POSIX per l'autenticazione utente.

Diagramma che mostra l'architettura per il provisioning locale da Microsoft Entra ID a un server di directory LDAP.

On-premises prerequisites (Prerequisiti locali)

Un server Linux o un altro server POSIX che risponde su un server di directory usando un modulo PAM o NSS.
Un server di directory LDAP che supporta lo schema POSIX, ad esempio OpenLDAP, in cui gli utenti possono essere creati, aggiornati ed eliminati. Per altre informazioni sui server di directory supportati, vedere informazioni di riferimento sul connettore LDAP generico.
Un computer con almeno 3 GB di RAM per ospitare un agente di provisioning. Il computer deve avere Windows Server 2016 o una versione successiva di Windows Server, con connettività al server directory di destinazione e con connettività in uscita a login.microsoftonline.com, altri microsoft Online Services e domini di Azure . Un esempio è una macchina virtuale Windows Server 2016 ospitata in Azure IaaS o dietro un proxy. .NET Framework 4.7.2 deve essere installato in tale server.
Facoltativo: anche se non è obbligatorio, è consigliabile scaricare Microsoft Edge per Windows Server e usarlo sul posto di Internet Explorer.

Requisiti cloud

Tenant di Microsoft Entra con ID Microsoft Entra P1 o Premium P2 (o EMS E3 o E5).

L'uso di questa funzionalità richiede licenze microsoft Entra ID P1. Per trovare la licenza corretta per le proprie esigenze, vedere il confronto delle funzionalità di Microsoft Entra ID disponibili a livello generale.
Ruolo Di amministratore delle identità ibride per la configurazione dell'agente di provisioning.
I ruoli Amministratore applicazione o Amministratore applicazioni cloud per la configurazione del provisioning nell'interfaccia di amministrazione di portale di Azure o Microsoft Entra.
Gli utenti di Microsoft Entra di cui eseguire il provisioning nella directory LDAP devono essere già popolati con gli attributi che saranno richiesti dallo schema del server di directory e sono specifici per ogni utente. In particolare, ogni utente deve avere un numero univoco come numero ID utente. Prima di distribuire l'agente di provisioning e assegnare gli utenti alla directory, è necessario generare tale numero da un attributo esistente nell'utente oppure estendere lo schema di Microsoft Entra e popolare tale attributo negli utenti nell'ambito. Vedere Estendibilità di Graph per informazioni su come creare estensioni di directory aggiuntive.

Altre raccomandazioni e limitazioni

I punti elenco seguenti sono più raccomandazioni e limitazioni.

Non è consigliabile usare lo stesso agente per la sincronizzazione cloud e il provisioning di app locali. Microsoft consiglia di usare un agente separato per la sincronizzazione cloud e uno per il provisioning di app locali.
Per AD LDS, attualmente non è possibile effettuare il provisioning degli utenti con password. Sarà quindi necessario disabilitare i criteri password per AD LDS o effettuare il provisioning degli utenti in uno stato disabilitato.
Per altri server di directory, è possibile impostare una password casuale iniziale, ma non è possibile effettuare il provisioning della password di un utente di Microsoft Entra in un server di directory.
Il provisioning degli utenti da LDAP a Microsoft Entra ID non è supportato.
Il provisioning di gruppi e appartenenze utente a un server directory non è supportato.

Determinare l'interazione del connettore LDAP di Microsoft Entra con il server di directory

Prima di distribuire il connettore in un server di directory esistente, è necessario discutere con l'operatore del server directory nell'organizzazione come eseguire l'integrazione con il server di directory. Le informazioni raccolte includono le informazioni di rete su come connettersi al server directory, come il connettore deve autenticarsi al server di directory, quale schema il server di directory ha selezionato per modellare gli utenti, le regole di base di nome e gerarchia di directory del contesto di denominazione, come associare gli utenti nel server directory agli utenti in Microsoft Entra ID, e cosa dovrebbe accadere quando un utente esce dall'ambito in Microsoft Entra ID. La distribuzione di questo connettore può richiedere modifiche alla configurazione del server di directory, nonché modifiche alla configurazione apportate all'ID Microsoft Entra. Per le distribuzioni che coinvolgono l'integrazione di Microsoft Entra ID con un server directory di terze parti in un ambiente di produzione, è consigliabile che i clienti lavorino con il fornitore del server directory o un partner di distribuzione per assistenza, indicazioni e supporto per questa integrazione. Questo articolo usa i valori di esempio seguenti per OpenLDAP.

Impostazione di configurazione	Posizione in cui è impostato il valore	Valore di esempio
hostname del server di directory	Pagina Connettività della procedura guidata di configurazione	`APP3`
numero di porta del server directory	Pagina Connettività della procedura guidata di configurazione	636. Per LDAP su SSL o TLS (LDAPS), usare la porta 636. Per `Start TLS`usare la porta 389.
account per il connettore per identificarsi con il server di directory	Pagina Connettività della procedura guidata di configurazione	`cn=admin,dc=contoso,dc=lab`
password per il connettore per l'autenticazione al server di directory	Pagina Connettività della procedura guidata di configurazione
classe di oggetti strutturali per un utente nel server di directory	Pagina Tipi di oggetti della procedura guidata di configurazione	`inetOrgPerson`
classi di oggetti ausiliari per un utente nel server directory	mapping degli attributi della pagina di provisioning portale di Azure	`posixAccount` e`shadowAccount`
attributi da popolare in un nuovo utente	Configurazione guidata Selezione attributi pagina e mapping degli attributi della pagina di provisioning portale di Azure	`cn`, `gidNumber`, `homeDirectory`, `mail`, `objectClasssn`, `uid`, , `uidNumberuserPassword`
gerarchia di denominazione richiesta dal server di directory	mapping degli attributi della pagina di provisioning portale di Azure	Impostare il DN di un utente appena creato in modo che sia immediatamente seguente `DC=Contoso,DC=lab`
attributi per correlare gli utenti tra Microsoft Entra ID e il server di directory	mapping degli attributi della pagina di provisioning portale di Azure	`mail`
comportamento di deprovisioning quando un utente esce dall'ambito in Microsoft Entra ID	Pagina di deprovisioning della procedura guidata di configurazione	Eliminare l'utente dal server di directory

L'indirizzo di rete di un server di directory è un nome host e un numero di porta TCP, in genere la porta 389 o 636. Tranne quando il server di directory si trova in modalità condivisa con il connettore nello stesso Server Windows o si usa la sicurezza a livello di rete, le connessioni di rete dal connettore a un server di directory devono essere protette tramite SSL o TLS. Il connettore supporta la connessione a un server di directory sulla porta 389 e l'uso di Start TLS per abilitare TLS all'interno della sessione. Il connettore supporta anche la connessione a un server di directory sulla porta 636 per LDAPS - LDAP tramite TLS.

Sarà necessario disporre di un account identificato per consentire al connettore di eseguire l'autenticazione al server di directory già configurato nel server di directory. Questo account viene in genere identificato con un nome distinto e ha una password o un certificato client associato. Per eseguire operazioni di importazione ed esportazione sugli oggetti nella directory connessa, l'account connettore deve disporre di autorizzazioni sufficienti all'interno del modello di controllo di accesso della directory. Il connettore deve disporre delle autorizzazioni di scrittura per poter esportare e leggere le autorizzazioni per poter eseguire l'importazione. La configurazione delle autorizzazioni viene eseguita nelle esperienze di gestione della directory di destinazione stessa.

Uno schema di directory specifica le classi e gli attributi dell'oggetto che rappresentano un'entità reale nella directory. Il connettore supporta un utente rappresentato con una classe di oggetti strutturali, ad esempio inetOrgPerson, e facoltativamente classi di oggetti ausiliari aggiuntive. Affinché il connettore sia in grado di effettuare il provisioning degli utenti nel server directory, durante la configurazione nel portale di Azure verranno definiti i mapping dallo schema di Microsoft Entra a tutti gli attributi obbligatori. Sono inclusi gli attributi obbligatori della classe oggetto strutturale, qualsiasi superclasse di tale classe oggetto strutturale e gli attributi obbligatori di qualsiasi classe di oggetti ausiliari. Inoltre, è probabile che si configurino anche i mapping ad alcuni degli attributi facoltativi di queste classi. Un server di directory OpenLDAP con lo schema POSIX per supportare l'autenticazione Linux potrebbe richiedere a un nuovo utente di avere attributi come l'esempio seguente.

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

Le regole della gerarchia di directory implementate da un server di directory descrivono il modo in cui gli oggetti per ogni utente si riferiscono l'uno all'altro e agli oggetti esistenti nella directory. Nella maggior parte delle distribuzioni, l'organizzazione ha scelto di avere una gerarchia flat nel server di directory, in cui ogni oggetto per un utente si trova immediatamente sotto un oggetto di base comune. Ad esempio, se il nome distinto di base per il contesto di denominazione in un server di directory è dc=contoso,dc=com un nuovo utente avrà un nome distinto come cn=alice,dc=contoso,dc=com. Tuttavia, alcune organizzazioni potrebbero avere una gerarchia di directory più complessa, nel qual caso sarà necessario implementare le regole quando si specifica il mapping dei nomi distinto per il connettore. Ad esempio, un server di directory potrebbe prevedere che gli utenti si trovano in unità organizzative per reparto, quindi un nuovo utente avrà un nome distinto come cn=alice,ou=London,dc=contoso,dc=com. Poiché il connettore non crea oggetti intermedi per le unità organizzative, gli oggetti intermedi previsti dalla gerarchia delle regole del server directory devono esistere già nel server di directory.

Successivamente, è necessario definire le regole per il modo in cui il connettore deve determinare se è già presente un utente nel server di directory corrispondente a un utente di Microsoft Entra. Ogni directory LDAP ha un nome distinto univoco per ogni oggetto nel server di directory, tuttavia tale nome distinto non è spesso presente per gli utenti in Microsoft Entra ID. In alternativa, un'organizzazione può avere un attributo diverso, ad esempio mail o employeeId, nello schema del server di directory presente anche nei propri utenti in Microsoft Entra ID. Quindi, quando il connettore esegue il provisioning di un nuovo utente in un server di directory, il connettore può cercare se esiste già un utente in tale directory con un valore specifico di tale attributo e creare un nuovo utente nel server directory solo se non è presente.

Se lo scenario prevede la creazione di nuovi utenti nella directory LDAP, non solo l'aggiornamento o l'eliminazione di utenti esistenti, sarà necessario determinare anche come i sistemi Linux che usano tale server di directory gestiranno l'autenticazione. Alcuni sistemi possono eseguire query sulla chiave pubblica o sul certificato SSH di un utente dalla directory, che potrebbe essere appropriato per gli utenti che contengono già le credenziali di tali moduli. Tuttavia, se l'applicazione che si basa sul server directory non supporta protocolli di autenticazione moderni o credenziali più avanzate, sarà necessario impostare una password specifica dell'applicazione durante la creazione di un nuovo utente nella directory, poiché Microsoft Entra ID non supporta il provisioning della password di microsoft Entra di un utente.

Infine, è necessario concordare il comportamento di deprovisioning. Quando il connettore è configurato e Microsoft Entra ID ha stabilito un collegamento tra un utente in Microsoft Entra ID e un utente nella directory, per un utente già nella directory o un nuovo utente, microsoft Entra ID può effettuare il provisioning delle modifiche dell'attributo dall'utente di Microsoft Entra nella directory. Se un utente assegnato all'applicazione viene eliminato in Microsoft Entra ID, Microsoft Entra ID invierà un'operazione di eliminazione al server di directory. È anche possibile che microsoft Entra ID aggiorni l'oggetto nel server directory quando un utente esce dall'ambito di essere in grado di usare l'applicazione. Questo comportamento dipende dall'applicazione che usa il server di directory, come molte directory, ad esempio OpenLDAP, potrebbe non avere un modo predefinito per indicare che l'account di un utente è inattivato.

Installare e configurare Microsoft Entra Connect Provisioning Agent

Accedere al portale di Azure.
Passare ad Applicazioni aziendali e selezionare Nuova applicazione.
Cercare l'applicazione dell'app ECMA locale, assegnare un nome all'app e selezionare Crea per aggiungerla al tenant.
Dal menu passare alla pagina Provisioning dell'applicazione.
Seleziona Inizia.
Nella pagina Provisioning impostare la modalità su Automatico.

In Connettività locale selezionare Scarica e installa e selezionare Accetta termini e download.

Lasciare il portale ed eseguire il programma di installazione dell'agente di provisioning, accettare le condizioni per il servizio e selezionare Installa.
Attendere la configurazione guidata dell'agente di provisioning di Microsoft Entra e quindi selezionare Avanti.
Nel passaggio Seleziona estensione selezionare Provisioning di applicazioni locali e quindi selezionare Avanti.
L'agente di provisioning userà il Web browser del sistema operativo per visualizzare una finestra popup per l'autenticazione con Microsoft Entra ID e potenzialmente anche il provider di identità dell'organizzazione. Se si usa Internet Explorer come browser in Windows Server, potrebbe essere necessario aggiungere siti Web Microsoft all'elenco di siti attendibili del browser per consentire l'esecuzione corretta di JavaScript.
Specificare le credenziali per un amministratore di Microsoft Entra quando viene richiesto di autorizzare. L'utente deve avere almeno il ruolo di amministratore delle identità ibride.
Selezionare Conferma per confermare l'impostazione. Al termine dell'installazione, è possibile selezionare Esci e chiudere anche il programma di installazione del pacchetto dell'agente di provisioning.

Configurare l'app ECMA locale

Nella sezione Connettività locale del portale selezionare l'agente distribuito e selezionare Assegna agenti.
Mantenere aperta questa finestra del browser, mentre si completa il passaggio successivo della configurazione usando la configurazione guidata.

Configurare il certificato host del connettore Microsoft Entra ECMA

In Windows Server in cui è installato l'agente di provisioning fare clic con il pulsante destro del mouse sulla Configurazione guidata Microsoft ECMA2Host dal menu Start ed eseguire come amministratore. L'esecuzione come amministratore di Windows è necessaria per la procedura guidata per creare i registri eventi di Windows necessari.
Dopo l'avvio della configurazione host del connettore ECMA, se è la prima volta che si esegue la procedura guidata, verrà chiesto di creare un certificato. Lasciare la porta predefinita 8585 e selezionare Genera certificato per generare un certificato. Il certificato generato automaticamente verrà autofirmato come parte della radice attendibile. La san corrisponde al nome host.
Seleziona Salva.

Nota

Se si è scelto di generare un nuovo certificato, registrare la data di scadenza del certificato per assicurarsi di tornare alla configurazione guidata e generare nuovamente il certificato prima della scadenza.

Configurare il connettore LDAP generico

A seconda delle opzioni selezionate, alcune schermate della procedura guidata potrebbero non essere disponibili e le informazioni potrebbero essere leggermente diverse. Usare le informazioni seguenti per guidare l'utente nella configurazione.

Generare un token segreto che verrà usato per l'autenticazione dell'ID Microsoft Entra nel connettore. Deve contenere almeno 12 caratteri e univoci per ogni applicazione. Se non si dispone già di un generatore di segreti, è possibile usare un comando di PowerShell come il seguente per generare una stringa casuale di esempio.
```
-join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
```
Se non è già stato fatto, avviare la Configurazione guidata Microsoft ECMA2Host dal menu Start.
Selezionare Nuovo connettore.

Nella pagina Proprietà compilare le caselle con i valori specificati nella tabella che segue l'immagine e selezionare Avanti.

Proprietà	valore
Nome	Nome scelto per il connettore, che deve essere univoco in tutti i connettori nell'ambiente. Ad esempio: `LDAP`.
Timer asincrono automatico (minuti)	120
Token segreto	Immettere il token segreto qui. Deve contenere almeno 12 caratteri.
DLL di estensione	Per il connettore LDAP generico selezionare Microsoft.IAM.Connector.GenericLdap.dll.

Nella pagina Connettività verrà configurato il modo in cui l'host del connettore ECMA comunicherà con il server di directory e si impostano alcune delle opzioni di configurazione. Compilare le caselle con i valori specificati nella tabella che segue l'immagine e selezionare Avanti. Quando si seleziona Avanti, il connettore eseguirà una query sul server di directory per la relativa configurazione.

Proprietà	Descrizione
Host	Nome host in cui si trova il server LDAP. Questo esempio usa `APP3` come nome host di esempio.
Porta	Numero di porta TCP. Se il server di directory è configurato per LDAP tramite SSL, usare la porta 636. Per `Start TLS`o se si usa la sicurezza a livello di rete, usare la porta 389.
Timeout di connessione	180
Binding	Questa proprietà specifica il modo in cui il connettore eseguirà l'autenticazione nel server di directory. Con l'impostazione o con l'impostazione `Basic` `SSL` o `TLS` e nessun certificato client configurato, il connettore invierà un binding LDAP semplice per l'autenticazione con un nome distinto e una password. Con l'impostazione `SSL` o `TLS` e un certificato client specificato, il connettore invierà un binding SASL `EXTERNAL` LDAP per l'autenticazione con un certificato client.
Nome utente	Modalità di autenticazione del connettore ECMA nel server di directory. In questo esempio, `cn=admin,dc=contoso,dc=lab`
Password	Password dell'utente che il connettore ECMA eseguirà l'autenticazione al server di directory.
Area di autenticazione/dominio	Questa impostazione è necessaria solo se è stata selezionata `Kerberos` l'opzione Binding per fornire l'area di autenticazione/dominio dell'utente.
Certificate	Le impostazioni in questa sezione vengono usate solo se è stata selezionata `SSL` o `TLS` come opzione Binding.
Alias degli attributi	La casella di testo Attribute Aliases viene usata per gli attributi definiti nello schema con la sintassi RFC4522. Questi attributi non possono essere rilevati durante il rilevamento dello schema e il connettore deve essere utile per identificare tali attributi. Ad esempio, se il server di directory non viene pubblicato `userCertificate;binary` e si vuole effettuare il provisioning di tale attributo, è necessario immettere la stringa seguente nella casella alias dell'attributo per identificare correttamente l'attributo userCertificate come attributo binario: `userCertificate;binary`. Se non sono necessari attributi speciali non presenti nello schema, è possibile lasciare vuoto questo valore.
Includere gli attributi operativi	Selezionare la `Include operational attributes in schema` casella di controllo per includere anche gli attributi creati dal server di directory. Sono d esempio inclusi gli attributi relativi all'ora di creazione e dell'ultimo aggiornamento dell'oggetto.
Includere attributi estendibili	Selezionare la `Include extensible attributes in schema` casella di controllo se nel server directory vengono usati oggetti estendibili (RFC4512/4.3). L'abilitazione di questa opzione consente l'uso di ogni attributo in tutti gli oggetti. Se si seleziona questa opzione, le dimensioni dello schema diventano molto estese, quindi a meno che la directory connessa non usi questa funzionalità, è consigliabile lasciare deselezionata l'opzione.
Consenti selezione dell'ancoraggio manuale	lasciare la casella deselezionata.

Nota

Se si verifica un problema durante il tentativo di connessione e non è possibile passare alla pagina Globale , assicurarsi che l'account del servizio nel server directory sia abilitato.

Nella pagina Globale si configurerà il nome distinto del log delle modifiche differenziali, se necessario, e funzionalità LDAP aggiuntive. La pagina è già popolata con le informazioni fornite dal server LDAP. Esaminare i valori visualizzati e quindi selezionare Avanti.

Proprietà	Descrizione
Meccanismi SASL supportati	La sezione superiore mostra le informazioni fornite dal server stesso, incluso l'elenco dei meccanismi SASL.
Dettagli certificato server	Se `SSL` o `TLS` è stato specificato, la procedura guidata visualizzerà il certificato restituito dal server di directory. Verificare che l'autorità emittente, l'oggetto e l'identificazione personale siano per il server di directory corretto.
Funzionalità obbligatorie trovate	Il connettore verifica inoltre che i controlli obbligatori siano presenti nell'ambiente di dominio radice. Se questi controlli non sono elencati, viene visualizzato un avviso. Alcune directory LDAP non elencano tutte le funzionalità di Root DSE ed è possibile che il connettore funzioni senza problemi anche se è presente un avviso.
Controlli supportati	Le caselle di controllo controlli supportati controllano il comportamento per determinate operazioni
Importazione delta	Il DN del log delle modifiche è il contesto dei nomi usato dal log delle modifiche differenziali, ad esempio cn=changelog. Questo valore deve essere specificato per poter eseguire l'importazione differenziale. Se non è necessario implementare l'importazione differenziale, questo campo può essere vuoto.
Attributo Password	Se il server directory supporta un attributo o un hash delle password diverso, è possibile specificare la destinazione per le modifiche della password.
Nomi delle partizioni	Nell'elenco delle partizioni aggiuntive è possibile aggiungere altri spazi dei nomi non rilevati automaticamente. Questa impostazione può essere ad esempio usata se diversi server costituiscono un cluster logico e devono quindi essere importati contemporaneamente. Così come Active Directory può includere più domini in una foresta, ma tutti i domini condividono uno schema, lo stesso approccio può essere simulato immettendo gli spazi dei nomi aggiuntivi in questa casella. Ogni spazio dei nomi può importare da server diversi ed è ulteriormente configurato nella pagina Configura partizioni e gerarchie .

Nella pagina Partizioni mantenere l'impostazione predefinita e selezionare Avanti.

Nella pagina Run Profiles (Esegui profili) verificare che la casella di controllo Export (Esporta) e la casella di controllo Full import (Importazione completa) siano entrambe selezionate. Quindi seleziona Avanti.

Proprietà	Descrizione
Esportazione	Eseguire il profilo che esportare i dati nel server di directory LDAP. Questo profilo di esecuzione è obbligatorio.
Importazione completa	Profilo di esecuzione che importerà tutti i dati dalle origini LDAP specificate in precedenza. Questo profilo di esecuzione è obbligatorio.
Importazione delta	Profilo di esecuzione che importerà solo le modifiche da LDAP dall'ultima importazione completa o differenziale. Abilitare questo profilo di esecuzione solo se si è verificato che il server di directory soddisfi i requisiti necessari. Per altre informazioni, vedere Informazioni di riferimento sul connettore LDAP generico.

Nella pagina Esporta lasciare invariate le impostazioni predefinite e fare clic su Avanti.
Nella pagina Importazione completa lasciare invariate le impostazioni predefinite e fare clic su Avanti.
Se presente, nella pagina DeltaImport lasciare invariate le impostazioni predefinite e fare clic su Avanti.

Nella pagina Tipi di oggetto compilare le caselle e selezionare Avanti.

Proprietà	Descrizione
Oggetti di destinazione	Questo valore è la classe di oggetti strutturali di un utente nel server di directory LDAP. Usare `inetOrgPerson`e non specificare una classe oggetto ausiliaria in questo campo. Se il server directory richiede classi di oggetti ausiliari, verranno configurate con i mapping degli attributi nella portale di Azure.
Ancora	I valori di questo attributo devono essere univoci per ogni oggetto nella directory di destinazione. Il servizio di provisioning Di Microsoft Entra eseguirà una query sull'host del connettore ECMA usando questo attributo dopo il ciclo iniziale. In genere usare il nome distinto, che può essere selezionato come `-dn-`. Gli attributi multivalore, ad esempio l'attributo `uid` nello schema OpenLDAP, non possono essere usati come ancoraggi.
Attributo query	Questo attributo deve essere uguale all'ancoraggio.
DN	DistinguishedName dell'oggetto di destinazione. Mantenere `-dn-`.
Generato automaticamente	unchecked

L'host ECMA individua gli attributi supportati dalla directory di destinazione. È possibile scegliere quali di questi attributi esporre a Microsoft Entra ID. Questi attributi possono quindi essere configurati nel portale di Azure per il provisioning. Nella pagina Seleziona attributi aggiungere tutti gli attributi nell'elenco a discesa, uno alla volta, necessari come attributi obbligatori o di cui si vuole eseguire il provisioning da Microsoft Entra ID.
L'elenco a discesa Attributo mostra qualsiasi attributo individuato nella directory di destinazione e non è stato scelto nell'uso precedente della pagina Selezione attributi della configurazione guidata.

Assicurarsi che Treat as single value la casella di controllo sia deselezionata per l'attributo objectClass e, se userPassword impostata, sia deselezionabile o selezionata per l'attributo userPassword .

Configurare la visibilità per gli attributi seguenti.

Attributo	Considera come valore singolo
_distinguishedName
-Dn-
export_password
cn	Y
gidNumber
homeDirectory
mail	Y
objectClass
sn	Y
uid	Y
uidNumber
userPassword	Y

Dopo aver aggiunto tutti gli attributi pertinenti, selezionare Avanti.

Nella pagina Deprovisioning è possibile specificare se si vuole che Microsoft Entra ID rimuovono gli utenti dalla directory quando escono dall'ambito dell'applicazione. In caso affermativo, in Disabilita flusso selezionare Elimina e in Elimina flusso selezionare Elimina. Se Set attribute value viene scelto, gli attributi selezionati nella pagina precedente non saranno disponibili per la selezione nella pagina Deprovisioning.

Nota

Se si usa il valore dell'attributo Set tenere presente che sono consentiti solo valori booleani.

Selezionare Fine.

Verificare che il servizio ECMA2Host sia in esecuzione e possa leggere dal server di directory

Seguire questa procedura per verificare che l'host del connettore sia stato avviato e abbia identificato gli utenti esistenti dal server di directory.

Nel server che esegue l'host connettore Microsoft Entra ECMA selezionare Avvia.
Selezionare Esegui , se necessario, quindi immettere services.msc nella casella.
Nell'elenco Servizi assicurarsi che Microsoft ECMA2Host sia presente e in esecuzione. Se non è in esecuzione, selezionare Avvia.
Se il servizio è stato avviato di recente e sono presenti molti oggetti utente nel server directory, attendere alcuni minuti prima che il connettore stabilisca una connessione con il server di directory.
Nel server che esegue l'host del connettore Microsoft Entra ECMA avviare PowerShell.
Passare alla cartella in cui è stato installato l'host ECMA, ad esempio C:\Program Files\Microsoft ECMA2Host.
Passare alla sottodirectory Troubleshooting.
Eseguire lo script TestECMA2HostConnection.ps1 in tale directory come illustrato di seguito e specificare come argomenti il nome del connettore e il ObjectTypePath valore cache. Se l'host del connettore non è in ascolto sulla porta TCP 8585, potrebbe anche essere necessario specificare l'argomento -Port . Quando richiesto, digitare il token segreto configurato per tale connettore.
```
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 lo script visualizza un messaggio di errore o di avviso, verificare che il servizio sia in esecuzione e che il nome del connettore e il token segreto corrispondano a quelli configurati nella configurazione guidata.
Se lo script visualizza l'output False, il connettore non ha visualizzato voci nel server di directory di origine per gli utenti esistenti. Se si tratta di una nuova installazione del server directory, questo comportamento deve essere previsto ed è possibile continuare nella sezione successiva.
Tuttavia, se il server di directory contiene già uno o più utenti ma lo script visualizzato False, questo stato indica che il connettore non è riuscito a leggere dal server di directory. Se si tenta di effettuare il provisioning, microsoft Entra ID potrebbe non corrispondere correttamente agli utenti in tale directory di origine con gli utenti in Microsoft Entra ID. Attendere alcuni minuti prima che l'host del connettore completi la lettura degli oggetti dal server di directory esistente e quindi rieseguire lo script. Se l'output continua a essere False, controllare la configurazione del connettore e le autorizzazioni nel server directory consentono al connettore di leggere gli utenti esistenti.

Testare la connessione da Microsoft Entra ID all'host del connettore

Tornare alla finestra del Web browser in cui è stato configurato il provisioning dell'applicazione nel portale.

Nota

Se si è verificato il timeout della finestra, sarà necessario selezionare nuovamente l'agente.
1. Accedere al portale di Azure.
2. Passare ad Applicazioni aziendali e all'applicazione dell'app ECMA locale.
3. Fare clic su Provisioning.
4. Se viene visualizzato Get started (Introduzione), impostare la modalità su Automatico nella sezione Connettività locale selezionare l'agente appena distribuito e selezionare Assegna agenti e attendere 10 minuti. In caso contrario, passare a Modifica provisioning.
Nella sezione Credenziali amministratore immettere l'URL seguente. Sostituire la connectorName parte con il nome del connettore nell'host ECMA, ad esempio LDAP. Se è stato fornito un certificato dall'autorità di certificazione per l'host ECMA, sostituire localhost con il nome host del server in cui è installato l'host ECMA.

Proprietà valore

Tenant URL https://localhost:8585/ecma2host_connectorName/scim
Immettere il valore token segreto definito al momento della creazione del connettore.

Nota

Se l'agente è stato appena assegnato all'applicazione, attendere 10 minuti per il completamento della registrazione. Il test di connettività non funzionerà fino al completamento della registrazione. Forzare il completamento della registrazione dell'agente riavviando l'agente di provisioning nel server può velocizzare il processo di registrazione. Passare al server, cercare i servizi nella barra di ricerca di Windows, identificare il servizio Microsoft Entra Connect Provisioning Agent , fare clic con il pulsante destro del mouse sul servizio e riavviare.
Selezionare Test connessione e attendere un minuto.
Dopo che il test di connessione ha esito positivo e indica che le credenziali fornite sono autorizzate ad abilitare il provisioning, selezionare Salva.

Proprietà	valore
Tenant URL	https://localhost:8585/ecma2host_connectorName/scim

Estendere lo schema di Microsoft Entra

Se il server directory richiede attributi aggiuntivi che non fanno parte dello schema predefinito di Microsoft Entra per gli utenti, quando si esegue il provisioning è possibile configurare per fornire i valori di tali attributi da una costante, da un'espressione trasformata da altri attributi di Microsoft Entra o estendendo lo schema Microsoft Entra.

Se il server directory richiede agli utenti di avere un attributo, ad esempio uidNumber per lo schema POSIX OpenLDAP e tale attributo non fa già parte dello schema microsoft Entra per un utente e deve essere univoco per ogni utente, sarà necessario generare tale attributo da altri attributi dell'utente tramite un'espressione, oppure usare la funzionalità di estensione della directory per aggiungere tale attributo come estensione.

Se gli utenti hanno origine in Dominio di Active Directory Services e hanno l'attributo in tale directory, è possibile usare la sincronizzazione cloud Microsoft Entra Connect o Microsoft Entra Connect per configurare che l'attributo deve essere sincronizzato da Dominio di Active Directory Services a Microsoft Entra ID, in modo che sia disponibile per il provisioning in altri sistemi.

Se gli utenti hanno origine in Microsoft Entra ID, per ogni nuovo attributo sarà necessario archiviare in un utente, sarà necessario definire un'estensione della directory. Aggiornare quindi gli utenti di Microsoft Entra di cui è previsto il provisioning, per assegnare a ogni utente un valore di tali attributi.

Configurare il mapping degli attributi

In questa sezione si configurerà il mapping tra gli attributi dell'utente di Microsoft Entra e gli attributi selezionati in precedenza nella configurazione guidata dell'host ECMA. Successivamente, quando il connettore crea un oggetto in un server di directory, gli attributi di un utente di Microsoft Entra verranno quindi inviati tramite il connettore al server di directory per far parte di tale nuovo oggetto.

Nell'interfaccia di amministrazione di Microsoft Entra, in Applicazioni aziendali selezionare l'applicazione app ECMA locale e quindi selezionare la pagina Provisioning .
Selezionare Modifica provisioning.
Espandere Mapping e selezionare Provisioning utenti di Microsoft Entra. Se questa è la prima volta che sono stati configurati i mapping degli attributi per questa applicazione, per un segnaposto sarà presente un solo mapping.
Per verificare che lo schema del server directory sia disponibile in Microsoft Entra ID, selezionare la casella di controllo Mostra opzioni avanzate e selezionare Modifica elenco attributi per ScimOnPremises. Assicurarsi che tutti gli attributi selezionati nella configurazione guidata siano elencati. In caso contrario, attendere alcuni minuti per l'aggiornamento dello schema, quindi selezionare Mapping attributi nella riga di spostamento e quindi selezionare di nuovo Modifica elenco attributi per ScimOnPremises per ricaricare la pagina. Dopo aver visualizzato gli attributi elencati, annullare da questa pagina per tornare all'elenco dei mapping.
Ogni utente in una directory deve avere un nome distinto univoco. È possibile specificare il modo in cui il connettore deve costruire un nome distinto usando un mapping di attributi. Selezionare Aggiungi nuovo mapping. Usare i valori seguenti per creare il mapping, modificando i nomi distinti nell'espressione in modo che corrispondano a quello dell'unità organizzativa o di un altro contenitore nella directory di destinazione.
- Tipo di mapping: espressione
- Espressione: Join("", "CN=", Word([userPrincipalName], 1, "@"), ",DC=Contoso,DC=lab")
- Attributo di destinazione: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:-dn-
- Applica questo mapping: solo durante la creazione di oggetti
Se il server di directory richiede più valori della classe oggetto strutturale o valori della classe oggetto ausiliaria, da specificare nell'attributo objectClass , aggiungere un mapping a tale attributo. Per aggiungere un mapping per objectClass, selezionare Aggiungi nuovo mapping. Usare i valori seguenti per creare il mapping, modificando i nomi delle classi oggetto nell'espressione in modo che corrispondano a quello dello schema della directory di destinazione.
- Tipo di mapping: espressione
- Espressione, se si esegue il provisioning dello schema POSIX: Split("inetOrgPerson,posixAccount,shadowAccount",",")
- Attributo di destinazione: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:objectClass
- Applica questo mapping: solo durante la creazione di oggetti

Per ognuno dei mapping nella tabella seguente per il server di directory, selezionare Aggiungi nuovo mapping e specificare gli attributi di origine e di destinazione. Se si esegue il provisioning in una directory esistente con utenti esistenti, sarà necessario modificare il mapping per l'attributo comune per impostare gli oggetti Match usando questo attributo per tale attributo. Altre informazioni sul mapping degli attributi sono disponibili qui.

Per OpenLDAP con lo schema POSIX, è necessario specificare anche gli gidNumberattributi , homeDirectoryuid e uidNumber . Ogni utente richiede un univoco uid e un oggetto univoco uidNumber. In genere l'oggetto homeDirectory viene impostato da un'espressione derivata dall'ID utente dell'utente. Ad esempio, se l'oggetto uid di un utente viene generato da un'espressione derivata dal nome dell'entità utente, il valore della home directory dell'utente può essere generato anche da un'espressione simile derivata dal nome dell'entità utente. A seconda del caso d'uso, è possibile che tutti gli utenti si trovino nello stesso gruppo, quindi assegnare l'oggetto gidNumber da una costante.

Tipo di mapping	Attributo di origine	Attributo di destinazione
Diretto	`displayName`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:cn`
Diretto	`surname`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:sn`
Diretto	`userPrincipalName`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:mail`
Espressione	`ToLower(Word([userPrincipalName], 1, "@"), )`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uid`
Connessione diretta	(attributo specifico della directory)	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uidNumber`
Espressione	`Join("/", "/home", ToLower(Word([userPrincipalName], 1, "@"), ))`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:homeDirectory`
Costante	`10000`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:gidNumber`

Aggiungere un mapping a urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword che imposta una password casuale iniziale per l'utente.
Seleziona Salva.

Assicurarsi che gli utenti di cui eseguire il provisioning nella directory dispongano degli attributi necessari

Se sono presenti utenti che dispongono di account utente esistenti nella directory LDAP, sarà necessario assicurarsi che la rappresentazione utente di Microsoft Entra abbia gli attributi necessari per la corrispondenza.

Se si prevede di creare nuovi utenti nella directory LDAP, sarà necessario assicurarsi che le rappresentazioni di Microsoft Entra di tali utenti abbiano gli attributi di origine richiesti dallo schema utente della directory di destinazione. Ogni utente richiede un univoco uid e un oggetto univoco uidNumber.

Conferma degli utenti tramite PowerShell

Dopo aver aggiornato gli utenti in Microsoft Entra ID, è possibile usare i cmdlet di PowerShell di Microsoft Graph per automatizzare il controllo degli utenti con tutti gli attributi necessari.

Si supponga, ad esempio, che il provisioning richieda agli utenti tre attributi DisplayNameesurname extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty. Questo terzo attributo verrà usato per contenere .uidNumber È possibile usare il Get-MgUser cmdlet per recuperare ogni utente e verificare se sono presenti gli attributi necessari. Si noti che il cmdlet Graph v1.0 Get-MgUser non restituisce per impostazione predefinita alcuno degli attributi di estensione della directory di un utente, a meno che non vengano specificati nella richiesta come una delle proprietà da restituire.

Questa sezione illustra come interagire con Microsoft Entra ID usando i cmdlet di PowerShell di Microsoft Graph.

La prima volta che l'organizzazione usa questi cmdlet per questo scenario, è necessario essere in un ruolo di amministratore globale per consentire l'uso di Microsoft Graph PowerShell nel tenant. Le interazioni successive possono usare un ruolo con privilegi inferiori, ad esempio:

Amministratore utenti, se si prevede di creare nuovi utenti.
Amministratore dell'applicazione o Amministratore della governance delle identità, se si gestiscono solo le assegnazioni di ruolo dell'applicazione.

Aprire PowerShell.
Se i moduli di Microsoft Graph PowerShell non sono già installati, installare il Microsoft.Graph.Users modulo e altri usando questo comando:
```
Install-Module Microsoft.Graph
```
Se i moduli sono già installati, assicurarsi di usare una versione recente:
```
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
```

Connettersi all'ID Microsoft Entra:

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

Costruisci l'elenco degli utenti e gli attributi da controllare.

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

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

Eseguire una query sulla directory per ognuno degli utenti.

$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" } }
}

Raccogliere utenti esistenti dalla directory LDAP

Identificare quali utenti di tale directory rientrano nell'ambito per essere utenti con autenticazione Linux. Questa scelta dipenderà dalla configurazione del sistema Linux. Per alcune configurazioni, qualsiasi utente presente in una directory LDAP è un utente valido. Altre configurazioni potrebbero richiedere all'utente di avere un attributo specifico o di essere un membro di un gruppo in tale directory.
Eseguire un comando che recupera il subset di utenti dalla directory LDAP in un file CSV. Assicurarsi che l'output includa gli attributi degli utenti che verranno usati per la corrispondenza con Microsoft Entra ID. Esempi di questi attributi sono ID dipendente, nome account o uide indirizzo di posta elettronica.
Se necessario, trasferire il file CSV che contiene l'elenco di utenti in un sistema con i cmdlet di PowerShell di Microsoft Graph installati.
Dopo aver ottenuto un elenco di tutti gli utenti ottenuti dalla directory, questi utenti verranno associati dalla directory con gli utenti in Microsoft Entra ID. Prima di procedere, esaminare le informazioni sugli utenti corrispondenti nei sistemi di origine e di destinazione.

Recuperare gli ID degli utenti in Microsoft Entra ID

Questa sezione illustra come interagire con Microsoft Entra ID usando i cmdlet di PowerShell di Microsoft Graph.

Amministratore utenti, se si prevede di creare nuovi utenti.
Amministratore dell'applicazione o Amministratore della governance delle identità, se si gestiscono solo le assegnazioni di ruolo dell'applicazione.

Aprire PowerShell.
Se i moduli di Microsoft Graph PowerShell non sono già installati, installare il Microsoft.Graph.Users modulo e altri usando questo comando:
```
Install-Module Microsoft.Graph
```
Se i moduli sono già installati, assicurarsi di usare una versione recente:
```
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
```

Connettersi all'ID Microsoft Entra:

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

Se è la prima volta che è stato usato questo comando, potrebbe essere necessario fornire il consenso per consentire agli strumenti della riga di comando di Microsoft Graph di avere queste autorizzazioni.
Leggere l'elenco degli utenti ottenuti dall'archivio dati dell'applicazione nella sessione di PowerShell. Se l'elenco degli utenti si trovava in un file CSV, è possibile usare il cmdlet Import-Csv di PowerShell e specificare il nome del file della sezione precedente come argomento.

Ad esempio, se il file ottenuto da SAP Cloud Identity Services è denominato Users-exported-from-sap.csv e si trova nella directory corrente, immettere questo comando.
```
$filename = ".\Users-exported-from-sap.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Per un altro esempio se si usa un database o una directory, se il file è denominato users.csv e si trova nella directory corrente, immettere questo comando:
```
$filename = ".\users.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Scegliere la colonna del file users.csv che corrisponderà a un attributo di un utente in Microsoft Entra ID.

Se si usa SAP Cloud Identity Services, il mapping predefinito è l'attributo userName SAP SCIM con l'attributo userPrincipalNameMICROSOFT Entra ID :
```
$db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"
```
Per un altro esempio se si usa un database o una directory, è possibile che siano presenti utenti in un database in cui il valore nella colonna denominata EMail è lo stesso valore dell'attributo userPrincipalNameMicrosoft Entra :
```
$db_match_column_name = "EMail"
$azuread_match_attr_name = "userPrincipalName"
```

Recuperare gli ID di tali utenti in Microsoft Entra ID.

Lo script di PowerShell seguente usa i $dbusersvalori , $db_match_column_namee $azuread_match_attr_name specificati in precedenza. Eseguirà una query su Microsoft Entra ID per individuare un utente con un attributo con un valore corrispondente per ogni record nel file di origine. Se sono presenti molti utenti nel file ottenuto dall'origine SAP Cloud Identity Services, dal database o dalla directory, il completamento di questo script potrebbe richiedere alcuni minuti. Se non si dispone di un attributo in Microsoft Entra ID che ha il valore e che deve usare un'espressione contains di filtro o un'altra, sarà necessario personalizzare questo script e che nel passaggio 11 riportato di seguito per usare un'espressione di filtro diversa.

$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 }
}

Visualizzare i risultati delle query precedenti. Verificare se uno degli utenti in SAP Cloud Identity Services, il database o la directory non è stato possibile trovare in Microsoft Entra ID, a causa di errori o corrispondenze mancanti.

Lo script di PowerShell seguente visualizzerà i conteggi dei record che non si trovano:

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

Al termine dello script, indicherà un errore se eventuali record dell'origine dati non si trovano in Microsoft Entra ID. Se non tutti i record per gli utenti dell'archivio dati dell'applicazione potrebbero trovarsi come utenti in Microsoft Entra ID, è necessario analizzare quali record non corrispondono e perché.

Ad esempio, l'indirizzo di posta elettronica di un utente e userPrincipalName potrebbe essere stato modificato nell'ID Microsoft Entra senza aggiornare la proprietà corrispondente mail nell'origine dati dell'applicazione. In alternativa, l'utente potrebbe aver già lasciato l'organizzazione, ma si trova ancora nell'origine dati dell'applicazione. In alternativa, potrebbe essere presente un account fornitore o amministratore con privilegi avanzati nell'origine dati dell'applicazione che non corrisponde a una persona specifica nell'ID Microsoft Entra.
Se sono presenti utenti che non potevano trovarsi in Microsoft Entra ID o non erano attivi e non sono stati in grado di accedere, ma si vuole avere l'accesso esaminato o i relativi attributi aggiornati in SAP Cloud Identity Services, nel database o nella directory, è necessario aggiornare l'applicazione, la regola di corrispondenza o aggiornare o creare utenti di Microsoft Entra per loro. Per altre informazioni sulle modifiche da apportare, vedere Gestire mapping e account utente nelle applicazioni che non corrispondono agli utenti in Microsoft Entra ID.

Se si sceglie l'opzione di creazione di utenti in Microsoft Entra ID, è possibile creare utenti in blocco usando uno dei due elementi seguenti:
- Un file CSV, come descritto in Creare utenti in blocco nell'interfaccia di amministrazione di Microsoft Entra
- Cmdlet New-MgUser
Assicurarsi che questi nuovi utenti siano popolati con gli attributi necessari per Microsoft Entra ID per associarli in un secondo momento agli utenti esistenti nell'applicazione e gli attributi richiesti dall'ID Microsoft Entra, inclusi userPrincipalName, mailNickname e displayName. Deve userPrincipalName essere univoco tra tutti gli utenti nella directory.

Ad esempio, si potrebbero avere utenti in un database in cui il valore nella colonna denominata EMail è il valore che si vuole usare come nome dell'entità utente Microsoft Entra, il valore nella colonna Alias contiene il nome alternativo della posta elettronica microsoft Entra ID e il valore nella colonna Full name contiene il nome visualizzato dell'utente:
```
$db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"
```
È quindi possibile usare questo script per creare utenti di Microsoft Entra per quelli in SAP Cloud Identity Services, nel database o nella directory che non corrispondono agli utenti in Microsoft Entra ID. Si noti che potrebbe essere necessario modificare questo script per aggiungere altri attributi di Microsoft Entra necessari nell'organizzazione o se non è né mailNickname userPrincipalName, per fornire l'attributo $azuread_match_attr_name 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
   }
}
```

Dopo aver aggiunto gli utenti mancanti all'ID Microsoft Entra, eseguire di nuovo lo script del passaggio 7. Eseguire quindi lo script dal passaggio 8. Verificare che non vengano segnalati errori.

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

Assegnare utenti all'applicazione in Microsoft Entra ID

Ora che si dispone dell'host del connettore Microsoft Entra ECMA che comunica con Microsoft Entra ID e il mapping degli attributi configurato, è possibile passare alla configurazione di chi è nell'ambito del provisioning.

Importante

Se è stato eseguito l'accesso usando un ruolo di amministratore delle identità ibride, è necessario disconnettersi e accedere con un account con almeno il ruolo di amministratore dell'applicazione per questa sezione. Il ruolo Amministratore identità ibrida non dispone delle autorizzazioni per assegnare utenti alle applicazioni.

Se nella directory LDAP sono presenti utenti esistenti, è necessario creare assegnazioni di ruolo dell'applicazione per tali utenti esistenti. Per altre informazioni su come creare assegnazioni di ruolo dell'applicazione in blocco usando New-MgServicePrincipalAppRoleAssignedTo, vedere Governance degli utenti esistenti di un'applicazione in Microsoft Entra ID.

Se non si desidera aggiornare ancora gli utenti esistenti nella directory LDAP, selezionare un utente di test da Microsoft Entra ID che dispone degli attributi necessari e verrà effettuato il provisioning nel server di directory.

Assicurarsi che l'utente selezioni tutte le proprietà di cui verrà eseguito il mapping agli attributi necessari dello schema del server di directory.
Nella portale di Azure selezionare Applicazioni aziendali.
Selezionare l'applicazione dell'app ECMA locale.
A sinistra, in Gestisci selezionare Utenti e gruppi.
Selezionare Aggiungi utente/gruppo.
In Utenti selezionare Nessuno selezionato.
Selezionare un utente a destra e selezionare il pulsante Seleziona .
Selezionare Ora Assegna.

Provisioning di test

Dopo aver eseguito il mapping degli attributi e assegnato un utente iniziale, è possibile testare il provisioning su richiesta con uno degli utenti.

Nel server in cui è in esecuzione l'host del connettore Microsoft Entra ECMA selezionare Avvia.
Immettere run e immettere services.msc nella casella.
Nell'elenco Servizi assicurarsi che sia il servizio Microsoft Entra Connect Provisioning Agent che i servizi Microsoft ECMA2Host siano in esecuzione. In caso contrario, selezionare Avvia.
Nella portale di Azure selezionare Applicazioni aziendali.
Selezionare l'applicazione dell'app ECMA locale.
A sinistra selezionare Provisioning.
Selezionare Provision on demand (Provision on demand).
Cercare uno degli utenti di test e selezionare Provision (Provision).
Dopo alcuni secondi, viene visualizzato il messaggio Utente creato correttamente nel sistema di destinazione, con un elenco degli attributi utente. Se viene visualizzato un errore, vedere risoluzione degli errori di provisioning.

Avviare il provisioning degli utenti

Al termine del test del provisioning su richiesta, aggiungere gli utenti rimanenti. Per altre informazioni su come creare assegnazioni di ruolo dell'applicazione in blocco usando New-MgServicePrincipalAppRoleAssignedTo, vedere Governance degli utenti esistenti di un'applicazione in Microsoft Entra ID.

Nella portale di Azure selezionare l'applicazione.
A sinistra, in Gestisci selezionare Utenti e gruppi.
Assicurarsi che tutti gli utenti siano assegnati al ruolo applicazione.
Tornare alla pagina di configurazione del provisioning.
Assicurarsi che l'ambito sia impostato solo su utenti e gruppi assegnati, attivare lo stato del provisioning e selezionare Salva.
Attendere alcuni minuti per l'avvio del provisioning. Potrebbero essere necessari fino a 40 minuti. Al termine del processo di provisioning, come descritto nella sezione successiva,

Risoluzione degli errori di provisioning

Se viene visualizzato un errore, selezionare Visualizza log di provisioning. Cercare nel log una riga in cui lo stato è Errore e fare clic su tale riga.

Se il messaggio di errore non è Riuscito a creare l'utente, controllare gli attributi visualizzati in base ai requisiti dello schema della directory.

Per altre informazioni, passare alla scheda Risoluzione dei problemi e raccomandazioni .

Se il messaggio di errore per la risoluzione dei problemi include che un valore objectClass è invalid per syntax, assicurarsi che il mapping dell'attributo di provisioning all'attributo objectClass includa solo i nomi delle classi oggetto riconosciute dal server di directory.

Per altri errori, vedere Risoluzione dei problemi relativi al provisioning di applicazioni locali.

Se si vuole sospendere il provisioning in questa applicazione, nella pagina di configurazione del provisioning è possibile modificare lo stato del provisioning su Disattivato e selezionare Salva. Questa azione impedisce l'esecuzione del servizio di provisioning in futuro.

Verificare che il provisioning degli utenti sia stato eseguito correttamente

Dopo l'attesa, controllare il server di directory per assicurarsi che venga effettuato il provisioning degli utenti. La query eseguita sul server di directory dipenderà dai comandi forniti dal server directory.

Le istruzioni seguenti illustrano come controllare OpenLDAP in Linux.

Aprire una finestra del terminale con una shell dei comandi nel sistema con OpenLDAP.
Digitare il comando ldapsearch -D "cn=admin,dc=contoso,dc=lab" -W -s sub -b dc=contoso,dc=lab -LLL (objectclass=inetOrgPerson)
Verificare che l'LDIF risultante includa gli utenti di cui è stato effettuato il provisioning da Microsoft Entra ID.

Passaggi successivi

Per altre informazioni sul funzionamento del servizio di provisioning e sulle domande frequenti, vedere Automatizzare il provisioning e il deprovisioning degli utenti in applicazioni SaaS con l'ID Microsoft Entra e l'architettura di provisioning delle applicazioni locali.

Condividi tramite

Configurazione dell'ID Microsoft Entra per effettuare il provisioning degli utenti in una directory LDAP per l'autenticazione Linux

Prerequisiti per il provisioning degli utenti in una directory LDAP per l'autenticazione Linux

On-premises prerequisites (Prerequisiti locali)

Requisiti cloud

Altre raccomandazioni e limitazioni

Determinare l'interazione del connettore LDAP di Microsoft Entra con il server di directory

Installare e configurare Microsoft Entra Connect Provisioning Agent

Configurare l'app ECMA locale

Configurare il certificato host del connettore Microsoft Entra ECMA

Configurare il connettore LDAP generico

Verificare che il servizio ECMA2Host sia in esecuzione e possa leggere dal server di directory

Testare la connessione da Microsoft Entra ID all'host del connettore

Estendere lo schema di Microsoft Entra

Configurare il mapping degli attributi

Assicurarsi che gli utenti di cui eseguire il provisioning nella directory dispongano degli attributi necessari

Conferma degli utenti tramite PowerShell

Raccogliere utenti esistenti dalla directory LDAP

Recuperare gli ID degli utenti in Microsoft Entra ID

Assegnare utenti all'applicazione in Microsoft Entra ID

Provisioning di test

Avviare il provisioning degli utenti

Risoluzione degli errori di provisioning

Verificare che il provisioning degli utenti sia stato eseguito correttamente

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive