Overview
The Microsoft Online service within Atria has been designed from the Ground Up with Customization and flexibility in mind.
This means, that it can likely cater with most configuration scenarios you may come across with Microsoft Online Services.
By configuration scenarios - specifically this is related to Users and Authentication methods.
AzureAD / Microsoft support many different configurations which impact the way users are managed in Microsoft 365.
We currently support the below
-
Stand-Alone Azure AD (Cloud Only Microsoft 365 Users) - the simplest and default configuration.
-
Microsoft Active Directory Federation Services (ADFS) - where one or more domains are configured for authentication via an external federation service.
-
Microsoft Azure Active Directory Connect (AAD Connect) - which automates synchronisation between Active Directory and Azure Active Directory.
-
Third party Identity Services such as Citrix Netscaler or Okta - which behave similarly to ADFS
If there is anything outside of the above that you use for user management in Office 365 that binds to users and makes them Immutable - Please reach out for confirmation from us about supportability.
With each of these scenarios - You can even have a combination of them! I.e. Using Okta + Azure Active Directory Connect.
The Atria "Sync Policy"
The "Master Directory"
Atria is able to synchronise user accounts from Azure AD into Atria, Atria uses the Master Directory setting to determine priority for any conflicts. The setting only has an impact when users are being synchronised into Atria.
For Cloud Only customers who don't consume on-premise services from yourself, it's safe to assume that Azure AD is likely the best source of truth for user properties, which we call as
AzureAD Master
If the customer consumes on-premises services from you, or if Azure AD accounts have been manually created without a full set of information, Atria will likely already have the most valid and up to date information, this would be recommended as
Atria Master
Note that this configuration setting only applies to User Properties such as Phone and Address, not mail delivery or system "Impacting" properties such as Proxy Addresses or Primary Email Addresses - These will always be taken directly from Microsoft365 if the user is Mail Enabled.
For more information on sync policy configuration settings , please read here -
https://support.automate101.com/portal/en/kb/articles/synchronizing-atria-with-microsoft-online
The Atria "ADFS Policy"
As outlined above, there are multiple ADFS provider options - The ADFS Policy is used to store these settings, this allows you to re-use the configuration across customers.
With ADFS Being configured, we handle the create/update of the user in Active Directory and then apply changes directly in Azure AD - once complete, the users are correctly linked. The user can logon to any M365 service and be authenticated via ADFS.
Configure the ADFS Policy with the relevant fields as described in the page (Located at Services > Microsoft Online > ADFS Policies) - We've got a full guide outlining this step here -
https://support.automate101.com/portal/en/kb/articles/configuring-microsoft-online-with-adfs
In this guide, we configure Microsoft ADFS, but this will be similar for other Identity Providers such as OKTA.
Creating Customer Plans & Policies
Below, we can see that there are up to 8 configurations to cover the majority of scenarios you may face.
The Customer Plan contains a Sync Policy and optionally an ADFS policy. Our recommendation is to create a short list of standard customer plans with your base configurations, and then override these for individual customers.
For example, if each customer had their own ADFS/OKTA deployment then you might have one Generic "ADFS Standard" Customer plan which is used for all ADFS customers, and a specific ADFS Policy for each customer, when the customer is provisioned within Atria, you would create a new ADFS Policy for the customer, then override the Customer Plan "ADFS Policy" setting.
Use the flow diagram below, to determine the configuration you need to apply when onboarding a customer.
These will then be used to create the customer plans.
Customer Plan / Configuration
|
End Customer Scenario
|
Azure AD Connect + ADFS + Azure Master
|
A Customer with a physical On-Premise Domain Controller with AAD Connect + ADFS
|
Azure AD Connect + ADFS + Atria Master
|
A Customer consuming on-premise shared services with AD Connect + ADFS
|
Azure AD Connect + Azure AD Master
|
A Customer with a Private Domain with Azure AD Connect
|
Azure AD Connect + Atria Master
|
A Customer with the Legacy O365 Service, or has a AAD Connect service pointed at the Shared Directory
|
|
A Customer with an External ADFS Application such as Okta or Citrix Netscaler
|
|
A Customer who has Microsoft ADFS with the Shared Directory
|
Default Policy + Azure AD Master
|
A Cloud Only Customer who is being on-boarded to Atria for the first time
|
Default Policy + Atria Master
|
A Customer that existed in Atria with services or identity, but has moved to Microsoft 365
|
With these customer plans, you can likely suite most scenarios that a customer has. By this, you can then easily select the Customer Plan from the Dropdown when provisioning Microsoft Online to synchronize the customer
What is AzureAD Connect? Is this the Nightly Sync Process?
Azure AD Connect also known as Azure Active Directory Sync or DirSync is a tool provided by Microsoft to sync an Active Directory with a Microsoft 365 Tenancy. This enables properties and passwords to be kept in syncronisation. This is an agent which is installed then targeted at an OU on a Active Directory Domain. This is an external product to Atria provided by Microsoft.
The Nightly sync Process, which is also known as Azure Sync or "Azure AD Sync" is an Atria function that retrieves User Properties from Microsoft 365 and updates your local Active Directory. This can be used across multiple tenants and does not require multiple agents for multiple directories. This sync process runs nightly on the Atria Provisioning server. This Nightly Sync process is similar to Azure AD Connect, but does not have password synchronization from Microsoft 365, it will only push passwords up when reset directly in Atria.
What is ADFS?
ADFS is Microsoft's Active Directory Federation Services. This is a Single Sign On solution provided by Microsoft to authenticate users against Active Directory for Applications that can't use the typical Windows Authentication.
This gives you the ability to have applications such as Microsoft 365 to use Active Directory for authentication - This means that you don't have a password in Azure Active Directory, and apply local domain policies to control users and access. This also enables you to enable third party tools such as Okta, Duo or Citrix NetScaler to enforce Multi-Factor Authentication against Active Directory Authentication attempts.
What do you mean by Default Policy?
The Default Policy is the default policy configured when you Provision the Microsoft Online service - This should be named "Tier 1 Provider" or "Tier 2 Provider" which specifies which "Tier" of Microsoft CSP you are.
Can I change between Sync Policies?
Yes - Sync Policies can be changed on the fly, this will then mean for each future Synchronization or in the case of Azure AD Connect and ADFS, if this is enabled or disabled, user provisioning will interact in a different way to meet the requirement(s) of user changes.
What's the migration steps if I want to remove a customer from a policy?
For moving a user from one policy to another, such as from Tier 1 to AD Connect, you can simply change the customer plan or change the properties of the current customer plan. There is no migration or downtime for the customer.
I have a scenario that isn't listed - Can I get assistance on this?
Definitely! If you have a scenario you don't think falls into these boxes, or need further advise based on the scenario your customer is in, or if you need anything else - please reach out to our friendly support team.