Autenticación de solo aplicación para scripts desatendidos en PowerShell de Exchange Online y PowerShell de seguridad & cumplimiento

Artículo
01/10/2024

Los escenarios de auditoría e informes en Microsoft 365 suelen implicar scripts desatendidos en Exchange Online Powershell y Security & Compliance PowerShell. En el pasado, el inicio de sesión desatendido requería almacenar el nombre de usuario y la contraseña en un archivo local o en un almacén secreto al que se accedía en tiempo de ejecución. Pero, como todos sabemos, almacenar las credenciales de usuario localmente no es una buena práctica de seguridad.

La autenticación basada en certificados (CBA) o la autenticación de solo aplicación, como se describe en este artículo, admite escenarios de automatización y scripts desatendidos mediante aplicaciones de Microsoft Entra y certificados autofirmados.

Nota:

¿Sabía que puede conectarse a Exchange Online PowerShell mediante identidades administradas en Azure? Consulte Uso de identidades administradas de Azure para conectarse a PowerShell de Exchange Online.
Las características y procedimientos descritos en este artículo requieren las siguientes versiones del módulo de PowerShell de Exchange Online:
- PowerShell de Exchange Online (Connect-ExchangeOnline): versión 2.0.3 o posterior.
- PowerShell de cumplimiento de & de seguridad (Connect-IPPSSession): versión 3.0.0 o posterior.
Para obtener instrucciones sobre cómo instalar o actualizar el módulo, consulte Instalación y mantenimiento del módulo de PowerShell de Exchange Online. Para obtener instrucciones sobre cómo usar el módulo en Azure Automation, consulte Administración de módulos en Azure Automation.
Las conexiones de API REST en el módulo Exchange Online PowerShell V3 requieren los módulos PowerShellGet y PackageManagement. Para obtener más información, vea PowerShellGet para conexiones basadas en REST en Windows.

Si los procedimientos de este artículo no funcionan para usted, compruebe que no tiene instaladas versiones beta de los módulos PackageManagement o PowerShellGet mediante la ejecución del siguiente comando: Get-InstalledModule PackageManagement -AllVersions; Get-InstalledModule PowerShellGet -AllVersions.
En PowerShell de Exchange Online, no puede usar los procedimientos de este artículo con los siguientes cmdlets de grupo de Microsoft 365:
Puede usar Microsoft Graph para reemplazar la mayor parte de la funcionalidad de esos cmdlets. Para obtener más información, consulte Trabajar con grupos en Microsoft Graph.
En PowerShell de cumplimiento de seguridad &, no puede usar los procedimientos de este artículo con los siguientes cmdlets de grupo de Microsoft 365:
Los escenarios delegados se admiten en Exchange Online. El método recomendado para conectarse con la delegación es usar GDAP y el consentimiento de la aplicación. Para obtener más información, consulte Uso del módulo de PowerShell v3 de Exchange Online con GDAP y consentimiento de la aplicación. También puede usar aplicaciones multiinquilino cuando no se crean relaciones de CSP con el cliente. Los pasos necesarios para usar aplicaciones multiinquilino se indican en las instrucciones habituales de este artículo.
Use el modificador SkipLoadingFormatData en el cmdlet Connect-ExchangeOnline si recibe el siguiente error al usar el SDK de Windows PowerShell para conectarse: 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.

¿Cómo funciona?

El módulo de PowerShell de Exchange Online usa la biblioteca de autenticación de Active Directory para capturar un token de solo aplicación mediante el identificador de aplicación, el identificador de inquilino (organización) y la huella digital del certificado. El objeto de aplicación aprovisionado dentro del identificador de Microsoft Entra tiene un rol de directorio asignado, que se devuelve en el token de acceso. El control de acceso basado en rol (RBAC) de la sesión se configura mediante la información de rol de directorio que está disponible en el token.

Ejemplos de conexión

En los ejemplos siguientes se muestra cómo usar el módulo de PowerShell de Exchange Online con autenticación de solo aplicación:

Importante

En los siguientes comandos de conexión, use el dominio principal .onmicrosoft.com de su organización como valor del parámetro Organization .

Los siguientes comandos de conexión tienen muchas de las mismas opciones disponibles, como se describe en Connect to Exchange Online PowerShell and Connect to Security & Compliance PowerShell (Conectarse a PowerShell de Exchange Online PowerShell y Conectarse a PowerShell de cumplimiento de & seguridad). Por ejemplo:

