Skip navigation
All Places > Products > RSA SecurID Access > Blog > 2015 > September
2015

 

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:

o365-users-mailbox.png

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

o365-no-exchange-mailbox.png

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:

 

dns-o365-settings.png

First I made sure that worked externally:

~$host -t TXT singlepoint66.com 
singlepoint66.com descriptive text "v=spf1 include:spf.protection.outlook.com -all"
~$host -t MX singlepoint66.com
singlepoint66.com mail is handled by 0 singlepoint66-com.mail.protection.outlook.com.
~$host -t SRV _sip._tls.singlepoint66.com
_sip._tls.singlepoint66.com has SRV record 100 1 443 sipdir.online.lync.com.

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

ad-server-o365-dns-entries.png

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

 

C:\>nslookup -q=mx singlepoint66.com

Server:  UnKnown

Address:  10.210.0.154

 

 

singlepoint66.com       MX preference = 0, mail exchanger = singlepoint66-com.mail.protection.outlook.com

singlepoint66-com.mail.protection.outlook.com   internet address = 207.46.163.138


C:\>nslookup autodiscover.singlepoint66.com

Server:  UnKnown

Address:  10.210.0.154

 

 

Name:    autodiscover-namwest.outlook.com

Addresses:132.245.81.136

          132.245.39.248

Aliases:  autodiscover.singlepoint66.com

          autodiscover.outlook.com

          autodiscover.outlook.com.g.outlook.com


C:\>nslookup -q=srv _sip._tls.singlepoint66.com

Server:  UnKnown

Address:  10.210.0.154

 

 

_sip._tls.singlepoint66.com     SRV service location:

          priority       = 100

          weight         = 1

          port           = 443

          svr hostname   = sipdir.online.lync.com

sipdir.online.lync.com  internet address = 132.245.113.25

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:

outlook-rich-client-auto-discovered.png

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:

outook-client-with-adal.png

Mobile Testing

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

down-ms-outlook.png

Launch the App:

outlook-add-account.png

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:

outl-enter-username.png

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

outl-redirect-to-idp.png

And here is the login page you will see:

outl-at-idp.png

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

outl-comp-setup.png

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

outl-logged-in.png

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

ADAL

I decided to try out the new ADAL authentication method that Microsoft now provides. Some of the specifics of ADAL can be found at Office 2013 updated authentication enabling Multi-Factor Authentication and SAML identity providers. Here is a pretty good overview of what ADAL provides from that page:

adal-auth-pic.png

 

More information and specific use cases that this method covers is laid out in Azure AD Authentication Library for .NET. Prior to running this you need to enable ADAL support for your O365 tenant. The Office 2013 modern authentication public preview announced  page covers the instructions on how to apply for that. After you apply for the program, you will see the following:

o365-adal-program.png

You will receive an email when it's enabled for your O365 Tenant.

Desktop Office Suite

So let's install the O365 Rich client (A.K.A. Office 2013) on our Desktop. This is done by going to Office 365 settings from the O365 Web Portal:

o365-settings.png

Then click on Software:

o365-software.png

And then you can click Install at the bottom of the page to start the install:

install-software-o365.png

Then the install will start:

o365-installer-2.png

The installer will run through the installation process and after it's done you will see this:

o365-installer-done.png

You can also check out the installed apps on windows and you will see the following:

o365-installed.png

Updating Office

Looking over the Office 2013 modern authentication public preview announced page it mentions that we have to be at a specific version:

The public preview update for Office 2013 clients includes Office 2013 and Office 365 ProPlus. Office 2013 requires the March 2015 update patch that is described here.

From the bottom of the page:

Please note that the Office client updates can be found in the following versions of Office Click-to-Run:

14.0.7145.5001

15.0.4701.1002

Looking over my version, I saw the following:

o36-version-rich-client.png

So I was already at the latest version: 15.0.4745.1001. If you are below the above version, click Update Now to update the client:

update-o365-button.png

and the update process should start:

o-2013-update-going.png

After it's done, if you restart the Office Application you will see the new version:

o2013-new-version.png

Enable ADAL for Office

We also have to enable a registry modification to enable ADAL support for Office 2013. From Enable Modern Authentication for Office 2013 on Windows devices

