Autenticação somente do aplicativo para scripts autônomos no Exchange Online PowerShell e PowerShell de Conformidade & Segurança

Cenários de auditoria e relatórios no Microsoft 365 geralmente envolvem scripts autônomos no PowerShell do Exchange Online e na Segurança e Conformidade do PowerShell. No passado, o login autônomo exigia que você armazenasse o nome de usuário e a senha em um arquivo local ou em um cofre secreto acessado em tempo de execução. Mas, como todos sabemos, armazenar credenciais de usuário localmente não é uma boa prática de segurança.

A autenticação baseada em certificado (CBA) ou autenticação somente de aplicativo, conforme descrito neste artigo, dá suporte a cenários de script e automação autônomos usando certificados e aplicativos do Microsoft Entra.

Observação

Você sabia que pode se conectar ao PowerShell do Exchange Online usando identidades gerenciadas no Azure? Confira Usar identidades gerenciadas do Azure para se conectar ao PowerShell do Exchange Online.
Os recursos e procedimentos descritos neste artigo exigem as seguintes versões do módulo do PowerShell do Exchange Online:
- PowerShell do Exchange Online (Connect-ExchangeOnline): versão 2.0.4 ou posterior.
- PowerShell de Segurança & Conformidade (Connect-IPPSSession): versão 3.0.0 ou posterior.
Para obter instruções sobre como instalar ou atualizar o módulo, consulte Instalar e atualizar o módulo do PowerShell do Exchange Online. Para obter instruções sobre como usar o módulo na Automação do Azure, consulte Gerenciar módulos na Automação do Azure.
A autenticação CBA ou somente aplicativo está disponível no Office 365 operado pela 21Vianet na China.
As conexões da API REST no módulo V3 do PowerShell do Exchange Online exigem os módulos PowerShellGet e PackageManagement. Para obter mais informações, consulte PowerShellGet para conexões baseadas em REST no Windows.
Se os procedimentos neste artigo não funcionarem para você, verifique se você não tem versões prévias dos módulos PackageManagement ou PowerShellGet instaladas executando o seguinte comando: Get-InstalledModule PackageManagement -AllVersions; Get-InstalledModule PowerShellGet -AllVersions
No PowerShell do Exchange Online, não é possível usar os procedimentos neste artigo com os seguintes cmdlets do Grupo do Microsoft 365:
Você pode usar o Microsoft Graph para substituir a maioria das funcionalidades desses cmdlets. Para obter mais informações, consulte Trabalhando com grupos no Microsoft Graph.
Para executar cmdlets de Descoberta Eletrônica com autenticação somente de aplicativo no PowerShell de Segurança & Conformidade, use o ExchangeOnlineManagement 3.10.1 ou posterior, inclua a opção EnableSearchOnlySession ao executar o Connect-IPPSSession e configure a entidade de serviço e o RBAC (controle de acesso baseado em função) da Descoberta Eletrônica. Para obter mais informações, consulte Configurar a autenticação somente de aplicativo para o PowerShell de Descoberta Eletrônica.
Há suporte para cenários delegados no Exchange Online. O método recomendado para conectar com delegação é usar GDAP e Consentimento de aplicativo. Para obter mais informações, consulte Usar o módulo do PowerShell v3 do Exchange Online com GDAP e consentimento de aplicativo. Você também pode usar aplicativos multilocatário quando as relações CSP não são criadas com o cliente. As etapas necessárias para usar aplicativos multilocatário são destacadas nas instruções regulares deste artigo.
Use a opção SkipLoadingFormatData no cmdlet Connect-ExchangeOnline se você receber o seguinte erro ao usar o SDK do Windows PowerShell para se conectar: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.

Como funciona?

O módulo do PowerShell do Exchange Online usa a Biblioteca de Autenticação do Active Directory para buscar um token somente de aplicativo usando a ID do aplicativo, a ID do locatário (organização) e a impressão digital do certificado. O objeto de aplicativo provisionado no Microsoft Entra ID tem uma Função de Diretório atribuída a ele, que é retornada no token de acesso. O RBAC (controle de acesso baseado em função) da sessão é configurado usando as informações de função de diretório disponíveis no token.

