Unintended access rights are granted by sharing contents on OneDrive for Business

#This entry was originally wrote in Japanese here.
#Updated on 2017/04/04. You can see updated article here.

In some case that an organization willing to share contents on OneDrive for Business or SharePoint online team site, there is a security risk to grant unnecessary access rights to guest users without administrators' awareness.

I'm reporting this problem to Azure AD team of Microsoft Corporation and requesting fix as soon as possible, but so far no changes were made, and it is strongly recommended that administrators check own environment and change some configuration to avoid this issue.

Overview of the problem

Guest users who were invited to Office365 tenant by sharing contents on OneDrive for Business or on SharePoint online team site are able to access following information unintendedly in addition to the contents which were shared,

• Applications which are connected to Azure AD and granted to 'All Users' group through Access Panel.
• Directory configuration on Azure AD through Azure Portal.

And no administrators or users who invite guests aware this because there is no documents describes this so far.

This happens whether the invited user is an organization account or a Microsoft Account.

What happens when invite a guest

They say 'Seeing is believing' in Japan and it is true that to understand what happens by seeing a movie is the fastest way I guess.


Directory "eIdentity" : Inviting party
- using Office365
- "test001@ems.adfs20.net" shares a folder on OneDrive for Business to an external user "test001@gapps21.adfs20.net".
- on this directory, there is an applications which called "ts2016" assigned to "All Users" group.

Directory "InternetWeek" : Guest party
- not using Office365 but using Azure AD
- a user called "test001@gapps21.adfs20.net" is belonging to this directory.

By sharing a folder on OneDrive for Business, the guest user is able to access "ts2016" application and is able to see domain list on eIdentity directory.

Obtain domain lists on eIdentity directory by the guest. (sorry for Japanese screen shot)

Access applications on eIdentity directory by the guest.


No administrators wished to share these information or grant access rights to applications other than contents sharing.

This behavior will be a big problem in some case.

What's happening in background

When a user who was invited accepts the invitation, the invited user is registered as a guest user on Azure AD of inviting party. This behavior is the same as behavior of Azure AD B2B inviting and this happens because Office365 invitation is using this capability internally.

And a guest user is able to
1. sign in on the directory(authentication)
2. access to own profile on the directory
and
3. access to directory configuration(at least domain lists)
4. access to applications which "All Users" assigned. Because the user is automatically added to the "All Users" group.

The root causes are 3 and 4 above, and Microsoft should change default access rights of guest users to not allowed unnecessary resources.

What administrators should do to avoid this problem

To avoid this problem, administrators should do following things at least.
* most of operation requires Azure AD Premium licence.

1. Check existence of guest users on the directory

With Azure Active Directory PowerShell, admins can check existence of guest users on the directory by following command. It is strongly recommended to check regularly.

Get-MsolUser | Where-Object { $_.userType -eq 'Guest' }

2. Create a security group which includes only members(not include guest users) alternative to "All Users"

Create a security group with dynamic membership and set the membership condition to "userType=Member". By using this group, admins can assign or grant rights to only original member on the directory.

Also admin can create a security group which includes only guest users with the same operation (the membership rule should be "userType=Guest").

3. Change application assignment from All Users to All Members group

It is very easy way to assign "All Users" group to applications, but now admins should change assignment to "All Members".

By this change, guest users no longer see applications on the Access Panel(https://myapps.microsoft.com).

(before the change assignment)

(after the change assignment)

4. Authorize users on applications

Security issues are finally solved with not only authentication but authorization on application itself. So it is very important thing to configure authorization properly on applications.

For example, the application "ts2016" on the movie was configured to be accessed with only authentication and guest users very easily access there. Admins should configure applications not to permit access important data on application by guest users.

5. Prohibit guest users to access Azure Portal

Be careful while configure this policy. Wrong configuration may cause very big problem such as no users include admins can access Azure Portal. 

You can prohibit access to Azure Portal by guest users with conditional access policy on Windows Azure Service Management API.

Creating this access policy and enable to prohibit access to Azure Portal.
- Users and groups : All Guests(group includes only guest users)
- Cloud apps : Windows Azure Service Management API (Updated on 2017/04)Microsoft Azure Subscription Management
- Grant : Block access
- Enable policy : On

By enabling this policy, guest users access to Azure Portal is blocked.

Change directory,

the access is blocked.

What's the next

This behavior is not treated as a bug and I guess it takes some while to change the behavior.(I don't sure they fix this or not.) So admins should manage own directory properly by checking guest access and configure applications properly.

If any change have been made by Microsoft, I'll update this entry. Stay tuned!

Cheers,
Naohiro