Latest / The Identity Blueprint / Secure Your Infrastructure Without Service Accounts

Transcript

Secure Your Infrastructure Without Service Accounts · The Identity Blueprint

• 0:00
  SPEAKER_01: Welcome back to the Identity Blueprint.
• 0:02
  SPEAKER_01: Beyond the Domain.
• 0:03
  SPEAKER_01: I'm Ernie with Jose.
• 0:05
  SPEAKER_01: We're leaving MA behind this episode for a threat that's been sitting quietly in your environment for years.
• 0:11
  SPEAKER_01: The static service account.
• 0:14
  SPEAKER_01: We trace exactly how an attacker cracks one offline using nothing but a Kerberos ticket and a GPU, why managed identities make that attack mathematically impossible, and the real trade-offs behind Microsoft's intra-domain services.
• 0:30
  SPEAKER_01: One-way sync, zero admin rights, and yes, it still generates NTLM hashes.
• 0:36
  SPEAKER_01: We also cover the identity aware gateway alternative and the one thing it can never actually replace.
• 0:42
  SPEAKER_01: If you've still got a service account with password never expires checked, this episode is for you.
• 0:48
  SPEAKER_01: Let's get into it.
• 0:50
  SPEAKER_01: Imagine you've just spent um like three years and maybe$10 million migrating your organization to a pure cloud native utopia.
• 0:59
  SPEAKER_00: Oh, yeah.
• 0:59
  SPEAKER_00: The absolute dream scenario.
• 1:01
  SPEAKER_01: Right.
• 1:01
  SPEAKER_01: The dream, your new servers are beautifully elastic, they're spinning up and down based on demand.
• 1:07
  SPEAKER_01: Your security model is entirely zero trust.
• 1:11
  SPEAKER_01: So you go to flip the final switch, pop the champagne, and suddenly your company's most critical supply chain application, which was written in like 2008, completely crashes.
• 1:21
  SPEAKER_00: Just totally falls apart.
• 1:22
  SPEAKER_01: Exactly.
• 1:22
  SPEAKER_01: Why?
• 1:23
  SPEAKER_01: Because it's screaming into the void looking for a physical Active Directory server that, well, no longer exists.
• 1:28
  SPEAKER_00: Yeah, and if you are architecting the cloud migration right now, you know that this is the absolute nightmare scenario.
• 1:33
  SPEAKER_01: It really is.
• 1:34
  SPEAKER_01: So today we are going deep into the precise architectural mechanics of what actually happens to servers and legacy applications when you cut that traditional Active Directory cord and transition to a fully cloud native identity.
• 1:47
  SPEAKER_00: Aaron Powell It is the ultimate architectural puzzle, honestly.
• 1:50
  SPEAKER_00: And it usually catches organizations completely off guard.
• 1:53
  SPEAKER_00: I mean, we have spent over 20 years building enterprise networks where Active Directory was the absolute center of gravity.
• 2:01
  SPEAKER_00: Every server, every application, every user tied back to that physical or virtual domain controller.
• 2:06
  SPEAKER_00: Trevor Burrus, Jr.
• 2:06
  SPEAKER_00: Right.
• 2:07
  SPEAKER_01: It was the anchor for everything.
• 2:08
  SPEAKER_01: Trevor Burrus, Jr.
• 2:08
  SPEAKER_00: Exactly.
• 2:09
  SPEAKER_00: You can't just sever that lifeline and expect a 15-year-old legacy application to suddenly, you know, understand modern cloud architecture.
• 2:18
  SPEAKER_00: Trevor Burrus, Jr.
• 2:18
  SPEAKER_01: Which means we really need to look at the survival mechanics today.
• 2:22
  SPEAKER_01: And we are drawing from a massive stack of technical architecture overviews, identity management best practices, and official vendor documentation covering Microsoft, Okta, Ping identity, and Key Cloak.
• 2:33
  SPEAKER_00: Aaron Powell That's a lot of ground to cover.
• 2:35
  SPEAKER_01: Aaron Powell It is.
• 2:35
  SPEAKER_01: But the mission for this deep dive is to break down exactly how legacy protocols, servers, and applications survive this transition.
• 2:43
  SPEAKER_01: We're going to be comparing Microsoft's managed directory approach directly against the vendor neutral identity gateways.
• 2:48
  SPEAKER_00: Aaron Powell Okay.
• 2:49
  SPEAKER_00: So to really understand this, we have to start at the foundational layer.
• 2:52
  SPEAKER_00: I mean, before we even touch the legacy applications, we have to look at the metal.
• 2:56
  SPEAKER_01: Or uh the virtual metal, I guess.
• 2:58
  SPEAKER_01: Yeah.
• 2:58
  SPEAKER_00: Right.
• 2:59
  SPEAKER_00: The virtual metal.
• 3:00
  SPEAKER_01: Yeah.
• 3:00
  SPEAKER_00: We have to address how a cloud native server operates without a traditional Active Directory computer account.
• 3:06
  SPEAKER_01: Aaron Powell Yeah, because if you're an old school sysadmin listening to this, you know that for decades, joining a server to a domain meant creating a literal computer object in Active Directory.
• 3:17
  SPEAKER_01: People actually often forget that servers had passwords, just like human users did.
• 3:22
  SPEAKER_00: Aaron Powell Oh, they absolutely did.
• 3:23
  SPEAKER_00: And Active Directory managed that password under the hood.
• 3:28
  SPEAKER_00: Theoretically, it rotated it automatically every 30 days via the net login service.
• 3:32
  SPEAKER_01: Aaron Powell Right, theoretically.
