SAML Single Sign On Configuration – Azure AD

MyWorkDrive Azure AD SAML Overview

MyWorkDrive supports SAML based Web File Manager Single Sign On (SSO) to Azure AD instead of traditional Active Directory authentication for all necessary logins.

For SAML, MyWorkDrive acts as a Service Provider (SP) while the Azure AD acts as the identity provider (IdP). In a typical scenario, customers sync their Active Directory Credentials to Azure AD. User logins are set to use the same upn suffix to login to Active Directory as they do in Azure AD (in most cases this is the companies Office 365 Subscription).

 

Configuration using these instructions will permit you to enable/apply conditional access policies for features in Azure AD such as Pre-Auth and MFA to this Enterprise Application.

 

MyWorkDrive Azure AD SAML Setup

Before you start:
Ensure the MyWorkDrive server is trusted for delegation as per our Delegation Article

MyWorkDrive is listed an approved enterprise application in Azure AD – Information link : https://azuremarketplace.microsoft.com/marketplace/apps/aad.myworkdrive?tab=Overview

Review the instructions in Microsoft’s tutorial and information links here:
https://docs.microsoft.com/azure/active-directory/saas-apps/myworkdrive-tutorial

Prerequisites

• Ensure users have a upn suffix applied for domain name to match Azure AD Login name so they can login to your MyWorkDrive server with their email address (most companies sync their Active Directory to the same Azure AD directory that the use to login to Office 365).
• Ensure the MyWorkDrive server is trusted for delegation as per our Delegation Article
• Ensure your MyWorkDrive server is accessible on the internet for client login (web, mobile, map drive). Enable the Cloud Web Connector or Setup your own public SSL Certificate and Hostname pointing to your MyWorkDrive Server over port 443 (SSL) View Support Article.

Setup Steps

• Login to portal.azure.com as admin and connect to Azure AD Domain (if you are using Office 365 this is the same account you use to login to portal.office.com).
• Click on Azure Active Directory, Enterprise Applications – New Application – Search for “MyWorkDrive” – Add MyWorkDrive as an Enterprise App.

• Click Single sign-on from the menu on the left and choose SAML (you will only need to choose SAML the first time you begin configuration)

 

• Ignore the configuration guide presented at the top of the page. This is helpful when you are setting up an SSO from scratch, but offers unnecessary steps when using the template we provide.

 

• Start by editing the information in box 1. Select Edit.

• Accept the default Entity ID of “MyWorkDrive”
  This only needs to be changed if you have multiple MyWorkDrive Servers setup in your Azure AD as Azure AD requires each enterprise app to have a unique Entity ID. When changed, it must also be changed to match in the Service Provider Name field of SSO setup in MyWorkDrive admin. You will get an error about Entity ID mismatch on user sign in if they are not set correctly.
• Enter your reply URL – this will be your host name followed by /SAML/AssertionConsumerService.aspx
  for example: https://yourserver.yourdomain.com/SAML/AssertionConsumerService.aspx
  If you intend to support multiple domain names for the server – such as both a Cloud Web Connector and Direct connection address, be sure to enter all of them as possible reply/response URLs.
• Enter your sign-on URL if users will be logging on to MyWorkDrive directly (instead of or in addittion to accessing through myapps.microsoft.com portal) with your host name followed by: /Account/login-saml
  for example: https://yourserver.yourdomain.com/Account/login-saml.
  Note that this is technically optional as you can retain a traditional login while only providing SSO as an option, though most often you will want to set it up this way.
• Single logout URL. If you wish to use single logout, set your logout URL as https://yourserver.yourdomain.com/SAML/SLOService.aspx
  Note the additional information below about how AzureAD handles single logout.
• Nothing needs to be entered in the Relay State field, leave it blank.

 

• Next, make the new MyWorkDrive server available to users. Only those users who actually have permissions to shares via NTFS and as configured on share permissions in MyWorkDrive will be able to successfully log in, regardless of how you enable access here.You have two options – Permit all OR manually select specific users.To permit all, click Properties from the left menu then set “User Assignment Required” to No in the body.This is the most normal configuration as it avoids duplicate administration. Simply add users to AD and the appropriate groups. Assuming you’re syncing your local AD to Azure AD, those users will be able to login to the MyWorkDrive server and get the shares they are granted permission to as configured in MyWorkDrive without needing to assign them one-by-one to the Enterprise App.OR Manually assign users and groups in the Azure Active Directory portal to the new MyWorkDrive App
  Select users and groups from the left menu, then use the Add User/Group item at the top of the screen.
  Note Domain Users groups do not sync to Azure AD by default. In most cases if you are manually assigning users you will be assigning by name.
  

• In box 3, Copy the App Federation Signing Certificate Metadata URL to the clipboard. No other changes are required in box 3, you do not need to edit, just copy the URL using the copy icon.

 

• Ignore boxes 4, 5, and 6. Like the configuration instructions above, this is helpful if you are setting up an SSO from scratch – since these instructions use our template, actions in those boxes are not required.

• On the MyWorkDrive Server in the admin panel, Enterprise Section, Enable SAML/ADFS SSO, Choose Azure AD SAML and paste in the Azure App Federation Metadata URL you copied from box 3.
• Optionally click “Require SSO Login” (this will automatically redirect all connections to Azure AD SAML Login).
  If you do not select Require SSO Login, users will login when going to your MyWorkDrive server URL with their traditional domain login, and the Azure AD login will only be used when clicked as a link from the Office portal or MyApps.
