Files.com provides integration with Microsoft Entra ID (also known as Microsoft Azure Active Directory or Azure AD), enabling user authentication and user provisioning from your Azure Active Directory service.

Implementing Single Sign On (SSO) allows your users to authenticate with the password specified in your Azure Active Directory and allows your administrators to manage user credentials and privileges at a single location.

Users can be provisioned within Files.com based on criteria defined within your Azure Active Directory service. For example, you can specify that only users that are members of a specified Group should be provided with Files.com user accounts.

Integration with Azure Active Directory can be achieved using SAML, OAuth, or the LDAP protocol. You can also have more than one Azure AD instance or app connected to your Files.com site.

There are differences in functionality when choosing between SAML, OAuth, and LDAP. Generally speaking, the more modern SAML and OAuth standards are only designed to be used for web and cloud based applications whereas the older LDAP standard can be used by all types of applications but isn't as well integrated with web and cloud based applications. Some notable differences are:

If you don't know which method to use, we recommend using SAML-based integration with Microsoft Entra ID/Azure AD because SAML-based integration is generally more secure, and it also offers seamless user and group provisioning using SCIM.

Azure SSO via SAML

Below are the instructions for adding Files.com as an application in Azure AD for SAML integration.

Adding Files.com in Azure AD for SAML

After logging in to your Azure portal as an administrator, navigate to Microsoft Entra ID -> Manage -> Enterprise applications and click the New application button. Click Create your own application. Enter an app name (e.g., Files.com), select Integrate any other application you don't find in the gallery (Non-gallery), and click the Create button.

Under Getting Started, click Set up single sign-on. Under Select a single sign-on method, click SAML. In the Basic SAML Configuration box, click the Edit button.

Complete the form using the following values, and leave other fields at their defaults:

Click the Save button to apply the changes.

Lastly, copy the App Federation Metadata Url in the SAML Signing Certificate box. You will need this URL when adding Azure in Files.com.

Adding Azure AD in Files.com for SAML

Go to the SSO page and select Microsoft Azure Active Directory SSO as the SSO provider, then select Use SAML, and enter the Display Name.

There are three different ways you can connect to SAML provider as below. Choosing the correct method depends on your requirements. The Metadata URL is the simplest option as it automatically handles updates, such as certificate renewals or changes to service provider URLs. For example, if Entra ID’s certificate expires, the Metadata URL will automatically update, while Metadata XML or Certificate Fingerprint requires manual updates. If automatic updates are not required, Metadata XML works well but requires manual intervention when changes occur. Certificate Fingerprint is the most manual option, giving more control over updates but requiring more effort to manage in the long-term.

Using Metadata URL

Paste the App Federation Metadata Url you copied from Azure into the Metadata URL field.

Using Metadata XML file

If you need to use metadata XML file to connect to Entra ID via SAML, as an Azure administrator, save the content of App Federation Metadata Url to an XML file. In Files.com, select the option Metadata XML file and select the XML file you created from Azure.

Using Certificate Fingerprint

If you need to use Certificate Fingerprint to connect to Entra ID via SAML, download the SAML Signing Certificate from Azure application dashboard. To get the certificate and issuer URL, go to the application you created in Entra ID and download the certificate. Once the Certificate is downloaded on your local machine, run the following command using terminal to obtain the Certificate's Fingerprint.

openssl x509 -in [your_cert_file] -noout -sha256 -fingerprint

In Files.com, select the Certificate Fingerprint option and paste the fingerprint you obtained from the above command. Also, paste the Issuer URL you copied from Entra ID. You can use the same URL for SLO endpoint and SSO endpoint also.

Once you save the changes, the Azure SSO method will now be available when assigning an authentication method for a user in Files.com, and the Sign in with Azure SSO button will be displayed on your site's login page.

It is strongly recommended to keep at least one site administrator with the password option as the authentication method, rather than assigning all to SSO, to prevent being locked out of Files.com in case of IdP or SSO issues.

Azure SSO via OAuth

Below are the instructions for adding Files.com as an application in Azure AD for OAuth integration. Note that OAuth is not compatible with SCIM for user and group provisioning.

