Preparare la verifica dell'accesso degli utenti a un'applicazione

  • Articolo

Microsoft Entra ID Governance consente di bilanciare la necessità dell'organizzazione per la sicurezza e la produttività dei dipendenti con i processi e la visibilità corretti. Fornisce funzionalità per garantire che le persone giuste abbiano l'accesso appropriato alle risorse giuste.

Le organizzazioni con requisiti di conformità o piani di gestione dei rischi hanno applicazioni sensibili o critiche per l'azienda. La riservatezza dell'applicazione può essere basata sullo scopo o sui dati contenuti, ad esempio informazioni finanziarie o informazioni personali dei clienti dell'organizzazione. Per tali applicazioni, solo un subset di tutti gli utenti dell'organizzazione è autorizzato ad avere accesso e l'accesso deve essere consentito solo in base ai requisiti aziendali documentati. Microsoft Entra ID può essere integrato con molte applicazioni SaaS comuni, applicazioni locali e applicazioni che l'organizzazione sviluppa, usando interfacce API e protocolli standard. Tramite queste interfacce, Microsoft Entra ID può essere l'origine autorevole per controllare chi può accedere a tali applicazioni. Quando si integrano le applicazioni con Microsoft Entra ID, è quindi possibile usare le verifiche di accesso per ricertificare gli utenti che hanno accesso a tali applicazioni e rimuovere l'accesso di tali utenti che non necessitano più dell'accesso. È anche possibile usare altre funzionalità, incluse le condizioni per l'utilizzo, l'accesso condizionale e la gestione entitlement, per gestire l'accesso alle applicazioni, come descritto in come gestire l'accesso alle applicazioni nell'ambiente.

Prerequisiti per la verifica dell'accesso

Per usare Microsoft Entra ID per una verifica di accesso dell'accesso a un'applicazione, è necessario disporre di una delle licenze seguenti nel tenant:

  • Microsoft Entra ID P2 o Microsoft Entra ID Governance
  • Licenza di Enterprise Mobility + Security (EMS) E5

Sebbene l'uso della funzionalità di verifica di accesso non richieda agli utenti di assegnare tali licenze per l'uso della funzionalità, è necessario disporre di licenze sufficienti. Per altre informazioni, vedere Scenari di licenza di esempio per le verifiche di accesso.

Inoltre, anche se non è necessario per esaminare l'accesso a un'applicazione, è consigliabile esaminare regolarmente l'appartenenza dei ruoli della directory con privilegi che hanno la possibilità di controllare l'accesso di altri utenti a tutte le applicazioni. Amministrazione istrator in Global Administrator, Identity Governance AdministratorUser Administrator, Application Administrator, Cloud Application Administrator e Privileged Role Administrator possono apportare modifiche agli utenti e alle assegnazioni di ruolo dell'applicazione, in modo da assicurarsi che la verifica di accesso di questi ruoli della directory sia stata pianificata.

Determinare la modalità di integrazione dell'applicazione con Microsoft Entra ID

Affinché le verifiche di accesso vengano usate per un'applicazione, l'applicazione deve prima essere integrata con Microsoft Entra ID e rappresentata nella directory. Un'applicazione integrata con Microsoft Entra ID significa che è necessario soddisfare uno dei due requisiti seguenti:

  • L'applicazione si basa sull'ID Microsoft Entra per l'accesso SSO federato e microsoft Entra ID controlla il rilascio dei token di autenticazione. Se Microsoft Entra ID è l'unico provider di identità per l'applicazione, solo gli utenti assegnati a uno dei ruoli dell'applicazione in Microsoft Entra ID sono in grado di accedere all'applicazione. Gli utenti negati da una verifica perdono l'assegnazione del ruolo applicazione e non possono più ottenere un nuovo token per accedere all'applicazione.
  • L'applicazione si basa su elenchi di utenti o gruppi forniti all'applicazione dall'ID Microsoft Entra. Questo adempimento può essere eseguito tramite un protocollo di provisioning, ad esempio System for Cross-Domain Identity Management (SCIM), dall'applicazione che esegue query sull'ID Microsoft Entra tramite Microsoft Graph, il provisioning degli utenti di Microsoft Entra nel database o nei gruppi dell'applicazione scritti in Servizi di dominio Active Directory. Gli utenti negati da una verifica perdono l'assegnazione di ruolo dell'applicazione o l'appartenenza a gruppi e, quando tali modifiche vengono rese disponibili all'applicazione, gli utenti negati non avranno più accesso.

