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

Articolo
12/14/2024

La documentazione seguente è un'esercitazione che illustra come gestire l'accesso a un sistema Linux. Microsoft Entra effettua il provisioning degli utenti in una directory LDAP locale considerata attendibile dal sistema Linux. In questo modo gli utenti possono accedere a un sistema Linux che si basa su tale directory LDAP per l'autenticazione utente. Quando un utente viene rimosso dall'ID Microsoft Entra, 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 dovrebbero 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, diversi dall'autenticazione Linux, che coinvolgono il provisioning degli utenti in directory LDAP, vedere la configurazione di Microsoft Entra ID per il provisioning degli utenti nelle directory LDAP.

Prerequisiti per il provisioning di utenti in una directory LDAP per l'autenticazione su 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 in locale da Microsoft Entra ID a un server di directory LDAP.

Prerequisiti in sede

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 le 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. Deve anche avere connettività al server directory di destinazione e alla connettività in uscita a login.microsoftonline.com, altri di 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: sebbene non sia necessario, è consigliabile scaricare Microsoft Edge per Windows Server e usarlo sul posto di Internet Explorer.

Requisiti cloud

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

L'uso di questa funzionalità richiede licenze microsoft Entra ID P1. Per trovare la licenza appropriata per i requisiti, vedi Confronta le funzionalità generalmente disponibili di Microsoft Entra ID.
Ruolo di Amministratore delle Identità Ibride per la configurazione dell'agente di provisioning.
I ruoli di Amministratore applicazione e Amministratore dell'applicazione cloud consentono di configurare il provisioning nel portale di Azure o nel centro di amministrazione di Microsoft Entra.
Lo schema del server directory richiede attributi specifici per ogni utente di Microsoft Entra da fornire nella directory LDAP e questi attributi devono essere già compilati. 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 o estendere lo schema di Microsoft Entra. È quindi possibile popolare quell'attributo per gli utenti nell'ambito. Consultare estendibilità Graph per istruzioni su come creare estensioni di directory aggiuntive.

Altre raccomandazioni e limitazioni

I seguenti punti elenco forniscono ulteriori raccomandazioni e limitazioni.

Non è raccomandato usare lo stesso agente per la sincronizzazione cloud e il provisioning di applicazioni in sede. Microsoft consiglia di usare un agente separato per la sincronizzazione cloud e uno per il provisioning di app locali.
Attualmente, per AD LDS non è possibile fornire password agli utenti. È quindi necessario disabilitare i criteri password per AD LDS o configurare gli utenti con lo stato di 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.
La configurazione di gruppi e appartenenze utente su un server directory non è supportata.

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 di directory della propria organizzazione su come integrare il loro server di directory. Le informazioni da raccogliere includono:

Informazioni di rete su come connettersi al server di directory.
Come il connettore dovrebbe autenticarsi al server di directory.
Schema selezionato dal server di directory per modellare gli utenti.
Il nome distinto di base del contesto di denominazione e le regole della gerarchia della directory.
Come associare gli utenti nel server di directory agli utenti in Microsoft Entra ID.
Cosa deve 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 della Configurazione Guidata Connettività	`APP3`
numero di porta del server di directory	Pagina della procedura guidata di configurazione connettività	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 della procedura guidata di configurazione connettività	`cn=admin,dc=contoso,dc=lab`
password del connettore per autenticarsi al server di directory	Pagina della configurazione guidata della connettività
classe di oggetti strutturali per un utente nel server di directory	Pagina tipi di oggetto della configurazione guidata	`inetOrgPerson`
classi di oggetti ausiliari per un utente nel server directory	Mapping degli attributi di pagina del portale di Azure provisioning	`posixAccount` e`shadowAccount`
attributi da compilare per un nuovo utente	Pagina Configurazione guidata Selezione attributi e pagina di mapping degli attributi della pagina di provisioning del portale di Azure	`cn`, `gidNumber`, `homeDirectory`, `mail`, `objectClass`, `sn`, `uid`, `uidNumber`, `userPassword`
gerarchia di denominazione richiesta dal server di directory	Mapping degli attributi della pagina di provisioning del portale Azure	Impostare il DN di un utente appena creato in modo che sia immediatamente sotto `DC=Contoso,DC=lab`
attributi per correlare gli utenti tra Microsoft Entra ID e il server di directory	Mapping degli attributi della pagina nel portale di Azure Provisioning	`mail`
comportamento di deprovisioning quando un utente esce dal contesto in Microsoft Entra ID	Configurazione guidata, pagina di deprovisioning	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.