Adding Files.com in Azure AD for OAuth

After logging in to your Azure portal as an administrator, navigate to Microsoft Entra ID -> Manage -> App registrations and click the New registration button.

In the registration form, enter Files.com in the Name field, and enter the Web URL https://app.files.com/login_from_oauth?provider=azure in the Redirect URI field. Keep the supported account type as Accounts in this organizational directory only (Default Directory only - Single tenant).

Click the Register button to complete the registration.

Next, copy both the Application (client) ID and Directory (tenant) ID by clicking the copy icon that appears when hovering your cursor over them, and make a note of these by pasting them into a text/document editor.

Next, to generate a client secret, navigate to Certificates & secrets, and click the New client secret button.

In the dialog that appears, enter a Description and select the Expires option according to your preference.

Click the Add button to generate your client secret.

Next, use the copy icon next to the generated secret Value to copy it, and make a note of it along with your previously copied client and tenant IDs.

Adding Azure AD in Files.com for OAuth

Go to the SSO page and select Microsoft Azure Active Directory SSO as the SSO provider.

In the Add provider form, select the Use OAuth option, enter Display Name, paste your Directory (tenant) ID copied from Azure into the Tenant ID field, paste your Application (client) ID copied from Azure into the Client ID field, and paste your Client secret copied from Azure into the Client Secret field.

Lastly, click the Save button to apply the change.

The Azure SSO method will now be available when assigning an authentication method for a user in Files.com, and the Sign in with Azure SSO button will be displayed on your site's login page.

It is strongly recommended to keep at least one site administrator with the password option as the authentication method, rather than assigning all to SSO, to prevent being locked out of Files.com in case of IdP or SSO issues.

Azure SSO via LDAP

If you prefer to use the LDAP method, Azure Active Directory will be integrated in the same way as with any other LDAP-capable service, such as on-premises Active Directory.

Prerequisites for Using LDAP(S)

Before you start the LDAP integration process, ensure that your Azure AD is set up with LDAPS. Avoid using a self-signed TLS/SSL certificate for LDAPS, and instead, opt for a valid and chained TLS/SSL certificate for LDAPS.

To configure LDAP based integration, refer to the LDAP/Active Directory integration documentation.

Provisioning Users Automatically

There are 2 primary methods for automatically provisioning users through Azure AD: SCIM provisioning and Just-In-Time (JIT) provisioning. SCIM provisioning involves the systematic synchronization of user data between your identity provider and Files.com, ensuring consistent and up-to-date user records. On the other hand, Just-In-Time (JIT) provisioning operates by creating user records on Files.com at the moment of their initial successful login, offering a more immediate approach. These two mechanisms provide flexibility in managing user provisioning based on your specific requirements and preferences within the Azure AD environment.

SCIM Provisioning

SCIM Provisioning is a standard that allows your Users to be automatically provisioned in Files.com from your Azure AD identity source. Note that SCIM provisioning is only compatible with SAML-based integration, not OAuth. Files.com offers numerous configuration options for SCIM provisioning, detailed in the Configuration Options section under our SCIM provisioning documentation.

If Authentication Mode is set to Basic Auth, generate the Basic Auth username and password in Files.com by navigating to the advanced settings in the Add/Edit SSO provider form. Under the Enable automatic user provisioning via SCIM? section, select Basic, then click Generate SCIM Username and Password. Copy both values and enter them in Entra ID for SCIM provisioning. Note that the credentials will only become active after saving the Add/Edit SSO provider form.

If Authentication Mode is set to Token, generate the access token by selecting Token in the same section, then click Save to generate the token. Copy the token and enter it in Entra ID for SCIM provisioning setup.

In your Azure portal, navigate to Azure Active Directory -> Enterprise Applications -> Files.com. Under the Manage menu, select Provisioning, set the Provisioning Mode to Automatic, enter the SCIM API endpoint URL as https://app.files.com/api/scim, set the Secret Token to the access token generated above. Click Test Connection and wait for the confirmation message, then click Save to authorize and enable provisioning.

