Azure Active Directory Synchronization Service

The Retarus Azure Active Directory Synchronization Service (“AAD Sync”) synchronizes customers’ directory data (email addresses etc.) from a Microsoft Azure Active Directory with the Retarus Email Security services, thus simplifying the administration of the Email Security services for customers using Azure Active Directory as integral part of Microsoft 365.

Important for customers using an on-premise Active Directory

If you are using a local Active Directory, please use the Retarus DirSync Service (Windows service) and refer to Retarus Directory Synchronization Service (DirSync).

Sync via Azure App vs. DirSync/LDAPS

There are two different ways to synchronize your Azure Active Directory with Retarus:

• Sync via Microsoft Azure App (Retarus AAD Sync App using Microsoft Graph API): Preferred way for synchronizing Azure AD with Retarus, should be sufficient for most customers.

• Sync via Retarus DirSync Service/LDAPS: Advanced option that may be used if the default sync via app does not cover all your requirements, e.g., if you need to sync “Shared Mailboxes” or if you would like to do profile mapping based on the data.

For general information about Retarus DirSync Service, refer to the dedicated admin documentation available via the Retarus EAS web portal.

See the following comparison table for choosing the way that suits your requirements best:

AAD sync via Azure App

Preferred way for synchronizing Azure AD with Retarus, should be sufficient for most customers.

Licensing requirements

In order to be able to use the service, customers need a valid licence for Microsoft Azure Active Directory including the Microsoft Graph API. This licence is normally included in all Microsoft 365 licences.

Architecture

Retarus AAD Sync Service operates via a so-called “enterprise app” inside the Azure environment. As a customer, you have to add this app to your account and grant permissions to read the required user data from your Azure Active Directory. The Retarus app doesn’t contain any source code, it only acts as synchronization interface. The Microsoft Azure “Graph” API is used to access the data.

Synchronization data

As displayed during the installation and afterwards under “details” of the Retarus AAD Sync app in your Azure account, the Retarus AAD Sync app needs following Microsoft Azure permissions to work:

• Read all users’ full profiles

• Read all user mailbox settings

• Read all group memberships

These permissions allow read-only access to a certain amount of user data, but we request and synchronize only the following data that is mandatory for the service to work:

• Domains

• Email addresses
  → Email addresses may include generic addresses like “room mailboxes” or “equipment mailboxes” defined in Microsoft 365.

• Alias email addresses
  → Alias email addresses defined in Microsoft 365 are used for the alias-to-primary quarantine mapping of Retarus Email Security. Emails sent to an alias address and quarantined are transferred to the user quarantine of the primary user address.

• Groups

Please consider the following examples of data that is not being synchronized:

• Group owners defined in Microsoft 365 are not transferred. Group addresses themselves are synchronized (as described above) and treated the same way as other user addresses.

• Dynamic distribution groups cannot be synchronized as they are not supported by the Microsoft Graph API.

• Mail-enabled public folders cannot be synchronized as they are not supported by the Microsoft Graph API. You may of course manually add these addresses to the Retarus DirFilter Allowlist in order to make sure that emails to those recipient addresses are accepted.

• Shared mailboxes cannot be synchronized as the Microsoft Graph API doesn’t offer a dedicated access permission without having to access all user emails as well. You may of course manually add these addresses to the Retarus DirFilter Allowlist in order to make sure that emails to those recipient addresses are accepted.

• Any other personal user data that could be used for the Signature/Disclaimer feature.

Implementation of the sync via Azure App

To implement the Retarus AAD Sync via Azure App, there are only a few steps to be completed:

1. Go to Retarus landing page: https://azure-sync.retarus.com.

   

2. After you read and understood the terms and conditions and confirmed this by clicking on the checkbox, you are forwarded to your Azure account where you have to log in with your Azure admin credentials.

   

3. A new window informs about the required permissions that the Retarus AAD Sync app needs in order to work correctly. By clicking on “confirm” you grant admin consent to the Retarus app.

   

4. The Retarus AAD Sync app is now listed in your account.

   

5. You are ready for synchronization; now, please contact Retarus in order to have the sync activated from the Retarus side as well.

AAD sync via DirSync Service/LDAPS

This is an advanced option that may be used if the default sync via Azure App doesn’t cover all your requirements, e.g., if you need to sync “Shared Mailboxes” or if you would like to do profile mapping based on the data.

