Pianificare la distribuzione di Microsoft Entra per il provisioning utenti con app di origine e destinazione SAP

Articolo
08/09/2024

L'organizzazione si basa su Microsoft per vari servizi Azure o Microsoft 365. Il software e i servizi SAP possono fornire anche funzioni critiche per l’organizzazione, come risorse umane (HR) e pianificazione delle risorse aziendali (ERP). È possibile usare Microsoft Entra per orchestrare le identità per i dipendenti, i terzisti e altri utenti, e l'accesso tra le applicazioni SAP e non SAP.

Questa esercitazione illustra come usare le funzionalità di Microsoft Entra per gestire le identità tra le applicazioni SAP in base alle proprietà di tali identità provenienti da origini SAP HR. Il tutorial presuppone che:

l'organizzazione disponga di un tenant di Microsoft Entra nel cloud commerciale con una licenza per almeno Microsoft Entra ID P1 in tale tenant. (alcuni passaggi illustrano anche l'uso delle funzionalità di governance di Microsoft Entra ID).
L'utente è un amministratore del tenant in questione.
L'organizzazione ha un sistema di origine record dei lavoratori, ovvero SAP SuccessFactors.
L'organizzazione è dotata di SAP ERP Central Component (ECC), SAP S/4HANA o altre applicazioni SAP e, facoltativamente, dispone di altre applicazioni non SAP.
Si usa SAP Cloud Identity Services per il provisioning e l'accesso Single Sign-On (SSO) a qualsiasi applicazione SAP diversa da SAP ECC.

Panoramica

Questa esercitazione illustra come connettere Microsoft Entra con origini autorevoli per l'elenco dei lavoratori di un'organizzazione, ad esempio SAP SuccessFactors. Viene inoltre mostrato come usare Microsoft Entra per configurare le identità per tali lavoratori. Si apprenderà quindi come usare Microsoft Entra per fornire ai lavoratori l'accesso a una o più applicazioni SAP, ad esempio SAP ECC o SAP S/4HANA.

Il processo è:

Pianificare: definire i requisiti per le identità e l'accesso per le applicazioni nell'organizzazione. Assicurarsi che Microsoft Entra ID e i servizi Microsoft Online correlati soddisfino i prerequisiti dell'organizzazione per questo scenario.
Implementare: portare gli utenti necessari in Microsoft Entra ID e creare un processo per tenere aggiornati tali utenti con le credenziali appropriate. Assegnare agli utenti i diritti di accesso necessari in Microsoft Entra. Effettuare il provisioning di tali utenti e dei relativi diritti di accesso alle applicazioni per consentire loro di accedere a tali applicazioni.
Monitorare: monitorare i flussi di identità per individuare eventuali errori e adeguare le politiche e le operazioni in base alle esigenze.

Al termine del processo, i singoli utenti possono accedere alle applicazioni SAP e non SAP che sono autorizzati a usare con le identità utente di Microsoft Entra.

Il diagramma seguente illustra la topologia di esempio usata in questa esercitazione. In questa topologia i lavoratori sono rappresentati in SuccessFactors e devono avere gli account in un dominio di Windows Server Active Directory (Windows Server AD), in Microsoft Entra, SAP ECC e nelle applicazioni cloud SAP. Questa esercitazione descrive un'organizzazione con un dominio in Windows Server AD. Tuttavia, Windows Server AD non è necessario per questa esercitazione.

Questa esercitazione è incentrata sul ciclo di vita delle identità per gli utenti che rappresentano dipendenti e altri lavoratori. Il ciclo di vita delle identità per gli utenti guest e il ciclo di vita di accesso per assegnazioni di ruolo, richieste e revisioni non rientrano nell'ambito della presente esercitazione.

Pianificare le integrazioni con origini e destinazioni SAP

In questa sezione si definiscono i requisiti per le identità e l'accesso per le applicazioni nell'organizzazione. In questa sezione vengono evidenziate le decisioni chiave necessarie per l'integrazione con le applicazioni SAP. Per le applicazioni non SAP, è possibile anche definire i criteri dell'organizzazione per gestire l'accesso a tali applicazioni.

Se si usa SAP IDM, è possibile eseguire la migrazione degli scenari di gestione delle identità da SAP IDM a Microsoft Entra. Per altre informazioni, vedere Eseguire la migrazione degli scenari di gestione delle identità da SAP IDM a Microsoft Entra.

Determinare la sequenza di onboarding delle applicazioni e il modo in cui le applicazioni si integrano con Microsoft Entra

Forse l'organizzazione ha già integrato alcune applicazioni con Microsoft Entra per un subset degli scenari di integrazione disponibili. Ad esempio, è possibile integrare SAP Cloud Identity Services con Microsoft Entra per l'accesso SSO al fine di ottenere il vantaggio dell'accesso condizionale, ma si fa ancora affidamento sul provisioning e sul deprovisioning manuali. Oppure nell'organizzazione potrebbero essere presenti applicazioni come SAP ECC che non sono ancora state integrate con Microsoft Entra.

Stabilire un ordine di priorità per l'integrazione delle applicazioni con Microsoft Entra per l'accesso SSO e per il provisioning. Le organizzazioni in genere iniziano a integrarsi con applicazioni SaaS (Software as a Service) che supportano protocolli moderni. Per le applicazioni SAP, è consigliabile che le organizzazioni che dispongono di applicazioni cloud SAP avviino le integrazioni con l'accesso Single Sign-On e le integrazioni di provisioning con SAP Cloud Identity Services come middleware. In questo caso, un provisioning degli utenti e l'integrazione SSO a Microsoft Entra può essere utile a più applicazioni SAP.
Verificare l'integrazione di ogni applicazione con Microsoft Entra. Se l'applicazione è elencata come uno dei sistemi di destinazione di provisioning di SAP Cloud Identity Services, ad esempio SAP S/4HANA, è possibile usare SAP Cloud Identity Services come middleware per il bridge SSO e per effettuare il provisioning da Microsoft Entra all'applicazione. Se l'applicazione è SAP ECC, è possibile integrare Microsoft Entra direttamente con SAP NetWeaver per l'SSO e con le Business Application Programming Interfaces (BAPI) di SAP ECC per il provisioning.

Per le applicazioni non SAP, seguire le istruzioni riportate in Integrare l'applicazione con Microsoft Entra ID per determinare le tecnologie di integrazione supportate per l'accesso SSO e il provisioning per ciascuna delle applicazioni.
Raccogliere i ruoli e le autorizzazioni forniti da ogni applicazione. Alcune applicazioni hanno un singolo ruolo. Ad esempio, SAP Cloud Identity Services ha un solo ruolo, Utente, disponibile per l'assegnazione. SAP Cloud Identity Services può leggere i gruppi da Microsoft Entra ID per utilizzarli nell'assegnazione delle applicazioni. Altre applicazioni potrebbero avere più ruoli da gestire tramite Microsoft Entra ID. Questi ruoli dell’applicazione in genere impongono ampi vincoli sull'accesso che un utente con quel ruolo ha all'interno dell'applicazione.

Altre applicazioni potrebbero affidarsi anche alle appartenenze a gruppi o alle rivendicazioni per controlli di ruolo a grana più fine. Possono essere forniti a ciascuna applicazione da Microsoft Entra ID in fase di provisioning o da richieste emesse utilizzando i protocolli SSO di federazione. Inoltre, possono anche essere scritti in Active Directory come appartenenza a gruppi di sicurezza.

Nota

Se si usa un'applicazione della raccolta di applicazioni Microsoft Entra che supporta il provisioning, Microsoft Entra ID potrebbe importare ruoli definiti nell'applicazione e aggiornare automaticamente il manifesto dell'applicazione con i ruoli dell'applicazione dopo la configurazione del provisioning.
Selezionare i ruoli e i gruppi con appartenenza che devono essere regolati in Microsoft Entra ID. In base ai requisiti di conformità e gestione dei rischi, le organizzazioni spesso assegnano priorità a quei ruoli o gruppi dell'applicazione che consentono l'accesso privilegiato o l'accesso alle informazioni riservate. Sebbene questa esercitazione non includa i passaggi per la configurazione dell'assegnazione di accesso, potrebbe essere necessario identificare i ruoli e i gruppi rilevanti per far sì che tutti i loro membri siano assegnati alle applicazioni.

Definire i criteri dell'organizzazione con i prerequisiti utente e altri vincoli per l'accesso a un'applicazione

In questa sezione vengono determinati i criteri dell'organizzazione che si prevede di utilizzare per stabilire l'accesso a ogni applicazione.

Identificare se sono presenti prerequisiti o standard che un utente deve soddisfare prima di poter accedere a un'applicazione. Le organizzazioni con requisiti di conformità o piani di gestione dei rischi sono dotate di applicazioni sensibili o critiche per l'azienda. È possibile che siano già stati documentati i criteri per chi deve avere accesso a tali applicazioni prima dell'integrazione con Microsoft Entra ID. In caso contrario, potrebbe essere necessario consultare gli stakeholder, ad esempio i team di gestione della conformità e dei rischi. È necessario assicurarsi che i criteri utilizzati per automatizzare le decisioni di accesso siano appropriati per lo scenario in uso.

Ad esempio, in circostanze normali, solo i dipendenti a tempo pieno o i dipendenti di un reparto o di un centro di costo specifico possono accedere per impostazione predefinita a una determinata applicazione del reparto. Se si usa la gestione entitlement di Microsoft Entra in Microsoft Entra ID Governance, è possibile scegliere di configurare i criteri di gestione entitlement per un utente di un altro reparto che richiede l'accesso, in modo da avere uno o più responsabili approvazione e che gli utenti possano ottenere l'accesso tramite eccezione.