• 3:33
  SPEAKER_00: Yeah.
• 3:33
  SPEAKER_00: Theoretically.
• 3:34
  SPEAKER_00: But when you move to the cloud, that paradigm just completely fractures.
• 3:38
  SPEAKER_01: Aaron Powell How so?
• 3:39
  SPEAKER_01: Like what breaks first?
• 3:40
  SPEAKER_00: Aaron Powell Well, it's the sheer scale and elasticity.
• 3:42
  SPEAKER_00: You have virtual machines spinning up, living for maybe a few hours to handle a traffic spike and then being completely destroyed.
• 3:48
  SPEAKER_00: That traditional, tightly coupled, persistent AD computer account model is just it's completely unworkable.
• 3:55
  SPEAKER_01: Oh, I see.
• 3:56
  SPEAKER_00: Yeah.
• 3:56
  SPEAKER_00: The directory would just be littered with tombstoned computer objects within a week.
• 4:00
  SPEAKER_01: Aaron Powell And the problem was even worse when we talk about service accounts, right.
• 4:03
  SPEAKER_01: Because we had computer accounts for the servers, but then we had service accounts for the actual applications running on them.
• 4:09
  SPEAKER_00: Aaron Powell Oh, service accounts.
• 4:10
  SPEAKER_00: Yeah, that was that was a mess.
• 4:12
  SPEAKER_01: Aaron Powell The classic model was to basically give a server or an application a static service account password manually vaulted somewhere, or you know, rely on a human being to remember to rotate it.
• 4:24
  SPEAKER_00: Aaron Powell Which was basically a ticking time bomb.
• 4:26
  SPEAKER_00: I mean, let's look at what actually happened operationally.
• 4:28
  SPEAKER_00: A systems administrator would get a ticket to spin up a new application.
• 4:33
  SPEAKER_00: They'd go into Active Directory, create a standard user account, and name it something like uh SVC database.
• 4:39
  SPEAKER_00: Right.
• 4:39
  SPEAKER_00: And then they'd check that dreaded box that says password never expires.
• 4:44
  SPEAKER_01: Ugh, the worst box.
• 4:45
  SPEAKER_00: The worst.
• 4:46
  SPEAKER_00: And then they hand that credential over to the development team.
• 4:48
  SPEAKER_00: The developers would then embed that static password in configuration files or plain text scripts or connection strings right there on the server.
• 4:56
  SPEAKER_01: Aaron Powell It's just a completely manual, heavily fragmented process.
• 5:00
  SPEAKER_00: Aaron Powell And a catastrophic security liability.
• 5:02
  SPEAKER_00: I mean, if a threat actor compromised that server, they just opened up a text file and found a highly privileged domain account password sitting right there in plain text.
• 5:10
  SPEAKER_01: Aaron Powell Wow.
• 5:10
  SPEAKER_01: Okay.
• 5:11
  SPEAKER_01: So to operate securely in the cloud, we clearly have to replace that entire fragile ecosystem.
• 5:16
  SPEAKER_00: Yep.
• 5:16
  SPEAKER_01: And we replace it with managed identities.
• 5:18
  SPEAKER_00: Yes.
• 5:19
  SPEAKER_01: So these are cloud native service principles that are bound directly to the cloud resources themselves.
• 5:24
  SPEAKER_01: But I want to get into the actual mechanics of how this stops the bleeding.
• 5:28
  SPEAKER_01: Like, if a cloud native server needs to authenticate to a database, how does it prove who it is without a password?
• 5:36
  SPEAKER_00: Aaron Powell So the cloud platform itself actually takes over the credential lifecycle.
• 5:41
  SPEAKER_00: When you provision a workload, say, a virtual machine, the platform generates cryptographic keys for that specific instance.
• 5:48
  SPEAKER_01: Okay.
• 5:48
  SPEAKER_00: There's no password for a human to know or to store in a vault or to accidentally leak in a public GitHub repository.
• 5:55
  SPEAKER_00: When that server needs to talk to a database or a storage bucket, it utilizes something called the instance metadata service or IMDS.
• 6:03
  SPEAKER_01: Okay, let's break that down for the listener.
• 6:04
  SPEAKER_01: What exactly is the IMDS doing?
• 6:06
  SPEAKER_00: The IMDS is basically a non-routable endpoint.
• 6:10
  SPEAKER_00: It usually lives at a highly specific local-only IP address, like uh 169.254.169.254.
• 6:19
  SPEAKER_00: Got it.
• 6:19
  SPEAKER_00: Only the server itself can reach it.
• 6:21
  SPEAKER_00: So when the application on the server needs access to a resource, it sends a request to this local endpoint saying, hey, I need to access the database.
• 6:28
  SPEAKER_01: And then the cloud fabric intercepts that.
• 6:30
  SPEAKER_00: Aaron Powell Exactly.
• 6:31
  SPEAKER_00: The cloud fabric intercepts this request.
• 6:33
  SPEAKER_00: And because the fabric is the thing hosting the virtual machine in the first place, it cryptographically verifies the identity of the caller without needing a password.
• 6:42
  SPEAKER_00: Right.
• 6:42
  SPEAKER_00: The fabric then generates a short-lived access token and just hands it back to the server.
• 6:47
  SPEAKER_00: The server uses that token to access the database.
• 6:49
  SPEAKER_01: Aaron Powell You know, it's like moving from giving a server a physical metal key that can be copied at a hardware store or just stolen from a desk drawer to a biometric lock where the building itself inherently recognizes the server.
• 7:02
  SPEAKER_01: Trevor Burrus, Jr.
• 7:03
  SPEAKER_00: That's a great way to put it.
