Controllare l'accesso alle funzionalità in Viva
È possibile usare i criteri di accesso in Viva per gestire quali utenti possono accedere a funzionalità specifiche nelle app Viva. La gestione degli accessi alle funzionalità consente di abilitare o disabilitare funzionalità specifiche in Viva per gruppi o utenti specifici nel tenant e quindi personalizzare le distribuzioni in base ai requisiti normativi e aziendali locali.
Importante
È possibile avere più criteri di accesso per una funzionalità attiva nell'organizzazione. Ciò significa che un utente o un gruppo potrebbe essere interessato da più criteri. In tal caso, i criteri più restrittivi assegnati direttamente a un utente o a un gruppo hanno la precedenza. Per altre informazioni, vedere Funzionamento dei criteri di accesso in Viva.
Un amministratore autorizzato nel tenant può creare, assegnare e gestire i criteri di accesso da PowerShell. Quando un utente accede a Viva, vengono applicate le impostazioni dei criteri e vengono visualizzate solo le funzionalità che non sono state disabilitate.
Nota
È possibile disabilitare solo un subset di funzionalità nelle app Viva usando la gestione degli accessi alle funzionalità. La limitazione dell'uso di una funzionalità potrebbe influire sulla funzionalità di altre funzionalità nell'app. Assicurarsi di controllare la documentazione dell'app sulla funzionalità specifica per comprendere le implicazioni della disabilitazione o dell'abilitazione dell'accesso a una funzionalità.
È possibile usare la gestione degli accessi alle funzionalità per gestire l'accesso alle funzionalità seguenti:
Nota
- Alcune funzionalità potrebbero non supportare i criteri utente/gruppo. Inoltre, i criteri per un'app possono avere un impatto sull'intero tenant o sugli utenti nel tenant. Per altre informazioni, vedere la documentazione sulla funzionalità usando il collegamento nella tabella.
- Solo alcune funzionalità hanno i controlli disponibili per gli amministratori per fornire agli utenti la possibilità di rifiutare esplicitamente.
App | Funzionalità | Controllare il rifiuto esplicito dell'utente? | Chi può gestire l'accesso | ModuleID |
---|---|---|---|---|
Partecipazione | Copilot in Engage | No | amministratore Engage | VivaEngage |
Riepilogo dell'intelligenza artificiale | Sì | amministratore Engage | VivaEngage | |
Obiettivi | Copilot in Viva Goals | No | amministratore Goals | VivaGoals |
Insights | Pubblicazione report degli analisti (anteprima) | No | amministratore Viva Insights | VivaInsights |
Copilot Dashboard | No | Amministratore globale | VivaInsights | |
Abilitazione automatica del dashboard copilot | No | Amministratore globale | VivaInsights | |
Delega del dashboard copilot | No | Amministratore globale | VivaInsights | |
Valore assistito copilot | No | Amministratore globale | VivaInsights | |
Copilot in Viva Insights | No | amministratore Viva Insights | VivaInsights | |
Digest Welcome Email | No | Amministratore globale | VivaInsights | |
Costo e qualità delle riunioni | No | Amministratore Insights | VivaInsights | |
Riflessione | No | Amministratore Insights | VivaInsights | |
Polso | Personalizzazione | No | amministratore di Viva Pulse | VivaPulse |
Conversazioni del team nei report Pulse | No | amministratore di Viva Pulse | VivaPulse | |
Competenze | Visibilità delle competenze predefinite* | Sì | Amministratore delle informazioni | VivaSkills |
Suggerimenti per le competenze* | Sì | Amministratore delle informazioni | VivaSkills |
* Il controllo della funzionalità o della funzionalità potrebbe non essere ancora disponibile per tutti i tenant. Il supporto verrà aggiunto a breve.
Nota
- È possibile controllare l'accesso solo alle funzionalità che supportano i criteri di accesso e che sono disponibili nel tenant. Ad esempio, se si dispone di un tenant basato su EDU, non è possibile usare i criteri per ottenere l'accesso alle funzionalità non disponibili per i tenant EDU. Lo stesso vale per le funzionalità non disponibili in aree geografiche specifiche. Per altre informazioni sulla disponibilità, vedere la documentazione relativa alla funzionalità specifica che si vuole usare.
- L'applicazione delle modifiche alla funzionalità Copilot in Viva Engage potrebbe richiedere fino a 48 ore. Le modifiche per altre funzionalità in genere hanno effetto entro 24 ore.
Prima di creare un criterio di accesso in Viva, è necessario:
- Una versione supportata di Microsoft 365 o una licenza di Viva Suite
- Accesso a Exchange Online PowerShell versione 3.2.0 o successiva. Se è necessario usare gruppi non abilitati alla posta elettronica, è necessario avere accesso a Exchange PowerShell versione 3.5.1 o successiva.
- Account utente creati in o sincronizzati con Microsoft Entra ID.
- Gruppi di Microsoft 365, Microsoft Entra gruppi di sicurezza creati in o sincronizzati con Microsoft Entra ID o gruppi di distribuzione. Il tipo di appartenenza può essere dinamico o assegnato.
- Ruolo necessario per l'app e la funzionalità specifiche.
Importante
Viva gestione degli accessi alle funzionalità non è disponibile per i clienti che hanno piani Microsoft 365 GCC, GCC High o DOD.
Prima di poter creare un criterio di accesso, è necessario ottenere il featureID per la funzionalità specifica a cui si vuole controllare l'accesso.
Usare il cmdlet Di PowerShell Get-VivaModuleFeature per ottenere un elenco di tutte le funzionalità disponibili in un'app Viva specifica e i relativi ID associati.
Installare Exchange Online PowerShell versione 3.2.0 o successiva:
Install-Module -Name ExchangeOnlineManagement
Connettersi a Exchange Online con le credenziali di amministratore:
Connect-ExchangeOnline
Completare l'autenticazione come amministratore globale o il ruolo necessario per la funzionalità specifica per cui si stanno creando i criteri.
Eseguire il cmdlet Get-VivaModuleFeature per visualizzare le funzionalità che è possibile gestire usando un criterio di accesso.
Ad esempio, per vedere quali funzionalità sono supportate in Viva Insights, eseguire il cmdlet seguente:
Get-VivaModuleFeature -ModuleId VivaInsights
Trovare la funzionalità per cui si vuole creare un criterio di accesso e prendere nota del relativo featureID.
Ora che è disponibile il featureID, usare il cmdlet Di PowerShell Add-VivaModuleFeaturePolicy per creare un criterio di accesso per la funzionalità.
È possibile assegnare un massimo di 10 criteri per funzionalità a utenti e gruppi. Ogni criterio può essere assegnato a un massimo di 20 utenti o gruppi. È possibile assegnare un criterio aggiuntivo per funzionalità all'intero tenant usando il parametro -Everyone , che funzionerà come stato predefinito globale per tale funzionalità nell'intera organizzazione.
Eseguire il cmdlet Add-VivaModuleFeaturePolicy per creare un nuovo criterio di accesso.
Nota
Se la funzionalità supporta i controlli utente per rifiutare esplicitamente, assicurarsi di impostare il parametro IsUserControlEnabled quando si creano i criteri. In caso contrario, i controlli utente per i criteri usano lo stato predefinito per la funzionalità.
Ad esempio, eseguire quanto segue per creare un criterio di accesso, denominato UsersAndGroups, per limitare l'accesso alla funzionalità reflection in Viva Insights.
Add-VivaModuleFeaturePolicy -ModuleId VivaInsights -FeatureId Reflection -Name UsersAndGroups -IsFeatureEnabled $false -GroupIds group1@contoso.com,group2@contoso.com -UserIds user1@contoso.com,user2@contoso.com
In questo esempio viene aggiunto un criterio per la funzionalità Reflection in Viva Insights. Il criterio disabilita la funzionalità per gli utenti e i membri del gruppo specificati. Se si vuole disabilitare la funzionalità per tutti gli utenti, usare invece il parametro -Everyone .
È possibile aggiornare un criterio di accesso per modificare se una funzionalità è abilitata o disabilitata, nonché per modificare a chi si applica il criterio (tutti, un utente o un gruppo).
Ad esempio, basandosi sull'ultimo esempio, per aggiornare a chi si applica il criterio, eseguire il cmdlet seguente:
Update-VivaModuleFeaturePolicy -ModuleId VivaInsights -FeatureId Reflection -PolicyId xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -GroupIds group1@contoso.com,group2@contoso.com
Proprio come quando si creano i criteri, se i criteri supportano i controlli utente, includere il parametro IsUserControlEnabled quando si modificano i criteri.
Importante
I valori specificati per i parametri -UserIds e -GroupIds o il parametro -Everyone sovrascrivono tutti gli utenti o i gruppi esistenti. Per mantenere gli utenti e i gruppi esistenti, è necessario specificare gli utenti o i gruppi esistenti e gli eventuali utenti o gruppi aggiuntivi che si desidera aggiungere. Se non si includono utenti o gruppi esistenti nel comando, tali utenti o gruppi specifici vengono rimossi dai criteri. Non è possibile aggiornare un criterio per un determinato utente o gruppo in modo da includere l'intero tenant se esiste già un criterio per l'intero tenant per la funzionalità. È supportato un solo criterio a livello di tenant.
Per verificare quali funzionalità sono disabilitate per un utente o un gruppo specifico, eseguire il cmdlet Get-VivaModuleFeatureEnablement . Questo cmdlet restituisce quello che viene chiamato stato di abilitazione per l'utente o il gruppo.
Ad esempio:
Get-VivaModuleFeatureEnablement -ModuleId VivaInsights -FeatureId Reflection -Identity user@contoso.com
Usare il cmdlet Remove-VivaModuleFeaturePolicy per eliminare un criterio di accesso.
Ad esempio, per eliminare i criteri di accesso alle funzionalità di Reflection, iniziare recuperando l'UID specifico per i criteri di accesso. È possibile ottenerlo eseguendo Get-VivaModuleFeaturePolicy. In seguito, eseguire il seguente comando cmdlet:
Remove-VivaModuleFeaturePolicy -ModuleId VivaInsights -FeatureId Reflection -PolicyId xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
In caso di problemi durante la creazione o l'uso di criteri di accesso per Viva funzionalità dell'app, verificare che la funzionalità per cui si sta tentando di impostare un criterio sia elencata nella tabella delle funzionalità ed è disponibile per il tenant.
Se viene visualizzato il messaggio di errore "Richiedente non autorizzato a completare la richiesta" durante l'esecuzione di un cmdlet di PowerShell, verificare se sono stati impostati criteri di accesso condizionale che bloccano indirizzi IP specifici. In tal caso, rimuovere l'indirizzo IP da tale criterio o creare un nuovo criterio per consentire l'inserimento dell'indirizzo IP. Altre informazioni su Microsoft Entra l'accesso condizionale e la risoluzione dei problemi di accesso condizionale usando lo strumento What If.
- Quando un utente accede e accede Viva, viene immediatamente eseguito un controllo per verificare se è presente un criterio che si applica all'utente.
- Se l'utente viene assegnato direttamente a un criterio o è membro di un gruppo di Microsoft Entra o di Microsoft 365 con un criterio assegnato, viene applicata l'impostazione dei criteri.
- Se all'utente non viene assegnato direttamente un criterio o non è membro di un gruppo di Microsoft Entra o di Microsoft 365 a cui è assegnato un criterio, vengono applicati i criteri predefiniti globali. Se non sono presenti criteri predefiniti globali, viene applicato lo stato di abilitazione predefinito per la funzionalità.
- Se all'utente sono assegnati più criteri direttamente o come gruppo, vengono applicati i criteri più restrittivi. Si noti che non tutte le funzionalità includono la possibilità per un utente di rifiutare esplicitamente. Ecco l'ordine di precedenza:
- La funzionalità è disabilitata.
- La funzionalità è abilitata.
- La funzionalità è abilitata e l'utente può rifiutare esplicitamente.
- Se gli utenti si trovano in gruppi annidati e si applicano criteri di accesso al gruppo padre, gli utenti nei gruppi annidati ricevono i criteri. I gruppi annidati e gli utenti in tali gruppi annidati devono essere creati in o sincronizzati con Microsoft Entra ID.
- Le modifiche ai criteri di accesso diventano effettive per l'utente entro 24 ore, se non diversamente indicato per una funzionalità specifica. Le modifiche per Copilot in Viva Engage potrebbero richiedere fino a 48 ore.
- Quando si aggiungono utenti o li si rimuove da un Microsoft Entra ID o da un gruppo di Microsoft 365, possono essere necessarie 24 ore prima che le modifiche apportate all'accesso alle funzionalità abbiano effetto.
- Quando un amministratore rimuove l'opzione per consentire agli utenti di rifiutare esplicitamente abilitando o disabilitando completamente la funzionalità, la preferenza di consenso esplicito dell'utente non viene mantenuta e verrà ripristinato lo stato predefinito. Se un amministratore riabilitare l'opzione che consente a un utente di rifiutare esplicitamente una funzionalità, gli utenti dovranno scegliere di rifiutare nuovamente la funzionalità.
- Le modifiche rapide allo stato di abilitazione per una funzionalità in meno di 24 ore dopo aver apportato la modifica potrebbero non comportare la reimpostazione delle preferenze di consenso esplicito dell'utente.
- Per una cronologia della creazione, degli aggiornamenti e delle eliminazioni dei criteri, vedere i log delle modifiche Viva Feature Access Management (VFAM) per l'organizzazione in Microsoft Purview.
- I criteri vengono valutati in base all'utente.
- Solo un criterio per funzionalità può essere assegnato a "tutti". Questo criterio funge da stato predefinito globale per tale funzionalità nell'organizzazione.
- Poiché i nuovi controlli funzionalità vengono resi disponibili in Viva per gestire l'accesso di utenti e gruppi, vengono aggiunti a Viva gestione degli accessi alle funzionalità.
- Quando le identità utente in Microsoft Entra ID vengono eliminate, i dati utente vengono eliminati da Viva gestione degli accessi alle funzionalità. Se le identità utente vengono riabilitare durante il periodo di eliminazione temporanea, l'amministratore deve riassegnare i criteri all'utente.
- Quando i gruppi in Microsoft Entra ID e Microsoft 365 vengono eliminati, vengono eliminati dai criteri archiviati. Se i gruppi vengono riabilitare durante il periodo di eliminazione temporanea, l'amministratore deve riassegnare i criteri ai gruppi.