When is Azure AD Conditional Access evaluated? – Deep-dive

hello and welcome you may know that Azure ad evaluates conditional access every time there's an authentication event but what triggers an authentication event it could be when a user signs in it could be when a cookie is used to prove Authentication or a refresh token is used to refresh an access token or it could be when an API issues a claims challenge as part continuous access evaluation in this deep dive session I will reveal these triggers don't forget to subscribe and keep learning come with me into the cloud okay let's start by thinking about what is the core functionality of azure ad its core purpose is to securely authenticate users and workloads against applications and those applications could be Cloud software as a service apps such as Office 365 they could be on-premise apps that are protected by sort of some hybrid secure access Gateway such as the Azure 80 application proxy or they could be third-party apps partner apps and so on but the first thing that we need to arrange is for all of our users to be authenticated by Azure ad and once we have our users authenticated by Azure ad the next thing is we can trigger the conditional access policy engine and that policy engine is going to make a decision as to whether we allow the user or the workload identity access to a particular application and it takes into account a whole range of signals now I'm not going to go into the details of those signals in this particular video for those details watch my Azure ad conditional access the gateway to xero trust video so we've got signals coming from users and workloads and then we've got also Microsoft's own threat intelligence signals that are coming in so evaluating risk and then we've got signals from devices that are coming in and we might be using InTune we might recognize the operating system that's being used and so on those signals are coming in and we're going to make a decision as to whether we allow access to the application we can enhance the signals with things like Microsoft Defender products with using in tune for looking at the device and making sure the device is compliant next job are we going to low access well we've got a number of things we can do we can block access completely we could ask for Assurance to be increased by doing MFA or in certain circumstances we could remediate we could force a password reset onto a user if we decide to allow access to an app the next thing that can be done is we can apply session controls and as I say watch my other video to see all the details of this this video is about the siding when conditional access is actually evaluated and it's evaluated every time a request is made for a saml token and a saml token could be got through saml protocol or maybe even WS Federation protocol also if you request an ID token so that's open ID connect or we request an access token using oauth 2. all the times those tokens are requested we evaluate conditional access there are also events that trigger conditional access evaluation for instance uh proving authentication by the use of a session token we'll come back at that using a refresh token to obtain a new access token again we'll look at that in a bit more detail and also when an API rejects an access token through a claims Challenge and that's part of continuous access evaluation we're also look at that but let's start by thinking about the authentication story so we have a user that wants to gain access to an application and what the application will do is say you're not authenticated well if they have been authenticated already they'll in terms of the user would pass a cookie to prove that authentication to the app but assuming they haven't been authenticated the app is going to redirect up to the security token service that it trusts well in this particular case Azure ad and we have a fairly complex stream that we send to Azure ad which is really saying please authenticate the user to to this application and all of that information is held in the authentication request let's have a look at that in a demo let's start by going to an application oidc V2 and I'm going to sign into this app using openid connect now there we are up at azir and this is my string that I've said now I'm going to use Fiddler and I'm just going to use the text wizard in Fiddler to convert that string and do a URL decode on it it just makes it a little bit more readable so let's grab that and let's put that into Notepad now I'm not going to go into all the details but what I want to do is just sort of clean this up a little bit so we'll break it down into its constituent parts and I'm going to explain this in one second that has said not the real detail we'll have to do that in another video so what it is it's going up to a particular endpoint that's the authorize endpoint and it's by going there it's saying I'm doing open ID connect or2 protocol and in this particular string it's saying please authenticate the user to this application and after you've authenticated the user to this application return back to this particular location okay and there's things like response mode uh the scope and so on and a shape we'll have to look at that in another video let's go to a different application Let's uh just close this off and let's go off to a saml application and I'm going off to XCS Samo up here and I'm going to go login and that's going to send me up to Azure with a string and if we drop that into notepad it's a rather different um thing and what we're going is we're going to the Samo endpoint with a saml request which is actually encoded and I can grab that and pop that into Fiddler and we're going to Fiddler again drop it in there and what we'll discover is this is actually deflated saml so I'm going to decode it from deflated saml I'm going to grab that lot and I'm going to pop that back into notepad just to make it a little bit easier to understand so again I'm not going to go into the detail here it will have to be in another video but we're hitting the app the app is saying you're not authenticated and the app is making that decision because we're not passing a cookie to the app and we're being sent off to azir with an authentication string it says authenticate the user to this application and the protocol that is being used is the endpoint that we choose so we want to speak saml we go to the saml endpoint which is here and we can see that up in here as well so that's where we're going to the saml endpoint and we need to use the language that is appropriate for the saml endpoint and again if we're doing open ID connect or two we come up to this endpoint using the appropriate language to go there yeah when we log in is MFA evaluated well let's do something slightly different let's go to another application and I'm going to go to my app oidc V1 and I'm actually going to sign in this time again we've got this string that's gone up and I'm going to sign in as my user Don and I've got the password sort of in the browser just to make my life easier so signing in as Don and it's saying oh you need to approve the sign in request and the reason we're doing that is because we've got multi-factor so on my phone I'm just putting in 82 [Music] I'm now signed in and we can see it's uh Donovan and the AMR which the authentication method reference claim is set to password and MFA let's go across to the enter portal and have a look at the conditional access policy so here I am now in the entry portal I'm going to go to Azure active directory under protect and secure I'm going to find conditional access and if we look down through our conditional access policies we've got this particular one we're down here which is oidc V1 MFA for all users when always okay if we look at that we can see it's all users the one application that's applying to is oidc V1 and the grant uh the control here is to Grant access we need to do multi-factor so it was the fact of that we were authenticating triggered conditional access evaluation okay let's have a look at the authentication flow our user hits the application the application says you're not authenticated and sends the user up to Azure ad through a redirect so we end up at a zero ad with this rather complex authentication string saying please authenticate the user to app one the next thing that happens is that we have the authentication whatever method that is in use which would be executed and if you watch my video on the authentication method policies you can see there's an awful lot of different ways we can authenticate once we're authenticated Azure ad returns a security token and that security token is appropriate for the protocol so if the protocol was saml that would be a saml token if a protocol was open ID connect that would be an ID token is your ID also sets an authentication cookie and that authentication cookie proves authentication to Azure ad next job is we go back to the application and we present the security token the security token is proof of authentication of the user to the app the app will then render back whatever page it needs to render back having of course validated the token and then it sets authentication cookies which prove that you're authenticated to the application I feel the need for a little diagram on SSO so let's go across to the Microsoft whiteboard so we'll have our first application which is app one and our user right hits application number one and is sent off up to azure to actually get authenticated and that's where we get authenticated and after that authentication Azure is going to return to us the security token but it's also going to return back a cookie and that cookie is going to be sent back and we're going to store that cookie let's have it as uh our black cookie we're going to store that black cookie down here now when the user hits application number two go to app two again they're going to be redirected up to Azure this time they're going to send that cookie up to Azure so the black cookie up to Azure and this will prove that the user is already authenticated so every time we hit a different app we're going to use the Azure cookie to prove that they've already been authenticated and therefore it will be a single sign-on experience okay so let's experience SSO in a demo so I'm going to go to oidcb2 and I'm signing in as my user Don and that should be successful which it is okay now I'm not going to close the browser we'll just minimize the browser that cookie that we got from Azure is still inside the browser and I'm going to go to my saml application now and I'm going to log in and notice straight in I am in there as done so Donis got into the saml application through SSO now let's go against oidc V1 now remember lidc V1 requires MFA we click on that and say sign in with open ID connect and all we're being asked for is the second factor of authentication I need to put in that value of 23 and now I'm in it's going to be an SSO experience if need be I have to step up my Assurance by providing the second factor for authentication our next job is to look at access tokens and refresh tokens but before we do let's just set the scene with open ID connect in oauth2 open idea connect proves the user's authentication to the application in this case app one Now app one can be given an access token which authorizes at one to access a backend API and in our picture here it's shown as app2 so the ID token is proof of authentication of the user to app one and the access token is proof that app one is authorized to access app2 now the access token could be using the user's Identity or it could actually be using the identity of application one in which case it would be a workload identity where do refresh tokens fit in with all this if you know anything about continuous access evaluation or CAE I want you to forget about that for the moment we have app one which has an access token which authorizes it to access a back-end API with the identity of the user now all these tokens have a finite lifetime so watch of the lifetime of an access token be well if type 1 needs to continuously access app to even when the user's offline that token lifetime has to be extremely long otherwise when it expires at one will no longer be able to access app2 the challenge with having a very long lifetime for the access token is that act one has that token and can just keep going there is no going back to azir ad and Azure ad saying hang on a minute I just want to check that you're still allowed that access token so the design was to use a refresh token so we have a fairly short lifetime for the access token it's approximately one hour and every r at one goes back to azir using a refresh token and saying hey can I have a new access token please and at that point in time Azure ad can do a check so it can check is the account still enabled it can check that the password's been changed it can check conditional access policy so everyone are by using this refresh token we can go back and check whether we should be issuing a new access token so I think it's time for a little demo of this okay let's start off on oidc V2 and I'm going to sign in with code flow asking for an ID token so I'm going to just update my scope and off we go and we're going to sign in as Don and that's successful I'm going to convert the code to token I've got an ID token and I've got an access token the audience with that good is actually graph so if I look down there I've also got a refresh token so I'm going to click home on that and what I'm going to do now is I'm going to use the refresh token and what it will do is it will give me back a new ID token and an access token and if I go over and look at the server itself so if I bring my my server up here I'm running Fiddler on the server and I can see the interaction between the server this is in my diagram app one uh the grant type is refresh token and it's sending a refresh token back to azir and saying please give me a new access token and in fact it gets a new access token it gets a new ID token and it gets a new refresh token back so that's the use of the refresh token to refresh the access token and in this case the ID token as well now let's go to our conditional access policy and we're going to be using the enter portal for this and what I want to be doing is looking at SN 14 so here um specified users included and who are those users well Don and John the application is I've got two applications but one of those oidc V2 all right and what's the grant type the grant type is require multi-factor so I'm going to turn that on and I'm going to save that now let's go back again to our client so back to our Windows client and I'm going to come back down here and I'm going to go home and I'm going to use the refresh token again so refresh the access token and it's failed right we haven't got one bag so let's go and have a look at what happened on the server so over to the server and we can see it's a bad request that's come back we've got the refresh tokens everything solid looks like it should be all right but if we look in here in Json and I can grab the error description and I can put that into notepad to make it a little bit easier let's just change the font size in here just to make it a little bit more readable and what we can see is if we put word wrap on as well we can see that Jupiter configuration change made by administrator because you're moved to a new location you must use multi-factor so at this point um app one can no longer use that access token a user has to be involved at this point but the key here is I wanted to show you that when the refresh token is used conditional access is re-evaluated let's just go back to our client and let's just get the user involved so I'm going to click home and I'm going to sign in with code flow again and at this point Don is being prompted to actually provide that second Factor our last thing to look at is continuous access evaluation and CAE is Microsoft's proprietary implementation of the core of continuous access evaluation protocol caep as a work in progress by the shared signals framework working group in essence is about an IDP as an identity provider being able to inform an API about a policy or about a significant event well seeing as Microsoft own Azure ID the IDP and they own the API SharePoint exchange graph then Microsoft can Implement what would have to become part of the protocol and they can implement it today so if we look at CAE what we can actually see is that we've got Azure ID and we've got a Microsoft API and azir AD can inform the API about policy and in particular Network policy it's saying you know what where the application is allowed to be in terms of IP address when it makes a connection to the API the subscription which will be part of the protocol with how we do that subscribing to events and policies you know is is inbuilt into the Microsoft ecosystem so now our application comes along and it requests access to the API and it passes an access token at that point the API can check the policy hmm is the app coming from the right network if it is then we'll send back the information but it can also check to see if it's had any significant event notifications right such as the user's password has changed the user's tokens have been revoked the user has come into the scope of an Azure conditional access policy if any of those happen then what will happen is the API will deny access and return a claims challenge at which point the application will go back to Azure presenting the claims Challenge and azir will do whatever is necessary maybe prompting for second factor maybe blocking access or maybe requesting the user to re-authenticate with a new password if the password has been changed for this to work properly the client has to be CAE aware otherwise what could happen is the client could present the access token from cash so it presents the access token the access tokens rejected so it presents it again it's rejected so it presents it again it could go around in a loop so the application has the number one declare that is is CAE or where and then the CAE will kick in when we're gaining access to this particular API so it's initially focused on Exchange teams and SharePoint I'm going to show it to you with Microsoft graph in a second um critical events include things like the user account being deleted being disabled password change password reset MFA enabled for the user refresh tokens revoked and also an Azure ad identity protection detects an elevated user risk that would cause this claims challenge to be presented and in terms of CA policy it's a network location change would cause again the claims challenge now if you look at an access token when CAE is disabled the access token is about an hour in length so we can see here it's going it's issued at 1616 and it expires at 17.21. here with CAE enabled is issued at 1905 and it expires at 2018 so you think ah what's the difference but then you notice the day it was issued on November the 28th it's expiring on November the 29th so we can have a access token which actually could have a lifetime of 28 hours which means your app isn't continuously going back hell here's my refresh tone give me a new access token and so on so now revocation of access is now event driven and policy driven and it no longer relies on an attempt to renew the refresh token let's have a look at that in a demo okay for this demo I'm going to go to graph using Powershell so I have the ISE running for Powershell I'm going to start up Fiddler and I'm going to get it to monitor the command window for ISE so now it's going to trap capture any traffic going from this particular command window so my first job in here is actually to connect to mg graph so I'm going to connect up to mg graph and I'm going to sign in as my user John 1.80 and we're just going to go in with a password Here and that has now successfully connected me to graph so let me do one thing here and I'm going to ask for information about myself so I'm going to do a get mg user but from with my own identity so run that selection and that was successful let's have a look at Fiddler so here is that call to graph and if we look at the headers in the call what we can see down there is it's going to graph and it's asking for the resource users John at one dot ad.xtub.com if I look down here I've got a access token so I'm going to grab that token and so I'm going to copy the value of that token and I'm going to go to jsonweb token dot Ms so jsonwebtoken.ms.ms and I'm going to drop that in there so there's my token gone in I just need to remove Bearer from there and if we look down here what we can see is when it was issued and when it expires well the nice thing about jwt.ms is that you can go to claims and it shows you the issued at with uh Friday March 24th 2023 1512 and it expires on Saturday March the 22 25th at 15 17. so it has just over 24 hours as a lifetime now what I want to do is go and make a significant change but before I do I want to show you where this particular application is declaring that it is CAE aware and if we look at the first interaction up here I'm going to grab this and I'm just going to drop it into the text wizard and I'm going to URL decode it just to make it a little bit more readable and I'm going to copy that and drop that into Notepad well we had rather a lot of things in notepad and I'll bring it in here and I'm not going to go through everything here but I just want to pick this point out here this is where the client is declaring that it is CAE aware okay and that's why it got back this long lifetime for a token right let's go over now to the portal and what I want to do is go to users and I'm going to go to all users and select my user John so we just put John in here and this particular user is John Williams and what I'm going to do now is revoke sessions and in a short while it's not going to be instantaneous we'll see that John's access is revoked to graph so let's go back to graph and through the magic of video I'm going to actually just wait a period of time before I attempt to access again okay so I just attempted to get uh get mg user again and it is prompting me to authenticate so we can have a look at Fiddler and our last interaction with graph and what it's saying is 401 unauthorized and if I I think just look at the Json in here grab this lot and copy it and pop that into Notepad and it's a continuous access evaluation resulted in a challenge so we got a challenge coming back and basically it's interaction required so we have to get the user to sign in again thanks for watching this session to the end I hope you enjoyed the level of technical detail now you know all about the triggers that cause conditional access to be evaluated don't forget to subscribe and keep learning I'll see you next time in the cloud thanks for watching my channel subscribe for more free training you might like to join me for my identity masterclass hopefully see you soon [Music]

Channel: John Craddock Identity and Access Training

Views: 1,479

Keywords: John Craddock Identity and Access Training, Azure AD, Identity, Microsoft Entra, Cloud Deep-dive, Conditional Access, Continuous Access Evaluation, CAE, Refresh tokens, Access tokens, OpenID Connect, OAuth2.0, Session tokens, SSO, John Craddock, John_Craddock

Id: fWRSglWqQdk

Length: 33min 59sec (2039 seconds)

Published: Mon Mar 27 2023