Los entornos de Microsoft 365 GCC High o Microsoft 365 DoD requieren los siguientes parámetros y valores adicionales:
- Connect-ExchangeOnline en GCC High: -ExchangeEnvironmentName O365USGovGCCHigh.
- Connect-IPPSSession en GCC High: -ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/common.
- Connect-ExchangeOnline en DoD: -ExchangeEnvironmentName O365USGovDoD.
- Connect-IPPSSession en DoD: -ConnectionUri https://l5.ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/common.
Si un comando Connect-IPPSSession presenta un símbolo del sistema de inicio de sesión, ejecute el comando: $Global:IsWindows = $true antes del comando Connect-IPPSSession .

Conexión mediante una huella digital de certificado:

Nota:

El parámetro CertificateThumbprint solo se admite en Microsoft Windows.

El certificado debe instalarse en el equipo donde se ejecuta el comando. El certificado se debe instalar en el almacén de certificados de usuario.

Exchange Online PowerShell:

Connect-ExchangeOnline -CertificateThumbPrint "012THISISADEMOTHUMBPRINT" -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"

Security & Compliance PowerShell:

Connect-IPPSSession -CertificateThumbPrint "012THISISADEMOTHUMBPRINT" -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"

Conexión mediante un objeto de certificado:

No es necesario instalar el certificado en el equipo donde se ejecuta el comando. Puede almacenar el objeto de certificado de forma remota. El certificado se captura cuando se ejecuta el script.

Exchange Online PowerShell:

Connect-ExchangeOnline -Certificate <%X509Certificate2 Object%> -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"

Security & Compliance PowerShell:

Connect-IPPSSession -Certificate <%X509Certificate2 Object%> -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"

Conexión mediante un certificado local:

Nota:

El uso de un comando ConvertTo-SecureString para almacenar la contraseña del certificado de forma local anula el propósito de un método de conexión seguro para escenarios de automatización. El uso de un comando Get-Credential para solicitar la contraseña del certificado de forma segura no es ideal para escenarios de automatización. En otras palabras, realmente no hay ninguna manera automatizada y segura de conectarse mediante un certificado local.
- Exchange Online PowerShell:
```
Connect-ExchangeOnline -CertificateFilePath "C:\Users\navin\Desktop\automation-cert.pfx" -CertificatePassword (Get-Credential).password -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
```
- Security & Compliance 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 la autenticación solo enla aplicación

Se requiere una incorporación inicial para la autenticación con objetos de aplicación. La entidad de servicio y la aplicación se usan de forma intercambiable, pero una aplicación es como un objeto de clase mientras que una entidad de servicio es como una instancia de la clase. Para obtener más información, consulte Objetos de aplicación y entidad de servicio en Microsoft Entra ID.

Para obtener un flujo visual detallado sobre la creación de aplicaciones en Microsoft Entra ID, vea https://aka.ms/azuread-app.

Registre la aplicación en Microsoft Entra ID.
Asignar permisos de API a la aplicación.

Un objeto de aplicación tiene el permiso api delegadaMicrosoft Graph>User.Read de forma predeterminada. Para que el objeto de aplicación acceda a los recursos de Exchange, necesita el permiso api de aplicación Office 365 Exchange Online>Exchange.ManageAsApp.
Generar un certificado autofirmado
- Para la autenticación de solo aplicación en Microsoft Entra ID, normalmente se usa un certificado para solicitar acceso. Cualquier persona que tenga el certificado y su clave privada puede usar la aplicación con los permisos concedidos a la aplicación.
- Cree y configure un certificado X.509 autofirmado, que se usa para autenticar la aplicación con el identificador de Microsoft Entra, al tiempo que solicita el token de acceso de solo aplicación.
- Este procedimiento es similar a la generación de una contraseña para las cuentas de usuario. El certificado también puede estar autofirmado. Consulte esta sección más adelante en este artículo para obtener instrucciones para generar certificados en PowerShell.
  
  Nota:
  
  Criptografía: los certificados de próxima generación (CNG) no se admiten para la autenticación de solo aplicación con Exchange. Los certificados CNG se crean de forma predeterminada en las versiones modernas de Windows. Debe usar un certificado de un proveedor de claves CSP. En esta sección se tratan dos métodos admitidos para crear un certificado CSP.