• 7:04
  SPEAKER_01: And not only does it recognize the server, but the building is constantly changing the lock logic under the hood every few hours without anyone having to touch it.
• 7:11
  SPEAKER_00: Aaron Powell Yeah, that analogy hits the core mechanism perfectly.
• 7:14
  SPEAKER_00: Because there is no reusable, retrievable shared password, you are fundamentally breaking the mechanics of legacy attacks.
• 7:22
  SPEAKER_00: I mean, think about how Kerberoasting works.
• 7:24
  SPEAKER_01: Aaron Powell Oh, let's definitely walk through that attack scenario because I think it perfectly illustrates the vulnerability of the old model.
• 7:30
  SPEAKER_01: So if I'm an attacker who's just fished a standard low-level employee's credentials, how do I actually use that to steal a service account in a traditional Active Directory environment?
• 7:41
  SPEAKER_00: Aaron Powell Right.
• 7:42
  SPEAKER_00: So you start by querying the domain for any account that has a service principal name or an SPN.
• 7:47
  SPEAKER_00: An SPN is basically a tag that just says, hey, this account is running a service.
• 7:51
  SPEAKER_00: Once you find one, say our old SVC database account, you request a service ticket for it from the domain controller.
• 7:57
  SPEAKER_01: Aaron Powell And Active Directory just gives it to you?
• 7:59
  SPEAKER_00: Yeah.
• 7:59
  SPEAKER_00: Active directory functioning exactly as design just hands you back that ticket.
• 8:03
  SPEAKER_00: But here is the fatal flaw.
• 8:05
  SPEAKER_00: That ticket is encrypted using the password hash of the service account.
• 8:09
  SPEAKER_01: Aaron Powell Wait, so as the attacker, I now hold a piece of data that's encrypted with the very password I want to steal.
• 8:16
  SPEAKER_00: Exactly.
• 8:16
  SPEAKER_00: So you take that ticket offline, you load it onto a machine with massive GPU processing power, and you just run it through password cracking tools like Hashcat.
• 8:26
  SPEAKER_00: Right.
• 8:27
  SPEAKER_00: You are just guessing passwords, hashing them, and seeing if they decrypt the ticket.
• 8:32
  SPEAKER_00: And because service account passwords rarely change and are honestly often relatively simple to avoid breaking legacy systems, attackers crack them incredibly quickly.
• 8:42
  SPEAKER_00: Wow.
• 8:42
  SPEAKER_00: Yeah.
• 8:43
  SPEAKER_00: Once they have the plain text password, they have the keys to the kingdom.
• 8:46
  SPEAKER_01: Aaron Powell But with a managed identity, how does that math change?
• 8:49
  SPEAKER_00: Aaron Powell The math just disappears entirely.
• 8:52
  SPEAKER_00: There is new static password hash to crack.
• 8:55
  SPEAKER_00: The credentials are cryptographic keys.
• 8:57
  SPEAKER_00: They're incredibly long, they're fully randomized, and they're completely inaccessible to users or administrators.
• 9:03
  SPEAKER_01: Aaron Powell So there's nothing to take offline.
• 9:04
  SPEAKER_00: Aaron Powell Right.
• 9:05
  SPEAKER_00: There is no ticket to request offline.
• 9:07
  SPEAKER_00: You are basically shifting the entire security burden of credential lifecycle management from your IT operations team, who, you know, might forget to rotate a password directly to the cloud fabric itself, which never forgets.
• 9:18
  SPEAKER_01: Aaron Powell Okay, so the servers are secured.
• 9:20
  SPEAKER_01: We've replaced the AD computer accounts with cloud native managed identities.
• 9:24
  SPEAKER_01: That handles the infrastructure layer.
• 9:26
  SPEAKER_01: Right.
• 9:27
  SPEAKER_01: But here is where we hit the real world.
• 9:30
  SPEAKER_01: You've modernized the server, it's spinning elastically in the cloud, but sitting on top of that beautiful modern server is a stubborn, mission-critical application written 20 years ago.
• 9:40
  SPEAKER_00: Yeah, the real headache.
• 9:41
  SPEAKER_01: It doesn't know what a managed identity is.
• 9:43
  SPEAKER_00: Yeah.
• 9:43
  SPEAKER_01: It doesn't understand modern Ooth or SAMML tokens.
• 9:46
  SPEAKER_01: It doesn't even know what a web browser is.
• 9:48
  SPEAKER_01: It is hard-coded into its very binary to demand classic Active Directory schema, LDIP queries to look up user roles, and Kerberos or NTLM for authentication.
• 10:01
  SPEAKER_01: Like what do you do with that?
• 10:06
  SPEAKER_00: If an organization wants to shut down their physical on-premises domain controllers, they are faced with a massive problem.
• 10:13
  SPEAKER_00: You either have to rewrite the source code of that legacy application to understand modern web protocols, which can take years and millions of dollars, or you have to find a way to trick the application into thinking it's still living in 2005.
• 10:26
  SPEAKER_01: Which brings us to the native lift and shift answer.
• 10:29
  SPEAKER_01: Microsoft intra-domain services.
• 10:31
  SPEAKER_00: Yes.
• 10:32
  SPEAKER_00: Microsoft definitely recognized this exact road block.
• 10:35
  SPEAKER_00: Organizations were just refusing to migrate because they couldn't rewrite these critical apps.
• 10:40
  SPEAKER_00: So Microsoft built intra-domain services as the bridge.
• 10:44
  SPEAKER_00: It basically allows Windows and Linux virtual machines to join the cloud natively through a managed directory service.