In alcune organizzazioni, le richieste di accesso da parte di un dipendente potrebbero sottostare a due fasi di approvazione. La prima fase consiste nell'effettuare la richiesta al manager dell'utente. La seconda consiste nell’effettuare la richiesta a uno dei proprietari di risorse responsabili dei dati contenuti nell'applicazione.
Decidere per quanto tempo un utente a cui è stata concessa l’autorizzazione ad accedere può mantenere l’accesso e quando tale accesso può essere revocato. Nel caso di molte applicazioni, un utente potrebbe mantenere l'accesso illimitato fino a quando non fa più parte dell'organizzazione. In alcune situazioni, l'accesso potrebbe essere associato a determinati progetti o attività cardine in modo che, al loro termine, l'accesso venga rimosso automaticamente. In alternativa, se solo pochi utenti usano un'applicazione tramite un criterio, è possibile configurare revisioni trimestrali o annuali dell'accesso di ciascuno tramite i criteri, in modo che sia presente una supervisione a cadenza regolare. Tali scenari necessitano di Microsoft Entra ID Governance.
Se l'organizzazione sta già regolando l'accesso con un modello di ruolo aziendale, pianificare l'inserimento di tale modello di ruolo aziendale in Microsoft Entra ID. Potrebbe essere disponibile un modello di ruolo aziendale definito che assegna l'accesso in base alla proprietà di un utente, ad esempio la posizione o il reparto. Tali processi possono garantire che gli utenti non abbiano più accesso alla fine, quando l'accesso non è più necessario, anche nel caso in cui non esista una data di fine del progetto prestabilita.

Se si ha già una definizione di ruolo dell'organizzazione, è possibile eseguire la migrazione delle definizioni dei ruoli dell'organizzazione a Microsoft Entra ID Governance.
Verificare se sono presenti vincoli basati sulla separazione dei compiti. Questa esercitazione è incentrata sul ciclo di vita delle identità per fornire a un utente l'accesso di base alle applicazioni. Tuttavia, quando si pianifica l'onboarding delle applicazioni, è possibile identificare i vincoli in base alla separazione dei compiti da applicare.

Si supponga, ad esempio, che sia presente un'applicazione con due ruoli dell'app, Vendite Ovest e Vendite Est. Si vuole garantire che un utente abbia un solo ruolo di territorio di vendita alla volta. Includere un elenco di un’eventuale coppia di ruoli dell'app incompatibili per l'applicazione. Quindi, se un utente ha un ruolo, non è autorizzato a richiedere il secondo ruolo. Le impostazioni di incompatibilità della gestione entitlement di Microsoft Entra nei pacchetti di accesso possono far rispettare tali vincoli.
Selezionare i criteri di accesso condizionale appropriati per l'accesso a ogni applicazione. Si consiglia di analizzare le applicazioni e organizzarle in raccolte di applicazioni che presentano gli stessi requisiti di risorse per gli stessi utenti.

La prima volta che si integra un'applicazione SSO federata con Microsoft Entra ID, potrebbe essere necessario creare un nuovo criterio di accesso condizionale per esprimere i vincoli. Potrebbe essere necessario applicare i requisiti per l'autenticazione a più fattori (MFA) o l'accesso basato sulla posizione per l'applicazione in oggetto e le applicazioni successive. Inoltre, nell'accesso condizionale è possibile stabilire che gli utenti debbano accettare le condizioni per l'utilizzo.

Per altre considerazioni su come definire criteri di accesso condizionale, vedere Pianificare una distribuzione dell'accesso condizionale.
Decidere come gestire le eccezioni ai criteri. Ad esempio, un'applicazione potrebbe essere generalmente disponibile solo per i dipendenti designati, ma un revisore o un fornitore potrebbe richiedere l'accesso temporaneo per un progetto specifico. In alternativa, un dipendente itinerante potrebbe richiedere l'accesso da un’area geografica solitamente bloccata perché l'organizzazione non ha alcuna presenza in tale area geografica.

In queste situazioni, se si dispone di Microsoft Entra ID Governance, è possibile anche scegliere un criterio di gestione entitlement per l'approvazione con fasi diverse, limiti temporali diversi o un responsabile approvazione diverso. Un fornitore che ha eseguito l'accesso come utente guest nel tenant di Microsoft Entra potrebbe non avere un manager. Al contrario, uno sponsor dell'organizzazione, un proprietario di risorse o un responsabile della sicurezza potrebbe approvarne le richieste di accesso.

Decidere la topologia di provisioning e autenticazione

Dopo aver determinato le applicazioni da integrare con Microsoft Entra per il provisioning degli utenti e l'SSO, è necessario decidere il flusso di dati per la fornitura delle identità degli utenti e dei loro attributi a tali applicazioni, sulla base dei dati provenienti da origini autorevoli del sistema di registrazione.

Selezionare le fonti autorevoli per ciascuna identità e i relativi attributi. Questa esercitazione presuppone che SuccessFactors sia il sistema autorevole dell'origine record per gli utenti che devono accedere alle applicazioni SAP. La configurazione del provisioning degli utenti basato su risorse umane nel cloud da SuccessFactors a Microsoft Entra ID richiede una pianificazione che tenga conto di diversi aspetti. Questi fattori includono la determinazione dell'ID corrispondente e la definizione dei mapping degli attributi, la trasformazione degli attributi e i filtri di ambito.

Per indicazioni complete su tali argomenti, vedere il piano di distribuzione dell'app HR basata sul cloud. Per informazioni sulle entità supportate, i dettagli di elaborazione e su come personalizzare l'integrazione per scenari HR diversi, vedere la guida di riferimento all'integrazione di SAP SuccessFactors. È inoltre possibile avere altre origini autorevoli per altre identità e alcune identità, ad esempio account break-glass o altri amministratori IT, che dispongono dell'ID Microsoft Entra come origine autorevole.
Decidere se gli utenti esistono o devono essere sottoposti a provisioning in Windows Server AD oltre Microsoft Entra ID. Potrebbero esserci utenti già esistenti in Windows Server AD che corrispondono ai lavoratori nell'origine HR autorevole. O forse è stato configurato SAP ECC o altre applicazioni per basarsi su Windows Server tramite LDAP (Lightweight Directory Access Protocol) o Kerberos. In queste situazioni si effettua il provisioning degli utenti in Windows Server AD. Questi utenti vengono quindi sincronizzati con Microsoft Entra ID.
Progettare la topologia di distribuzione dell'agente di provisioning di Microsoft Entra Connect. Se si usa SuccessFactors e si dispone di Windows Server AD, sarà necessario installare l'agente di provisioning per effettuare il provisioning degli utenti in tali domini. La topologia di distribuzione dell'agente di provisioning di Microsoft Entra Connect dipende dal numero di tenant dell'app HR cloud e dai domini figlio di Active Directory che si prevede di integrare. Se sono presenti più domini di Active Directory, dipende dal fatto che i domini di Active Directory siano contigui o non contigui. Per altre informazioni, vedere Progettare la topologia di distribuzione dell'agente di provisioning di Microsoft Entra Connect.
Determinare se si usano più contenitori in Windows Server AD. Se si usa SuccessFactors e si dispone di Windows Server AD, in ogni dominio sarà necessario determinare se gli utenti che rappresentano i ruoli di lavoro sono organizzati in una gerarchia di contenitori. Alcune organizzazioni possono creare tutti gli utenti che rappresentano i dipendenti in un'unica; organizationalUnitaltre organizzazioni possono avere più. Per altre informazioni, vedere Configurare l'assegnazione di contenitori di unità organizzative di Active Directory.
Decidere se si desidera usare Microsoft Entra ID per effettuare il provisioning in SAP Cloud Identity Services oppure utilizzare SAP Cloud Identity Services per leggere da Microsoft Entra ID. Per altre informazioni sulle funzionalità di provisioning di Microsoft Entra, vedere Automatizzare il provisioning e il deprovisioning degli utenti in SAP Cloud Identity Services con Microsoft Entra ID. SAP Cloud Identity Services ha anche un connettore separato per leggere utenti e gruppi da Microsoft Entra ID. Per altre informazioni, vedere SAP Cloud Identity Services - Identity Provisioning - Microsoft Entra ID come sistema di origine.
Stabilire se è necessario effettuare il provisioning degli utenti in SAP ECC. È possibile effettuare il provisioning degli utenti da Microsoft Entra ID in SAP ECC (in precedenza SAP R/3) NetWeaver 7.0 o versione successiva. Se si usano altre versioni di SAP R/3, è comunque possibile usare le guide fornite nei Connettori per Microsoft Identity Manager 2016 scaricare come riferimento per creare un modello personalizzato per il provisioning.

Assicurarsi che i prerequisiti dell'organizzazione siano soddisfatti prima di configurare Microsoft Entra ID

Prima di iniziare il processo di provisioning dell'accesso alle applicazioni business critical da Microsoft Entra ID, accertarsi che l'ambiente Microsoft Entra sia configurato correttamente.

Assicurarsi che l'AMBIENTE Microsoft Entra ID e Microsoft Online Services sia pronto per i requisiti di conformità per le applicazioni. La conformità è una responsabilità condivisa tra Microsoft, provider di servizi cloud e organizzazioni.
Assicurarsi che il tenant di Microsoft Entra ID sia adeguatamente concesso in licenza. Per usare Microsoft Entra ID al fine di automatizzare il provisioning, il tenant deve disporre di tutte le licenze per Microsoft Entra ID P1 come requisito minimo, perché sono presenti lavoratori originati dall'applicazione HR di origine o dagli utenti membri (nonguest) di cui è stato effettuato il provisioning.

