Microsoft Office 365 Security Guidance: Single sign-on and remote access
Updated 4 November 2015
© Crown copyright 2015
This publication is licensed under the terms of the Open Government Licence v3.0 except where otherwise stated. To view this licence, visit nationalarchives.gov.uk/doc/open-government-licence/version/3 or write to the Information Policy Team, The National Archives, Kew, London TW9 4DU, or email: psi@nationalarchives.gov.uk.
Where we have identified any third party copyright information you will need to obtain permission from the copyright holders concerned.
This publication is available at https://www.gov.uk/government/publications/microsoft-office-365-security-guidance/microsoft-office-365-security-guidance-single-sign-on-and-remote-access
This document gives deployment security considerations relating to Single Sign-On (SSO) configuration and remote access to the Microsoft Office 365 (O365) web service. The secure configuration of this cloud-hosted service aligns with government’s guidance on implementing the Cloud Security Principles. Please send any feedback you may have to enquiries@cesg.gsi.gov.uk.
1. What is Single Sign-On?
A Microsoft Online user usually signs in using the username and password associated with their Microsoft account. This process can be simplified with O365 by using SSO, which allows a user to log in to O365 using their existing enterprise username and password. SSO login may happen automatically, although this depends on how the enterprise and its devices are configured.
2. Microsoft and SSO
O365 can be integrated with an existing on-premise Active Directory (AD) either by:
- synchronising user credentials to the cloud or
- implementing SSO using identity federation
Both options require account synchronisation between AD and the cloud, effectively copying user account and group data into Windows Azure Active Directory (Azure AD). Directory synchronisation is an ongoing relationship between the on-premise and cloud directories, implemented using the Directory Sync tool or with Azure AD Connect. Filters can be applied so only specified accounts in named organisational units or with certain user object attributes are synced.
O365 supports the implementation of SSO using identity federation which can be enforced once directory synchronisation is correctly established. In this configuration, the user authenticates to the enterprise instead of signing in to the O365 web app. This means there is no requirement to store enterprise passwords in the cloud, while also supporting multi-factor authentication such as a device identity or smartcard.
3. Synchronisation recommendations
CESG recommends implementing full identity federation rather than synchronising passwords into the cloud. Where possible, authentication should be made directly against the enterprise domain, connecting to it over a VPN when working remotely. This ensures there is no requirement to expose an authentication service directly to the Internet; a direct connection carries additional risk to the enterprise domain.
Enterprises implementing a cloud-first deployment may have already chosen to synchronise enterprise accounts and passwords into the cloud. In this case, an enterprise can take advantage of Azure AD services such as self-service password resets, Windows Azure Multi-Factor Authentication and integration options available with third party web apps adopting Microsoft Identity Manager.
Once user accounts have been synchronised to O365, an administrator will need to assign licenses to those users. While this is not automatically done using Directory Sync or Azure AD Connect, it can be scripted with PowerShell.
4. SSO compatibility
Automatic SSO is supported in all O365 services accessed through the O365 portal, as well as Microsoft Office desktop apps installed on domain-joined devices. SSO is also available on the Mobile Office platform for devices that support Workplace Join. Users of devices that are either unsupported or not enrolled in the enterprise will be able to log in to O365 using their enterprise username and password, unless O365 is configured to only allow connections from known and trusted devices.
5. SSO implementation requirements
An SSO implementation for O365 currently requires AD with a compatible Security Token Service (STS), also known as an Identity Provider (IdP). Microsoft currently supports Active Directory Federation Service (ADFS), Shibboleth IdP and other tested third party IdPs as an STS. It may be necessary to alter AD and ADFS configurations to meet the requirements defined by user identities and domain naming.
From a user perspective, SSO works by pointing them at an IdP which they authenticate against using a username and password. The browser then passes a security token to O365, allowing the user to log on to the service.
- For users on a domain-joined or workplace-joined device, this login will be seamless once the device is unlocked.
- For users on other device types, including those not connected to the enterprise network, they will authenticate against an enterprise authentication proxy using their username and password.
6. Web access
Public cloud services such as O365 are designed to be accessed from any device with an Internet connection. Some enterprises prefer to only allow their information to be accessed from authorised devices, whether these are enterprise managed or personal devices that meet a required security specification. These two approaches therefore appear to conflict.
There is no easy way to audit access as there is no administrator accessible log of the devices which users are logging in with. If you wish to restrict access to enterprise data to a subset of devices, one solution is to implement procedural controls for End User Devices (EUDs) which allow users to only log into O365 from certain devices. CESG have produced some guidance on securely configuring EUDs.
7. Restricting access to known devices
There is no specific feature in O365 designed to restrict access to the service by network location or device, through mechanisms such as IP range restrictions or forcing user certificate-based authentication. If ADFS is used as an IdP, it may be configured to require that devices come from known IP addresses. However, it is possible to configure SSO so that only devices that are connected to the enterprise network can authenticate, using any IdP:
With SSO configured as shown above, EUDs can only log in to O365 when they can see the IdP. This ensures that only devices that are connected directly to the enterprise network and those approved to connect using a VPN will be able to log in to O365. Once a user has logged in, the VPN can be dropped since the EUD will maintain the session with a web browser cookie, held until the user logs out. There should be an exception created in the VPN aggregator for managing latency-sensitive applications, such as Lync and Skype, in order to sustain a high level of usability.
SSO can also be configured to work with online IdPs. All approved EUDs should be provisioned with a non-exportable client certificate that identifies the user as a member of the enterprise. This certificate should be hardware-backed on supported devices. The IdP is required to only accept authentication from devices that have this certificate. The logon could also identify the unique user using the certificate, streamlining the logon.
Permissions can be applied to some data held in O365 so that it is only accessible by certain managed devices, or groups of specified devices. This is enabled primarily for devices enrolled in AD or Azure AD, through the Workplace Join or Domain Join mechanisms.
8. Shared devices
O365 sets non-persistent session cookies once a user has successfully logged in, whether or not SSO is being used. If the SSO implementation provides persistent session management, CESG recommend that users should be advised to manually log out of both O365 and their IdP. This will ensure that the cookie is deleted and in doing so separate user sessions on shared devices. It cannot be assumed that O365 will delete the SSO cookie set by the IdP.
9. References
In addition to the web pages referenced in the list of URLs below, Microsoft provides documentation to support SSO deployments including a troubleshooting guide:
See also CESG’s deployment security considerations for Microsoft Office 365: Administrator Good Practice in addition to documentation on End User Devices Security and Configuration Guidance.