PhishAlarm Add-in

If you are using PhishAlarm for Exchange or Proofpoint for Outlook, an Office 365 admin from within your company must accept new permissions within Office 365 prior to Microsoft shutting off access to legacy Exchange tokens.  Microsoft's transition process will start October 2024, which will allow admins to opt into using NAA. Access to legacy tokens will be turned off by default starting in January 2025.  A detailed timeline of the transition can be found here.  Users without updated permissions will not be able to report emails until the new permissions are accepted.  

This is required for the following install version:

• PhishAlarm for Exchange

Email Encryption Add-in

If you are using any version of the Proofpoint for Outlook add-in, a Microsoft 365 admin from within your company must accept new permissions within Microsoft 365 prior to when Microsoft will shut off access to legacy Exchange tokens. Microsoft's transition process starts October 2024: a detailed timeline of the transition can be found here. Users without updated permissions will not be able to use the following  features of the add-in until the new permissions are accepted:

This is required for the following install version:

• Proofpoint Standard Encryption Add-In - Send Secure

How do I update my permissions?

Administrators will need to accept a new series of permissions within Outlook that will allow PhishAlarm for Exchange to access this new authentication path.

To accept new permissions, use the following steps:

1. Open your Security Awareness platform and in the left column open PhishAlarm > Add-in Setup > Install
2. Scroll to Nested App Authentication for Office Add-ins and select Connect.
3. Authenticate to the resulting Microsoft 365 page using your Global Administrator account, select Accept.

What impact will this have on my end users?

If permissions are updated by an admin prior to your required transition to NAA, PhishAlarm will continue to work as expected and there will be no change for the end user.  If permissions are not accepted, users will see an error message requesting that they reach out to their administrator when attempting to report an email. No action is required by the end user.

What permissions are needed?

The following delegated permissions are needed for PhishAlarm for Exchange to continue to work properly.

• Mail.Read – Read user mail – This allows us to retrieve the email for analysis.
• Mail.Read.Shared -  Read user and shared mail - This allows us to retrieve the email for analysis when reported from a shared mailbox.
• Mail.ReadBasic - Read user basic mail - This allows us to retrieve the email for analysis but omits the body, previewBody, attachments, and any extended properties. This is superseded by Mail.Read.
• Mail.ReadBasic.Shared - Read user and shared basic mail - This allows us to retrieve the email for analysis when reported from a shared mailbox but omits info in the body, bodyPreview, uniqueBody, attachments, extensions, and any extended properties. This is superseded by Mal.Read.Shared.
• Mail.Readwrite – Read and write access to user mail – This allows PhishAlarm to Move/Delete the items after the report is complete.
• Mail.ReadWrite.Shared  - Read and write user and shared mail - This allows PhishAlarm to Move/Delete the items after the report from a shared mailbox is complete.
• Mail.send – Send mail as a user – This allows PhishAlarm to forward the mail as the user to an IT mailbox before analysis completes (Potential Phish Forwarding).
• Mail.Send.Shared – Send mail on behalf of others - This allows PhishAlarm to forward the reported mail from a shared mailbox as the user to an IT mailbox before analysis completes (Potential Phish Forwarding).
• User.Read – Sign in and read user profile – This allows us to review and log the user information reporting the mail. 
   

When the PhishAlarm plugin authenticates on behalf of the user, where will the OAuth token with permissions for the user's mailboxes be located/stored? Will Proofpoint's servers ever see, process, or store this OAuth token?

NAA does not use OAuth tokens. Instead, authentication is directly via the NAA Application. Microsoft describes their Single Sign-On access token using nested app authentication, https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/authentication.

When will the NAA start being used?

PhishAlarm is operational regardless of NAA's accessibility. The updated permissions can be accepted at any time. We will continue to use the current legacy token model until NAA becomes available. Once Microsoft transitions NAA from preview status to General Availability (GA), we will default to using that new method and fall back to legacy token. Proofpoint has requested a specific launch date from Microsoft.

How do I update my permissions?

Admins can accept the required permissions by:

1. Logging into their admin account in M365
2. Navigating to https://login.microsoftonline.com/organizations/adminconsent?client_id=215c2929-b469-432f-aa45-2e018f456e51.
3. Clicking on the button to click to grant the permissions across their organization from the screen listing the required permissions.

Note that accepting permissions will not automatically enable Nested App Authentication for the Proofpoint for Outlook add-in users. It will, however, ensure Proofpoint for Outlook continues to function properly once NAA is live. This will be enabled by Proofpoint on all accounts in October 2024, in accordance with Microsoft's transition.

If an Admin has not granted permissions in advance for the entire organization, users of the add-in will be prompted to accept the permissions on an individual basis when they attempt to use the add-in for the first time after the switch to Nested App Authentication. Users may not understand why they are suddenly being prompted for these permissions, so it is recommended that admins grant the appropriate permissions for their organization in advance.

What permissions are needed?

The following delegated permissions are needed for Proofpoint for Outlook to continue to work properly:

• Mail.ReadWrite — Enables read and write access to user email. Required for accessing email information and writing changes to email for Secure Send.
• Mail.Send — Enables ability to send email as a user. Required for Secure Send.
• offline_access  — Maintains access to data you have given the add-in access to. This is required for a refresh token to be acquired so the add-in can renew its access token on expiry.
• openid — Allows users to sign in their accounts and allows the app to see basic user profile information.
• profile — Allows the add-in to see users' basic profile (e.g., name, username, email address).
• User.Read  — Allows the add-in to sign in and read user profiles. This allows the add-in to review and log the user information while reporting the mail.