App Registration

Microsoft and Google remediations require an App registration in Entra ID or Google Developer Console. This page outlines how you can make the registrations and which permissions (scopes) different remediation types require.

Requirements by Remediation Type

Authentication	What you register	Obliterator input
Microsoft Interactive	An app registration in Microsoft Entra ID with delegated permissions	--client-id, and --tenant-id where required
Microsoft AppOnlySecret	An app registration with application permissions, admin consent and a client secret	--client-id, --tenant-id and the client secret
Microsoft AppOnlyCertificate	An app registration with application permissions, admin consent and a certificate	--client-id, --tenant-id, --pfx-path and the PFX password
Google Interactive	A Google Cloud OAuth client of type Desktop app	--client-id and the client secret
Google Dwd	A Google service account with a JSON key, granted domain-wide delegation	--dwd-json
Basic	Nothing	A username and a password or App Password

The other IMAP presets use an OAuth application registered with their own provider, which this page does not cover.

Permissions and Scopes at a Glance

Microsoft Permissions

Provider	Delegated permission (Interactive)	Application permission (App-only Authentication)	Listed under
GraphMail	Mail.ReadWrite	Mail.ReadWrite	Microsoft Graph
OneDrive	Files.ReadWrite.All	Files.ReadWrite.All	Microsoft Graph
SharePoint	Sites.ReadWrite.All	Sites.ReadWrite.All	Microsoft Graph
Ews	EWS.AccessAsUser.All	full_access_as_app	Microsoft Graph (delegated), Office 365 Exchange Online (application)
Imap (m365 and mspersonal presets)	IMAP.AccessAsUser.All	(Not supported)	Microsoft Graph

One registration can be used to target multiple providers when it contains permissions required for all of them. The standard openid, profile and offline_access permissions are requested automatically and do not have to be added.

Google Scopes

Provider	Scope
Gmail	https://mail.google.com/
GoogleDrive	https://www.googleapis.com/auth/drive
Imap (gmail preset)	https://mail.google.com/

Microsoft

Where to Register

Register the application in the custodians’ own tenant wherever you can. This avoids the consent restriction described under Consent in Another Organization’s Tenant, and lets the client delete the application when the matter closes. App-only Authentication always requires a registration in the custodians’ tenant.

For a sovereign cloud (--cloud GccHigh, DoD or China), register the application in that cloud’s own Microsoft Entra admin center. For clarity, an App registered in the Azure Commercial Cloud will not work for a GCC High remediation.

Interactive Authentication

Interactive authentication involves performing modern authentication interactively using the custodian’s credentials. It is generally suitable for personal Microsoft accounts and for a small number of custodians. When targeting a large number of M365 custodians, App-only Authentication is preferable.

1. In the Microsoft Entra admin center, open App registrations and select New registration.

2. Give it a name the custodians will recognize on the consent page.

3. Under Supported account types, choose one of these:

   Choice	Use it for
   Any Entra ID Tenant + Personal Microsoft accounts	Work, school and personal accounts alike.
   Single tenant only	Custodians of the tenant the registration is in. Start every remediation with --tenant-id.

   Do not choose Personal Microsoft accounts only, which Obliterator cannot sign in with.

4. Under Redirect URI, choose Public client/native (mobile & desktop) and enter http://localhost, with no port.

5. Select Register, and copy the Application (client) ID from the Overview page. That is the value you will use for --client-id.

6. Under API permissions, select Add a permission and add the delegated permissions of every provider you will use (see Microsoft Permissions).

An interactive registration needs no client secret.

Note

In an M365 tenant that restricts user consent, an administrator has to grant consent.

App-only Authentication

With App-only Authentication, the application itself accesses the target accounts without using the credentials of a specific custodian. It is suitable for a remediation that spans many mailboxes or Drives in an M365 tenant. An application permission covers every mailbox or Drive in the tenant, so it requires an administrator’s consent.

1. In the custodians’ tenant, open App registrations in the Microsoft Entra admin center and select New registration.
2. Give it a name, choose Single tenant only, and leave Redirect URI empty.
3. Select Register, and copy the Application (client) ID and the Directory (tenant) ID. You will use them for --client-id and --tenant-id.
4. Under API permissions, select Add a permission, choose Application permissions, and add the permission of every provider you will use (see Microsoft Permissions).
5. Select Grant admin consent for the organization. This requires a Global Administrator, Privileged Role Administrator or Cloud Application Administrator.
6. Add a client secret or a certificate under Certificates & secrets, as described below.

Client secret

Select New client secret, give it a description and an expiry, and select Add.

Copy the Value column immediately, because it is shown only once. The Secret ID column is not the secret.

Use --auth-mode AppOnlySecret, and enter the client secret when Obliterator prompts for it.

Certificate

Under Certificates & secrets, open the Certificates tab, select Upload certificate, and upload the certificate you would like to use in .cer, .pem, or .crt format.

When using a certificate, you will need to provide Obliterator with the local PKCS #12 (.pfx) certificate file. This file must contain the private key that matches the public certificate uploaded to Entra ID above.

Use --auth-mode AppOnlyCertificate, pass remediation.pfx with --pfx-path, and enter its password when Obliterator prompts for it.

Tip

Which address of an account TargetEmail must hold depends on the provider. See Target Accounts.

EWS in M365