È necessario disporre di un account identificato affinché il connettore si autentichi al server di directory già configurato nel sistema. 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 autorizzazioni di scrittura per poter esportare e autorizzazioni di lettura per poter eseguire l'importazione. La configurazione delle autorizzazioni viene eseguita all'interno delle funzionalità 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 inetOrgPersone 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 si definiscono 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.

È probabile che si configurino anche le mappature di alcuni degli attributi facoltativi di queste classi. Un server di directory OpenLDAP con lo schema POSIX per supportare l'autenticazione Linux potrebbe richiedere che un nuovo utente abbia attributi simili a quelli mostrati nel seguente esempio.

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 piatta 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 complessa, nel qual caso sarà necessario implementare le regole quando si specifica la mappatura dei nomi distinti 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, che è presente sia nello schema del server directory che nei propri utenti in Microsoft Entra ID. Quindi, quando il connettore esegue il provisioning di un nuovo utente in un server di directory, può cercare se esiste già un utente in quella directory con un valore specifico dell'attributo. Il connettore creerà un nuovo utente nel server di directory solo se tale utente 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 il modo in cui i sistemi Linux che usano tale server di directory gestiscono l'autenticazione. Alcuni sistemi possono interrogare la chiave pubblica o il certificato SSH di un utente dalla directory, il che potrebbe essere adatto per gli utenti che già possiedono credenziali di tali tipi. Tuttavia, se l'applicazione che si basa sul server di directory non supporta protocolli di autenticazione moderni o credenziali più forti, è necessario impostare una password specifica per l'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, sia per un utente già presente nella directory sia per un nuovo utente, Microsoft Entra ID può provvedere al provisioning delle modifiche degli attributi dall'utente di Microsoft Entra alla directory.

Se un utente assegnato all'applicazione viene eliminato in Microsoft Entra ID, Microsoft Entra ID invia un'operazione di eliminazione al server di directory. È anche possibile desiderare che Microsoft Entra ID aggiorni l'oggetto nel server della directory quando un utente non è più in grado di utilizzare l'applicazione. Questo comportamento dipende dall'applicazione che userà 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 a Applicazioni aziendali e selezionare Nuova applicazione.
Cercare l'applicazione On-premises ECMA , assegnare all'app un nome e selezionare Crea per aggiungerla al tenant.
Dal menu passare alla pagina Provisioning dell'applicazione.
Selezionare Inizia.
Nella pagina Provisioning, impostare la modalità su Automatico.

In Connettività localeselezionare Scaricare e installaree selezionare Accetta termini & scaricare.

Lasciare il portale ed eseguire il programma di installazione dell'agente di provisioning, accettare le condizioni per il servizio e selezionare Installa.
Attendere la procedura guidata di configurazione dell'agente di provisioning di Microsoft Entra e quindi selezionare Avanti.
Nel passaggio Seleziona estensione, seleziona il provisioning delle applicazioni locali e quindi seleziona Avanti.
L'agente di provisioning utilizza il browser web del sistema operativo per visualizzare una finestra a comparsa che ti consente di autenticarti su Microsoft Entra ID e, eventualmente, anche sul provider di identità della tua 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 richiesta l'autorizzazione. L'utente deve avere almeno il ruolo Amministratore delle Identità Ibride.
Selezionare Conferma per confermare l'impostazione. Una volta completata l'installazione, puoi selezionare Escie chiudere anche il programma di installazione del pacchetto dell'agente di provisioning.

Configurare l'app ECMA locale

Tornare nel portale, nella sezione Connettività Locale, selezionare l'agente che avete distribuito e selezionare Assegna Agente(i).
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, selezionare la Configurazione guidata Microsoft ECMA2Host dal menu Start ed eseguire come amministratore. Per creare i registri eventi di Windows necessari, la procedura guidata deve essere eseguita come amministratore di Windows.
Dopo l'avvio della configurazione host del connettore ECMA, se è la prima volta che si esegue la procedura guidata, viene chiesto di creare un certificato. Lasciare la porta predefinita 8585 e selezionare Generare certificato per generare un certificato. Il certificato generato automaticamente è autofirmato come parte della radice attendibile. La SAN corrisponde al nome host.
Selezionare Salva.

Nota

