We're receiving more and more questions from SURF institutions, and how they can use SURFconext federated authentication (and related technology like SURFsecureID) with Azure AD services, like Office 365. This is one of the reasons, why we've set up several reference environments, to be able to help these institutions troubleshoot their problems, but also to give them access to these environments.
On this page you can read about what works when using Office365 and SURFconext. You'll also read about what works with Office365 and SURF Strong Authentication.
The reference environments are based on:
We've installed several applications on these clients, to be able to test the different scenario's. These applications and the (im)possibilities with the different environments and configurations, are described further down.
We've setup these environments to be close to situations one expects to find with Dutch institutions. The clients and 'on premise' parts are hosted in the cloud, mirroring on premise installs, and thereby easily remotely accessible.
Using our documentation and scripts, you can create similar setups for your own environment.
To request access to one of the environments or in case you need help with your configuration, please contact us via email: support@surfnet.nl .
We've set up 3 types of configurations in 2 separate environments on Microsoft Azure. After describing the configuration, we document what does, and what doesn't work with that configuration.
In this setup, we use SURFconext to connect our on-premise environment with our Office 365 domain, just like so many webservices institutions use via SURFconext. No reconfiguration of the IdP is required: we use our normal SURFconext connection.
| Base set-up (shared with setup 2):
Configuration of domain 1, as pictured to the left:
In case you would like to build and configure this setup yourself, please check these pages: |
|---|
Everything you do with(in) your browsers, like webmail or using SharePoint Online via your browser, is no problem.
'Rich clients', like email apps, might not work or need a work-around when they do not support federated authentication:
Basically, you need to know with what clients your users want to access the Office365 environment, and test whether those clients pose problems.
In this setup, we connect an on-premise environment to the Microsoft cloud via ADFS and without SURFconext. For this, we need to set up an Identity Provider (IdP), typically using Active Directory Federation Services (ADFS). For other systems than ADFS, support by Microsoft may be limited. As of summer 2012, Shibboleth 2 is officially supported by Microsoft using the SAML 2.0 protocol, but not all protocol/client combinations are fully supported. We've tested a few popular applications, the test-results are displayed below. You need to know with what clients your users want to access the environment, and test your preferred scenario with all those clients.
We recommend configuring your Office 365 tenant for Modern Authentication. If you choose to allow Basic Authentication, some clients will route a user's password through Microsoft servers, so the webservices can validate those passwords using a back channel connection with the IdP. Although Microsoft doesn't need to store those passwords, from a security perspective, this is 'not ideal'. You need to trust every part in the communication path (especially the client, and Microsoft and possibly others like governmental intelligence agencies) not to misuse your users institution passwords, passwords providing access to so many systems.
| Base set-up (shared with setup 1):
Configuration of domain 2, as pictured to the left:
In case you would like to build and configure this setup yourself, please check these pages: |
|---|
Everything you do with(in) your browsers, like webmail or using SharePoint Online via your browser, is no problem.
'Rich clients', like email apps, might not work or need a work-around when they do not support federated authentication. Many Microsoft clients are able to work with federated authentication. Some (email) clients won't work with AD FS directly, but will work with IMAP or POP settings. With this scenario, you won't need MFA and application passwords, but you will need modern authentication. We've documented how you can enable modern authentication.
This is the easiest option from a configuration point of view. Passwords are hosted at Microsoft's servers. When you connect your on-premise directory to Office365, there is no need to set up an Identity Provider. Passwords can be set during account provisioning. As ever when a user-account-and-password is created 'off-premise', we advise you to use passwords that are different from the passwords hosted by your organisation's directory, so that in case of a leak/breach, services accessed via the password used in your organisation's directory are not affected. It is advisable to prevent your users from setting passwords themselves, as many will probably choose their "home" password.
| Set up:
In case you would like to build and configure this setup yourself, please check these pages: |
|---|
This setup is the least complex one of the three. We've experienced no problems with any of the tested applications and no extra settings were required.
We have also tested Office365 with SURFsecureID. The results can be found in this report.