Se nessuno di questi criteri viene soddisfatto per un'applicazione, poiché l'applicazione non si basa sull'ID Microsoft Entra, le verifiche di accesso possono comunque essere usate, ma ci saranno alcune limitazioni. Gli utenti che non sono nell'ID Microsoft Entra o non sono assegnati ai ruoli dell'applicazione in Microsoft Entra ID, non verranno inclusi nella revisione. Inoltre, le modifiche da rimuovere negate non saranno in grado di essere inviate automaticamente all'applicazione se non è disponibile alcun protocollo di provisioning supportato dall'applicazione. L'organizzazione deve invece disporre di un processo per inviare i risultati di una revisione completata all'applicazione.

Per consentire la gestione di un'ampia gamma di applicazioni e requisiti IT con Microsoft Entra ID, esistono diversi modelli per integrare un'applicazione con Microsoft Entra ID. Ogni modello usa diversi artefatti di Microsoft Entra. Il diagramma di flusso seguente illustra come selezionare tra tre modelli di integrazione A, B e C appropriati per le applicazioni da usare con la governance delle identità. Conoscere il modello usato per una determinata applicazione consente di configurare le risorse appropriate in Microsoft Entra ID per essere pronti per la verifica di accesso.

Flowchart for application integration patterns

Modello Modello di integrazione delle applicazioni Passaggi per preparare una verifica di accesso
Un L'applicazione supporta l'accesso SSO federato, Microsoft Entra ID è l'unico provider di identità e l'applicazione non si basa su attestazioni di gruppo o ruolo. In questo modello si configura che l'applicazione richiede singole assegnazioni di ruolo dell'applicazione e che gli utenti vengono assegnati all'applicazione. Quindi, per eseguire la verifica, si crea una singola verifica di accesso per l'applicazione, degli utenti assegnati a questo ruolo applicazione. Al termine della verifica, se un utente è stato negato, verrà rimosso dal ruolo applicazione. Microsoft Entra ID non emetterà più l'utente con token federativi e l'utente non sarà in grado di accedere a tale applicazione.
G Se l'applicazione usa attestazioni di gruppo oltre alle assegnazioni di ruolo dell'applicazione. Un'applicazione può usare l'appartenenza al gruppo Active Directory o Microsoft Entra, distinta dai ruoli dell'applicazione per esprimere l'accesso più dettagliato. In questo caso, è possibile scegliere in base ai requisiti aziendali per fare in modo che gli utenti con assegnazioni di ruolo dell'applicazione siano esaminati o per esaminare gli utenti che dispongono di appartenenze ai gruppi. Se i gruppi non forniscono copertura completa dell'accesso, in particolare se gli utenti possono accedere all'applicazione anche se non sono membri di tali gruppi, è consigliabile esaminare le assegnazioni di ruolo dell'applicazione, come nel modello A precedente.
A Se l'applicazione non si basa esclusivamente su Microsoft Entra ID per l'accesso SSO federato, ma supporta il provisioning tramite SCIM, tramite aggiornamenti a una tabella SQL degli utenti, dispone di una directory LDAP non AD o supporta un protocollo di provisioning SOAP o REST. In questo modello si configura Microsoft Entra ID per effettuare il provisioning degli utenti con assegnazioni di ruolo dell'applicazione al database o alla directory dell'applicazione, aggiornare le assegnazioni di ruolo dell'applicazione in Microsoft Entra ID con un elenco degli utenti che hanno attualmente accesso e quindi creare una singola verifica di accesso delle assegnazioni di ruolo dell'applicazione. Per altre informazioni, vedere Governance degli utenti esistenti di un'applicazione per aggiornare le assegnazioni di ruolo dell'app in Microsoft Entra ID.

