Howdy folks, Today I'm happy to announce that our new Tenant Restrictions capability is Generally Available! We built Tenant Restrictions with extensive input from our customer in finance, healthcare and pharmaceutical, industries which have relatively strict information access and compliance requirements. Tenant restrictions gives customers with these kinds of requirements enhanced control over access to SaaS cloud applications. Admins can now restrict employees using their corporate network to only being able to use Azure AD identities in tenants they have approved. To give you the details about this important new capability, I've asked Yossi Banai, a PM in our Identity Security and Protection team to write a blog about this feature. You'll find it below. I those of you in highly regulated industries will find this feature useful! And as always, we would love to receive any feedback or suggestions you have! Best Regards, Alex Simons (Twitter: @Alex_A_Simons ) Director of Program Management Microsoft Identity Division ________ Hello, I'm Yossi Banai, a Program Manager on the Azure Active Directory team. In today's blog post I'll cover Tenant Restrictions – a new feature we released today for general availability.
Overview
Companies that want to move their employees to SaaS apps like Office 365 are sometimes worried about opening their networks to information leaks. If users can access Office 365 with their corporate identity, they can also access these same services with other identities.
Before cloud services, network admins could simply block access to unwanted apps or websites by blocking their URL or IP address. This is no longer an option with SaaS apps, where a single endpoint (like outlook.office.com) is used by all consumers of the SaaS app.
Our solution for this common IT challenge is Tenant Restrictions. This new feature enables organizations to control access based on the Azure AD tenant the applications use for single sign-on. For example, you can use Tenant Restrictions to allow access to your organization's Office 365 applications, while preventing access to other organizations' instances of these same applications.
How it works
An on-premises proxy server is configured to intercept authentication traffic going to Azure AD. The Proxy inserts a new header called "Restrict-Access-To-Tenants" that lists the tenants that users on the network are permitted to access. Azure AD reads the permitted tenant list from the header, and only issues security tokens if the user or resource is in a tenant on that list.
The following diagram illustrates the high-level traffic flow.
End-user Experience
If a user on the Contoso network tries to sign in to the outlook.office.com instance of an unpermitted tenant, he or she will see this message on the web page:
Admin Experience
While configuration of Tenant Restrictions is done on the corporate proxy infrastructure, admins can access the Tenant Restrictions reports in the Azure Portal directly from the Overview page of Azure Active Directory, under 'Other capabilities'. Using the report, the admin for the tenant specified as the "Restricted-Access-Context" can see all sign-ins blocked because of the Tenant Restrictions policy, including the identity used and the target Tenant ID:
Learn more
When you're ready to get started, see Use Tenant Restrictions to manage access to SaaS cloud applications for more information.We appreciate your feedback
As always, we want to hear your feedback about this new feature. If you have any feedback, questions, or issues to report, please leave a comment at the bottom of this post or tweet with the hashtag #AzureAD.
Best regards, Yossi