Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Gli scenari di controllo e creazione di report di Microsoft 365 spesso coinvolgono script automatici in PowerShell per Exchange Online e in PowerShell per Sicurezza e conformità. In passato, l'accesso automatico richiedeva di memorizzare il nome utente e la password in un file locale o in un archivio di credenziali segreto a cui si accedeva in fase di esecuzione. Tuttavia, come tutti sappiamo, archiviare le credenziali utente in locale non è una buona procedura di sicurezza.
L'autenticazione basata su certificati (CBA) o l'autenticazione solo app, come descritto in questo articolo, supporta scenari di automazione e script non presidiati usando app e certificati Microsoft Entra.
Nota
Sapevi che puoi connetterti a PowerShell per Exchange Online usando le identità gestite in Azure? Vedere Usare le identità gestite di Azure per connettersi a PowerShell di Exchange Online.
Le funzionalità e le procedure descritte in questo articolo richiedono le versioni seguenti del modulo PowerShell di Exchange Online:
- Exchange Online PowerShell (Connect-ExchangeOnline): Versione 2.0.4 o successiva.
- Sicurezza & Conformità PowerShell (Connect-IPPSSession): Versione 3.0.0 o successiva.
Per istruzioni su come installare o aggiornare il modulo, vedere Installare e aggiornare il modulo PowerShell di Exchange Online. Per istruzioni su come utilizzare il modulo in Automazione di Azure, vedere Gestire i moduli in Automazione di Azure.
L'autenticazione CBA o solo app è disponibile in Office 365 gestito da 21Vianet in Cina.
Le connessioni API REST nel modulo PowerShell V3 di Exchange Online richiedono i moduli PowerShellGet e PackageManagement. Per altre informazioni, vedere PowerShellGet per connessioni basate su REST in Windows.
Se le procedure descritte in questo articolo non funzionano, verificare che le versioni di anteprima dei moduli PackageManagement o PowerShellGet non siano installate eseguendo il comando seguente:
Get-InstalledModule PackageManagement -AllVersions; Get-InstalledModule PowerShellGet -AllVersions.In Exchange Online PowerShell non è possibile usare le procedure descritte in questo articolo con i cmdlet di Gruppo di Microsoft 365 seguenti:
È possibile usare Microsoft Graph per sostituire la maggior parte delle funzionalità di questi cmdlet. Per altre informazioni, vedere Utilizzo dei gruppi in Microsoft Graph.
Per eseguire i cmdlet di eDiscovery con l'autenticazione solo app in PowerShell per la sicurezza & la conformità, utilizzare ExchangeOnlineManagement 3.10.1 o versione successiva, includere l'opzione EnableSearchOnlySession quando si esegue Connect-IPPSSession e configurare l'entità servizio e il controllo degli accessi in base al ruolo di eDiscovery. Per altre informazioni, vedere Configurare l'autenticazione solo app per PowerShell di eDiscovery.
Gli scenari delegati sono supportati in Exchange Online. Il metodo consigliato per connettersi tramite delega è usare GDAP e il consenso dell'app. Per ulteriori informazioni, vedere Usare il modulo PowerShell v3 di Exchange Online con GDAP e consenso dell'app. È anche possibile usare applicazioni multi-tenant quando non vengono create relazioni CSP con il cliente. I passaggi necessari per l'uso delle applicazioni multi-tenant sono indicati nelle normali istruzioni in questo articolo.
Utilizzare l'opzione SkipLoadingFormatData nel cmdlet Connect-ExchangeOnline se viene visualizzato l'errore seguente quando si usa Windows PowerShell SDK per connettersi:
The term 'Update-ModuleManifest' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Come funziona?
Il modulo PowerShell di Exchange Online usa la libreria di autenticazione di Active Directory per recuperare un token solo app usando l'ID applicazione, l'ID tenant (organizzazione) e l'identificazione personale del certificato. All'oggetto dell'applicazione di cui è stato eseguito il provisioning all'interno di Microsoft Entra ID è assegnato un ruolo directory, che viene restituito nel token di accesso. Il controllo degli accessi in base al ruolo (RBAC) della sessione viene configurato utilizzando le informazioni sul ruolo della directory disponibili nel token.
Esempi di connessione
Gli esempi seguenti mostrano come usare il modulo PowerShell di Exchange Online con l'autenticazione solo app:
Importante
Nei comandi di connessione seguenti usare il dominio primario .onmicrosoft.com dell'organizzazione come valore del parametro Organization .
I comandi di connessione seguenti hanno molte delle stesse opzioni descritte in Connettersi a Exchange Online PowerShell e Connettersi a Sicurezza & Conformità PowerShell. Ad esempio:
Gli ambienti Microsoft 365 GCC High, Microsoft 365 DoD o Microsoft 365 China (gestito da 21Vianet) richiedono i parametri e i valori aggiuntivi seguenti:
Microsoft 365 GCC High
Connect-ExchangeOnline -ExchangeEnvironmentName O365USGovGCCHighConnect-IPPSSession -ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/organizations*
Microsoft 365 DOD
Connect-ExchangeOnline -ExchangeEnvironmentName O365USGovDoDConnect-IPPSSession -ConnectionUri https://compliance.dod.microsoft.com/powershell-liveid -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/organizations*
Microsoft 365 gestito da 21Vianet (Cina)
Connect-ExchangeOnline -ExchangeEnvironmentName O365ChinaConnect-IPPSSession -ConnectionUri https://ps.compliance.protection.partner.outlook.cn/powershell-liveid -AzureADAuthorizationEndpointUri https://login.chinacloudapi.cn/organizations*
* Il valore AzureADAuthorizationEndpointUri che termina con
/organizationsconsente solo gli account aziendali o dell'istituto di istruzione. Il valore URI precedente che termina con/commonfunziona ancora, ma potrebbe essere richiesto di scegliere tra un account personale e un account aziendale o dell'istituto di istruzione. È consigliabile usare il/organizationsvalore URI negli scenari aziendali in cui gli account consumer devono essere esclusi.Se un comando Connect-IPPSSession presenta un prompt di accesso, eseguire il comando:
$Global:IsWindows = $trueprima del comando Connect-IPPSSession .Per eseguire i cmdlet di eDiscovery, utilizzare ExchangeOnlineManagement 3.10.1 o versione successiva e aggiungere l'opzione EnableSearchOnlySession al comando Connect-IPPSSession .
Connettersi usando un'identificazione personale del certificato:
Nota
Il parametro CertificateThumbprint è supportato solo in Microsoft Windows.
Il certificato deve essere installato nel computer in cui si esegue il comando. Il certificato deve essere installato nell'archivio certificati utente.
PowerShell per Exchange Online
Connect-ExchangeOnline -CertificateThumbPrint "012THISISADEMOTHUMBPRINT" -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"PowerShell per Sicurezza e conformità:
Connect-IPPSSession -CertificateThumbPrint "012THISISADEMOTHUMBPRINT" -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
Connettersi usando un oggetto certificato:
Non è necessario installare il certificato nel computer in cui si esegue il comando. È possibile archiviare l'oggetto certificato in remoto. Il certificato viene recuperato durante l'esecuzione dello script.
PowerShell per Exchange Online
Connect-ExchangeOnline -Certificate <%X509Certificate2 Object%> -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"PowerShell per Sicurezza e conformità:
Connect-IPPSSession -Certificate <%X509Certificate2 Object%> -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
Connettersi con un certificato locale:
Nota
L'uso di un comando ConvertTo-SecureString per archiviare la password del certificato in locale vanifica lo scopo di un metodo di connessione sicuro per gli scenari di automazione. L'uso sicuro di un comando Get-Credential per richiedere la password del certificato non è l'ideale per gli scenari di automazione. In altre parole, non esiste un modo automatizzato e sicuro per connettersi usando un certificato locale.
PowerShell per Exchange Online
Connect-ExchangeOnline -CertificateFilePath "C:\Users\navin\Desktop\automation-cert.pfx" -CertificatePassword (Get-Credential).password -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"PowerShell per Sicurezza e conformità:
Connect-IPPSSession -CertificateFilePath "C:\Users\navin\Desktop\automation-cert.pfx" -CertificatePassword (Get-Credential).password -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
Configurare l'autenticazione solo app
Per l'autenticazione usando gli oggetti applicazione è necessaria una procedura di onboarding iniziale. L'applicazione e l'entità servizio vengono usati in modo intercambiabile, ma un'applicazione è simile a un oggetto classe, mentre un'entità servizio è come un'istanza della classe. Per altre informazioni, vedere Oggetti entità applicazione e servizio in Microsoft Entra ID.
Per un flusso visivo dettagliato sulla creazione di applicazioni in Microsoft Entra ID, vedere https://aka.ms/azuread-app.
Assegnare autorizzazioni API all'applicazione.
Per impostazione predefinita, un oggetto applicazione dispone dell'autorizzazione API delegataMicrosoft Graph>User.Read . Aggiungere l'autorizzazione per l'applicazione corrispondente alla connessione di PowerShell:
- Exchange Online PowerShell (Connect-ExchangeOnline): Office 365 Exchange Online>Exchange.ManageAsApp.
- Security & Compliance PowerShell (Connect-IPPSSession): Microsoft Exchange Online Protection>Exchange.ManageAsApp.
Se l'applicazione si connette a entrambi gli ambienti, aggiungere entrambe le autorizzazioni. Concedere il consenso dell'amministratore a livello di tenant per ogni autorizzazione.
-
Per l'autenticazione solo app in Microsoft Entra ID, in genere si utilizza un certificato per richiedere l'accesso. Chiunque abbia il certificato e la relativa chiave privata può usare l'app con le autorizzazioni concesse all'app.
Crea e configura un certificato X.509, che viene utilizzato per autenticare la tua applicazione in base a Microsoft Entra ID, richiedendo il token di accesso solo per l'app. Il certificato può essere autofirmato.
Questa procedura è simile alla generazione di una password per gli account utente. Vedere questa sezione più avanti in questo articolo per istruzioni su come generare certificati in PowerShell.
Nota
Crittografia: i certificati di nuova generazione (CNG) non sono supportati per l'autenticazione solo delle app con Exchange. I certificati CNG vengono creati per impostazione predefinita nelle versioni moderne di Windows. È necessario usare un certificato di un provider chiave CSP. In questa sezione vengono illustrati due metodi supportati per creare un certificato CSP.
Passaggio 1: Registrare l'applicazione in Microsoft Entra ID
Nota
Nota: in caso di problemi, controllare le autorizzazioni necessarie per verificare che l'account possa creare l'identità.
Apri l'Interfaccia di amministrazione di Microsoft Entra all'indirizzohttps://portal.azure.com/.
Nella casella di ricerca nella parte superiore della pagina, inizia a digitare Registrazioni app, quindi seleziona Registrazioni app dai risultati nella sezione Servizi.
In alternativa, per passare direttamente alla pagina Registrazioni app app, usare https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade.
Nella pagina Registrazioni app selezionare Nuova registrazione.
Nella pagina Registrare un'applicazione, configurare le seguenti impostazioni:
Nome: inserire un nome descrittivo. Ad esempio, ExO PowerShell CBA.
Tipi di account supportati: Verificare che sia selezionata l'opzione Solo account in questa directory organizzativa (<solo NomeOrganizzazione> - tenant singolo ).
Nota
Per rendere l'applicazione multitenant per gli scenari delegati di Exchange Online, selezionare il valore Account in qualsiasi directory organizzativa (qualsiasi directory Microsoft Entra - Multitenant).
URI di reindirizzamento (facoltativo): questa impostazione è facoltativa. Se necessario, configura le impostazioni seguenti:
- Piattaforma: Seleziona Web.
- URI: immettere l'URI in cui viene inviato il token di accesso.
Nota
Non è possibile creare credenziali per applicazioni native, perché non è possibile utilizzare applicazioni native per applicazioni automatizzate.
Al termine, nella pagina Registrazioni app selezionare Registrati.
Viene visualizzata la pagina Panoramica dell'app registrata. Lascia aperta questa pagina. Lo userai nel passaggio successivo.
Passaggio 2: assegnare autorizzazioni API all'applicazione
Scegli uno dei metodi seguenti in questa sezione per assegnare le autorizzazioni API all'app:
- Selezionare e assegnare le autorizzazioni API dal portale.
- Modificare il manifesto dell'app per assegnare le autorizzazioni API. (Microsoft 365 GCC High e le organizzazioni DoD dovrebbero usare questo metodo).
Selezionare e assegnare le autorizzazioni API dal portale
Nella pagina Panoramica app seleziona Autorizzazioni API nella sezione Gestisci.
Nella pagina Autorizzazioni API app selezionare Aggiungi un'autorizzazione.
Nel riquadro a comparsa Richiedi autorizzazioni API che si apre, selezionare le API usate dall'organizzazione , quindi selezionare l'API che corrisponde alla connessione PowerShell:
- Exchange Online PowerShell (Connect-ExchangeOnline): cercare e selezionare Office 365 Exchange Online.
- Sicurezza & Conformità PowerShell (Connect-IPPSSession): cercare e selezionare Protezione Microsoft Exchange Online.
Se l'applicazione si connette a entrambi gli ambienti, ripetere i passaggi da 2 a 5 per l'altra API prima di continuare con il passaggio 6.
Lo screenshot seguente mostra la selezione di PowerShell per Exchange Online:
Nel riquadro a comparsa Quale tipo di autorizzazioni richiede l'applicazione? visualizzato selezionare Autorizzazioni applicazione.
Nell'elenco delle autorizzazioni visualizzato espandere Exchange, selezionare Exchange.ManageAsApp e quindi selezionare Aggiungi autorizzazioni.
Nella pagina delle autorizzazioni dell'API dell'app verificare che ogni autorizzazione Exchange.ManageAsApp richiesta sia elencata e contenga i valori seguenti:
Tipo: Applicazione.
Consenso dell'amministratore obbligatorio: Sì.
Stato: il valore attuale non corretto non è concesso per <l'organizzazione>.
Per modificare questo valore, selezionare Concedi il consenso dell'amministratore per <l'organizzazione>, leggere la finestra di dialogo di conferma visualizzata e quindi selezionare Sì.
Il valore dello stato è ora Concesso per <l'organizzazione>.
Per la voceUser.Read predefinita di Microsoft Graph>, selezionare ...>Revoca il consenso dell'amministratore e quindi seleziona Sì nella finestra di dialogo di conferma che si apre per ripristinare lo stato al valore vuoto predefinito.
Chiudere la pagina Autorizzazioni API (non la scheda del browser) per tornare alla pagina Registrazioni app. Si userà la pagina Registrazioni app in un passaggio successivo.
Modificare il manifesto dell'app per assegnare le autorizzazioni API
Nota
Le procedure descritte in questa sezione aggiungono le autorizzazioni predefinite esistenti nell'app (autorizzazioni User.Read delegate in Microsoft Graph) con l'autorizzazione richiesta per l'applicazione Exchange.ManageAsApp . Usa i valori delle risorse che corrispondono alla connessione di PowerShell. Se l'applicazione si connette sia a Exchange Online PowerShell che a Security & Compliance PowerShell, includere sia gli oggetti risorsa Exchange che un oggetto risorsa Microsoft Graph.
Nella pagina Panoramica dell'app selezionare Manifesto nella sezione Gestisci.
Nella pagina Manifesto dell'app, trovare la voce (alla riga 42 o verso la
requiredResourceAccessriga). Per PowerShell per Exchange Online, fare in modo che la voce sia simile al frammento di codice seguente:"requiredResourceAccess": [ { "resourceAppId": "00000002-0000-0ff1-ce00-000000000000", "resourceAccess": [ { "id": "dc50a0fb-09a3-484d-be87-e023b12c6440", "type": "Role" } ] }, { "resourceAppId": "00000003-0000-0000-c000-000000000000", "resourceAccess": [ { "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d", "type": "Scope" } ] } ],Nota
Per la sicurezza & la conformità PowerShell in qualsiasi ambiente, inclusi Microsoft 365 GCC High e DoD, usare i valori seguenti per la
requiredResourceAccessvoce:"requiredResourceAccess": [ { "resourceAppId": "00000007-0000-0ff1-ce00-000000000000", "resourceAccess": [ { "id": "455e5cd2-84e8-4751-8344-5672145dfa17", "type": "Role" } ] }, { "resourceAppId": "00000003-0000-0000-c000-000000000000", "resourceAccess": [ { "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d", "type": "Scope" } ] } ],Quando hai finito nella pagina Manifesto , seleziona Salva.
Sempre nella pagina Manifesto , seleziona Autorizzazioni API dalla sezione Gestisci .
Nella pagina delle autorizzazioni API verificare che ogni autorizzazione Exchange.ManageAsApp richiesta sia elencata e contenga i valori seguenti:
Tipo: Applicazione.
Consenso dell'amministratore obbligatorio: Sì.
Stato: il valore attuale non corretto non è concesso per <l'organizzazione>.
Modificare il valore Stato selezionando Concedi consenso amministratore per l'organizzazione>, leggere la finestra di dialogo di conferma visualizzata e <quindi selezionare Sì.
Il valore dello stato è ora Concesso per <l'organizzazione>.
Per la voceUser.Read predefinita di Microsoft Graph>, selezionare ...>Revoca il consenso dell'amministratore e quindi seleziona Sì nella finestra di dialogo di conferma che si apre per ripristinare lo stato al valore vuoto predefinito.
Chiudere la pagina Autorizzazioni API (non la scheda del browser) per tornare alla pagina Registrazioni app. Si userà la pagina Registrazioni app in un passaggio successivo.
Passaggio 3: Generare un certificato
Nota
Crittografia: i certificati di nuova generazione (CNG) non sono supportati per l'autenticazione solo app, come descritto in questo articolo. I certificati CNG vengono creati per impostazione predefinita nelle versioni moderne di Windows. È necessario usare un certificato fornito da un provider di chiavi CSP.
È possibile usare un certificato autofirmato, un certificato emesso da un'infrastruttura a chiave pubblica interna o PKI (ad esempio, Servizi certificati Active Directory o Servizi di certificazione AD) oppure un certificato emesso da un'autorità di certificazione (CA) commerciale attendibile.
Gli unici requisiti per il certificato X.509 sono una chiave privata (.pfx) e un certificato pubblico (.cer) esportabili e disponibili.
Per un certificato autofirmato, utilizzare uno dei metodi seguenti:
(Scelta consigliata): usare i cmdlet New-SelfSignedCertificate, Export-Certificate e Export-PfxCertificate in una sessione di PowerShell con privilegi elevati (una finestra di PowerShell aperta dopo aver selezionato Esegui come amministratore) per richiedere un certificato autofirmato ed esportare le chiavi private e pubbliche del certificato in file (SHA1 per impostazione predefinita). Ad esempio:
# Create a self-signed certificate $mycert = New-SelfSignedCertificate -DnsName "contoso.org" -CertStoreLocation "cert:\CurrentUser\My" -NotAfter (Get-Date).AddYears(1) -KeySpec KeyExchange # Export the X.509 certificate and the associated private key to a password-protected .pfx file $mycert | Export-PfxCertificate -FilePath mycert.pfx -Password (Get-Credential).password # Export the X.509 public certificate to a .cer file $mycert | Export-Certificate -FilePath mycert.cerUsare lo script Create-SelfSignedCertificate per generare certificati SHA1.
.\Create-SelfSignedCertificate.ps1 -CommonName "MyCompanyName" -StartDate 2026-01-06 -EndDate 2027-01-06
Passaggio 4: Allegare il certificato all'applicazione Microsoft Entra
Dopo aver registrato il certificato con l'applicazione, è possibile usare la chiave privata (file con estensione.pfx) o l'identificazione personale per l'autenticazione.
Nella scheda Applicazioni di proprietà nella pagina di registrazione delle app dalla fine del passaggio 2, selezionare l'applicazione.
Se è necessario tornare alla pagina di registrazione delle app , utilizzare https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/RegisteredApps, verificare che la scheda Applicazioni di proprietà sia selezionata e quindi selezionare l'applicazione.
Nella pagina dell'applicazione che si apre, seleziona Certificati & segreti dalla sezione Gestisci .
Nella pagina Certificati & segreti , seleziona Carica certificato.
Nel riquadro a comparsa Carica certificato che si apre, passa al certificato pubblico (
.cerfile) esportato nel passaggio 3 e quindi seleziona Aggiungi.
Il certificato SharePointSSL verrà visualizzato nella sezione Certificati.
Chiudere la pagina Certificati e segreti e la pagina Registrazioni app e tornare alla pagina https://portal.azure.com/ principale. Lo userai nel passaggio successivo.
Passaggio 4b: Solo scenari delegati di Exchange Online: concedere il consenso dell'amministratore per l'app multi-tenant
Se l'applicazione è stata resa multi-tenant per gli scenari delegati di Exchange Online nel passaggio 1, è necessario concedere il consenso dell'amministratore all'autorizzazione Exchange.ManageAsApp in modo che l'applicazione possa eseguire i cmdlet in Exchange Online in ogni organizzazione tenant. È necessario generare un URL di consenso amministratore per ogni tenant del cliente. Prima che chiunque usi l'applicazione multi-tenant per connettersi a Exchange Online nell'organizzazione tenant, un amministratore nel tenant del cliente deve aprire l'URL seguente:
https://login.microsoftonline.com/<tenant-id>/adminconsent?client_id=<client-id>&scope=https://outlook.office365.com/.default
-
<tenant-id>è l'ID tenant del cliente. -
<client-id>è l'ID dell'applicazione multi-tenant. - L'ambito predefinito viene usato per concedere le autorizzazioni dell'applicazione.
Per altre informazioni sulla sintassi dell'URL, vedere Richiedere le autorizzazioni a un amministratore di directory.
Passaggio 5: Assegnare le autorizzazioni di ruolo all'applicazione
Sono disponibili le opzioni seguenti:
Opzione 1: assegnare i ruoli di Microsoft Entra all'applicazione: usare i ruoli di Microsoft Entra predefiniti per concedere tutte le autorizzazioni del ruolo. Non è possibile personalizzare o limitare questi ruoli.
Opzione 2: assegnare gruppi di ruoli personalizzati all'applicazione usando le entità servizio: questa opzione è consigliata negli scenari seguenti:
- È necessario limitare i comandi disponibili nell'applicazione.
- È necessario usare un ambito di scrittura per limitare i destinatari che possono essere modificati.
Opzione 3: combinare i ruoli di Microsoft Entra con gruppi di ruoli personalizzati: Controllo dell'accesso basato sui ruoli (RBAC) combina le autorizzazioni di tutte le origini. Questo metodo è consigliabile per estendere le funzionalità di un ruolo di Microsoft Entra predefinito. Ad esempio, è possibile estendere le funzionalità del ruolo di amministratore destinatario di Exchange concedendo autorizzazioni aggiuntive da un ruolo personalizzato.
Queste opzioni sono descritte nelle sottosezioni seguenti.
Nota
Per le applicazioni multitenant negli scenari delegati di Exchange Online, è necessario assegnare autorizzazioni in ogni tenant del cliente.
Opzione 1: assegnare ruoli Microsoft Entra all'applicazione
I ruoli di Microsoft Entra supportati sono descritti nella tabella seguente:
| Ruolo | Exchange Online PowerShell |
Sicurezza e conformità PowerShell |
|---|---|---|
| Amministratore di conformità | ✔ | ✔ |
| Amministratore di Exchange¹ | ✔ | |
| Exchange Recipient Administrator | ✔ | |
| Amministratore globale¹ ² | ✔ | ✔ |
| Lettore globale | ✔ | ✔ |
| Amministratore dell'helpdesk | ✔ | |
| Amministratore della sicurezza¹ | ✔ | ✔ |
| Ruolo con autorizzazioni di lettura per la sicurezza | ✔ | ✔ |
¹ I ruoli Amministratore globale e Amministratore di Exchange forniscono le autorizzazioni necessarie per qualsiasi attività in PowerShell per Exchange Online. Ad esempio:
- Gestione destinatari.
- Funzionalità di sicurezza e protezione. Ad esempio, protezione da posta indesiderata, antimalware, anti-phishing e i report associati.
Il ruolo di amministratore della sicurezza non dispone delle autorizzazioni necessarie per le stesse attività.
² Microsoft sostiene con forza il principio del privilegio minimo. Assegnare agli account solo le autorizzazioni minime necessarie per eseguire le attività consente di ridurre i rischi per la sicurezza e rafforzare la protezione complessiva dell'organizzazione. L'amministratore globale è un ruolo con privilegi elevati che è consigliabile limitare agli scenari di emergenza o quando non è possibile usare un ruolo diverso.
Per istruzioni generali sull'assegnazione di ruoli in Microsoft Entra ID, vedere Assegnare ruoli di Microsoft Entra agli utenti.
Nota
I passaggi seguenti sono leggermente diversi per PowerShell per Exchange Online e PowerShell per Sicurezza e conformità. Vengono mostrati i passaggi per entrambi gli ambienti. Per configurare i ruoli per entrambi gli ambienti, ripetere i passaggi descritti in questa sezione.
Nell'interfaccia di amministrazione di Microsoft Entra all'indirizzo https://portal.azure.com/, iniziare a digitare ruoli e amministratori nella casella di ricerca nella parte superiore della pagina, quindi selezionare ruoli e amministratori di Microsoft Entra dai risultati nella sezione Servizi.
In alternativa, per passare direttamente alla pagina Ruoli e amministratori di Microsoft Entra, usare https://portal.azure.com/#view/Microsoft_AAD_IAM/AllRolesBlade.
Nella pagina Ruoli e amministratori trovare e selezionare uno dei ruoli supportati facendo clic nome del ruolo (non sulla casella di controllo) nei risultati.
PowerShell di Exchange Online: Ad esempio, trovare e selezionare il ruolo di amministratore di Exchange.
PowerShell per la sicurezza & la conformità: ad esempio, trovare e selezionare il ruolo Amministratore conformità .
Nella pagina Attività che viene visualizzata selezionare Aggiungi attività.
PowerShell per Exchange Online
PowerShell per Sicurezza e conformità:
Nel riquadro a comparsa Aggiungi assegnazioni, trovare e selezionare l’app creata nel Passaggio 1.
Al termine, nel riquadro a comparsa Aggiungi attività , selezionare Aggiungi.
Nella pagina Assegnazioni , verificare che il ruolo sia assegnato all'app.
PowerShell per Exchange Online
PowerShell per Sicurezza e conformità:
Opzione 2: assegnare gruppi di ruoli personalizzati all'applicazione usando le entità servizio
Nota
È necessario connettersi a PowerShell o a Exchange Online PowerShell per la sicurezza & la conformità prima di completare la procedura per creare una nuova entità servizio. La creazione di una nuova entità servizio senza connettersi a PowerShell non funziona (l'ID dell'app Azure e l'ID oggetto sono necessari per creare la nuova entità servizio).
Per informazioni sulla creazione di gruppi di ruoli personalizzati, vedere Creare gruppi di ruoli in Exchange Online e Creare gruppi di ruoli di collaborazione Email & nel portale Microsoft Defender. Il gruppo di ruoli personalizzato assegnato all'applicazione può contenere qualsiasi combinazione di ruoli predefiniti e personalizzati.
Per assegnare gruppi di ruoli personalizzati all'applicazione usando le entità servizio, eseguire la procedura seguente:
In Microsoft Graph PowerShell, eseguire i comandi seguenti per archiviare i dettagli dell'applicazione Microsoft Entra registrata nel passaggio 1 in una variabile:
Connect-MgGraph -Scopes AppRoleAssignment.ReadWrite.All,Application.Read.All $<VariableName1> = Get-MgServicePrincipal -Filter "DisplayName eq '<AppName>'"Ad esempio:
Connect-MgGraph -Scopes AppRoleAssignment.ReadWrite.All,Application.Read.All $AzureADApp = Get-MgServicePrincipal -Filter "DisplayName eq 'ExO PowerShell CBA'"Per informazioni dettagliate sulla sintassi e sui parametri, vedere Get-MgServicePrincipal.
Nella stessa finestra di PowerShell, connettersi a Exchange Online PowerShell o a Sicurezza & Conformità PowerShell ed eseguire i comandi seguenti per:
- Creare un oggetto entità servizio per l'applicazione Microsoft Entra.
- Archiviare i dettagli dell'entità servizio in una variabile da usare nel passaggio successivo.
New-ServicePrincipal -AppId $<VariableName1>.AppId -ObjectId $<VariableName1>.Id -DisplayName "<Descriptive Name>" $<VariableName2> = Get-ServicePrincipal -Identity "<Descriptive Name>"Ad esempio:
New-ServicePrincipal -AppId $AzureADApp.AppId -ObjectId $AzureADApp.Id -DisplayName "SP for Azure AD App ExO PowerShell CBA" $SP = Get-ServicePrincipal -Identity "SP for Azure AD App ExO PowerShell CBA"Per informazioni dettagliate sulla sintassi e sui parametri, vedere New-ServicePrincipal.
In PowerShell o in Exchange Online PowerShell per la sicurezza & la conformità eseguire il comando seguente per aggiungere l'entità servizio come membro del gruppo di ruoli personalizzato:
Add-RoleGroupMember -Identity "<CustomRoleGroupName>" -Member <$<VariableName2>.Identity | $<VariableName2>.ObjectId | $<VariableName2>.Id>Ad esempio:
Add-RoleGroupMember -Identity "Contoso View-Only Recipients" -Member $SP.IdentityPer informazioni dettagliate sulla sintassi e sui parametri, vedere Add-RoleGroupMember.