Exemplos de conexão

Os exemplos a seguir mostram como usar o módulo do PowerShell do Exchange Online com autenticação somente de aplicativo:

Importante

Nos comandos de conexão a seguir, use o domínio primário .onmicrosoft.com da sua organização como o valor do parâmetro Organization .

Os comandos de conexão a seguir têm muitas das mesmas opções disponíveis, conforme descrito em Conectar-se ao Exchange Online PowerShell e Conectar-se à Segurança & Conformidade do PowerShell. Por exemplo:

Os ambientes Microsoft 365 GCC High, Microsoft 365 DoD ou Microsoft 365 China (operado pela 21Vianet) exigem os seguintes parâmetros e valores extras:
Microsoft 365 GCC High
- Connect-ExchangeOnline -ExchangeEnvironmentName O365USGovGCCHigh
- Connect-IPPSSession -ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/organizations^*
Microsoft 365 DoD
- Connect-ExchangeOnline -ExchangeEnvironmentName O365USGovDoD
- Connect-IPPSSession -ConnectionUri https://compliance.dod.microsoft.com/powershell-liveid -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/organizations^*
Microsoft 365 operado por 21Vianet (China)
- Connect-ExchangeOnline -ExchangeEnvironmentName O365China
- Connect-IPPSSession -ConnectionUri https://ps.compliance.protection.partner.outlook.cn/powershell-liveid -AzureADAuthorizationEndpointUri https://login.chinacloudapi.cn/organizations^*
^* O valor AzureADAuthorizationEndpointUri que termina em /organizations permite apenas contas corporativas ou de estudante. O valor de URI mais antigo que termina em /common ainda funciona, mas pode solicitar que você escolha entre uma conta pessoal e uma conta corporativa ou de estudante. Recomendamos o valor URI /organizations em cenários corporativos onde as contas de consumidor devem ser excluídas.
Se um comando Connect-IPPSSession apresentar um prompt de entrada, execute o comando: $Global:IsWindows = $true antes do comando Connect-IPPSSession .
Para executar cmdlets de Descoberta Eletrônica, use o ExchangeOnlineManagement 3.10.1 ou posterior e adicione a opção EnableSearchOnlySession ao comando Connect-IPPSSession .

Conectar-se usando uma impressão digital de certificado:

Observação

O parâmetro CertificateThumbprint tem suporte apenas no Microsoft Windows.

O certificado precisa ser instalado no computador em que você está executando o comando. O certificado deve ser instalado no repositório de certificados do usuário.
- PowerShell do Exchange Online:
```
Connect-ExchangeOnline -CertificateThumbPrint "012THISISADEMOTHUMBPRINT" -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
```
- Segurança e Conformidade do PowerShell:
```
Connect-IPPSSession -CertificateThumbPrint "012THISISADEMOTHUMBPRINT" -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
```
Conectar-se usando um objeto de certificado:

O certificado não precisa ser instalado no computador no qual você está executando o comando. Você pode armazenar o objeto de certificado remotamente. O certificado é buscado quando o script é executado.
- PowerShell do Exchange Online:
```
Connect-ExchangeOnline -Certificate <%X509Certificate2 Object%> -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
```
- Segurança e Conformidade do PowerShell:
```
Connect-IPPSSession -Certificate <%X509Certificate2 Object%> -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
```
Conectar-se usando um certificado local:

Observação

