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

  • Articolo

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é con entrambi gli scenari è possibile creare un ciclo con Microsoft Entra Connessione.
  • 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 dietro 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 D edizione Standard, 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
  • Server directory Oracle (in precedenza Sun ONE) edizione Enterprise
  • RadiantOne Virtual Directory Server (VDS)

Per altre informazioni, vedere informazioni di riferimento sul Connessione or LDAP generico.

Requisiti cloud

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

    L'uso di questa funzionalità richiede licenze microsoft Entra ID P1. Per trovare la licenza corretta per le proprie esigenze, vedere il confronto delle funzionalità di Microsoft Entra ID disponibili a livello generale.

  • Ruolo Amministrazione istrator dell'identità ibrida per la configurazione dell'agente di provisioning e dell'applicazione Amministrazione istrator o dei ruoli Amministrazione istrator dell'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 in che modo il Connessione or Microsoft Entra LDAP interagisce 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.

Impostazione di configurazione Posizione in cui è impostato il valore Valore di esempio
hostname del server di directory Pagina configurazione guidata Connessione ivity APP3
numero di porta del server directory Pagina configurazione guidata Connessione ivity 636. Per LDAP su SSL o TLS (LD piattaforma di strumenti analitici), usare la porta 636. Per Start TLSusare la porta 389.
account per il connettore per identificarsi con il server di directory Pagina configurazione guidata Connessione ivity Per AD LDS CN=svcAccountLDAP,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab e per OpenLDAP, cn=admin,dc=contoso,dc=lab
password per il connettore per l'autenticazione al server di directory Pagina configurazione guidata Connessione ivity
classe di oggetti strutturali per un utente nel server di directory Pagina Tipi di oggetti della procedura guidata di configurazione Per AD LDS User e per OpenLDAP inetOrgPerson
classi di oggetti ausiliari per un utente nel server directory mapping degli attributi della pagina di provisioning portale di Azure Per OpenLDAP con lo schema posixAccount POSIX eshadowAccount
attributi da popolare in un nuovo utente Configurazione guidata Selezione attributi pagina e mapping degli attributi della pagina di provisioning portale di Azure Per AD LDS msDS-UserAccountDisabled, userPrincipalNamee displayName per OpenLDAP cn, , gidNumberhomeDirectory, mail, uidobjectClasssn, , , uidNumberuserPassword
gerarchia di denominazione richiesta dal server di directory mapping degli attributi della pagina di provisioning portale di Azure Impostare il DN di un utente appena creato come immediatamente seguente CN=CloudUsers,CN=App,DC=Contoso,DC=lab per AD LDS e DC=Contoso,DC=lab per OpenLDAP
attributi per correlare gli utenti tra Microsoft Entra ID e il server di directory mapping degli attributi della pagina di provisioning portale di Azure Per AD LDS, non configurato come questo esempio è per una directory inizialmente vuota e per OpenLDAP, mail
comportamento di deprovisioning quando un utente esce dall'ambito in Microsoft Entra ID Pagina di deprovisioning della procedura guidata di configurazione Eliminare l'utente dal server di directory

L'indirizzo di rete di un server di directory è un nome host e un numero di porta TCP, in genere la porta 389 o 636. Tranne quando il server di directory si trova in modalità condivisa con il connettore nello stesso Server Windows o si usa la sicurezza a livello di rete, le connessioni di rete dal connettore a un server di directory devono essere protette tramite SSL o TLS. Il connettore supporta la connessione a un server di directory sulla porta 389 e l'uso di Start TLS per abilitare TLS all'interno della sessione. Il connettore supporta anche la connessione a un server di directory sulla porta 636 per LD piattaforma di strumenti analitici - 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 è che le applicazioni usino un protocollo di federazione o SSO, ad esempio SAML, OAuth o OpenID Connessione per l'autenticazione con Microsoft Entra ID e si basano 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 Connessione 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 dell'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. Nella pagina Provisioning impostare la modalità su Automatico.

Screenshot della selezione automatica.

  1. In Connessione ivity locale selezionare Scarica e installa e selezionare Accetta termini e download.

Screenshot del percorso di download per l'agente.

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

Configurare l'app ECMA locale

  1. Nella sezione Connessione ivity locale del portale selezionare l'agente distribuito e selezionare Assegna agenti.

    Screenshot che mostra come selezionare e assegnare e agente.

  2. Mantenere aperta questa finestra del browser, mentre si completa il passaggio successivo della configurazione usando la configurazione guidata.

Configurare il certificato host Connessione or di Microsoft Entra ECMA

  1. In Windows Server in cui è installato l'agente di provisioning fare clic con il pulsante destro del mouse sulla Configurazione guidata Microsoft ECMA2Host dal menu Start ed eseguire come amministratore. L'esecuzione come amministratore di Windows è necessaria per la procedura guidata per creare i registri eventi di Windows necessari.
  2. Dopo l'avvio della configurazione host di ECMA Connessione or, 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. Screenshot che mostra la configurazione delle impostazioni.
  3. Seleziona Salva.

