Latest / The Identity Blueprint / Why Your Web Firewall Is an Inside Threat

Transcript

Why Your Web Firewall Is an Inside Threat · The Identity Blueprint

• 0:00
  SPEAKER_00: Welcome back to the Identity Blueprint, Beyond the Domain.
• 0:03
  SPEAKER_00: I'm Ernie with Jose.
• 0:05
  SPEAKER_00: This episode traces the mistake that actually took down a Fortune 500 company.
• 0:10
  SPEAKER_00: Giving a piece of infrastructure a master key to everything it didn't need.
• 0:15
  SPEAKER_00: We break down the real architectural split between Microsoft Intra ID and AWS IAM.
• 0:22
  SPEAKER_00: One is a passport office that verifies who you are.
• 0:25
  SPEAKER_00: The other is a locksmith that's never once asked.
• 0:28
  SPEAKER_00: We also cover CEDAR, the mathematically verified policy engine replacing static role-based access, and how an employee reaches a 20-year-old Kerberos app from a coffee shop with zero VPN and zero exposed ports.
• 0:43
  SPEAKER_00: If your cloud roles have more access than they need, this episode explains exactly why.
• 0:49
  SPEAKER_01: In July 2019, uh a single piece of hardware was tricked into asking a seemingly simple question.
• 0:57
  SPEAKER_00: Right.
• 0:57
  SPEAKER_01: And the answer it received well, it ended up exposing 106 million customer records.
• 1:01
  SPEAKER_00: Yeah.
• 1:02
  SPEAKER_00: It was it was massive.
• 1:03
  SPEAKER_01: Aaron Powell Welcome to our strategy session.
• 1:05
  SPEAKER_01: I mean, if you're sitting in on this deep dive, you're likely a fellow architect, a systems engineer, or you know, just an insanely curious learner trying to untangle the brutal complexities of modern cloud security.
• 1:17
  SPEAKER_00: Aaron Powell Because the fallout from that single event, it fundamentally changed how the industry views the cloud perimeter.
• 1:24
  SPEAKER_01: Exactly.
• 1:25
  SPEAKER_00: You know, when you migrate from a traditional on-premises data center to a distributed multi-cloud environment, the classic network perimeter, your firewalls, your DMZs, they effectively dissolve.
• 1:35
  SPEAKER_01: Right.
• 1:36
  SPEAKER_01: They just vanish.
• 1:36
  SPEAKER_00: Aaron Powell, yeah.
• 1:37
  SPEAKER_00: Identity becomes the new perimeter.
• 1:39
  SPEAKER_00: But the reason the 2019 breach happened is because different cloud providers have radically different architectural philosophies on what you know what identity actually means.
• 1:48
  SPEAKER_01: Aaron Powell So we're talking about the Capital One data breach, and I want to start right here because it perfectly frames the massive architectural divide we're going to explore today between intra ID and AWS IAM.
• 2:00
  SPEAKER_00: It's the perfect case study.
• 2:01
  SPEAKER_01: You've got the case file here.
• 2:02
  SPEAKER_01: And the entry point, it wasn't a stolen password.
• 2:05
  SPEAKER_00: No.
• 2:06
  SPEAKER_01: It wasn't some sophisticated zero-day exploit deep inside a database.
• 2:10
  SPEAKER_01: The entry point was a web application firewall away running on a standard AWS EC2 virtual machine.
• 2:17
  SPEAKER_00: Aaron Powell And the architecture of that failure is uh well it's a masterclass in misunderstood cloud permissions.
• 2:23
  SPEAKER_00: Totally.
• 2:23
  SPEAKER_00: The EC2 instance running that web firewall was granted an IAM role.
• 2:28
  SPEAKER_00: Now in AWS, you attach roles to instances so they can interact with other AWS services.
• 2:34
  SPEAKER_01: Makes sense.
• 2:35
  SPEAKER_00: But this specific role was wildly overpermissioned.
• 2:38
  SPEAKER_00: I mean it had red access to over 700 Amazon S3 storage buckets.
• 2:43
  SPEAKER_01: Okay, let's unpack this because hang on.
• 2:45
  SPEAKER_01: If it's just a web firewall facing the public internet, why on earth does it have a role attached to it that can read 700 different backend storage buckets?
• 2:53
  SPEAKER_00: Aaron Powell Yeah, that is the multi-million dollar question, isn't it?
• 2:56
  SPEAKER_00: Right.
• 2:56
  SPEAKER_00: It's a classic anti-pattern.
• 2:57
  SPEAKER_00: Often engineers, you know, they get frustrated during deployment when a service can't access what it needs, so they apply a wildcard permission just to make it work.
• 3:05
  SPEAKER_01: Aaron Powell The old I'll fix it later wildcard.
• 3:08
  SPEAKER_00: Exactly.
• 3:08
  SPEAKER_00: Intending to lock it down later.
• 3:10
  SPEAKER_00: And they rarely do.
• 3:12
  SPEAKER_00: But to understand the actual mechanic of the breach, we have to look at how the attacker pulled those permissions out of the machine.
• 3:18
  SPEAKER_00: They exploited a vulnerability called server-side request forgery or SSRF.
• 3:23
  SPEAKER_01: Aaron Powell Let's unpack SSRF for the listener because the attacker didn't like brute force a password or guess an admin credential.
• 3:29
  SPEAKER_00: Aaron Powell Not at all.
• 3:30
  SPEAKER_00: With SSRF, you aren't breaking into the server.
• 3:32
  SPEAKER_00: You're tricking the server into acting as a proxy.
• 3:35
  SPEAKER_01: Okay.
• 3:35
  SPEAKER_00: The attacker sent a carefully crafted web request to the firewall.
• 3:39
  SPEAKER_00: The firewall processed that request and was tricked into querying a highly sensitive internal AWS endpoint on behalf of the attacker.
• 3:46
  SPEAKER_01: Aaron Powell The EC2 instance metadata service, the IMDS?
• 3:50
  SPEAKER_00: The IMDS, yeah.
• 3:51
  SPEAKER_00: It lives in a very specific internal, non-rootable IP address.
• 3:55
  SPEAKER_00: Yeah.
• 3:55
  SPEAKER_00: 169.254.169.254.
• 3:59
  SPEAKER_01: It's a famous IP in the cloud world.
• 4:00
  SPEAKER_00: Oh, absolutely.
• 4:01
  SPEAKER_00: It's essentially a local built-in API that a virtual machine uses to ask AWS about itself.
• 4:08
  SPEAKER_01: Aaron Powell But wait, why does a virtual machine need to ask questions about itself?
• 4:12
  SPEAKER_01: Shouldn't it just you know what it is?
• 4:14
  SPEAKER_00: Aaron Powell Well, in a static data center, maybe, but the cloud is elastic, right?
• 4:19
  SPEAKER_00: Right.
• 4:19
  SPEAKER_00: An EC2 instance might spin up dynamically during a massive traffic spike.
• 4:23
  SPEAKER_00: It needs to know its own IP address, what network it's on, and crucially what security credentials it's supposed to use.