Inoltre, l'uso di Flussi di lavoro del ciclo di vita e altre funzionalità di governance di Microsoft Entra ID, come i criteri di assegnazione automatica della gestione entitlement di Microsoft Entra nel processo di provisioning, richiede licenze di governance di Microsoft Entra ID per i lavoratori. Tali licenze sono Microsoft Entra ID Governance o Microsoft Entra ID Governance aggiornato a Microsoft Entra ID P2.
Verificare che Microsoft Entra ID invii già il log di controllo e, facoltativamente, altri log a Monitoraggio di Azure. Monitoraggio di Azure è facoltativo ma utile per gestire l'accesso alle app perché Microsoft Entra archivia gli eventi di controllo solo per un massimo di 30 giorni nel suo log di controllo. È possibile mantenere i dati di controllo per più tempo rispetto a tale periodo di conservazione predefinito. Per altre informazioni, vedere Per quanto tempo Microsoft Entra ID archivia i dati dei report?.

È inoltre possibile usare cartelle di lavoro di Monitoraggio di Azure e query e report personalizzati sui dati di controllo storici. È possibile controllare la configurazione di Microsoft Entra per verificare se usa Monitoraggio di Azure in Microsoft Entra ID, andando nell'interfaccia di amministrazione di Microsoft Entra e selezionando Cartelle di lavoro. Se questa integrazione non è configurata, si dispone di una sottoscrizione ad Azure e si ricopre almeno il ruolo di amministratore della sicurezza, è possibile configurare Microsoft Entra ID per l'uso di Monitoraggio di Azure.
Accertarsi che solo gli utenti autorizzati si trovino nei ruoli amministrativi dotati di privilegi elevati all’interno del tenant di Microsoft Entra. Gli amministratori che sono almeno amministratore di Identity Governance, amministratore utenti, amministratore applicazioni, amministratore applicazioni cloud o amministratore ruolo con privilegi possono apportare modifiche agli utenti e alle assegnazioni di ruolo dell'applicazione. Se di recente non sono state esaminate le appartenenze di tali ruoli, è necessario un utente che sia almeno un amministratore del ruolo con privilegi per assicurarsi che la verifica di accesso di questi ruoli della directory sia stato avviato.

Inoltre, è consigliabile esaminare gli utenti nei ruoli di Azure nelle sottoscrizioni che contengono Monitoraggio di Azure, App per la logica e altre risorse necessarie per il funzionamento della configurazione di Microsoft Entra.
Verificare che il tenant abbia un isolamento appropriato. Se l'organizzazione usa Active Directory locale e questi domini di Active Directory sono connessi a Microsoft Entra ID, è necessario accertarsi che le operazioni amministrative con privilegi elevati per i servizi ospitati nel cloud siano isolate dagli account locali. Assicurarsi di aver effettuato la configurazione per proteggere l'ambiente cloud di Microsoft 365 da compromissioni locali.
Valutare l'ambiente in base alle procedure consigliate per la sicurezza. Per valutare come proteggere il tenant di Microsoft Entra ID, vedere Procedure consigliate per tutte le architetture di isolamento.
Documentare la durata del token e le impostazioni di sessione dell'applicazione. Al termine di questa esercitazione, si integreranno applicazioni SAP ECC o SAP Cloud Identity Services con Microsoft Entra per SSO. Per quanto tempo un utente al quale è stato negato l'accesso continuato può proseguire a usare un'applicazione federata dipende dalla durata della sessione dell'applicazione e dalla durata del token di accesso. La durata della sessione per un'applicazione dipende dall'applicazione stessa. Per altre informazioni sul controllo della durata dei token di accesso, vedere Durata dei token configurabili.

Verificare che SAP Cloud Identity Services disponga dei mapping dello schema necessari per le applicazioni

Ciascuna delle applicazioni SAP dell'organizzazione potrebbe avere dei requisiti che impongono agli utenti di tali applicazioni il popolamento di determinati attributi al momento del provisioning nell'applicazione.

Se si usa SAP Cloud Identity Services per eseguire il provisioning in SAP S/4HANA o in altre applicazioni SAP, assicurarsi che SAP Cloud Identity Services disponga dei mapping per inviare questi attributi da Microsoft Entra ID in tali applicazioni tramite SAP Cloud Identity Services. Se non si utilizza SAP Cloud Identity Services, passare alla sezione successiva.

Assicurarsi che la directory cloud SAP abbia lo schema utente richiesto dalle applicazioni cloud SAP. In SAP Cloud Identity Services, ogni sistema di destinazione configurato aggiunge trasformazioni dal modello di dati dell'origine per le identità fornite a SAP Cloud Identity Services ai requisiti della destinazione. Potrebbe essere necessario modificare tali trasformazioni in SAP Cloud Identity Services così che corrispondano al modo in cui si prevede di modellare l'identità, soprattutto se sono configurati più sistemi di destinazione. Registrare quindi lo schema necessario per Microsoft Entra per fornire alle applicazioni cloud SAP tramite SAP Cloud Identity Services.

Definire la relazione tra record di lavoro nel sistema di origini record e utenti in Microsoft Entra

Ogni attributo richiesto dalle applicazioni deve provenire da un'origine all’interno dell'organizzazione. Alcuni attributi possono avere valori costanti o che vengono trasformati da altri attributi. Altri valori possono essere assegnati da un servizio online Microsoft, ad esempio l'indirizzo di posta elettronica di un utente. Altri attributi, ad esempio il nome, il reparto o altre proprietà dell'organizzazione di un utente, hanno in genere origine in un sistema di risorse umane di record autorevole. Per garantire che i record HR corretti vengano mappati agli utenti in Microsoft Entra ID, collaborare con i team HR e IT per garantire la coerenza dei dati e pianificare le attività di pulizia dei dati.

Determinare come eseguire il mapping delle modifiche nel sistema dell'origine record per creare un join e lasciare eventi. Se si desidera automatizzare i processi per l'aggiunta e l'uscita del ruolo di lavoro, è necessario correlare le informazioni sullo stato di un ruolo di lavoro agli attributi in Microsoft Entra. Per altre informazioni, determinare lo stato dell'account utente.
Assicurarsi che l'origine HR disponga dello schema di lavoro in grado di fornire lo schema necessario per tali applicazioni SAP. Assicurarsi che ogni attributo obbligatorio di un'applicazione sap cloud o locale, che non ha origine in Microsoft Entra o in un altro servizio online Microsoft, possa essere monitorato in una proprietà disponibile dall'origine, ad esempio SuccessFactors. Se l'origine non ha lo schema richiesto, o gli attributi non sono popolati su una o più identità che avranno accesso alle applicazioni, o non sono disponibili per la lettura da parte di Microsoft Entra, è necessario soddisfare questi requisiti di schema prima di abilitare il provisioning.
Registrare lo schema usato per la correlazione tra Microsoft Entra ID e i sistemi di record. Potrebbero essere presenti utenti esistenti in Windows Server AD o Microsoft Entra ID che corrispondono ai ruoli di lavoro in SAP SuccessFactors. Se questi utenti non sono stati creati dall'ID Microsoft Entra, ma da un altro processo, vedere il riferimento all'attributo SAP SuccessFactors e lo schema utente di Windows Server o Microsoft Entra per selezionare gli attributi sugli oggetti utente contenenti un identificatore univoco per il ruolo di lavoro in SAP SuccessFactors.

Questo attributo deve essere presente con un valore univoco per ogni utente che corrisponde a un ruolo di lavoro, in modo che il provisioning in ingresso di Microsoft Entra possa determinare quali utenti esistono già per i ruoli di lavoro ed evitare di creare utenti duplicati. L'attributo di corrispondenza predefinito è basato sull'ID dipendente. Prima di importare i ruoli di lavoro dall'origine HR, è necessario assicurarsi che il valore di questo attributo, ad esempio l'ID dipendente, venga popolato in Microsoft Entra ID (per gli utenti solo cloud) e Windows Server AD (per gli utenti ibridi) prima di avviare la sincronizzazione completa e il relativo valore identifica in modo univoco ogni utente. Per altre informazioni, vedere Determinare gli attributi corrispondenti e generare un valore di attributo univoco.
Selezionare filtri di ambito per ignorare i record HR che non sono più pertinenti. I sistemi HR hanno diversi anni di dati sull'occupazione, inclusi i lavoratori che non sono dipendenti da anni. D'altra parte, il team IT può essere interessato solo all'elenco dei dipendenti attualmente attivi, dei nuovi assunti e dei record di terminazione che arrivano dopo il go-live. Per filtrare i record HR che non sono più rilevanti per il team IT, collaborare con il team HR per aggiungere flag al record HR che possano essere usati nei filtri di ambito per il provisioning di Microsoft Entra. Per altre informazioni, vedere Definire i filtri di ambito.
Pianificare la gestione di caratteri speciali che possono formare il nome utente di un nuovo utente. È pratica comune usare il nome e il cognome del lavoratore per creare un userPrincipalName univoco per l'utente. In Windows Server AD e Microsoft Entra ID, non userPrincipalName consente caratteri accentati e sono consentiti A - Z, a - z, 0 - 9, ' . - _ ! # ^ ~solo i caratteri seguenti. Usare la funzione NormalizeDiacritics per gestire i caratteri accento e costruire il userPrincipalName appropriato.
Pianificare la gestione di stringhe lunghe provenienti dall'origine HR. Controllare se i dati HR hanno valori stringa lunghi associati ai campi HR che verranno usati per popolare gli attributi microsoft Entra ID e Windows Server AD. Ogni attributo Microsoft Entra ID ha una lunghezza massima della stringa. Se il valore nel campo HR mappato all'attributo MICROSOFT Entra ID contiene più caratteri, l'aggiornamento dell'attributo potrebbe non riuscire. Un'opzione consiste nell’esaminare il mapping degli attributi e verificare se sia possibile troncare o aggiornare valori di stringa lunghi nel sistema HR. Se ciò non fosse possibile, si possono usare funzioni come Mid per troncare stringhe lunghe o funzioni come Switch per eseguire il mapping di valori lunghi a valori più brevi/abbreviazioni.
Indirizzare valori potenzialmente vuoti per gli attributi obbligatori. È obbligatorio popolare determinati attributi, ad firstNameesempio , lastName, CNo UPN quando si crea un account in Microsoft Entra ID o Windows Server AD. Se uno dei campi HR corrispondenti mappati a tali attributi è Null, l'operazione di creazione dell'utente ha esito negativo. Ad esempio, se si esegue il mapping dell'attributo AD CN a "nome visualizzato" e se il "nome visualizzato" non è impostato per tutti gli utenti, si verificherà un errore. Un'opzione consiste nell'esaminare questi mapping obbligatori degli attributi e assicurarsi che i campi corrispondenti siano popolati in HR. È anche possibile controllare la presenza di eventuali valori null in un mapping di espressioni. Ad esempio, se il nome visualizzato è vuoto, concatenare il nome e il cognome o il cognome per formare il nome visualizzato.

