Risk is part of doing business and you can’t eliminate the risk completely. Our job is the minimize the risk and bring it to a level that is acceptable by the business. Also, we look at the potential impact attributed from the risk. Even though I am referring to technology and cyber risk but when a bad news come to fore your reputation is at risk and you no longer immune from financial risk.
If you are an Azure or O365 administrator and you are responsible to providing consent to Application Permission, you need to think about the potential risk and impact to the enterprise attributed from those permissions. Impact is much higher for Application Permission than that of Delegated Permission. The latter will limit the scope to individual user’s account being delegated. Delegated permission still can be risky when the user has elevated privileges (RBAC or Directory role) like Contributor, Owner, Global Administrator, etc. Application permission does not require user context and a client application simply need client id (application id) and client secret to generate an access token from Azure AD. Then, this access token can be used to make graph api calls from anywhere.
Let’s think some specific use cases (hypothetical), we have an application called “Smart AI”, Smart AI requires Read and Write access to all mailboxes in O365 and Smart AI has to run unattended (non-interactive). Smart AI application developed by a startup company, Smart.io, where segregation of duties can’t be effectively maintained. Your organization is a multi-billion dollar company and you like the Smart AI and what it can do to make your marketing folks very productive. So, you consented the permissions to Smart AI. Your company is planning a merger or acquisition and you happened to share (inadvertently) the news to a developer at Smart.io.
Okay, our agile story is written and the context is set! The developer at Smart.io went home with application id (client id) and client secret written on a notepad. Developer called Azure AD token endpoint and got an access token. He (sorry, I am being biased here since most of the hackers are male!), retrieved emails of every employee in the company and he found the private conversation of merger and acquisition in CFO’s mailbox. Remember, the story is hypothetical but it could be real. You have given way too much permissions to Smart.io and, by design, they can misuse the authority. Risk and impact both are very high in this use case, and an admin must think twice before granting/consenting such application permissions.
There are use cases when we have to grant application permissions to mailboxes. However, to minimize the risk and impact, you can scope application permissions to specific mailboxes. You can follow the instructions at the link but we are going to cover basics of implementation and testing here.
We will show how to create an Application Access Policy using Exchange Online Powershell and restrict Azure AD application access to selected mailboxes.
Create a mail-enabled security group, you can do this at Exchange Admin Center or via script. I didn’t see this option at Azure AD. Assign members to the group you just created. It takes few seconds for this group to show up in Azure AD portal but it’s immediately available at exchange side.
Get the application id (client id) that you would like to restrict access. Run the Powershell script and wait for 30 minutes for policy can be synced with Azure Graph API. Don’t forget to replace the values with relevant values from your Azure tenant!
#Install ExchangeOnlineManagement module if you have not done so already Install- -Name ExchangeOnlineManagement #Import ExchangeOnlineManagement module Import-Module ExchangeOnlineManagement #Connect to ExchangeOnline using an admin (global admin) account Connect-ExchangeOnline -UserPrincipalName LionKing@aspnet4you2.onmicrosoft.com -ShowProgress $true #Create an application access policy to restrict the app to members of mail-enabled security group New-ApplicationAccessPolicy -AppId ab88a160-ea34-43dc-aee9-b627fa187274 -PolicyScopeGroupId O365PolicyTestGroup@aspnet4you2.onmicrosoft.com -AccessRight RestrictAccess -Description "Restrict this app to members of distribution group O365PolicyTestGroup." #Test the policy for members and non-members Test-ApplicationAccessPolicy -Identity Paul.Smith@aspnet4you2.onmicrosoft.com -AppId ab88a160-ea34-43dc-aee9-b627fa187274 Test-ApplicationAccessPolicy -Identity AdeleV@aspnet4you2.onmicrosoft.com -AppId ab88a160-ea34-43dc-aee9-b627fa187274 Test-ApplicationAccessPolicy -Identity JoniS@aspnet4you2.onmicrosoft.com -AppId ab88a160-ea34-43dc-aee9-b627fa187274 Test-ApplicationAccessPolicy -Identity PradeepG@aspnet4you2.onmicrosoft.com -AppId ab88a160-ea34-43dc-aee9-b627fa187274
Take a coffee or tea break! We have to wait for about 30 minutes because that’s how much time it may take to sync the policy with the Azure Graph API. As an admin, you can create a new secret at the Azure AD application and use the secret along with client id to get access token which is needed to test. We will run 4 tests in Postman- application can’t read mailboxes of JoniS and PradeepG because they are not member of mail-enabled security group, application can read mailboxes of AdeleV and Paul.Smith because they are member of mail-enabled security group.
Conclusion: Even though you have given the Azure AD app read/write permissions to all mailboxes, you can restrict the permission at O365 exchange side with a policy applied to the app id. Application Access Policy will reduce the risk and impact to a level that can be accepted by your business unit.