All right.
Hey, what's up, everybody.
All right.
Let's get moving, if you all don't mind.
Hope you're here to learn about Conditional Access and Intra.
Thank you for hanging out with me until 8.30 at night.
I've told everybody so far that I've met today that this time yesterday I was in my pajamas and ready to fall asleep.
So I'm going to try to be as energetic as I may have been like four or five hours ago.
Like our previous speaker, I'm really excited to get over to the casino party and drink several beers.
But before that, I'm going to try to teach you guys a few things.
I'll kind of whip through this and take some questions at the end.
So without further ado, as our keynote speaker showed, you shouldn't show pictures of yourself, apparently.
So I whipped this up real fast.
That's not me.
That's Johnny Christmas.
But who I am is Brandon Colley, or Tech Brandon.
You can find me on Twitter, on LinkedIn, YouTube, GitHub, all the good stuff.
So I am a father, I'm a husband, and I am a founder of a small business that is B&R Consulting.
We do small business consulting and remediation efforts for mostly Microsoft and intra-cloud services.
I just started with TrustedSec like three weeks ago, so I am now a senior security consultant with them.
If you follow TrustedSec or you've followed my previous company, Trimark Security, we recently merged with them, so we've kind of joined forces.
And now I've kind of got a foot in both of those worlds right now, so things are a little nuts.
But for both companies, I basically run a lot of their Active Directory security assessments, as well as their cloud or mostly intra-ID or their Microsoft 365 type stuff.
So at Trimark, I was the service lead for our MCSA, which was our Microsoft Service Cloud Assessment, which basically is a whole lot of credentials to basically say, I've seen things, right?
It's well over a thousand conditional access policies probably in the last several years that I've been working in intra.
And so what we're going to do today, this is kind of my brief agenda slide, we're just going to walk through a few of the common misconfigurations that I've seen, something that hopefully you don't have in your environment, but if it looks familiar, hopefully you'll learn something with that.
I'm going to walk through also why that matters.
So we're going to talk through kind of how attackers may do that or why it's a misconfiguration.
And then we're going to talk about what you can do about it.
So the most important stuff is how you can find some of these holes that exist in conditional access.
So without further ado, let's walk through our very first one, which is one that I love to talk to people about.
So we're going to do, I know it's 8.30, but I'm up here, you guys are in here, so we're going to do some audience participation.
Woo!
Okay.
So raise your hand if you think 129, 126 conditional access policies is too many policies.
Everybody's hand should be raised.
Guess what?
Because Microsoft only allows 195.
So if we cut that in half, being a little bit more realistic, 98 policies, probably still too many.
We cut it down.
I saw some heads like, yeah, 66, okay, 40.
Some people I asked said less than 20.
So we're kind of all over the place.
And that's fine because the real answer is it depends.
Because we are consultants after all, right?
The reason it depends, at least in my opinion, is that if you do things really, really, really well, then 60 plus into the 80 policies, if they're really well managed, can be fine.
If you really know what you're doing, if you're following this picture on the right-hand side there, is based off of Microsoft's zero trust conditional access.
They use personas.
So if you use global policies and you've got all these personas, that actually puts you at exactly 66 policies that exist in their Excel document that you can download.
So I like to say we're kind of in that space of between 40 and 66.
You know, you can deal with less.
It kind of depends on size of an environment and stuff like that.
Okay.
The water break ruined my transition here.
But basically, it can become a management nightmare.
And some of the things that I've seen is when a company goes to make a change, or there's a problem, or they need to add something to a policy, or, you know, if you manage conditional access, Microsoft changes something or adds something, where do you go to modify?
So which policy do you have to change?
Do you have to change multiple?
Or, even worse, maybe just add a new one, right?
So I had a tenant recently whose policies really looked like they were written, like they came in as help desk tickets.
So it was very much this person, this application, this block rule, or it requires MFA, and under all these conditions.
And really, I think the best thing that we can do is continue to try to lean onto that privilege, the least privileged documentation that I talked about.
I'm going to link that at the end.
I've got a bunch of resources that I'll share with you all, too.
But I don't have time to dig completely into that right now, because I could probably do 30 minutes on just that.
Next one that I've got is probably my favorite one.
So this is the requirements for administrators to use MFA.
This one I like to point out that Microsoft was nice enough to give us a template.
Also, if you are checking your policies in your tenant, you might notice that you have some Microsoft-managed policies.
The downfall with these, though, is by default, it only has these 14 policies selected.
And I'll tell you, in every single tenant that I've looked at over the last year, year and a half, it's only these 14 policies that are in all of those conditional access.
So what I'm here to say is we need to add some.
Anything that you're using, but also I think anything that's considered to be a highly privileged, is going to be important.
So adding things like at least these nine is what I would recommend.
So authentication policy administrator, directory writers, external identity, and then certainly the hybrid identity admin, which in my opinion is one of the most privileged roles that exists, because it gives access to manage all things that are the connection between Active Directory and intra-ID.
And so if you're using any sort of intra-ID sync, it allows you to modify settings in there.
Password hash sync settings, password authentication settings, seamless single sign-on configurations, so all the good stuff.
The other one that I found really interesting is the Intune administrator is not included by default.
However, SharePoint and Exchange administrator are.
And I don't know how they're different, but I'm here to say add Intune administrators, and then as well as some of those other ones, I'm going to keep on this slide for just one second, too.
So Microsoft does determine, if you guys notice that they've done this recently where the specific permissions that are granted to some of these roles actually make them tagged as privileged.
And I like that, but I also don't think it's something that we should really fully trust.
And this is part of the reason why.
It's because only six of these are considered privileged.
And the top one that's not, the authentication policy administrator, that actually gives you tenant-wide access to modify MFA settings as well as update the banned passwords.
So that seems pretty darn privileged to me.
And another fun transition meme.
So it's easy to overlook these because you have these policies in place and you think that they're covering all of your administrative accounts.
But in all of the reports that I do, I look at those specific accounts instead of just the roles.
And I look and see what kind of MFA are they configured for.
And what I find is that they're usually weak MFA methods, if any.
I find some that are not even registered for MFA, so I question how they're logging in at all if they're supposedly following this requirement to use multifactor.
So this one's another fun one for mine.
This one kind of goes back into my sysadmin days.
I was a systems administrator for about 15 years prior to doing security assessments.
And named locations... that was loud.
Named locations, and now they're changing them into networks and locations and stuff like that.
This is where you go to configure your IP scopes as well as any of the countries that you may either want to explicitly deny or make sure that are set as trusted locations.
And I posed the question to AI, and I actually did this back a long time ago, and asked AI, hey, remind me how to subnet, because I've forgotten, because I'm out of things.
And it told me, go look at an online calculator.
So AI wouldn't even subnet for me.
It doesn't even want to do it anymore.
And I said, well, how about a diagram, AI?
How about you help me out?
And so it gave me this diagram, which was gibberish and I thought was very appropriate.
So I'm not here to poo-poo on location policies, because they're great.
I feel like they're relied upon maybe a little bit too much.
And what I'm here to say on this misconfiguration specifically is, look at those subnets, and look at the last time that those subnets may have been modified in your environment.
Now, I realize that IP spaces, especially public IP spaces, don't change all that often.
But as a sysadmin, the only time I looked in Active Directory sites and services, or as a SCCM administrator, the only time I looked at which distribution points were pointing toward IPs was when stuff was broken.
It's because we changed IP schemes, we added or removed stuff, and we forgot about the trickle-down effect.
So don't leave those open.
Don't wait for bad things to happen.
Keep an eye on those scopes.
Make sure you're using narrow scopes.
Make sure you know how to subnet that you're not using full class B subnets for when you should be using just very specific IP addresses.
And the last misconfiguration I want to talk about is when you use multiple conditions.
So a lot of people really like to compare conditional access to a firewall.
And so what happens when you configure multiple conditions on the same policy is you're met with something called condition overkill, or here I've created one for an example.
This is stuff that I've seen in environments actually quite often, where you have a user risk, which is set to high and medium, and then you have a sign-in risk that is set to trigger on high.
And so this is actually per Microsoft best practices.
That's what you want to be set.
And, you know, maybe you want to set a location and say, you know, if you're on a trusted location, you know, my perimeter is fine.
That's all good and dandy.
But what actually happens when authentication occurs, it must match every single one of these conditions.
It is not an or statement.
It is an and statement.
So when a user logs in and they have a high user risk, which means that they are 100% compromised, but they're from on prem, this doesn't apply.
All right.
Whole policy, not applying.
This one played a lot better back in August when I gave this presentation, but I'm really glad I got giggles today.
Okay.
So now we're going to find the holes.
So I've given you some of the misconfigurations and finding holes.
They may be small holes.
They may be small, little cute holes that we can do.
Might take, you know, a team of people to actually kind of figure out where these holes are and what needs to be fixed.
Or there may just be absolutely no way that we're going to find or fix these at all.
So we're going to try.
And we're going to try with several different methods.
This is a busy slide, so now it's going to be a good time to get my throat wet.
Okay.
So first of all, we've got a lot of built-in tools that we can use at our disposal.
The what-if tool is probably the first and most well-known tool, probably my favorite to really geek out and to dig into certain circumstances.
So actually just, let's see, yesterday or the day before, I was doing an assessment for a tenant, and they really liked to use device platforms and the client types.
And so I was able to find a hole in their conditional access because they were not accounting for something coming from a macOS and using, like, an approved application.
So really easy to just plug those into the what-if tool, find out what policies would apply, what policies would not apply, to kind of figure out where those holes might exist or what may have happened in a specific situation.
Another cool place is the security alerts, which is in the overview tab on the home screen of conditional access.
So this is going to show things like that third one down there is the 94% of sign-ins lack multi-factor authentication in the last seven days.
So something's going on, maybe your policies are a little too lax on that, that 94% of your users may be coming from on-prem, so maybe that's normal , but who knows.
So that's a good place to look, a little bit of, I don't know, Microsoft AI, some co-pilot stuff, maybe helping out with that.
The other place is that coverage tab.
So coverage tab, you're going to lean on a lot of the application-specific stuff.
So one of the best practices for conditional access is to have at least one policy that applies to all resources in the environment.
If you've configured things to be very piecemeal and very targeted on specific applications and you just tell yourself, well, it's fine, I'm just going to add applications as we get new applications, I don't think that's a great way to continue to do this.
And here you can see where some of those gaps are and what your coverage on applications might look like.
And then a brand new one that just came out within the last month or so is this policy impact.
So this is right on the policy itself, where before you even fully configure the policy, you can look to see what this would have done over the last month or the last seven days.
So no more setting a policy in report-only mode and telling yourself that you're going to go look at the logs and decide whether or not it actually needs to be turned on or not.
Because I have seen, we do repeat assessments for customers where I have had a finding for a conditional access that was in report-only mode, and guess what?
Next year, still in report-only mode, they're still working on it.
So this is pretty cool to see how something would have behaved.
ID power toys, this is a tool by Merrill Fernando, this is a conditional access documenter.
I think it's powertoys.net or something like that.
This one's interesting, because this one spits out a PowerPoint presentation for all of the conditional access policies that exist.
This, I like to say, is kind of just highly visual and maybe good for some of the less technical people to be able to comprehend and look at the difference between a few policies.
So this is an example of the block legacy authentication policy that I have in my test tenant.
And then here's an example of one that's the require password change for high risk users.
Super, super, super simple to run this tool.
You can just copy and paste some JSON that will be spit out from a web request, or you can run some direct PowerShell against your tenant.
So the next cool tool, probably my favorite tool right now, is Meister.dev framework.
This is also built by Merrill, as well as a friend of mine, Thomas Naheim and Fabian Bader.
The tool now has 417 checks as of a few days ago when I re-ran it.
And that's up about 150 checks since the last time I did this presentation back in August.
So they're adding checks very, very quickly.
Also, I just double checked, and they're up to 24 of those checks are specific to conditional access best practice.
So check out this tool.
The way this looks when it spits out is also fabulous.
So a passing check looks like this.
So this is a check for application coverage that I had mentioned earlier .
All targeted apps in a conditional access policy shows you which ones are passing.
And if you click on one that fails, you'll see failed.
For device compliance, I don't have devices in my lab, so that's fine for me to fail it.
But if you do fail one and you're not really sure, like, what is this best practice or what is it, it'll have you link directly to Microsoft.
It'll also give you a link to their website, which is really good at explaining more about the specific test and the details of how to correct it.
All right.
Last thing I'm going to show off is a simple script that I wrote.
So this is on my personal GitHub.
So github.com slash tech Brandon.
It's called just CAPS.
You'll find it.
There's not a lot of stuff on there.
But this I wrote off to show a few different things that are fairly easy to look at in conditional access.
I also like to write code that's easy to read.
So I hope that it's easy to read for you.
It's also very short.
So it's about 200 lines of code.
So you're not going to have to work too hard before you run something that you don't necessarily trust.
Back as a sysadmin, I really hated grabbing code off of a GitHub repository that didn't have a lot of stars or whatever, and without fully understanding exactly what was being run.
So that's the intention of a lot of my code is I want it to be really short and sweet and to the point.
So it's fairly infant stages still, but there are kind of three high-level things that it will spit out for you.
So the first is it's going to give some high-level statistics, some information about how many policies exist, what state they're in, are they turned on, off, report only.
And then it's going to list all of those policies for you, as well as the last time that they were modified, as well as created date, the state that they're in.
And then it's going to attempt to place them into categories.
So the categories are based on 13 of the best practices.
Most of them are Microsoft best practices.
Some of them may be mine or they come from the Meister framework or just kind of more general guidance.
So this breaks them down into where it doesn't necessarily say that these are good policies, but they're at least trying to do these things, right?
So it's at least trying to do legacy authentication being blocked.
It's trying to do some MFA checks.
And then some of the new ones that I added there on the right-hand side is some of the multi-factor for device join, as well as blocking authentication flows, which is also known as the device code authentication.
So if you're all familiar with that sort of vulnerability that has existed for a while, it's now able to be blocked in conditional access.
And then the... what was the last one?
The secure registration.
So that's one that I also added just recently, too.
And then the last piece that I'm trying to do more of is actually add a little bit of intelligence inside of this.
So I told you that the last screen was what it tries to do.
This is digging a whole lot deeper and saying, okay, it does this well or it does not do this well.
So these are two of the checks that I've got right now.
It's going to look at any of the MFA policies that are targeting the administrative roles.
It's going to look at those 14 default roles that I told you about.
And then it's also going to compare that against the total number of roles that it's targeting.
And so we can see in this top one, it's got the 14 of 14, but it's also got seven additional roles that it's using.
And then some of the other ones are not quite as good.
And then the second one, this is one that I also just added.
This was some code I really didn't want to write, but I had to make myself do it because it was the one that I thought was the most important.
So this, I've noticed that Microsoft has now changed a lot of their documentation from saying, require MFA for X or administrators must use MFA.
They're now saying they must use authentication strengths.
And they're also saying that they need to be passwordless capable or phishing resistant.
So Microsoft has a great website that shows some of what those policies are.
And so what this is doing is it's looking at any policy that has configured for authentication strengths.
And it's checking to see if it includes like all MFA, because you can set it for authentication strengths, but then you can say, just use MFA and it's going to use all 17 different methods of MFA.
Or that bottom one we have as a pass, because it only includes what's considered the phishing resistant or the passwordless, which is FIDO2 keys, Windows Hello for Business, Certificate Authentication, and Microsoft Authenticator Push.
So it's going to kind of give you a little bit of a pass fail information as far as that goes.
All right.
And with that, I made up a little bit of time.
I've got my thank you squirrel slide.
And then here is some of the resources.
I haven't uploaded this version of the presentation, but the previous one has all except for that very last link.
That's on my GitHub as well.
So you can grab the slides from there.
They've been slightly changed a few additions, but most of the content is pretty much the same as it was.
So I'll try to get that updated maybe sometime tomorrow, since I have other plans tonight.
So with that, thank you all for being here.
I swear I expected 10 people in the audience this late, but I really appreciate you all coming and sticking around.
Would love to answer any questions in a few minutes that I've got or on the way to grab a beer.
So thanks.
If you have a question, you can raise your hand or you can come up here.
Yes.
The question was, I'm nervous about locking out my break class account.
So as far as conditional access goes, I like to see it excluded absolutely everywhere.
I've seen a lot of customers who really want to obfuscate what the name is.
So they've got, I've had some that literally name it like numbers and letters that are randomized and they say, Hey, that can't appear in the report.
Like they really want to protect it.
Personally, I, I'm not as afraid of that.
That should be detected.
So your break glass accounts should always be monitored for login, because if they log in, there damn better will be a fire someplace for that break glass to be used.
So if it's getting locked out, I would say same sort of thing.
There's, there's a fire that's happening someplace or somebody's trying to start one, right?
That's so that's a, I haven't, I'm not familiar with that, but that sounds fantastic.
So the, is it mostly a comment?
Um, uh, Microsoft MVP has been saying that they prefer to use certificate authentication on a user object and probably not even a user identity.
I'm guessing like an application identity, uh, application identity to use as a break glass account because they're able to log in and still get to the Microsoft graph and leverage and possibly, you know, fix whatever is broken there to that.
I, I guess I would just say like, yeah, secondary would be fantastic.
Yeah.
I would say I don't want to do that in a panic .
Like I'm going to freak out anyway.
Yeah.
He was just adding extra context around, uh, the slide that I had that talked about a persona of the, um, no, I can't even think basically that the application accounts are the workflow, uh, workflow identities, workload identities.
I was close.
Um, and, and yeah, so the personas are cool.
Cause if you've got those personas again, if you're using the break glass and yeah, there's going to be exceptions.
And so you're going to have to be careful, but, but yeah.
Um, okay.
I think I'm going to bounce, but like I said, I'll be around.