Jan 16, 2017

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

Jan 5, 2017

Three things you should know about SAML

When you are planning to configure single sign on some applications with Azure AD, first of all you have to ask application team whether the target application can "speak" federation protocol such as SAML or OpenID Connect. Of course also ws-federation is good protocol as you know:)

Today, I explain you top three things you should know at least when you choose SAML protocol to federate some applications with Azure AD.

1. Entity id and endpoints

To enable SSO, both of the identity provider(IdP) like Azure AD and the service provider(SP. i.e. application) like Google Apps are required to know each other. "Entity id" is the identifier to specify each entities(IdP and SP) and IdP have to know SP's entity id to specify SSO target application, and SP have to know IdP's entity id to specify where user was authenticated.

It is often misunderstood but entity id is not required to be uri format so that it is not required to be reached on the internet. For example, G Suite(a.k.a. Google Apps)'s entity id is "google.com/a/domainname", not "https://google.com/a/domainame".

Also IdP and SP have to know endpoint addresses to contact to the other party. There are several endpoints to be used while finishing SSO process and at least you should to know following two endpoints.

partyendpoint typedescriptionsample value
IdPSingleSignOnServiceendpoint to send authentication request from SPhttps://login.windows.net/{tenant id}/saml2
SPAssertionConsumerServiceendpoint to send authentication result(SAML assertion) from IdPhttps://www.google.com/a/{domain name}/acs


figure 1. SSO setting on Azure AD(IdP)

figure 2. SSO setting on G Suite(SP) * In case of G Suite, IdP's entity id is not required.


2. Certificate for token signing

To finishing SSO process, user-agent(i.e. Web browser) have to POST identity information(SAML Assertion) including authentication result to SP's assertion consumer service endpoint. To avoid identity spoofing, SP verifies SAML Assertion which is received from IdP. To verify the assertion SP uses public key certificate which is paired with private key which IdP uses to sign the SAML Assertion.

Usually during configuring SSO on IdP side, you can create and download token(i.e. SAML Assertion) signing certificate and upload the certificate to SP.

figure 3. Create and download signing certificate from Azure AD(IdP).

figure 4. Upload token signing certificate to G Suite(SP).


3. name id and attributes

"Identity federation" means "To link users between IdP and SP", so to complete SSO process, it is required to determine how to link users both parties. Usually name id element's value in SAML Assertion is used to link users. For example, G Suite requires name id value in SAML Assertion matches email address value of the user to be signed in.

In case of identifier in IdP does not match with SP's identifier, you have to put SP's identifier value to some attribute of the user in IdP. For example, identifier of G Suite is user@example.com and identifier(userPrincipalName) of Azure AD is user@example.net, administrator have to put the value "user@example.com" on mail attribute of user@example.net on Azure AD.

figure 5. Attribute mapping for name id.


Conclusion

SAML is very popular protocol to enable SSO especially for enterprise applications. But there are some tricks to configure successfully and doing trouble shooting. In fact, some one said that 99% of failure while configuring SAML SSO are caused by typo of entity id or endpoints, e.g. a lack of last '/' of entity id causes connection problem. So it is important to know basic structures and components of SAML protocol to configure SSO successfully.

Cheers,
Naohiro


Jan 2, 2017

Starting new blog in English!!

I have been blogging about Identity and Access Management solutions like Microsoft Identity Manager(a.k.a. MIM) and Azure Active Directory(Azure AD) in Japanese for 9 years.

From this new year, I decided to start writing posts in English as well, because I believe that Identity and Access Management is one of the most difficult topics for not only Japanese developers/administrators but for ones works for global companies. This is proven by my experiences in global IAM projects that I've been involved recently. There were no special requirements from other countries, it were almost the same requirements from Japanese local companies have.

You can see my historical posts from following link(in Japanese) and I placed translation widget on left side of the site so you can see my post with machine translation.

IdM Labo(in Japanese)

Cheers,
Naohiro