• 4:30
  SPEAKER_01: Ah, I see.
• 4:31
  SPEAKER_00: Instead of hard-coding passwords into the machine image, which is just a massive security risk, AWS built the metadata service to dynamically hand temporary credentials to the machine when it asks for them.
• 4:43
  SPEAKER_01: Okay, so it's like a blind valet inside a mansion.
• 4:45
  SPEAKER_00: A blind LA, I like that.
• 4:47
  SPEAKER_01: Yeah.
• 4:47
  SPEAKER_01: Like the valet is standing by the front door holding the master keys.
• 4:50
  SPEAKER_01: If someone inside the house asks for the keys, the valet just hands them over, assuming that because the person is already inside the house, they must be authorized.
• 4:58
  SPEAKER_00: The blind valet is a brilliant way to picture it, actually.
• 5:01
  SPEAKER_00: By exploiting that SSRF vulnerability, the attacker essentially yelled through the mail slot, forcing the firewall to turn around and ask the valet for its own security credentials.
• 5:10
  SPEAKER_00: Oh wow.
• 5:11
  SPEAKER_00: And the metadata service, operating exactly as designed, dutifully responded by handing over the temporary cryptographic keys associated with that wildly overpermissive IAM role.
• 5:22
  SPEAKER_01: So this wasn't a failure of knowing who the attacker was.
• 5:26
  SPEAKER_01: The system didn't care about human identity at all.
• 5:28
  SPEAKER_01: This was a failure of giving a piece of hardware a master key to the entire building.
• 5:33
  SPEAKER_00: Precisely.
• 5:34
  SPEAKER_01: The firewall was essentially holding a keyring that could open 700 different vaults, and the attacker just, you know, reached through the window, grabbed the keyring, and walked away.
• 5:43
  SPEAKER_00: And once the attacker had those temporary keys, they didn't even need to route their traffic through the compromise firewall anymore.
• 5:49
  SPEAKER_01: They just bypassed it.
• 5:50
  SPEAKER_00: Yeah.
• 5:51
  SPEAKER_00: They simply took those keys, opened up the standard AWS command line interface on their own laptop, sitting at a completely different location, and authenticated directly to the AWS API.
• 6:01
  SPEAKER_00: They issued an Oz S3Ls command to list every single bucket that role had permission to see, and then an OS S3 sync command to systematically drain the contents of those buckets.
• 6:12
  SPEAKER_01: Which brings us to the core tension of our deep dives today.
• 6:16
  SPEAKER_01: This catastrophic event perfectly illustrates the extreme danger of misunderstanding the foundational difference between our two main subjects.
• 6:24
  SPEAKER_00: It really does.
• 6:24
  SPEAKER_01: When we talk about AWS IM, we are talking about a mechanical locksmith.
• 6:29
  SPEAKER_01: It is not and never was a directory of people.
• 6:32
  SPEAKER_01: UNTRA ID, on the other hand, is the passport office.
• 6:35
  SPEAKER_00: The structural DNA of these two systems could not be more different.
• 6:39
  SPEAKER_01: Let's examine Intra ID first.
• 6:41
  SPEAKER_00: Sure.
• 6:41
  SPEAKER_00: UNTRA ID evolved from the lineage of on-premises active directory.
• 6:45
  SPEAKER_00: Because of that heritage, it is fundamentally a human-centric, context-aware identity provider, or IDP.
• 6:51
  SPEAKER_01: Right.
• 6:52
  SPEAKER_00: Its entire existence is dedicated to verifying who you are.
• 6:55
  SPEAKER_01: And it does that using modern web protocols, right?
• 6:57
  SPEAKER_01: OIBC, SAMLNL, OOT 2.0.
• 7:00
  SPEAKER_01: But what do those actually do in plain English?
• 7:03
  SPEAKER_01: Because we throw around acronyms like OOAuth, but architects need to really understand the mechanism.
• 7:07
  SPEAKER_00: Aaron Powell Think of it like a bouncer at a highly secure club.
• 7:10
  SPEAKER_01: Okay, I'm with you.
• 7:11
  SPEAKER_00: When you authenticate to Entra ID, you prove who you are, maybe with a password, a fingerprint, or a hardware key.
• 7:18
  SPEAKER_00: Entra ID then evaluates your context.
• 7:20
  SPEAKER_01: Aaron Powell What kind of context?
• 7:21
  SPEAKER_00: It looks at rich human attributes.
• 7:23
  SPEAKER_00: Who is your manager?
• 7:24
  SPEAKER_00: What department are you in?
• 7:26
  SPEAKER_00: Are you logging in from an unmanaged personal iPad or a corporate-issued laptop?
• 7:30
  SPEAKER_01: Oh, so it's pulling a lot of data.
• 7:32
  SPEAKER_00: Exactly.
• 7:32
  SPEAKER_01: Yeah.
• 7:33
  SPEAKER_00: What is your current risk profile based on behavioral analytics?
• 7:38
  SPEAKER_00: If everything checks out, enter ID doesn't hand you the keys to the database.
• 7:42
  SPEAKER_01: Right.
• 7:42
  SPEAKER_01: It doesn't give you direct access.
• 7:44
  SPEAKER_00: No, it hands you a session-based token like a tamper-proof wristband.
• 7:48
  SPEAKER_00: That token says, I am the passport office, I have heavily vetted Bob, and Bob is valid for the next hour.
• 7:54
  SPEAKER_01: Aaron Powell But AWS IM doesn't care about your wristband.
• 7:57
  SPEAKER_01: It doesn't care if I'm Bob from Finance or if I just got promoted or who my boss is.
• 8:01
  SPEAKER_00: AWS IMM is blind to human organizational charts.
• 8:05
  SPEAKER_01: Completely blind.
• 8:06
  SPEAKER_00: It was built from the ground up for infrastructure API control.
• 8:09
  SPEAKER_00: It acts as a machine-to-machine permission scalpel.
• 8:11
  SPEAKER_01: A scalpel, I like that.
• 8:13
  SPEAKER_00: It evaluates cryptographic signatures against specific resource endpoints, what AWS calls Amazon resource names or ARNs.
• 8:22
  SPEAKER_00: It also evaluates heavily defined condition keys.
• 8:25
  SPEAKER_00: It answers a very cold, binary question.
• 8:27
  SPEAKER_00: Yeah.
• 8:28
  SPEAKER_00: Does this exact cryptographically signed request have explicit mathematical permission to touch this exact cloud resource?
• 8:36
  SPEAKER_01: So treating these two systems as equivalents is the first and arguably the most dangerous trap cloud architects fall into.
• 8:43
  SPEAKER_00: Absolutely.
• 8:44
  SPEAKER_01: If I try to use AWS IM to manage employee onboarding, like you know, creating permanent IAM users with long-lived access keys for every new hire, I am building an administrative nightmare.
• 8:55
  SPEAKER_00: You're building a ticking time bomb.
• 8:56
  SPEAKER_01: Yeah.
• 8:57
  SPEAKER_00: Long-lived IM access keys sitting on developers' laptops get accidentally committed to public GitHub repositories every single day.