Altre opzioni

I modelli di integrazione elencati nella sezione precedente sono applicabili alle applicazioni SaaS di terze parti o alle applicazioni sviluppate da o per l'organizzazione.

  • Alcuni Microsoft Online Services, ad esempio Exchange Online, usano licenze. Anche se le licenze dell'utente non possono essere esaminate direttamente, se si usano assegnazioni di licenze basate su gruppo, con gruppi con utenti assegnati, è possibile esaminare invece le appartenenze di tali gruppi.
  • Alcune applicazioni usano il consenso dell'utente delegato per controllare l'accesso a Microsoft Graph o ad altre risorse. Poiché i consenso di ogni utente non sono controllati da un processo di approvazione, i consenso non sono verificabili. È invece possibile verificare chi è in grado di connettersi all'applicazione tramite criteri di accesso condizionale che possono essere basati su assegnazioni di ruolo dell'applicazione o appartenenze a gruppi.
  • Se l'applicazione non supporta protocolli di federazione o provisioning, è necessario un processo per applicare manualmente i risultati al termine di una verifica. Per un'applicazione che supporta solo l'integrazione SSO delle password, se un'assegnazione di applicazione viene rimossa al termine di una verifica, l'applicazione non verrà visualizzata nella pagina myapps per l'utente, ma non impedirà a un utente che conosce già la password di continuare ad accedere all'applicazione. Per le applicazioni locali, vedere Gestire gli utenti di un'applicazione che non supporta il provisioning. Per le applicazioni SaaS, chiedere al fornitore SaaS di eseguire l'onboarding nella raccolta di app per la federazione o il provisioning aggiornando l'applicazione per supportare un protocollo standard.

Verificare che l'applicazione sia pronta per la revisione

