By most of the companies I know or I was working with, there are two scenarios when I was speaking with them about the cloud and Office 365.
Number one: They have an existing business on-premise, which is working mostly well, but the lifecycle of the hardware and software version is reached.
Number two: Startup companies or companies who have a greenfield concept.
However, if we have the first information about the company, we need to make a little bit of consulting. In each case it makes sense to know the expectation of the IT manager who is responsible for their companies IT. This helps to plan the new environment, to destroy myths and to plan the way of migration.
For companies who already have an on-premise environment, we need to think more about than for “greenfield” companies how to go. By greenfield challenges the decision is fairly easy to make. Usually the business has no desire to deploy any on-premises IT infrastructure, except perhaps some basic printer sharing or local file storage, and so there is no on-premises Active Directory to consider.
However, if we talk now about organization with existing on-premises infrastructure, we can use any of three identity models which will be shown now below!
To decide which is the right one, depends about their long term plans, which we have discussed in the consulting meeting with IT management of the company.
So let’s start with the three options…
#1 – Cloud Identity
In the Microsoft world if we talk about cloud identity, that means that the Azure Active Directory becomes the source for the organization and user accounts for each person in the organization exist in the cloud. The Azure AD identities are used by Office 365 services like Exchange Online, and can also be used to sign on to third party services that support federation with Azure AD such as the Adobe creators suite ,Salesforce and/or Umantis.
To understand the graphic, here is a step by step explanation:
If the company user wants to make a login to the environment, he will be doing it across the Office 365 services. This because in the shown example the user has only a cloud identity. Cloud identity works well for organizations with no on-premises Active Directory, because users have a single set of credentials to remember and manage.
After a successful login, the user will be able to use all of the cloud services, which are enabled for him in the Office 365 portal. To name some examples we could use Exchange online, Sharepoint, Skype for Business, Teams, etc.
However, if the company also has an on-premise Active Directory, users can become confused. This because they have in minimum two sets of credentials. One set for authentication to the on-premise resources and one set for the cloud services.
As you can see on the graphic, users have to login to the cloud with a cloud identity and to the on-premise environment with the local Active Directory account. That might look easy, simple and understandable, but we have to remember that we do IT not just for technical savvy persons. Cloud computing is for “non technical” users still new and it is about us IT guys to bring it closer to them.
However, in the other hand, we as Admins have also a double effort to administrate the environment. One thing is to keep information like display names, phone numbers and user photos synchronized. However, there is of course also good news, a cloud identity model by itself doesn’t require IT to deploy any social infrastructure like hardware, power, Klima, storage etc.
#2 – Directory synchronization
Another way is to use the way with directory synchronization. This way is coming closer to the instances which are mostly used in the economy now days. Mostly, but still not the number one… In this scenario we also have a cloud and an on-premise environment. However, the difference in this case is, that we and our users can work in both worlds with one identity. That means less confusion for the users and less work for us. That we can go with this scenario of the directory sync, we need a directory sync tool. In the Microsoft world we use the Azure AD Connect tool for that. With AAD we are able to sync all information from on-premise to the cloud (Azure AD) we can decide which information we want to sync, and which not. If you need to know more about this Microsoft Tool, I can highly recommend you this LINK to the Microsoft article about AAD.
If we use this scenario, our users are now able to login to the cloud services with the same credentials like they are using on-premises. If we configure our AAD that he syncs the users attributes and objects, we need to configure the sync of the password hashes too. Depending on the company philosophy, we can configure it in a one way direction or two ways. If we use the one way option the users are able to change their password only in the on-premises environment, in a two way synchronization our user can change their password also on a cloud service. Both ways are optional, but at least one of it is highly recommended.
However, if for some reason the password sync will not be configured, our users will (analog to the cloud identity) have to remember multiple credentials.
#3 – Directory sync with Federated identity (ADFS)
The most recommended and used option is to use a federated identity. Similar to the directory synchronization we can use the Azure AD Connect to synchronize our objects and attributes. However, instead of using Azure AD to authenticate log-on requests, Office 365 services pass the authentication requests to an on-premises AD FS (Active Directory Federation Service) service. Using AD FS we have a service which is responsible for authenticating our users between on-premises and the cloud services.
To know more about AD FS you can follow my articles here or the Microsoft article here.
If we run the federated concept, we have some additional benefits. By handling of the authentication responsibility through the ADFS, we have no need to sync password hashes to the cloud. This helps if the company has high security policies. The ADFS environment can handle all connection requests to the cloud and other third party service that we even have the opportunity of single sign on (SSO).
The progress is easy as shown in the graphic, If the user try to connect directly to some cloud services, he will be redirected across the Proxy to the logon page of the ADFS server. There he needs to enter his on-premises credentials. After this is verified, the user will be forwarded to the cloud service.