• 9:03
  SPEAKER_01: Oh, we see it all the time.
• 9:04
  SPEAKER_00: Furthermore, when an employee leaves the company, HR deletes them from the HR system.
• 9:09
  SPEAKER_00: But if their identity is statically hard-coded into AWS IAM, they still have full access to your cloud infrastructure until someone remembers to manually delete that IAM user.
• 9:18
  SPEAKER_01: Yikes.
• 9:20
  SPEAKER_01: And conversely, if I tried to use UNTRA ID to manage micro-level read and write permissions on individual cloud storage buckets across thousands of workloads, I'm trying to use a passport office to pick a padlock.
• 9:32
  SPEAKER_01: It's just the wrong tool for the job.
• 9:34
  SPEAKER_00: You create immense friction.
• 9:35
  SPEAKER_01: Right.
• 9:36
  SPEAKER_00: Intra ID tokens get bloated, application developers get bottlenecked waiting for identity teams to approve basic infrastructure changes, and you lose the granular resource level control that AWS IAM excels at.
• 9:48
  SPEAKER_01: So you need both doing their own jobs.
• 9:51
  SPEAKER_00: You want the passport office to issue the verified identity, and you want the local locksmith to validate the specific keys at the door.
• 9:58
  SPEAKER_01: Aaron Powell Okay, here's where it gets really interesting.
• 10:00
  SPEAKER_01: If we accept that UNTRA ID is the central passport office issuing these modern wristbands, we run into a massive logistical problem.
• 10:07
  SPEAKER_00: We do.
• 10:08
  SPEAKER_01: Most enterprises aren't born in the cloud.
• 10:10
  SPEAKER_01: They aren't starting with a blank slate.
• 10:12
  SPEAKER_01: They have 20, sometimes 30 years of employee data, group memberships, and security policies sitting on physical active directory servers in a data center in Ohio somewhere.
• 10:22
  SPEAKER_00: Right, the legacy anchor.
• 10:23
  SPEAKER_01: Exactly.
• 10:24
  SPEAKER_01: So how do we physically get our human workforce into this cloud passport office in the first place?
• 10:38
  SPEAKER_01: The very first step.
• 10:39
  SPEAKER_00: Architects have to choose a synchronization engine to build that identity supply chain.
• 10:44
  SPEAKER_00: And right now, there are two distinct competing paths.
• 10:48
  SPEAKER_01: Okay.
• 10:49
  SPEAKER_01: What are they?
• 10:49
  SPEAKER_00: Microsoft Intra Connect Sync, which is the classic server-based monolith, and Microsoft EntraCloud Sync, which is the modern agent-based alternative.
• 10:58
  SPEAKER_01: Aaron Powell Let's put these two in the ring together because they represent entirely different operational philosophies.
• 11:04
  SPEAKER_01: Connect Sync is the heavyweight freight train, right?
• 11:07
  SPEAKER_01: It requires dedicated tracks.
• 11:09
  SPEAKER_00: It is an absolute heavyweight.
• 11:10
  SPEAKER_00: Connect Sync requires a full Windows Server deployment physically sitting on premises or in your private cloud, usually backed by a full SQL database.
• 11:17
  SPEAKER_01: Wow, that's heavy.
• 11:18
  SPEAKER_00: It is the sync engine you're forced to use when you have massive, highly complex, deeply entrenched environments.
• 11:25
  SPEAKER_00: It supports an unlimited number of objects, and it is strictly required if your organization relies on specific legacy hybrid features.
• 11:32
  SPEAKER_01: Like device write back.
• 11:34
  SPEAKER_00: Device write back is a prime example.
• 11:35
  SPEAKER_01: Walk us through that.
• 11:36
  SPEAKER_00: Well, if an employee joins their new laptop directly to enter ID in the cloud, but you have legacy on-premises management tools that need to see that computer object, ConnectSync will physically write that cloud object back down into your local Active Directory.
• 11:52
  SPEAKER_01: Oh, I see.
• 11:53
  SPEAKER_00: CloudSync cannot do that.
• 11:55
  SPEAKER_01: What about exchange?
• 11:56
  SPEAKER_01: Because every time I talk to an enterprise architect, hybrid email migrations seem to be the anchor holding them to legacy infrastructure.
• 12:03
  SPEAKER_00: Exchange hybrid is notoriously complex.
• 12:06
  SPEAKER_01: I've heard horror stories.
• 12:07
  SPEAKER_00: If you're routing mail between legacy on-premises exchange servers and cloud-based exchange online, you need incredibly specific mailbox attributes synchronized perfectly in both directions.
• 12:17
  SPEAKER_01: Connect sync handles that.
• 12:19
  SPEAKER_00: Only ConnectSync supports the deep multi-directional attribute flow required to keep an exchange hybrid environment from collapsing in on itself.
• 12:26
  SPEAKER_01: But the operational tax of running the free train is brutal.
• 12:30
  SPEAKER_01: I mean, you have to patch the underlying Windows Server operating system, you have to back up the SQL database, and if that server goes down, your entire identity supply chain halts.
• 12:40
  SPEAKER_00: It completely stops.
• 12:41
  SPEAKER_01: So you have to architect high availability by building a secondary passive staging server, which you also have to patch and monitor.
• 12:49
  SPEAKER_00: The administrative overhead is significant, and that is exactly why Microsoft introduced CloudSync.
• 12:54
  SPEAKER_00: If ConnectSync is the freight train, CloudSync is a fleet of nimble delivery vans.
• 12:59
  SPEAKER_01: It's like choosing between a massive freight train that requires dedicated tracks versus a fleet of nimble delivery vans that can't carry oversized loads.
• 13:08
  SPEAKER_01: I love that analogy.
• 13:09
  SPEAKER_01: Nimble delivery vans that don't require heavy infrastructure.
• 13:13
  SPEAKER_00: CloudSync completely shifts the heavy computation and the synchronization engine into the cloud itself.
• 13:18
  SPEAKER_01: So what runs on-prem?
• 13:20
  SPEAKER_00: On-premises, you don't install a monolithic database.
• 13:24
  SPEAKER_00: You just drop lightweight provisioning agents onto a few existing servers.
• 13:27
  SPEAKER_01: Oh, that's much easier.
• 13:29
  SPEAKER_00: And this provides native high availability out of the box.
• 13:32
  SPEAKER_00: You install three agents across three different servers.
• 13:34
  SPEAKER_00: If one server catches fire, the other two just keep processing the identity flow.
• 13:39
  SPEAKER_01: I imagine this is a lifesaver for mergers and acquisitions.
• 13:43
  SPEAKER_00: It changes the game for MA.
• 13:44
  SPEAKER_01: How so?
• 13:45
  SPEAKER_00: Historically, if your company bought another company, you had to establish incredibly complex network routing, build cross-forest trusts, and open firewalls just to get their employees into your directory.
• 13:57
  SPEAKER_01: A nightmare, basically.
• 13:58
  SPEAKER_00: Exactly.