To enable modern authentication for any devices running Windows (for example on laptops and tablets), that have Microsoft Office 2013 installed, you need to set the following registry keys. The keys have to be set on each device that you want to enable for modern authentication:

REGISTRY KEYTYPEVALUE
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL REG_DWORD1
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\VersionREG_DWORD1

 

So I went ahead and made that change:

adal-regedit.png

Using Office with ADAL and with SAML IdP

If you were previous using Office 2013 for something else, then relaunch Office 2013 and logout:

o-2013-logout.png

Then re-login and upon specifying the email it will figure out that you have an external IDP enabled and show you a window where you can login:

o-2013-idp-shown.png

After you login you will see that you are fully logged into the Rich client:

rich-client-logged-in-adal.png

I created a new document and I was able to successfully upload it to OneDrive using the ADAL enabled Office 2013 Rich client:

office-upload-to-cloud.png

While RSA Via Access supports using any identity source attribute in creating policies, user groups is probably the most commonly used attribute. What's great about groups is they give you pre-packaged sets of users with similar job functions. With the policies in Via Access, groups alone can offer great flexibility in access control.

 

Let's look at an example. Both my IT department and my Sales department need access to Concur for expenses. The Sales department has iPhones with TouchID and the IT department does not. However, the IT department has been issued SecurID tokens. As a company we want to offer single sign-on with additional authentication to Concur for all these users.

 

Let's take a look at how to make that happen.

 

First, I will create a new policy and select the appropriate identity source(s) where these users reside. Administration Console Access / Policies / Create a Policy.

 

To build my rule sets, I will first enable sales access by adding a new rule that selects the virtualGroups attribute.

Note: I could also use memberOf, but would need to include the full distinguished name (i.e. CN=Sales,OU=Mach_4_Corp,OU=MST,OU=United_States,OU=North_America,OU=Clients,DC=kc,DC=org ). VirtualGroups lets me strip out just the group name, "Sales".

 

Once I select "virtualGroups", I will select the operator "Set Contains Any" and enter the value "Sales". This says I'm restricting access to only users in the Sales group.

 

Screen Shot 2015-09-09 at 9.21.54 PM.png

 

 

When I save that setting, I've allowed sales access. In order to require sales to use "Fingerprint" as the step-up method, I first need to choose step-up required. I then choose the scheme and sensitivity that I have previously mapped to Fingerprint. In this case "Basic Step-Up Authentication" with a sensitivity of "High".

 

Great! I've got a rule set that allows sales access if they use their Fingerprint. We're half done.

 

 

Screen Shot 2015-09-09 at 9.26.18 PM.png

 

 

Now we need to enable IT access. To start, I will choose the option to create a new rule set. This new rule set will follow the first. Since the policy builder uses the XACML standard of First Applicable between rule sets, if I'm a user that's not in sales, the next rule set will be evaluated to see if that rule set grants me access.

 

I will repeat the steps I just did for selecting the attribute "virtualGroups" with the operator "Set contains any" with a value of "IT".

 

To add SecurID as the step-up required for the IT folks, I will again select step-up required and choose the scheme and sensitivity tied to SecurID. In this case "Basic Step-Up Authentication" with a sensitivity of "Medium".

 

 

Screen Shot 2015-09-09 at 9.23.42 PM.png

 

 

Anyone not in sales or IT will be denied access because neither of these rules sets apply to them.

 

Screen Shot 2015-09-09 at 9.28.14 PM.png

 

 

I can save this policy and then apply it to my Concur app and any other app where I want to use this policy using the application access page of application setup. Once this is done and I publish the changes, my sales team can access Concur using Fingerprint and IT can access Concur using SecurID.

Darren Platt has published a blog about the importance of deployment flexibility in leveraging IDaaS in a Hybrid World. In the post, Darren discusses the importance of migrating to the cloud in the way that makes sense for each company. Many applications are still on-prem while others are in the cloud but users want an experience that doesn't differentiate. With Via Access, we strive to provide end users with a consistent experience while providing enterprise level security. Whether through integrating with an existing WAM or using Via Access to connect to on-prem and SaaS applications, the Via Access hybrid model is purpose built for combined environments.

Filter Blog

By date: By tag: