Configurazione dell'ID Microsoft Entra per il provisioning degli utenti nelle directory LDAP

La documentazione seguente fornisce informazioni sulla configurazione e sull'esercitazione che illustrano come effettuare il provisioning degli utenti da Microsoft Entra ID in una directory LDAP.

Questo documento descrive i passaggi da eseguire per effettuare automaticamente il provisioning e il deprovisioning degli utenti da Microsoft Entra ID in una directory LDAP. Il documento illustra come effettuare il provisioning degli utenti in AD LDS come directory LDAP di esempio, ma è possibile eseguire il provisioning in uno dei server di directory LDAP supportati indicati nelle sezioni seguenti. Il provisioning degli utenti nei servizi Dominio di Active Directory tramite questa soluzione non è supportato.

Per informazioni importanti sul funzionamento di questo servizio 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. Il video seguente offre una panoramica del provisioning locale.

Prerequisiti per il provisioning degli utenti in una directory LDAP

On-premises prerequisites (Prerequisiti locali)

• Applicazione che usa un server di directory per eseguire query agli utenti.
• Directory di destinazione, diversa da Dominio di Active Directory Services, in cui gli utenti possono essere creati, aggiornati ed eliminati. Ad esempio, Active Directory Lightweight Services (AD LDS). Questa istanza di directory non deve essere una directory usata anche per effettuare il provisioning degli utenti nell'ID Microsoft Entra, perché la presenza di entrambi gli scenari può creare un ciclo con Microsoft Entra Connect.
• 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à alla 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 su un proxy.
• .NET Framework 4.7.2 deve essere installato.
• Facoltativo: anche se non è obbligatorio, è consigliabile scaricare Microsoft Edge per Windows Server e usarlo sul posto di Internet Explorer.

Server directory LDAP supportati

Il connettore si basa su varie tecniche per rilevare e identificare il server LDAP. Il connettore usa root DSE, nome fornitore/versione e controlla lo schema per trovare oggetti e attributi univoci noti per esistere in determinati server LDAP.

• OpenLDAP
• Microsoft Active Directory Lightweight Directory Services
• 389 Directory Server
• Apache Directory Server
• IBM Tivoli DS
• Isode Directory
• NetIQ eDirectory
• Novell eDirectory
• Open DJ
• Open DS
• Oracle (in precedenza Sun ONE) Directory Server Enterprise Edition
• RadiantOne Virtual Directory Server (VDS)

Per altre informazioni, vedere Informazioni di riferimento sul connettore LDAP generico.

Requisiti del cloud