• 13:59
  SPEAKER_00: With CloudSync, because it natively supports disconnected forests, you just email the newly acquired company, the lightweight agent installer.
• 14:07
  SPEAKER_01: Just email it.
• 14:08
  SPEAKER_00: Yeah.
• 14:08
  SPEAKER_00: They drop it on a server in their isolated data center.
• 14:11
  SPEAKER_00: It makes an outbound HTTPS connection to the cloud, and within minutes, their users start populating in your enter ID tenant.
• 14:18
  SPEAKER_01: But delivery vans have strict weight limits.
• 14:20
  SPEAKER_01: They can't carry an oversized load.
• 14:22
  SPEAKER_00: The hard caps on cloud sync are very real.
• 14:25
  SPEAKER_01: Well kind of caps.
• 14:26
  SPEAKER_00: Currently, it only supports up to 150,000 objects per domain.
• 14:31
  SPEAKER_00: It limits you to 50,000 members per group.
• 14:33
  SPEAKER_01: Okay, so if I have a massive company.
• 14:35
  SPEAKER_00: If you have an all-company distribution list with 60,000 employees, cloud sync will choke on it.
• 14:40
  SPEAKER_01: It just fails.
• 14:41
  SPEAKER_00: And as we mentioned, you sacrifice device right back and exchange hybrid support.
• 14:45
  SPEAKER_01: Right.
• 14:46
  SPEAKER_01: So whether you choose the freight train or the delivery van, the actual mechanics of moving a human identity from the ground to the cloud is where migrations typically fall apart.
• 14:56
  SPEAKER_00: That's where the math matters.
• 14:57
  SPEAKER_01: It all comes down to the stable join key or the identity math.
• 15:01
  SPEAKER_01: How does UNTRA ID know that the Bob Smith on a server in Ohio is the exact same Bob Smith logging into Azure?
• 15:08
  SPEAKER_00: It relies on an immutable anchor.
• 15:10
  SPEAKER_01: An immutable anchor.
• 15:11
  SPEAKER_00: When you sync a user, you aren't just copying a string of text like a first and last name.
• 15:16
  SPEAKER_00: You're maintaining a cryptographic mapping across a cloud boundary.
• 15:20
  SPEAKER_01: Okay, so how does it generate that map?
• 15:22
  SPEAKER_00: The synchronization engine looks at the on-premises user and takes a unique, unchanging value.
• 15:27
  SPEAKER_00: Historically, this was derived from the object GUID, a mathematical identifier assigned to the user the second they were created in Active Directory.
• 15:36
  SPEAKER_00: Got it.
• 15:37
  SPEAKER_00: The sync engine converts that GUID into a source anchor and creates the corresponding cloud user.
• 15:43
  SPEAKER_01: But what happens if an administrator tries to get clever?
• 15:46
  SPEAKER_01: Say Bob Smith leaves the company, so they delete his on-premises account.
• 15:50
  SPEAKER_01: Okay.
• 15:50
  SPEAKER_01: Two days later, Bob is rehired.
• 15:53
  SPEAKER_01: The admin creates a new account, names it Bob Smith, gives it the exact same email address, and waits for the sync.
• 16:00
  SPEAKER_00: Total catastrophic failure for Bob's access.
• 16:02
  SPEAKER_01: Really?
• 16:03
  SPEAKER_01: Why?
• 16:03
  SPEAKER_00: The identity math breaks.
• 16:05
  SPEAKER_00: Even though the name and email are identical, the new on-premises Bob has a brand new object GID.
• 16:10
  SPEAKER_01: Because it's a technically new object in AD.
• 16:13
  SPEAKER_00: Exactly.
• 16:13
  SPEAKER_00: When the sync engine evaluates this, it looks at the cloud, sees the old Bob with the old source anchor, and realizes they don't match.
• 16:20
  SPEAKER_01: So what does it do?
• 16:21
  SPEAKER_00: It will either try to provision a duplicate Bob Smith in the cloud, resulting in but him having two conflicting identities, or it will simply orphan the cloud account, completely locking Bob out of his cloud applications.
• 16:34
  SPEAKER_00: Ouch.
• 16:35
  SPEAKER_00: The absolute stability of that source anchor is paramount.
• 16:39
  SPEAKER_01: Okay, let's fast forward.
• 16:40
  SPEAKER_01: We've survived the sink.
• 16:41
  SPEAKER_00: We made it.
• 16:42
  SPEAKER_01: The identities are perfectly mapped, the immutable anchors are rock solid, and our human workforce now holds these modern, context-aware digital passports from Intra ID.
• 16:52
  SPEAKER_01: They're ready for the cloud.
• 16:53
  SPEAKER_01: They are armed with their session-based OAuth 2.0 and OIDC wristbands.
• 16:58
  SPEAKER_01: But a massive new problem arises.
• 17:00
  SPEAKER_01: What happens when these modern humans take their shiny new cloud passports and try to open ancient doors?
• 17:06
  SPEAKER_01: I'm talking about legacy applications.
• 17:08
  SPEAKER_00: This is the exact architectural wall that multi-cloud strategies hit at full speed.
• 17:12
  SPEAKER_01: Full speed into a brick wall.
• 17:14
  SPEAKER_00: Legacy applications.
• 17:15
  SPEAKER_00: You know, inventory systems built in 2004, custom HR portals written in old.NET frameworks.
• 17:20
  SPEAKER_00: They do not know what a JSON web token is.
• 17:22
  SPEAKER_01: I have no idea.
• 17:23
  SPEAKER_00: They cannot consume a modern OIDC token.
• 17:27
  SPEAKER_01: Uh-huh.
• 17:27
  SPEAKER_00: They look at that modern token like it's written in alien hieroglyphics.
• 17:30
  SPEAKER_01: So what do they speak?
• 17:31
  SPEAKER_00: They rely entirely on two older protocols, Kerberos and LDIP.
• 17:36
  SPEAKER_01: Aaron Powell Let's clearly distinguish Kerberos and LDIP for the listener because people constantly lump them together as just legacy active directory stuff.
• 17:44
  SPEAKER_00: But they do all the time.
• 17:45
  SPEAKER_01: But they perform two entirely different critical functions for an application, don't they?
• 17:50
  SPEAKER_00: Aaron Powell Separating them is crucial for understanding how to host them in the cloud.
• 17:54
  SPEAKER_00: Kerberos is the authentication and ticketing system.
• 17:57
  SPEAKER_01: Ticketing, okay.
• 17:58
  SPEAKER_00: It is how you cryptographically prove you are who you say you are to a local network.
• 18:03
  SPEAKER_00: When a user wants to access a service, they authenticate to the domain controller, which issues them a ticket granting ticket or TGT.
• 18:10
  SPEAKER_01: Like a master ticket.
• 18:12
  SPEAKER_00: Exactly.
• 18:12
  SPEAKER_00: The user then presents that TGT to request a specific service ticket for the legacy application.
• 18:18
  SPEAKER_00: The application inspects the cryptography of the service ticket, trusts the domain controller that issued it, and lets the user in.
