Cloud Security Strategy Migration Moving Online? This Cloud Security Strategy Will Back Your Migration [part 1]

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.

Where are we?

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?

Cloud security – one way or another?

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:

• A single organization with a more advanced directory service structure (multiple domains within a single forest) – from the task perspective, it’s the same as with a single domain.
• A single organization with multiple AD forests or multiple organizations joining separate Office 365 services – this one might be a bit more challenging. Basic requirements to cover stay the same.  But how to get to these basics when multiple parts are moving? Here you may require some additional planning and dedicated experts’ help.

Here’s what your identity synchronization in the cloud may look like in sequence of four steps

To build your hybrid identity services for Office 365 you need to address three key elements:

• Provide the right data from your directory
• Establish the process of synchronization to keep it up to date between on-premise and cloud services
• Select the way your users will authenticate to their services (which directly influences their user experience). I’ll focus on that in the II part of this guide.

Let’s handle these one by one.

The right data for your new and shiny directory tenant.

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.

• AAD Connect supports synchronization of data from multiple Active Directory forests and also from some other sources
• It also provides in-place upgrade and fail-over configuration. And this becomes critical when you start to use more advanced options provided by Azure AD, (for instance, self-service password resets with a write-back).

AAD Connect supports synchronization of data from multiple Active Directory forests

Speaking of other tools, some of them you might have heard of earlier. Does any of these ring a bell?

• DirSync – the oldest tool provided by Microsoft. In fact not needed anymore. Not an option for you right now.
• AAD Sync – a DirSync replacement. Its support ends soon. More capable than DirSync but not providing all the options AAD Connect has to offer.
• Microsoft Identity Manager (MIM) – MIM provides a connector for synchronization of data to Azure AD, but it is not supported anymore. Advanced data transformation and scenarios are also at stake, and it supports PowerShell as well. MIM is often used to support complex scenarios of data synchronization, even if the final push to the cloud is made with AAD Connect.

Here you can find a full comparison between these tools provided by Microsoft.

What information is being synchronized to on-line Azure AD?

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:

• Get to know what your planned e-mail domain(s) in Office 365 are
• Verify that users have UPN values matching these domains. You can use Microsoft provided IdFix tool for it or a custom PowerShell script.

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.

But what if I can’t change my UPNs?

Are you doomed to fail? Is heaven falling? No. Take it easy – it just requires some more planning and additional work.

• The first question is why you might not be able to change it? Usually, it comes down to those two reasons: There is one or more application assuming the UPN as a good identity handle, and it identifies users by this value. It is a wrong assumption but let’s not go into this discussion here. From my experience and some past deployments, it might happen and stand for the blocking point. You need to check this before even considering to embrace any cloud services.
• There is another trusted AD forest that is already using the UPN suffix you also want to use. It’s less likely, but still happens. Particularly in larger organizations. UPN suffixes are used for Kerberos authentication, so in this case having the same two UPN suffixes might break a thing or two.

And here are the two possible remedies:

• In AAD Connect you can simply change the source of an attribute being synchronized to the cloud as the user identifier. You need to adjust attribute flow using synchronization rule editor.
• If you are using AD FS as an authentication method, you need to configure what is known as Alternate login ID. You will get a better overview of it when we cover it in part II.

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!