• Un tenant di Microsoft Entra con una licenza P1 o Premium P2 di Microsoft Entra ID (oppure 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 Amministratore identità ibrida per la configurazione dell'agente di provisioning e dei ruoli Amministratore applicazione o Amministratore applicazione cloud per la configurazione del provisioning nel portale di Azure.

• 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. Ad esempio, se il server di directory richiede a ogni utente di avere un numero univoco compreso tra 10000 e 30000 come numero ID utente per supportare un carico di lavoro POSIX, è necessario generare tale numero da un attributo esistente nell'utente oppure estendere lo schema di Microsoft Entra e popolare tale attributo per gli utenti nell'ambito dell'applicazione basata su LDAP. 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 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 Microsoft Entra ID a Dominio di Active Directory s Services non è supportato.
• 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.

Selezione dei profili di esecuzione

Quando si crea la configurazione per l'interazione del connettore con un server di directory, si configurerà prima per il connettore per leggere lo schema della directory, eseguire il mapping dello schema a quello di Microsoft Entra ID e quindi configurare l'approccio che il connettore deve usare in modo continuativo tramite profili di esecuzione. Ogni profilo di esecuzione che verrà configurato specifica come il connettore genererà richieste LDAP per importare o esportare dati dal server di directory. Prima di distribuire il connettore in un server di directory esistente, è necessario discutere con l'operatore del server di directory nell'organizzazione il modello di operazioni che verranno eseguite con il server di directory.

• Dopo la configurazione, all'avvio del servizio di provisioning, eseguirà automaticamente le interazioni configurate nel profilo di esecuzione Importazione completa. In questo profilo di esecuzione il connettore leggerà tutti i record per gli utenti dalla directory usando un'operazione di ricerca LDAP. Questo profilo di esecuzione è necessario in modo che in un secondo momento, se Microsoft Entra ID deve apportare una modifica per un utente, Microsoft Entra ID aggiornerà un oggetto esistente per tale utente nella directory, invece di creare un nuovo oggetto per tale utente.

• Ogni volta che vengono apportate modifiche in Microsoft Entra ID, ad esempio per assegnare un nuovo utente all'applicazione o aggiornare un utente esistente, il servizio di provisioning eseguirà le interazioni LDAP nel profilo di esecuzione esportazione . Nel profilo di esecuzione di esportazione, Microsoft Entra ID emette richieste LDAP per aggiungere, modificare, rimuovere o rinominare oggetti nella directory, per portare il contenuto della directory sincronizzato con Microsoft Entra ID.

• Se la directory lo supporta, è anche possibile configurare facoltativamente un profilo di esecuzione di importazione delta. In questo profilo di esecuzione, Microsoft Entra ID leggerà le modifiche apportate nella directory, diverse da Microsoft Entra ID, dall'ultima importazione completa o differenziale. Questo profilo di esecuzione è facoltativo perché la directory potrebbe non essere stata configurata per supportare un'importazione differenziale. Ad esempio, se l'organizzazione usa OpenLDAP, OpenLDAP deve essere stato distribuito con la funzionalità di sovrapposizione dei log di accesso abilitata.

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 due directory, per AD LDS e per OpenLDAP.

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 si definiranno 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. Ad esempio, un server di directory OpenLDAP 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 directory, in cui ogni oggetto per ogni 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 è già presente 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 le applicazioni che usano tale server di directory gestiranno l'autenticazione. L'approccio consigliato consiste nell'usare una federazione o un protocollo SSO, ad esempio SAML, OAuth o OpenID Connect per eseguire l'autenticazione con Microsoft Entra ID e basarsi solo sul server di directory per gli attributi. Le directory LDAP tradizionalmente possono essere usate dalle applicazioni per autenticare gli utenti controllando una password, ma questo caso d'uso non è possibile per l'autenticazione a più fattori o quando l'utente è già stato autenticato. Alcune applicazioni possono eseguire query sulla chiave pubblica o sul certificato SSH di un utente dalla directory, che potrebbe essere appropriata per gli utenti che contengono già le credenziali di tali moduli. Tuttavia, se l'applicazione che si basa sul server di 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.

Preparare la directory LDAP

Se non si dispone già di un server di directory e si vuole provare questa funzionalità, Preparare Active Directory Lightweight Directory Services per il provisioning da Microsoft Entra ID illustra come creare un ambiente AD LDS di test. Se è già stato distribuito un altro server di directory, è possibile ignorare questo articolo e continuare a installare e configurare l'host del connettore ECMA.

Installare e configurare Microsoft Entra Connect Provisioning Agent

Se l'agente di provisioning è già stato scaricato e configurato per un'altra applicazione locale, continuare la lettura nella sezione successiva.

1. Accedere al portale di Azure.
2. Passare ad Applicazioni aziendali e selezionare Nuova applicazione.
3. Cercare l'applicazione App ECMA locale, assegnare un nome all’app e selezionare Crea per aggiungerla al tenant.
4. Dal menu, passare alla pagina Provisioning dell'applicazione.
5. Seleziona Inizia.
6. Alla pagina Provisioning, modificare la modalità ad Automatico.

7. In Connettività localeselezionare Scaricare e installare, quindi selezionare Accettare i termini e scaricare.

8. Lasciare il portale e aprire il programma di installazione dell'agente di provisioning, accettare le condizioni d’uso e selezionare Installa.
9. Attendere la configurazione guidata dell'agente di provisioning di Microsoft Entra, quindi selezionare Avanti.
10. Nel passaggio Seleziona estensione, selezionare Provisioning delle applicazioni locali, quindi Avanti.
11. L'agente di provisioning utilizzerà il browser web del sistema operativo per visualizzare una finestra popup per l'autenticazione a Microsoft Entra ID e potenzialmente anche al 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.
12. Quando viene richiesta l’autorizzazione, specificare le credenziali di un amministratore di Microsoft Entra. L'utente deve avere almeno il ruolo di amministratore dell'identità ibrida.
13. Selezionare Conferma per confermare l’impostazione. Al termine dell'installazione, è possibile selezionare Uscire e chiudere anche il programma di installazione del pacchetto dell'agente di provisioning.

Configurare un’app ECMA locale

1. Nella sezione Connettività locale del portale selezionare l'agente distribuito e selezionare Assegna agente/i.

   

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

1. Nel 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 al fine di creare i registri eventi di Windows necessari.
2. 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.
3. Seleziona Salva.

Configurare un connettore LDAP generico

A seconda delle opzioni selezionate, alcune schermate della procedura guidata potrebbero non essere disponibili e le informazioni potrebbero variare leggermente. Ai fini di questa configurazione di esempio, viene visualizzato il provisioning degli utenti con la classe oggetto User per AD LDS e la classe di oggetti inetOrgPerson per OpenLDAP. Usare le informazioni seguenti come linee guida per la configurazione.

1. Generare un token segreto che verrà usato per l'autenticazione di Microsoft Entra ID nel connettore. Esso deve contenere almeno 12 caratteri 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]$_})
   

2. Se non è già stato fatto, avviare la Configurazione guidata Microsoft ECMA2Host dal menu Start.

3. Selezionare Nuovo connettore.
   

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

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

5. Nella pagina Connettività verrà configurato il modo in cui l'host del connettore ECMA comunicherà con il server 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 TLSo 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 per AD LDS, il nome utente di esempio è CN=svcAccount,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab e per OpenLDAP, 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 in AD LDS o l'altro server di directory sia abilitato.

6. Nella pagina Globale si configurerà il nome distinto del log delle modifiche differenziali, se necessario, e le 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.
   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 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 .

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

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

9. Nella pagina Esporta lasciare invariate le impostazioni predefinite e fare clic su Avanti.

10. Nella pagina Importazione completa lasciare invariate le impostazioni predefinite e fare clic su Avanti.

11. Se presente, nella pagina DeltaImport lasciare invariate le impostazioni predefinite e fare clic su Avanti.

12. Nella pagina Tipi 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. Ad esempio, inetOrgPerson per OpenLDAP o User per AD LDS. 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 utilizzando questo attributo dopo il ciclo iniziale. Per AD LDS, usare ObjectGUIDe per altri server di directory, vedere la tabella seguente. Si noti che il nome distinto 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, ad esempio objectGUID se AD LDS è il server di directory o _distinguishedName se OpenLDAP.
    DN	DistinguishedName dell'oggetto di destinazione. Mantenere -dn-.
    Generato automaticamente	unchecked

    La tabella seguente elenca i server LDAP e l'ancoraggio in uso:

    Directory	Ancora
    Microsoft AD LDS e Catalogo globale Active Directory	objectGUID. È necessario usare l'agente versione 1.1.846.0 o successiva per ObjectGUID essere usato come ancoraggio.
    389 Directory Server	dn
    Apache Directory	dn
    IBM Tivoli DS	dn
    Isode Directory	dn
    Novell/NetIQ eDirectory	GUID
    Open DJ/DS	dn
    Open LDAP	dn
    Oracle ODSEE	dn
    RadiantOne VDS	dn
    Sun One Directory Server	dn

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

    Se si usa OpenLDAP con lo schema inetOrgPerson, configurare la visibilità per gli attributi seguenti.

    Attributo	Considera come valore singolo
    cn	Y
    mail	Y
    objectClass
    sn	Y
    userPassword	Y

    Se si usa OpenLDAP con lo schema POSIX, 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.

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

15. 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 letto tutti gli utenti esistenti dal server di directory nell'host del connettore.

1. Nel server in cui è in esecuzione l'host del connettore Microsoft Entra ECMA, selezionare Avvia.
2. Selezionare eseguire, se necessario, quindi immettere services.msc nella casella.
3. Nell'Elenco servizi, assicurarsi che Microsoft ECMA2Host sia presente e in esecuzione. Se non è in esecuzione, selezionare Avvia.
4. 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.
5. Nel server in cui è in esecuzione l'host del connettore Microsoft Entra ECMA, lanciare PowerShell.
6. Passare alla cartella in cui è stato installato l'host ECMA, ad esempio C:\Program Files\Microsoft ECMA2Host.
7. Passare alla sottodirectory Troubleshooting.
8. Eseguire lo script TestECMA2HostConnection.ps1 in tale directory come illustrato nell'esempio seguente 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: ************
   

9. 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.
10. 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.
11. 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 eseguire il provisioning, Microsoft Entra ID potrebbe non abbinare correttamente gli utenti della directory di origine con quelli di 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

1. Tornare alla finestra del Web browser in cui si stava 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. Passare ad Applicazioni aziendali e andare all’applicazione App ECMA locale.
   3. Fare clic su Provisioning.
   4. Se appare Attività iniziali, modificare la modalità in Automatica, quindi nella sezione Connettività locale selezionare l'agente appena distribuito e selezionare Assegna agente/i, dopodiché attendere 10 minuti. In caso contrario, passare a Modifica provisioning.

2. Nella sezione Credenziali amministratore, inserire 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 tenant	https://localhost:8585/ecma2host_connectorName/scim

3. Immettere il valore del Token segreto definito al momento della creazione del connettore.

   Nota

   Se l'agente è stato appena assegnato all'applicazione, attendere 10 minuti perché la registrazione sia completata. 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 proprio server, cercare servizi nella barra di ricerca di Windows, identificare il servizio Agente di provisioning di Microsoft Entra Connect, fare clic con il pulsante destro del mouse sul servizio e riavviare.

4. Selezionare Test connessione e attendere un minuto.

5. Dopo che il test di connessione ha esito positivo e indica che le credenziali fornite sono autorizzate ad abilitare il provisioning, selezionare Salva.
   

Estendere lo schema Microsoft Entra (facoltativo)

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, sarà necessario generare tale attributo da altri attributi dell'utente tramite un'espressione o 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.

1. Nell'interfaccia di amministrazione di Microsoft Entra, in Applicazioni aziendali selezionare l'applicazione app ECMA locale e quindi selezionare la pagina Provisioning .

2. Selezionare Modifica provisioning.

3. Espandere Mapping e selezionare Effettua il provisioning degli utenti Microsoft Entra. Se questa è la prima volta che sono stati configurati i mapping degli attributi per questa applicazione, sarà presente un solo mapping per un segnaposto.

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

5. 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 nell'esempio seguente 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, se si esegue il provisioning in AD LDS: Join("", "CN=", Word([userPrincipalName], 1, "@"), ",CN=CloudUsers,CN=App,DC=Contoso,DC=lab")
   • Espressione, se si esegue il provisioning in OpenLDAP: 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

6. 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 questo esempio di provisioning in AD LDS, il mapping objectClass di non è necessario, ma potrebbe essere necessario per altri server di directory o altri schemi. Per aggiungere un mapping per objectClass, selezionare Aggiungi nuovo mapping. Usare i valori nell'esempio seguente 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 inetOrgPerson: Split("inetOrgPerson",",")
   • 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

7. Se si esegue il provisioning in AD LDS ed è presente un mapping da userPrincipalName a PLACEHOLDER, fare clic su tale mapping e modificarlo. Usare i valori seguenti per aggiornare il mapping.

   • Tipo di mapping: diretto
   • Attributo di origine: userPrincipalName
   • Attributo di destinazione: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPrincipalName
   • Precedenza corrispondente: 1
   • Applica questo mapping: solo durante la creazione di oggetti

8. Se si esegue il provisioning in AD LDS, aggiungere un mapping per isSoftDeleted. Selezionare Aggiungi nuovo mapping. Usare i valori seguenti per creare il mapping.

   • Tipo di mapping: diretto
   • Attributo di origine: isSoftDeleted
   • Attributo di destinazione: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:msDS-UserAccountDisabled

9. 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, è necessario modificare il mapping per l'attributo in comune per impostare gli oggetti Match usando questo attributo per tale attributo. Altre informazioni sul mapping degli attributi sono disponibili qui.

   Per AD LDS:

   Tipo di mapping	Attributo di origine	Attributo di destinazione
   Connessione diretta	displayName	urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:displayName

   Per OpenLDAP:

   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

   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
   Espressione	ToLower(Word([userPrincipalName], 1, "@"), )	urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uid
   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

10. Se si esegue il provisioning in una directory diversa da AD LDS, aggiungere un mapping a urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword che imposta una password casuale iniziale per l'utente. Per AD LDS, non esiste alcun mapping per userPassword.

11. Seleziona Salva.

Assicurarsi che gli utenti di cui eseguire il provisioning nell'applicazione dispongano degli attributi necessari in Microsoft Entra ID

Se sono presenti utenti che dispongono di 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, 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.

È possibile usare i cmdlet di PowerShell di Microsoft Graph per automatizzare il controllo degli utenti per gli attributi necessari.

Si supponga, ad esempio, che il provisioning richieda agli utenti tre attributi DisplayNameesurname extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty. È 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.

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

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

$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

Molte directory LDAP, ad esempio Active Directory, includono un comando che restituisce un elenco di utenti.

1. Identificare quali utenti di tale directory rientrano nell'ambito per essere utenti dell'applicazione. Questa scelta dipenderà dalla configurazione dell'applicazione. Per alcune applicazioni, qualsiasi utente presente in una directory LDAP è un utente valido. Per altre applicazioni potrebbe essere necessario che l'utente disponga di un attributo specifico o di un membro di un gruppo in tale directory.

2. Eseguire il comando che recupera il subset di utenti dalla directory LDAP. 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 e indirizzo di posta elettronica.

   Ad esempio, questo comando in Windows che usa il programma AD LDS csvde genera un file CSV nella directory del file system corrente con l'attributo userPrincipalName di ogni persona nella directory:

   $out_filename = ".\users.csv"
   csvde -f $out_filename -l userPrincipalName,cn -r "(objectclass=person)"
   

3. Se necessario, trasferire il file CSV che contiene l'elenco di utenti in un sistema con i cmdlet di PowerShell di Microsoft Graph installati.

4. Ora che si dispone di un elenco di tutti gli utenti ottenuti dall'applicazione, sarà possibile associare gli utenti dall'archivio dati dell'applicazione 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 Microsoft Graph PowerShell.

La prima volta che l'organizzazione usa questi cmdlet per questo scenario, è necessario avere il 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.

1. Aprire PowerShell.

2. Se non sono già installati i moduli di Microsoft Graph PowerShell, 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
   

3. Connettersi a Microsoft Entra ID:

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

4. Se è la prima volta che è stato usato questo comando, potrebbe essere necessario fornire il consenso per permettere agli strumenti della riga di comando di Microsoft Graph di avere queste autorizzazioni.

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

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

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

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

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

10. 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
    • Il 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. Il valore di userPrincipalName deve essere univoco tra tutti gli utenti nella directory.

    Ad esempio, in un database potrebbero essere presenti utenti per 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 di 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 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
       }
    }
    