Adjuntar el certificado a la aplicación Microsoft Entra
Asignación de roles de Microsoft Entra a la aplicación

La aplicación necesita tener asignados los roles RBAC adecuados. Dado que las aplicaciones se aprovisionan en Microsoft Entra ID, puede usar cualquiera de los roles integrados admitidos.

Paso 1: Registro de la aplicación en microsoft entra id.

Nota:

Si tiene problemas, revise los permisos necesarios para comprobar que su cuenta puede crear la identidad.

Abra el Centro de administración de Microsoft Entra en https://portal.azure.com/.
En el cuadro Buscar de la parte superior de la página, empiece a escribir Registros de aplicaciones y, a continuación, seleccione Registros de aplicaciones en los resultados de la sección Servicios .

O bien, para ir directamente a la página Registros de aplicaciones, use https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade.
En la página Registros de aplicaciones, seleccione Nuevo registro.

En la página Registrar una aplicación que aparece, configure las siguientes opciones:
- Nombre: escriba algo descriptivo. Por ejemplo, ExO PowerShell CBA.
- Tipos de cuenta admitidos: compruebe que solo está seleccionada la opción Cuentas de este directorio organizativo (<Solo NombreDeOrganización>: Inquilino único).
  
  Nota:
  
  Para que la aplicación sea multiinquilino para escenarios delegados de Exchange Online , seleccione el valor Accounts in any organizational directory (Any Microsoft Entra directory - Multitenant).
- URI de redireccionamiento (opcional): esta configuración es opcional. Si necesita usarlo, configure los siguientes valores:
  - Plataforma: seleccione Web.
  - URI: escriba el URI donde se envía el token de acceso.
  Nota:
  
  No puede crear credenciales para aplicaciones nativas, ya que no puede usar aplicaciones nativas para aplicaciones automatizadas.
Cuando haya terminado en la página Registros de aplicaciones, seleccione Registrar.
Se le llevará a la página Información general de la aplicación que acaba de registrar. Deje esta página abierta. La necesitará en el siguiente paso.

Paso 2: asignar permisos de API a la aplicación

Elija uno de los métodos siguientes de esta sección para asignar permisos de API a la aplicación:

Seleccione y asigne los permisos de API desde el portal.
Modifique el manifiesto de la aplicación para asignar permisos de API. (Las organizaciones de Microsoft 365 GCC High y DoD deben usar este método)

Selección y asignación de los permisos de API desde el portal

En la página Información general de la aplicación, seleccione Permisos de API en la sección Administrar .
En la página Permisos de API de la aplicación, seleccione Agregar un permiso.
En el control flotante Solicitar permisos de API que se abre, seleccione la pestaña API que usa mi organización , empiece a escribir Office 365 Exchange Online en el cuadro Buscar y, a continuación, selecciónelo en los resultados.
En el control flotante ¿Qué tipo de permisos requiere la aplicación? que aparece, seleccione Permisos de aplicación.
En la lista de permisos que aparece, expanda Exchange, seleccione Exchange.ManageAsApp y, a continuación, seleccione Agregar permisos.
De nuevo en la página permisos de API de la aplicación, compruebe que Office 365 Exchange Online>Exchange.ManageAsApp aparece en la lista y contiene los valores siguientes:
- Tipo: Aplicación.
- Se requiere el consentimiento del administrador: Sí.
- Estado: el valor incorrecto actual no se concede para <la organización>.
  
  Para cambiar este valor, seleccione Conceder consentimiento de administrador para <la organización>, lea el cuadro de diálogo de confirmación que se abre y, a continuación, seleccione Sí.
  
  El valor Status ahora se concede para <Organization>.
Para la entradaUser.Read predeterminada deMicrosoft Graph>, seleccione ...>Revoque el consentimiento del administrador y, a continuación, seleccione Sí en el cuadro de diálogo de confirmación que se abre para devolver Estado al valor en blanco predeterminado.
Cierre la página actual depermisos de la API (no la pestaña del explorador) para volver a la página de registros de la aplicación. Use la página Registros de aplicaciones en un paso próximo.

Modificación del manifiesto de aplicación para asignar permisos de API

Nota:

Los procedimientos de esta sección anexan los permisos predeterminados existentes en la aplicación (permisos user.read delegados en Microsoft Graph) con los permisos de Exchange.ManageAsApp de aplicación necesarios en Office 365 Exchange Online.

En la página Información general de la aplicación, seleccione Manifiesto en la sección Administrar .

