How do you run one identity across on-prem and cloud?
The mistake that defines this topic is creating a second directory. A cloud account gets its own users because it was quicker than involving the identity team, and for a year nothing goes wrong. What goes wrong afterwards is that leavers keep their cloud access, access reviews cover one directory and not the other, and nobody can answer the only question an auditor asks, which is who has access to what. One authoritative source of identity is the whole objective, and everything else here is mechanism.
What does one identity actually mean?
One place where a person or a service is created and deleted, with both environments deriving their access from it. The directory does not have to be on-premise and it does not have to be in the cloud, but it does have to be singular, because the value comes from there being exactly one action that removes someone's access everywhere.
Concretely that means three things joined up: a single lifecycle where joining, moving and leaving are recorded once; a single authentication event where a person proves who they are once and both environments accept it; and authorisation that reads group membership from that same source rather than from a locally maintained list.
The third is the one that decays quietly. Plenty of estates federate authentication properly and then assign cloud permissions to individually named users, which means the directory correctly stops the leaver signing in while the permission record remains and the review report is wrong. Group-based assignment is what makes the single source actually authoritative.
Synchronise or federate, and what is the difference?
Synchronising copies identities from your directory into the cloud identity service, which then performs the authentication itself. Federating leaves authentication with an identity provider you run, and the cloud redirects to it and trusts the assertion that comes back. Both give one source of truth for who exists; they differ in who checks the password and therefore in what happens when something is down.
The availability consequence is the part worth deciding deliberately. If cloud sign-in federates to an on-premise identity provider, an outage in your data centre stops people signing in to cloud services that are themselves perfectly healthy. That is a real dependency of the least reliable component on the most reliable one, and it has caused more visible incidents than the security difference it was chosen for.
Synchronising avoids that and moves the credential verification into the cloud service, which some organisations are not comfortable with and others find preferable. The workable middle position is common: synchronise so that cloud authentication survives an on-premise outage, and use conditional access policies to enforce the controls that federation was wanted for.
Why is machine identity the harder problem?
Because machines outnumber people, their credentials are usually long-lived, and nobody offboards a service account. The employee identity problem is well understood and generally solved by products. The service account problem is solved by whoever set the integration up, in whatever way was convenient that afternoon.
The specific hybrid failure is a static key. A cloud workload needs to reach an on-premise system, or an on-premise job needs to reach a cloud bucket, so someone issues a permanent credential and puts it in a configuration file. It works, it never expires, it gets copied into a second environment during a migration, and it appears in a repository three years later. Long-lived shared credentials are the single most common finding in hybrid security reviews.
The replacement is short-lived credentials issued on the basis of what the workload is rather than what it knows. Cloud providers support federating an external workload identity so an on-premise process can obtain temporary cloud credentials by presenting a trusted token instead of holding a key. In the other direction, mutual TLS with certificates from your own authority gives the cloud workload an identity your data centre can verify, with an expiry date that forces rotation to actually happen.
| Identity type | On-premise mechanism | Cloud mechanism | How to bridge | Common failure |
|---|---|---|---|---|
| Employee | Directory account | Cloud identity account | Synchronise or federate from one directory | A second set of cloud-only accounts |
| Contractor or third party | Directory account with an end date | Guest or external identity | Same directory, with expiry enforced | The end date is set once and never re-checked |
| Administrator | Separate privileged account | Role assumed for a task | Privileged access with time limits both sides | Standing administrative rights in the cloud |
| Service account for an integration | Directory service account with a password | Cloud service principal or role | Workload identity federation, no stored key | A permanent key in a configuration file |
| Workload or application | Certificate from an internal authority | Instance role or managed identity | Mutual TLS, or a token exchange for short-lived credentials | One shared certificate for everything |
Why does the leaver process break in hybrid?
Because deprovisioning follows the directory, and anything not derived from the directory is not touched. A person removed from the identity source loses everything that federates from it and keeps everything that does not: a local account on a cloud service someone signed up for, a personal access token in a code repository, an SSH key on a virtual machine, a credential in an automation tool.
The gap widens whenever a team adopts a cloud service directly. That service was not connected to the directory because connecting it required a licence tier or an identity team ticket, so it accumulated its own users, and it will not appear in any leaver report because nothing knows it exists.
The test is uncomfortable and takes an afternoon. Pick someone who left several months ago and try, systematically, to find any credential of theirs that still functions: cloud consoles, repositories, VPN, the on-premise domain, any software as a service tool the team uses, and any key pair issued to them. Whatever you find is not a mistake by one person, it is a description of which parts of your estate are outside the identity system.
What does not cross the boundary cleanly?
The older authentication protocols. Kerberos and Windows integrated authentication assume a domain-joined machine with a line of sight to a domain controller, and applications relying on them do not simply start working because a cloud workload can reach the network. Modern cloud services speak token-based protocols instead, and the two families do not translate without something in between.
The usual bridges are a gateway or proxy that terminates a modern token and performs the legacy authentication on the user's behalf, or extending the domain into the cloud network so instances can join it. The first is cleaner and keeps the legacy dependency in one place. The second is quicker and extends a dependency you were probably trying to reduce, which is a reasonable trade if the timeline demands it and a poor one if it becomes permanent by default.
Certificates are the other thing that does not cross without thought. An internal certificate authority trusted throughout your data centre is not trusted by a cloud workload unless you distribute the root to it, and expiry of an internal certificate is a routine cause of hybrid integrations failing at an hour nobody chose. Whatever tracks expiry on-premise needs to cover both sides.
What should you check before extending access?
Five questions, answerable from what you already have. Is there exactly one directory that both environments derive from? Are cloud permissions assigned to groups from that directory rather than to named users? Does any integration between the environments rely on a credential with no expiry date? If the data centre is unavailable, can people still sign in to cloud services? And does an access review cover both environments in one report or two?
A no to any of the first three is a finding worth acting on before adding anything new, because each of them makes the next integration harder to unwind. A no to the fourth is a design decision to make consciously rather than a defect.
The fifth is the one that predicts audit outcomes. If producing a list of who has access to what requires exporting from two systems and reconciling them in a spreadsheet, the answer will be wrong occasionally, and nobody will know which occasions.
Common questions
- How do you manage identity across on-premise and cloud?
- With one authoritative directory that both environments derive from, so a single action creates or removes access everywhere. That requires three things joined up: one lifecycle for joining, moving and leaving; one authentication event both environments accept; and permissions assigned from groups in that directory rather than to individually named users in each environment. The second directory created for convenience is the failure this topic is about.
- What is the difference between synchronising and federating identity?
- Synchronising copies identities into the cloud identity service, which then verifies credentials itself. Federating leaves verification with an identity provider you run, and the cloud redirects to it and trusts the returned assertion. The practical difference is availability: federating to an on-premise provider means a data centre outage stops people signing in to cloud services that are otherwise healthy, while synchronising keeps cloud sign-in working independently.
- Why is machine identity harder than user identity in hybrid cloud?
- Because service accounts outnumber people, their credentials are usually long-lived, and no offboarding process covers them. The typical hybrid failure is a permanent key placed in a configuration file so one environment can reach the other, which never expires, gets copied during migrations and surfaces in a repository years later. Short-lived credentials issued through workload identity federation or mutual TLS remove the stored secret entirely.
- Why do leavers keep access in hybrid environments?
- Deprovisioning follows the directory, so anything not derived from it survives: local accounts on cloud services a team signed up for directly, personal access tokens in code repositories, SSH keys on virtual machines and credentials inside automation tools. The gap is widest around services adopted without connecting them to the directory, because nothing knows those accounts exist and they appear on no leaver report.
- Does Kerberos work in a hybrid cloud?
- Not without help. Kerberos and Windows integrated authentication assume a domain-joined machine with a path to a domain controller, while cloud services use token-based protocols, and the two do not translate on their own. The options are a gateway that terminates a modern token and performs the legacy authentication on the user's behalf, which keeps the dependency in one place, or extending the domain into the cloud network, which is faster and deepens a dependency you may be trying to reduce.
- How do you test whether hybrid access controls actually work?
- Pick a person who left several months ago and systematically try to find any credential of theirs that still functions: cloud consoles, code repositories, VPN, the on-premise domain, team software as a service tools, and any key pairs issued to them. Anything still working is not an individual mistake, it is a map of which parts of the estate sit outside the identity system.