Token based SCIM provisioning

If you are using token based provisioning, by default the token will expire in a year from the date you generated it. You will receive an alert email from Files.com before your SCIM token is going to expire. You can always extend the expiry date of the SCIM provisioning Secret token in Files.com. Type "SSO Providers" in the search box at the top of every page and then click on the matching result. Edit your Azure provider's settings and locate the Enable automatic user provisioning via SCIM? -> Token -> Token Expiration. You can either enter new date in the Token Expiration text box or pick a new date from date picker UI and click Save.

To revoke the current token and get a new one because it got compromised or for any other reason, you can reset the token from Files.com. Edit your Azure provider's settings and locate the Enable automatic user provisioning via SCIM? -> Token -> Reset Token. Once you reset the token and click on Save, new token will be generated and available for you to copy from the Token text box.

User fields mapping between Azure and Files.com with SCIM provisioning

If you create a user in Azure AD with the fields User name, Display name (or Name), First name and Last name and provision that user to Files.com via SCIM, the same user will be created or updated in Files.com by mapping Azure fields to Files.com as User name into email, First Name and Last Name combined into Full Name. We ignore Display Name and other fields from Azure AD.

Just-In-Time (JIT) Provisioning

JIT Provisioning works by creating user records on Files.com upon their first successful login. This method is easier than SCIM, however, it suffers from one major limitation as below when used with Azure AD.

Azure AD erroneously communicates Group Names as their Group IDs rather than the actual Group Name. This means that users will be provisioned with a list of groups that shows up as UUIDs (long strings of characters). These groups will work, but they won't be easily understood.

Some customers use our API to retroactively rename those groups, however, this is not a clean solution. We strongly recommend SCIM provisioning instead if you need to provision group memberships from Azure AD.

This is a limitation of Azure AD itself, and not Files.com. JIT Provisioning works properly on Files.com for other SAML providers, including Okta, Auth0, and OneLogin.

JIT Provisioning will work if your Azure AD Users aren't members of any Groups, or if you disable Group provisioning via SAML.

Migrating Users from Active Directory/LDAP to Azure AD SSO

For Site Administrators currently using Active Directory/LDAP and needing to migrate their users to Azure AD SSO, we recommend the process below.

Before migrating, be aware that Azure AD SSO authentication with a password is only supported for browser-based sessions, or the Files.com Desktop app. SFTP and API authentication are supported using SFTP Keys or API Keys.

Set up the Azure AD SSO provider (SAML) alongside your existing Active Directory/LDAP SSO provider. Test the functionality with an existing Active Directory/LDAP user by updating their Authentication method to Azure at User Accounts -> Users -> [Username] -> Authentication. Verify that the user can successfully log in using the Sign in with Azure SSO button. After confirming Azure SSO works for a single user, update the authentication method for the remaining Active Directory/LDAP users to Azure. If dealing with a large user base, consider using one of our SDKs to script this process, and don't hesitate to reach out if you need assistance. Once all users have been updated to use Azure authentication, you can safely remove the Active Directory/LDAP SSO provider.

Differences Between Active Directory/LDAP and Azure AD After Migrating Users

After migrating users from Active Directory/LDAP to Azure AD there will be some differences in behavior on the Files.com platform:

Troubleshooting

If you encounter issues with the username not updating automatically after a change in Azure AD, review the following steps for a resolution.

Username Changed in Azure AD

If a username has been changed within Azure Active Directory, the username change may not automatically update the username of the associated Files.com user. There are two easy ways to fix this.

In Files.com, a Site Administrator may update the user's account to match the username within Azure AD. Alternatively, this can be completed within the Azure account by an administrator.

To address this, sign in to your Azure portal, navigate to All services -> Enterprise applications, choose the relevant application where the Files.com user is located, go to the provisioning configuration page, select Provision on demand, input the updated username, and click Provision at the bottom of the page.

When updating either the username or email address in Azure portal, it is considered best practice to change both values simultaneously to ensure they match. This approach helps prevent data mismatches on Files.com and avoids potential login issues.