11. 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 gli utenti a un'applicazione

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

Se nella directory LDAP sono presenti utenti esistenti, è necessario creare assegnazioni di ruolo dell'applicazione per gli utenti esistenti in Microsoft Entra ID. 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.

In caso contrario, se la directory LDAP è vuota, selezionare un utente di test da Microsoft Entra ID con gli attributi necessari e verrà effettuato il provisioning nel server di directory dell'applicazione.

1. Assicurarsi che l'utente selezioni tutte le proprietà di cui verrà eseguito il mapping agli attributi necessari dello schema del server di directory.
2. Nel portale di Azure selezionare Applicazioni aziendali.
3. Selezionare l'applicazione App ECMA locale.
4. Nel riquadro sinistro, in Gestisci, fare clic su Utenti e gruppi.
5. Selezionare Aggiungi utente/gruppo.
6. In Utenti, selezionare Nessun utente selezionato.
7. Selezionare un utente a destra e selezionare il pulsante Seleziona .
   
8. Ora, selezionare Assegna.

Test del provisioning

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

1. Nel server in cui è in esecuzione l'host del connettore Microsoft Entra ECMA selezionare Avvia.

2. Immettere esegui, quindi inserire services.msc nella casella di ricerca.

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

4. Nel portale di Azure selezionare Applicazioni aziendali.