Ora che è stato identificato il modello di integrazione per l'applicazione, controllare che l'applicazione rappresentata in Microsoft Entra ID sia pronta per la revisione.

  1. Accedere a Microsoft Entra Amministrazione Center come almeno un Amministrazione istrator di Identity Governance.

  2. Passare a >Applicazioni aziendali di> identità>.

  3. Qui è possibile verificare se l'applicazione è nell'elenco delle applicazioni aziendali nel tenant.

  4. Se l'applicazione non è già elencata, verificare se l'applicazione è disponibile nella raccolta di applicazioni per le applicazioni che possono essere integrate per l'accesso Single Sign-On federato o il provisioning. Se si trova nella raccolta, usare le esercitazioni per configurare l'applicazione per la federazione e, se supporta il provisioning, configurare anche l'applicazione per il provisioning.

  5. Se l'applicazione non è già elencata, ma usa gruppi di sicurezza di Active Directory ed è un'applicazione Web e la configurazione dell'applicazione può essere modificata per cercare gruppi di sicurezza diversi in ACTIVE Directory, quindi aggiungere l'applicazione per l'accesso remoto tramite application proxy, spostare l'appartenenza dei gruppi di sicurezza di Active Directory esistenti in nuovi gruppi di Microsoft Entra e configurare il writeback dei gruppi di gruppo in ACTIVE Directory. Aggiornare quindi l'applicazione per verificare la presenza dei nuovi gruppi di Active Directory creati dal writeback del gruppo, come descritto in Gestire le app basate su Active Directory locale (Kerberos).

  6. Se l'applicazione non è già elencata, ma usa gruppi di sicurezza di Active Directory ed è un'applicazione Web e la configurazione dell'applicazione non può essere modificata per cercare gruppi di sicurezza diversi in ACTIVE Directory, quindi aggiungere l'applicazione per l'accesso remoto tramite application proxy, spostare l'appartenenza dei gruppi di sicurezza di Active Directory esistenti a nuovi gruppi di Microsoft Entra e configurare il writeback dei gruppi in ACTIVE Directory. Aggiornare quindi i gruppi di sicurezza di Active Directory esistenti che l'applicazione stava controllando per includere i nuovi gruppi come membri, come descritto in Gestire le app basate su Active Directory locale (Kerberos).

  7. Se l'applicazione non è già elencata, usa i gruppi di sicurezza di Active Directory e non è un'applicazione Web e la configurazione dell'applicazione può essere modificata per cercare gruppi di sicurezza diversi in ACTIVE Directory, quindi spostare l'appartenenza dei gruppi di sicurezza di Active Directory esistenti in nuovi gruppi di Microsoft Entra e configurare il writeback dei gruppi di gruppo in ACTIVE Directory. Aggiornare quindi l'applicazione per verificare la presenza dei nuovi gruppi di Active Directory creati dal writeback del gruppo, come descritto in Gestire le app basate su Active Directory locale (Kerberos).Next, update the application to check for the new AD groups created by group writeback, as described in govern Active Directory locale based apps (Kerberos). Continuare quindi alla sezione successiva.

  8. Se l'applicazione non è già elencata, usa i gruppi di sicurezza di Active Directory e non è un'applicazione Web e la configurazione dell'applicazione non può essere modificata per cercare gruppi di sicurezza diversi in ACTIVE Directory, quindi spostare l'appartenenza dei gruppi di sicurezza di Active Directory esistenti in nuovi gruppi di Microsoft Entra e configurare il writeback dei gruppi in ACTIVE Directory. Aggiornare quindi i gruppi di sicurezza di Active Directory esistenti che l'applicazione stava controllando per includere i nuovi gruppi come membri, come descritto in Gestire le app basate su Active Directory locale (Kerberos). Continuare quindi alla sezione successiva.

  9. Quando l'applicazione è nell'elenco delle applicazioni aziendali nel tenant, selezionare l'applicazione dall'elenco.

  10. Passare alla scheda Proprietà . Verificare che l'opzione Assegnazione utente obbligatoria? sia impostata su Sì. Se è impostata su No, tutti gli utenti nella directory, incluse le identità esterne, possono accedere all'applicazione e non è possibile esaminare l'accesso all'applicazione.

    Screenshot that shows planning app assignments.

  11. Passare alla scheda Ruoli e amministratori . In questa scheda vengono visualizzati i ruoli amministrativi che forniscono i diritti per controllare la rappresentazione dell'applicazione in Microsoft Entra ID, non i diritti di accesso nell'applicazione. Per ogni ruolo amministrativo che dispone delle autorizzazioni per consentire la modifica dell'integrazione o delle assegnazioni dell'applicazione e ha un'assegnazione a tale ruolo amministrativo, assicurarsi che solo gli utenti autorizzati siano in tale ruolo.

  12. Passare alla scheda Provisioning . Se il provisioning automatico non è configurato, viene arrestato o in quarantena, l'ID Entra di Microsoft non avrà un modo per notificare all'applicazione quando l'accesso di un utente viene rimosso se tale accesso viene negato durante la verifica. Il provisioning potrebbe non essere necessario per alcuni modelli di integrazione, se l'applicazione è federata e si basa esclusivamente su Microsoft Entra ID come provider di identità o l'applicazione usa gruppi di Active Directory Domain Services. Tuttavia, se l'integrazione dell'applicazione è il modello C e l'applicazione non supporta l'accesso SSO federato con Microsoft Entra ID come unico provider di identità, è necessario configurare il provisioning da Microsoft Entra ID all'applicazione. Il provisioning è necessario in modo che Microsoft Entra ID possa rimuovere automaticamente gli utenti esaminati dall'applicazione al termine di una revisione e questo passaggio di rimozione può essere eseguito tramite una modifica inviata da Microsoft Entra ID all'applicazione tramite SCIM, LDAP, SQL, SOAP o REST.

