How to Configure Single-Sign
On with Office 365
Author: Jamie Turbill
Release Date: 13/06/2022
If you use Office 365 heavily, you know it’s a critical application in your organisation. It enables collaboration and communication between your employees, customers, suppliers and more and without it you simply cannot work.
You May Also Like:
Ensuring that your users can access Office 365 is therefore very important, but it’s also important to have a secure way for your users to access Office 365. It’s the front door in your virtual workplace.
What is SSO?
Single Sign-on (SSO) is a term used to describe the process of authenticating once, to multiple, but independent applications. Many technologies exist for the application of SSO, but most commonly open standards are preferred such as SAML 2.0, as these are widely adopted, easily supported and are trusted.
SSO in many cases decreases the time to login and has a positive impact on user experience and security, by eliminating passwords and/or allowing stronger authentication policies to be invoked.
In the context of Okta, SSO is a core feature that provides a key integration between Okta as the identity provider and the application. SSO is available using common standards such as SAML 2.0, WS-Federation and OAuth/OpenID Connect. In addition, SSO can also be achieved using Okta SWA (Secure Web Authentication) which is a proprietary Okta solution to further increase SSO compatibility when open standards are unavailable.
When implementing SSO, the concept of “IDP-initated” and “SP-initiated” describes when and how SSO is available. IDP initiated means that SSO is possible when authentication to an app originating from the identity provider (e.g a chiclet/button in the Okta portal) and SP-initated means it is possible for the app to establish SSO with the identity provider when browsing directly to the application (e.g for office 365, going to portal.office.com and logging in). It is possible for apps to support IDP-initiated or SP-initiated, or both. The majority of apps do support both IDP and SP initiated, as this provides the best integration.
SSO for Office 365
Single Sign On for Office 365 is a great way to improve the security and experience for your users.
Benefits
In Okta, Office 365 is one of the top integrations available in the Okta Integration Network! Many of our customers are asking us about Office 365 and Okta and it’s one of the best supported integrations available, including SSO with WS-Federation and full lifecycle management capabilities being possible in many environments.
When is SSO available in Office 365?
- On the web, from the Okta portal, or directly when logging into Microsoft services such as portal.office.com.
- On the desktop, using Windows/Mac clients such as Office, Word, Excel etc.
- On mobile devices, using official Office 365 applications available in the iOS App Store or Android Google Play store.
So, how do we set up SSO in Office 365 with Okta?
First of all, don’t do this in production first! Test in a preview environment and under a domain that you don’t use in Office 365. Once you federate (enable SSO) a domain with Office 365, you enable SSO for all the users under that domain – so you don’t want to do this until you are ready.
What do you need to know first?
1. Office 365 Tenant Name
This is the name given to your tenant. Typically this will be <tenantname>.onmicrosoft.com and is the default domain that Microsoft will create for you when you first set up Office 365.
2. Office 365 Global Administrator Credentials
To be able to allow Okta to manage the federation of domain/s automatically, ensure you have a suitable global admin service account. This account cannot be in the same domain/s you are federating.
3. The domain/s you wish to federate (set up SSO on)
SSO is set up on a per-domain basis, so ensure that you know what domain/s you need to enable SSO on. Note: you cannot federate the .onmicrosoft.com domain or the default domain.
Following the docs…
Once you have the information you need, you can follow the steps here for configuring SSO. It can take a little time for the federation changes to propagate, but once enabled, you should find that logins to Office 365 are now SSO enabled, and you are redirected through your Okta tenant for authentication.
What’s next?
Now you have single sign-on, take a look at implementing Office 365 Sign-on policies to further secure your implementation, and if you make use of VDI or shared desktop sessions, consider implementing silent activation to provide seamless access to Office 365 for users of these clients.
If you have set this up in test, make sure you evaluate functionality against all the ways a user might login to Office 365, including on the web, via the desktop apps on Windows and Mac, and on phones (include iOS and Android and third party mail clients such as Gmail and the mail app on iOS).
Notes on legacy protocols such as POP and IMAP
These legacy protocols used for email communication do not have any support for modern standards such as federation based single sign on. As such, even after federation, these protocols will still require password based authentication. These will work after federation, and the requests are passed to Okta for verification against a users Okta password.
But ideally, as these protocols also do not support MFA they are a security risk, and you should consider disabling them completely. This Okta whitepaper on Securing Office 365 with Okta is a good resource to follow.