• 10:50
  SPEAKER_01: Aaron Powell Wait, so let me unpack this.
• 10:52
  SPEAKER_01: We are migrating to a modern, flat, API-driven cloud environment, but we're essentially building a like a holographic simulation of a 20-year-old on-premises domain controller just so these legacy apps don't break.
• 11:07
  SPEAKER_00: Kind of.
• 11:07
  SPEAKER_01: Are we just putting a highly expensive band-aid on technical deck?
• 11:11
  SPEAKER_00: I mean, you can call it a band-aid, but in enterprise architecture, we call it necessary pragmatism.
• 11:15
  SPEAKER_00: Sometimes the original developers of an application are long gone.
• 11:18
  SPEAKER_00: Sometimes the original source code is literally lost on a decommissioned hard drive somewhere.
• 11:23
  SPEAKER_00: Yeah.
• 11:23
  SPEAKER_00: Or sometimes the vendor who built the app just went out of business a decade ago.
• 11:27
  SPEAKER_00: You literally cannot rewrite it.
• 11:29
  SPEAKER_00: So Entra Domain Services acts as a fully managed domain in the cloud, providing the exact legacy environment the app expects without requiring you to maintain the physical servers.
• 11:39
  SPEAKER_01: So under the hood, how is this continuous synchronization engine actually simulating the old world?
• 11:45
  SPEAKER_00: Well, think about the source of truth.
• 11:47
  SPEAKER_00: Your modern users live in Microsoft Entra ID, you know, the modern flat cloud native directory.
• 11:54
  SPEAKER_00: They authenticate with biometric pass keys and multi-factor authentication.
• 11:57
  SPEAKER_00: Right.
• 11:58
  SPEAKER_00: Entra domain services sits below that.
• 12:00
  SPEAKER_00: It utilizes a continuous synchronization engine that takes your modern cloud users and groups and pushes them down into a managed isolated domain.
• 12:08
  SPEAKER_00: It basically takes a flat cloud identity and translates it into a legacy compatible format.
• 12:14
  SPEAKER_01: Okay, so it's generating the legacy baggage on the fly.
• 12:16
  SPEAKER_00: Exactly.
• 12:17
  SPEAKER_00: It creates the classic user objects, it populates the legacy attributes like security identifiers or SIDs.
• 12:22
  SPEAKER_00: It stands up a classic LDIP directory, a Kerberos key distribution center, and NTLM authentication at endpoints.
• 12:29
  SPEAKER_01: It's just spinning up all the old school machinery.
• 12:31
  SPEAKER_00: Trevor Burrus, Jr.
• 12:31
  SPEAKER_00: Yeah.
• 12:32
  SPEAKER_00: So that when the legacy application reaches out to authenticate a user, it receives a perfectly valid Kerberos ticket.
• 12:39
  SPEAKER_00: The application is completely unaware that the user actually authenticated to a cloud directory using like a YubiKey.
• 12:47
  SPEAKER_01: Aaron Powell I can see how that provides massive relief to development teams.
• 12:50
  SPEAKER_01: It really buys the organization time.
• 12:52
  SPEAKER_01: It lets you evacuate your on-premises data center, shut down the physical hardware, and get out of the real estate business without having to wait for a multi-year application modernization project to finish.
• 13:04
  SPEAKER_00: It fundamentally bridges the gap.
• 13:06
  SPEAKER_00: It is a brilliant technical compromise.
• 13:09
  SPEAKER_00: But, and this is a massive but it comes with severe architectural trade-offs.
• 13:13
  SPEAKER_01: Right.
• 13:14
  SPEAKER_01: If you're listening to this and thinking, perfect, I'll just click the button for entry domain services and all my legacy problems is solved, just hold on.
• 13:20
  SPEAKER_01: We really have to dive into the three strict limitations of this architecture.
• 13:23
  SPEAKER_01: You cannot deploy this without understanding what you're giving up.
• 13:27
  SPEAKER_00: Absolutely.
• 13:27
  SPEAKER_00: The first major limitation is that the synchronization is strictly one way.
• 13:31
  SPEAKER_01: Meaning the sync only flows from the modern UNTRA ID cloud down into the legacy managed domain.
• 13:37
  SPEAKER_01: Why is there absolutely no right back path?
• 13:39
  SPEAKER_00: Aaron Powell It really comes down to the structural difference between a stateful directory and a flat API directory.
• 13:46
  SPEAKER_00: Okay.
• 13:46
  SPEAKER_00: Traditional Active Directory is incredibly stateful and complex.
• 13:50
  SPEAKER_00: It relies on a deeply interconnected web of organizational units, group policies, and custom schema extensions.
• 14:03
  SPEAKER_01: Does it map perfectly?
• 14:04
  SPEAKER_00: Not at all.
• 14:04
  SPEAKER_00: If Microsoft allowed bi-directional syncing, meaning you could create a user account inside the legacy managed domain and have it sync up to the cloud, you would introduce massive state conflicts and split brain scenarios.
• 14:17
  SPEAKER_01: So the cloud is the absolute unquestionable source of truth.
• 14:20
  SPEAKER_00: Always.
• 14:50
  SPEAKER_01: No infrastructure control.
• 14:52
  SPEAKER_01: You are basically losing your keys to the kingdom.
• 14:54
  SPEAKER_00: Oh yeah.
• 14:55
  SPEAKER_00: If you are an old school sysadmin who is used to having God mode, you know, domain administrator, enterprise administrator rights on your domain controllers, you are in for a massive shock.
• 15:06
  SPEAKER_01: Aaron Powell Right.
