CAF – Security Advisory for Azure AD User Consent Settings

Are your cloud settings inadvertently sharing your data without your consent?

If your organization is among 95-97% of Canadian research and education organizations that use Azure Active Directory (AAD), a simple default setting may be exposing your users’ personal data to third party applications/services in Azure.  

The default configuration setting for User Consent within Azure Active Directory lets all users (including students) connect third party apps to Azure without any administrator involvement. There are a few issues with this:

  1. These default settings may conflict with your Information Security & Privacy Classification policies on a regular basis. 
  2. Additionally, in some cases your users’ and your organizational data are disclosed to third parties, putting your users at risk for data mining purposes. 
  3. Due to these default open settings, users may agree to share their personal data and unknowingly share others’ data (through their level of access) in perpetuity, unaware of how that data is used and under the false assumption that the app is endorsed by you.
     

What’s the best practice?

When deploying any new app or service, apply a “least privilege” approach to user data.
  

The Good News: 

Your Azure AD tenant User Consent setting can easily be changed to be more restrictive. The Canadian Access Federation (CAF) team strongly recommends that new applications need approval by Azure AD administrators before they are granted access to read profile data [1], and that you configure the admin consent workflow to manage this access.[2] 

More specifically, in your User Consent settings, ensure that:

  • ‘Users can register applications’ is set to ‘No’ 
  • ‘Users can consent to apps accessing company data on their behalf’ is set to ‘No’ 
  • ‘Users can consent to apps accessing company data for the groups they own’ is set to ‘No’ 

Recommended reading: 

Making these changes to increase control and security may impact productivity and the existing workflows that users may have come to expect, so you may want to communicate the reasoning for these changes to your user community.

The Not-So-Good News:

Adjusting the User Consent setting to be more restrictive applies only from the point that the setting is changed. It will prevent new applications from being granted access without appropriate review, but apps that have already been permitted will retain access.  

We recommend that you audit all applications that have been enabled on Azure and remove any that are suspicious and not relevant to the learning, research, and business objectives of your organizations.

Recommended reading:  

More Good News: 

If you are using CAF’s Federated Identity Management (FIM) service to grant access to services within the federation, you are in full control of the data that’s shared. You can trust that each service can only access the data that you have authorized. Normally this is limited to the user’s name, email address, and organization. The services themselves are vetted by the federation to legitimately serve the research and education community. Your users will not be able to override your settings. 

For organizations that have joined the Research and Scholarship (R&S) Entity Category within the federation, your risk of unintentionally disclosing user data to commercial services is further minimized. Services that are part of the R&S Entity Category are vetted by the federation to be non-commercial, serve the research and education community, and only require a small and constant subset of low-risk user attributes to enable access. By joining R&S, all R&S-enabled services are automatically provisioned to work for your users.  

Recommended reading:  

Adapted with permission from our good friends at Jisc, the operator of the trust and identity federation in the UK.