Se si è scelto di generare un nuovo certificato, registrare la data di scadenza del certificato, per assicurarsi di ritornare alla procedura guidata di configurazione e rilasciare 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 autenticare l'ID Microsoft Entra nel connettore. Deve contenere almeno 12 caratteri e univoci per ogni applicazione. Se non si ha già 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 l'hai già fatto, avvia l'Installazione guidata di configurazione 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 di sincronizzazione automatica (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à, configurerai come l'host del connettore ECMA comunica con il server della directory e imposterai 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 esegue una query sul server di directory per la relativa configurazione.

Proprietà	Descrizione
Host	Nome dell'host dove si trova il server LDAP. Questo esempio usa `APP3` come nome host di esempio.
Porto	Numero di porta TCP. Se il server di directory è configurato per LDAP tramite SSL, usare la porta 636. Per `Start TLS`, oppure se si utilizza la sicurezza a livello di rete, utilizzare la porta 389.
Timeout di connessione	180
Vincolo	Questa proprietà specifica il modo in cui il connettore esegue l'autenticazione nel server di directory. Con l'impostazione `Basic` o con l'impostazione `SSL` o `TLS` e nessun certificato client configurato, il connettore invia 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 invia un binding LDAP SASL `EXTERNAL` per autenticarsi con un certificato client.
Nome utente	Modalità con cui il connettore ECMA autentica se stesso al server directory. In questo esempio `cn=admin,dc=contoso,dc=lab`
Parola d’ordine	La password dell'utente con cui il connettore ECMA si autentica al server di directory.
Ambito/Dominio	Questa impostazione è necessaria solo se è stata selezionata `Kerberos` come opzione Binding per fornire l'area di autenticazione/dominio dell'utente.
Certificato	Le impostazioni in questa sezione vengono usate solo se è stata selezionata `SSL` o `TLS` come opzione Binding.
Alias degli attributi	La casella di testo per gli alias degli attributi viene usata per gli attributi definiti nello schema con sintassi RFC4522. Questi attributi non possono essere rilevati durante la fase di rilevamento dello schema e il connettore ha bisogno di aiuto per identificarli. Ad esempio, se il server di directory non pubblica `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 casella di controllo `Include operational attributes in schema` per includere anche gli attributi creati dal server di directory. Questi includono attributi, ad esempio quando l'oggetto è stato creato e l'ora dell'ultimo aggiornamento.
Includere attributi estendibili	Selezionare la casella di controllo `Include extensible attributes in schema` se nel server di 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, lo schema risulta molto grande, a meno che la directory connessa non usi questa funzionalità, è consigliabile mantenere deselezionata l'opzione.
Consenti selezione dell'ancoraggio manuale	Lasciare deselezionata.

Nota

Se riscontri un problema nel tentativo di connetterti e non riesci a passare alla pagina globale di , assicurati 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, nonché funzionalità LDAP aggiuntive. La pagina è prepopolata dalle 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 del certificato server	Se è stato specificato `SSL` o `TLS`, nella procedura guidata viene visualizzato il certificato restituito dal server di directory. Verificare che l'emittente, l'oggetto e l'impronta digitale siano per il server di directory corretto.
Funzionalità obbligatorie trovate	Il connettore verifica inoltre che i controlli obbligatori siano presenti nel Root DSE. 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 controllano il comportamento di determinate operazioni per i controlli supportati .
Importazione Delta	Il DN del registro delle modifiche è il contesto di denominazione utilizzato dal log delle modifiche delta, 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 di partizioni aggiuntive è possibile includere ulteriori spazi dei nomi non rilevati automaticamente. Ad esempio, questa impostazione può essere usata se più server costituiscono un cluster logico, che deve essere importato contemporaneamente. Proprio come Active Directory può avere più domini in una foresta, ma tutti i domini condividono uno schema, lo stesso può essere simulato immettendo i namespace aggiuntivi in questo box. Ogni namespace può importare da server diversi ed è ulteriormente configurato nella pagina Configura Partizioni e Gerarchie.

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

Nella pagina Profili di esecuzione, verificare che siano selezionate entrambe le caselle di controllo Esporta e Importazione completa. Selezionare quindi Avanti.

Proprietà	Descrizione
Esportazione	Eseguire il profilo che esporta i dati nel server di directory LDAP. Questo profilo di esecuzione è obbligatorio.
Importazione completa	Profilo di esecuzione che importa tutti i dati dalle origini LDAP specificate in precedenza. Questo profilo di esecuzione è obbligatorio.
Importazione delta	Profilo di esecuzione che importa solo le modifiche da LDAP rispetto all'ultima importazione completa o differenziale. Abilitare questo profilo di esecuzione solo se si è verificato che il server di directory soddisfi i requisiti necessari. Per ulteriori informazioni, consultare il riferimento al connettore LDAP generico .

Nella pagina Esporta, lasciare le impostazioni predefinite invariate e selezionare Avanti.
Nella pagina Importazione completa, lascia invariate le opzioni predefinite e seleziona Avanti.
Nella pagina DeltaImport lasciare invariate le impostazioni predefinite e selezionare Avanti.

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

Proprietà	Descrizione
Oggetto 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 di directory richiede classi di oggetti ausiliari, verranno configurate con i mapping degli attributi nel 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 esegue una query sull'host del connettore ECMA utilizzando 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'Ancora.
DN	Il DistinguishedName dell'oggetto di destinazione. Mantenere `-dn-`.
Generato automaticamente	Deselezionata

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, che sono necessari come obbligatori o che si desidera configurare da Microsoft Entra ID. Screenshot che mostra la pagina Seleziona attributi. L'elenco a discesa Attributi mostra qualsiasi attributo individuato nella directory di destinazione e non è stato scelto nell'uso precedente della configurazione guidata nella pagina Seleziona attributi .

Assicurarsi che la casella di controllo Treat as single value sia deselezionata per l'attributo objectClass e, se viene impostato userPassword, sia non selezionabile oppure 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
posta	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 tal caso, sotto Disabilita flusso, selezionare Elimina, e sotto Elimina flusso, selezionare Elimina. Se si sceglie Set attribute value, gli attributi selezionati nella pagina precedente non saranno disponibili per la selezione nella pagina Deprovisioning.

Nota

Se si utilizza l'attributo per impostare il valore, 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 nel server di directory.

Sul server in cui è in esecuzione l'host del connettore Microsoft Entra ECMA, selezionare Avvia.
Selezionare eseguire, se necessario, quindi immettere services.msc nella casella.
Nell’elenco dei Services, assicurati che il 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.
Sul 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 e specificare come argomenti il nome del connettore e il valore ObjectTypePathcache. Se l'host del connettore non è in ascolto sulla porta TCP 8585, potrebbe essere necessario fornire anche 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, allora il connettore non ha rilevato voci nel server di directory sorgente 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 uno o più utenti già, ma lo script ha visualizzato False, questo stato indica che il connettore non è riuscito a leggere dal server di directory. Se si tenta di effettuare il provisioning degli utenti, Microsoft Entra ID potrebbe non abbinare correttamente gli utenti in quella directory di origine con quelli 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 che le autorizzazioni nel server directory siano impostate affinché consentano al connettore di leggere gli utenti esistenti.

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

Torna alla finestra del web browser in cui stavi configurando 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. Vai a applicazioni aziendali e all'applicazione ECMA locale.
3. Selezionare Provisioning.
4. Se compare Inizia, impostare la modalità su Automatico, nella sezione Connettività in sede, selezionare l'agente appena distribuito e selezionare Assegna Agente(i), e attendere 10 minuti. In caso contrario, passare a Modifica configurazione.
Nella sezione credenziali di amministratore, immettere l'URL seguente. Sostituire la parte connectorName 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

URL del tenant https://localhost:8585/ecma2host_connectorName/scim
Inserisci il valore del Token Segreto che hai definito durante la creazione del connettore.

Nota

Se l'agente è stato appena assegnato all'applicazione, attendete 10 minuti per il completamento della registrazione. Il test di connettività non funzionerà fino al completamento della registrazione. Forzare la registrazione completa dell'agente riavviando l'agente di provisioning sul tuo server può velocizzare il processo di registrazione. Passare al server, cercare servizi nella barra di ricerca di Windows, identificare il servizio Microsoft Entra Connect Provisioning Agent, selezionare il servizio e riavviare.
Selezionare Test connessionee attendere un minuto.
Al termine del test della connessione, se segnala che le credenziali fornite sono autorizzate a procedere con il provisioning, selezionare Salva.

Proprietà	Valore
URL del tenant	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 di Microsoft Entra.

Se il server di 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 di Microsoft Entra per un utente e deve essere univoco per ogni utente, è 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 nei Servizi di dominio Active Directory e possiedono l'attributo in tale directory, è possibile utilizzare Microsoft Entra Connect o la sincronizzazione cloud di Microsoft Entra Connect. L'attributo verrà configurato per essere sincronizzato dai Servizi di dominio Active Directory all'ID Microsoft Entra, rendendolo disponibile per il provisioning su altri sistemi.

Se gli utenti hanno origine in Microsoft Entra ID, è necessario definire un'estensione della directory per ogni nuovo attributo da archiviare in un utente. Quindi, aggiornare 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 procedura guidata di configurazione dell'host ECMA. Successivamente, quando il connettore crea un oggetto in un server directory, gli attributi utente di Microsoft Entra vengono inviati tramite il connettore al server 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.
Espandi Mapping e seleziona Effettua il provisioning degli utenti di Microsoft Entra. Se questa è la prima volta che configuri le mappature degli attributi per questa applicazione, è presente solo una mappatura come segnaposto.
Per verificare che lo schema del server directory sia disponibile in Microsoft Entra ID, selezionare la casella di controllo Mostra opzioni avanzate e selezionare l'opzione Modifica elenco di attributi per ScimOnPremises. Assicurati 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 navigazione e poi selezionare di nuovo Modifica elenco attributi per ScimOnPremises per ricaricare la pagina. Dopo aver visualizzato gli attributi elencati, cancella da questa pagina per tornare all'elenco delle mappature.
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 nuova mappatura. Usare i valori seguenti per creare la mappatura, modificando i nomi distinti nell'espressione in modo che corrispondano a quelli 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 che siano forniti più valori di classi di oggetti strutturali o valori di classi oggetto ausiliarie nell'attributo objectClass, allora aggiungere un mapping per quell'attributo. Per aggiungere una mappatura per objectClass, selezionare Aggiungi nuova mappatura. 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 implementa lo 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 un oggetto

Per ciascuna delle mappature nella tabella seguente per il server di directory, selezionare Aggiungi nuova mappaturae specificare gli attributi di origine e di destinazione. Se si esegue il provisioning in una directory esistente con utenti esistenti, è necessario modificare il mapping per l'attributo comune per impostare gli oggetti Match usando questo attributo per tale attributo. Ulteriori informazioni sul mapping degli attributi qui .

Per OpenLDAP con lo schema POSIX, è necessario specificare anche gli attributi gidNumber, homeDirectory, uid e uidNumber. Ogni utente richiede un uid univoco e un uidNumberunivoco. In genere il homeDirectory viene impostato da un'espressione derivata dall'ID utente dell'utente. Ad esempio, se il uid di un utente viene generato da un'espressione derivata dal nome principale dell'utente, allora il valore della home directory dell'utente potrebbe essere generato da un'espressione simile anch'essa derivata dal nome principale dell'utente. A seconda del caso d'uso, potresti desiderare che tutti gli utenti siano nello stesso gruppo, quindi assegnare il gidNumber tramite una costante.

Tipo di mappatura	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`
Diretto	(attributo specifico della tua 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 una mappatura a urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword che imposta una password iniziale casuale per l'utente.
Selezionare Salva.

Assicurati che gli utenti da provisionare nella directory dispongano degli attributi necessari.

Se sono presenti utenti con account utente esistenti nella directory LDAP, è 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, è 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 uid univoco e un uidNumberunivoco.

Se gli utenti provengono dai Servizi di dominio Active Directory e hanno l'attributo in tale directory, è possibile usare Microsoft Entra Connect o la sincronizzazione cloud Microsoft Entra Connect per configurare la sincronizzazione dell'attributo da Servizi di dominio Active Directory a Microsoft Entra ID, affinché sia disponibile per il provisioning verso altri sistemi.

Se gli utenti hanno origine in Microsoft Entra ID, per ogni nuovo attributo è necessario archiviare in un utente, è definire un'estensione della directory. Quindi, aggiorna gli utenti Microsoft Entra pianificati per il provisioning, per assegnare a ogni utente un valore di tali attributi.

Conferma degli utenti tramite PowerShell

Una volta aggiornati gli utenti in Microsoft Entra ID, è possibile utilizzare i cmdlet di Microsoft Graph PowerShell per automatizzare la verifica che gli utenti dispongano di tutti gli attributi richiesti.

Supponiamo, ad esempio, che il provisioning richieda agli utenti di avere tre attributi: DisplayName,surname e extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty. Questo terzo attributo viene usato per contenere il uidNumber. È possibile usare il cmdlet Get-MgUser per recuperare ogni utente e verificare se sono presenti gli attributi necessari. Si noti che il cmdlet Graph v1.0 Get-MgUser, per impostazione predefinita, non restituisce alcun attributo dell'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 cmdlet di Microsoft Graph PowerShell.

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 di Identity Governance, se gestite solo gli incarichi di ruolo dell'applicazione.

Aprire PowerShell.
Se non sono già installati i moduli di PowerShell di Microsoft Graph , installare il modulo Microsoft.Graph.Users 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" } }
}

