SecurID® Community Blog

Subscribe to the official SecurID Community blog for information about new product features, industry insights, best practices and more.

RSA SecurID Access O365 ADAL Rich Client Email and Mobile Setup

2 2 7,723

After I confirmed that ADAL can be used with RSA Via Access I decided to go a little further and ensure that the Desktop Outlook Client works along with the Mobile Outlook App as well. First make sure you run through the steps described in RSA Via Access O365 ADAL Basic Rich Client Setup to enable ADAL on the O365 tenant side and local machine as well.

Office 365 Configuration

Confirm User has an Exchange Mailbox

If you login as an Admin to the O365 portal and go to Users -> Active Users -> "YOUR USER" and you will see the status of a user's mailbox:


If the user doesn't have a mailbox, you will see the following:


DNS Configuration

If you login as an Admin to the O365 portal and go to Domains -> "YOUR DOMAIN" ->  Domain Settings it will list all the DNS setting necessary for all specific functionalities:


First I made sure that worked externally:

~$host -t TXT descriptive text "v=spf1 -all"
~$host -t MX mail is handled by 0
~$host -t SRV has SRV record 100 1 443

Then I did the same thing on the my internal DNS server:


Lastly ensure the machine that will run the Outlook Desktop client can resolve the above DNS entries:

C:\>nslookup -q=mx

Server:  UnKnown

Address:       MX preference = 0, mail exchanger =   internet address =


Server:  UnKnown







C:\>nslookup -q=srv

Server:  UnKnown

Address:     SRV service location:

          priority       = 100

          weight         = 1

          port           = 443

          svr hostname   =  internet address =

Rich Client Testing

Desktop Client Test

Then I launched Outlook and it picked up my email by default and started to autodiscover the mail setup and after it was done, I saw the following:


Since I already authenticated after I launched Word (as seen in the previous post), I didn't even have to enter the password. Just in case, I rebooted my machine and re-launched the Outlook client and I was able to send an email without any issues:


Mobile Testing

My next test was to try out the Android Outlook App. Install the app from Google Play:


Launch the App:


I tried Office 365 and Exchange  (I am using Exchange Online provided with O365 and not an Exchange Server on Premise) and both worked for me. Here is the O366 flow, first enter your username:


It will figure out your domain is federated and will then forward you to the IdP:


And here is the login page you will see:


Then after you authenticate to the IdP, it will go back to O365 and show you that it's completing the setup:


And then you will see your mailbox and you can send messages:


Supported Clients and Protocols

Microsoft provides links to pages that have the support matrix: Updated Office 365 modern authentication. You will notice under the Legacy Clients section, we see the following:




Some clients like Office 2010 and 2007 are not supported and clients like Native iOS and Android Mail Apps (which use Active Sync) are not supported either. Similar note seen at Outlook 2016: What Exchange admins need to know:


Modern Authentication provides Outlook 2016 with several benefits:

  • Single sign-on (SSO). Outlook now support single sign in with other Office applications.
  • Multi-factor authentication. Outlook will support multi-factor authentication (MFA). MFA secures the user sign-in beyond just a single password. When enabled, users are required to acknowledge a phone call, text message, or app notification on their smartphones after correctly entering their passwords. Sign in is only confirmed after this second authentication factor has been satisfied.
  • No more basic auth: Prior to Modern Authentication, Outlook would connect to Exchange Online using Basic auth over HTTPS. This required the username and password to be provided anytime a connection to Exchange Online is made. Modern Auth flows negate the need for this type of basic authentication. Instead, the Outlook client now communicates directly with the customer’s Identity Provider and no longer needs to share the user’s password with Exchange Online for user authentication.

Definitely something to consider when moving to ADAL/Modern Authentication