Modern Active Directory: Entra ID Hybrid, AD CS, ADFS

You already cross this boundary every day. When you open your work email in the browser, join a Teams call, or sign into a cloud app with your company account, you are using your Active Directory identity out in the cloud. The directory you have spent this module studying no longer stops at the on-prem domain, and an attacker knows it.

This sub adds the modern pieces a defender now has to include: hybrid identity with Entra ID, the certificate services that have quietly become a major attack surface, and the federation services that bridge to the cloud.

For most of its life, Active Directory was a self-contained, on-premises system. That is no longer the typical picture. The directory now reaches into the cloud and leans on add-on services that carry their own serious exposure, and all of it is fair game for an attacker. Take the three pieces that matter most.

Hybrid identity and Entra ID

Most organizations now run a hybrid identity: the same person has an on-prem Active Directory account and an Entra ID account in the cloud, and the two are kept in step by a synchronization service that runs between them. That is what lets one work account open both a file share down the hall and a cloud application on the other side of the world.

How that link is built shapes the risk. In the most common setup the sync service copies a protected form of each user's password into the cloud so the same password works in both places; in others the cloud checks the password against on-prem in real time, or hands authentication off to a federation server entirely. Each choice has different failure modes, but they share a theme: the on-prem and cloud identities are bound together, so weakening one weakens the other.

The cloud also has its own most-privileged role, the Global Administrator, which is tier zero for the tenant in the same way Domain Admins is for the domain.

The seam between the two is where modern attacks pivot. An attacker who compromises the on-prem domain can often reach into the cloud tenant, because the identities and sometimes the credentials flow upward, and the reverse can happen too. The synchronization service is itself a prize: the account it runs under holds powerful rights on both sides, which makes it tier-zero-adjacent and a favorite target. A defender has to treat on-prem and cloud as one connected estate, not two separate problems owned by two separate teams.

The directions are worth being concrete about. An attacker who reaches the on-prem sync server can often capture or replay what flows through it and step into the cloud tenant. Going the other way, a compromised cloud admin can in some configurations push changes or credentials back down toward on-prem.

Neither direction is guaranteed, and both depend on how the hybrid link was built, but the defender's posture is the same: assume the seam is crossable and watch both sides for an identity appearing where it should not. Conditional access policies in the cloud are one of the main levers for making that crossing harder, constraining where and how an identity can be used even when its credential is valid.

The practical consequence is about where you look. The on-prem attacks in this course leave evidence in the Windows Security log on the controllers, but the cloud half of an intrusion leaves its evidence in the Entra ID sign-in and audit logs instead. An investigation that follows an identity across the seam has to follow the telemetry across it too, which is why this course, though centered on the on-prem domain, includes the hybrid pivot rather than pretending the boundary still holds.

It also changes the skills a defender needs. Reading an on-prem intrusion means knowing the Windows Security log; following it into the cloud means knowing the Entra sign-in and audit logs, which record different things in a different shape. The course keeps its center of gravity on-prem, where the foundations are clearest, but it points across the seam often enough that you will not mistake the edge of your logs for the edge of the attack.

Active Directory Certificate Services

Active Directory Certificate Services is the on-prem public key infrastructure: it issues the digital certificates an organization uses for things like authentication, secure email, and encrypted connections. Many environments turned it on years ago for one application and have not thought hard about it since, which is exactly the problem.

A quick orientation helps. At its center is a certificate authority, the server that signs and issues certificates, working from templates that define what each kind of certificate is for and who may request it. In a healthy deployment those templates are tight and the authority is guarded like the sensitive system it is. In a neglected one, a template left too open or an authority left too reachable turns the whole service into a liability, and because certificates feel like dull infrastructure, that neglect is common.

The reason it matters is that a certificate can be used to authenticate, and a misconfigured certificate template can let an ordinary user obtain a certificate that identifies them as someone far more privileged. Where that misconfiguration exists, a low-privilege user can escalate to a tier-zero identity in a single step, without cracking a password or abusing a delegation, simply by asking the certificate authority for the right certificate. That family of misconfigurations has become one of the most reliable escalation surfaces in modern Active Directory.

Researchers catalogued these template and configuration flaws as a numbered family, and the names recur in real findings, but the detail matters less right now than the shape: the certificate authority will issue what its templates permit, and if a template permits too much, the authority becomes an escalation engine that hands out admin-grade identity on request.

The authority server itself is also a prime target, because controlling it means controlling what gets issued. Both the templates and the issuance belong on a defender's list, and certificate issuance does leave events you can watch.

Certificates carry a second danger: they are durable. A certificate is valid for its lifetime regardless of password changes, so an attacker who obtains one has a credential that survives the usual response of resetting passwords. That makes a certificate-based foothold a persistence mechanism as well as an escalation, and it is why certificate abuse is both serious and easy to miss, because nothing about a valid certificate looks wrong unless you know what to check.

This durability is what makes certificate abuse so awkward to evict. After a compromise you reset passwords, perhaps reset the krbtgt key, and feel you have closed the doors, but an attacker holding a valid certificate still walks straight in until that certificate is found and revoked. Knowing to look for issued certificates, and being able to revoke them, has to be part of any serious response, which many playbooks learned the hard way.

Active Directory Federation Services

Active Directory Federation Services, or ADFS, is the older way organizations extended their identity to external and cloud applications. It is a server that issues security tokens vouching for a user, so that a third-party or cloud service will accept the company's authentication without holding the password itself. It made single sign-on to outside services possible before the cloud directory matured.

ADFS is being superseded by native Entra ID methods, but it is still present in many environments, and where it lives it is a crown-jewel target. The reason is the token-signing key: ADFS proves its tokens are genuine by signing them with a private key, so an attacker who steals that key can forge a valid token for any user, including an administrator, and walk into the federated applications as them.

This forged-token attack, often called Golden SAML by analogy to the golden ticket, bypasses passwords and even some multi-factor checks, because the application trusts the signature, not the login. An ADFS server, and the key it holds, therefore belongs firmly in tier zero.

Two further points carry forward. First, because a forged token is trusted on its signature, this kind of attack can sail past multi-factor authentication, since the application never sees a fresh login to challenge, which is exactly what makes it so dangerous.

Second, the underlying idea did not disappear with ADFS: the cloud has its own forms of token theft and abuse, where stealing a valid session token lets an attacker ride an already-authenticated session. The specific server changes, but the lesson, that whoever can forge or steal the proof of identity bypasses the login entirely, holds across on-prem and cloud.

Holding the modern picture

The boundary you studied earlier in the module has moved outward. On-prem Active Directory is still the core, and most of this course lives there, but it now sits inside a larger identity fabric. Hybrid identity ties it to Entra ID, so a compromise can pivot between on-prem and cloud and the evidence splits across two sets of logs. AD Certificate Services adds a fast, durable escalation surface that many organizations run without hardening. ADFS, where it remains, holds a signing key that forges trust itself.

For a defender, the takeaway is one of scope. The attacks in the coming modules are mostly on-prem, because that is where the foundations are clearest and where the telemetry is richest, but you carry forward the awareness that the directory does not end at the domain edge.

When an on-prem compromise suddenly shows up in cloud activity, when a certificate authenticates an account that should not have one, or when a federated login arrives without a matching authentication, you will know you are watching the modern seams these pieces created.

Why does an on-prem-centered course spend a sub here? Because you cannot scope a defense to a boundary attackers no longer respect. Even if your daily work is the Windows logs, the intrusion you investigate may begin in the cloud, escalate through a certificate, or persist on a federation key, and recognizing those moves starts with knowing the pieces exist. You do not have to master each here; you have to stop being surprised by them.

That completes the components and the context. One short sub remains in this orientation, and it ties the whole structure back to the ground it runs on: the difference between Active Directory's logical model, the domains and forests you have been picturing, and its physical reality of sites, controllers, and replication. After that, Module 1 begins the hands-on work of reading the evidence.