Condividi tramite

Connettersi a Sicurezza e conformità PowerShell

Questo articolo contiene istruzioni su come connettersi a PowerShell per la sicurezza & conformità usando il modulo Exchange Online PowerShell con o senza autenticazione a più fattori.

Il modulo Exchange Online PowerShell usa l'autenticazione moderna per la connessione a PowerShell Exchange Online powershell e powershell di conformità & sicurezza. Per altre informazioni sul modulo Exchange Online PowerShell, vedere Informazioni sul modulo Exchange Online PowerShell.

Per connettersi a Security & Compliance PowerShell per l'automazione, vedere Autenticazione solo app per script automatici.

Che cosa è necessario sapere prima di iniziare?

Passaggio 1: Caricare il modulo Exchange Online PowerShell

Nota

Se il modulo è già installato, è in genere possibile ignorare questo passaggio ed eseguire Connect-IPPSSession senza prima caricare manualmente il modulo.

Dopo aver installato il modulo, aprire una finestra di PowerShell e caricare il modulo eseguendo il comando seguente:

Import-Module ExchangeOnlineManagement

Passaggio 2: Connettersi e autenticare

Nota

È probabile che i comandi connect non riescano se il percorso del profilo dell'account usato per connettersi contiene caratteri di PowerShell speciali , $ad esempio . La soluzione alternativa consiste nel connettersi usando un account diverso che non include caratteri speciali nel percorso del profilo.

Il comando da eseguire utilizza la sintassi seguente:

Connect-IPPSSession -UserPrincipalName <UPN> [-ConnectionUri <URL>] [-AzureADAuthorizationEndpointUri <URL>] [-DelegatedOrganization <String>] [-PSSessionOption $ProxyOptions]

Per informazioni dettagliate su sintassi e parametri, vedere Connect-ExchangeOnlineIPPSSession .

  • <UPN> è l'account nel formato del nome dell'entità utente , [email protected]ad esempio .

  • I valori ConnectionUri e AzureADAuthorizationEndpointUri necessari dipendono dalla natura dell'organizzazione di Microsoft 365. I valori comuni sono descritti nell'elenco seguente:

    • Microsoft 365 o Microsoft 365 GCC:
      • ConnectionUri: nessuno. Il valore https://ps.compliance.protection.outlook.com/powershell-liveid/ obbligatorio è anche il valore predefinito, quindi non è necessario usare il parametro ConnectionUri negli ambienti GCC di Microsoft 365 o Microsoft 365.
      • AzureADAuthorizationEndpointUri: nessuno. Il valore https://login.microsoftonline.com/common obbligatorio è anche il valore predefinito, quindi non è necessario usare il parametro AzureADAuthorizationEndpointUri negli ambienti GCC di Microsoft 365 o Microsoft 365.
    • Microsoft 365 GCC High:
      • ConnectionUri: https://ps.compliance.protection.office365.us/powershell-liveid/
      • AzureADAuthorizationEndpointUri: https://login.microsoftonline.us/common
    • Microsoft 365 DoD:
      • ConnectionUri: https://l5.ps.compliance.protection.office365.us/powershell-liveid/
      • AzureADAuthorizationEndpointUri: https://login.microsoftonline.us/common
    • Office 365 gestito da 21Vianet:
      • ConnectionUri: https://ps.compliance.protection.partner.outlook.cn/powershell-liveid
      • AzureADAuthorizationEndpointUri: https://login.chinacloudapi.cn/common

  • Se si è dietro un server proxy, è possibile usare il parametro PSSessionOption nel comando di connessione. Eseguire prima di tutto questo comando: $ProxyOptions = New-PSSessionOption -ProxyAccessType <Value>, dove <Value> è IEConfig, WinHttpConfigo AutoDetect. Usare quindi il valore $ProxyOptions per il parametro PSSessionOption . Per altre informazioni, vedere New-PSSessionOption.

  • A seconda della natura dell'organizzazione, è possibile omettere il parametro UserPrincipalName nel passaggio successivo. Al contrario, immettere il nome utente e la password o selezionare le credenziali archiviate dopo aver eseguito il comando Connect-IPPSSession. Se questa operazione non funziona, è necessario usare il parametro UserPrincipalName.

  • Se non si usa l'autenticazione a più fattori (MFA), dovrebbe essere possibile usare il parametro Credential anziché il parametro UserPrincipalName. Per prima cosa, eseguire il comando $Credential = Get-Credential, immettere nome utente e password, quindi usare il nome variabile per il parametro Credential (-Credential $Credential). Se questa operazione non funziona, è necessario usare il parametro UserPrincipalName.