Verificare che i BAPI necessari per SAP ECC siano pronti per l'uso da parte di Microsoft Entra

L'agente di provisioning Microsoft Entra e il connettore generico per i servizi web forniscono la connettività agli endpoint SOAP locali, compresi i BAPI di SAP.

Se non si usa SAP ECC e si esegue il provisioning solo nei servizi cloud SAP, passare alla sezione successiva.

Verificare che i BAPI necessari per il provisioning siano pubblicati. Esporre le API necessarie in SAP ECC NetWeaver 7.51 per creare, aggiornare ed eliminare utenti. Il file Connectors for Microsoft Identity Manager 2016 denominato Deploying SAP NetWeaver AS ABAP 7.pdf illustra come esporre le API necessarie.
Registrare lo schema disponibile per gli utenti SAP esistenti. Forse si dispone di utenti esistenti in SAP ECC che corrispondono ai ruoli di lavoro nel sistema autorevole di origine record. Tuttavia, se tali utenti non sono stati creati da Microsoft Entra ID, è necessario avere un campo popolato su tali utenti che possa essere usato come identificatore univoco per il ruolo di lavoro. Questo campo deve essere presente con un valore univoco per ogni utente che corrisponde a un ruolo di lavoro. Il provisioning di Microsoft Entra può quindi determinare quali utenti esistono già per i ruoli di lavoro ed evitare di creare utenti duplicati.

Ad esempio, è possibile usare i BAPI_USER_GETLIST BAPI di SAP e BAPI_USER_GETDETAIL. Uno dei campi restituiti da BAPI_USER_GETDETAIL deve essere scelto come identificatore univoco da correlare all'origine. Se non si dispone di un campo che corrisponde a un identificatore univoco dall'origine, potrebbe essere necessario usare un identificatore univoco diverso. Ad esempio, potrebbe essere necessario usare il campo SAP address.e_mail se i relativi valori sono univoci in ogni utente SAP e sono presenti anche negli utenti di Microsoft Entra ID.
Registrare lo schema necessario per Microsoft Entra da fornire ai BAPI di SAP. Ad esempio, è possibile usare i campi SAP BAPI BAPI_USER_CREATE1, che richiedono ADDRESS,COMPANY,DEFAULTS,LOGONDATA,PASSWORD,SELF_REGISTER e USERNAME per creare un utente. Quando si configura il mapping dallo schema utente di Microsoft Entra ID per i requisiti di SAP ECC, eseguire il mapping degli attributi utente o delle costanti di Microsoft ID per ciascuno di questi campi.

Documentare il flusso e le trasformazioni degli attributi end-to-end

Sono stati identificati i requisiti dello schema delle applicazioni e i campi dei ruoli di lavoro disponibili dal sistema delle origini record. Ora documentare il percorso di questi campi attraverso Microsoft Entra e, facoltativamente, Windows Server AD e SAP Cloud Identity Services, fino alle applicazioni.

In alcuni casi, gli attributi richiesti dalle applicazioni non corrispondono direttamente ai valori di dati disponibili nell'origine. È quindi necessario trasformare i valori prima che possano essere forniti all'applicazione di destinazione.

Esistono diverse fasi di elaborazione in cui è possibile applicare una trasformazione.

Fase	Considerazioni	Link per altre informazioni
Nel sistema di registrazione stesso	La gestione del ciclo di vita di Microsoft Entra ID potrebbe non essere l'unica soluzione che legge da un sistema di origine record. L'esecuzione della normalizzazione dei dati prima di esporli a Microsoft Entra potrebbe essere utile anche ad altre soluzioni che necessitano di dati simili.	Vedere la documentazione relativa al sistema di record
Nel flusso di provisioning in ingresso, dal sistema di record a Microsoft Entra o Windows Server AD	È possibile scrivere un valore personalizzato in un attributo utente di Windows Server AD o in un attributo utente Microsoft Entra ID, in base a uno o più attributi di SuccessFactors.	Espressione con funzioni per la personalizzazione
Quando si esegue la sincronizzazione da Windows Server AD a Microsoft Entra ID	Se si dispone già di utenti in Windows Server AD, è possibile trasformare gli attributi di tali utenti man mano che vengono inseriti in Microsoft Entra ID.	Come personalizzare una regola di sincronizzazione in Microsoft Entra Connect e Utilizzare il generatore di espressioni con Microsoft Entra Cloud Sync
Nel flusso di provisioning in uscita da Microsoft Entra ID a SAP Cloud Identity Services, SAP ECC o altre applicazioni non SAP	Quando si configura il provisioning a un'applicazione, uno dei tipi di mapping degli attributi che è possibile specificare è il mapping di uno o più attributi in Microsoft Entra ID a un attributo nella destinazione.	Espressione con funzioni per la personalizzazione
In SSO federato in uscita	Per impostazione predefinita, la Microsoft Identity Platform genera per l'applicazione un token SAML che contiene un'attestazione, il cui valore del nome utente, o nome dell'entità utente, può identificare in modo univoco l'utente. Il token SAML contiene anche altre attestazioni che includono l'indirizzo di posta elettronica o il nome visualizzato dell'utente ed è possibile usare le funzioni di trasformazione delle attestazioni.	Personalizzare le attestazioni del token SAML e Attestazioni token Web JSON del cliente
SAP Cloud Identity Services	In SAP Cloud Identity Services, ogni sistema di destinazione configurato aggiunge trasformazioni dal modello di dati dell'origine per le identità fornite a SAP Cloud Identity Services ai requisiti della destinazione. Potrebbe essere necessario modificare tali trasformazioni in SAP Cloud Identity Services così che corrispondano al modo in cui si prevede di modellare l'identità, soprattutto se sono configurati più sistemi di destinazione. Tale approccio può risultare appropriato se il requisito dell'attributo è specifico di una o più applicazioni SAP connesse a SAP Cloud Identity Services.	SAP Cloud Identity Services - Gestire la trasformazione

Preparare il rilascio di nuove credenziali di autenticazione

Se si usa Windows Server AD, pianificare l'emissione di credenziali di Windows Server AD per i ruoli di lavoro che necessitano dell'accesso alle applicazioni e che in precedenza non disponevano di account utente di Windows Server AD. In passato, in alcune organizzazioni gli utenti venivano sottoposti a provisioning direttamente nei repository delle applicazioni. I ruoli di lavoro hanno ricevuto account utente in Windows Server AD solo se hanno richiesto una cassetta postale di Microsoft Exchange o l'accesso alle applicazioni integrate di Windows Server AD.

In questo scenario, se si configura il provisioning in ingresso in Windows Server AD, Microsoft Entra crea utenti in Windows Server AD, sia per i ruoli di lavoro esistenti che in precedenza non disponevano di account utente di Windows Server AD sia per ruoli di lavoro nuovi. Se gli utenti accedono al dominio Windows, si consiglia di iscriversi a Windows Hello for Business per ottenere un'autenticazione più forte della semplice password.
Se non si usa Windows Server AD, pianificare l'emissione di credenziali di Microsoft Entra ID per i ruoli di lavoro che necessitano dell'accesso alle applicazioni e che in precedenza non disponevano di account utente di Microsoft Entra ID. Se si configura il provisioning in ingresso in Microsoft Entra ID non recandosi prima in Windows Server AD, Microsoft Entra crea utenti in Microsoft Entra ID, sia per i ruoli di lavoro esistenti che in precedenza non disponevano di account utente di Microsoft Entra ID sia per ruoli di lavoro nuovi.

Se gli utenti necessitano di password, è possibile implementare la funzionalità di reimpostazione della password self-service di Microsoft Entra ID per consentire all'utente di reimpostare la password. È possibile effettuare il provisioning dell'attributo Numero di dispositivi mobili dall'app hr cloud. Dopo che l'attributo Numero di cellulare si trova in Microsoft Entra ID, è possibile abilitare la reimpostazione della password self-service per l'account dell'utente. Quindi, durante il primo giorno, il nuovo utente può usare il numero di cellulare registrato e verificato per l'autenticazione. Per informazioni dettagliate su come precompilare le informazioni di contatto di autenticazione, vedere la documentazione sulla reimpostazione della password self-service.