Per altre informazioni, vedere Integrazione di applicazioni con Microsoft Entra ID.

  1. Se il provisioning è configurato, selezionare Modifica mapping attributi, espandere la sezione Mapping e selezionare Provisioning utenti di Microsoft Entra. Controllare che nell'elenco dei mapping degli attributi sia presente un mapping per isSoftDeleted l'attributo nell'archivio dati dell'applicazione che si vuole impostare su false quando un utente perde l'accesso. Se questo mapping non è presente, Microsoft Entra ID non notifica all'applicazione quando un utente lascia l'ambito, come descritto in come funziona il provisioning.

  2. Se l'applicazione supporta l'accesso Single Sign-On federato, passare alla scheda Accesso condizionale. Esaminare i criteri abilitati per l'applicazione. Se sono presenti criteri abilitati, bloccare l'accesso, assegnare agli utenti i criteri, ma non altre condizioni, tali utenti potrebbero essere già bloccati per ottenere l'accesso SSO federato all'applicazione.

  3. Passare alla scheda Utenti e gruppi . Questo elenco contiene tutti gli utenti assegnati all'applicazione in Microsoft Entra ID. Se l'elenco è vuoto, una revisione dell'applicazione viene completata immediatamente, poiché non è disponibile alcun accesso per il revisore da rivedere.

  4. Se l'applicazione è integrata con il modello C, è necessario verificare che gli utenti in questo elenco siano uguali a quelli nell'archivio dati interno delle applicazioni, prima di iniziare la revisione. Microsoft Entra ID non importa automaticamente gli utenti o i relativi diritti di accesso da un'applicazione, ma è possibile assegnare utenti a un ruolo applicazione tramite PowerShell. Vedere Governance degli utenti esistenti di un'applicazione per informazioni su come inserire utenti di diversi archivi dati dell'applicazione in Microsoft Entra ID e assegnarli a un ruolo applicazione.

  5. Controllare se tutti gli utenti vengono assegnati allo stesso ruolo applicazione, ad esempio Utente. Se gli utenti vengono assegnati a più ruoli, se si crea una verifica di accesso dell'applicazione, tutte le assegnazioni a tutti i ruoli dell'applicazione verranno esaminate insieme.

  6. Controllare l'elenco degli oggetti directory assegnati ai ruoli per verificare che non siano presenti gruppi assegnati ai ruoli dell'applicazione. È possibile esaminare questa applicazione se è presente un gruppo assegnato a un ruolo; Tuttavia, un utente membro del gruppo assegnato al ruolo e il cui accesso è stato negato non verrà rimosso automaticamente dal gruppo. Se l'applicazione non si basa sui gruppi, è consigliabile prima convertire l'applicazione in modo da avere assegnazioni utente dirette, anziché membri di gruppi, in modo che un utente il cui accesso venga negato durante la verifica di accesso possa avere rimosso automaticamente l'assegnazione di ruolo dell'applicazione. Se l'applicazione si basa sui gruppi e tutti i gruppi dell'applicazione vengono assegnati allo stesso ruolo dell'applicazione, esaminare le appartenenze ai gruppi invece di esaminare le assegnazioni dell'applicazione.

Verificare che i gruppi siano pronti per la revisione

