The decision has been made. Your organization is going to deploy Office 365. Let me tell you — cloud security is a SERIOUS game. I’m speaking from experience — and I want to share it with you, to make your life easier.
So here’s your detailed guide on what to do and what to avoid BEFORE moving to the cloud.
We’ll be talking about data quality and governance, its seamless synchronization and we’ll break down the perfect strategy for building your hybrid identity and authentication as well, and even more.
Let’s get started.
You are sitting at your desk, looking at a network diagram with all the domain controllers, probably Exchange servers and other services you’ve built over the years with your team.
Here comes the first question – where to start? What do we need to do?
The good news is that you are not the first one to have such doubts. Even better news – I have helped plenty of our customers with securing their migration to the cloud, so I am ready to share some lessons learned from various projects.
Let’s focus first on planning the steps to provide your users with the best possible experience during this journey to the cloud. And let’s make it turbulence-free! The ultimate goal is to have your cloud services integrated and secure, right?
In the first part of this puzzle, we’ll start with a typical case – imagine a company with an existing on-premise infrastructure based on Active Directory. Your users are logging on with AD credentials and then on-premise Exchange or another communication service.
Yes… whatever your perception might be, there are still other services around. So far we have helped our clients to switch to Office 365 from their custom hosted mail systems, Linux-based ones and Lotus Notes as well. At Predica we have moved from Google Apps to Office 365.
What my experience tells me is that most of the organizations will fall into this scenario, but the following ones may also be applicable:
To build your hybrid identity services for Office 365 you need to address three key elements:
Let’s handle these one by one.
Did I write tenant? Is it a new word? Well – yes. And if you are not familiar with it, you will be as soon as you enter the realm of cloud services. The tenant is your instance of the directory in the cloud. That is where your user’s data and all the other Microsoft online services will reside.
So how to get the data from your tenant? Let’s try synchronizing it with the existing Active Directory. How can you do this? By using Azure AD Connect (AAD Connect) tool provided by Microsoft.
Why this particular one? It is basically the most recent on the market – it will provide you with all the capabilities you need to synchronize your data.
Speaking of other tools, some of them you might have heard of earlier. Does any of these ring a bell?
Here you can find a full comparison between these tools provided by Microsoft.
It depends on what services are used. Lists of attributes for each service are different, and it is well documented. However, based on my experience from current deployments, there is the special one causing most of the problems – userPrincipalName. Or simply saying – UPN.
What is UPN? It is a string attribute in your Active Directory, which allows the user to login with their full name, like [email protected] The user recognizes this mostly as login name (which is technically samAccountName).
Why do you need to worry about it? Well, on-line service needs to know that the user belongs to your organization. Simple login name is not enough. Quick hint – there is more than one John in the world, I guess. So it requires something more consistent.
And the choice is the user’s e-mail address. When you synchronize the data from Active Directory to the on-line one, all the tools are assuming one thing – that your UPN contains exactly the reliable value to identify a user (based on their e-mail).
Why you actually don’t have to? To be honest – almost no one cared about the format of UPN, and usually, it is in the default format of AD domain name, like [email protected] (BTW – using “.local” as the domain name is a dreadful example. Why – this is a subject for another post). It’s not a big deal when most users don’t even know it exists.
The good thing is that it’s easy to fix; here is what to do:
You can learn more about the attributes synchronization and preparation while migrating them to the cloud services in this Prepare to provision users through directory synchronization to Office 365 article from Microsoft.
There is no magic when it comes to directory data – garbage in, garbage out, that’s how it works.
And this is the moment when many of our clients are turning to Microsoft Identity Manager (MIM) to ensure that information in the directory is being populated in a consistent and automated way. Especially since MIM synchronization service license is included with Windows Server – no additional cost attached.
Are you doomed to fail? Is heaven falling? No. Take it easy – it just requires some more planning and additional work.
And here are the two possible remedies:
And here you are – your users’ identities are in the cloud. The first step is completed. At this point, you might start to ask a question on how do you get into this tenant and how can your users log onto it?
No worries, I’m going to let you rest by now. But hey! Come back soon for more clues, and now… go and test. And fix after testing. And ask me for help if needed.
In the second part of our hybrid identity set up guidance, we’ll work on identity and authentication issues. So stay tuned!
I covered security in GitHub last time. But some of you likely use Azure DevOps for building your products, so let’s t...
Sometimes it feels like I'm pushing too much with security and software development, but then you prove me wrong. Rec...