• Optionally select Enable Single Logout, see note below about how Logout is handled in AzureAD
• Optionally, if you changed the Entity ID in Azure AD setup box 1, change the Service Provider name to match exactly what you entered in Azure AD Setup.
• Click Save. This will automatically pull down the Azure AD SSL Certificate and settings for you.

Test Access

• We suggest initially testing with the web browser before proceeding to test the other clients.
• You may wish to use a different browser from what you routinely use / are logged in to OR private browsing mode to validate the Azure AD login experience and any Conditional Access policies for MFA you may have applied.
• If you enabled Require SSO Login, browse to your server’s Login URL, e.g. https://yourserver.company.com and you will be redirected to Azure AD SAML to login.
  If you did not enable Require SSO Login, you will need to specify the SAML Login URL e.g. https://yourserver.company.com/account/login-saml.m
• Login using Azure AD. After successful login your test user will be redirected by the your MyWorkDrive Web Site and their assigned file shares will be displayed.
• Alternatively, if you are assigning users to the App in Azure AD, you may login as an assigned user to https://myapps.microsoft.com. Select the MyWorkDrive application.

The user is automatically logged into your MyWorkDrive browser Web File Manager.

If, upon login, the user’s shares are present but are blank when you click into them, that’s an indication that Delegation is not set correctly. Please refer to the Delegation setup article. Note that changes to delegation can take 15 minutes or longer to propogate on AD. In cases of a large AD, several hours have been noted for delegation to fully propogate.

 

SSO Logins are fully compatible with all MyWorkDrive features including

• all clients (Web, Mobile Web, Windows Map Drive, Mac Map Drive, iOS, Android, and Teams)
• the Cloud Web Connector
• Editing in Local Office from the Web Client
• and Places in Mobile Office.

SAML Logout

Azure Active Directory doesn’t support SAML logout. SP-initiated SLO, where a SAML logout request is sent to Azure AD, doesn’t cause a logout response to be returned. Instead, Azure AD displays a message indicating the user is logged out and that the browser windows should be closed. Logout from Azure AD doesn’t cause a logout request to be sent to the service provider. Azure AD doesn’t support configuring a SAML logout service URL for the service provider.

Troubleshooting

• Ensure you are using a browser for testing in-private or incognito to eliminate any caching issues
• Double check that user is able to login without SAML and they are using an email address that matches their UPN in Active Directory
• User receives error: The signed in user xxx@xxx.com is not assigned a role for the application – as per setup notes above: Assign a user or group they are a member of in Azure Active Directory portal to the new MyWorkDrive App (Enterprise applications – All applications – MyWorkDrive – Single sign-on -SAML-based sign-on) users and groups or disable the user assignment required by setting it to no.
• Folders are displaying as blank after logging user in: Ensure the MyWorkDrive server is trusted for delegation as per our Delegation Article
• User receives error: The reply URL specified in the request does not match the reply URL’s configured for the application – Check to ensure the URL specified in Azure AD SAML matches the public web address of the server and if reverse proxies are used they are not re-writing the URL. Additionally if you are using your own hostname – e.g. https://yourserver.yourdomain.com be sure to disable the MyWorkDrive Cloud Web Connect under settings on your MyWorkDrive server (when the Cloud Web Connector is enabled we assume your using our *.myworkdrive.net and make changes to the reply URL to accommodate it).
• If you are receiving multiple MFA prompts during login, make sure if you disable two factor in MyWorkDrive Enterprise after enabling Require SSO. If you have an MFA requirement in Azure AD, that will be called as part of the login through Azure AD and no settings are required in MyWorkDrive to enable it.

 

Renewing your certificate

The SSO certificate issued by Microsoft and used by MyWorkDrive to secure communications between Azure AD and your MyWorkDrive server periodically expires. The default is 3 years, but you can choose a lesser amount on creation.

Then your certificate is due to expire, you’ll receive an email with some general guidelines from Microsoft, but thanks to the integration work we’ve done to make Azure AD easier to deploy, its actually easier than Microsoft describes.

The email you’ll receive notes 5 steps.

 

The two changes to the instructions are to

• Delete the old certificate from Azure AD
• Use MyWorkDrive to download the new certificate, there is no need to manually place the certificate

 

After step 4,

Delete your old certificate in AzureAD.
You’ll immediatley be updating MyWorkDrive in the next step with the new one, so make the new one Active (if it isn’t done automatically) and delete the old one as it is no longer necessary.
On the old/inactive certificate, click on the 3 dot menu on the left edge of the certificate row and choose Delete Certificate.

Instead of Step 5

Now, with only one cert showing on your MyWorkDrive Azure AD configuration, save the Azure AD Page, and then login to the MyWorkDrive Admin panel on the MyWorkDrive server and browse to the Enterprise tab.

Confirm you have Azure AD Configured, and then just save the page.

 

MyWorkDrive will use the built in Azure AD configuration to connect to your Azure AD and download and update the certificate. There is no need to manually place the new certificate on the file system or “Upload it to MyWorkDrive”, MyWorkDrive will take care of that for you.

The SAML certificate may be stored in a number of locations depending on your version of MyWorkDrive and if you have Clustering enabled.

 

Note that if you receive an error message about multiple public signing certificates, that is an indication that you failed to delete the old certificate from Azure AD. Please log back in to Azure AD and double check that the new certificate was made active and the old certificate was deleted.