Se l'applicazione non si basa sui gruppi, passare alla sezione successiva. In caso contrario, se l'integrazione dell'applicazione richiede anche la revisione di uno o più gruppi, come descritto nel modello B, verificare che ogni gruppo sia pronto per la revisione.

  1. Accedere a Microsoft Entra Amministrazione Center come almeno un Amministrazione istrator di Identity Governance.
  2. Passare a >Gruppi.
  3. Cercare e selezionare ogni gruppo dall'elenco.
  4. Nella scheda Panoramica verificare che il tipo di appartenenza sia Assegnato e l'origine sia Cloud. Se l'applicazione usa un gruppo dinamico o un gruppo sincronizzato dall'ambiente locale, tali appartenenze a gruppi non possono essere modificate in Microsoft Entra ID. È consigliabile convertire l'applicazione in gruppi creati in Microsoft Entra ID con appartenenze assegnate, quindi copiare gli utenti membri in tale nuovo gruppo.
  5. Passare alla scheda Ruoli e amministratori . In questa scheda vengono visualizzati i ruoli amministrativi che forniscono diritti per controllare la rappresentazione del gruppo in Microsoft Entra ID, non i diritti di accesso nell'applicazione. Per ogni ruolo amministrativo che consente di modificare l'appartenenza ai gruppi e di avere utenti in tale ruolo amministrativo, assicurarsi che solo gli utenti autorizzati siano in tale ruolo.
  6. Passare alla scheda Membri . Verificare che i membri del gruppo siano utenti e che non siano presenti membri non utente o gruppi annidati. Se non sono presenti membri di un gruppo all'avvio della revisione, la revisione del gruppo viene completata immediatamente.
  7. Passare alla scheda Proprietari . Assicurarsi che nessun utente non autorizzato venga visualizzato come proprietari. Se si chiede ai proprietari del gruppo di eseguire la verifica di accesso di un gruppo, verificare che il gruppo disponga di uno o più proprietari.

Selezionare i revisori appropriati

Quando si crea ogni verifica di accesso, gli amministratori possono scegliere uno o più revisori. I revisori possono eseguire una verifica scegliendo gli utenti per l'accesso continuo a una risorsa o rimuovendoli.

In genere un proprietario della risorsa è responsabile dell'esecuzione di una revisione. Se si sta creando una revisione di un gruppo, come parte della revisione dell'accesso per un'applicazione integrata nel modello B, è possibile selezionare i proprietari del gruppo come revisori. Poiché le applicazioni in Microsoft Entra ID non hanno necessariamente un proprietario, l'opzione per selezionare il proprietario dell'applicazione come revisore non è possibile. Al contrario, quando si crea la revisione, è possibile specificare i nomi dei proprietari dell'applicazione come revisori.

È anche possibile scegliere, quando si crea una revisione di un gruppo o di un'applicazione, per avere una revisione a più fasi. Ad esempio, è possibile selezionare per fare in modo che il responsabile di ogni utente assegnato esegua la prima fase della revisione e il proprietario della risorsa la seconda fase. In questo modo il proprietario della risorsa può concentrarsi sugli utenti che sono già stati approvati dal manager.

Prima di creare le revisioni, verificare di disporre di postazioni sufficienti dello SKU di governance dell'ID Microsoft Entra P2 o Microsoft Entra ID Nel tenant. Verificare inoltre che tutti i revisori siano utenti attivi con indirizzi di posta elettronica. All'avvio delle verifiche di accesso, ogni utente esamina un messaggio di posta elettronica da Microsoft Entra ID. Se il revisore non dispone di una cassetta postale, non riceverà il messaggio di posta elettronica all'avvio della revisione o a un promemoria tramite posta elettronica. Inoltre, se non sono in grado di accedere a Microsoft Entra ID, non potranno eseguire la revisione.

Creare le recensioni

