Certified: August 01, 2022
When integrated, Microsoft Office 365 end users must authenticate with RSA SecurID Access to sign in. Microsoft Office 365 can integrate using WS-Federation SSO Agent, SAML SSO Agent, or SAML relying party.
The available features and limitations are dependent on the specific Office 365 application and on whether it is integrated using SAML (SSO Agent or relying party) or WSFederation.
Application | Integration Type | |||
---|---|---|---|---|
Operating System | Office Version | Name |
WSFederation |
SAML |
Any | Office 365 | Web browser | ||
Android | N/A | Outlook for Android | ||
iOS | N/A | iOS Mail app (ActiveSync) | ||
iOS | N/A | Outlook for iOS | ||
Windows | Office 2016 (ADAL enabled) | Word, Access, Excel, PowerPoint, OneNote, Teams | ||
Windows | Office 2013 (ADAL disabled) | Word, Access, Excel, PowerPoint, Project, SharePoint, Visio, Teams | ||
Windows | Office 2013 (ADAL enabled) | Word, Access, Excel, PowerPoint, Project, SharePoint, Visio, Teams |
Authentication supported | |
Client configuration required | |
Authentication not supported | |
Access policies and additional authentication supported | |
Access policies supported but additional authentication not supported |
SSO Agent integrations use SAML 2.0 or WS-Fed technologies to direct users’ web browsers to Cloud Authentication Service for authentication. SSO Agents also provide single sign-on to other applications using the RSA Application Portal.
Relying party integrations use SAML 2.0 to direct users’ web browsers to Cloud Authentication Service for authentication.
This section shows all of the supported features by integration type and by RSA SecurID Access component. Use this information to determine which integration type and which RSA SecurID Access component your deployment will use. The next section in this guide contains the steps to integrate RSA SecurID Access with Microsoft Office 365 for each integration type.
Authentication Methods |
Authentication API |
RADIUS |
Relying Party |
SSO Agent |
---|---|---|---|---|
RSA SecurID | - | - | ![]() |
![]() |
LDAP Password | - | - | ![]() |
![]() |
Authenticate Approve | - | - | ![]() |
![]() |
Authenticate Tokencode | - | - | ![]() |
![]() |
Device Biometrics | - | - | ![]() |
![]() |
SMS Tokencode | - | - | ![]() |
![]() |
Voice Tokencode | - | - | ![]() |
![]() |
FIDO Token | n/a | n/a | - | - |
Authentication Methods |
Authentication API |
RADIUS | Authentication Agent |
---|---|---|---|
RSA SecurID | - | - | - |
On-Demand Authentication | - | - | - |
Risk-Based Authentication | n/a | - | - |
![]() |
Supported |
- | Not supported |
n/t | Not yet tested or documented, but may be possible |
n/a | Not applicable |
The following links provide instructions on how to integrate Microsoft Office 365 with RSA SecurID Access.
This document is not intended to suggest optimum installations or configurations. It assumes that the reader has both working knowledge of all products involved, and the ability to perform the tasks outlined in this section. Administrators should have access to the product documentation for all products in order to install the required components. All RSA SecurID Access components must be installed and working prior to the integration.
The following links provide information on Office 365 prerequisites to integrate with RSA SecurID Access. Some or all of these prerequisites may already be met if your organization is already using Office 365.
Note: When using a non-persistent virtual desktop infrastructure (VDI) to access Office 365, the user’s credentials are not saved once they log out. At the end of a session, the desktop reverts to its original state, and users have to re-enter their credentials again. However, a persistent VDI saves the user's credentials, and they appear each time at login.
Allow or block clients that do not support modern authentication
Issue: Clients, such as Microsoft Office desktop applications that do not support modern authentication will fail authentication if using a policy that requires additional authentication.
Resolution: Configure and apply an access policy that allows or denies clients that does not support modern authentication and require additional authentication for clients that do.
The following clients will have MSOIDCRL in User Agent string:
The following clients will have null in User Agent string:
This example policy allows access for all clients that do not support modern authentication, and requires additional authentication with low assurance level for clients that do.
Office 2013 rich clients do not prompt for credentials
Issue: A domain-joined user using a rich client will initially login, but if the user signs out of the rich client, they won’t get prompt to sign-in.
Resolution: Add a new DWORD value to the registry NoDomainUser and set the value to 1.
For full details, refer to the following link.
Sign-in error when identity routers are behind a load balancer
Issue: Error when accessing Office 365 applications:
Sorry but we're having trouble signing you in.
AADSTS20012: An error occurred when we tried to process a WS-Federation message. The message was invalid.
Cause: When multiple identity routers are configured behind a load balancer, internal identity router traffic can get sent to the load balancer and then on to a different identity router. This loss of session persistence can cause authentication failure.
Resolution: Create static DNS entries to map the load balancer hostname to each identity router proxy IP address:
For each identity router:
Reference Step 13 of Add an Identity Router Using the Cloud Administration Console.
No known issues
No known issues.
RSA SecurID Access Implementation Guide > Microsoft Office 365 - RSA Ready SecurID Access Implementation Guide