• 15:07
  SPEAKER_01: Because with traditional Active Directory, you own the metal, or at least the virtual metal.
• 15:11
  SPEAKER_01: You patch the operating system, you install monitoring agents, you tweet the registry, you control the network interfaces.
• 15:16
  SPEAKER_00: Aaron Powell But with intra-domain services, Microsoft fully manages the domain controllers.
• 15:21
  SPEAKER_00: You are granted zero administrative access to the underlying virtual machines.
• 15:26
  SPEAKER_00: Aaron Powell None.
• 15:26
  SPEAKER_00: None.
• 15:27
  SPEAKER_00: There is no remote desktop access.
• 15:29
  SPEAKER_00: There are no OS level patching rights.
• 15:31
  SPEAKER_00: You consume it purely as a platform service.
• 15:34
  SPEAKER_01: Aaron Powell Man, I can hear IT departments screaming about this right now.
• 15:38
  SPEAKER_00: Yeah.
• 15:38
  SPEAKER_01: Why does Microsoft lock them out so aggressively?
• 15:41
  SPEAKER_01: Is it just to force them into a managed service model?
• 15:44
  SPEAKER_00: Aaron Powell It's really about the physical realities of cloud hyperscale.
• 15:48
  SPEAKER_00: Microsoft is guaranteeing the high availability, the automated patching, and the continuous replication of these domains across availability zones.
• 15:57
  SPEAKER_00: If they let a customer's domain admin remote into the underlying server and tweak a core registry setting or, you know, install a custom security agent that aggressively locks down network ports, those managed service guarantees would instantly fall apart.
• 16:12
  SPEAKER_00: Microsoft literally cannot guarantee uptime if they don't control the operating system.
• 16:16
  SPEAKER_01: Aaron Powell That makes sense.
• 16:17
  SPEAKER_01: And we also have to talk about how this impacts group policy or GPOs, because that is the lifeblood of legacy Windows server management.
• 16:24
  SPEAKER_01: Very true.
• 16:25
  SPEAKER_01: The source documentation notes that standard GPO-based configuration is supported for the domain joined VMs in this environment.
• 16:32
  SPEAKER_01: Like, you can still map network drives, deploy local printers, or enforce local password lengths for the servers you join to this managed domain.
• 16:40
  SPEAKER_01: But because you lack domain administrator or enterprise administrator privileges, you are severely restricted.
• 16:46
  SPEAKER_00: Aaron Powell You are operating inside a locked box, you get a delegated administrative unit essentially.
• 16:53
  SPEAKER_00: You can apply group policy to the objects within your specific organizational unit, but the root of the domain is entirely locked down.
• 17:00
  SPEAKER_01: So no big sweeping changes.
• 17:01
  SPEAKER_00: Right.
• 17:02
  SPEAKER_00: Any GPO action that requires root-level schema access or enterprise-wide execution is completely off the table.
• 17:08
  SPEAKER_00: It requires a complete rewiring of how you view systems administration.
• 17:12
  SPEAKER_00: You are no longer managing servers, you are just managing policies within a sandbox.
• 17:16
  SPEAKER_01: Okay, that brings us to the third limitation.
• 17:18
  SPEAKER_01: And this one is deeply technical, but incredibly important for security teams.
• 17:22
  SPEAKER_01: The strict requirement for password hash synchronization or PHS.
• 17:26
  SPEAKER_00: This is where the cryptographic realities of legacy protocols really catch up with you.
• 17:31
  SPEAKER_00: To provision users with corporate credentials inside the managed domain, PHS is absolutely mandatory.
• 17:38
  SPEAKER_00: Remember our earlier point.
• 17:47
  SPEAKER_01: Right.
• 17:47
  SPEAKER_01: And to generate a Kerberos ticket, the domain controller physically needs the cryptographic hash of the user's password.
• 17:54
  SPEAKER_01: But Microsoft Enter ID doesn't store those legacy hashes by default, does it?
• 17:58
  SPEAKER_00: It doesn't.
• 18:13
  SPEAKER_01: Let's look at the mechanics of that because it's not just a simple copy-paste job.
• 18:16
  SPEAKER_01: The sources detail that this involved taking the plaintext password the moment the user types it in, applying additional salting, and then running it through a PBKDF2 algorithm.
• 18:25
  SPEAKER_00: Yes.
• 18:26
  SPEAKER_00: PBKDF2 stands for password-based key derivation function two.
• 18:30
  SPEAKER_00: But what it actually does is way more important than what it stands for.
• 18:34
  SPEAKER_00: It's a key stretching mechanism.
• 18:36
  SPEAKER_01: Explain key stretching for the listener.
• 18:38
  SPEAKER_01: Why do we need it?
• 18:39
  SPEAKER_00: Well, think of a standard legacy hash, like a single pane of glass.
• 18:42
  SPEAKER_00: If an attacker gets it, they can smash it relatively easily with brute force.
• 18:47
  SPEAKER_01: Right.
• 18:47
  SPEAKER_01: They just guess until they get it.
• 18:48
  SPEAKER_00: Exactly.
• 18:49
  SPEAKER_00: So key stretching is like taking that pane of glass, shattering it, putting the shards into a high-speed blender, melting it back down, shattering it again, and repeating that entire process 10,000 times.
• 19:00
  SPEAKER_00: Wow.
• 19:01
  SPEAKER_00: Okay.
• 19:01
  SPEAKER_00: It makes the cryptographic material exponentially harder for an attacker to reverse engineer.
• 19:06
  SPEAKER_00: Microsoft uses PBKDF2 to securely generate the legacy NTLM and Kerberos hashes from the modern cloud credential, and then it securely syncs those specific legacy hashes down into the managed domain.