Nota

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

Configurare un connettore LDAP generico

A seconda delle opzioni selezionate, alcune schermate della procedura guidata potrebbero non essere disponibili e le informazioni potrebbero essere leggermente diverse. 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 per guidare l'utente nella configurazione.

  1. Generare un token segreto che verrà usato per l'autenticazione dell'ID Microsoft Entra nel connettore. Deve contenere almeno 12 caratteri e univoci per ogni applicazione. Se non si dispone già di un generatore di segreti, è possibile usare un comando di PowerShell come il seguente per generare una stringa casuale di esempio.

    -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})

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

  3. Selezionare Nuovo connettore. Screenshot che mostra la scelta di Nuovo Connessione or.

  4. Nella pagina Proprietà compilare le caselle con i valori specificati nella tabella che segue l'immagine e selezionare Avanti. Screenshot che mostra l'immissione delle proprietà.

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

  5. Nella pagina Connessione ivity si configurerà il modo in cui ecma Connessione or host comunicherà con il server di directory e si impostano alcune delle opzioni di configurazione. Compilare le caselle con i valori specificati nella tabella che segue l'immagine e selezionare Avanti. Quando si seleziona Avanti, il connettore eseguirà una query sul server di directory per la relativa configurazione. Screenshot che mostra la pagina Connessione ivity.

    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 BasicSSL 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 Connessione or 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 l'Connessione or ECMA eseguirà l'autenticazione nel 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 nel D radice D edizione Standard. Se questi controlli non sono elencati, viene visualizzato un avviso. Alcune directory LDAP non elencano tutte le funzionalità nella radice D edizione Standard 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. Screenshot che mostra la pagina Profili di esecuzione.

    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 Connessione or 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 di oggetto compilare le caselle e selezionare Avanti.

    Proprietà Descrizione
    Oggetti di destinazione Questo valore è la classe di oggetti strutturali di un utente nel server di directory LDAP. 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 usando 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. Screenshot che mostra la pagina Seleziona attributi.
    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.