Se gli utenti usano un'autenticazione più avanzata, abilitare il criterio Pass di accesso temporaneo in modo da poter generare pass di accesso temporanei per i nuovi utenti.

Verificare che gli utenti siano abilitati a Microsoft Entra MFA. È consigliabile richiedere Microsoft Entra MFA per applicazioni business critical integrate tramite federazione. Per tali applicazioni, un criterio dovrebbe richiedere all'utente di soddisfare un requisito MFA prima che Microsoft Entra ID gli consenta di accedere a un'applicazione. Inoltre, alcune organizzazioni potrebbero bloccare l'accesso per località o richiedere all'utente di accedere da un dispositivo registrato.

Se non sono già presenti criteri appropriati che includono le condizioni necessarie per l'autenticazione, la posizione, il dispositivo e le condizioni per l'utilizzo, aggiungere un criterio alla distribuzione dell'accesso condizionale.
Preparare il rilascio di un pass di accesso temporaneo per i nuovi ruoli di lavoro. Se si dispone di Microsoft Entra ID Governance e si sta configurando il provisioning in ingresso in Microsoft Entra ID, pianificare la configurazione dei flussi di lavoro del ciclo di vita per rilasciare un pass di accesso temporaneo per i nuovi ruoli di lavoro.

Pianificare un progetto pilota

L'integrazione di processi aziendali hr e flussi di lavoro di identità dalle origini HR ai sistemi di destinazione richiede una notevole quantità di convalida dei dati, trasformazione dei dati, pulizia dei dati e test end-to-end prima di poter distribuire la soluzione nell'ambiente di produzione.

Eseguire la configurazione iniziale in un ambiente pilota prima di estenderla a tutti gli utenti nell'ambiente di produzione.

Distribuire le integrazioni di Microsoft Entra ID

In questa sezione verrà illustrato come:

Portare gli utenti in Microsoft Entra ID da un sistema di origine autorevole.
Effettuare il provisioning di tali utenti in SAP Cloud Identity Services o SAP ECC per consentire loro di accedere alle applicazioni SAP.

Aggiornare lo schema utente di Windows Server AD

Se si esegue il provisioning degli utenti in Windows Server AD e Microsoft Entra ID, assicurarsi che l'ambiente di Windows Server AD e gli agenti Microsoft Entra associati siano pronti per trasportare gli utenti da e verso Windows Server AD con lo schema necessario per le applicazioni SAP.

Se non si utilizza Windows Server AD, passare alla sezione successiva.

Estendere lo schema di Windows Server AD, se necessario. Per ogni attributo utente richiesto da Microsoft Entra e per le applicazioni che non fanno già parte dello schema utente di Windows Server AD, è necessario selezionare un attributo di estensione utente di Windows Server AD predefinito. In alternativa, è necessario estendere lo schema di Windows Server AD affinché Windows Server AD contenga tale attributo. Questo requisito include anche gli attributi utilizzati per l'automazione, ad esempio la data di ingresso e la data di uscita di un lavoratore.

Ad esempio, alcune organizzazioni potrebbero utilizzare gli attributi extensionAttribute1 e extensionAttribute2 per conservare queste proprietà. Se si sceglie di usare gli attributi di estensione predefiniti, assicurarsi che tali attributi non siano già in uso da altre applicazioni basate su LDAP di Windows Server AD o da applicazioni integrate con Microsoft Entra ID. Altre organizzazioni creano nuovi attributi di Windows Server AD con nomi specifici dei requisiti, ad esempio contosoWorkerId.
Verificare che tutti gli utenti di Windows Server AD esistenti dispongano degli attributi necessari per la correlazione con l'origine HR. Magari si dispone di utenti esistenti in Windows Server AD che corrispondono ai ruoli di lavoro. Tali utenti devono avere un attributo il cui valore è univoco e corrisponde a una proprietà nel sistema autorevole dell'origine record per tali ruoli di lavoro.

Ad esempio, alcune organizzazioni utilizzano un attributo come employeeId in Windows Server AD. Se sono presenti utenti che non dispongono di tale attributo, potrebbero non essere presi in considerazione durante l'integrazione successiva. Il provisioning automatizzato comporta quindi la creazione di utenti duplicati in Windows Server AD. Quando un utente se ne va, gli utenti originali non vengono aggiornati o rimossi. Puoi usare:
- La pipeline di PowerShell su un computer collegato al dominio con il comando Get-ADUser per ottenere tutti gli utenti in un contenitore di Active Directory.
- Il comando where-object per filtrare gli utenti con un attributo mancante con un filtro come {$_.employeeId -eq $null}.
- Il comando export-csv per esportare gli utenti risultanti in un file CSV.
Assicurarsi che nessun utente corrisponda a lavoratori a cui manca questo attributo. Nel caso ce ne fossero, è necessario modificare gli utenti in Windows Server AD per aggiungere l'attributo mancante prima di procedere.
Estendere lo schema Microsoft Entra ID e configurare i mapping dallo schema di Windows Server AD allo schema utente di Microsoft Entra ID. Se si usa Microsoft Entra Connect Sync, seguire questa procedura in Microsoft Entra Connect Sync: estensioni della directory per estendere lo schema utente di Microsoft Entra ID con gli attributi. Configurare i mapping di Microsoft Entra Connect Sync per gli attributi di Windows Server AD a tali attributi.

Se si usa Microsoft Entra Cloud Sync, seguire questa procedura in Estensioni della directory Microsoft Entra Cloud Sync e mappatura personalizzata degli attributi per estendere lo schema utente di Microsoft Entra ID con eventuali altri attributi necessari. Configurare i mapping di Microsoft Entra Connect Cloud per gli attributi di Windows Server AD a tali attributi. Assicurarsi di sincronizzare gli attributi richiesti dai flussi di lavoro del ciclo di vita.
Attendere la sincronizzazione da Windows Server AD a Microsoft Entra ID per terminare. Se sono state apportate modifiche ai mapping per effettuare il provisioning di più attributi da Windows Server AD, attendere fino a quando tali modifiche per gli utenti passano da Windows Server AD a Microsoft Entra ID in modo che la rappresentazione di Microsoft Entra ID degli utenti disponga del set completo di attributi di Windows Server AD.

Se si usa Microsoft Entra Cloud Sync, è possibile monitorare la proprietà steadyStateLastAchievedTime dello stato di sincronizzazione recuperando il processo di sincronizzazione dell'entità servizio che rappresenta Microsoft Entra Cloud Sync. Se non si dispone dell'ID dell’entità servizio, vedere Visualizzare lo schema di sincronizzazione.
Creare tutti i contenitori necessari in Windows Server AD. Se si eseguirà il provisioning degli utenti in unità organizzative nel dominio, assicurarsi che tali organizationalUnit contenitori esistano prima di abilitare l'agente di provisioning.

Aggiornare lo schema dell'utente Microsoft Entra ID

Se si usa Windows Server AD, lo schema utente di Microsoft Entra ID è già stato esteso durante la configurazione dei mapping da Windows Server AD. Se questo passaggio è terminato, passare alla sezione successiva.

Se non si usa Windows Server AD, seguire la procedura descritta nella presente sezione per estendere lo schema utente di Microsoft Entra ID.

Creare un'applicazione per contenere le estensioni dello schema Microsoft Entra ID. Per i tenant non sincronizzati con Windows Server AD, le estensioni dello schema devono far parte di una nuova applicazione. Se non è già stato fatto, creare un'applicazione per rappresentare le estensioni dello schema. L'applicazione non avrà alcun utente assegnato.
Identificare l'attributo per la correlazione con il sistema di record. Magari si dispone di utenti esistenti in Microsoft Entra ID che corrispondono ai ruoli di lavoro. Quindi, tali utenti devono avere un attributo il cui valore è univoco e corrisponde a una proprietà nel sistema autorevole dell'origine record per tali ruoli di lavoro.

Ad esempio, alcune organizzazioni estendono lo schema utente di Microsoft Entra ID per avere un nuovo attributo a questo scopo. Se non è già stato creato un attributo a tale scopo, includerlo come attributo nel passaggio successivo.
Estendere lo schema utente di Microsoft Entra ID per i nuovi attributi. Creare estensioni dello schema di directory per ogni attributo richiesto dalle applicazioni SAP che non fanno già parte dello schema utente di Microsoft Entra ID. Questi attributi consentono a Microsoft Entra di archiviare più dati sugli utenti. È possibile estendere lo schema creando un attributo di estensione.

Assicurarsi che gli utenti in Microsoft Entra ID possano essere correlati ai record di lavoro nell'origine HR

Magari si dispone di utenti esistenti in Microsoft Entra ID che corrispondono ai ruoli di lavoro. Quindi, tali utenti devono avere un attributo il cui valore è univoco e corrisponde a una proprietà nel sistema autorevole dell'origine record per tali ruoli di lavoro.

Ad esempio, alcune organizzazioni potrebbero estendere lo schema utente di Microsoft Entra ID per avere un nuovo attributo a questo scopo. Se sono presenti utenti che non dispongono di tale attributo, potrebbero non essere presi in considerazione durante l'integrazione successiva. Il provisioning automatico provoca quindi la creazione di utenti duplicati in Windows Server AD. Quando un utente se ne va, gli utenti originali non vengono aggiornati o rimossi.