• 19:18
  SPEAKER_01: But the bottom line is you are still generating and storing NTLM and Kerberos hashes.
• 19:24
  SPEAKER_01: If an organization has a strict, uncompromising security policy against generating or storing legacy NTLM hashes anywhere in their environment, perhaps due to compliance or a previous devastating breach, they are going to hit an absolute brick wall here.
• 19:40
  SPEAKER_00: They are.
• 19:56
  SPEAKER_01: What if you are an architect listening to this and you cannot accept those limitations?
• 20:00
  SPEAKER_01: Like if the lack of enterprise admin rights breaks your server management model, or if your chief information security officer absolutely forbids the synchronization of NTLM hashes, if enter domain services is a deal breaker, there is a completely different architectural path you can take to solve the exact same legacy access problem, identity aware gateways.
• 20:19
  SPEAKER_00: Yes.
• 20:20
  SPEAKER_00: This is where we look at the vendor neutral approach.
• 20:22
  SPEAKER_00: Organizations using dedicated identity platforms like Okta, Ping Identity, and Key Cloak solve the legacy access puzzle through a completely different paradigm.
• 20:32
  SPEAKER_00: They do not attempt to stand up a managed domain controller in the cloud.
• 20:35
  SPEAKER_00: They don't try to simulate the old world at the directory level.
• 20:39
  SPEAKER_00: Instead, they use advanced authentication gateways.
• 20:42
  SPEAKER_01: If Microsoft's enter domain services approach is like building an exact functioning replica of your old corporate office in the cloud so your legacy apps feel at home, this gateway approach is fundamentally different.
• 20:54
  SPEAKER_01: It's like hiring a highly skilled universal translator, or even better, a highly trusted forgery artist to stand at the front door of your actual old office.
• 21:02
  SPEAKER_01: Oh yes.
• 21:03
  SPEAKER_01: They take the Hodden Cloud badges from the users, verify them, and then quietly forge the old school physical keys to handle the legacy applications inside.
• 21:12
  SPEAKER_00: I love the forgery artist analogy because it gets right to the mechanics of token translation.
• 21:16
  SPEAKER_00: The gateway sits directly in front of the legacy application on the network.
• 21:20
  SPEAKER_00: It essentially acts as a reverse proxy.
• 21:23
  SPEAKER_00: When a user tries to access the old application, they don't hit the application directly.
• 21:28
  SPEAKER_00: The gateway intercepts the traffic.
• 21:30
  SPEAKER_01: And it forces the user to authenticate in the modern cloud.
• 21:33
  SPEAKER_00: Exactly.
• 21:33
  SPEAKER_00: The gateway halts the request and redirects the user's browser to the modern identity provider, whether that is the Optic Cloud, Ping Own, or a modern Key Cloak realm.
• 21:43
  SPEAKER_00: The user performs the modern authentication dance.
• 21:45
  SPEAKER_00: They might use a FIDO2 security key, biometric authentication, or adaptive multi factor authentication that checks their location and device health.
• 21:55
  SPEAKER_01: But once the cloud identity provider verifies the user, it issues a modern Token like a SAML assertion or an OIDC token back to the gateway.
• 22:04
  SPEAKER_01: And the legacy application still has no idea what to do with the SAML assertion.
• 22:08
  SPEAKER_00: Right.
• 22:08
  SPEAKER_00: And here is where the forgery artist does its job.
• 22:11
  SPEAKER_00: The gateway takes that verified modern session, consumes it, and translates it into the exact legacy protocol the back-end application expects.
• 22:20
  SPEAKER_01: Let's break down how the specific vendors handle this translation because they each approach it with different mechanical focuses.
• 22:26
  SPEAKER_01: The sources outline Okta Access Gateway, or OAG.
• 22:30
  SPEAKER_00: Okta Access Gateway is a classic, robust, reverse proxy.
• 22:34
  SPEAKER_00: It sits right in front of the application.
• 22:36
  SPEAKER_00: Once it verifies the modern session with the OktaCloud, it translates that session into legacy protocols like Kerberos or integrated Windows authentication known as IWA.
• 22:46
  SPEAKER_01: Aaron Powell But it also does something really critical with HTTP headers, right?
• 22:49
  SPEAKER_01: Because a lot of legacy web applications don't even use Kerberos.
• 22:52
  SPEAKER_00: Yes.
• 22:52
  SPEAKER_00: HTTP header injection is a massive use case for Okta Access Gateway.
• 22:56
  SPEAKER_00: Many older web applications, especially those built behind legacy web access management systems like CA SiteMinder or Oracle Access Manager, they don't do their own authentication.
• 23:06
  SPEAKER_01: Well they don't.
• 23:07
  SPEAKER_00: No, they just blindly trust a specific HTTP header that contains the user's username.
• 23:12
  SPEAKER_00: So the Okta gateway intercepts the modern authentication, verifies the user, and then injects that trusted HTTP header before passing the traffic down to the legacy application.
• 23:23
  SPEAKER_01: Aaron Powell And the app just accepts it.
• 23:24
  SPEAKER_00: The application reads the header, assumes the user is authenticated, and grants access.
• 23:29
  SPEAKER_00: It never knows that the user actually authenticated in the cloud using a biometric passkey.
• 23:34
  SPEAKER_01: And Ping Identity uses a very similar architectural pattern, but they split the duties between Ping Access and Ping Federate.
• 23:41
  SPEAKER_01: Let's look at how those two work in tandem.
• 23:43
  SPEAKER_00: So Ping Access is the policy engine and the reverse proxy.
