Quando si connette Libraesva ESG a un tenant Microsoft 365 utilizzando l'integrazione nativa Microsoft 365 (Graph API), il modo in cui le shared mailbox vengono importate e gestite ha implicazioni sui report di quarantena, sull'esperienza di login e sui ruoli assegnati.
Questo documento spiega il metodo predefinito e la possibile alternativa (script di mapping esterno).
Metodo 1 (Predefinito): Shared Mailbox importate come Functional User
Per progettazione, quando Libraesva ESG importa gli utenti da Microsoft 365, le shared mailbox vengono create in ESG come Functional User. Questo accade perché la Microsoft Graph API non fornisce dati dettagliati sui permessi relativi all'accesso alla shared mailbox. Senza informazioni sui permessi, ESG non può mappare automaticamente la shared mailbox agli effettivi utenti finali che vi accedono.
I Functional User hanno le seguenti caratteristiche:
-
Non possono accedere direttamente al portale web ESG.
-
I loro report di quarantena vengono generati e archiviati in ESG come per gli utenti normali, ma con funzionalità limitate (nessun pulsante "View").
-
-
Aprire l'email del report di quarantena dalla shared mailbox nella propria casella di posta.
-
Seguire il link al portale web ESG.
-
Accedere utilizzando il proprio account utente tramite Microsoft 365 SSO
-
L'utente finale deve disporre degli stessi ruoli e permessi ESG che il functional user possiede per poter agire sugli elementi in quarantena.
Ad esempio, se la shared mailbox (functional user) dispone dei permessi di Release, anche l'utente finale deve essere autorizzato a rilasciare messaggi in ESG. Se i ruoli non corrispondono, l'utente potrebbe non essere in grado di eseguire azioni di rilascio o gestione elenco.
Svantaggi del comportamento predefinito
-
Report di quarantena separati:
-
Un report di quarantena per la propria casella di posta personale.
-
Un report di quarantena per la shared mailbox.
-
- Nessuna opzione “View” diretta: Gli elementi in quarantena della shared mailbox potrebbero non mostrare l'azione “View” nel report allo stesso modo degli elementi della casella di posta personale.
Metodo 2: Script di mapping esterno
Esiste un metodo alternativo che consiste nel mappare le shared mailbox agli account utente effettivi configurando uno script esterno tramite PowerShell e l'API ESG.
[fruitful_alert type="alert-info"]
Nota: questo approccio può valere la pena se il numero di shared mailbox da mappare è elevato; se si hanno solo poche shared mailbox da mappare a un paio di utenti, è preferibile farlo manualmente.
Questo può essere fatto aggiungendo l'indirizzo della shared mailbox come "indirizzo secondario" all'utente ESG che deve poter gestirne la quarantena tramite "User Management".[/fruitful_alert]
L'obiettivo dello script è, per ogni shared mailbox, identificare gli utenti con accesso delegato e utilizzare l'API ESG per assegnare l'indirizzo della shared mailbox come indirizzo secondario sull'account utente corrispondente in ESG. In questo modo, la shared mailbox diventa effettivamente associata ad account utente reali in ESG, invece di essere rappresentata come functional user.
Lo script esegue i seguenti passaggi:
-
Connessione a Exchange Online tramite PowerShell.
- Login con M365 SSO dell'amministratore del tenant per accedere ai dati.
-
Recupero di tutte le shared mailbox.
-
Per ogni shared mailbox:
-
Ottenere i permessi della mailbox (FullAccess concesso a utenti e gruppi).
-
Per i gruppi, espandere il gruppo ai suoi membri.
-
-
Per ogni utente con permessi sulla shared mailbox, aggiungere l'SMTP primario della shared mailbox come indirizzo secondario tramite l'API ESG.
Svantaggi dello script di mapping esterno
- Per mantenere aggiornati questi mappamenti, è necessario eseguire lo script su base pianificata.
- Script personalizzato da costruire basandosi sul template fornito
Questo script di esempio è fornito da Libraesva come template e deve essere personalizzato in base al proprio tenant e ambiente: https://docs.libraesva.com/knowledgebase/automatic-mapping-of-shared-mailbox-in-m365/