Recuperare gli utenti da Microsoft Entra ID. Assicurarsi che qualsiasi utente già presente in Microsoft Entra ID che rappresenta un lavoratore abbia un attributo in modo da poter essere correlato. In genere, alcuni utenti in Microsoft Entra ID non corrispondono ai ruoli di lavoro nel sistema autorevole di origine record. Tali utenti includono l'account break-glass per l'accesso amministrativo di emergenza, gli account per i fornitori IT e gli utenti guest aziendali. Il resto degli utenti deve essere già in possesso di un attributo con un valore univoco da usare per la correlazione.

Se alcuni utenti non sono correlati, potrebbero non essere coinvolti negli aggiornamenti e nel deprovisioning. Microsoft Entra potrebbe perfino creare utenti duplicati. Ad esempio, se il requisito è che tutti gli utenti membri (oltre all'account break-glass) abbiano un attributo employeeid, è possibile identificare gli utenti con una pipeline di comandi di PowerShell simile allo script seguente:
```
$u = get-mguser -all -property id,displayname,userprincipalname,usertype,employeeid | Where-Object {$_.UserType -ne 'Guest' -and $_.EmployeeId -eq $null}
```

Configurare i prerequisiti per le funzionalità di governance delle identità

Se è stata identificata la necessità di una funzionalità di governance di Microsoft Entra ID, ad esempio la gestione entitlement di Microsoft Entra o i flussi di lavoro del ciclo di vita di Microsoft Entra, distribuire tali funzionalità prima di inserire i ruoli di lavoro come utenti in Microsoft Entra ID.

Caricare il documento con le condizioni per l'utilizzo, se necessario. Se è necessario che gli utenti accettino le condizioni per l'utilizzo prima di poter accedere a un'applicazione, creare e caricare il documento relativi alle condizioni per l'utilizzo in modo che possa essere incluso in un criterio di accesso condizionale.
Creare un file di catalogo, se necessario. Per impostazione predefinita, quando un amministratore interagisce per la prima volta con la gestione entitlement di Microsoft Entra, viene creato automaticamente un catalogo predefinito. Tuttavia, i pacchetti di accesso per le applicazioni regolamentate devono trovarsi in un catalogo designato. Per creare un catalogo nell'interfaccia di amministrazione di Microsoft Entra, seguire la procedura descritta nella sezione Creare un catalogo.

Per creare un catalogo tramite PowerShell, seguire la procedura descritta nelle sezioni Eseguire l'autenticazione a Microsoft Entra ID e Creare un catalogo.
Creare un flusso di lavoro di entrata. Se si sta configurando il provisioning in ingresso in Microsoft Entra ID, configurare un flusso di lavoro del ciclo di vita di entrata con un’attività per rilasciare un pass di accesso temporaneo per i nuovi ruoli di lavoro.
Creare un flusso di lavoro di uscita che blocca gli accessi. In Flussi di lavoro del ciclo di vita di Microsoft Entra configurare un flusso di lavoro di uscita con un'attività che impedisce agli utenti di accedere. Questo flusso di lavoro può essere eseguito su richiesta. Se non è stato configurato il provisioning in ingresso dalle origini del record per impedire agli operatori di accedere dopo la data di uscita pianificata, configurare un flusso di lavoro di uscita per l'esecuzione nelle date di uscita pianificate dei lavoratori.
Creare un flusso di lavoro di uscita per eliminare gli account utente. Facoltativamente, configurare un flusso di lavoro di uscita con un'attività per eliminare un utente. Pianificare l'esecuzione del flusso di lavoro per un determinato periodo di tempo, ad esempio 30 o 90 giorni, dopo la data di uscita pianificata del lavoratore.

Connettere gli utenti in Microsoft Entra ID ai record di lavoro dell'origine HR

Questa sezione illustra come integrare Microsoft Entra ID con SAP SuccessFactors come sistema di origine HR.

Configurare il sistema di record con un account del servizio e concedere le autorizzazioni appropriate per Microsoft Entra ID. Se si usa SAP SuccessFactors, seguire la procedura descritta nella sezione Configurazione di SuccessFactors per l'integrazione.
Configurare i mapping in ingresso dal sistema di record a Windows Server AD o Microsoft Entra ID. Se si usa SAP SuccessFactors e si esegue il provisioning degli utenti in Windows Server AD e Microsoft Entra ID, seguire la procedura descritta nella sezione Configurazione del provisioning utenti da SuccessFactors ad Active Directory.

Se si usa SAP SuccessFactors e non si esegue il provisioning in Windows Server AD, seguire la procedura descritta nella sezione Configurazione del provisioning utenti da SuccessFactors a Microsoft Entra ID.

Quando si configurano i mapping, assicurarsi di aver configurato un mapping con Abbinare gli oggetti che utilizzano questo attributo per l'attributo di Windows Server AD o l'attributo utente Microsoft Entra ID utilizzato per la correlazione. Configurare anche i mapping per gli attributi necessari per l'aggiunta al ruolo di lavoro e le date di uscita e tutti gli attributi richiesti dalle applicazioni di destinazione, che hanno origine dall'origine HR.
Eseguire il provisioning iniziale in ingresso dal sistema di record. Se si usa SAP SuccessFactors e si esegue il provisioning degli utenti in Windows Server AD e Microsoft Entra ID, seguire la procedura descritta nella sezione Abilitare e avviare il provisioning. Se si usa SAP SuccessFactors e non si esegue il provisioning in Windows Server AD, seguire la procedura descritta nella sezione Abilitare e avviare il provisioning. Per i tenant di app hr cloud di grandi dimensioni (>30.000 utenti), eseguire il ciclo iniziale in fasi progressive, come descritto in Pianificare il ciclo iniziale.
Attendere il completamento della sincronizzazione iniziale dal sistema di record. Se si esegue la sincronizzazione da SAP SuccessFactors ad Windows Server AD o Microsoft Entra ID, al termine della sincronizzazione iniziale con la directory, Microsoft Entra aggiorna il report di riepilogo del controllo nella scheda Provisioning dell'applicazione SAP SuccessFactors nell'interfaccia di amministrazione di Microsoft Entra.
Se si esegue il provisioning in Windows Server AD, attendere che i nuovi utenti creati in Windows Server AD o quelli aggiornati in Windows Server AD vengano sincronizzati da Windows Server AD a Microsoft Entra ID. Attendere che le modifiche apportate agli utenti in Windows Server AD vengano trasferite a Microsoft Entra ID, in modo che la rappresentazione di Microsoft Entra ID degli utenti disponga del set completo di utenti e dei relativi attributi di Windows Server AD.

Se si usa Microsoft Entra Cloud Sync, è possibile monitorare il steadyStateLastAchievedTime dello stato di sincronizzazione recuperando il processo di sincronizzazione dell'entità servizio che rappresenta Microsoft Entra Cloud Sync. Se non si dispone dell'ID dell’entità servizio, vedere Visualizzare lo schema di sincronizzazione.

Assicurarsi che sia stato effettuato il provisioning degli utenti in Microsoft Entra ID. A questo punto, gli utenti dovrebbero essere presenti in Microsoft Entra ID con gli attributi richiesti dalle applicazioni di destinazione. Ad esempio, potrebbe essere necessario che gli utenti dispongano degli attributi givenname, surname e employeeID. Per visualizzare il numero di utenti con attributi specifici o con attributi mancanti, è possibile usare comandi di PowerShell simili allo script seguente:

$u = get-mguser -all -property id,displayname,userprincipalname,usertype,givenname,surname,employeeid
$u2 = $u | where-object {$_.usertype -ne 'Guest' -and $_.employeeid -ne $null}
$u2c = $u2.Count
write-output "member users with employeeID attribute: $u2c"
$u3 = $u| Where-Object {$_.UserType -ne 'Guest' -and ($_.EmployeeId -eq $null -or $_.GivenName -eq $null -or $_.Surname -eq $null)}
$u3c = $u3.Count
write-output "member users missing employeeID, givenname or surname attributes: $u3c"

Assicurarsi che in Microsoft Entra ID non siano presenti account imprevisti non correlati. In genere, alcuni utenti in Microsoft Entra ID non corrispondono ai ruoli di lavoro nel sistema autorevole di origine record. Includono l'account break-glass per l'accesso amministrativo di emergenza, gli account per i fornitori IT e gli utenti guest aziendali.

Tuttavia, potrebbero anche essere account orfani in Microsoft Entra che assomigliano a quelli degli attuali ruoli di lavoro, ma che non sono stati sincronizzati con un record di lavoro. Gli account orfani possono derivare da ex dipendenti non più presenti nel sistema HR. Inoltre, possono provenire da errori di corrispondenza. Oppure possono verificarsi problemi di qualità dei dati, ad esempio una persona che ha modificato il nome o che è stata riassunta.
Testare correttamente il join, aggiornare e lasciare le attività in un sistema upstream del flusso di record a Microsoft Entra. Per altre informazioni, vedere Pianificare i test.

Ora che gli utenti esistono in Microsoft Entra ID, nelle sezioni successive ne viene effettuato il provisioning nelle applicazioni di destinazione.

Effettuare il provisioning degli utenti in SAP Cloud Identity Services

I passaggi descritti in questa sezione consentono di configurare il provisioning da Microsoft Entra ID a SAP Cloud Identity Services. Per impostazione predefinita, configurare Microsoft Entra ID per effettuare automaticamente il provisioning e il deprovisioning degli utenti in SAP Cloud Identity Services. Questi utenti possono quindi eseguire l'autenticazione a SAP Cloud Identity Services e avere accesso ad altri carichi di lavoro SAP integrati con SAP Cloud Identity Services. SAP Cloud Identity Services supporta il provisioning dalla directory delle identità locali ad altre applicazioni SAP come sistemi di destinazione.

In alternativa, è possibile configurare SAP Cloud Identity Services per leggere Microsoft Entra ID. Se si usa SAP Cloud Identity Services per leggere utenti e gruppi facoltativamente in Microsoft Entra ID, seguire le indicazioni SAP su come configurare SAP Cloud Identity Services. Passare quindi alla sezione successiva.

Se non si utilizza SAP Cloud Identity Services, passare alla sezione successiva.

Assicurarsi di disporre di un tenant di SAP Cloud Identity Services con un account utente in SAP Cloud Identity Services con autorizzazioni di amministratore.
Configurare SAP Cloud Identity Services per il provisioning. Accedere alla console di amministrazione di SAP Cloud Identity Services e seguire la procedura descritta nella sezione Configurare SAP Cloud Identity Services per il provisioning.
Aggiungere SAP Cloud Identity Services dalla raccolta e configurare il provisioning automatico degli utenti in SAP Cloud Identity Services. Seguire la procedura descritta nelle sezioni Aggiungere SAP Cloud Identity Services dalla raccolta e Configurare il provisioning automatico degli utenti in SAP Cloud Identity Services.
Effettuare il provisioning di un utente di test da Microsoft Entra ID a SAP Cloud Identity Services. Verificare che l'integrazione del provisioning sia pronta seguendo la procedura descritta nella sezione Effettuare il provisioning di un nuovo utente di test da Microsoft Entra ID a SAP Cloud Identity Services.
Assicurarsi che gli utenti esistenti in Microsoft Entra e SAP Cloud Identity Services possano essere correlati. Per confrontare gli utenti in Microsoft Entra ID con gli utenti già presenti in SAP Cloud Identity Services, seguire la procedura descritta in queste sezioni:
- Assicurarsi che gli utenti esistenti di SAP Cloud Identity Services dispongano degli attributi corrispondenti necessari
- Assicurarsi che gli utenti esistenti di Microsoft Entra abbiano gli attributi necessari
Assegnare gli utenti esistenti di SAP Cloud Identity Services all'applicazione in Microsoft Entra ID. Seguire la procedura descritta nella sezione Assegnare utenti all'applicazione SAP Cloud Identity Services in Microsoft Entra ID. In questi passaggi è necessario:
- Risolvere eventuali problemi di provisioning in modo che il provisioning non venga messo in quarantena.
- Verificare la presenza di utenti presenti in SAP Cloud Identity Services e che non sono già assegnati all'applicazione in Microsoft Entra ID.
- Assegnare gli utenti rimanenti.
- Monitorare la sincronizzazione iniziale.
Attendere la sincronizzazione da Microsoft Entra ID a SAP Cloud Identity Services. Attendere il provisioning di tutti gli utenti assegnati all'applicazione. Un ciclo iniziale richiede da 20 minuti a diverse ore. La durata dipende dalle dimensioni della directory Microsoft Entra e dal numero di utenti nell'ambito del provisioning. È possibile monitorare la proprietà steadyStateLastAchievedTime dello stato di sincronizzazione recuperando il processo di sincronizzazione dell'entità servizio che rappresenta SAP Cloud Identity Services.
Verificare errori di provisioning. Controllare il log di provisioning tramite l'interfaccia di amministrazione di Microsoft Entra o API Graph. Filtrare il log in base allo stato Errore.

Se si verificano errori con un codice di errore DuplicateTargetEntries, questo codice indica un'ambiguità nelle regole di corrispondenza del provisioning. Per accertarsi che ogni utente di Microsoft Entra corrisponda a un utente dell'applicazione, è necessario aggiornare gli utenti di Microsoft Entra o i mapping usati per la corrispondenza. Filtrare quindi il log con l'azione Crea e lo stato Ignorato.

Se gli utenti sono stati ignorati con il codice SkipReason di *NotEffectivelyEntitled, questo evento di log potrebbe indicare che gli account utente in Microsoft Entra ID non sono stati abbinati perché lo stato dell'account utente era Disabilitato.
Confrontare gli utenti in SAP Cloud Identity Services con quelli in Microsoft Entra ID. Ripetere i passaggi nella sezione Verificare che gli utenti di SAP Cloud Identity Services esistenti dispongano degli attributi corrispondenti necessari per esportare nuovamente gli utenti da SAP Cloud Identity Services. Verificare quindi che gli utenti esportati abbiano le proprietà necessarie per le applicazioni SAP. È possibile usare il comando PowerShell where-object per filtrare l'elenco di utenti solo per gli utenti che dispongono di un attributo mancante, con un filtro come {$_.employeeId -eq $null}.
Configurare l'accesso SSO federato da Microsoft Entra a SAP Cloud Identity Services. Abilitare l'accesso SSO basato su SAML per SAP Cloud Identity Services. Seguire le istruzioni fornite nell'esercitazione sull'accesso Single Sign-On di SAP Cloud Identity Services.
Portare l'endpoint Web dell'applicazione nell'ambito dei criteri di accesso condizionale appropriati. Può darsi che si disponga di un criterio di accesso condizionato esistente, creato per un'altra applicazione soggetta agli stessi requisiti di governance. È quindi possibile aggiornare tale criterio per applicarlo anche a questa applicazione per evitare di avere un numero elevato di criteri.

Dopo aver apportato gli aggiornamenti, verificare che vengano applicati i criteri previsti. È possibile visualizzare quali criteri si applicano a un utente con lo strumento di simulazione dell'accesso condizionale.
Verificare che un utente di test possa connettersi alle applicazioni SAP. Inoltre, è possibile usare App personali Microsoft per testare l'applicazione SSO. Assicurarsi che un utente di test sia stato assegnato all'applicazione SAP Cloud Identity Services e che ne sia stato effettuato il provisioning da Microsoft Entra ID a SAP Cloud Identity Services. Accedere quindi a Microsoft Entra come utente e passare a myapps.microsoft.com.

Quando si seleziona il riquadro di SAP Cloud Identity Services in App personali, se è stata configurata l'integrazione in modalità provider di servizi (SP), si viene reindirizzati alla pagina di accesso dell'applicazione per avviare il flusso di accesso. Se è stata configurata la modalità IDP (Identity Provider), si accede automaticamente all'istanza di SAP Cloud Identity Services per cui si è configurato l'accesso SSO.

Utenti che eseguono il provisioning su SAP ECC

Ora che si dispone degli utenti in Microsoft Entra ID, è possibile eseguirne il provisioning in SAP locale.

Se non si usa SAP ECC, passare alla sezione successiva.

Configurazione del provisioning. Seguire le istruzioni in Configurare Microsoft Entra ID per effettuare il provisioning degli utenti in SAP ECC con NetWeaver AS ABAP 7.0 o versione successiva.
Attendere la sincronizzazione da Microsoft Entra ID a SAP ECC. Attendere il provisioning di tutti gli utenti assegnati all'applicazione SAP ECC. Un ciclo iniziale richiede da 20 minuti a diverse ore. La durata dipende dalle dimensioni della directory Microsoft Entra e dal numero di utenti nell'ambito del provisioning. È possibile monitorare la proprietà steadyStateLastAchievedTime dello stato di sincronizzazione recuperando il processo di sincronizzazione dell'entità servizio.
Verificare errori di provisioning. Controllare il log di provisioning tramite l'interfaccia di amministrazione di Microsoft Entra o API Graph. Filtrare il log in base allo stato Errore.

Se si verificano errori con un codice di errore DuplicateTargetEntries, questo evento log indica un'ambiguità nelle regole di corrispondenza del provisioning. È necessario aggiornare gli utenti di Microsoft Entra o i mapping usati per la corrispondenza per accertarsi che ogni utente di Microsoft Entra corrisponda a un utente dell'applicazione. Filtrare quindi il log con l'azione Crea e lo stato Ignorato.

Se gli utenti sono stati ignorati con il codice SkipReason di NotEffectivelyEntitled, questo codice potrebbe indicare che gli account utente in Microsoft Entra ID non sono stati abbinati perché lo stato dell'account utente era Disabilitato.
Confrontare gli utenti in SAP ECC con quelli in Microsoft Entra ID. In Windows Server che ospita l'agente di provisioning per il provisioning in SAP ECC, riavviare il servizio di Windows Microsoft ECMA2Host. Quando il servizio viene riavviato, esegue un'importazione completa degli utenti da SAP ECC.
Configurare l'accesso SSO federato da Microsoft Entra a SAP. Abilitare SSO basato su SAML per le applicazioni SAP. Se si usa SAP NetWeaver, seguire le istruzioni fornite nell'esercitazione SAP NetWeaver SSO.
Portare l'endpoint Web dell'applicazione nell'ambito dei criteri di accesso condizionale appropriati. Può darsi che si disponga di un criterio di accesso condizionato esistente, creato per un'altra applicazione soggetta agli stessi requisiti di governance. È quindi possibile aggiornare tale criterio per applicarlo anche a questa applicazione per evitare di avere un numero elevato di criteri.

Dopo aver apportato gli aggiornamenti, verificare che vengano applicati i criteri previsti. È possibile visualizzare quali criteri si applicano a un utente con lo strumento di simulazione dell'accesso condizionale.
Verificare che sia possibile effettuare il provisioning di un utente di test e accedere a SAP NetWeaver. Seguire le istruzioni nella sezione Testare l'accesso SSO per assicurarsi che gli utenti possano accedere dopo la configurazione dell'accesso condizionale.

Configurare il provisioning in SuccessFactors e altre applicazioni

È possibile configurare Microsoft Entra per scrivere attributi specifici da Microsoft Entra ID a SAP SuccessFactors Employee Central, inclusa la posta elettronica aziendale. Per altre informazioni, vedere Configurare il writeback di SAP SuccessFactors in Microsoft Entra ID.

Inoltre, Microsoft Entra può eseguire il provisioning in molte altre applicazioni, incluse quelle che usano standard come OpenID Connect, SAML, SCIM, SQL, LDAP, SOAP e REST. Per altre informazioni, vedere Integrazione di applicazioni con Microsoft Entra ID.

Assegnare agli utenti i diritti di accesso all’applicazione necessari in Microsoft Entra

A meno che il tenant che si sta configurando non sia un tenant completamente isolato configurato in modo specifico per l'accesso alle applicazioni SAP, è improbabile che tutti gli utenti del tenant richiedano l'accesso alle applicazioni SAP. Le applicazioni SAP nel tenant sono configurate in modo tale che solo gli utenti con un ruolo applicativo assegnato a un'applicazione siano assegnati all'applicazione e possano accedere da Microsoft Entra ID a tale applicazione.

Quando gli utenti assegnati a un'applicazione vengono aggiornati in Microsoft Entra ID, tali modifiche vengono automaticamente sottoposte a provisioning in tale applicazione.

Se si dispone di Microsoft Entra ID Governance, è possibile automatizzare le modifiche alle assegnazioni di ruolo dell'applicazione per SAP Cloud Identity Services o SAP ECC in Microsoft Entra ID. È possibile utilizzare l'automazione per aggiungere o rimuovere le assegnazioni quando le persone entrano a far parte dell'organizzazione oppure se ne vanno o cambiano ruolo.

Esaminare le assegnazioni esistenti. Facoltativamente, eseguire una verifica degli accessi una tantum delle assegnazioni di ruolo dell'applicazione. Al termine della verifica, la verifica degli accessi rimuove le assegnazioni non più necessarie.
Configurare il processo per mantenere aggiornate le assegnazioni di ruolo dell'applicazione. Se si usa la gestione entitlement di Microsoft Entra, vedere Creare un pacchetto di accesso nella gestione entitlement per un'applicazione con un singolo ruolo usando PowerShell per configurare le assegnazioni all'applicazione che rappresentano i servizi di gestione delle identità cloud SAP o SAP ECC.

In tale pacchetto di accesso, è possibile definire criteri per l'assegnazione degli accessi agli utenti che ne fanno richiesta. Le assegnazioni possono essere effettuate da un amministratore, automaticamente in base alle regole oppure generate tramite flussi di lavoro del ciclo di vita.

Se non si dispone di Microsoft Entra ID Governance, è possibile assegnare ogni singolo utente all'applicazione nell'interfaccia di amministrazione di Microsoft Entra. È possibile assegnare singoli utenti all'applicazione tramite il cmdlet New-MgServicePrincipalAppRoleAssignedTo di PowerShell.

Distribuire le credenziali agli utenti di Microsoft Entra appena creati o agli utenti di Windows Server AD

A questo punto, tutti gli utenti sono presenti in Microsoft Entra ID e sono stati assegnati alle applicazioni SAP pertinenti. Tutti gli utenti creati durante questo processo, per i ruoli di lavoro non presenti in precedenza in Windows Server AD o Microsoft Entra ID, richiedono nuove credenziali.

Se il provisioning in ingresso di Microsoft Entra crea utenti in Windows Server AD, distribuire le credenziali iniziali di Windows Server AD per gli utenti appena creati. È possibile recuperare un elenco di eventi per le interazioni di Microsoft Entra con Windows Server AD usando il comando Get-MgAuditLogProvisioning.

È possibile usare il comando Set-ADAccountPassword con il parametro -Reset su un computer collegato a un dominio per impostare una nuova password di Windows Server AD per un utente. Usare quindi il comando Set-ADUser con il parametro -ChangePasswordAtLogon per richiedere all'utente di selezionare una nuova password all’accesso successivo.
Se il provisioning in ingresso di Microsoft Entra crea utenti in Microsoft Entra ID, distribuire le credenziali iniziali di Microsoft Entra ID per gli utenti appena creati. È possibile recuperare un elenco di utenti appena creati con il comando Get-MgAuditLogDirectoryAudit, con parametri quali Get-MgAuditLogDirectoryAudit -Filter "category eq 'UserManagement' and activityDisplayName eq 'Add user' and result eq 'success' and activityDateTime+ge+2024-05-01" -all.

Per generare un pass di accesso temporaneo per un utente, è possibile usare i comandi New-MgUserAuthenticationTemporaryAccessPassMethod e Get-MgUserAuthenticationTemporaryAccessPassMethod, come illustrato in Creare un pass di accesso temporaneo.
Verificare che gli utenti siano registrati per l'autenticazione a più fattori (MFA). È possibile identificare gli utenti che non sono registrati per l’MFA eseguendo i comandi di PowerShell nella sezione Report di PowerShell sugli utenti registrati per l'autenticazione a più fattori.
Creare una verifica di accesso ricorrente se gli utenti necessitano di esclusioni di criteri temporanei. In alcuni casi, potrebbe non essere possibile applicare immediatamente i criteri di accesso condizionale per ogni utente autorizzato. Ad esempio, alcuni utenti potrebbero non avere un dispositivo registrato appropriato. Se è necessario escludere uno o più utenti dai criteri di accesso condizionale e consentire loro l'accesso, configurare una verifica di accesso per il gruppo di utenti esclusi dai criteri di accesso condizionale.

Monitorare i flussi di identità

Dopo aver configurato il provisioning in ingresso e in uscita con le applicazioni, è possibile usare l'automazione in Microsoft Entra per monitorare il provisioning continuo dai sistemi autorevoli di record alle applicazioni di destinazione.

Monitorare il provisioning in ingresso

Le attività eseguite dal servizio di provisioning vengono registrate nei log di provisioning di Microsoft Entra. È possibile accedere ai log di provisioning nell'interfaccia di amministrazione di Microsoft Entra. È possibile eseguire ricerche nei dati di provisioning in base al nome dell'utente o all'identificatore nel sistema di origine o nel sistema di destinazione. Per altre informazioni sul provisioning, vedere Log di provisioning.

Monitorare le modifiche in Windows Server AD

Come descritto in Raccomandazioni sui criteri di controllo di Windows Server, assicurarsi che gli eventi di controllo di Gestione account utente siano abilitati in tutti i controller di dominio e raccolti per l'analisi.

Monitorare assegnazioni di ruolo applicazione

Se è stato configurato Microsoft Entra ID per inviare eventi di controllo a Monitoraggio di Azure, è possibile usare le cartelle di lavoro di Monitoraggio di Azure per ottenere informazioni dettagliate sul modo in cui gli utenti ricevono l'accesso.

Se si usa la gestione entitlement di Microsoft Entra, la cartella di lavoro denominata Access Package Activity visualizza ogni evento correlato a un determinato pacchetto di accesso.
Per verificare se le modifiche alle assegnazioni dei ruoli di applicazione per un'applicazione non sono state create a causa delle assegnazioni dei pacchetti di accesso, selezionare la cartella di lavoro denominata Attività di assegnazione dei ruoli di applicazione. Se si sceglie di omettere l'attività entitlement, vengono visualizzate solo le modifiche ai ruoli dell'applicazione non apportate dalla gestione entitlement. Ad esempio, viene visualizzata una riga se un altro amministratore ha assegnato direttamente un utente a un ruolo applicazione.

Monitorare il provisioning in uscita

Per ogni applicazione integrata con Microsoft Entra è possibile usare la sezione Dettagli sincronizzazione per monitorare lo stato di avanzamento e selezionare i collegamenti al report dell'attività di provisioning. Il report descrive tutte le azioni eseguite dal servizio di provisioning di Microsoft Entra nell’applicazione. Inoltre, è possibile monitorare il progetto di provisioning tramite le API Graph di Microsoft.

Per altre informazioni sulla lettura dei log di provisioning di Microsoft Entra, vedere Creazione di report sul provisioning automatico degli account utente.

Monitorare l'accesso Single Sign-On

È possibile visualizzare gli ultimi 30 giorni di accesso a un'applicazione nel report degli accessi nell'interfaccia di amministrazione di Microsoft Entra o tramite Microsoft Graph. Inoltre, è possibile inviare i log di accesso a Monitoraggio di Azure per archiviare l'attività di accesso per un massimo di due anni.

Monitorare le assegnazioni in Microsoft Entra ID Governance

Se si usa Microsoft Entra ID Governance, è possibile segnalare in che modo gli utenti ottengono l'accesso usando le funzionalità di Microsoft Entra ID Governance. Ad esempio:

Un amministratore o un proprietario del catalogo può recuperare l'elenco di utenti con assegnazioni di pacchetti di accesso tramite l'interfaccia di amministrazione di Microsoft Entra, Microsoft Graph o PowerShell.
È anche possibile inviare i log di controllo a Monitoraggio di Azure e visualizzare una cronologia delle modifiche al pacchetto di accesso nell'interfaccia di amministrazione di Microsoft Entra o tramite PowerShell.

Per altre informazioni su questi e altri scenari di governance delle identità, vedere come monitorare per modificare i criteri di gestione entitlement e l'accesso in base alle esigenze.

Condividi tramite