Dopo aver identificato le risorse, l'applicazione e, facoltativamente, uno o più gruppi, in base al modello di integrazione e a chi devono essere i revisori, è possibile configurare Microsoft Entra ID per avviare le recensioni.

  1. Per questo passaggio, è necessario trovarsi nel Global administrator ruolo o Identity Governance administrator .

  2. Nei modelli A e C si crea una verifica di accesso, selezionando l'applicazione. Seguire le istruzioni nella guida per la creazione di una verifica di accesso di gruppi o applicazioni per creare la revisione delle assegnazioni di ruolo dell'applicazione.

  3. Se l'applicazione è integrata con il modello B, usare la stessa guida per creare verifiche di accesso aggiuntive per ognuno dei gruppi.

    Nota

    Se si crea una verifica di accesso e si abilitano gli helper delle decisioni di revisione, l'helper decisionale varia a seconda della risorsa da esaminare. Se la risorsa è un'applicazione, le raccomandazioni sono basate sul periodo di 30 giorni a seconda del momento in cui l'utente ha eseguito l'ultimo accesso all'applicazione. Se la risorsa è un gruppo, le raccomandazioni si basano sull'intervallo in cui l'utente ha eseguito l'ultimo accesso a qualsiasi applicazione nel tenant, non solo all'applicazione che usa tali gruppi.

  4. All'avvio delle verifiche di accesso, chiedere ai revisori di fornire input. Per impostazione predefinita, ogni utente riceve un messaggio di posta elettronica da Microsoft Entra ID con un collegamento al pannello di accesso, in cui esamina l'appartenenza ai gruppi o accede all'applicazione.

Visualizzare le assegnazioni aggiornate al termine delle revisioni

Una volta avviate le revisioni, è possibile monitorare lo stato di avanzamento e aggiornare i responsabili approvazione, se necessario, fino al completamento della revisione. È quindi possibile confermare che gli utenti, il cui accesso è stato negato dai revisori, hanno l'accesso rimosso dall'applicazione.

  1. Monitorare le verifiche di accesso, assicurandosi che i revisori eseseguono selezioni per approvare o negare l'esigenza dell'utente di continuare l'accesso, fino al completamento della verifica di accesso.

  2. Se l'applicazione automatica non è stata selezionata al momento della creazione della revisione, è necessario applicare i risultati della revisione al termine.

  3. Attendere che lo stato della revisione venga modificato in Risultato applicato. È possibile che, dopo alcuni minuti, eventuali utenti rifiutati vengano rimossi dall'appartenenza al gruppo o dall'assegnazione dell'applicazione.

  4. Se in precedenza è stato configurato il provisioning degli utenti nell'applicazione, quando vengono applicati i risultati, Microsoft Entra ID avvia il deprovisioning degli utenti negati dall'applicazione. È possibile monitorare il processo di deprovisioning degli utenti. Se il provisioning indica un errore con l'applicazione, è possibile scaricare il log di provisioning per verificare se si è verificato un problema con l'applicazione.

  5. Se è stato configurato il writeback dei gruppi per i gruppi esaminati, attendere il completamento del writeback del gruppo in Microsoft Entra Cloud Sync e propagare le modifiche a tutti i controller di dominio.

  6. Se il provisioning non è stato configurato per l'applicazione, è necessario copiare separatamente l'elenco di utenti negati nell'applicazione. Ad esempio, nelle verifiche di accesso per un gruppo gestito da Active Directory di Windows Server usare questo script di esempio di PowerShell. Lo script descrive le chiamate di Microsoft Graph necessarie ed esporta i cmdlet di PowerShell di Windows Server AD per eseguire le modifiche.

  7. Se lo si desidera, è anche possibile scaricare un report della cronologia delle revisioni completate.

  8. Per quanto tempo un utente che ha negato l'accesso continuo può continuare a usare un'applicazione federata dipende dalla durata della sessione dell'applicazione e dalla durata del token di accesso. Se le applicazioni usano Kerberos, poiché Kerberos memorizza nella cache le appartenenze a un gruppo di un utente quando accedono a un dominio, gli utenti potrebbero continuare ad accedere fino alla scadenza dei ticket Kerberos. Per altre informazioni sul controllo della durata dei token di accesso, vedere Durata dei token configurabili.

Passaggi successivi