Configuring Azure Active Directory MultiFactor Authentication for DataCove
What is MultiFactor Authentication and how does it help?
From the development of computers and well into many decades of their use in the business and personal use worlds, users have consistently proven their identity to an operating system, application or website via the common Username and Password system. This combination of something that identifies the individual (the Username) and something the individual knows (the Password) have been a pair of keys that, when turned simultaneously, provided access to the system or service.
In our internet-inured world of the present, Usernames have long since adopted the unique identifier of an email address as a constant and are pretty to find or guess given their ubiquity as a communication system; they are no longer a viable “key” in terms of identity-proofing due to how easy they are to determine. Passwords, however, are something only the user knows (or at least are intended that way; we won’t get into Post-It Note passwords, Shared passwords or any of the various travails of the real world) and this “knowledge” of something that is otherwise secret is still useful as a key when accessing a system or service.
This proof-of-knowledge methodology has been reasonably functional for many use cases throughout that time, but the prevalence of new security threats and easier-than-ever means of fooling users into unwittingly giving away that Username and Password combination to malefactors has made it a low barrier of security when used on its own, leading to tens of thousands of compromised accounts every year, both business and personal. The data contained within that account can be used for any number of nefarious purposes, but usually wind up with the goal of extorting money from someone or some organization in the end.
MultiFactor Authentication, commonly abbreviated as 2FA (Two-Factor Authentication) or MFA, is an enhanced means of proving your identity to a system. It combines two or more “factors,” that the user possesses to then authenticate themselves to the system as the intended user. Sticking with the door and key example, it’s essentially adding more keyholes to the door that new keys (the “factors”) can be inserted into for that simultaneous turning to provide access. These new keys are vastly more difficult to steal than a mere Username and Password combination, and provide another strong layer of defense that defends against most common attackers.
These new factors are commonly broken out amongst three different kinds of classification:
The Password is considered “Something you know,” and is the easiest to steal in a variety of technical and non-technical ways.
A Security Token, like a physical keyfob, is “Something you have,” and generally requires some casual physical access to the user to obtain.
Something that is intrinsic to the user, like a retina or fingerprint, is considered “Something you are,” and can be the most challenging to acquire.
By using two or more of these factors, it greatly increases the security of any given service or system by needing additional, much more difficult procure “keys” to obtain access.
DataCove naturally possesses the standard Username and Password functionality that is common throughout the computer world, but with the addition of a third party MFA service provider, henceforth referred to as an Identity Provider (IdP), additional factors can be added for authenticating user login. These IdP’s use a standard of communication known as Security Assertion Markup Language (SAML) in order to transfer access control information bidirectionally, so the term of SAML will be commonly seen in many of the upcoming instructions.
The steps below will cover the integration of your organization’s pre-existing IdP solution with DataCove, affording it a much stronger security barrier in the future.
Note: Using MFA with DataCove requires a valid Certificate-Authority (CA) Signed SSL Certificate to be installed on the system for proper key exchange with the IdP provider. If an SSL Certificate has not yet been uploaded, please follow the steps in the following guide before continuing: https://datacove.net/knowledge-base/uploading-an-ssl-certificate-to-datacove
Obtaining the DataCove SAML MetaData
Your organization’s Identity Provider (IdP) will need two unique URLs from the DataCove in order to prepare to support login requests being generated from it and will use these to authenticate a user back to DataCove as an allowed login, and the DataCove will likewise receive a URL from the IdP to instruct the system on where to send login request prompts.
The two DataCove-native URLs are found by logging into the DataCove web interface, selecting Users and Groups in the top header bar, clicking on SSO/2FA on the left hand side and then clicking on the “This Link” text at the top of the screen.
This link will open a new tab providing a large quantity of XML content, which is the SAML MetaData that the IdP will need to communicate with the DataCove. Two specific URLs on this page will be necessary to capture: the MetaData URL and the Assertion Consumer Service (ACS) URL.
These two URLs are universal between any DataCove and will take on the fully qualified domain name of the machine. For example, a DataCove named MASH4077 will always have a URL of https://MASH4077.domainname.com/saml/metadata/, with another DataCove named MASH8055 will always have https://MASH8055.domainname.com/saml/metadata/.
Using the example provided below as a guide, on your Datacove, locate the https://hostname.datacovehosted.com/saml/metadata and https://hostname.datacovehosted.com/saml/acs URLs. Depending on screen size and resolution used, scrolling down may be necessary.
Copy and paste this information over to a holding area like Notepad to add into the IdP’s relevant fields for it in the next section. Once the MetaData information has been captured, close the XML windows and leave the SSO/2FA page of DataCove available for data entry.
Creating an Enterprise Application for MFA in Azure Active Directory
Azure Active Directory’s (AAD) naming convention for integrating their MFA protection to a new system or service is called Single Sign-On, and this capability requires an Enterprise Application to be configured in AAD. The steps to configure that for DataCove are covered below.
Log onto the Microsoft administrative portal at admin.microsoft.com with an administrative login and navigate to Admin Centers on the left hand side menu, then select Azure Active Directory.
In the AAD Admin Center, select Enterprise Applications on the left hand side menu.
Now in Enterprise Applications, select All Applications from the Enterprise Applications menu, then click on the New Application button to configure a new Enterprise Application for DataCove.
A pop-in window will appear from the right hand side of the interface to prepare some details for the new application.
Provide a name for the application that will distinguish it clearly from any other Enterprise Applications and makes apparent the services it provides and the product it is supporting.
The recommended name for this is “DataCove Azure Active Directory SSO/MFA Service.”
For the purpose of the application, select “Integrate with any other application you don’t find in the gallery (Non-gallery)”
Azure Active Directory will take a moment to create the application, and then provide a confirmation dialog box of the success.
Once the Enterprise Application has been created, AAD will move you to its Application page.
Begin by selecting Properties on the left hand side Application menu.
Change the default setting for Assignment Required from “Yes” to “No.”
This allows for all users and all groups to use this application to log into the DataCove, assuming they have an appropriate Local or LDAP-integrated account that matches the information provided.
Adjusting the Visible to Users default setting of “Yes” to “No” can also be performed here, but is optional.
This setting determines whether the Enterprise Application displays to users in their Office 365 Application list for access, and is generally only used when a resource landing page is used for the end users who will have access to DataCove.
Next, select Single Sign-On from the left hand side Application menu.
This provides a listing of different Single Sign-On functions that this Enterprise Application can support.
Select SAML on this page to have AAD prepare a Single Sign-On service for configuration.
On the newly generated SAML-based Sign-On page, two fields will be required for population that instruct the Enterprise Application of whom they’ll be communicating with.
These fields will require the previously saved SAML MetaData information from DataCove.
Select the Edit icon in the Basic SAML Configuration section.
After clicking Edit, a right hand side menu will appear asking for various fields to be populated.
The two fields necessary will be the Identifier, commonly known as the ‘Entity ID’ and the Reply URL, more often referred to as the ‘Assertion Consumer Service URL.’
Populate these fields with the SAML MetaData URL from DataCove in the Identifier Field and the Assertion Consumer Service URL in the Reply URL field.
The remaining fields are not necessary to populate.
Once both required fields are configured, select Submit at the bottom of the page.
The SAML Single Sign-On section will now save this data and provide a confirmation message.
With the configuration of the Enterprise Application now complete, the MetaData XML from it will be ready for download and installation to the DataCove.
Under the Single Sign-On section of the Enterprise Application, scroll down the Section 3: SAML Certificates.
Click on the Federation MetaData XML download link and save the XML content somewhere easily retrievable.
This will be used in the next step to configure the DataCove to communicate with AAD for MFA purposes.
Adding the Azure Active Directory MetaData to DataCove and Applying MFA to Specific Users and Groups
If the SSO/2FA page from earlier in this process is still up, switch to that page now.
If it is no longer up, log into the DataCove web interface and navigate to Users and Groups in the top header bar, then select SSO/2FA from the left hand side menu.
DataCove has three options for which user accounts will be affected by the MFA configuration:
All users, which include both local users on the system as well as any LDAP Authenticated users. This is selected by using the Configure Global SAML button.
Local Users only, which are specific to local user accounts made on the DataCove like the ‘admin’ account. This can be configured by selecting Configure SAML for Local Users.
LDAP Authenticated Users, which are users who are granted access via an Active Directory group or common name system. This can be configured by selecting Configure SAML for LDAP Auth.
In general, most organizations will want to use the Configure Global SAML function to provide MFA for all users. In situations where different MFA systems exist, such as independent systems for administrative staff and for the end users, individual authentication options can exist for different user types.
Select the desired User Type to apply MFA to to proceed.
Note: DataCove does support IdP-initiated logins for Single Sign On purposes, but it is not recommended to use this function due to the security risks it presents from communication snooping or other user token theft issues. The use of IdP-initiated logins or their configuration is beyond the scope of this guide due to their often unique cases and configurations. Tangent Support should be contacted for troubleshooting assistance if this feature does not function with your IdP.
Note: Local User Accounts should possess the username of the email address used for login with Microsoft for the easiest deployment method. Attributes and Claims can be adjusted to compensate, but it is often simpler to match the username with email address when Local Accounts are being used. An example of an email address based username is pictured below. Note that logins are case sensitive.
Copy the MetaData XML content reserved earlier form the Azure Active Directory download link into the SAML MetaData XML section in the second field.
Everything below the EntityDescriptor starting field should be expanded and copied, including the EntityDescriptor field itself. Likewise, the text will close with EntityDescriptor at the end of the XML content.
Note: When opening XML content, it’s best to use a current generation web browser such as Microsoft Edge, Google Chrome or Mozilla Firefox to read the data legibly. Unexpected line breaks, spaces or other formatting errors can occur when using old or unsupported browsers.
Note: Do not copy any formatting information that the browser may interject prior to the EntityDescriptor field. Copying this data will result in errors when testing and using the MFA service.
Once the XML data is copied, scroll down to the bottom of the page and select Save and Test.
A test battery will now launch behind the scenes, wherein DataCove will attempt to reach out to the IdP to inquire with it for supported User Attributes. Unless there is already a live browser session authenticated with the IdP (usually only present in Single Sign On situations), this will likely time out or fail authentication. If after 30 seconds the top portion of the page does not change to text denoting the option to select the attributes to use, or if Single Sign On is not in use, proceed to the Test Link section.
Select the “Click here to begin test” link to open a new tab to your IdP based on the SAML MetaData URL provided in the previous step.
The Microsoft sign-in page will now appear.
Organization specific iconography or backgrounds may also appear at this time, if configured.
Sign in with an user account that matches the email address used for the username on DataCove and proceed with the preferred MFA authentication option already set up for that account.
Upon successful authentication, the Microsoft login page will now redirect back to DataCove and provide a list of Attributes that can be used to function as the Username.
Populate the radio button on the EmailAddress attribute and then click Select Username Attribute.
The page will now refresh back to the SSO/2FA section with a small green text update noting which Attribute was selected.
Note: if this Attribute needs to be changed later, run the same Save and Test sequence on the SAML Configurator and select a different Attribute.
The system is now primed for implementation of MFA.
Locate the newly created SAML Authenticator for the appropriate User Type and under the Actions field, select the upward facing green arrow.
This will activate the service for that User Type and all future logins will receive an MFA challenge.
Other User Types can be added in using the same method in the future if changes need to be made.
Subsequent future logins will now ask for a UserID when logging on, traditionally the user’s email address.
Upon successful login, the user’s email address will now display under the “logged in user” section in the upper right hand corner of the DataCove web interface.
This concludes the Azure Active Directory MFA configuration guide for DataCove.