Requirements

To use the service, you need a valid license for Microsoft 365 and the Microsoft Azure Active Directory including Azure AD Domain Services (AD DS). This may require additional licensing.

Another prerequisite is that Secure LDAP has been configured for your Azure AD Domain Services managed domain (including a valid or self-signed certificate as a pfx file). Microsoft describes how to configure this at https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-configure-ldaps..

Architecture

The AAD sync via LDAPS is based on the Retarus DirSync service running in your local environment (on premise). The service uses a secure LDAP connection to access your Azure Active Directory in the cloud, request the required user data (see below) and creates a map file that is transferred to Retarus via upload to a dedicated sftp file share. For details regarding Retarus DirSync service, please refer to the dedicated DirSync admin documentation available via the Retarus EAS portal.

Synchronization data

As described above, the sync via DirSync/LDAPS allows you to synchronize the following data:

• Domains

• Email addresses

• Alias email addresses

• Groups

• Shared Mailboxes

The solution allows you to:

• filter by attributes

• use profile mapping

• use data for Signature/Disclaimer feature

• use User-Based Routing

Please consider the following examples of data that is not being synchronized, because the data is related to Microsoft Exchange and therefore not included/available via Azure Active Directory. Nevertheless, it is possible to get the data using PowerShell; examples are mentioned below:

• Group owners defined in Microsoft 365 are not transferred. Group addresses themselves are synchronized (as described above) and treated the same way as other user addresses. Powershell command to retrieve the data:
  Get-UnifiedGroup -Identity "Consulting" | Get-UnifiedGroupLinks -LinkType Owner | Select PrimarySmtpAddress

• Dynamic distribution groups cannot be synchronized. You may of course manually add these addresses to the Retarus DirFilter Allowlist in order to make sure that emails to those recipient addresses are accepted - or use Powershell to retrieve the data:
  Get-EXORecipient -Filter "RecipientType -eq 'DynamicDistributionGroup'" | select PrimarySmtpAddress

• Mail-enabled public folders cannot be synchronized. You may of course manually add these addresses to the Retarus DirFilter Allowlist in order to make sure that emails to those recipient addresses are accepted – or use Powershell to retrieve the data:
  Get-EXORecipient -Filter "RecipientType -eq 'PublicFolder'" | select PrimarySmtpAddress

Implementation of the sync via DirSync/LDAPS

To implement the Retarus AAD Sync via LDAPS, there are only a few steps to be completed:

1. Enablement of LDAPS access for your Microsoft Azure Active Directory:
   → Log in to your Microsoft account via https://portal.azure.com, go to Azure AD Domain Services, choose Secure LDAP in the settings, and complete the configuration including your pfx file.

2. Your IPs have to be allowed for port 636 in the Network security group aadds-nsg inbound rules.

3. To perform an LDAPS query, the admin user needs to be part of the AAD DC Administrator Group.

4. For the LDAP query auth user in the Dirsync XML credential section, you can use the bind distinguished name or just the user name, example below:

   CODE

   <Credential Name="ad_export"
     Description="Connection to Azure ActiveDirectory Server"
     UserId="Your Ldap User" Password="YOUR PASSWORD"
     EnableSSL="false" Compression="OFF" UseDefaultCredentials="false"
     ProxyCredentialName="" Retries="0" HTTPVersion="HTTP11"
     AdditionalOptionName=""
   />
   
   The userID can be either
   "CN=Your Ldap User,OU=AADDC Users,DC=subdomain,DC=yourdomain,DC=com"
   or just
   "Your Ldap user"

5. Optional you can use any tool like “Softerra LDAP Browser” using your external Secure LDAP-IP to get an overview of the directory structure. The important part is stored in OU=AADDC Users.

6. To allow a successful authentication, the AuthType="NONE" needs to be used in the Servers section of the config.
   

   CODE

   <Servers>
     <Server Name=”ad_server” Description=”Default AD server”
     ServerAddress=”ldaps.domain.com” Port=”636” PageSize=”1000”
     CredentialName=”ad_export” AuthType=”NONE”
     UseDefaultCredentials=”false” />
   </Servers>

7. Retarus DirSync setup and configuration: In order to use the data for Retarus Email Security services (e.g. profile mapping, usage for email signature/disclaimer etc.), the DirSync service has to be set up (Retarus Implementation engineer) and configured appropriately.