Usar um comando ConvertTo-SecureString para armazenar a senha do certificado localmente anula a finalidade de um método de conexão segura para cenários de automação. Usar um comando Get-Credential para solicitar a senha do certificado com segurança não é ideal para cenários de automação. Em outras palavras, não há realmente nenhuma maneira automatizada e segura de se conectar usando um certificado local.
- PowerShell do 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"
```
- Segurança e Conformidade do PowerShell:
```
Connect-IPPSSession -CertificateFilePath "C:\Users\navin\Desktop\automation-cert.pfx" -CertificatePassword (Get-Credential).password -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
```

Configurar autenticação somente no aplicativo

A integração inicial é necessária para autenticação usando objetos do aplicativo. O aplicativo e a entidade de serviço são usados de forma intercambiável, mas um aplicativo é como um objeto de classe, enquanto uma entidade de serviço é como uma instância da classe. Para obter mais informações, consulte Objetos de entidade de serviço e aplicativo no Microsoft Entra ID.

Para obter um fluxo visual detalhado sobre a criação de aplicativos no Microsoft Entra ID, consulte https://aka.ms/azuread-app.

Registre o aplicativo no Microsoft Entra ID.
Atribuir permissões de API para o aplicativo.

Um objeto de aplicativo tem a permissão de API DelegadaMicrosoft Graph>User.Read por padrão. Adicione a permissão de aplicativo que corresponde à conexão do PowerShell:
- Exchange Online PowerShell (Connect-ExchangeOnline):Office 365 Exchange Online>Exchange.ManageAsApp.
- PowerShell de Segurança & Conformidade (Connect-IPPSSession): Proteção> Microsoft Exchange OnlineExchange.ManageAsApp.
Se o aplicativo se conectar a ambos os ambientes, adicione ambas as permissões. Conceda consentimento de administrador em todo o locatário para cada permissão.
Gerar um certificado
- Para autenticação somente de aplicativo no Microsoft Entra ID, você normalmente usa um certificado para solicitar acesso. Qualquer pessoa que tenha o certificado e sua chave privada pode usar o aplicativo com as permissões concedidas ao aplicativo.
- Crie e configure um certificado X.509, que é usado para autenticar seu aplicativo em relação ao Microsoft Entra ID, enquanto solicita o token de acesso somente do aplicativo. O certificado pode ser autoassinado.
- Esse procedimento é semelhante à geração de uma senha para contas de usuário. Confira essa seção mais adiante neste artigo para obter instruções sobre como gerar certificados no PowerShell.
  
  Observação
  
  Criptografia: os certificados CNG (Próxima Geração) não têm suporte para autenticação somente de aplicativo com o Exchange. Os certificados CNG são criados por padrão nas versões modernas do Windows. Você deve usar um certificado de um provedor de chave CSP. Esta seção aborda dois métodos suportados para criar um certificado CSP.
Anexar o certificado ao aplicativo Microsoft Entra
Atribuir permissões de funções ao aplicativo

Etapa 1: registrar o aplicativo no Microsoft Entra ID

Observação

Se você encontrar problemas, verifique as permissões necessárias para verificar se sua conta pode criar a identidade.

Abra o centro de administração do Microsoft Entra em https://portal.azure.com/.
Na caixa Pesquisar, na parte superior da página, comece a digitar Registros de aplicativo e selecione Registros de aplicativo nos resultados na seção Serviços.

Ou, para ir diretamente para a página de Registros de aplicativo, use https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade.
Na página registros de aplicativo, selecione novo registro.
Na página Registrar um aplicativo que é aberta, defina as seguintes configurações:
- Nome: digite algo descritivo. Por exemplo, ExO Windows PowerShell CBA.
- Tipos de conta com suporte: Verifique se Contas somente neste diretório organizacional (<somente YourOrganizationName> - locatário único) está selecionado.
  
  Observação
  
  Para tornar o aplicativo multilocatário para cenários delegados do Exchange Online, selecione o valor Contas em qualquer diretório organizacional (qualquer diretório do Microsoft Entra - multilocatário).
- URI de redirecionamento (opcional): essa configuração é opcional. Se você precisar usá-lo, defina as seguintes configurações:
  - Plataforma: Selecione Web.
  - URI: insira o URI para onde o token de acesso é enviado.
  Observação
  
  Não é possível criar credenciais para aplicativos nativos porque não é possível usar aplicativos nativos para aplicativos automatizados.
Quando terminar, na página de Registros de aplicativo, selecione Registrar.
Você será levado para a página Visão geral do aplicativo que registrou. Deixe esta página aberta. Você poderá usá-la na próxima etapa.

Etapa 2: atribuir permissões de API para o aplicativo

Escolha um dos seguintes métodos nesta seção para atribuir permissões de API ao aplicativo:

Selecione e atribua as permissões de API do portal.
Modifique o manifesto do aplicativo para atribuir permissões de API. (As organizações Microsoft 365 GCC High e DoD devem usar esse método).

Selecione e atribua as permissões de API do portal

Na página Visão geral do aplicativo, selecione Permissões de API na seção Gerenciar .
Na página Permissões da API do aplicativo, selecione Adicionar uma permissão.
No submenu Solicitar permissões de API aberto, selecione a guia APIs que minha organização usa e, em seguida, selecione a API que corresponde à conexão do PowerShell:
- Exchange Online PowerShell (Connect-ExchangeOnline): Pesquise e selecione Office 365 Exchange Online.
- PowerShell de Segurança & Conformidade (Connect-IPPSSession): pesquise e selecione Proteção Microsoft Exchange Online.
Se o aplicativo se conectar a ambos os ambientes, repita as etapas 2 a 5 para a outra API antes de prosseguir para a etapa 6.

A captura de tela a seguir mostra a seleção do PowerShell do Exchange Online:
Na página Que tipo de permissões seu aplicativo exige? , selecione Permissões do aplicativo.
Na lista de permissões exibida, expanda Exchange, selecione Exchange.ManageAsApp e selecione Adicionar permissões.
De volta à página de permissões de API do aplicativo, verifique se cada permissão necessária de Exchange.ManageAsApp está listada e contém os seguintes valores:
- Tipo: Aplicativo.
- Consentimento da Administração obrigatório: Sim.
- Status: O valor incorreto atual não é concedido para <a Organização>.
  
  Altere esse valor selecionando Conceder consentimento de administrador para <Organização>, leia a caixa de diálogo de confirmação que é aberta e selecione Sim.
  
  O valor Status agora é Concedido para <Organização>.
Para a entradaUser.Read do Microsoft Graph> padrão, selecione ...>Revogue o consentimento do administrador e, em seguida, selecione Sim na caixa de diálogo de confirmação que é aberta para retornar Status de volta ao valor em branco padrão.
Feche a página atual de permissões da API (não a guia do navegador) para retornar à página de registros de aplicativos. Você usará a página de Registros de aplicativo em uma próxima etapa.

Modifique o manifesto do aplicativo para atribuir permissões de API

Observação

Os procedimentos nesta seção acrescentam as permissões padrão existentes no aplicativo (permissões delegadas User.Read no Microsoft Graph) com a permissão Exchange.ManageAsApp do aplicativo necessária. Use os valores de recursos que correspondem à conexão do PowerShell. Se o aplicativo se conectar ao PowerShell Exchange Online e ao PowerShell de Segurança & Conformidade, inclua os objetos de recurso do Exchange e um objeto de recurso do Microsoft Graph.

Na página Visão geral do aplicativo, selecione Manifesto na seção Gerenciar.

Na página Manifesto do aplicativo, localize a requiredResourceAccess entrada (na linha 42 ou por volta dela). Para o Windows PowerShell do Exchange Online, faça com que a entrada se pareça com o seguinte trecho de código:

"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"
            }
        ]
    }
],

Observação

Para o PowerShell de Segurança & Conformidade em qualquer ambiente, incluindo Microsoft 365 GCC High e DoD, use os seguintes valores para a requiredResourceAccess entrada:

"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 tiver terminado na página Manifesto , selecione Salvar.

Ainda na página Manifesto , selecione as permissões de API na seção Gerenciar .
Na página Permissões de API , verifique se cada permissão necessária de Exchange.ManageAsApp está listada e contém os seguintes valores:
- Tipo: Aplicativo.
- Consentimento da Administração obrigatório: Sim.
- Status: O valor incorreto atual não é concedido para <a Organização>.
  
  Altere o valor Status selecionando Conceder consentimento de administrador para <Organização>, leia a caixa de diálogo de confirmação que é aberta e selecione Sim.
  
  O valor Status agora é Concedido para <Organização>.
Para a entradaUser.Read do Microsoft Graph> padrão, selecione ...>Revogue o consentimento do administrador e, em seguida, selecione Sim na caixa de diálogo de confirmação que é aberta para retornar Status de volta ao valor em branco padrão.
Feche a página atual de permissões da API (não a guia do navegador) para retornar à página de registros de aplicativos. Você usará a página de Registros de aplicativo em uma próxima etapa.

Etapa 3: Gerar um certificado

Observação

Criptografia: os certificados CNG (Próxima Geração) não têm suporte para autenticação somente de aplicativo, conforme descrito neste artigo. Os certificados CNG são criados por padrão em versões modernas do Windows. Você precisa usar um certificado de um provedor de chaves CSP.

Você pode usar um certificado autoassinado, um certificado emitido por uma infraestrutura de chave pública interna ou PKI (por exemplo, Serviços de Certificado do Active Directory ou AD CS) ou um certificado emitido por uma CA (autoridade de certificação) comercial confiável.

Os únicos requisitos para o certificado X.509 são uma chave privada exportável e disponível (.pfx) e um certificado público (.cer).

Para obter um certificado autoassinado use um dos seguintes métodos:

(Recomendado): use os cmdlets New-SelfSignedCertificate, Export-Certificate e Export-PfxCertificate em uma sessão do PowerShell com privilégios elevados (uma janela do PowerShell que você abriu depois de selecionar Executar como administrador) para solicitar um certificado autoassinado e exportar as chaves privada e pública do certificado para arquivos (SHA1 por padrão). Por exemplo:

# 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.cer

Use o script de script Create-SelfSignedCertificate para gerar certificados SHA1.

.\Create-SelfSignedCertificate.ps1 -CommonName "MyCompanyName" -StartDate 2026-01-06 -EndDate 2027-01-06

Etapa 4: anexar o certificado ao aplicativo Microsoft Entra

Depois de registrar o certificado com seu aplicativo, você pode usar a chave privada (.pfx arquivo) ou a miniatura para autenticação.

Na guia Aplicativos de propriedade na página Registro de aplicativos do final da Etapa 2, selecione seu aplicativo.

Se você precisar voltar à página Registro de aplicativos , use https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/RegisteredApps, verifique se a guia Aplicativos possuídos está selecionada e, em seguida, selecione seu aplicativo.
Na página do aplicativo que é aberta, selecione Certificados & segredos na seção Gerenciar .
Na página Certificados & segredos , selecione Carregar certificado.

No submenu Carregar certificado aberto, navegue até o certificado público (.cer arquivo) que você exportou na Etapa 3 e selecione Adicionar.

O certificado agora é mostrado na seção Certificados.
Feche a página atual de Certificados e segredos e, em seguida, a página de registros de aplicativoshttps://portal.azure.com/ para retornar à página principal. Você poderá usá-la na próxima etapa.

Se você tornou o aplicativo multilocatário para cenários delegados do Exchange Online na Etapa 1, precisará conceder consentimento de administrador à permissão Exchange.ManageAsApp para que o aplicativo possa executar cmdlets no Exchange Online em cada organização de locatário. Você precisa gerar uma URL de consentimento do administrador para cada locatário do cliente. Antes que qualquer pessoa use o aplicativo multilocatário para se conectar ao Exchange Online na organização do locatário, um administrador no locatário do cliente deve abrir a seguinte URL:

https://login.microsoftonline.com/<tenant-id>/adminconsent?client_id=<client-id>&scope=https://outlook.office365.com/.default

<tenant-id> é a ID do locatário do cliente.
<client-id> é a ID do aplicativo multilocatário.
O escopo padrão é usado para conceder permissões de aplicativo.

Para obter mais informações sobre a sintaxe da URL, consulte Solicitar as permissões de um administrador de diretório.

Etapa 5: atribuir permissões de função ao aplicativo

Você tem as seguintes opções:

Opção 1: atribuir funções do Microsoft Entra ao aplicativo: use funções internas do Microsoft Entra para conceder todas as permissões da função. Você não pode personalizar ou definir o escopo dessas funções.
Opção 2: atribuir grupos de funções personalizados ao aplicativo usando entidades de serviço: Recomendamos essa opção nos seguintes cenários:
- Você precisa restringir os comandos disponíveis em seu aplicativo.
- Você precisa usar um escopo de gravação para limitar quais destinatários podem ser modificados.
Opção 3: combinar funções do Microsoft Entra com grupos de funções personalizados: o RBAC combina permissões de todas as fontes. Recomendamos esse método para estender os recursos de uma função interna do Microsoft Entra. Por exemplo, você pode estender os recursos da função de Administrador de Destinatários do Exchange concedendo permissões extras de uma função personalizada.

Essas opções são descritas nas subseções a seguir.

Observação

Para aplicativos multilocatários em cenários delegados do Exchange Online, você precisa atribuir permissões em cada locatário do cliente.

Opção 1: atribuir funções do Microsoft Entra ao aplicativo

As funções do Microsoft Entra com suporte são descritas na tabela a seguir:

Função	Exchange Online PowerShell	Conformidade e Segurança PowerShell
Administrador de Conformidade	✔	✔
Administrador do Exchange¹	✔
Administrador de Destinatários do Exchange	✔
Administrador Global¹ ²	✔	✔
Leitor Global	✔	✔
Administrador da Assistência Técnica	✔
Administrador de Segurança¹	✔	✔
Leitor de Segurança	✔	✔

¹ As funções de Administrador Global e Administrador do Exchange fornecem as permissões necessárias para qualquer tarefa no Exchange Online PowerShell. Por exemplo:

Gerenciamento de destinatários.
Recursos de proteção e segurança. Por exemplo, relatórios antispam, antimalware, antiphishing e relatórios associados.

A função de Administrador de Segurança não tem as permissões necessárias para essas mesmas tarefas.

² A Microsoft defende fortemente o princípio do privilégio mínimo. Atribuir às contas apenas as permissões mínimas necessárias para realizar suas tarefas ajuda a reduzir os riscos de segurança e fortalece a proteção geral da sua organização. Administrador Global é uma função altamente privilegiada que você deve limitar a cenários de emergência ou quando não puder usar uma função diferente.

Para obter instruções gerais sobre como atribuir funções no Microsoft Entra ID, consulte Atribuir funções do Microsoft Entra aos usuários.

Observação

As etapas a seguir são ligeiramente diferentes para o PowerShell do Exchange Online vs. a Segurança e Conformidade do PowerShell. As etapas para ambos os ambientes são mostradas. Para configurar funções para ambos os ambientes, repita as etapas nesta seção.

No centro de administração do Microsoft Entra em https://portal.azure.com/, comece a digitar funções e administradores na caixa Pesquisar na parte superior da página e selecione Funções e administradores do Microsoft Entra nos resultados na seção Serviços.

Ou, para ir diretamente para a página de funções e administradores do Microsoft Entra, use https://portal.azure.com/#view/Microsoft_AAD_IAM/AllRolesBlade.
Na página Funções e administradores que é aberta, localize e selecione uma das funções suportadas por clicando no nome da função (não na caixa de seleção) nos resultados.
- PowerShell do Exchange Online: Por exemplo, localize e selecione a função de administrador do Exchange.
- PowerShell de Segurança & Conformidade: por exemplo, localize e selecione a função Administrador de Conformidade .
Na página Tarefas que é aberta, selecione Adicionar atribuições.
- PowerShell do Exchange Online:
- Segurança e Conformidade do PowerShell:
No menu desdobrável Adicionar atribuições que é aberto, encontre e selecione o aplicativo que você criou na Etapa 1.

Quando tiver terminado, no submenu Adicionar atribuições , selecione Adicionar.
De volta à página Atribuições , verifique se a função está atribuída ao aplicativo.
- PowerShell do Exchange Online:
- Segurança e Conformidade do PowerShell:

Opção 2: atribuir grupos de funções personalizados ao aplicativo usando entidades de serviço

Observação

Você precisa se conectar ao Exchange Online PowerShell ou ao PowerShell de Conformidade & de Segurança antes de concluir as etapas para criar uma nova entidade de serviço. A criação de uma nova entidade de serviço sem se conectar ao PowerShell não funciona (a ID do Azure App e a ID do Objeto são necessárias para criar a nova entidade de serviço).

Para obter informações sobre como criar grupos de função personalizados, consulte Criar grupos de função no Exchange Online e Criar Email & grupos de função de colaboração no portal Microsoft Defender. O grupo de funções personalizado que você atribui ao aplicativo pode conter qualquer combinação de funções internas e personalizadas.

Para atribuir grupos de funções personalizados ao aplicativo usando entidades de serviço, execute as seguintes etapas:

No Microsoft Graph PowerShell, execute os seguintes comandos para armazenar os detalhes do aplicativo do Microsoft Entra que você registrou na Etapa 1 em uma variável:

Connect-MgGraph -Scopes AppRoleAssignment.ReadWrite.All,Application.Read.All

$<VariableName1> = Get-MgServicePrincipal -Filter "DisplayName eq '<AppName>'"

Por exemplo:

Connect-MgGraph -Scopes AppRoleAssignment.ReadWrite.All,Application.Read.All

$AzureADApp = Get-MgServicePrincipal -Filter "DisplayName eq 'ExO PowerShell CBA'"

Para obter informações detalhadas de sintaxe e parâmetro, consulte Get-MgServicePrincipal.

Na mesma janela do PowerShell, conecte-se ao Exchange Online PowerShell ou ao PowerShell de Segurança & Conformidade e execute os seguintes comandos para:
- Crie um objeto de entidade de serviço para o aplicativo Microsoft Entra.
- Armazene os detalhes da entidade de serviço em uma variável a ser usada na próxima etapa.
```
New-ServicePrincipal -AppId $<VariableName1>.AppId -ObjectId $<VariableName1>.Id -DisplayName "<Descriptive Name>"

