The recent wave of ransomware attacks means that it is necessary for organizations to reassess their security strategies. User identities can be the most vulnerable access point. Password synchronization between your AD and the cloud can be an effective way of protecting them. Read on to find out how to secure your business against potential threats.
The internet has become a dangerous place and at the same time, it’s established our new perimeter. With this change, security is one of the main concerns of modern organizations.
Don’t get me wrong – it was always a concern, but right now it is usually the number one issue raised by the companies when we start talking about leveraging cloud-related projects.
It is YOU who’s in charge of your company’s security. You’ve created its perimeter security, put controls on the network, created security policies. You took care of it all.
And now – someone wants to compromise it and put your users in the cloud! As well as your resources!
What the hell!
Identity is the new perimeter!
I’ve stressed it many times and I will stress it again. You can’t rely on standard measures alone these days. User identity is the new control plane and your perimeter. This is what stands between your resources and applications, and in most cases, it is also what protects your organization from being compromised.
It is much easier to break your user’s account than it is to break your network perimeter.
Therefore, we need to protect user identities. How are they secured? Usually still with passwords. We also have a few additional weapons in the arsenal which we have covered here, such as MFA, conditional access and so on.
Passwords are still the frontline of user account protection.
In this article, based on our experience of projects and customers’ environments, I will provide you with all the answers you need to make the right and well-informed decision about approaching this new reality.
I will also make the case for password synchronization from a new and unexpected angle, which is a direct result of one our customers’ experience in the wake of the NonPetya world.
In the end, I will give you three reasons why password synchronization might be beneficial to your organization right now.
“We need user passwords.” Really, DO YOU?
In our cloud projects, be it Office 365 deployment or Azure application, one of the first areas to address is setting up on-premises-to-cloud authentication and authorization.
To put it simply – let your users access cloud resources.
For that we need to establish two elements:
- Synchronize your users’ identities and attributes – this is easy, most organizations will default to using AAD Connect, the Microsoft “bridge” for user synchronization
- Establish a way for users to authenticate when accessing cloud resources – here is where the rocky road starts.
Identity information synchronization is usually easier to get through the organization and policies:
- It can be narrowed down to a selected list of attributes
- There is always a discussion around privacy and data location – do remember to choose your tenant location wisely (Mistake #1: Location, Location, Location).
Now that we have it covered, it’s time for the authentication part.
What choices do we have?
There are four options you can choose from:
- Cloud-only account – users have separate passwords to cloud accounts:
- Pros: It looks easier from the security standpoint, no passwords are synchronized, no connection between on-premises and cloud security.
- Cons: It takes all the hell of managing additional user passwords and drops it directly upon you and your IT department. Now handle it!
- Federated access – authentication goes to a federation server on-premises:
- Pros: No passwords in the cloud, no synchronization, you keep all the keys in your kingdom!
- Cons: You need to put additional servers in place and plan for high availability; losing access to the federation service means no access to the cloud.
- Password synchronization – your passwords are “magically” the same between on-premises and the cloud.
- Pros: Simple, users know their passwords. No additional servers.
- Cons: WHAT!? My users’ passwords in the CLOUD! Are you NUTS!?
- Pass-through authentication – this is neat, you have access to the cloud using on-premises passwords but without synchronization.
- Pros: Easy life and setup with no compromise to security.
- Cons: Still depends on access to on-premises infrastructure to work. Not supported by all possible clients.
Let’s ditch the cloud-only accounts – no one needs additional passwords, we have too many of them. The other three options look viable.
Two of them depend on the on-premises infrastructure. Password synchronization is independent from it – at least from the point of sync to the next password change.
Which one to choose?
If you go with password synchronization, is it safe!? Why would you want to go with it anyway?!
What we see among our clients is that more and more organizations are choosing either password sync or, gradually, pass-through authentication over federation approach.
Are they serious!? Password synchronization?
This is the usual reaction when I start this discussion with our customers.
No, it is not going to happen. Maybe others, but we are not doing it. Our passwords in the cloud! You are joking!
First of all, it is never your password that goes to the cloud. It’s the password hash! There is a huge difference between the two. The password hash is obtained by calculating a value from the original password with a mathematical function.
If done right, there is no way to derive the original password from hash. Or at least it is hard and time-consuming – which in practical terms means, no way!
Your local AD stores passwords as hashes as well.
But hey, isn’t hash used in the PASS-THE-HASH attack? If I sync my hash to the cloud, can it be used against my AD?
You’ve got it right regarding Pass-the-Hash, but actually, the hash in AD is not the same as in Azure AD (cloud). The process is slightly different:
- The on-premises password is obtained by AAD Connect on-premises which hashes it and sends to the AAD. AAD receives a strongly hashed version of your original AD hash.
- Upon receiving this hash, AAD encrypts it (the received hash of a hash) and then stores it locally in its database.
Lots of hashing on the way. This is all to ensure:
- Your password never crosses the network in a clear format, it is always the hash of a password which is transferred
- Password hash in the cloud is different than the one stored in your on-premises AD, but they are derived from the same password.
Sean Dubey covered this entire process in detail in his perfect blog post (soon to be extended into a full article) – make sure to check it out for details.
So, password synchronization is actually a safe process of password hash synchronization. Its name might mislead you to think that it is the password which is synchronized. But it is not!
Password hash synchronization just sounds too scary!
It has one key advantage over other methods – once the password is synchronized, it works completely independently from the on-premises environment.
Is it really an advantage?
Here is where we come to our customer case and the not-so-obvious case for password (hash) sync.
Surviving the NonPetya apocalypse!
Have you seen the The Walking Dead TV series? Or Mad Max? They both have one thing in common – the characters in these movies need to survive in a post-apocalyptic world.
What is the equivalent of an apocalypse in IT environment? One of our large customers recently wrote their own definition of it, when all their resources were stricken and effectively destroyed by the NonPetya strike.
Anything that was not damaged, was switched off to prevent the further spread of NonPetya in the network.
All. Null. A complete IT BLACKOUT!
Can you imagine it? Everything gone, including all your Active Directory resources. You have nothing left!
Actually… not quite. The business still had its Office 365 and Azure AD up and running in the cloud.
They used AD FS (federation approach) but luckily, just shortly before the NonPetya apocalypse strike, they have synchronized their passwords (as hash) to the cloud Azure AD.
What happened next?
After NonPetya wiped out their network, they were still able to give employees access to cloud resources with the same passwords and enable communication flow. It was a crucial thing for recovery and keeping the company afloat at that moment.
This might not be the intended use of password synchronization, but you have to admit that it is handy. And actually, it cuts all the ties between the on-premises environment and the cloud environment, while still keeping it easy to use for users.
And speaking of easy to use – I have not mentioned this yet, but the new Azure AD feature, seamless single sign-on, works with synchronized passwords as well! Neat!
Three (not so obvious) reasons to synchronize passwords to the cloud
I hope you have all the knowledge right now about what password synchronization is and what it means for your organization.
To make sure you are FULLY prepared for a discussion and decision, I will provide you now with three additional benefits of syncing passwords to the cloud.
- Federation service fall-back: Federation services are nice and provide SSO experience for users. But what if they fail and you need time to recover? You can have password synchronization enabled together with federation services and if your AD FS fails, then you can quickly fall back to password-based auth.
- Enabling seamless sign-on before switching to pass-through authentication: Pass-through authentication is a new capability of Azure AD with AAD Connect. It also enables a new feature called seamless sign-on. Before you test and deploy it, you can synchronize passwords to the cloud and then enable seamless sign-on.
- Being prepared for your own ITpocalypse: It might happen. It happened to many companies recently. In more than a few cases we know, cloud services were crucial to recovering the systems quickly to some degree. It is wise to think about how it will help you recover in case all other services are lost!
The final thing to remember
Word of advice here – if you do enable it, then make sure that you are taking the security of your AAD Connect infrastructure seriously. And that you protect its service account and access to the service. It is handling crucial operations of receiving and re-hashing your AD password hash.
If someone takes over the service account, they will gain the privilege to obtain these hashes from your AD and can abuse them.
I hope this article will help you in your daily work and discussion with your peers.
If you have any more questions related this subject, then feel free to drop me a question in the comments or get in touch directly!