WEBVTT 00:00:00.000 --> 00:00:06.560 You are listening to Support Engineering Weekly. Picture this scenario. It's like 00:00:06.560 --> 00:00:12.000 two in the morning. Oh, the classic IT nightmare hour. Right. The absolute best time. 00:00:12.000 --> 00:00:17.440 So your phone buzzes, wakes you up, and suddenly you are staring at this glaring monitor, 00:00:18.080 --> 00:00:23.360 trying to troubleshoot a user sign in that just refuses to work. And let me guess, 00:00:23.360 --> 00:00:27.200 it's not just some random user. Of course not. It's an executive. 00:00:28.160 --> 00:00:34.320 And they are completely locked out of like a highly sensitive business critical financial app. 00:00:34.879 --> 00:00:39.519 The pressure is totally on. The clock is ticking. Yeah, that is not a fun spot to be in. 00:00:39.519 --> 00:00:44.320 No, it's the worst. So you do what literally any support engineer is trained to do, right? 00:00:44.320 --> 00:00:49.440 You open up the Microsoft entry ID sign in logs. Naturally, you find the users failed attempt, 00:00:49.440 --> 00:00:53.680 you scroll down to that conditional access tab and right there in plain text, you see what looks 00:00:53.680 --> 00:00:58.800 like the answer. Policy A says require MFA. And right next to it is this beautiful bright green 00:00:58.800 --> 00:01:04.239 check mark. The Holy Grail. Exactly. The results as success. Yeah. So you breathe this massive 00:01:04.239 --> 00:01:09.680 sigh of relief, but then it's still blocked. Yes. The user is still on the phone yelling that 00:01:09.680 --> 00:01:16.400 they're staring at a massive access denied screen. They literally cannot get in. And you're just 00:01:16.400 --> 00:01:21.840 sitting there thinking, how on earth is that possible? It's a completely mind-bending moment, 00:01:21.840 --> 00:01:25.760 the first time you see it. It really is. So welcome to this deep dive on support 00:01:25.760 --> 00:01:31.440 Engineering Weekly. I'm Alex. And I'm Maya. Thank you so much for joining us today to untangle this 00:01:31.440 --> 00:01:37.840 exact mystery. Yeah, today's deep dive is laser focused on Microsoft and for ID conditional access. 00:01:37.840 --> 00:01:43.120 We're breaking down why the traditional mental model, like the one most of us have for security 00:01:43.120 --> 00:01:48.320 rules, is just completely backwards in the cloud. It really is. We're going to explore how 00:01:48.320 --> 00:01:53.440 Microsoft actually makes these access decisions under the hood. And most importantly, why stopping 00:01:53.440 --> 00:01:58.960 at that very first green check mark in a log is a guaranteed way to keep your executives locked out. 00:01:58.960 --> 00:02:03.600 Yeah. So to understand why the user in your opening scenario was blocked despite that MFA 00:02:03.600 --> 00:02:08.000 success, we kind of have to unlearn almost everything traditional networking has taught us. 00:02:08.000 --> 00:02:13.440 Oh, big time. Unlearning is the hardest part. It is because the root of this whole troubleshooting 00:02:13.520 --> 00:02:20.240 nightmare usually stems from visualizing conditional access as a like a traditional network firewall. 00:02:20.240 --> 00:02:25.520 Let's unpack that firewall mentality for a second, because I mean, it is incredibly ingrained in how 00:02:25.520 --> 00:02:31.200 IT professionals think. Oh, completely. It's day one network. Exactly. When you picture a firewall, 00:02:31.200 --> 00:02:37.760 you visualize a router processing packets of data. So a packet arrives and it hits an access control 00:02:37.760 --> 00:02:42.720 list. It checks policy one. If it passes, it moves to policy two. Great. It's walking down the list. 00:02:42.720 --> 00:02:47.920 Right. And if policy two denies it, boom, the packet drops, the evaluation stops right then 00:02:47.920 --> 00:02:52.720 and there and the firewall saves its CPU cycles. Because why keep checking rules if you already 00:02:52.720 --> 00:02:58.320 denied it, right? Exactly. It's a top down sequential list. Yeah. But I mean, the documentation we are 00:02:58.320 --> 00:03:03.360 analyzing today makes it very, very clear that treating conditional access like a sequential 00:03:03.360 --> 00:03:08.960 firewall is just a fundamental trap. Yeah, it's a huge trap because the architecture of cloud 00:03:08.960 --> 00:03:14.000 identity platforms simply does not operate like a network appliance doing sequential packet 00:03:14.000 --> 00:03:20.160 inspection. So how does it operate? Well, Microsoft untritt conditional access relies on a parallel 00:03:20.160 --> 00:03:25.600 processing model. Okay, parallel processing. Yeah. When a user attempts to sign in, the system 00:03:25.600 --> 00:03:31.680 takes this massive snapshot of their real time context. It looks at the user's identity, the 00:03:33.040 --> 00:03:37.600 health state of the device they're holding, the IP address they're coming from. Even real time 00:03:37.600 --> 00:03:42.799 risk signals, right? Right. From threat intelligence. Exactly. It grabs all of that. It takes that 00:03:42.799 --> 00:03:48.720 entire contextual snapshot and evaluates it simultaneously against every single active policy 00:03:48.720 --> 00:03:52.799 you have configured in your tenant. Wait, I have to challenge the mechanics of that for a second. 00:03:52.799 --> 00:03:58.640 Sure, go for it. Because if I'm an enterprise administrator, I might have like 200 different 00:03:58.640 --> 00:04:03.280 conditional access policies deployed across my global workforce very easily. Yeah. Right. So if 00:04:03.280 --> 00:04:09.600 a user signs in, an entra evaluates all 200 policies simultaneously, doesn't that parallel 00:04:09.600 --> 00:04:14.880 processing create like massive latency? You'd think so. Yeah. I mean, evaluating that much logic, 00:04:14.880 --> 00:04:20.079 all at one sounds like a huge performance bottleneck compared to a firewall that could just drop a 00:04:20.079 --> 00:04:24.800 connection at rule number one. It's a really logical concern. But it actually points to why 00:04:24.800 --> 00:04:29.440 parallel processing is absolutely necessary for identity. How so? Well, think about what a 00:04:29.440 --> 00:04:34.400 firewall looks at. Simple headers, right? Source IP, destination port, super fast. 00:04:35.200 --> 00:04:40.800 But identity evaluation requires these really complex database lookups. Oh, like checking 00:04:40.800 --> 00:04:46.159 in tune for device compliance. Exactly. Checking device compliance and in tune or, you know, 00:04:46.159 --> 00:04:52.320 verifying user risk and identity protection. If entra evaluated those state checks sequentially, 00:04:52.320 --> 00:04:57.360 like waiting for policy ones device check to return before even starting policy to his location 00:04:57.440 --> 00:05:01.520 check, whole user would be staring at a loading screen for like 30 seconds. 00:05:01.520 --> 00:05:05.920 Precisely. It would be an awful user experience. So parallel processing queries, 00:05:05.920 --> 00:05:10.800 all those required states at once the engine evaluates the context instantly across all policies, 00:05:10.800 --> 00:05:15.200 rather than just, you know, walking down a line. Okay, that structural difference makes sense. 00:05:15.200 --> 00:05:19.760 But it means we need a totally new way to visualize the process for you as an engineer. 00:05:19.760 --> 00:05:24.720 We definitely do. So instead of a series of security doors that you have to unlock one by one, 00:05:25.680 --> 00:05:31.760 what if we picture conditional access as like a committee? A committee. I like that. Yeah. 00:05:31.760 --> 00:05:34.640 Imagine you have this entire board of directors sitting around a big table. 00:05:35.280 --> 00:05:40.320 A user walks in and requests access to an application. Okay. The entire committee 00:05:40.880 --> 00:05:46.000 looks at the user's context all at once. And every committee member, meaning every policy 00:05:46.000 --> 00:05:51.280 looks at the data and then drops their specific security requirements into this collective bucket 00:05:51.280 --> 00:05:54.479 right in the middle of the table. The collective bucket of requirements. 00:05:54.479 --> 00:05:59.280 That is honestly the perfect mental model. It helps, right? It does because shifting to that 00:05:59.280 --> 00:06:04.640 visualization completely changes the central question of troubleshooting. You can no longer ask 00:06:04.640 --> 00:06:10.239 which policy one or which policy blocked the user. Right. Because they aren't competing. 00:06:10.239 --> 00:06:15.520 Exactly. In a parallel model, policies don't compete with each other to win out. The required 00:06:15.520 --> 00:06:20.719 engineering question actually becomes what requirements were thrown into the bucket by the committee 00:06:20.720 --> 00:06:25.360 and which of those specific requirements remained unsatisfied. Because it's all about what's left 00:06:25.360 --> 00:06:32.400 in the bucket. Right. The final decision to grant or block access is based purely on whether every 00:06:32.400 --> 00:06:37.680 single requirement in that collective bucket has been successfully satisfied by the user's current 00:06:37.680 --> 00:06:43.040 context. But wait, if every policy on the tenant drops a requirement into the bucket, 00:06:43.600 --> 00:06:48.960 wouldn't a large organization's bucket just overflow on every single sign in? What do you mean? 00:06:48.960 --> 00:06:53.840 Well, a frontline worker checking their email shouldn't have to satisfy the exact same requirements 00:06:53.840 --> 00:06:58.320 as like a domain administrator accessing Azure infrastructure. Right. 00:06:58.320 --> 00:07:02.640 Definitely not. So how does Entra keep the bucket from filling up with all these irrelevant 00:07:02.640 --> 00:07:07.919 requirements? Okay. So that brings us to the crucial first filter of the evaluation process, 00:07:07.919 --> 00:07:12.640 which is applicability. Applicability, okay. Yeah. Before we look at what requirements are 00:07:12.640 --> 00:07:16.719 inside the bucket, we have to determine which committee members are actually invited to the 00:07:16.720 --> 00:07:22.240 meeting for that specific sign in got it. A policy only becomes applicable, meaning it only 00:07:22.240 --> 00:07:27.760 earns the right to drop a requirement into the bucket. If the sign in context is an exact match 00:07:27.760 --> 00:07:32.480 for both the assignments and the conditions of that policy, we should probably define those two 00:07:32.480 --> 00:07:35.440 categories to make sure the terminology is super clear for everyone listening. Yeah, 00:07:35.440 --> 00:07:41.680 that's a good idea. So assignments dictate the who and the what, like who was the policy targeting 00:07:41.680 --> 00:07:46.640 which users or groups? And what are they trying to access which cloud applications or actions? 00:07:46.800 --> 00:07:52.400 Right. And then conditions, on the other hand, define the circumstances of that access attempt. 00:07:52.400 --> 00:07:58.000 The context. Exactly. Are they coming from a trusted location? Are they using an Android device 00:07:58.000 --> 00:08:03.040 or a Windows device? Is their sign in flagged as high risk by the system? Okay. So the critical 00:08:03.040 --> 00:08:07.680 mechanical detail there is that all of those configured assignments and conditions within a 00:08:07.680 --> 00:08:14.320 single policy are logically combined using a strict and de operator. Yes. A very strict Andy. 00:08:14.320 --> 00:08:20.240 Right. If the policy targets the finance group and D the application sales force and D the platform 00:08:20.240 --> 00:08:27.120 Android, the sign in must match all three of those. All three. If even one of those parameters doesn't 00:08:27.120 --> 00:08:32.880 align with the reality of the user sign in, the entire policy is just ignored. It evaluates to 00:08:32.880 --> 00:08:37.919 a state the logs call not applied. You know, the sources provide a very specific scenario that 00:08:37.919 --> 00:08:42.480 illustrates this perfectly. They called the Alice scenario. Oh, yeah, the Alice scenario is a great 00:08:42.480 --> 00:08:48.000 example. It really is. So imagine you have a conditional access policy. The assignment targets 00:08:48.000 --> 00:08:53.360 all users. The target application is SharePoint. And the condition is set to the device platform 00:08:53.360 --> 00:08:59.040 iOS. Okay. Simple enough. Now a user named Alice signs in to SharePoint, but she happens to do it 00:08:59.040 --> 00:09:05.760 from a Windows laptop. My immediate instinct looking at that configuration is that the policy sees Alice 00:09:05.760 --> 00:09:11.920 on a Windows machine realizes she is violating the iOS rule and blocks her. And that is the 00:09:11.920 --> 00:09:16.719 assumption almost everyone makes. It feels right. It does. But it fundamentally misreads how the 00:09:16.719 --> 00:09:22.160 engine works. Let's let's trace the engine's logic here. Okay, let's do it. User Alice. That 00:09:22.160 --> 00:09:28.640 matches the all users assignment. Right. Application SharePoint. That matches the target app platform 00:09:28.640 --> 00:09:35.839 Windows. But the policy explicitly looks for iOS. Right. Because that single platform condition 00:09:35.839 --> 00:09:41.599 fails to match the sign in context, the policy just stops evaluating. The final result for that 00:09:41.680 --> 00:09:48.320 specific policy is simply not applied. It just bows out. Exactly. The policy didn't evaluate Alice 00:09:48.320 --> 00:09:53.520 and reject her access. It simply wasn't part of the access decision at all. It was never invited to 00:09:53.520 --> 00:10:00.160 the committee. So it threw zero requirements into the bucket. Wow. The psychological trap there is 00:10:00.160 --> 00:10:05.200 just massive when you are troubleshooting a live outage. It's brutal. Because you're skimming the 00:10:05.200 --> 00:10:10.240 sign in logs at a million miles an hour. An executive is yelling you see this great out 00:10:10.320 --> 00:10:17.360 not applied status next to a policy you recently built. And I mean, the human brain just hates 00:10:17.360 --> 00:10:22.160 unresolved patterns. We want to fix things. We do. It is so easy to assume the policy is broken, 00:10:22.160 --> 00:10:27.600 or that this gray not applied status is somehow the active cause of the outage. Engineers will 00:10:27.600 --> 00:10:33.040 literally spend hours tweaking the conditions of a not applied policy, trying to fix a block that 00:10:33.040 --> 00:10:37.280 is actually being caused by something else entirely. I've seen it happen so many times. 00:10:37.920 --> 00:10:42.480 Separating the policy configuration from the real time sign in evaluation is a learned 00:10:42.480 --> 00:10:49.040 its skill. It really is. When you are under pressure, any log result that isn't a bright green success 00:10:49.040 --> 00:10:54.880 feels like an enemy you need to defeat. But if a policy is not applied, it mathematically cannot 00:10:54.880 --> 00:10:59.600 block the user. Full stop. Full stop. You have to learn to filter those out immediately and focus 00:10:59.600 --> 00:11:04.640 only on the policies that actually apply to the event. So once we filter out the noise, right, 00:11:04.640 --> 00:11:09.520 and identify the policies that did apply, we face the reality of an enterprise environment. 00:11:09.520 --> 00:11:14.480 And that reality is that a single sign in is almost never governed by just one policy. 00:11:14.480 --> 00:11:19.840 Almost never. So what happens when multiple applicable policies collide on a single sign in? 00:11:19.840 --> 00:11:24.960 Well, the collision of multiple applicable policies is the norm, not the exception. And because of 00:11:24.960 --> 00:11:29.360 that parallel processing model we talked about, they do not cancel each other out. They stack. 00:11:29.440 --> 00:11:35.520 Exactly. UNTRAC combines the requirements of all applicable policies using a logical AE. 00:11:36.160 --> 00:11:42.400 If policy A applies and requires MFA, and a completely separate policy B applies and requires a 00:11:42.400 --> 00:11:47.600 compliant device, both of those requirements are dumped into the collective bucket. Okay. 00:11:47.600 --> 00:11:51.760 The sources outline a SharePoint collision scenario to really ground this concept. 00:11:51.760 --> 00:11:57.200 Let's walk through it. Let's do it. A user attempts to access SharePoint. Policy A applies to this 00:11:57.200 --> 00:12:02.320 sign in and it demands MFA. The user receives the prompt on their authenticator app and they 00:12:02.320 --> 00:12:08.160 approve it. Nice and easy. Right. In the logs for policy A, the result logs as a success. Yeah. 00:12:08.160 --> 00:12:13.040 However, policy B also applies to this exact same sign in and its requirement is that the user 00:12:13.040 --> 00:12:17.760 must be on a compliant device, meaning a device managed by Intune and meeting all the security 00:12:17.760 --> 00:12:22.240 baselines. Right. Checking device health. But the user happens to be working from their personal 00:12:22.240 --> 00:12:27.520 unmanage home computer. So policy B results in failure. Yeah. Now, even though policy A was 00:12:27.520 --> 00:12:33.280 a complete success, the overall decision for the sign in is access denied. And the mechanism behind 00:12:33.280 --> 00:12:38.640 that denial is exactly what catches people off guard. Because of the log view. Yes. An engineer 00:12:38.640 --> 00:12:45.600 opens the sign in logs, expands the conditional access tab, sees policy A success, and prematurely 00:12:45.600 --> 00:12:50.480 concludes the conditional access allowed the user. Oh, like in our two AM scenario. Exactly like 00:12:50.560 --> 00:12:55.200 that. They think, while the MFA policy succeeded, so the authentication is fine, 00:12:55.200 --> 00:12:59.760 the problem must be the SharePoint application itself. They start looking in totally the wrong 00:12:59.760 --> 00:13:06.080 place. Right. But a successful MFA requirement from one policy does not magically override or 00:13:06.080 --> 00:13:11.680 cancel a failed device requirement from another policy. It functions exactly like a highly secure 00:13:11.680 --> 00:13:16.960 VIP nightclub. A nightclub. Okay, I'm listening. Yeah, think about it. Conditional access is the 00:13:16.960 --> 00:13:22.400 security team at the front door. Yeah. Policy A is the bouncer checking your ID to verify you 00:13:22.400 --> 00:13:27.280 are who you say you are. That is your MFA check. Right. Policy B is a second bouncer checking the 00:13:27.280 --> 00:13:32.080 dress code to ensure you are wearing a suit. That is your compliant device requirement. I see where 00:13:32.080 --> 00:13:36.960 you're going with this. Right. Just because you handed your ID to the first bouncer and pass the 00:13:36.960 --> 00:13:41.040 identity check, that doesn't mean you get to ignore the dress code and stroll into the club 00:13:41.040 --> 00:13:46.800 wearing flip flops. Both bouncers have to give you the nod independently. The nightclub in 00:13:46.800 --> 00:13:52.000 analogy perfectly illustrates it. Passing one control doesn't grant you a free pass on the overall 00:13:52.000 --> 00:13:58.319 evaluation. You need both nods. Exactly. The final outcome isn't dictated by the policy that 00:13:58.319 --> 00:14:03.599 succeeded. The outcome is dictated entirely by the requirement in the collective bucket that 00:14:03.599 --> 00:14:09.760 remain unsatisfied. The flip flops. The flip flops. This is why troubleshooting requires analyzing the 00:14:09.760 --> 00:14:15.680 complete collection of applicable policies rather than hunting for a single point of success. But 00:14:16.000 --> 00:14:20.479 getting past those front door requirements is really only half the battle, isn't it? For sure. 00:14:20.479 --> 00:14:26.079 Passing MFA and having a compliant device might get you into the nightclub. But conditional access 00:14:26.079 --> 00:14:31.520 have these hidden layers of evaluation that can still catch an engineer completely off guard. 00:14:31.520 --> 00:14:36.400 It's a deep system. It is. I want to dig into the technical distinction between MFA and 00:14:36.400 --> 00:14:42.000 authentication strength because the assumption is often, well, MFA is just MFA. If they typed a 00:14:42.000 --> 00:14:47.600 code they should be in relying on that generic concept of MFA is actually a massive vulnerability 00:14:47.600 --> 00:14:53.520 in modern architecture. Really? A massive vulnerability? Yeah. Simply completing an MFA prompt does not 00:14:53.520 --> 00:14:57.840 mean the user satisfied and authentication strength requirement. They are distinctly different 00:14:57.840 --> 00:15:05.600 mechanisms. How so? While a user might complete MFA by receiving a six digit code via SMS text message 00:15:06.320 --> 00:15:10.320 that technically qualifies as multi-factor authentication. Right. It's two factors. 00:15:10.880 --> 00:15:16.400 But SMS is highly susceptible to phishing and sim swapping attacks. So a conditional access 00:15:16.400 --> 00:15:21.440 policy might be configured to demand a specific phishing resistant authentication strength like 00:15:21.440 --> 00:15:28.080 a FIDO2 security key. Okay. So the logs might show that the user successfully performed an SMS text 00:15:28.080 --> 00:15:33.920 MFA. But the requirement dropped into the bucket wasn't just do any MFA. The requirement was 00:15:34.479 --> 00:15:39.920 provide cryptographic proof of identity using a hardware key. So if the user provided the text 00:15:39.920 --> 00:15:44.959 message code instead of the hardware key, they supplied the wrong flavor of authentication and 00:15:44.959 --> 00:15:49.920 they are still denied. That's exactly it. The evaluation engine is checking for the exact claims 00:15:49.920 --> 00:15:56.560 in the token. If the policy demands the FIDO2 claim and the token only presents an SMS claim, 00:15:56.560 --> 00:16:02.400 the requirement remains unsatisfied. That is a subtle but huge difference. It is. And the 00:16:02.400 --> 00:16:07.280 evaluation doesn't even stop at the authentication method. Microsoft structures conditional access 00:16:07.280 --> 00:16:12.319 in distinct phases. Okay. Phases. Right. The grant controls like authentication strength or device 00:16:12.319 --> 00:16:17.360 compliance. They happen first. They determine if the token is issued at all. But then we moved 00:16:17.360 --> 00:16:21.600 to the next phase, which is session controls. Oh, this is where the bouncers continue to watch 00:16:21.600 --> 00:16:27.040 what you do inside the club. Exactly. Even if you are granted access, session controls can heavily 00:16:27.040 --> 00:16:31.439 restrict your post authentication experience. So you're in, but you're restricted. Right. 00:16:31.440 --> 00:16:36.000 Session controls operate after the initial token is issued by injecting restrictions into 00:16:36.000 --> 00:16:41.120 how the application handles that token. Like what kind of restrictions? Well, a policy might enforce 00:16:41.120 --> 00:16:46.720 a strict sign in frequency forcing the application to reauthenticate the user every four hours, 00:16:46.720 --> 00:16:51.360 regardless of their activity. Wow. Or it might utilize conditional access app control. 00:16:52.080 --> 00:16:57.360 This actually routes the user's session through a Microsoft reverse proxy. 00:16:57.360 --> 00:17:03.120 Okay. So they're proxying the traffic. Why? So that the user can view sensitive documents in the 00:17:03.120 --> 00:17:08.800 browser, but the proxy intercepts and blocks any attempt to download those documents to their local 00:17:08.800 --> 00:17:14.160 hard drive. Oh, that's clever. Yeah. So a success on the grant controls simply means you got in. 00:17:14.160 --> 00:17:19.760 It does not guarantee an unrestricted session. That's wild. And the idea that access isn't just a 00:17:19.760 --> 00:17:26.160 binary yes or no at the front door becomes even more apparent when we look at authentication context. 00:17:26.160 --> 00:17:30.800 Oh, authentication context is fascinating. It really highlights the depth of the engine, 00:17:30.800 --> 00:17:35.760 because this is where access decisions can happen mid session. So how does the application actually 00:17:35.760 --> 00:17:40.800 communicate with Entra to trigger a new requirement when the user is already logged in? 00:17:40.800 --> 00:17:44.960 The mechanism behind authentication context relies on claims challenges. 00:17:44.960 --> 00:17:51.120 Claims challenges. Okay. Yeah. Traditionally, a user signs in, gets a token, and works until 00:17:51.120 --> 00:17:57.199 the token expires. But with authentication context, the evaluation becomes highly granular. 00:17:57.199 --> 00:18:02.000 Imagine a user browsing a SharePoint site. Okay. They're in SharePoint. Their current token is 00:18:02.000 --> 00:18:07.919 perfectly valid for reading standard company news. But then they click a button to download a highly 00:18:07.919 --> 00:18:13.280 confidential financial report. The SharePoint application is actually coded to recognize that 00:18:13.280 --> 00:18:19.600 specific action as sensitive. So the application intercepts the action and realizes the user's 00:18:19.679 --> 00:18:23.600 current token isn't strong enough for this specific elevated task. 00:18:23.600 --> 00:18:28.240 Precisely. The application issues a claims challenge. It essentially bounces the user's 00:18:28.240 --> 00:18:32.719 session back to Entra ID and says, Hey, this user wants to access a protected context, 00:18:32.719 --> 00:18:37.360 evaluate them again. Mid session. Mid session. Entra then looks to see if an authentication 00:18:37.360 --> 00:18:41.600 context policy is tied to that action. It might layer on a sudden new requirement, 00:18:41.600 --> 00:18:46.000 like stepping up to a fight or two key, or suddenly requiring them to agree to a custom 00:18:46.000 --> 00:18:50.960 terms of use right in that exact moment. And if they pass it, once the user satisfies that 00:18:50.960 --> 00:18:56.640 new requirement, Entra issues a new token with the upgraded claims and hands the session back 00:18:56.640 --> 00:19:02.160 to SharePoint. It proves that conditional access dictates interactions continuously, 00:19:02.160 --> 00:19:06.960 not just at the initial login screen. I mean, the theory and the mechanisms are fascinated, 00:19:06.960 --> 00:19:12.560 but when that VIP executive is locked out and the help desk queue is blowing up, you really need a 00:19:12.560 --> 00:19:16.000 practical methodology. You definitely do. You don't have time for theory. 00:19:16.000 --> 00:19:20.800 Right. You need to find that one unmet requirement in the bucket. And you need to do it without 00:19:20.800 --> 00:19:25.840 making the security posture worse. Let's explore the tools of the trade. Good idea. 00:19:25.840 --> 00:19:31.120 If I'm troubleshooting our locked out executive, my immediate instinct is to open the what if tool 00:19:31.120 --> 00:19:35.760 in the Azure portal, plug in their name and just see why they were blocked. And that instinct will 00:19:35.760 --> 00:19:40.800 lead you down a very, very frustrating path. Really? Why? Because what if is a powerful tool, 00:19:40.800 --> 00:19:44.879 but it is built for hypothetical simulations, not historical forensics? 00:19:44.879 --> 00:19:45.440 Okay. 00:19:45.440 --> 00:19:51.840 When you use what if, you manually input a user, an app, and an IP address, and Entra generates 00:19:51.840 --> 00:19:57.120 a hypothetical token context to show you what would apply if that exact scenario happens. 00:19:57.120 --> 00:19:58.720 So it's not looking at the past. 00:19:58.720 --> 00:20:04.320 Exactly. It does not read historical data. It doesn't know what actually occurred at 2.0 AM 00:20:04.320 --> 00:20:05.919 on that specific laptop. 00:20:06.000 --> 00:20:13.600 Okay. So if what if is for testing hypothetical policy scope and report only mode is for analyzing 00:20:13.600 --> 00:20:20.000 the impact of a policy before enforcing it, that leaves the sign in logs as the only viable tool 00:20:20.000 --> 00:20:26.400 for a live outage. Yes. The sign in logs are your ground truth. They're the immutable historical 00:20:26.400 --> 00:20:32.400 record of the exact context, the exact device state, and the exact requirements that were evaluated 00:20:32.400 --> 00:20:36.000 in that specific millisecond. You don't guess what happened. You read the receipt. 00:20:36.000 --> 00:20:37.200 Read the receipt exactly. 00:20:37.200 --> 00:20:40.240 But reading that receipt requires discipline. You can't just skim it. 00:20:40.240 --> 00:20:44.640 The source material outlines an authoritative six step practical reading order for engineers 00:20:44.640 --> 00:20:45.360 to follow. 00:20:45.360 --> 00:20:49.440 Let's virtually open up the log for our locked out VIP and walk through this together. 00:20:49.440 --> 00:20:50.080 Let's do it. 00:20:50.080 --> 00:20:56.000 Step one is simply identifying the correct event. I'm assuming we don't want to look at the users 00:20:56.000 --> 00:21:02.160 overall history for the week. We need to isolate this specific log entry for the exact moment 00:21:02.160 --> 00:21:04.160 they receive the error on their screen. 00:21:04.160 --> 00:21:09.360 Finding the exact timestamp is critical because context fluctuates. A device might be compliant 00:21:09.360 --> 00:21:14.000 at 2.00 am and non-compliant at 2.05 am. 00:21:14.000 --> 00:21:14.640 Wow. Okay. 00:21:14.640 --> 00:21:19.760 So once you have that specific log entry open, you move to step two. Identify all applicable 00:21:19.760 --> 00:21:21.280 conditional access policies. 00:21:21.280 --> 00:21:23.440 So I'm looking at the list of policies under the tab. 00:21:23.440 --> 00:21:27.120 Right. You will see a list of policies under the tab. Immediately filter out anything that says 00:21:27.120 --> 00:21:31.040 not applied. You only care about the policies that were actually invited to the committee. 00:21:31.040 --> 00:21:35.520 Okay. I have filtered out the noise. I am left with three policies that say they applied. 00:21:36.080 --> 00:21:39.920 Step three tells me to determine what each of those applicable policies requires. 00:21:39.920 --> 00:21:40.399 Yep. 00:21:40.399 --> 00:21:46.000 So I need to open policy A, policy B and policy C individually and read their grant controls. 00:21:46.000 --> 00:21:50.720 Let's say policy A required MFA, policy B required a compliant device, 00:21:50.720 --> 00:21:53.920 policy C required a hybrid Azure AD joined device. 00:21:54.480 --> 00:21:57.120 I have officially built my bucket of requirements. 00:21:57.120 --> 00:21:59.280 Perfect. Now you execute step four. 00:22:00.080 --> 00:22:02.639 Check which of those requirements were satisfied. 00:22:02.639 --> 00:22:02.960 Okay. 00:22:02.960 --> 00:22:06.800 You look at the authentication details in the log. Did they pass MFA? 00:22:06.800 --> 00:22:09.440 The log says the MFA requirement was satisfied. 00:22:10.160 --> 00:22:15.360 Good. Which brings us to step five, the entire crux of the troubleshooting process. 00:22:15.920 --> 00:22:18.480 Find the requirement that was not satisfied. 00:22:18.480 --> 00:22:25.760 So I am not looking for the policy that one or the MFA check that succeeded. I am hunting for 00:22:25.760 --> 00:22:29.040 the specific requirement in my bucket that failed. 00:22:29.040 --> 00:22:29.840 Exactly. 00:22:29.840 --> 00:22:34.640 I see it. The device compliance check failed because the Intune sync hadn't completed. 00:22:34.640 --> 00:22:36.800 And that leads naturally to step six. 00:22:36.800 --> 00:22:39.280 Determine the resulting access or session outcome. 00:22:39.280 --> 00:22:42.000 Because you identified that unmet device requirement, 00:22:42.000 --> 00:22:46.080 you understand the true root cause of why the overall decision was in access to NIL. 00:22:46.080 --> 00:22:48.480 So I don't disable the policy or exclude the user. 00:22:48.480 --> 00:22:51.520 No. You instruct the user to sync their device with Intune. 00:22:51.520 --> 00:22:54.320 That methodology completely removes the guesswork. 00:22:54.320 --> 00:22:57.840 Identify the sign in, filter for what applies, list the requirements in the bucket, 00:22:57.840 --> 00:23:01.200 see what passed, hunt for what failed and confirm the outcome. 00:23:01.200 --> 00:23:04.560 Following those steps means you stop panicking and you start engineering. 00:23:04.560 --> 00:23:05.200 I love that. 00:23:05.200 --> 00:23:05.600 Yeah. 00:23:05.600 --> 00:23:07.439 Let's synthesize all of this. 00:23:07.439 --> 00:23:10.240 If you take away anything from this deep dive, let it be this. 00:23:11.040 --> 00:23:16.320 Conditional access is a parallel evaluation, not a sequential checklist. 00:23:16.320 --> 00:23:16.960 Absolutely. 00:23:16.960 --> 00:23:19.520 You must abandon the firewall mentality. 00:23:19.520 --> 00:23:23.439 Do not look for a policy that one, hunt for the requirement that 00:23:23.440 --> 00:23:25.120 remained unsatisfied. 00:23:25.120 --> 00:23:30.160 A single policy showing success does not equal overall access to the application. 00:23:30.160 --> 00:23:34.160 And remember the psychological trap, not applied, does not mean failure. 00:23:34.160 --> 00:23:37.440 It just means the policy wasn't part of the conversation. 00:23:37.440 --> 00:23:40.640 As we look toward the future of zero trust architecture, 00:23:40.640 --> 00:23:42.640 I know you had a thought on where this is all heading. 00:23:42.640 --> 00:23:46.000 Yeah. I want to leave you with a forward looking engineering challenge. 00:23:46.000 --> 00:23:49.920 Conditional access is evolving beyond just checking your ID at the front door. 00:23:49.920 --> 00:23:53.200 We are moving into the era of continuous access evaluation. 00:23:54.320 --> 00:23:55.040 Right. 00:23:55.040 --> 00:24:00.560 What happens when a device's health state fluctuates mid-session entirely behind the scenes 00:24:00.560 --> 00:24:03.120 faster than a human administrator can even track? 00:24:03.680 --> 00:24:08.640 Imagine an EDR sensor suddenly flagging a background process on a laptop as malicious. 00:24:09.280 --> 00:24:11.120 That signal is sent to Entra. 00:24:11.120 --> 00:24:16.320 The user's risk level elevates instantly and their access token is revoked in real time, 00:24:16.320 --> 00:24:17.920 completely severing their session. 00:24:17.920 --> 00:24:19.280 Without them doing anything. 00:24:19.280 --> 00:24:20.160 Exactly. 00:24:20.240 --> 00:24:25.040 Will future troubleshooting require us to reconstruct the exact millisecond of context 00:24:25.040 --> 00:24:29.040 to understand an access denial that happened without a traditional sign-in event? 00:24:29.040 --> 00:24:32.720 The days of simply looking at a static log entry are ending. 00:24:32.720 --> 00:24:36.800 We are entering an era where understanding the real time fluidity of context 00:24:36.800 --> 00:24:39.200 is the only way to troubleshoot access. 00:24:39.200 --> 00:24:43.040 You've been listening to Support Engineering Weekly from the Support Engineering Blog. 00:24:43.040 --> 00:24:46.880 For the full articles, references, and technical resources from today's discussion, 00:24:46.880 --> 00:24:49.840 visit the URL blog.sadhan.ch. 00:24:50.720 --> 00:24:54.720 Until next week, keep troubleshooting, keep learning, and keep engineering. 00:24:55.920 --> 00:24:58.640 Thank you for listening to Support Engineering Weekly. 00:24:59.360 --> 00:25:04.640 This podcast is available on Spotify, Apple Podcast, YouTube, and other major 00:25:04.640 --> 00:25:16.720 podcast platforms. Follow the show on your preferred platform and never miss an episode.