• 18:24
  SPEAKER_01: So Kerberos gets you through the front door.
• 18:26
  SPEAKER_01: What about LDIP?
• 18:27
  SPEAKER_00: LDAP, the lightweight directory access protocol, is the query language.
• 18:31
  SPEAKER_00: It's the phone book.
• 18:32
  SPEAKER_00: It's a phone book.
• 18:32
  SPEAKER_00: Once the application accepts your Kerberos ticket and lets you in the door, it often needs to know what you're allowed to see.
• 18:40
  SPEAKER_00: It uses LDF to reach back out over the network to the domain controller and ask, okay, the Kerberos ticket proves this is Alice, but I need to know, is Alice a member of the financial approver security group?
• 18:53
  SPEAKER_00: Who is Alice's manager?
• 18:55
  SPEAKER_01: So if I have an old.NET application that expects a Kerberos ticket at the front door and needs an LDF phone book on the back end to look up user attributes, it's going to violently bounce my shiny new OF token at the door.
• 19:06
  SPEAKER_00: It will flat out reject it.
• 19:08
  SPEAKER_01: IntraID natively speaks web protocols.
• 19:10
  SPEAKER_01: It does not hand out Kerberos service tickets.
• 19:12
  SPEAKER_01: How do we give it what it wants in a cloud environment?
• 19:15
  SPEAKER_00: You have to provide it with a real domain controller to talk to in the cloud.
• 19:18
  SPEAKER_00: A real one.
• 19:19
  SPEAKER_00: And this introduces a critical decision matrix for architects regarding managed domain services.
• 19:24
  SPEAKER_00: The very first instinct many infrastructure teams have is to fall back on what they know, the self-managed approach.
• 19:31
  SPEAKER_01: Right.
• 19:31
  SPEAKER_01: They just spin up a standard virtual machine in Azure or an EC2 instance in AWS, and they manually install the Active Directory domain services role on it.
• 19:40
  SPEAKER_01: Good old infrastructure as a service.
• 19:42
  SPEAKER_01: So it's the buy-a-pet approach.
• 19:45
  SPEAKER_01: You get full control, but you have to feed it, walk it, and take it to the vet.
• 19:49
  SPEAKER_00: The by pet approach is incredibly accurate.
• 19:51
  SPEAKER_00: You get absolute control, but you bear the full burden of keeping the pet alive.
• 19:56
  SPEAKER_01: What are the pros of doing it that way?
• 19:58
  SPEAKER_00: The primary pro is that you retain full enterprise admin rights, direct host level OS access, and the ability to implement highly customized schema extensions.
• 20:08
  SPEAKER_01: Schema extensions being when a legacy application requires you to literally rewrite the underlying database structure of Active Directory to function.
• 20:16
  SPEAKER_00: Exactly.
• 20:17
  SPEAKER_00: If you have a legacy app that demands a custom attribute injected into the core AD schema, the self-managed route might be your only choice.
• 20:24
  SPEAKER_01: Okay.
• 20:25
  SPEAKER_01: But the cons.
• 20:26
  SPEAKER_00: A con is the massive ongoing operational cost.
• 20:29
  SPEAKER_00: You own the patching of the Windows Server OS, you own the backup and disaster recovery strategy.
• 20:33
  SPEAKER_01: Yeah, it's all on you.
• 20:34
  SPEAKER_00: You are entirely responsible for architecting the SYS VL replication and high availability across multiple availability zones.
• 20:42
  SPEAKER_00: If the primary domain controller corrupts its database at 2.0 AM on a holiday weekend, your pager goes off.
• 20:49
  SPEAKER_00: You are the one performing the authoritative restore.
• 20:52
  SPEAKER_01: Yeah, and most organizations are desperately trying to get out of the business of patching domain controllers at 2.am.
• 20:57
  SPEAKER_01: Definitely.
• 20:58
  SPEAKER_01: Which naturally pushes architects toward managed platform offerings.
• 21:01
  SPEAKER_01: And I want to start on the AWS side of the multi-cloud fence because they offer a service called AWS Managed Microsoft AD.
• 21:09
  SPEAKER_00: AWS Managed Microsoft AD is a fascinating piece of platform engineering.
• 21:13
  SPEAKER_01: How so?
• 21:14
  SPEAKER_00: AWS provides a fully managed, real active directory forest running on actual Windows Server instances under the hood.
• 21:20
  SPEAKER_01: Wait, real Windows servers.
• 21:22
  SPEAKER_00: Real Windows servers.
• 21:23
  SPEAKER_00: It supports native domain join for your legacy apps, full Kerberos authentication, and full LD app queries.
• 21:29
  SPEAKER_01: But they manage it.
• 21:30
  SPEAKER_00: Exactly.
• 21:31
  SPEAKER_00: AWS handles the heavy lifting.
• 21:33
  SPEAKER_00: They patch the underlying operating system automatically, they take the automated snapshots, and they seamlessly deploy the domain controllers across multiple availability zones to guarantee high availability.
• 21:44
  SPEAKER_01: Okay, there's always a catch.
• 21:45
  SPEAKER_01: When you move from self managed infrastructure to a platform service, you surrender something.
• 21:50
  SPEAKER_01: What's the trade off here?
• 21:52
  SPEAKER_00: The trade off is administrative control.
• 21:54
  SPEAKER_00: You do not get direct host level access to the operating system.
• 21:58
  SPEAKER_01: So I can't log into the server itself.
• 22:00
  SPEAKER_00: You cannot RDP into the domain controller.
• 22:03
  SPEAKER_00: Furthermore, you do not receive domain admin or enterprise admin rights.
• 22:07
  SPEAKER_01: Interesting.
• 22:08
  SPEAKER_00: You receive heavily delegated administrative permissions to manage your users, groups, and group policies within a specific organizational unit.
• 22:16
  SPEAKER_00: But AWS retains the ultimate administrative keys to the underlying forest to ensure they can patch and maintain it safely.
• 22:23
  SPEAKER_01: But here's where it gets really fascinating.
• 22:24
  SPEAKER_01: The critical differentiator for AWS managed Microsoft AD, the specific feature that makes it the absolute linchpin for so many enterprise migrations, is that it supports traditional cross-forest trusts back to an on-premises active directory environment.
• 22:39
  SPEAKER_00: What's fascinating here is that that is a massive architectural advantage.
• 22:43
  SPEAKER_00: A cross-forest trust allows an architect to establish a secure Kerberos-level routing path across a VPN or Direct Connect, linking the AWS cloud environment directly back to the legacy on-premises data center.
• 22:58
  SPEAKER_01: So let me get this straight.
• 22:59
  SPEAKER_01: I can lift and shift a 20-year-old application into AWS, join it to the AWS managed AD, and a user sitting at their desk in the corporate headquarters can access it seamlessly using the exact same on-premises credentials they logged into their computer with.
• 23:13
  SPEAKER_00: Yes, absolutely.
• 23:14
  SPEAKER_00: The trust allows the authentication request to hit the AWS cloud, realize the user is from the on-premises domain, and route the Kerperos referral back to the on-premises domain controllers for verification.