En la página Manifiesto de la aplicación, busque la requiredResourceAccess entrada (en o sobre la línea 42) y haga que la entrada tenga un aspecto similar al siguiente fragmento 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"
            }
        ]
    }
],

Nota:

Los entornos de Microsoft 365 GCC High o DoD solo tienen acceso a PowerShell de cumplimiento de seguridad &. Use los siguientes valores para la 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"
            }
        ]
    }
],

Cuando haya terminado en la página Manifiesto , seleccione Guardar.

Aún en la página Manifiesto , seleccione Permisos de API en la sección Administrar .
En la página Permisos de API , compruebe que Office 365 Exchange Online>Exchange.ManageAsApp aparece en la lista y contiene los valores siguientes:
- Tipo: Aplicación.
- Se requiere el consentimiento del administrador: Sí.
- Estado: el valor incorrecto actual no se concede para <La organización> para la entradaExchange.ManageAsApp de Office 365 Exchange Online>.
  
  Cambie el valor de Estado seleccionando Conceder consentimiento de administrador para <Organización>, leyendo el cuadro de diálogo de confirmación que se abre y, a continuación, seleccionando Sí.
  
  El valor Status ahora se concede para <Organization>.
Para la entradaUser.Read predeterminada deMicrosoft Graph>, seleccione ...>Revoque el consentimiento del administrador y, a continuación, seleccione Sí en el cuadro de diálogo de confirmación que se abre para devolver Estado al valor en blanco predeterminado.
Cierre la página actual depermisos de la API (no la pestaña del explorador) para volver a la página de registros de la aplicación. Use la página Registros de aplicaciones en un paso próximo.

Paso 3: Generar un certificado autofirmado

Use uno de los métodos siguientes para crear un certificado x.509 autofirmado:

(Recomendado) Use los cmdlets New-SelfSigned Cmdlet, Export-Certificate y Export-Mbrer en una sesión de Windows PowerShell con privilegios elevados (ejecutar como administrador) para solicitar un certificado autofirmado y exportarlo a .cer y .pfx (SHA1 de forma predeterminada). Por ejemplo:

# Create certificate
$mycert = New-SelfSignedCertificate -DnsName "contoso.org" -CertStoreLocation "cert:\CurrentUser\My" -NotAfter (Get-Date).AddYears(1) -KeySpec KeyExchange

# Export certificate to .pfx file
$mycert | Export-PfxCertificate -FilePath mycert.pfx -Password (Get-Credential).password

# Export certificate to .cer file
$mycert | Export-Certificate -FilePath mycert.cer

Use el script Create-SelfSigned Script para generar certificados SHA1.

.\Create-SelfSignedCertificate.ps1 -CommonName "MyCompanyName" -StartDate 2021-01-06 -EndDate 2022-01-06

Paso 4: Adjuntar el certificado a la aplicación Microsoft Entra

Después de registrar el certificado con la aplicación, puede usar la clave pública (archivo .pfx) o la huella digital para la autenticación.

En la pestaña Aplicaciones propiedad de la página Registro de aplicaciones del final del paso 2, seleccione la aplicación.

Si necesita volver a la página Registro de aplicaciones , use https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/RegisteredApps, compruebe que la pestaña Aplicaciones en propiedad está seleccionada y, a continuación, seleccione la aplicación.
En la página de aplicación que se abre, seleccione Certificados & secretos en la sección Administrar .
En la página Certificados & secretos , seleccione Cargar certificado.

En el cuadro de diálogo que se abre, vaya al certificado autofirmado (.cer archivo) que creó en el Paso 3.

Cuando termine, seleccione Agregar.

El certificado ahora se muestra en la sección Certificados.
Cierre la página Certificados y secretos y, después, la página de Registros de la aplicación para volver a la https://portal.azure.com/página principal. La necesitará en el siguiente paso.

Si creó el multiinquilino de la aplicación para escenarios delegados de Exchange Online en el paso 1, debe conceder el consentimiento del administrador al permiso Exchange.ManageAsApp para que la aplicación pueda ejecutar cmdlets en Exchange Online en cada organización de inquilinos. Para ello, genere una dirección URL de consentimiento del administrador para cada inquilino de cliente. Antes de que alguien use la aplicación multiinquilino para conectarse a Exchange Online en la organización de inquilinos, un administrador del inquilino del cliente debe abrir la siguiente dirección URL:

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