Raccogli utenti esistenti dalla directory LDAP

Identificare quali utenti di tale directory sono idonei ad essere autenticati con 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.
Esegui un comando che recupera il sottoinsieme di utenti dalla directory LDAP in un file CSV. Assicurarsi che l'output includa gli attributi degli utenti utilizzati per l'abbinamento con Microsoft Entra ID. Esempi di questi attributi sono l'ID del dipendente, il nome dell'account o uide l'indirizzo di posta elettronica.
Se necessario, trasferire il file CSV che contiene l'elenco degli utenti in un sistema con i cmdlet di Microsoft Graph PowerShell installati.
Dopo aver ottenuto un elenco di tutti gli utenti dalla directory, confronterai questi utenti della directory con quelli in Microsoft Entra ID. Prima di procedere, esamina le informazioni sugli utenti corrispondenti nei sistemi di origine e destinazione.

Recuperare gli ID degli utenti in Microsoft Entra ID

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

Amministratore utente: se prevedi di creare nuovi utenti.
Amministratore dell'applicazione o amministratore di Identity Governance, se si gestiscono solo le assegnazioni di ruolo dell'applicazione.

Aprire PowerShell.
Se non sono già installati i moduli di PowerShell di Microsoft Graph , installare il modulo Microsoft.Graph.Users 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 di PowerShell Import-Csv 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 di 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 SAP SCIM userName con l'attributo Microsoft Entra ID userPrincipalName:
```
$db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"
```
Per un altro esempio se si usa un database o una directory, è possibile che si disponga di utenti in un database in cui il valore nella colonna denominata EMail è lo stesso valore dell'attributo Microsoft Entra userPrincipalName:
```
$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 valori $dbusers, $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 con il valore necessario e si deve utilizzare un'espressione di filtro come contains o un'altra, sarà necessario personalizzare questo script e quello menzionato al passaggio 11 riportato di seguito per utilizzare 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. Verifica se uno qualsiasi degli utenti in SAP Cloud Identity Services, nel database o nella directory non può essere localizzato in Microsoft Entra ID, a causa di errori o di 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 è stato possibile trovare tutti i record degli utenti dell'archivio dati dell'applicazione come utenti in Microsoft Entra ID, è necessario analizzare quali record non hanno corrisposto e perché.

Ad esempio, l'indirizzo di posta elettronica di un utente e il nome utente principale potrebbero essere stati modificati nell'ID Microsoft Entra senza che la proprietà mail corrispondente venga aggiornata 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 esserci un account di tipo fornitore o super-amministratore nell'origine dei dati dell'applicazione che non corrisponde a nessuna persona specifica in Microsoft Entra ID.
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 ulteriori informazioni su quale modifica effettuare, consulta la gestione dei mapping e degli 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
- Il cmdlet New-MgUser
Assicurarsi che questi nuovi utenti siano popolati con gli attributi necessari per l'ID di Microsoft Entra per associarli in un secondo momento agli utenti esistenti nell'applicazione e gli attributi richiesti dall'ID Microsoft Entra, inclusi userPrincipalName, mailNickname e displayName. Il userPrincipalName deve 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 è quello che si desidera utilizzare come Nome Principale Utente di Microsoft Entra, il valore nella colonna Alias contiene il soprannome della posta elettronica di 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 il $azuread_match_attr_name non è né mailNickname né userPrincipalName, per fornire tale attributo 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 hai configurato Microsoft Entra ECMA Connector Host per comunicare con Microsoft Entra ID e mappato gli attributi, puoi passare a definire quali utenti sono compresi nell'ambito del provisioning.

Importante

Se hai effettuato l'accesso utilizzando il ruolo di Amministratore delle Identità Ibride, devi disconnetterti e accedere nuovamente con un account che abbia almeno il ruolo di Amministratore delle Applicazioni 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 ulteriori informazioni su come creare assegnazioni di ruolo dell'applicazione in blocco usando New-MgServicePrincipalAppRoleAssignedTo, consulta per la gestione degli utenti esistenti di un'applicazione in Microsoft Entra ID.

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

Assicurarsi che l'utente selezionato abbia tutte le proprietà che saranno mappate agli attributi richiesti dello schema del server di directory.
Nel portale di Azure selezionare Applicazioni aziendali.
Selezionare l'applicazione app ECMA locale.
A sinistra, in Gestisci, selezionare Utenti e gruppi.
Selezionare Aggiungi utente/gruppo.
Sotto Utenti, selezionare Nessuno Selezionato.
Selezionare un utente a destra e selezionare il pulsante Seleziona.
Selezionare ora Assegna.

Provisioning dei test

Dopo aver mappato gli attributi e assegnato un utente iniziale, è possibile testare il provisioning su richiesta con un utente.

Nel server su cui è in esecuzione l'host del connettore Microsoft Entra ECMA, selezionare Avvia.
Inserisci esegui e digita services.msc nella casella.
Nell'elenco servizi, assicurarsi che siano in esecuzione sia il servizio Microsoft Entra Connect Provisioning Agent sia il servizio Microsoft ECMA2Host. In caso contrario, selezionare Avvia.
Nel portale di Azure selezionare Applicazioni aziendali.
Selezionare l'applicazione ECMA locale app.
A sinistra selezionare Provisioning.
Selezionare Effettuare il provisioning su richiesta.
Cerca uno degli utenti di test e seleziona Provisioning.
Dopo alcuni secondi, verrà visualizzato il messaggio Utente creato correttamente nel sistema di destinazione, con un elenco degli attributi utente. Se invece appare un errore, vedere la sezione risoluzione degli errori di provisioning.

Avviare il provisioning degli utenti

Completato il test del provisioning su richiesta, aggiungere gli utenti rimanenti. Per saperne di più su come creare in blocco assegnazioni di ruolo per le applicazioni usando New-MgServicePrincipalAppRoleAssignedTo, veda sulla gestione degli utenti esistenti di un'applicazione in Microsoft Entra ID.

Nel portale di Azure selezionare l'applicazione.
A sinistra, in Gestisci, selezionare Utenti e gruppi.
Assicurarsi che tutti gli utenti siano assegnati al ruolo applicativo.
Tornare indietro alla pagina di configurazione del provisioning.
Assicurarsi che l'ambito sia impostato solo su utenti e gruppi assegnati, impostare lo stato del provisioning su One selezionare Save.
Attendi alcuni minuti affinché il provisioning inizi. 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 Visualizzare i log di provisioning. Cercare nel log una riga in cui lo stato è Erroree selezionare quella riga.

Se il messaggio di errore è Impossibile creare l'utente, controllare gli attributi visualizzati rispetto ai requisiti dello schema della directory.

Per altre informazioni, passare alla scheda Risoluzione dei problemi & Raccomandazioni.

Se il messaggio di errore di risoluzione include un valore objectClass pari a invalid per syntax, assicurarsi che il mappaggio dell'attributo di provisioning verso l'attributo objectClass contenga solo nomi delle classi oggetto riconosciute dal server di directory.

Per altri errori, consultare la 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 in Disattivatoe selezionare Salva. Questa azione impedisce l'esecuzione del servizio di provisioning in futuro.

Verificare che il provisioning degli utenti sia stato eseguito correttamente

Dopo aver aspettato, controllare il server di directory per assicurarsi che venga effettuato il provisioning degli utenti. La richiesta che esegui sul server delle directory dipenderà dai comandi che il server delle directory fornisce.

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 provisionati da Microsoft Entra ID.

Passaggi successivi

Per ulteriori informazioni su cosa fa il servizio di provisioning, come funziona e le domande frequenti, vedere Automatizzare il provisioning e il deprovisioning degli utenti in applicazioni SaaS con Microsoft Entra ID 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 di utenti in una directory LDAP per l'autenticazione su Linux

Prerequisiti in sede

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

Assicurati che gli utenti da provisionare nella directory dispongano degli attributi necessari.

Conferma degli utenti tramite PowerShell

Raccogli utenti esistenti dalla directory LDAP

Recuperare gli ID degli utenti in Microsoft Entra ID

Assegnare utenti all'applicazione in Microsoft Entra ID

Provisioning dei 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