Office 365 SSO Security Guidance: Single sign-on and remote access

Office 365 SSO: The secure configuration of this cloud-hosted service aligns with government’s guidance on implementing the Cloud Security Principles. You can find out more regarding implementation of Federation in order to Restrict Access to Office 365.

1. What is Office 365 SSO (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 Office 365 SSO, which allows a user to log in to O365 using their existing enterprise username and password. Office 365 SSO login may happen automatically, although this depends on how the enterprise and its devices are configured.

2. Microsoft Office 365 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. Office 365 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. Office 365 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 toO365, 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.

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. This can be achieved either through Mobile Device Management, Intune or through Group Policy with ADFS. Additional policy and security control can be achieved through private VLANs, removing the complexity of managing outbound requests via the Internet from trusted locations, such as fixed office sites or data centre locations.

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. TheIdP 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:

• SSO Roadmap
• Troubleshooting SSO

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.

If you have any questions or need a little more in-depth help please get in touch.

Source: https://www.ncsc.gov.uk/guidance/microsoft-office-365-security-guidance-single-sign-and-remote-access