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

In the previous post, I have started to guide you through the process of defining a cloud security strategy and deploying the services in your organization. If you missed it, make sure you read it before going through this part.

We started moving to the cloud services with the directory synchronization – just to summarize the main points here:

• Your tool for data synchronization within the cloud is Azure AD Connect. You might use other tools to support it if your scenario is complicated, but this is what you should use to make the final push of information to your tenant.
• Data quality is key to your success. Remember – garbage in, garbage out!
• You may face the need to sort out UPN values. The default configuration of all tools assumes that UPN will be your user’s login name in the cloud. If you can stay consistent with this – that’s better. If not, there are some ways to work around it with Alternate login ID.

But now, how will your users get in the cloud services and to your new and shiny Azure AD tenant once they are synchronized?

We have our data in the directory. So… let’s use it!

And let’s log on. But wait… What is my password? What? Another password? Do I really need a password for this account? Do I have one already for AD?

And here you have entered a new realm of cloud identity. Congratulations! Your job just got way more interesting.

First of all, you may have two major types of users in your cloud directory:

• Cloud only users – those who are created and managed directly in a cloud service
• Hybrid identity users – they are being synchronized from on-premises Active Directory to the cloud Azure AD and their identity is managed there.

(Actually there are also other types of users in Azure AD – you can have MSA accounts as guests, B2B accounts from other tenants… but I will keep it simple for now).

Cloud only users are simple to handle. You create them in the cloud; you set their password in the cloud. And it stays there. They authenticate directly to the cloud, and you don’t have to worry about it. You can do some Azure AD logon page branding to provide them with a nice user experience.

Feel like “alone in the dark”? Don’t worry it’s just Warsaw by night!

Hybrid identity users

They are a bit more complicated, as you have multiple options for them to authenticate:

• Cloud authentication – you synchronize users to Azure AD from your on-premises directory, but you don’t synchronize password hash or provide SSO with AD FS. The password is set in the cloud, and they authenticate the same way as cloud-only users. Simple but provides a bad user experience. (Some of our clients are using this option – mostly for compliance reasons).
• Password hash synchronization – your user is synchronized to the cloud, and their password hash (never a clear password) is synchronized as well. Let me say this OUT LOUD. AND CLEAR! The password is never synchronized as plain text. And this hash is even re-hashed before being sent to the cloud. And then it is additionally encrypted before finally being stored in the cloud. After all of it is done, the user can log on to the Azure AD with the same password as to their on-premises Active Directory. It is same sign-on, not single sign-on. (Hint: if you are FIPS compliant you may want to read this part). Drawback – the user still needs to provide login and password at logon time.
• Federated single sign-on – this is an option which provides the full single sign-on experience for your users from on-premises Active Directory to Office 365. When the user is asked to authenticate, they will be redirected to your on-premises AD FS infrastructure (or other Identity Provider, as there are third-party SAML providers supported). The user will get authenticated at this provider (effectively your Active Directory) and get back to Azure AD with the token. Simple as that. There is one disadvantage though – if you don’t use AD FS or have another identity provider already in place, you need to build it before enabling this scenario. And you need to plan it for high availability.
• Pass-Through authentication – this method allows users to access cloud services with the same account name and password as in on-premises Active Directory but without AD FS or password hash synchronization. Authentication itself is actually performed in the on-premises network. This method also enables the single sign-on experience for users working within the on-premises network (for full details and current limitations make sure to read current documentation).

These are the possible authentication scenarios defined above. Source: azure.microsoft.com

With all these options, once user logs on to Azure AD in the session, they will remain authenticated among all other Azure AD-based services.

Now – what may be the right choice for you?

The answer depends on a few elements, so here you have a simple decision tree you can use to support “the one”:

• If you want to provide a full single sign-on experience for your users based on existing Active Directory credentials, then federation single sign-on with AD FS is your best shot. Remember, this will require additional hardware and configuration – on-prem or in Azure IaaS as it has to be highly available and load balanced infrastructure. And you will also need a public SSL certificate.
• If you can’t meet some of AD FS requirements (no budget for hardware, not enough VMs or you simply don’t want it), then choose password hash synchronization. It is simple and secure to implement. It provides a convenient sign-on experience with the same password for all users.
• The last resort is to go for cloud authentication for your hybrid identity users. It will require them to use another password, and it will not provide the perfect user experience. Not to mention, your helpdesk will hate you for that.

If you are interested in what others are using regarding authentication method, Microsoft has provided metrics based on their usage observation.

Here’s how Azure AD Authentications are completed out of 1.3B authentications a day

Cloud security strategy Q&A

Well, now I think you may have a few questions regarding the options mentioned above. Let’s play a quick Q&A here, to explore at least some of them.

Q: If I choose AD FS as an option and it is not available, will my users be able to log on to Office 365?
A: The short answer is NO. And this is why you need to plan it as highly available and load balanced service. A bit more extended answer is that there’s a workaround for this situation. You can set up a federation single sign-on and password hash synchronization at the same time. When your AD FS is not available, you can fall back to password synchronization until you resolve the issue. It is a manual process.

Q: Is there any other method for providing a sign-on based on current Active Directory credentials but using federated sign-on or password hash synchronization?
A: At this moment – NO. But the Azure AD team is working on it now. Keep watching our blog and you will get to know about it as soon as it gets released.

Q: What about the Alternate Logon ID? You said that there is something related to authentication?
A: I’m glad you are paying attention. When you are using the Alternate Logon ID, it means that the value (other than UPN) is sent to Azure AD as the user identifier. The user identifier is sent with the AD FS as part of the token generated by the service. Then it also needs to contain this “other” value. To do this, you need to configure rules in your AD FS to retrieve this value instead of UPN. You will find it well covered in the Alternate Logon Id configuration guide. These simple backup script for AD FS claims rules might become handy as well.

Q: The password hash synchronization… is it secure?
A: The only thing being sent over the wire between your on-premises AAD Connect and Azure AD is SHA256 hashed copy of AD hash. AD hash is retrieved using replication protocol by a Password Synchronization Agent, and this connection is also secured over a wire. And the hash stored in Azure AD is being encrypted with AES. So probably it is as secure as it can be.

Q: If the user password hash is being synchronized from on-premises AD, can the password be changed in Azure AD?
A: Good point. Yes, it can be actually. However, it will be changed in Azure AD and not on-premises AD (unless you have password write back configured). It means that the user will have two different passwords until the next time they will change the password in on-premises AD and password hash will get synchronized again.

Let’s summarize our security guide… at last!

You made it to this point – I’m soooo proud! It means you are really into this “cloud thing”. Let me then quickly recap the main points from this blog post:

1. When your starting point is an existing Active Directory, and you are moving or considering to move to an online service, there are few things you need to consider:
   1. Data quality and governance
   2. Data synchronization
   3. Hybrid identity and authentication strategy.
2. Data quality is critical. The best way to keep it is to deploy some automation and governance methods for it. But surely you will have some cleanup to do before moving it. Be prepared for it.
3. Gather information on domain names in use in your organization. You probably want to know what to configure in Office 365. And how to register them all in your tenant upfront.
4. You can have single synchronization source for your Azure AD tenant. Keep this in mind if you are managing a more complex environment on-premises.
5. Your choice of authentication method is affecting your user experience. They don’t care how their data got there, but they do care if they have to type login and password one more time. Make it easy for them.
6. You are choosing authentication method per domain in your Azure AD tenant. If you select federated single sign-on, all users in this domain will have to use AD FS (including administrator – keep this in mind!). The good news is that each domain can use different identity provider. At least this will not get complicated (or might not).
7. Have fun!

If you find these key practices useful, make sure you share them with the rest of the IT world! Do not miss out the latest news and our blog updates (I’m telling you there’s still sooo much to cover!). Get in touch!