Page tree
Skip to end of metadata
Go to start of metadata

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:

  • Windows Server 2016
    • ADDS role (and AD FS role)
    • AAD Connect (AAD Sync)
    • SURFconext connection (only 1 environment)
    • Windows 10 Client
    • Mac Client (OS X 10.12 Sierra)

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 . 

Set-ups

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.

Setup 1 Office 365 with AD FS and SURFconext

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):

  • "Harting College" Office 365 Tenant, with 2 domains
  • Windows Server 2016 with ADDS and ADFS Roles
  • AAD Connect sync (for user provisioning)

Configuration of domain 1, as pictured to the left:

  • Authentication via AD FS and SURFconext

In case you would like to build and configure this setup yourself, please check these pages:

What does and doesn't work in setup 1, Office 365 with AD FS and SURFconext 

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. For Outlook to work in this configuration, you need to enable 'modern authentication' for your Exchange Online. You can find more information about modern authentication on this page.
  • Email clients like Thunderbird or Apple mail will need some extra configuration and will only work with Microsoft Multi Factor Authentication (MFA) enabled. MFA needs to be enabled to use application-specific passwords. These application-specific passwords were added to AAD in order to support clients that are unable to communicate a user's MFA credentials. Application-specific passwords can also be used in the federated scenario, where similar issues exist with client software that doesn't support a federated login flow. MFA can be enabled per user or per group. With MFA enabled, you can create application-specific passwords, that you can use to login with on (email) clients like Thunderbird or Apple Mail. 

Basically, you need to know with what clients your users want to access the Office365 environment, and test whether those clients pose problems.

OS/client-combinations we have tested for this setup (note: don't forget to test mobile clients!):

Notes:


Setup 2 Office 365 with AD FS

Configuration

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):

  • "Harting College" Office 365 Tenant, with 2 domains
  • Windows Server 2016 with ADDS and ADFS Roles
  • AAD Connect sync (for user provisioning)

Configuration of domain 2, as pictured to the left:

  • Authentication via AD FS (no SURFconext)

In case you would like to build and configure this setup yourself, please check these pages:

What does and doesn't work in setup 2, Office 365 with AD FS

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.

OS/client-combinations we have tested for this setup (note: don't forget to test mobile clients!):

Notes:

  • Thunderbird will only work with IMAP or POP settings. You can use the 'normal' username and password. Use outlook.office365.com for incoming server and smtp.office365.com for outgoing server.
    • Username and password will be sent over a SSL connection
    • This setup needs some more configuration for Thunderbird
    • You don't have the Exchange functionalities in Thunderbird, since this is an IMAP or POP configuration
  • At the moment of writing, Edge  is supported, but with limitations 

Setup 3 Office 365 with password sync

Configuration

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:

  • "Effen College" Office 365 Tenant with 1 domain
  • Windows Server 2016 with ADDS Role
  • AAD Connect sync (password sync)

In case you would like to build and configure this setup yourself, please check these pages:

What does and doesn't work in setup 3, Office 365 with password sync

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.

OS/client-combinations we have tested for this setup (note: don't forget to test mobile clients!):

Notes:

Office365 and SURFsecureID

We have also tested Office365 with SURFsecureID. The results can be found in this report.


  • No labels