• 23:46
  SPEAKER_00: It sits at the edge and applies security policies to the client requests at the HTTP level.
• 23:51
  SPEAKER_00: It evaluates the risk, checks the device posture, and validates the session.
• 23:55
  SPEAKER_00: But Ping Access itself doesn't always do the heavy lifting of token translation.
• 24:00
  SPEAKER_01: That's where PingFederate comes in.
• 24:01
  SPEAKER_00: Yes.
• 24:01
  SPEAKER_00: Ping Access works in tandem with PingFederate.
• 24:04
  SPEAKER_00: When a legacy protocol translation is needed, Ping Access hands the verified modern context over to PingFederate, which acts as the ultimate token translation engine.
• 24:13
  SPEAKER_00: PingFederate mints the exact token format required by the back end legacy system, whether that's a legacy SAML 1.1 token, a custom XML token, or a WS Trust token and hands it back to Ping Access to deliver to the application.
• 24:28
  SPEAKER_00: It's an incredibly flexible, heavily customizable bridge for massive enterprise environments.
• 24:34
  SPEAKER_01: And for organizations that want an open source path, the SLERTIS highlight Key Cloak.
• 24:39
  SPEAKER_00: Key Cloak is a fascinating open source alternative.
• 24:42
  SPEAKER_00: It acts natively as an OIDC and SAML broker.
• 24:46
  SPEAKER_00: But what makes it relevant for this deep dive is its built-in Kerberos and SPNEGO support.
• 24:51
  SPEAKER_01: Let's pause there and explain SPNego, because that is a dense acronym and that gets thrown around a lot in architecture meetings.
• 24:57
  SPEAKER_01: It stands for Simple and Protected G S S API negotiation mechanism.
• 25:01
  SPEAKER_01: But what is it actually doing under the hood?
• 25:03
  SPEAKER_00: To understand SPNEGO, you first have to understand GS AAPI.
• 25:06
  SPEAKER_00: Think of GS API as a generic standardized envelope for sending authentication data.
• 25:11
  SPEAKER_00: It doesn't care what kind of data is inside.
• 25:13
  SPEAKER_00: EspNego is the negotiation process that happens between a web browser and a server to figure out what to put in that envelope.
• 25:18
  SPEAKER_01: So the browser and the server are essentially talking to each other, trying to find a common language.
• 25:23
  SPEAKER_00: Exactly.
• 25:23
  SPEAKER_00: When you try to access a web app, the server says, Hey, I require authentication.
• 25:28
  SPEAKER_00: The browser, using SPNego, replies, Okay, I see you support Kerberos.
• 25:33
  SPEAKER_00: I have a Kerberos ticket for this user.
• 25:35
  SPEAKER_00: I'm going to put it inside the GSAPI envelope and hand it to you.
• 25:39
  SPEAKER_01: Ah, I see.
• 25:40
  SPEAKER_00: STNego is a mechanism that allows a web browser to seamlessly and securely pass a legacy Kerberos ticket over a modern HTTP connection.
• 25:48
  SPEAKER_00: Key Cloak acts as the modern front door, handling the OIDC brokering, but it can federate directly with existing LD app or active directory environments on the back end, using SPNego to speak the legacy protocols flawlessly.
• 26:00
  SPEAKER_01: So to summarize the gateway approach, Okta, Ping, and Keycloak are all sitting in front of the application, proxying the traffic, handling the modern OOT or SAML dance with the cloud identity provider, and then injecting headers or negotiating Kerberos tickets on the back end.
• 26:18
  SPEAKER_01: You modernize the access controls, getting conditional access, device posture checks, strong MFA wrapped around an application that was built before any of those concepts even existed without touching a single line of the legacy code.
• 26:30
  SPEAKER_00: It is incredibly powerful.
• 26:32
  SPEAKER_00: But just like enter domain services, to truly decide between these two architectural paths, you must understand the fundamental structural difference in what is actually happening to your infrastructure.
• 26:42
  SPEAKER_00: We have to talk about the critical distinction.
• 26:44
  SPEAKER_01: If you are listening to this and thinking, this is perfect, I'll just deploy Okta Access Gateway or Keycloak and finally turn off all my old physical domain controllers.
• 26:52
  SPEAKER_01: Hold on.
• 26:53
  SPEAKER_01: We need to look at the fine print of how this forgery actually works.
• 26:56
  SPEAKER_00: This is the most important architectural takeaway of the entire discussion.
• 26:59
  SPEAKER_00: Okta, ping, and keycloak are strictly authentication gateways.
• 27:02
  SPEAKER_00: They are not directory services.
• 27:04
  SPEAKER_01: Aaron Powell Let's break down the difference between stateless and stateful infrastructure.
• 27:09
  SPEAKER_01: A directory service holds state.
• 27:11
  SPEAKER_01: It has a complex schema.
• 27:12
  SPEAKER_01: It stores persistent objects.
• 27:14
  SPEAKER_00: Yes.
• 27:15
  SPEAKER_00: A directory service like your old Active Directory or Microsoft's intra domain services holds user objects, computer objects, group memberships, and organizational units.
• 27:25
  SPEAKER_00: It manages the relational database between all those objects.
• 27:28
  SPEAKER_00: The authentication gateways do absolutely none of that.
• 27:32
  SPEAKER_00: They have no Active Directory schema of their own.
• 27:34
  SPEAKER_00: They are stateless proxies that simply route and translate traffic.
• 27:38
  SPEAKER_01: Which means they cannot natively domain join a Windows server.
• 27:41
  SPEAKER_00: They cannot.
