In the cloud era, any organization can have zillions of applications available to end users, so having usernames and passwords for every single application like we used to have in the past is just not practical anymore. Using Azure Active Directory, an organization can take advantage of the synchronized directories between on-premises to the cloud, and by doing that the same identity will be used on both environments, providing a seamless and simple experience to the end users. Microsoft provides the functionality for Azure Active Directory SSO (single sign-on). Having a central location for authentication helps Office 365, SaaS, and third-party providers use the same authentication method to allow access to their application, thus reducing the number of username and passwords and at the same time improving the end user experience. And using Azure Active Directory SSO also adds to consistency, productivity, and security.
Leveraging Azure Active Directory helps administrators to use increase security by applying conditional access based on several variables, such as application resource, network location, MFA (multi-factor authentication), and user identity.
In this article, we are going to configure the synchronization between an on-premises Active Directory and a brand-new Azure Active Directory, and publish a couple of Azure Active Directory SSO applications to end users. It all starts on the Azure Active Directory item on the Microsoft Azure portal. That page is the starting point to manage the synchronization, configure applications, and additional features related to the functionality.
Configuring the DNS domain
The first step is to configure the domain. Nowadays, it is simple and easy to configure when your users are using the UPN (email@example.com) that matches your public domain. In our article, we are going to use the domain infralab.org, and we have the Active Directory using that same domain as a fully qualified domain name (FQDN). If that is not your case and you use a non-routable domain (something like domain.local), then you need to add a UPN to your domain and configure the users to use it.
Logged on Azure Active Directory, click on Domain Names, and click on Add domain name. In the new blade, type in the domain name and click on Add Domain.
To create a new domain, we must validate it. There are a couple of ways to do that using DNS (either adding a TXT or an MX record). Let’s keep it simple and add a new TXT entry in our public DNS with the string informed below, wait a few minutes for the replication to take place, and then click on Verify.
After verifying the new domain successfully, click on Make primary, and on the new dialog box Do you want to make infralab.org your primary domain? click on Yes to confirm. On the same page, click on Download Azure AD Connect link, which will open a new window with the latest supported version of the Azure AD synchronization tool. Copy that download to the server that will be used to synchronize accounts between on-premises and Azure Active Directory.
For this portion, we will start from a healthy Active Directory running on Windows Server 2016 with two domain controllers, and they are replicating just fine on a single Active Directory site. We are going to use a server called TORSYNC01, which is where we are going to install the AD Sync Tool.
After downloading the tool, we are going to select Express Settings, and authenticate on both on-premises and Azure AD (it is nice to create an account on Azure AD with the global administrator role) and leave default settings.
Preparing for the Azure Active Directory SSO configuration
Before starting the process, there are a couple of points that I would like to highlight that will make it easier creating your Azure AD Active Directory SSO integration, as follows:
- Make sure that you open a brand-new session of your browser. Also, do not save passwords, and if possible delete all historical data and cached credentials to start fresh.
- Open two tabs, one with Microsoft Azure and another with the application that you want to integrate (in our case Citrix ShareFile).
- Define a user to be used in the testing process. In our article, it is going to be firstname.lastname@example.org.
- Read the documentation integration in Microsoft Azure and on the vendor’s site, which helps to troubleshoot any issue that may arise during the deployment.
- If you are hitting a wall for too long, go for a cup of coffee! I’m sure you will solve it faster when you come back.
Besides these points above, we created a list of the item that will be requested on either side of the fence (Azure/Citrix ShareFile) and where to retrieve such information, and an example of the value expected.
|Item||Location to retrieve||Value|
|Sign on URL||Citrix ShareFile||https://infralab.sharefile.com/saml/login|
|Certificate||Azure Portal||Open the file with notepad and copy and paste the entire content|
|Your IDP Issuer / Entity ID||Azure Portal||https://sts.windows.net/7c32d55a-8532-xxxx-yyyy-1xxx123x1x12/|
|Login URL||Azure Portal||https://login.microsoftonline.com/7c32d55a-8532-xxxx-yyyy-1xxx123x1x12/saml2|
|Logoff Url||Azure Portal||https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0|
Configuring Citrix ShareFile
The first step is to get a trial (if you don’t have a subscription already) with Citrix ShareFile, and that process takes no more than two minutes. Logged on the Citrix ShareFile as administrator, click on Settings icon, Admin Settings, expand Security, click on Login & Security Policy.
First, disable the Enable two-step verification by selecting No.
In the Basic Settings section: First, enable SAML by selecting Yes. Copy the URL of the ShareFile Issuer / Entity ID because we will add that information on the Azure side. The other information Your IDP Issuer/Entity ID, the certificate thumbprint, Login URL and Logout URL are coming from the Microsoft Azure portal.
In the Optional settings section, select Yes, and change the SP-Initiated Auth Context to exact, and make sure to save the settings.
There are two steps to complete the settings on ShareFile. First, create a couple of folders, one personal and one shared (no need to assign permissions at this point). Click on People and Manage Users Home, click on Create Employee, on the new page fill out the First and Last name and email address (no need for a password), and for this article, we are going to use the email@example.com. During the creation of the user, assign the two directories (personal and shared) that were created in the previous step.
Adding ShareFile on Azure AD Enterprise apps
Logged on the Azure Portal, click on Azure Active Directory. In the new blade, click on Enterprise applications, and on the next blade click on All applications. A list of all applications will be listed. Click on New Application.
We can search for existent applications. In this article we are going to use Citrix ShareFile. Type in Citrix and select Citrix ShareFile from the list. On the new blade, click on Add. Note: The app we are adding provides the SSO mode support, in this case, Password and SAML.
Azure Active Directory provides a Quick Start, which is a series of steps to get the app integrated and up and running. We will focus on two must-do steps to get it going, which are Assign a user for testing and Configure single sign-on. All steps described on the Quick Start are accessible on the Manage section, which can be found on the right side. If this is your first time, you will use that to get up to speed, but as you get acquainted with the interface you probably will go straight to the Single sign-on and Users and groups items.
The first step, in my humble opinion, is to configure the SSO. Click on Configure single sign-on (required) on the list. On the right side, select define the mode. Using Citrix ShareFile, we can select SAML-based Sign-on. The information to be placed on Sign on URL will come from ShareFile site.
The next step is to download the certificate that is going to be used by the SAML tokens. Click on Certificate (Base64) and open the file with a notepad and copy the entire content (we will use that information on Citrix ShareFile site). Make sure to change the notification email to receive information when the certificate is about to expire. Click on Save located on the top bar.
After configuring the SSO, click on Users and Groups, and on the new blade click on Add user. In the next blade, select a user and select the role. We are going to select Employee to match what we had created on ShareFile in the previous section.
Testing the SSO integration
The basic test is to log on to myapps using our test account (firstname.lastname@example.org) and the Citrix ShareFile icon will be displayed. Click on it and we will be redirected automatically to the ShareFile site without any authentication.
Another method is going straight to the Citrix ShareFile site. Click on Sign In located on the Company Employee Sign In section. That will redirect the user to the Microsoft authentication page.
In both scenarios, which are going to the myapps page or straight to ShareFile and authenticating on the same place (Microsoft Azure), the end user experience will be the same and it will end up on the initial page of the ShareFile. The same applies for users trying to use the mobile ShareFile app.