Azure AD Connect (AADConnect) is a great tool to have a common User Identity for Cloud and On Premise Technology Infrastructure. Let us understand the Business Use Case
There is a 100 user Company which has 1 MS Exchange Server and 1 Tally Server which is also serving as Active Directory (AD) On Premise. It is now planning to move the Email to the Cloud and therefore looking at Office 365 Cloud Service. It is also considering Salesforce CRM Solution.
One of the issues which is bothering it is that if it moves Email to the Cloud there will be another User Directory created. So users will have to track their local AD user name with password and their Office 365 user name and password. Add to that, if they adopt Salesforce CRM, that will be one more combination of user name and password to track.
We can implement Hybrid Identity using Azure AD Connect. This will sync the local Identity to the Azure AD which is on the Cloud. This will ensure that the local identities are in sync with the Cloud Identity. So there will be one common identity for On Premise Applications and also Office 365. This solves one part of the problem.
Now let’s handle the issue of using Salesforce CRM. The good news is that Azure AD has the ability to federate with Salesforce and also hundreds of other Cloud applications. So using the same local Identity, the User can use On Premise Tally, Cloud based Office 365 and also Cloud based Salesforce CRM. And whenever there is a change in the local identity due to password policy, this will get synced with the Cloud Identity as well automatically.
Let’s explore the Azure AD Connect now. As you can see in the screen shot below, there are 2 options:
2.Federation with Active Directory Federation Services (AD FS)
The Password Sync is the preferred option. It will sync the password and subsequent changes made in the local AD to the Azure AD. The User then has to use the same credentials to use Office 365 and Salesforce and other Cloud Apps. This component is responsible for creating users, groups, and other objects. It is also responsible for making sure identity information for your on-premises users and groups is matching the cloud. The end-user can use the same password on-premises and in the cloud but only manage it in one location. Since it uses your on-premises Active Directory as the authority, you can also use your own password policy. If your local AD goes down, you can still access and use your Cloud Apps.
AD FS is more complex Hybrid environment. So if you are planning Hybrid Exchange for example, you need to use AD FS. This gives you a Single Sign On. But more often than not, the benefit of SSO is much smaller as compared to the complex setup. And we also need to remember that if your local AD is down, you cannot access your Cloud Applications.
You can also add or restrict certain apps to be using this feature. The screen shot below shows the list of Apps which have been setup with Azure AD. All the apps shown will have common set of credentials.
One more interesting aspect is that we could have a mix of Hybrid and Cloud only identities. Let us take a situation of a School which has say 100 fixed Office users and 500 students which change on graduation. We can create a hybrid environment where the fixed users can be creating don On Premise AD and temporary users created only on Azure AD. So the temporary users can be given access only to some Cloud Apps. Please see the snap shot below and you will notice 2 kinds of users. So this also is a very interesting Solution for certain specific scenarios.
So as we can see, using the Azure AD Connect tool, we can ensure that we have a common Hybrid Identity for On Premise as well as Cloud Apps.
To know more about Azure AD, visit the page here