Connettersi a Security & Compliance PowerShell con un prompt di accesso interattivo

  1. Gli esempi seguenti funzionano in Windows PowerShell 5.1 e PowerShell 7 per gli account con o senza MFA:

    • Questo esempio consente di connettersi a PowerShell in Sicurezza e conformità in un'organizzazione di Microsoft 365 o Microsoft 365 GCC:

      Connect-IPPSSession -UserPrincipalName [email protected]

    • Questo esempio consente di connettersi a PowerShell in Sicurezza e conformità in un'organizzazione di Microsoft GCC High:

      Connect-IPPSSession -UserPrincipalName [email protected] -ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/common

    • Questo esempio consente di connettersi a PowerShell in Sicurezza e conformità in un'organizzazione di Microsoft 365 DoD:

      Connect-IPPSSession -UserPrincipalName [email protected] -ConnectionUri https://l5.ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/common

    • Questo esempio si connette a Sicurezza e conformità PowerShell in un'organizzazione di Office 365 gestita da 21Vianet:

      Connect-IPPSSession -UserPrincipalName [email protected] -ConnectionUri https://ps.compliance.protection.partner.outlook.cn/powershell-liveid -AzureADAuthorizationEndpointUri https://login.chinacloudapi.cn/common

  2. Nella finestra di accesso visualizzata immettere la password e quindi selezionare Accedi.

    Immettere la password nella finestra Accedi al tuo account.

    Nota

    In PowerShell 7 viene usato l'accesso Single Sign-On (SSO) basato su browser per impostazione predefinita, quindi il prompt di accesso viene aperto nel Web browser predefinito anziché in una finestra di dialogo autonoma.

  3. Solo MFA: viene generato e recapitato un codice di verifica in base all'opzione di risposta configurata per l'account(ad esempio, un SMS o l'app Microsoft Authenticator nel dispositivo).

    Nella finestra di verifica visualizzata immettere il codice di verifica e quindi selezionare Verifica.

    Immettere il codice di verifica nella finestra Accedi al tuo account.

Connettersi a Security & Compliance PowerShell senza richiesta di accesso (script automatici)

Per istruzioni complete, vedere Autenticazione solo app per script automatici in PowerShell Exchange Online PowerShell e Sicurezza & Conformità a PowerShell.

Connettersi a Security & Compliance PowerShell nelle organizzazioni dei clienti

Le procedure in questa sezione richiedono la versione 3.0.0 o successiva del modulo.

In Security & Compliance PowerShell è necessario usare AzureADAuthorizationEndpointUri con il parametro DelegatedOrganization .

Per altre informazioni sui partner e le organizzazioni dei clienti, vedere gli articoli seguenti:

Questo esempio si connette alle organizzazioni dei clienti negli scenari seguenti:

  • Connettersi a un'organizzazione cliente usando un account CSP.

  • Connettersi a un'organizzazione cliente usando un GDAP.

  • Connettersi a un'organizzazione cliente come guest.

    Connect-IPPSSession -UserPrincipalName [email protected] -DelegatedOrganization adatum.onmicrosoft.com -AzureADAuthorizationEndpointUri https://login.microsoftonline.com/adatum.onmicrosoft.com

Passaggio 3: Disconnetti al termine

Assicurarsi di disconnettere la sessione al termine. Se si chiude la finestra di PowerShell senza disconnettere la sessione, è possibile usare tutte le sessioni disponibili ed è necessario attendere la scadenza delle sessioni. Per disconnettere la sessione, eseguire il comando seguente:

Disconnect-ExchangeOnline

Per disconnettersi in modo invisibile all'utente senza un prompt di conferma, eseguire il comando seguente:

Disconnect-ExchangeOnline -Confirm:$false

Nota

È probabile che il comando di disconnessione non riesca se il percorso del profilo dell'account usato per connettersi contiene caratteri powershell speciali , $ad esempio . La soluzione alternativa consiste nel connettersi usando un account diverso che non include caratteri speciali nel percorso del profilo.

Come si fa a sapere di aver eseguito correttamente la connessione?

I cmdlet di Sicurezza e conformità PowerShell vengono importati nella tua sessione Windows PowerShell locale come mostrato da una barra di avanzamento. Se non vengono visualizzati errori, la connessione è stata eseguita correttamente. Un breve test consiste nell'eseguire un cmdlet di Sicurezza e conformità Poweshell (ad esempio, Get-RetentionCompliancePolicy) e vedere i risultati.

Se non vengono visualizzati errori, controllare i requisiti seguenti:

  • Un problema comune è rappresentato da una password errata. Eseguire di nuovo i tre passaggi e prestare particolare attenzione al nome utente e alla password usati.

  • L'account usato per connettersi deve essere abilitato per PowerShell. Per altre informazioni, vedere Abilitare o disabilitare l’accesso a PowerShell di Exchange Online..

  • Il traffico sulla porta TCP 80 deve essere aperto tra il computer locale e Microsoft 365. È probabile che sia aperto, ma è bene verificare se l'organizzazione prevede criteri restrittivi relativi all'accesso a Internet.

  • Le connessioni basate su REST a Security & Compliance PowerShell richiedono il modulo PowerShellGet. Per dipendenza, il modulo PowerShellGet richiede il modulo PackageManagement. Si verificano errori se si tenta di connettersi senza che entrambi i moduli vengano installati. Ad esempio, potrebbe essere visualizzato l'errore seguente:

    Il termine "Update-ModuleManifest" non è riconosciuto come nome di un cmdlet, di una funzione, di un file di script o di un programma operabile. Controllare l'ortografia del nome oppure, se è stato incluso un percorso, verificare che questo sia corretto e riprovare.

    Per altre informazioni sui requisiti del modulo PowerShellGet e PackageManagement, vedere PowerShellGet per le connessioni basate su REST in Windows.

  • Potrebbe non essere possibile connettersi se l'indirizzo IP del client cambia durante la richiesta di connessione. L'errore si verifica se l'organizzazione usa un pool SNAT (Network Address Translation) di origine con più indirizzi IP. L'errore di connessione ha questo aspetto:

    La richiesta per Windows Remote Shell con ID> ShellId <non è riuscita perché la shell non è stata trovata nel server. Le possibili cause sono: il valore di ShellId specificato non è corretto oppure la shell non esiste più nel server. Fornire la ShellId corretta o creare una nuova shell e ripetere l'operazione.

    Per risolvere il problema, eseguire una delle operazioni seguenti:

    • Usare un pool SNAT che contiene un singolo indirizzo IP.
    • Forzare l'uso di un indirizzo IP specifico per le connessioni all'endpoint di PowerShell Security & Compliance.