<tenant-id> es el identificador de inquilino del cliente.
<client-id> es el identificador de la aplicación multiinquilino.
El ámbito predeterminado se usa para conceder permisos de aplicación.

Para obtener más información sobre la sintaxis de la dirección URL, consulte Solicitud de los permisos de un administrador de directorios.

Paso 5: Asignación de roles de Microsoft Entra a la aplicación

Tiene dos opciones:

Asignación de roles de Microsoft Entra a la aplicación
Asignar grupos de roles personalizados a la aplicación mediante entidades de servicio: este método solo se admite cuando se conecta a PowerShell de Exchange Online o PowerShell de cumplimiento de seguridad & en modo de API REST. PowerShell de cumplimiento de & de seguridad admite el modo de API REST en la versión 3.2.0 o posterior.

Nota:

También puede combinar ambos métodos para asignar permisos. Por ejemplo, puede usar roles de Microsoft Entra para el rol "Administrador de destinatarios de Exchange" y también asignar el rol RBAC personalizado para ampliar los permisos.

Para las aplicaciones multiinquilino en escenarios delegados de Exchange Online , debe asignar permisos en cada inquilino de cliente.

Asignación de roles de Microsoft Entra a la aplicación

Los roles de Microsoft Entra admitidos se describen en la tabla siguiente:

Role	Exchange Online PowerShell	Seguridad y cumplimiento PowerShell
Administrador de cumplimiento	✔	✔
Administrador de Exchange¹	✔
Administrador de destinatarios de Exchange	✔
Administrador global¹ ²	✔	✔
Lector global	✔	✔
Administrador del departamento de soporte técnico	✔
Administrador de seguridad¹	✔	✔
Lector de seguridad	✔	✔

¹ Los roles Administrador global y Administrador de Exchange proporcionan los permisos necesarios para cualquier tarea de Exchange Online PowerShell. Por ejemplo:

Administración de destinatarios.
Características de seguridad y protección. Por ejemplo, contra correo no deseado, antimalware, antiphishing y los informes asociados.

El rol Administrador de seguridad no tiene los permisos necesarios para esas mismas tareas.

² Microsoft recomienda usar roles con los permisos más mínimos. El uso de cuentas con permisos inferiores ayuda a mejorar la seguridad de su organización. Administrador global es un rol con privilegios elevados que debe limitarse a escenarios de emergencia cuando no se puede usar un rol existente.

Para obtener instrucciones generales sobre cómo asignar roles en Microsoft Entra ID, consulte Asignación de roles de Microsoft Entra a los usuarios.

Nota:

Los pasos siguientes son ligeramente diferentes para Exchange Online PowerShell frente a Security & Compliance PowerShell. Se muestran los pasos para ambos entornos. Para configurar roles para ambos entornos, repita los pasos de esta sección.

En el Centro de administración de Microsoft Entra en https://portal.azure.com/, empiece a escribir roles y administradores en el cuadro Buscar de la parte superior de la página y, a continuación, seleccione Roles y administradores de Microsoft Entra en los resultados de la sección Servicios .

O bien, para ir directamente a la página Roles y administradores de Microsoft Entra , use https://portal.azure.com/#view/Microsoft_AAD_IAM/AllRolesBlade.
En la página Roles y administradores que se abre, busque y seleccione uno de los roles admitidos haga clic en el nombre del rol (no en la casilla) de los resultados.
- PowerShell de Exchange Online: por ejemplo, busque y seleccione el rol de administrador de Exchange .
- PowerShell de cumplimiento de & seguridad: por ejemplo, busque y seleccione el rol Administrador de cumplimiento .
En la página Asignaciones que se abre, seleccione Agregar asignaciones.
- Exchange Online PowerShell:
- Security & Compliance PowerShell:
En el menú flotante Agregar tareas que se abre, busque y seleccione la aplicación que creó en el Paso 1.

Cuando haya terminado en el control flotante Agregar asignaciones , seleccione Agregar.
De nuevo en la página Asignaciones , compruebe que el rol se ha asignado a la aplicación.
- Exchange Online PowerShell:
- Security & Compliance PowerShell:

Asignación de grupos de roles personalizados a la aplicación mediante entidades de servicio

Nota:

Debe conectarse a PowerShell de Exchange Online o PowerShell de cumplimiento de seguridad & antes de completar los pasos para crear una nueva entidad de servicio. La creación de una nueva entidad de servicio sin conectarse a PowerShell no funcionará (el identificador de aplicación de Azure y el identificador de objeto son necesarios para crear la nueva entidad de servicio).

Este método solo se admite cuando se conecta a PowerShell de Exchange Online o PowerShell de cumplimiento de seguridad & en modo de API REST. PowerShell de cumplimiento de & de seguridad admite el modo de API REST en la versión 3.2.0 o posterior.

Para obtener información sobre cómo crear grupos de roles personalizados, consulte Creación de grupos de roles en Exchange Online y Creación de grupos de roles de colaboración & correo electrónico en el portal de Microsoft Defender. El grupo de roles personalizado que asigne a la aplicación puede contener cualquier combinación de roles integrados y personalizados.

Para asignar grupos de roles personalizados a la aplicación mediante entidades de servicio, siga estos pasos:

En Microsoft Graph PowerShell, ejecute los siguientes comandos para almacenar los detalles de la aplicación Microsoft Entra que registró en el paso 1 en una variable:

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

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

Por ejemplo:

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

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

Para obtener información detallada sobre la sintaxis y los parámetros, vea Get-MgServicePrincipal.

En la misma ventana de PowerShell, conéctese a PowerShell de Exchange Online o PowerShell de cumplimiento de seguridad & y ejecute los siguientes comandos para:
- Cree un objeto de entidad de servicio para la aplicación Microsoft Entra.
- Almacene los detalles de la entidad de servicio en una variable que se usará en el paso siguiente.
```
New-ServicePrincipal -AppId $<VariableName1>.AppId -ObjectId $<VariableName1>.Id -DisplayName "<Descriptive Name>"

$<VariableName2> = Get-ServicePrincipal -Identity "<Descriptive Name>"
```
Por ejemplo:
```
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 obtener información detallada sobre la sintaxis y los parámetros, consulte New-ServicePrincipal.
En PowerShell de Exchange Online o PowerShell de cumplimiento de & de seguridad, ejecute el siguiente comando para agregar la entidad de servicio como miembro del grupo de roles personalizado:
```
Add-RoleGroupMember -Identity "<CustomRoleGroupName>" -Member <$<VariableName2>.Identity | $<VariableName2>.ObjectId | $<VariableName2>.Id>
```
Por ejemplo:
```
Add-RoleGroupMember -Identity "Contoso View-Only Recipients" -Member $SP.Identity
```
Para obtener información más detallada acerca de la sintaxis y los parámetros, consulte Add-RoleGroupMember.

Compartir a través de

Autenticación de solo aplicación para scripts desatendidos en PowerShell de Exchange Online y PowerShell de seguridad & cumplimiento

¿Cómo funciona?

Ejemplos de conexión

Configurar la autenticación solo enla aplicación

Paso 1: Registro de la aplicación en microsoft entra id.

Paso 2: asignar permisos de API a la aplicación

Selección y asignación de los permisos de API desde el portal

Modificación del manifiesto de aplicación para asignar permisos de API

Paso 3: Generar un certificado autofirmado

Paso 4: Adjuntar el certificado a la aplicación Microsoft Entra

Paso 5: Asignación de roles de Microsoft Entra a la aplicación

Asignación de roles de Microsoft Entra a la aplicación

Asignación de grupos de roles personalizados a la aplicación mediante entidades de servicio

Comentarios

Recursos adicionales

Compartir a través de

Autenticación de solo aplicación para scripts desatendidos en PowerShell de Exchange Online y PowerShell de seguridad & cumplimiento

¿Cómo funciona?

Ejemplos de conexión

Configurar la autenticación solo enla aplicación

Paso 1: Registro de la aplicación en microsoft entra id.

Paso 2: asignar permisos de API a la aplicación

Selección y asignación de los permisos de API desde el portal

Modificación del manifiesto de aplicación para asignar permisos de API

Paso 3: Generar un certificado autofirmado

Paso 4: Adjuntar el certificado a la aplicación Microsoft Entra

Paso 4b: Solo escenarios delegados de Exchange Online: Conceder consentimiento de administrador para la aplicación multiinquilino

Paso 5: Asignación de roles de Microsoft Entra a la aplicación

Asignación de roles de Microsoft Entra a la aplicación

Asignación de grupos de roles personalizados a la aplicación mediante entidades de servicio

Comentarios

Recursos adicionales