$<VariableName2> = Get-ServicePrincipal -Identity "<Descriptive Name>"
```
Por exemplo:
```
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"
```
Para obter informações detalhadas sobre sintaxe e parâmetro, consulte New-ServicePrincipal.
No PowerShell ou no PowerShell Exchange Online Conformidade de Segurança &, execute o seguinte comando para adicionar a entidade de serviço como membro do grupo de função personalizado:
```
Add-RoleGroupMember -Identity "<CustomRoleGroupName>" -Member <$<VariableName2>.Identity | $<VariableName2>.ObjectId | $<VariableName2>.Id>
```
Por exemplo:
```
Add-RoleGroupMember -Identity "Contoso View-Only Recipients" -Member $SP.Identity
```
Para obter informações detalhadas sobre sintaxe e parâmetro, consulte Add-RoleGroupMember.

Comentários

Esta página foi útil?

Last updated on 2026-08-25

Autenticação somente do aplicativo para scripts autônomos no Exchange Online PowerShell e PowerShell de Conformidade & Segurança

Como funciona?

Exemplos de conexão

Configurar autenticação somente no aplicativo

Etapa 1: registrar o aplicativo no Microsoft Entra ID

Etapa 2: atribuir permissões de API para o aplicativo

Selecione e atribua as permissões de API do portal

Modifique o manifesto do aplicativo para atribuir permissões de API

Etapa 3: Gerar um certificado

Etapa 4: anexar o certificado ao aplicativo Microsoft Entra

Etapa 4b: somente cenários delegados do Exchange Online: Conceder consentimento de administrador para o aplicativo multilocatário

Etapa 5: atribuir permissões de função ao aplicativo

Opção 1: atribuir funções do Microsoft Entra ao aplicativo

Opção 2: atribuir grupos de funções personalizados ao aplicativo usando entidades de serviço

Comentários

Recursos adicionais