• 23:24
  SPEAKER_00: It creates a seamless bridge.
• 23:25
  SPEAKER_01: So Amazon AWS is running a highly capable Microsoft workload that often fits enterprise migration needs beautifully.
• 23:33
  SPEAKER_00: It's ironic, but true.
• 23:35
  SPEAKER_01: But what if you don't need a massive robust forest?
• 23:37
  SPEAKER_01: What if you're a startup or you just have a tiny Linux application sitting in AWS that simply needs a basic LDDACI phone book to look up users?
• 23:46
  SPEAKER_00: For those highly specific edge cases, AWS offers directory service Simple AD.
• 23:51
  SPEAKER_01: Simple AB, okay.
• 23:52
  SPEAKER_00: It is strictly the cost-optimized option designed for small environments.
• 23:56
  SPEAKER_01: But simple AD isn't really Active Directory, is it?
• 23:59
  SPEAKER_01: Under the hood, it's something entirely different.
• 24:01
  SPEAKER_00: That's the secret of SimpleAD.
• 24:03
  SPEAKER_00: It is powered by Samba 4.
• 24:04
  SPEAKER_01: Ah, Samba.
• 24:06
  SPEAKER_00: Yeah, which is an open source Linux software suite designed to mimic Active Directory.
• 24:09
  SPEAKER_00: Because it is Samba 4 and not actual Windows server code, it provides basic LDAP and basic Kerberos, but it fundamentally lacks full Active Directory feature parity.
• 24:20
  SPEAKER_01: So what can it do?
• 24:21
  SPEAKER_00: It cannot support cross-forest trusts, it doesn't support complex DNS configurations, it doesn't support modern AD features like dynamic access control.
• 24:29
  SPEAKER_00: An architect chooses simple AD strictly when budget is the absolute primary driver, the user count is very low, and the legacy applications requirements are exceptionally basic.
• 24:40
  SPEAKER_01: Okay, so AWS has a real AD forest option that supports trusts back to on-prem, and a lightweight Linux option for cheap LDAP.
• 24:49
  SPEAKER_01: If our legacy app is sitting in Azure, surely Microsoft's own managed offering is identical to Amazon's, right?
• 24:55
  SPEAKER_01: I mean, it's Microsoft's own proprietary protocol.
• 24:58
  SPEAKER_01: They invented Active Directory.
• 25:00
  SPEAKER_00: You would naturally assume that, but structurally, they are vastly different products.
• 25:04
  SPEAKER_00: Really?
• 25:05
  SPEAKER_00: Microsoft's managed offering is called Microsoft Intra Domain Services.
• 25:09
  SPEAKER_00: And it is not a traditional Active Directory Forest in the way AWS provisions one.
• 25:13
  SPEAKER_01: Then what is it?
• 25:14
  SPEAKER_00: It is essentially a one-way synchronization engine flowing from your cloud enter ID tenant down to an isolated managed domain environment in Azure.
• 25:23
  SPEAKER_01: Let's break down the limitations of enter domain services because those limitations dictate exactly how and when architects are allowed to use it.
• 25:30
  SPEAKER_00: The limitations are stark and highly intentional.
• 25:32
  SPEAKER_01: Okay, hit me.
• 25:33
  SPEAKER_00: There is no write back from the managed domain backup to enter ID.
• 25:37
  SPEAKER_00: It is strictly a one-way street.
• 25:39
  SPEAKER_01: One way only.
• 25:40
  SPEAKER_00: Just like AWS, there are no enterprise admin rights.
• 25:43
  SPEAKER_00: But the two most critical limitations are these.
• 25:46
  SPEAKER_00: First, it absolutely does not support cross-forest trusts back to your on-premises data center.
• 25:52
  SPEAKER_01: Wait, what?
• 25:53
  SPEAKER_00: And second, it strictly requires password hash sync to be enabled on your UNTRAConnect setup.
• 25:59
  SPEAKER_01: Wait, really?
• 26:00
  SPEAKER_01: Microsoft, the company that invented Active Directory, doesn't let you connect their cloud AD back to their own on-premises AD, but AWS does.
• 26:08
  SPEAKER_00: It's true.
• 26:09
  SPEAKER_01: Why would Microsoft build it that way?
• 26:10
  SPEAKER_01: That makes zero sense.
• 26:12
  SPEAKER_01: Why would they intentionally handicap their own managed service by refusing to support cross-forest trusts?
• 26:17
  SPEAKER_00: It makes perfect sense when you understand Microsoft's strategic push toward a modern cloud native architecture.
• 26:23
  SPEAKER_01: Explain that.
• 26:24
  SPEAKER_00: Microsoft views traditional network-routed trusts as a security anti-pattern of the past.
• 26:29
  SPEAKER_00: They see intra-domain services as a highly specific tool, purpose-built for lifting and shifting legacy Azure workloads.
• 26:36
  SPEAKER_00: It is designed to act as a lifeboat.
• 26:38
  SPEAKER_01: A lifeboat!
• 26:39
  SPEAKER_00: Yes.
• 26:39
  SPEAKER_00: You move the legacy application into Azure.
• 26:42
  SPEAKER_00: You point at intra domain services for its Cabreros and LDF needs.
• 26:46
  SPEAKER_00: And by doing so, you intentionally sever the legacy network on Biblical cord to your on-premises data center.
• 26:52
  SPEAKER_01: Oh wow, so they force the break.
• 26:54
  SPEAKER_00: Microsoft does not want you building long-term, complex, vulnerable, routed trust networks spanning clouds and data centers.
• 27:01
  SPEAKER_00: They want you relying on Intra ID as the central modern hub and using domain services strictly to keep legacy apps breathing in isolated cloud pockets until you can finally rewrite them to support modern authentication.
• 27:14
  SPEAKER_01: That's wild.
• 27:15
  SPEAKER_01: AWS builds a bridge to your past.
• 27:18
  SPEAKER_01: Microsoft builds a lifeboat that cuts the cord to force you toward their modern cloud identity.
• 27:23
  SPEAKER_00: Exactly.
• 27:23
  SPEAKER_01: That is a profound strategic difference.
• 27:26
  SPEAKER_01: But what about that second limitation you mentioned?
• 27:28
  SPEAKER_01: Why does intra domain services force me to enable password hash sync from my on-premises environment?
• 27:34
  SPEAKER_00: This comes down to cryptography.
• 27:35
  SPEAKER_01: Okay, let's hear it.
• 27:47
  SPEAKER_00: Because UNTRA domain services is a one-way sync from the cloud down to the lifeboat, it forces you to sync those legacy hashes from your on-premises servers up into Intra ID in the cloud, just so they can then be synced back down into the managed domain where the legacy app can use them.
• 28:04
  SPEAKER_01: So to recap the multi-cloud reality here, AWS builds a bridge, Azure builds a lifeboat.
• 28:10
  SPEAKER_01: Exactly.
• 28:10
  SPEAKER_01: But we have to look beyond just Microsoft and AWS.
• 28:14
  SPEAKER_01: Many modern enterprises have a massive Google footprint, particularly with Google Workspace or data lakes in GCP.