Caution

Microsoft began disabling EWS by default in Exchange Online tenants on October 1, 2026, and plans to retire it from Exchange Online on April 1, 2027. An Ews remediation against M365 works only while the tenant’s administrator opts in to keep EWS enabled. On-premises Exchange is not affected.

The two EWS permissions are listed in different places:

• EWS.AccessAsUser.All (Interactive Authentication) is listed under Microsoft Graph. In Add a permission, select Microsoft Graph, then Delegated permissions, and find it in the EWS group.
• full_access_as_app is listed under Office 365 Exchange Online. In Add a permission, open the APIs my organization uses tab, search for Office 365 Exchange Online, choose Application permissions, and search for full_access_as_app. Add it using Add permissions.

Tip

If you cannot find full_access_as_app in the Entra ID UI, you can use the manifest editing method as described here.

Consent in Another Organization’s Tenant

Microsoft Entra blocks user consent for multitenant applications without a verified publisher when they are used from another tenant. So, a custodian signing in to an application registered in your own tenant is refused with AADSTS90094, which says an administrator has to grant permission first. Personal Microsoft accounts are not affected.

There are three ways around it:

• Register the application in the custodians’ own tenant.
• Have an administrator of that tenant grant admin consent once, under Enterprise applications.
• Verify your organization as the publisher, which requires a Microsoft AI Cloud Partner Program account.

Sign-in Errors About Account Types

Message	Cause	Fix
You can’t sign in here with a personal account. Use your work or school account instead.	The registration excludes personal accounts.	Set Supported account types to Any Entra ID Tenant + Personal Microsoft accounts.
The request is not valid for the application’s ‘userAudience’ configuration…	The registration admits personal accounts only.	The same setting.
AADSTS50194	A single-tenant registration was used without a tenant.	Add --tenant-id.

Google

OAuth Client for Interactive Authentication

In this scenario, each target account requires authentication using the custodian’s credentials. Interactive modern authentication is suitable for personal Gmail accounts, and for Google Workspace accounts where domain-wide delegation of authority is not feasible.

1. In the Google Cloud console, create a project for the matter, or select an existing one.
2. Under APIs & Services > Library, enable the Gmail API for Gmail and for the IMAP gmail preset, and the Google Drive API for GoogleDrive.
3. Open Google Auth Platform, complete Branding and give the app a name. The name will be displayed on the consent page during authentication.
4. Under Audience, choose the user type External, and leave the publishing status at Testing.
5. Still under Audience, select Add users under Test users, and add every target account in the input CSV. Only test users can consent while the app is in Testing.
6. Under Data Access, add the scopes of every provider you will use (see Google Scopes).
7. Under Clients, select Create client, choose the application type Desktop app, and create it. Copy the Client ID and the Client secret. Pass the client ID with --client-id, and enter the client secret when Obliterator prompts for it.

Consent Lasts Seven Days

While the app is in Testing, each custodian’s consent lasts seven days. A remediation resumed after that asks for reauthentication.

Note

Google shows a notice that the app has not been verified. That is expected for an app in Testing, and the custodian can continue to the consent page.

If a Google Workspace custodian is told that access is blocked by their organization, their administrator can whitelist the client ID under Security > Access and data control > API controls in the Google Admin console.

Domain-wide Delegation

Domain-wide delegation allows one Google service account access every account in a Google Workspace tenant. It does not apply to personal Gmail accounts.

In the Google Cloud Console

1. Create a project for the matter, or select an existing one, and enable the Gmail API and the Google Drive API as needed.
2. Under IAM & Admin > Service accounts, select Create service account and give it a name.
3. Open the service account and copy its Client ID, shown under Advanced settings.
4. On the Keys tab, select Add key > Create new key, choose JSON, and create it. Pass the downloaded key file with --dwd-json.

Note

Google Cloud organizations created since May 2024 block service account key creation by default. If creating the key is refused, you can:

• Create the Google service account in a project outside the custodians’ organization (e.g., in your own firm’s Google Cloud organization), or in a project with no organization.
• Have an organization policy administrator allow key creation for the project.

In the Google Admin Console

This part requires a super administrator role. Typically, it will be performed by the target organization’s administrator.

1. Go to Security > Access and data control > API controls, and select Manage Domain Wide Delegation.
2. Select Add new, and enter the service account’s Client ID.
3. Under OAuth scopes, enter the scopes of every provider you will use, separated by commas, e.g., https://mail.google.com/,https://www.googleapis.com/auth/drive.
4. Select Authorize.

The delegation usually takes effect within minutes, but it can take longer for tenants with many users.

Caution

The JSON key can access every account the delegation covers. Store it securely, or delete it once the remediation has started. Obliterator keeps a copy in the encrypted remediation project so that the project can be resumed.

After the Remediation

Obliterator removes the credentials stored in a project when a remediation completes, and the clear-credentials command removes them on demand. The app registrations themselves remain until you remove them:

• Microsoft: delete the app registration, or at least its client secret or certificate. If the application was consented to in a client’s tenant, the client can remove it under Enterprise applications.
• Google (Interactive): delete the OAuth client. Each custodian can also remove the app’s access from their Google account’s security settings.
• Google (Domain-wide Delegation): remove the client ID from Manage Domain Wide Delegation, and delete the service account’s key, or the service account itself.