• 27:42
  SPEAKER_00: If you spin up a traditional Windows server, it expects to join a domain that speaks the native complex Active Directory protocols.
• 27:49
  SPEAKER_00: An authentication gateway just translates web traffic.
• 27:52
  SPEAKER_00: It does not provide the underlying directory infrastructure required for a server OS to bind to a domain.
• 27:57
  SPEAKER_01: So let's tie this back to our forgery artist analogy.
• 28:00
  SPEAKER_01: When Okta Access Gateway or Ping Access needs to forge that old school Kerberos ticket to hand to the legacy application, how does it actually do it?
• 28:10
  SPEAKER_01: It can't just invent a mathematically valid cryptographic ticket out of thin air, right?
• 28:14
  SPEAKER_00: Aaron Powell It absolutely cannot.
• 28:15
  SPEAKER_00: To generate a valid Kerberos ticket, the gateway uses a mechanism called Kerberos Constrained Delegation or KCD.
• 28:23
  SPEAKER_01: Walk us through the mechanics of KCD.
• 28:25
  SPEAKER_00: Remember, the gateway has verified the user via the cloud, but the legacy app demands a Kerberos ticket.
• 28:31
  SPEAKER_00: So the gateway basically walks to the back room of your network where an actual functioning Active Directory domain controller lives.
• 28:38
  SPEAKER_01: Wait, really?
• 28:38
  SPEAKER_00: Yes.
• 28:39
  SPEAKER_00: The gateway says to the domain controller, hey, I securely authenticated this user in the cloud.
• 28:44
  SPEAKER_00: I am explicitly authorized by you to request tickets on their behalf.
• 28:48
  SPEAKER_00: Please mint a Kerberos ticket for this user and give it to me.
• 28:51
  SPEAKER_00: The domain controller performs the cryptographic math, mints the ticket, and hands it to the gateway.
• 28:56
  SPEAKER_00: The gateway then passes it to the application.
• 28:59
  SPEAKER_01: Which means, and this is the absolute crux of the matter, the gateway still heavily depends on your existing Active Directory infrastructure to function.
• 29:07
  SPEAKER_00: Yes, the old infrastructure must live on.
• 29:11
  SPEAKER_00: Because the gateways do not replace the directory.
• 29:14
  SPEAKER_00: You must keep an active directory environment running to support the back-end Kerberos negotiation.
• 29:19
  SPEAKER_00: Trevor Burrus, Jr.
• 29:19
  SPEAKER_01: Contrast this explicitly with Microsoft's managed domain approach.
• 29:23
  SPEAKER_00: Enter domain services actually replaces the need for self-managed domain controllers entirely by hosting the directory state in the cloud.
• 29:31
  SPEAKER_00: You are shutting down your on-premises domain controllers and letting Microsoft run the directory as a managed service.
• 29:37
  SPEAKER_01: Aaron Powell But with the gateway approach, you aren't actually turning them off.
• 29:41
  SPEAKER_01: You are keeping them alive just to service the back end of the gateway.
• 29:44
  SPEAKER_00: Aaron Powell You are.
• 29:45
  SPEAKER_00: The gateways modernize the user access, but they do not eliminate the legacy infrastructure.
• 29:49
  SPEAKER_00: You still have to patch your physical or virtual domain controllers, you still have to manage replication, you still have to secure the on-premises directory against attacks.
• 29:58
  SPEAKER_01: So the architectural decision really comes down to a fundamental choice of what you were trying to eliminate.
• 30:03
  SPEAKER_01: Are you trying to eliminate the management of infrastructure or are you trying to implement the most advanced access controls?
• 30:09
  SPEAKER_00: Exactly.
• 30:10
  SPEAKER_00: If your absolute primary goal is to completely eradicate self-managed Active Directory domain controllers from your architecture, you know, to get out of the business of patching Windows Server operating systems, Microsoft's entradomain services provides the path to do that, albeit with strict management and administrative limitations.
• 30:28
  SPEAKER_00: But if your goal is to implement the most advanced, flexible, modern authentication controls, like complex zero trust policies, advanced MFA, and deep traffic inspection at the gateway edge without worrying about the limitations of a managed domain sandbox, the gateway approach is superior.
• 30:43
  SPEAKER_00: You just have to accept the trade-off that you will be maintaining your underlying, patched, and secured active directory infrastructure to support those legacy back-end protocols.
• 30:52
  SPEAKER_01: To recap, transitioning servers and legacy applications to cloud native identity requires moving from traditional computer accounts to managed identities.
• 31:01
  SPEAKER_01: For legacy applications, organizations must choose between recreating the directory state in the cloud via enter domain services or utilizing authentication gateways like Okta, Ping, and Key Cloak, which translate modern cloud sessions but still rely on existing active directory infrastructure.
• 31:18
  SPEAKER_01: That's a wrap on secure your infrastructure without service accounts.
• 31:22
  SPEAKER_01: We closed on the real choice every architect eventually faces.
• 31:26
  SPEAKER_01: Eliminate your domain controllers with intra domain services and give up admin rights.
• 31:32
  SPEAKER_01: Or keep a gateway in front of legacy apps while still patching Active Directory in the background to feed it Kerberos tickets.
• 31:40
  SPEAKER_01: Next episode, we turn to a device sitting on almost every network that nobody thinks to question.
• 31:45
  SPEAKER_01: Why your web firewall is an inside threat.
• 31:49
  SPEAKER_01: Connect with Ernie on LinkedIn, the link's in the episode description.
• 31:52
  SPEAKER_01: Subscribe if this is useful.
• 31:53
  SPEAKER_01: Until next time.