With GDPR just around the corner, protecting a company against data loss is finally getting more serious. Office 365 is a great help in this, but only if it is configured correctly. Office 365 and an Azure subscription both come with Azure Active Directory preinstalled (??? 🤨). However, the default configuration is, ehm, interesting to say the least. Let me highlight what I think is the most often overlooked, yet most important switch you should flip immediately.
Users can consent to apps accessing company data on their behalf
🤨 Sooo what does this mean? I'll rephrase it:
All users can allow external, untrusted apps to access your company data on their behalf without your advance approval
😱 Wow, wait what? Hold on there, it can't be that bad, can it? Users can't possibly allow untrusted apps to access files on SharePoint Online or read the GAL? It appears there are numerous permissions an app can be delegated without administrator approval, amongst others:
Allright, enough with all the scaring! Quick note that eases the pain a little: each permission is of course limited to the elements the consenting user already has access to.
Even Microsoft notes this 'concerning'. Oh, no, hold on. Actually, it is phrased as follows: might initially sound concerning. How belittling!
To further understand what this all means, we should first talk a bit about how Azure Active Directory handles authorization, scopes, permissions, applications and service principles.
The great thing about Azure Active Directory is that is allows easy and secure integration between different apps. The most notable being the Office 365 apps: SharePoint Online, Exchange Online, Flow, etcetera. All these apps leverage AAD for authentication and authoration. Moreover, third party apps, such as SalesForce and your LOB-app can use too 🙌. Not much different from on-premises Active Directory right? Except, maybe, that is is connected to the INTERNET 😈.
Connecting apps to AAD basically works the same as on-premises: the app needs an (service) account to connect to the directory so users can log on. SharePoint on-premises for example needs about 15 service accounts to allow for secure document storage. Yeah, silly SharePoint...
In the cloud, each app uses at least one service or application principal to connect to Azure AD. SharePoint Online uses this principal: `57fb890c-0dab-4253-a5e0-7188c88b2bb4. These are registered automatically for Office 365. Others need to be added.
The service principals can be given fine-granulated permissions (scopes): read user profile, write e-mail, let the user sign in, and many many more. Most apps won't require much, but 'sign in and read user profile' is the bare minimum I suppose. All access is based on APIs which are all accessible through the app model: Windows Azure Active Directory API, Exchange Online API, Microsoft Graph, and a few more. The required permissions can be applicative or delegated, and may require admin preapproval. Consider the following three examples:
| Scenario | Scope | Permission type | Requires admin preapproval? |
|---|---|---|---|
| 3rd party web application that users sign in to and allows them to save files to his/her OneDrive | Sign in, write OneDrive | Delegated | No |
| 3rd party phone app where users can sign in and view all directory groups | Sign in, read all groups | Delegated | Yes |
| Azure Automation Job that analyzes audit log data | Read all audit log data | Application | Yes |
Simply put, interactive apps where users sign into require delegated permissions but may not require administrator approval. Whether or not an admin should preapprove access, depends on the required permission. Noninteractive (background) workloads always require that an administrator has granted access on behorehand. Just to be sure, in order to sign in, an account is needed. The app should have a service principal account. But who can add service principal accounts?
We have identified that some data in Azure Active Directory and Office 365 does not require preapproval by an administrator. All users and apps accessing Azure AD should have an account, respectively a user account or a service principal account.
By default, all users can add applications to the directory, as only long as the required scope does not include permissions that require admin pre-approval.
So when a user browses to a new, third party website that would like to read the user's mailbox, the user can allow that website to do so. Without approval. Without any guarantee it is an application that should be trusted. This will result in an application registration and/or service principal being created in Azure AD for that application.
If an application would like to access data that does require administrator approval, then the administrator should allow that first before any user can use that particular application.
Call me traditional, sceptic or suspicious, but I don't want any user to allow untrusted apps to access my directory. So I disable it. And so should you flip that switch. Users have difficulties distinguishing rogue applications from trusted applications. They shouldn't bear that burden.
I would have shown some awesome PowerShell here, but I can only show you some oldschool code because the new Azure AD module doesn't allow one to change it setting.
Set-MsolCompanySettings -UsersPermissionToUserConsentToAppEnabled $false
