In my previous article, I explained that hybrid cloud is primarily a management model built on identity, governance, security, monitoring and disaster recovery (DR). If I had to choose one element on which all the others depend, it would be identity. Without visibility into who is signing in where, neither a well-designed network nor an expensive security tool will save you. In this part of the series, we will explore why this is the case and how to configure identities securely while keeping them practical to use.
We already know what hybrid cloud is and why it is so important today. For a hybrid environment to operate securely and without unnecessary complications, identity is the first step. In the Microsoft ecosystem, identity is centred on Entra ID (formerly Azure AD). Together with on-premises Active Directory, it creates a common layer in which every user, device and application has a verifiable identity, regardless of whether it operates on-premises or in the cloud.
In the past, security was built on the idea of a clear boundary: the corporate network was ‘inside’ and everything else was ‘outside’. Today, people work from home, on mobile devices or from branch offices, and many applications run outside your infrastructure. Very little remains of the old perimeter.
That is why who is connecting matters more than where the user is connecting from. Hence the popular saying that identity is the new security perimeter. Compromised credentials have long been one of the most common ways for attackers to gain access to an organisation, typically through phishing or weak or reused passwords. Attacks in which the attackers don’t need the password at all are also on the rise. Attackers steal a valid session after sign-in, thereby bypassing even the second authentication factor. Verifying a user just once at the point of entry is therefore not enough. Trust needs to be evaluated continuously.
This also determines the order of operations: secure identity first, then the rest of the environment. If you do it the other way round and build security around scattered, inconsistent accounts, you end up doing many things twice and still leave security gaps.
First, let us clarify something that often causes confusion. Active Directory and Entra ID are not the same thing, and one doesn’t yet replace the other. In a hybrid environment, they operate side by side and complement each other.
Active Directory is a proven tool for the on-premises environment. It handles domain sign-in, device management through Group Policy, file servers, printers and older applications that rely on protocols such as Kerberos and NTLM. It remains essential for many corporate workloads.
Entra ID provides identity in the cloud. It manages access to Microsoft 365, Azure and thousands of SaaS applications through web protocols such as SAML, OAuth 2.0 and OpenID Connect. It also offers features not available in on-premises AD, including Conditional Access, risk-based identity protection and single sign-on (SSO) across cloud services.
Hybrid identity connects these two worlds. Users and groups from on-premises AD are synchronised to Entra ID using Entra Connect or its lighter-weight alternative, Entra Cloud Sync, which Microsoft recommends wherever it supports the required scenarios. Users then have a single account with the same sign-in credentials for on-premises and cloud resources, and IT staff no longer need to manage two separate identities. To give users true single sign-on, you also need to join devices to Entra ID (hybrid join) or enable Seamless SSO.
When connecting the two environments, you need to decide how passwords will be verified. There are three options available: With Password Hash Synchronization (PHS), the passwords themselves are not synchronised to the cloud. Instead, their hashed representations are synchronised, so sign-in authentication is performed directly by Entra ID. This is the simplest option to operate, and cloud sign-in continues to work even if the on-premises environment is unavailable. With Pass-through Authentication (PTA), not even the password hash is sent to the cloud. A local agent verifies the password against on-premises AD at each sign-in. Organisations choose this option when, for security or regulatory reasons, they don’t want any form of password stored in the cloud.
The trade-off is that cloud sign-in then depends on the availability of local servers and their connection to the cloud. The most complex option is federation through AD FS, and Microsoft now recommends it only where there is a specific reason to use it. For most organisations, PHS is a sensible default. The decision should, however, be based on your environment and on what you can operate reliably over the long term.
In practice, Entra ID plays several roles in a hybrid environment. Together, they form a single identity layer covering both on-premises and cloud environments.
The aim is for every user to have a single identity. Once Active Directory is connected to Entra ID, accounts are synchronised to the cloud and users no longer need separate credentials for on-premises and cloud resources. IT staff have less administration to do, users have fewer passwords to remember, and no one has to work out which of two accounts is the right one.
This is where Conditional Access comes in: policies that determine the conditions under which an identity can access an application or data. In the cloud, it takes over much of the role once played by the network perimeter. At sign-in, it assesses not only the password but also the context: who is signing in, from where, on which device, whether the device is managed, and how risky the sign-in appears to be. Based on that, it then allows access, requests additional verification or blocks access. An ordinary user in the office will barely notice the policies, while a suspicious sign-in from an unfamiliar device will be challenged. Conditional Access protects access through Entra ID. On-premises resources that authenticate through Kerberos or NTLM need their own protection.
One detail is often underestimated in practice. Legacy authentication protocols don’t support a second authentication factor, so policies requiring MFA don’t apply to them. Microsoft has already disabled them to a large extent in Exchange Online, but they still persist in many environments. Blocking them is an inexpensive measure with a significant impact.
Multi-factor authentication (MFA) is one of the most effective and least expensive measures against account compromise. A password, even a strong one, is a single point of failure. A second factor, such as an app, a hardware security key or biometrics, significantly reduces the likelihood that an attacker with a stolen password will succeed. However, authentication methods vary considerably in their level of security. SMS codes can be bypassed, and even a standard approval prompt in an app will not withstand a well-prepared phishing attack. Phishing-resistant methods, such as FIDO2 security keys, passkeys or Windows Hello for Business, can withstand such attacks. In a hybrid environment, MFA should be standard for all users, not just administrators.
Accounts with elevated permissions pose the greatest risk, and attackers target them first. That is why the principle of least privilege and Privileged Identity Management (PIM) are used. Users don’t hold permanent administrator rights. They request them for a specific task, go through approval if required, and lose them automatically after a set period. Everything is recorded in an audit trail. If an attacker takes control of such an account, they will usually find no active elevated permissions assigned to it. In a hybrid environment, there is another important rule: Entra ID administrator accounts should be cloud-only and should not be synchronised from on-premises AD. This prevents a compromise of the on-premises domain from automatically spreading to the cloud.
Access management is closely tied to the lifecycle of access rights, from onboarding to departure. A new employee should automatically receive access rights based on their role. When their position changes, old permissions should be removed and new ones granted. When they leave, their account should be locked immediately and any active sessions revoked, rather than waiting three months for someone to remember to do it. Active accounts belonging to people who left the organisation long ago are among the most common findings in access audits.
Identity cannot be configured overnight. However, the process can be broken down into three steps, and early results, such as rolling out MFA across the organisation, can be achieved relatively quickly.
The first step is to take stock and clean up. Map existing accounts, groups and permissions, identify inactive and privileged accounts, and clean up on-premises Active Directory before synchronisation.
The second step is to set up the foundations: connect to Entra ID, enable MFA for all users, block legacy authentication protocols and create the first Conditional Access policies, initially in report-only mode.
The third step is enforcement and ongoing management. Enforce the policies, establish regular access reviews, tighten privileged account management and gradually move towards passwordless sign-in, for example using passkeys or FIDO2 security keys.
The work doesn’t end there. The organisation evolves, people join and leave, and new devices and applications are added. Identity settings must evolve accordingly. Remember to factor licensing into your plans: Conditional Access requires Entra ID P1, while PIM, risk-based policies and access reviews require P2 or Entra ID Governance.
Identity management should be one of your priorities if several of the following apply:
If I were to sum up the above in one sentence, it would be this: in a hybrid cloud environment, everything rests on identity. Security, governance, monitoring and disaster recovery work well only when you know exactly who is who, what they are authorised to do and under what conditions.
In the Microsoft ecosystem, you have a set of tools that work together: Entra ID, Conditional Access, MFA and privileged access management. You don’t need to introduce them all at once. It’s better to proceed step by step and understand why you are taking each one.
If you already use Microsoft 365, you probably have some of the foundations in place and can build on them.
If you are interested in this topic, read more on our Soitron blog. In the first article on hybrid cloud, I explained what hybrid cloud actually is and why it is worth focusing on. In this second article, I have explored identity. In the next article, which is coming soon, I will focus on networking and connectivity, looking at how to connect an on-premises environment to the cloud securely and reliably.
We are in the process of finalizing. If you want to be redirected to our old version of web site, please click here.