5. Selezionare l'applicazione App ECMA locale.

6. A sinistra, selezionare Provisioning.

7. Selezionare Provisioning su richiesta.

8. Cercare uno degli utenti di test e selezionare Effettua il provisioning.
   

9. Dopo alcuni secondi, verrà 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.

1. Nella portale di Azure selezionare l'applicazione.
2. Nel riquadro sinistro, in Gestisci, fare clic su Utenti e gruppi.
3. Assicurarsi che tutti gli utenti siano assegnati al ruolo applicazione.
4. Tornare alla pagina di configurazione del provisioning.
5. Assicurarsi che l'ambito sia impostato solo su utenti e gruppi assegnati, attivare lo stato del provisioning e selezionare Salva.
6. Attendere alcuni minuti per l'avvio del provisioning. Può richiedere fino a 40 minuti. Al termine del processo di provisioning, come descritto nella sezione successiva,

Risoluzione degli errori relativi al 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 consigli.

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 AD LDS.

1. Aprire Server Manager e selezionare AD LDS a sinistra.
2. Fare clic con il pulsante destro del mouse sull'istanza di AD LDS e selezionare ldp.exe dal popup.
   
3. Nella parte superiore di ldp.exe selezionare Connessione e connessione.
4. Immettere le informazioni seguenti e fare clic su OK.
   • Server: APP3
   • Porta: 636
   • Inserire un segno di spunta nella casella SSL
     
5. Nella parte superiore, in Connessione selezionare Associa.
6. Lasciare le impostazioni predefinite e fare clic su OK.
7. Nella parte superiore selezionare Visualizza e albero
8. Per BaseDN immettere CN=App,DC=contoso,DC=lab e fare clic su OK.
9. A sinistra espandere il DN e fare clic su CN=CloudUsers,CN=App,DC=contoso,DC=lab. Dovrebbero essere visualizzati gli utenti di cui è stato effettuato il provisioning da Microsoft Entra ID.
   

Le istruzioni seguenti illustrano come controllare OpenLDAP.

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

Passaggi successivi

• Provisioning di app
• Esercitazione: connettore SQL generico per l'host del connettore ECMA