• 28:21
  SPEAKER_01: Integrating Google into this stack introduces a new layer, GCP Cloud Identity.
• 28:26
  SPEAKER_00: Integrating Google requires careful architectural planning.
• 28:29
  SPEAKER_01: Yeah.
• 28:30
  SPEAKER_00: GCP Cloud Identity is Google's enterprise identity platform.
• 28:33
  SPEAKER_01: Right.
• 28:34
  SPEAKER_00: If an organization has a heavy Google footprint, how do you fit that into an environment where Intra ID is already acting as the definitive central passport office?
• 28:42
  SPEAKER_01: You definitely don't want users maintaining separate passwords, one for Azure and one for Google.
• 28:47
  SPEAKER_01: I mean, that's a massive security risk and a total nightmare for the help desk.
• 28:50
  SPEAKER_00: The cleanest architectural pattern here is federation.
• 28:52
  SPEAKER_01: Federation.
• 28:53
  SPEAKER_00: You configure GCP Cloud Identity to federate its authentication back to UNTRA ID.
• 28:58
  SPEAKER_00: When a user attempts to access a Google Cloud resource or open a Google Doc in Workspace, Google acts as the service provider.
• 29:06
  SPEAKER_00: It immediately redirects the authentication request to Entra ID.
• 29:10
  SPEAKER_01: So Entra ID plays the bouncer again.
• 29:12
  SPEAKER_00: Exactly.
• 29:12
  SPEAKER_00: Entra ID performs the contextual evaluation, it checks the device compliance, challenges for multifactor authentication, evaluates the location risk.
• 29:20
  SPEAKER_01: All the standard modern checks.
• 29:22
  SPEAKER_00: And if everything passes, entra ID generates a mathematically signed SAML or OIDC token and passes it back to Google.
• 29:29
  SPEAKER_00: Google trusts the signature and lets the user in.
• 29:31
  SPEAKER_01: Seamless.
• 29:41
  SPEAKER_01: Now we have Entra ID talking to AWS, Azure Legacy Domains, and Google.
• 29:46
  SPEAKER_01: We've centralized the human identity, but how do we securely manage what these humans are allowed to do across all these clouds without falling back into the Capital One trap of over-permissioned IAM roles?
• 29:58
  SPEAKER_00: This brings us to the architectural holy grail of modern cloud security.
• 30:03
  SPEAKER_00: Decoupling authentication, which is authentic from authorization, which is auth C, across cloud boundaries.
• 30:10
  SPEAKER_01: Let's clearly define the roles in this decoupled architecture, because historically, auth and auth C were bundled together in active directory, right?
• 30:18
  SPEAKER_01: You proved who you were, and the exact same server checked what groups you were in.
• 30:22
  SPEAKER_00: In a multi-cloud environment, you must separate them.
• 30:25
  SPEAKER_00: Entra ID authenticates the human.
• 30:27
  SPEAKER_00: It is the auth n engine.
• 30:28
  SPEAKER_01: Okay.
• 30:29
  SPEAKER_00: It proves that Bob is actually Bob, using biometrics, phyto2 keys, device compliance checks, and location signals.
• 30:36
  SPEAKER_00: But intra ID did not, and architecturally should not, know exactly which specific S3 buckets Bob is allowed to read in AWS?
• 30:44
  SPEAKER_01: Because if Entra ID tried to manage that, we'd be back to using a passport office to pick a padlock.
• 30:48
  SPEAKER_01: So where does the authorization happen?
• 30:50
  SPEAKER_00: That is where AWS IM Identity Center steps in to handle ATC.
• 30:54
  SPEAKER_01: Ah.
• 30:55
  SPEAKER_00: IM Identity Center takes over the authorization phase locally within AWS.
• 30:59
  SPEAKER_00: The architecture works by mapping intra-ID groups to specific AWS roles.
• 31:03
  SPEAKER_01: But how does AWS know who is in the UNTRA ID group if Entra is over in Azure?
• 31:08
  SPEAKER_00: Through an incredible protocol called SSCM, the system for cross-domain identity management.
• 31:13
  SPEAKER_01: I always think of SCM as an automated, highly aggressive HR department for the cloud.
• 31:18
  SPEAKER_00: That's a great way to view it.
• 31:19
  SPEAKER_00: SEM constantly syncs user metadata and group memberships from Intra ID into AWS.
• 31:25
  SPEAKER_01: So it's real time.
• 31:26
  SPEAKER_00: Essentially.
• 31:26
  SPEAKER_01: Essentially.
• 31:27
  SPEAKER_00: If Bob moves from finance to engineering, Intra ID updates his group.
• 31:32
  SPEAKER_00: SCM immediately tells AWS about the change.
• 31:35
  SPEAKER_01: Oh wow.
• 31:36
  SPEAKER_00: Because we are using SCM and Federation, we completely eliminate the need to create permanent, static IAMM users for employees.
• 31:44
  SPEAKER_01: So no more lingering keys.
• 31:46
  SPEAKER_00: Right.
• 31:46
  SPEAKER_00: Bob never gets a permanent AWS access key downloaded to his laptop.
• 31:50
  SPEAKER_00: When Bob logs into AWS, he authenticates via entra ID, and AWS temporarily maps him to a role based on his SCM-synced group.
• 31:58
  SPEAKER_00: He gets a temporary mathematically constrained session that evaporates after a few hours.
• 32:02
  SPEAKER_01: And if we connect this to the bigger picture, this decoupled model is precisely how you prevent the Capital One scenario.
• 32:08
  SPEAKER_00: Precisely.
• 32:09
  SPEAKER_01: Humans and the infrastructure acting on their behalf only get temporary context-evaluated keys precisely when they need them.
• 32:16
  SPEAKER_01: And those keys are governed locally by the authorization engine that actually understands the resources.
• 32:22
  SPEAKER_01: But AWS is pushing authorization even further now, aren't they?
• 32:25
  SPEAKER_01: They're moving beyond standard role-based access control, or RBAC, with a new open source policy language called CEDAR.
• 32:33
  SPEAKER_00: CEDAR is a fascinating evolution in how we write authorization roles.
• 32:37
  SPEAKER_00: It is the core language used in AWS verified access.
• 32:41
  SPEAKER_01: How does it differ from RBAC?
• 32:42
  SPEAKER_00: Traditional RBAC evaluates static assignments.
• 32:45
  SPEAKER_00: Bob is in the DP Admins group, therefore Bob can access the database.
• 32:49
  SPEAKER_00: It is a binary static check.
• 32:51
  SPEAKER_01: Right.
• 32:51
  SPEAKER_01: Very rigid.
• 32:52
  SPEAKER_00: CEDAR, however, evaluates per request contextual data.
• 32:56
  SPEAKER_01: What does per request evaluation actually look like in practice?
• 32:58
  SPEAKER_00: I mean CEDAR doesn't just look at the role you hold, it evaluates the live context of the specific network request you are making at that exact millisecond.
• 33:06
  SPEAKER_01: Oh wow.