Nota

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

  1. 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 che esegue Microsoft Entra ECMA Connessione or Host selezionare Avvia.
  2. Selezionare Esegui , 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. Screenshot che mostra che il servizio è in esecuzione.
  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 che esegue Microsoft Entra ECMA Connessione or Host avviare 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 effettuare il provisioning, microsoft Entra ID potrebbe non corrispondere correttamente agli utenti in tale directory di origine con gli utenti in Microsoft Entra ID. Attendere alcuni minuti prima che l'host del connettore completi la lettura degli oggetti dal server di directory esistente e quindi rieseguire lo script. Se l'output continua a essere False, controllare la configurazione del connettore e le autorizzazioni nel server directory consentono al connettore di leggere gli utenti esistenti.

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

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

    Nota

    Se si è verificato il timeout della finestra, sarà necessario selezionare nuovamente l'agente.

    1. Accedere al portale di Azure.
    2. Passare ad Applicazioni aziendali e all'applicazione dell'app ECMA locale.
    3. Fare clic su Provisioning.
    4. Se viene visualizzato Get started (Attività iniziali), impostare la modalità su Automatico nella sezione Connessione ivity locale selezionare l'agente appena distribuito e selezionare Assegna agenti e attendere 10 minuti. In caso contrario, passare a Modifica provisioning.

  2. Nella sezione Amministrazione credenziali immettere l'URL seguente. Sostituire la connectorName parte con il nome del connettore nell'host ECMA, ad esempio LDAP. Se è stato fornito un certificato dall'autorità di certificazione per l'host ECMA, sostituire localhost con il nome host del server in cui è installato l'host ECMA.

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

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

    Nota

    Se l'agente è stato appena assegnato all'applicazione, attendere 10 minuti per il completamento della registrazione. Il test di connettività non funzionerà fino al completamento della registrazione. Forzare il completamento della registrazione dell'agente riavviando l'agente di provisioning nel server può velocizzare il processo di registrazione. Passare al server, cercare i servizi nella barra di ricerca di Windows, identificare il servizio Microsoft Entra Connessione Provisioning Agent, fare clic con il pulsante destro del mouse sul servizio e riavviare.

  4. Selezionare Test Connessione ion 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.
    Screenshot che mostra il test di un agente.

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 Microsoft Entra Connessione o Microsoft Entra Connessione cloud sync per configurare che l'attributo deve essere sincronizzato da Dominio di Active Directory Servizi 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 Provisioning utenti di Microsoft Entra. Se questa è la prima volta che sono stati configurati i mapping degli attributi per questa applicazione, per un segnaposto sarà presente un solo mapping.

  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
    Diretto 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
    Diretto (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 DisplayNameesurnameextension_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 PowerShell di Microsoft Graph.

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

  • Utente Amministrazione istrator, se si prevede di creare nuovi utenti.
  • Application Amministrazione istrator o Identity Governance Amministrazione istrator, se si gestiscono solo le assegnazioni di ruolo dell'applicazione.

  1. Aprire PowerShell.

  2. Se i moduli di Microsoft Graph PowerShell non sono già installati, installare il Microsoft.Graph.Users modulo e altri usando questo comando:

    Install-Module Microsoft.Graph

    Se i moduli sono già installati, assicurarsi di usare una versione recente:

    Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications

  3. Connessione 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 consentire 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:

    Assicurarsi che questi nuovi utenti siano popolati con gli attributi necessari per Microsoft Entra ID per associarli in un secondo momento agli utenti esistenti nell'applicazione e gli attributi richiesti dall'ID Microsoft Entra, inclusi userPrincipalName, mailNickname e displayName. Deve userPrincipalName essere univoco tra tutti gli utenti nella directory.

    Ad esempio, si potrebbero avere utenti in un database in cui il valore nella colonna denominata EMail è il valore che si vuole usare come nome dell'entità utente Microsoft Entra, il valore nella colonna Alias contiene il nome alternativo della posta elettronica microsoft Entra ID e il valore nella colonna Full name contiene il nome visualizzato dell'utente:

    $db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"

    È quindi possibile usare questo script per creare utenti di Microsoft Entra per quelli in SAP Cloud Identity Services, nel database o nella directory che non corrispondono agli utenti in Microsoft Entra ID. Si noti che potrebbe essere necessario modificare questo script per aggiungere altri attributi di Microsoft Entra necessari nell'organizzazione o se non è né mailNicknameuserPrincipalName, 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 di Microsoft Entra ECMA Connessione or Host che comunica con Microsoft Entra ID e il mapping degli attributi configurato, è possibile passare alla configurazione di chi è nell'ambito del provisioning.

Importante

Se è stato eseguito l'accesso usando un ruolo di Amministrazione istrator di identità ibrida, è necessario disconnettersi e accedere con un account con il ruolo Application Amministrazione istrator, Cloud Application Amministrazione istrator o Global Amministrazione istrator per questa sezione. Il ruolo Hybrid Identity Amministrazione istrator 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 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. Nella portale di Azure selezionare Applicazioni aziendali.
  3. Selezionare l'applicazione dell'app ECMA locale.
  4. A sinistra, in Gestisci selezionare Utenti e gruppi.
  5. Selezionare Aggiungi utente/gruppo. Screenshot che mostra l'aggiunta di un utente.
  6. In Utenti selezionare Nessuno selezionato. Screenshot che mostra Nessuno selezionato.
  7. Selezionare un utente a destra e selezionare il pulsante Seleziona .
    Screenshot che mostra Selezionare gli utenti.
  8. Selezionare Ora Assegna. Screenshot che mostra Assegna utenti.

Provisioning di test

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

  1. Nel server in cui è in esecuzione Microsoft Entra ECMA Connessione or Host selezionare Avvia.

  2. Immettere run e immettere services.msc nella casella.

  3. Nell'elenco Servizi assicurarsi che sia il servizio Microsoft Entra Connessione Provisioning Agent che i servizi Microsoft ECMA2Host siano in esecuzione. In caso contrario, selezionare Avvia.

  4. Nella portale di Azure selezionare Applicazioni aziendali.

  5. Selezionare l'applicazione dell'app ECMA locale.

  6. A sinistra selezionare Provisioning.

  7. Selezionare Provision on demand (Provision on demand).

  8. Cercare uno degli utenti di test e selezionare Provision (Provision). Screenshot che mostra il test del provisioning su richiesta.

  9. Dopo alcuni secondi, viene visualizzato il messaggio Utente creato correttamente nel sistema di destinazione, con un elenco degli attributi utente. Se viene visualizzato un errore, vedere risoluzione degli errori di provisioning.

Avviare il provisioning degli utenti

Al termine del test del provisioning su richiesta, aggiungere gli utenti rimanenti.

  1. Nella portale di Azure selezionare l'applicazione.
  2. A sinistra, in Gestisci selezionare 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. Potrebbero essere necessari fino a 40 minuti. Al termine del processo di provisioning, come descritto nella sezione successiva,

Risoluzione degli errori di provisioning

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

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

Per altre informazioni, passare alla scheda Risoluzione dei problemi e 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. Screenshot del percorso dello strumento Ldp.
  3. Nella parte superiore di ldp.exe selezionare Connessione ion e Connessione.
  4. Immettere le informazioni seguenti e fare clic su OK.
    • Server: APP3
    • Porta: 636
    • Inserire un segno di spunta nella casella SSL Screenshot che mostra la connessione Ldp per il controllo degli utenti.
  5. Nella parte superiore, in Connessione ion 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. Screenshot che mostra l'associazione Ldp per gli utenti.

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