• 33:07
  SPEAKER_01: Like what?
• 33:07
  SPEAKER_00: What is the IP address of the request?
• 33:09
  SPEAKER_00: What is the current time of day?
• 33:10
  SPEAKER_00: What is the exact health posture of the device making the request right now?
• 33:14
  SPEAKER_01: So it's not just asking, does Bob's key fit the lock?
• 33:17
  SPEAKER_01: It's asking, is this key being used by Bob, who is a deep admin during normal business hours from a corporately managed laptop that has its antivirus fully updated to open a database that isn't currently under a lockdown protocol.
• 33:31
  SPEAKER_00: Yes, exactly that.
• 33:32
  SPEAKER_00: And structurally, CEDAR is radically different from traditional policy languages because it is formally verified.
• 33:38
  SPEAKER_01: Formally verified.
• 33:39
  SPEAKER_00: That means it uses mathematical proofs to ensure that the policy you wrote behaves exactly mathematically as you intended, with zero unintended loopholes or conflicting overlapping rules.
• 33:49
  SPEAKER_01: Okay.
• 33:50
  SPEAKER_01: When you combine UNTRA ID's incredibly rich, context-aware authentication with AWS verified accesses per request, mathematically proven CEDER authorization, you unlock real-world scenarios that seemed impossible five years ago.
• 34:04
  SPEAKER_01: Which brings us to the ultimate application of everything we've discussed today: the zero trust VPN replacement.
• 34:10
  SPEAKER_00: This is where the theoretical architecture becomes a tangible victory for the end user.
• 34:14
  SPEAKER_00: Let's walk through a detailed user journey.
• 34:16
  SPEAKER_01: Set the scene.
• 34:17
  SPEAKER_00: Imagine an employee sitting in a local coffee shop.
• 34:20
  SPEAKER_00: They're on an untrusted public Wi-Fi network, and they urgently need to access a legacy, Koberos-dependent internal application that you migrated onto an AWS-managed Microsoft AD instance.
• 34:40
  SPEAKER_01: They would establish an IPsec tunnel.
• 34:42
  SPEAKER_01: And critically, the enterprise would have had to punch a hole in their perimeter, exposing inbound firewall ports to the public internet just to accept that tunnel connection.
• 34:51
  SPEAKER_00: Which is terrifying.
• 34:52
  SPEAKER_01: It was friction for the user and a massive attack surface for the company.
• 34:55
  SPEAKER_01: So how does our decoupled multi-cloud architecture handle this today?
• 34:59
  SPEAKER_00: Aaron Powell The technical magic here relies entirely on identity aware proxies, specifically using tools like intra private access or AWS verified access.
• 35:08
  SPEAKER_00: Okay.
• 35:09
  SPEAKER_00: Here is the flow.
• 35:10
  SPEAKER_00: The user simply opens their web browser in the coffee shop and types in the internal URL of the legacy application.
• 35:15
  SPEAKER_00: They don't launch a VPN.
• 35:17
  SPEAKER_01: No VPN at all.
• 35:18
  SPEAKER_00: The identity aware proxy sitting at the edge of the cloud environment intercepts that traffic.
• 35:24
  SPEAKER_00: It immediately redirects the user to Enter ID for authentication.
• 35:28
  SPEAKER_01: So it sends them to the passport office.
• 35:30
  SPEAKER_00: Yes.
• 35:30
  SPEAKER_00: The user performs a modern biometric authentication, perhaps looking at their camera for Windows Hobby Short.
• 35:36
  SPEAKER_01: Yeah.
• 35:36
  SPEAKER_00: Hello.
• 35:37
  SPEAKER_00: Or touching a FIDO2 security key.
• 35:39
  SPEAKER_01: Smooth.
• 35:40
  SPEAKER_00: Enter ID evaluates the context.
• 35:43
  SPEAKER_00: It sees the public IP of the coffee shop, validates that the laptop is healthy and compliant, and issues a modern session-based web token.
• 35:51
  SPEAKER_01: But wait, we spent an immense amount of time earlier establishing that the legacy application sitting in AWS only speaks Kerberos.
• 35:57
  SPEAKER_00: It does.
• 35:58
  SPEAKER_01: It doesn't understand JSON web tokens.
• 36:00
  SPEAKER_01: It's going to bounce that modern web token at the door.
• 36:02
  SPEAKER_00: This is where the proxy performs the critical cryptographic translation.
• 36:06
  SPEAKER_00: The identity aware proxy takes that modern biometric-backed web token from IntraID and securely communicates with the back-end cloud environment.
• 36:15
  SPEAKER_00: Because the proxy is deeply integrated into the architecture, it can dynamically translate that modern web token into a legacy Kerberos service ticket on behalf of the user.
• 36:23
  SPEAKER_01: That's incredible.
• 36:24
  SPEAKER_00: It essentially acts as a protocol bridge.
• 36:27
  SPEAKER_00: It then forwards that valid Kerberos ticket to the legacy application running on the AWS managed AD.
• 36:33
  SPEAKER_01: So what does this all mean?
• 36:35
  SPEAKER_01: We took a biometric context where passport evaluated in the cloud, and we dynamically translated it into the exact physical key the legacy locksmith needed, all completely invisibly to the user.
• 36:46
  SPEAKER_00: Invisible to the user.
• 36:47
  SPEAKER_01: The employee accesses a 20-year-old application from a coffee shop with zero friction.
• 36:51
  SPEAKER_01: There is no clunky VPN client to break.
• 36:54
  SPEAKER_01: And critically, from a security perspective, there are zero inbound firewall ports exposed to the public internet.
• 37:00
  SPEAKER_01: None.
• 37:01
  SPEAKER_01: The architecture handles the extreme complexity, cleanly enforcing modern zero trust principles on ancient technology.
• 37:07
  SPEAKER_00: Today we explored the architectural divide between Entra ID and AWS IAM and navigated the complexities of managed domain services for legacy workloads in a multi-cloud environment.
• 37:18
  SPEAKER_00: By decoupling authentication from authorization, organizations can secure legacy applications without relying on traditional VPNs.
• 37:26
  SPEAKER_00: That's a wrap on why your web firewall is an inside threat.
• 37:30
  SPEAKER_00: We closed on the fix for exactly the failure that opened this episode.
• 37:34
  SPEAKER_00: Decouple authentication from authorization.
• 37:37
  SPEAKER_00: Let Intra ID prove who someone is.
• 37:40
  SPEAKER_00: Let AWS IAM and CEDER decide what they can actually touch.
• 37:44
  SPEAKER_00: And stop handing infrastructure a master key it doesn't need.
• 37:48
  SPEAKER_00: Next episode, we go from one cloud role with too much access to 40 of them.
• 37:54
  SPEAKER_00: How to govern isolated OT tenants centrally.
• 37:58
  SPEAKER_00: Connect with Ernie on LinkedIn.
• 38:00
  SPEAKER_00: The links in the episode description.
• 38:02
  SPEAKER_00: Subscribe if this is useful.
• 38:03
  SPEAKER_00: Until next time.