Know Your Stack:
Entra ID hardening

Jazzy: Hello and welcome everyone. Good afternoon depending on where you are in the world though. Good morning, good afternoon, good evening. We cover all of whatever, whichever part of the country or the world you guys are in. Love that. I'm guessing that it's not night for someone in the world right now or in this meeting. Well, hopefully not. If it is night, they absolutely love these webinars, wanted to join during this time. Absolutely love it. Absolutely love it. Well, good to have you all. Thank you for being part of our webinar, part one of our Know Your Stack series, a four-part webinar, where we'll talk about a few things, Microsoft world and the things we love doing every day, each day. I think I think, I mean it's 2 3 red one. What you think? Should we get, should we get cracking? Should we get started? Hopefully people can see.

Redouan: I guess so. It's already 2 minutes past 4. So I'm guessing that most people have joined so far. Do we do we have like a Q&A section or do we just use the chat within Teams? I'm guessing we're using the chat then, right?

Jazzy: Yeah. Yeah. Let's use the chat. Anyone that wants to, some questions.

Redouan: Greetings from Switzerland. Greetings from South Africa. Actually, I'm in South Africa right now for some on-site engagements for inforcer. I've been here for like a week now. So, greetings from South Africa, but I'm actually based in the Netherlands, but we'll jump into intros in a bit, I guess. We've got, we've got someone from UAE as well.

Jazzy: I mean, right now it feels like UAE in the UK. I'm based in Richmond, United Kingdom. It's almost 100° here. Not really, but that's what it feels like. I am melting slightly. But I think I think we'll be okay, mate. We have people from all over the world right now. We got Haiti in the house.

Redouan: Yeah, as well, bro. What? Greece. Are you guys making like making things up? They're just putting in countries right now. Well, Netherlands is not going anywhere in terms of football, but yeah, otherwise Netherlands is in the house, too, boys.

Jazzy: Someone says 100 degrees in USA. Man, we measure in Celsius, man. 37. Yeah. Yeah. 37. I mean, that is what it feels like to be fair. I really need an AC. Cries hearts, actually. Awesome. Let's get going. I'll move over to the next slide. So, a little bit about us and who we are. Welcome guys. I'm Jazzy. I'm part of the Microsoft 365 solutions architect team here. I'm a Microsoft fanboy first of all. That's all I love. That's all I talk about. Even with my misses. Somehow, someway I managed to bring Microsoft in the conversation. I am also the official IT support for my parents, without a doubt. Anything that ever goes wrong it's a phone call straight to me. Somehow I know everything about phones and TVs and the fan that sometimes doesn't work and swivels in the wrong direction, even though there is no right direction for a fan to realistically swivel. And my whole IT career has been MSP. That's all I've ever done guys. I've only ever worked on MSP. I've been heavily involved with the Microsoft ecosystem, things like Intune, Entra, Exchange, a little bit of your virtual desktop here and there. And that's a little bit about me and nice to have you all. We're 134 big right now on this webinar. So, thank you for joining. I did create this slide like 10 minutes ago, so I didn't get

Redouan: Yeah, I was going to ask you like what did you put under my name? Like what? At least

Jazzy: Over here for no reason. You're not going to have time to add anything.

Redouan: I will, I will introduce myself as well. So, my name is Redouan. I'm actually based in the Netherlands. As I said, right now I'm in South Africa, so that's really fun. I'm here for some on-site engagements. I used to work for an MSP as well, just like Jazzy. I used to work for an MSP that is based in the Netherlands, in Anto. For all of the people from the Netherlands right now, they probably know where it is. I was the lead consultant there for the model work team. So I did a lot of project work around Microsoft, the Microsoft ecosystem. We were really focused on the Microsoft ecosystem. So defend office, defend the cloud apps, all of that, all of those shenanigans within Microsoft 365. We configured it and we were really focused on it. And since I want to say a month or two right now, I'm a solutions architect here at inforcer. So yeah, thank you all for joining, man. I mean, we have a, we have a good group today, Jazzy.

Jazzy: Absolutely. I think I think we're ready to hopefully inspire some knowledge that wasn't already there and maybe we learned some from all the other experts in the call as well. And happy for all of your inputs and questions in the chat. So, feel free to go. I am controlling the slides. So, Redon, whenever you need me to go to the next one, you can tell me as well and we'll do, we'll do this together. FYI guys, none of this is rehearsed. We're doing it on the fly as we always do. So we'll make it work as we always do. Things will cover. So we'll cover some of the stack that you already own. And talk about some of the foundation work that we can harden that sometimes gets missed in obviously conditional access, can't speak about ID without speaking about conditional access. And some external and cross tenant collaboration that we may have missed about guest, type of security and infrastructure that we have available inside Entra ID, and making sure that we configure things and make sure they stay enforced, right? Because configuring a policy, turning it on and not applying means nothing, does it? How many times have we deployed something and forgot to assign someone to it? I've made that mistake once or twice myself. What about you, red one?

Redouan: Yep, I know exactly what you're talking about.

Jazzy: Awesome. Awesome. So, stack you already own guys. You've paying for business premium. Hopefully, all of you are, and that includes Entra ID P1 that is included with the licensing. And sometimes where we struggle with is when we have too many subscriptions, we already have an identity platform that we're using. We're using HR P1. We've got the business premium licensing under our wings and that's where it's brilliant to be able to configure it, but are we configuring it to its extent? And sometimes we find, we don't find things we're looking for within Entra ID, and that covers other workloads as well like Defender and antivirus and Exchange email security gateway and things like that. And you, it starts stacking up, right? You start having more portals to cover, more work for the invoicing team to ask for money for other products that you're covering and just more consoles ultimately.

Redouan: Yeah, I mean you're hopping from portal to portal enough within the Microsoft ecosystem and now you have like other third party applications that also have portals that you have to hop to. I'm guessing that for a lot of people that this is making sense. I've been on some on-site engagements here in South Africa as well. I will see a lot of MSPs that will utilize like third party applications where they don't really know that it's already included within business premium actually, or it might even be cheaper to move to business premium and then leave some of those tools, cuz nowadays Microsoft technologies, I mean you can check the Gartner quadrant charts, right? I mean Microsoft is in top of the charts. So I guess that the goal of this series is to like really focus on what you already have within that Microsoft ecosystem, since it makes so much sense to consolidate into that, if that makes sense.

Jazzy: Yeah, absolutely. No, absolutely does. You're spot on. And what that also sometimes means is that you only need one type of expert within your MSP, right? Someone who knows the Microsoft ecosystem. You're not looking for people with other skills because they know Microsoft. We live and breathe Microsoft. It's easier to manage and configure because we know and we've been trained on it. And ultimately, who wants to jump between more portals when we already have so many Microsoft pools to jump from, right? You said that spot on. Wasn't it also recently that Microsoft announced price rises and the only thing that wasn't raised was business premium in terms of licensing? Anything else changed?

Redouan: Yeah. Yeah, that is correct. So, that is a very good argument for an MSP to actually move towards business premium since it is the only SKU that is not being raised in price and business standard is being raised. So yeah, makes more sense, even more sense to move towards business premium.

Jazzy: Absolutely. So what do we get? We get Entra ID P1 in business premium. We've got things that we can configure such as conditional access that we'll talk about in a minute. We've got SSPR in there, self-service password reset. We even got password protection in there where we can apply certain words that are refrain from being used as passwords, like a banned user password list. We've got named locations where we can decide which IP addresses are part of the allow/block list. Could be, could be your office IP address or could be the customers offices of the world where they are. So we could, you know, block certain countries from being accessed into their Entra tenant environment and just allow certain countries. And you've got proper security reporting that comes out of Entra. There's so many reports, especially with workbooks as well, isn't there? When you do the diagnostic settings and there's lots of reporting that can be pulled out, if I'm not wrong, with by standard in Entra ID you get 30 days of history in terms of sign-in logs as well that we can export out, and that's already all paid for, it's part of your Entra ID P1. So things like built-in MFA, we've got you know pass keys that we can use, we've got lots of authenticate, we've got the Microsoft Authenticator app we can use on our phones, we don't necessarily need third party vendors to help us with MFA. So that approach there for us as well. We do have an add-on, right? P2 which can be purchased on top of your business premium, is part of some suites as well. I think the Defender suite and the Purview suite comes with P2. And you can have standalone P2 licenses as well that gives you things like risk based protection and privileged identity management as well. So the just in time, just enough access protocol to make sure that we're covering that framework. So with PIM, you can elevate up to a certain role and only have it for certain hours, assign them to specific users, so we're not sprawling out with all of the roles to everyone. Give everyone GA, because that's what turns out to be happening.

Redouan: It does still happen though. I mean, I've seen it. Unfortunately, it does.

Jazzy: Absolutely. I've seen it too. We should, we should really rein that in and start controlling. I mean, it was like that in my MSP as well. We did tend to give out a lot of global admins across the board and have to rein that in as much as we can. I mean, I'm not going to go deep into GDAP and PIM GP there as well, but for people that don't know

Redouan: You want to make this a two-hour webinar, Jess.

Jazzy: All right. All right. Like I said, slight, I could talk about, Microsoft fanboy out here.

Redouan: Yeah. I mean, we usually had to revert to like P2 licenses for our administrative accounts whenever GDAP wasn't, when we weren't able to do specific things within GDAP. I know that at the time, this was only a couple of months ago, you couldn't manage Teams within GDAP. I'm pretty sure that is still the case. And then we'd still have to like have a P2 license if we were to like properly configure the roles with PIM. So, yeah.

Jazzy: Yeah. Yeah. And making sure that every user gets that P2 license. Yeah. Not just the one to unlock it in the tenant, like some people have been doing. Every user benefiting from that should be having a P2 license, but we're not going to go into deep licensing talk either.

Redouan: That's fine. No. No. Please no.

Jazzy: Awesome. Talking about the foundation site. So obviously there's conditional access as well that we'll cover later on. But there's a few basic settings that some, sometimes do end up getting missed within Entra, and standard users and their privilege with the default user role permissions being one of them. Right.

Redouan: Yeah. If I could even add to that, please just realize that Microsoft 365 was built for enterprise. It wasn't built for MSPs. So all of the default values of all of the tenant-wide settings are always like enterprise-based settings. So it doesn't make sense for MSPs out of the box. A lot of these settings are forgotten about by MSPs, like we see that a lot that these MSPs will focus on conditional access for instance, or they will focus on Intune policies, but when it comes to the tenant-wide settings within Entra they're just forgotten about. So a couple of them right here, and I'm pretty sure that the next slides we're going to discuss some more. By default users can actually register app registrations within the tenant. So not sure why that is. That is really for like enterprise environments where you have like in-house developers. They need to be able to register applications and stuff like that. For MSPs, nine times out of 10, it doesn't make sense that users are able to do that. And the same goes for restricting non-administrative users from creating tenants. Most MSPs are managing like SMB type environments, sometimes enterprise, but usually there's like no good reason a normal user should be able to create a tenant. Like again, this is really for like in-house developers that are creating tenants, maybe testing stuff out before going to, before going to a production. So, please just have a look at these tenant-wide settings and make sure that you baseline that correctly once and then try to apply them all of them correctly. And the same goes for security groups. Sorry for taking over, Jazzy, by the way.

Jazzy: No, please. Yeah, go for it. Of course.

Redouan: And the same goes for security groups. So security groups and Microsoft 365 groups are like two different toggles. And I'm pretty sure that the M365 one will be shown in one of the following slides. But in most scenarios, you don't want users to be like creating security groups. That's what we as an MSP are doing. There might be some like shared administrative scenarios where the users of the tenant or your client are actually also managing the environment. So there might be scenarios, but generally speaking like from an MSP perspective, normal users should be able to create security groups, if that's making sense so far. I am really curious though for everyone who is in the webinar right now, if you have an edge case where you as an MSP actually need that toggle to be turned the other way around. I'm really curious if you could drop that in the chat because I'd love, I'd love to hear the edge case here.

Jazzy: You're spot on. I completely agree. So, in terms of the M365 groups, I still feel like there may be some relevance as to why that should be enabled, right? Security groups really comes down to, you know, we control things like in policies, who they apply to, conditional access policies, app access, you know, we realistically, where are we looking for security groups to be enabled? And exactly like you said, it's really an enterprise-heavy setting, isn't it? When it comes to restricting non-admins from creating tenants as well. So although, I mean I think the only, the only tenant you can create is the external tenant view, and whoever creates it becomes the owner and they have to connect it to an Azure subscription anyway. There is a few things you have to do before you can create that tenant. But why have that setting there in the first place, and we can just control it from here and say no, if you need a tenant we'll think about it, right? Yeah, so there's someone in the chat, Martine, thank you, thank you for sending it. If a customer needs to do it themselves we give them, we give the user PIM with a role.

Redouan: So that was exactly what I wanted to add, is all of these things, if you actually block it then a certain role within ID can still do it. So you can have a process around that and it's way more controllable instead of just having every user being able to register applications or create groups. So makes perfect sense.

Jazzy: Exactly. We've got that audit term. We've got the role that we can apply. I mean things like user administrator or groups administrator. We can even create custom roles, can't we? That have specific rules, allow where they can create just security groups and they automatically become the owner and they can go from there if they want to. If there is any reason for that. But yeah, I think I think these default settings can definitely be changed, especially with default user role permissions. And exactly, with another setting around that is the user settings that, you know, talk about restricting access to the Microsoft Entra admin center as well, if they don't need access to review. Yeah, we were talking about that.

Redouan: Yeah. Yeah, we were talking about that. So I do want to emphasize for everybody listening in, the toggle "restrict access to the Microsoft Entra admin center" is not a security toggle, like not at all. That toggle is meant for users who are like clicking around into portals and then happen to go to the Entra portal for some reason. So the overview page of the Entra portal will be blocked, but any deep links or any API access is still accessible for those users. So for instance, if you allow users to create security groups and then you block access to the Entra admin center, they are still able to create security groups in the Entra admin center through like a deep link. So if they go to the direct link for creating groups, they're still able to go there. So you do want to like to toggle this to blocking those users, but this is not a security toggle at all. So please make note of that and don't forget that.

Jazzy: That was insanely funny, right? Because we were able to copy and paste the link from what we knew from one of the blades that existed. Even though restrict access was set to yes, and when we jumped onto the link with a normal user, we were still able to access that page and review some details. So it's safer to have it, yes. But then use conditional access to properly control it if we can, to the Windows Service Management API and PowerShell and Graph-based resources where we can completely block them, so non-admin users and only administrators can access that. Then we have the LinkedIn account connections as well. So that basically surfaces LinkedIn data. If that is set to yes inside Microsoft 365 environment, like Outlook cards and Teams cards you can see LinkedIn information, but from what the privacy data I read, it also shares a lot of data to LinkedIn. So like things about your meetings, things about your calendar. There's a lot of privacy data in there that goes out to either way, right? You're bringing some stuff in, you're taking some stuff out. If there's no reason to be to have LinkedIn data within Microsoft's environment, that can be set to no as well, right? Although from memory, I do remember that if this is set to yes, and you do try and connect it, you, the end user does get prompted, you're about to share this data kind of thing and do you accept, they do get a consent prompt. But having no data being shared across both environments and an external environment, it's just safer to have that as no. And then lastly, we've got the lovely "show keep user signed in" button. And if you're not properly controlling that, especially if you've got security defaults enabled on your tenancies and not, you're not using conditional access, that will issue a persist, persistent cookie that will only, you know, drop you out of sign in or ask you to sign in again after 90 days of inactivity. But it does keep rolling. So if you were to access something on the 88th day, that resets, right? It goes back to the to the to the 90-day rolling window. And realistically, we want to control that. We don't want someone to stay logged in at all times. Laptops can be left open, unlocked, as Red did about a week ago. But anyway

Redouan: I don't know what you're talking about.

Jazzy: Especially on unmanaged devices as well, if there's you know kids play on that, falls into the wrong hands, we want to have that prompt being, you know, with persistent browser session policies with conditional access, that is covered later, where we can control how long we can have those sessions active, hopefully 24 hours is the number I'm going for, but what do you think Red, what's a good session policy to have for persistent browser sessions?

Redouan: Oh, that's a really good one. I've seen MSPs do a variety of things. So, I've seen some that will scope it specifically to global admins as well and then give that like a smaller amount of time, so maybe an hour or two hours. And then for regular administrative accounts, it's like four hours or something like that. And for just regular users, it can be 24 hours for instance. And usually unmanaged devices is, it's never a persistent browser session. That's usually why. Yeah. What I see, I do see a question from Luke though. "Will the slide deck be available to us?" I don't see an issue with sharing the slide deck.

Jazzy: Absolutely. We can get those out to you. Yeah, absolutely. Okay. Perfect. Awesome. And then lastly talking about groups themselves. So far we've covered some of the user settings which are available in Entra ID. I believe they fall under users and then user settings. And then we had the we have this group section here which falls under groups and group settings. I think it falls under general, if I'm not wrong, red one.

Redouan: Yeah. Yeah. Talking about the blades takes me back to my AZ-104 exam where I had to think about every single blade that existed and that drove me nuts. But somehow we end up remembering some of these now. But you see the same toggle here as well. So the security groups that we spoke about in the previous slide, which is the exact same toggle here. Where we can set that to no, for some reason I'm not, I'm not sure why they show that exact toggle in two different places.

Jazzy: That, for you, really?

Redouan: Yeah, very easy, because Microsoft loves to make, exactly, they love, they love to double up and give you more options in the same settings.

Jazzy: Why do it in one place?

Redouan: For the sharp people in the webinar, it is exactly the same toggle. And if you toggle it in this place to like yes or no, it will actually be toggled to yes or no in the other place as well. So, for some reason, Microsoft shows it in two different ways within the Entra admin center. And then after that comes the interesting one, Microsoft 365 groups. Like that's where it gets interesting. Like I'd be, I'd be really interested to hear some arguments from MSPs in the call right now, like what they do with this toggle, since Jezzy and I had a discussion about it. I mean ideally you would have like a good process around creating Microsoft 365 groups because there's like a bunch of different places within the ecosystem where users can create these groups, but then on the other side you need like a proper good process as an MSP to like have control over creating these groups because you don't want to like create every group for normal end users. So I'm really interested to see like what most MSPs do with this specific toggle, like how did you guys do that in your MSP, Jazz?

Jazzy: So I mean it's a balance of productivity and somewhat security as well at the same time. It's, well, is that, is that the right thing to say? Probably not. I mean in terms of M365 groups, right? What we, what we noticed that a lot of end users in different customers when we were at an MSP end up spinning up their own M365 groups, right? They've created a new SharePoint site because they're not controlling site creation settings for example, or they're controlling planner groups because they've gone in ahead and created a new planner and they've associated to four or five custom members and they've probably wanting to share that planner plan with them specifically, and all of these things, even Teams channels as well by the way, all of these things end up creating new Microsoft 365 groups. So 6 months down the line when one of the end users asks, "Hey, can I be added to this group, or I need to have access to this site?" And there's three finance sites with three different groups. And if we had just blocked the group creation or the Teams channel creation in terms of Microsoft 365 groups as well, you're, we know where we're going.

Redouan: You're forgetting to mention that the group naming will probably be like test 01, test 02, test everything. Like the amount of times that I've done a tenant to tenant migration. We do like an indexation of all of the SharePoint sites and all the team sites and then we discuss what we would actually migrate and then that were always the times where we would see that there's like 50 SharePoint sites called like test 01, test 02, test zero, whatever it is. And yeah, it was insane.

Jazzy: Yeah. So this would give you way more control over that, like Microsoft 365 groups and the process around it essentially. But you do have to think about it though. So yeah, ultimately Red and I went with this should be set to no so you can control exactly what groups exist. You can control the naming conventions. And if, I mean sometimes they do end up with a vague error. So, for example, if you were to create a Teams channel and it needs a Microsoft 365 group on the end, it just says you need to own a group. So, either they're an owner of a group and they try and associate to that, or if they're not owner of any groups, it just tells them to own a group. That can obviously end up with a ticket to the help desk. And then a human can actually review with some technical knowledge if that group or if that site already exists, that team chat already exists, and add them to the right group instead of creating 15 new ones every single month because they can't find the old one. I forgot that they created it. But then again, you can also reduce your amount of tickets that get sent to the help desk by switching that to yes, I suppose, right? Which will let them create, let anyone create any resource that requires a 365 group on the back end. I mean the other argument is control it on the other side. So block site creation, don't allow Teams channel creation, things like that, and only allow admins to do it. Then I guess the middle ground could be giving some people access to create 365 group, trusted members within an organization. Well, could be managers and who have all the other groups. Yeah. Give them a custom role.

Redouan: Is that, is that still a PowerShell cmdlet? Because that used to be a PowerShell cmdlet to give like a specific group access to creating Microsoft 365 groups. I'm guessing that

Jazzy: I'm sure you can do that within Entra custom roles now. So you can literally tick that, says, yeah I think there was one where I saw one of the custom permissions was allow the ability to create a M365 group and the person that creates it becomes the owner. So you can give those roles out. But then it depends on how we allow them to create the group ultimately as well, right? So if it's done via the actual app itself, then great. When they spin it up, they hopefully with the custom role, they have the ability to create it. And we can move on that way. And we don't have a sprawl of a hundred different groups being spun up every couple of weeks and help desk doesn't run out of ideas of who to add where, right?

Redouan: It's funny cuz we solved it in a different way by creating a security group and then I'm pretty sure you had a PowerShell cmdlet. I'm not, I'm not sure what it was again, but if you look it up, it's probably the like the first article that pops up, but with that PowerShell cmdlet, you could just give that security group and the members of it access to creating Microsoft 365 groups. And that's how we solved it for like most our customers cuz we didn't really want to be bothered with creating most of those groups. And then the customer, like the IT manager or whatever, they could create the Microsoft 365 groups for that environment. So yeah, makes sense.

Jazzy: So the middle ground is the best ground here, right? Give some trusted people access. Keep this to no, hopefully less tickets and they have overview of what exists, and then at least you'll have less groups being spun up constantly. And I like that, the middle ground is the best ground. That brings us to self-service group management, right? We've got two settings that they live in the same place. I believe they live in the group the groups and general page. I believe on the group settings, where we can manage group memberships where owners can manage their own group memberships in the My Groups portal. And turning that off basically stops that flow from happening. If someone owns a group, they can't approve someone requesting access or not. And it's deliberately controlled by an administrator.

Redouan: Yeah, I was, I was laughing because I saw an article by Daniel in the chat by managing who can create those Microsoft 365 groups, and yes, it is still a PowerShell cmdlet from what I can see here.

Jazzy: There we go. There we go. Taking it back. Thank you, Daniel. I mean the appeal is obviously if we do set that to yes, owners can manage their own approval flows and they don't have to wait for an administrator. But ultimately if we, if we set that to no, someone can from the help desk can actually review what that is doing, what that group is responsible for allowing access to, you know we can have a control process behind it so that when someone wants to access it they can go through it, make sure that it's verified and allowed to access the resources that are bounded by that group, and it stays with the help desk, stays with an administrator.

Redouan: And to be honest, when I saw these toggles again like a couple of weeks back when I was looking at these toggles, I was thinking like what does this actually change from like the end user perspective, because I actually forgot about that. So for the people that are thinking about that as well, when you go to like myaccount.microsoft.com, if you, if you block everything from these from these toggles, you do not have like an extra blade that says groups. But then if you don't block it, the user will have like an extra blade that's called groups. And then within that blade, users can go ahead and request access as membership to security groups, or create security groups, or they'd like to join them. "Someone outside of your organization should reopen it." I saw that it was a learn.microsoft.com article. So yeah, I did open it.

Jazzy: I mean, if you want to phish me, send me a Microsoft Learn documentation link and I will click on it. I need to send, a few clicks on that would be the best phishing for me. First thing we do. But yeah, so the My Groups portal is what this is controlling, with within the exact blade that red one just mentioned. And we can have the ability to also restrict them from viewing anything. So they only have read only access when you're, when you're a group or a user admin. And everything else is restricted from the groups features, which, yeah, I mean, is a setting that I still think is a, is a setting I'd probably configure to yes and leave it at that. We want to be able to control as much as we can, but that also does end up sometimes meaning more help desk tickets to be able to help out with, but everything should be a control process in my opinion, and as much as we can.

Redouan: Favorite topic of everyone. I just put it in the chat as an example. If you go to that, to that link, then the group blade will be shown there and that's where end users can actually go ahead and then manage groups themselves. So if that blade is not shown in your account, that means it's blocked from Entra ID. Unless you're an admin or a user admin, that then the read only right still applies. So I think they can still, the group section.

Jazzy: Favorite topic of everyone, right? Conditional access framework. We get a very high and granular security with business premium, and we get Entra ID P1 and we can configure conditional access with that. Security defaults or conditional access, for me that answer is always going to be conditional access. In terms of security defaults it's on by default. It comes included I believe in all aspects of things. In terms of licensing, it's free of charge. And it does three main things. It provides MFA for everyone. You have admin protection as well. It protects administrators, and legacy authentication is blocked. And it's a, it's a all or nothing situation, right? Everyone, if it's on, everyone gets it. If it's off, no one gets it.

Redouan: To be honest, I am pretty sure that we did make a mistake in this slide because it says it enforces MFA. One of our Intune MVPs, Luis Barry, just made an article about this as well, why business premium is like a good value proposition, and he dove into it, and in his article I read that security defaults will force users to register MFA, but then when it comes to like actually forcing them to like provide MFA, yeah, that is based on some metrics in the background by Microsoft and some mistakes that have been made. So there's been some serious cases of breach that security defaults will not force you to like provide MFA. So it will force you to register but not necessarily always force you to like actually perform multifactor.

Jazzy: I guess it depends on the on the signals in the background, right? What is triggering an MFA policy and that could be, well that is Microsoft, right? So we don't necessarily have the advantage of knowing when and where we're expecting it. Whereas with conditional access, we absolutely know exactly when it's going to happen because we're targeting those apps, we're targeting those device states and locations, and we're making sure that depending on the action that the end user is taking, that requires either the authentication strengths or, so MFA or additional authentication method to be to be prompted for, and maybe even block access for certain things. Right? Coming back to our country of usage where we can block access depending on what country you're signing in from. So conditional access allows us to be very granular in those state of mind, and ultimately if you do have a tenant that's got security defaults on, you can absolutely still deploy conditional access policies and absolutely still run them in report only mode to find out where people will get tripped up and find out the issues that will happen beforehand, rather than turning security defaults on and just chucking conditional access in them. We can have a phased approach. In the beginning, one of my, one of the mistakes I made was security defaults have to be turned off and then you can deploy conditional access policy. But actually, no, that's not true. After various testing of re-reading how Microsoft displays it was more about the fact that you can create CAs so long they're in report only mode or turned off, right? They just don't, can't be on if security defaults are on.

Redouan: I actually did not know that to be honest. I thought you had to turn them off and then create, I always turned it off and then really created the policies really quickly. Right. Since the security, or I didn't know you could create them in report only.

Jazzy: Yeah. And that's exactly where it helps, right? You can, you can find out where your gaps are and find out where users are going to be triggered before it happens. And talking about some of the conditional access policies that should be as part of our of our standard or minimum requirements. We put together a few CAs that are definitely going to be helpful. Which is, you know, MFA for internal users, MFA for B2B guests, and MFA for guests excluding B2B. But I mean, identity front door of Microsoft 365. Someone calls it the new perimeter, someone calls it the perimeter that always existed. Right. In terms of it just having MFA process allows us to block more than 99% of account takeovers. We've seen lots of reports, we've seen cyber security defense reports from Microsoft and it's a very high number by just having MFA turned on and actually making sure they get triggered at the right places. Right, you can you can associate users to it. You can have your authentication methods that are applying to it. And make sure that if you, before you do deploy, you can have this in report only mode and have all of our authentication methods selected that we still deem fit for today's date, which is hopefully not text codes and phone codes and SMSs. And the good news is that obviously ultimately this is an inforcer presentation, so we will talk about inforcer a little bit, not just Microsoft, but we do have these policies also available in our tier one blueprint baseline that you can review, the exact settings that we have, and have it turned on and configured based on our recommendations and our best practices. Have you, have you seen the chat?

Redouan: I have not.

Jazzy: "Security defaults is like a chocolate fire guard." I'm going to incorporate that in my, in my own presentations. I'm taking that, James. I'm sorry, but I'm taking that.

Redouan: Do we have to credit James underneath it as well? Little smile somewhere in the slide.

Jazzy: White on white text. One font size and that should do it, right? Love that. Absolutely love that. Someone said "security defaults is worthless for MFA. Have to combine with per user MFA." I'll be very honest, I am not a fan of per user MFA. It's really legacy type of way of managing MFA. So, I would definitely move towards conditional access for going there. But yeah, security defaults is worthless indeed. You are 100% correct. Absolutely right. Luckily down there is management access for administrators. Right. We should, exactly what you said in the beginning that we discussed, the red one, about making sure that, you know, if you have a, have a "keeping signed in" sort of turned on and the session for administrators also lasts longer, we can control that here where for administrators we have a more stricter control, right, where they can't be signed in for longer than let's say four hours, and we can have a persistence where the session signs them out and has to, they have to re-MFA when they're using administrative tasks within the portal. And we don't have to target all the resources, right, for administrators as well, we can, we can target specific endpoints that are related to the Microsoft administrator centers. So like your Azure portal or the Intune admin center or things like PowerShell and CLI and Azure DevOps. So we can target different resources and have different settings for administrators specifically when it comes to conditional access. And like it says in the slide there, I mean they are the crown jewels, where the administrator accounts are crown jewels. So first of all separate the administrative accounts. People shouldn't be using their daily driver accounts for administrative accounts as well. And again, these policies are available in our tier one blueprints baseline and you can reuse these. I reckon this might be a good time to add as well that you could probably configure token protection as well if you wanted to and make sure that if an administrator is logging in that they're coming in from the same device, where that was where that was signing in from, right? So cookies aren't hijacked and they stay bound to the same device where they signed in from. I think in terms of using this, these policies in report only mode, it might be a good time to highlight that you've also got the workbooks that you can use within Entra ID to look at the sign-in logs. You can first of all use the sign-in logs themselves and filter by that to see if there's any report only mode policies that have been triggered. You can also click on the actual conditional access policy within it. And I believe there's a report only tab there that you can have a look at. That shows you the history of the last few days of what's happened with that conditional access policy. And ultimately if you configure diagnostic settings you have access to a bunch of workbooks as well that you can use to filter against these, I think I think specifically is the conditional access insights or reporting workbook that we can use, and we can talk about those, I think I think there's a slide for that anyway.

Redouan: Talking specifically about workbooks and managing the sign-in logs and reading those, I've actually encountered some MSPs that will either forget about the report only mode or don't really understand what the report only mode does. So yeah, we do have a slide on that, right? So we'll talk about that in a bit then. Yeah. Yeah. And I'd say that the policies that we've discussed so far, security defaults do something around them. So requiring MFA for internal users for instance, or for admins as well. I'd say that this is where really gets interesting since you actually get functionalities that you just don't have within security defaults. So for instance, blocking authentication transfer and blocking unsupported platforms like the second on the bottom, or the two policies on the bottom. That's just not available in security defaults. I'm pretty sure it only does the legacy authentication one and device code flow, but then the other ones, security defaults just doesn't do. And then there's a bunch of other policies as well that security defaults just doesn't do at all. So this is where a lot of added value comes in when you when you have that P1 functionality of conditional access.

Jazzy: Yeah, absolutely spot on. In terms of how many policies that we can absolutely have in our in our baseline for all of our customers is humongous, and just using security defaults seems to be not required and moving to conditional access is the way forward, right? And again even with these policies, exactly like we said previously, that there are lots of workbooks that we can use. There may not be a specific workbook for each one of these policies, but using the workbooks and having diagnostic settings configured while you're pushing those policies out is a brilliant way to keep track of all of these.

Redouan: Yeah, definitely. And I'd say that specifically for these types of policies, like if we're talking about device code flow, for instance, I've seen some organizations or MSPs that will tell me like, we don't know if this is being used, right? We're not entirely sure if it's being used. And that is where that reporting or report only mode comes into play where you can just have that policy in report only mode for a couple of weeks or maybe two months or whatever, and then see if that policy had been impacting some of the sign-in logs. So that's really important to take note of when it comes to like configuring new policies in general.

Jazzy: Yeah. Yeah. Agreed. We have some questions in the chat though.

Redouan: I'm having some technical difficulties here. My internet's just dropped out. Oh, I thought it was, not my internet, cuz I'm in a hotel. Turns out it's my internet. My laptop's probably too hot. I can't handle the heat.

Jazzy: Your laptop is too hot. I mean, don't you have a good laptop?

Redouan: Clearly not. Clearly I need air conditioning specifically just for this. I think, I think I'm back though. I think I'm back.

Jazzy: Yeah. Yeah. Yeah. I can hear you. I can hear you just fine now. Excellent. And some other policies that we're hoping to also have included as part of your baselines is browser sessions for unmanaged devices. The Intune enrollment, sign-in frequency and token protection as well. Coming back to specifically it being Windows, is GA only and iOS and macOS are still in preview. But we would love for you to have all of these baseline policies configured and make sure that there is good use being put to them and you're not relying on just security defaults again, available as part of our policy stack, aren't they? In our blueprint baselines, a lot of these.

Redouan: We had a question in the chat about what's the best way to handle phishing resistant MFA for administrators. James already answered it, but yes, definitely use the temporary access pass. That's what we utilized as well. So that's just like a one-off like onboarding procedure where you're allowed to log in, but then after that you can actually register the pass key. And it can be quite buggy when it comes to phishing resistant MFA. That's also what I've concluded in the last like couple of couple of years using that specific setting.

Jazzy: Yeah. And seeing the gaps with Entra ID workbooks, right? So within Entra ID the logs are stored there for 30 days. You can configure diagnostic settings where you can send those out to log analytics workspace and store the data there and the logs there for as long as you decide on those log analytics workspace resource. You do need an Azure subscription for this. So it's not included in terms of business premium. And it is done separately. But we wanted to let you know that this does exist. Especially because it comes with built-in workbooks that you can access within Entra ID, monitoring and health, and then workbooks is the blade you're looking for. And there's like, I don't know, a couple dozen at least or a couple thousand workbooks.

Redouan: I have forgotten about these workbooks so many times cuz I would only go into like insights and reporting and go to like the report only results for conditional access policies. That's like the place, my go-to place to go to whenever I needed to know like what impact does a specific policy have. But please don't forget that under, is it, is it there at the audit log and sign-in logs as well? Is it under monitoring and health?

Jazzy: It is, right. Yeah, it's in monitoring and health and there's a workbooks tab there I think that you can select within Entra ID itself. So we have it on the slide actually. What am I even, monitoring and health, diagnostic settings, oh yeah, workbooks. Yeah.

Redouan: Yeah, please don't forget about that.

Jazzy: Yeah, lots of good workbooks to choose from. You know, you've got the conditional access gap analyzer in there. You've got multifactor authentication gaps. And you know, no one wants to learn another language, right? We don't want to run, learn KQL. So, it's there for you to run KQL on if you want to, but the workbooks just make life slightly easier.

Redouan: I'm already struggling learning English and running PowerShell. I don't want to add another one to my list. Too many languages in my head at this point.

Jazzy: You should have, you should have learned English by now, man.

Redouan: I am struggling to learn English. I'm from the Netherlands, man. I mean, I'm having all of these, like you, I'm having all of these US influences and then UK influences. I'm making my own accents in English.

Jazzy: I mean, it creates your own personal accent. I mean, that's what ends up happening, though, isn't it? You watch TV shows and stuff like that, and they're all in US English or British English, and you, and you end up confusing your own accent sometimes. And I don't mean to do this, when I'm speaking to someone and when they speak in their own accent, I accidentally end up mimicking it. I'm like, oops, that's not what I was supposed to be doing. I was just trying to have a normal conversation. I look like an idiot trying to, trying to act like I'm copying your accent or making fun of it. Promise, my brain just does this automatically. Copy and paste. Now we've got, we've got internal users. We've got conditional access to protect us from internal users. We've got lots of stuff that we always think about when it comes to our internal users, but sometimes we forget our lovely guests. Now, we don't want them in our environment. I always feel like guests should stay out, but you know, we need to collaborate with guests and we need to make sure that we're working with them. So, we want to talk a little bit about the guests as well. So, the four main guest types that I could think of in here was B2B collaboration guest. So any Entra ID guest you sign in with or social identity you sign in with, and you share a resource with them, or you manually invite them, they can create their own guest account and it will show up as a user type guest within your Entra ID environment. The good news is that most of their own authentication and guest account access is controlled within their own identity within their own tenant, but it does show up in your identity and the footprint is there. Then we've got the B2B collaboration member, similar to B2B guest but the user type is member instead of guest realistically. We've also got B2B direct connect that we can do. And that's when two Entra organizations explicitly allow each other to have access to the shared channel in Teams, where they can sort of be signed into their own home environment, home tenant directory, and still communicate on channels that exist within a different Entra ID environment. So they're not switching directories at the top. And ultimately is the cross tenant sync option that we have where we can synchronize our users into other directories and bring other users over into our directories, which is, which is good for if you, if you got mergers and acquisitions, or it's a multi, enterprise and it almost seems, seamlessly it works in things like Teams and stuff where you can chat with each other. We did used to set up MTOs, multi-tenant organizations, which is a slightly separate section that lives under Microsoft 365 admin center and not the cross tenant access blade within Entra ID. Well, it uses the underlying infrastructure of cross tenant access setting and Exchange relationships and things like that, but the MTO, the multi-tenant organization specific lives in, it lives in the Microsoft 365 admin center. And what can we do with those guests, right? So, we've got guest permissions that we can set up as well with it within user settings in the Entra ID portal. So, I think by default it's limited access. So, guests can't enumerate users or directory objects but can still see membership of every non-hidden group. I mean, the guests for me, that is more about restricted to an object. They need to be able to see the groups they're a part of and they can see their own profile and not really enumerate everyone else within the environment. And they should really see what they've been added to. So even if guests are added to specific groups like Teams and the Microsoft 365 group there, at least they can enumerate that, right, they can look through the Microsoft 365 group that they have access to. What would you think red one? I think I think restricted to an object is probably what I'd go for on this slide.

Redouan: I always went with the default option here. That's what I did. I mean, it was a good balance of letting guests be like productive in an environment but not let them, let them access too much. So, the default setting here was the, my go-to.

Jazzy: Yeah. Yeah. And James pointed a really good point out. I mean, this will become more important now that SharePoint adds guests when sharing files externally. So absolutely, when you, when you're sending out those files to share externally, they are also a guest in your own environment, right? That was a

Redouan: Isn't that because SharePoint now switched to B2B collaboration like underwater, from Entra ID?

Jazzy: Yeah. Yeah. That is correct. We actually had, we had some issues there because if your SharePoint settings and then your B2B settings didn't really match in the correct way, you'd have issues with guest users not being able to access files. So yeah, that has happened and I hope you got that right by now. Yeah, absolutely. And yeah, absolutely. So there is, there is some settings within the Entra ID that we can, we can also set up. So who can invite guests, right? By default, any user can invite someone. We can restrict that to only users assigned to specific admin roles that can invite guest users. So there are guest invite settings that we can control as well. So we can make sure that the right people have access in terms of who can invite guests. And then we've also got the restrictions in collaboration. So which domains can we are allowed to access and become as part of our invited guest users. So we can restrict it further and actually have an approved white list of who's allowed to jump into our environment. And we're really close to time, so I'm slightly jumping through these a little bit quickly. And then lastly, we've also got the enable guest self-service sign up via user flows as well. So, they can't sign up to your Entra ID tenant by themselves. There's no self-service signup. To be really honest, the self-service signup flow that you see here, you can set it to no. But even if it is yes, unless you actually have that flow set up and maybe associated to an app or a service principal, it's not really doing anything. But again, coming back to our point of why have it in the first place if there was no self-service signup flow required, and set that to no, right?

Redouan: Something funny in the chat that Rooney Pot said: "Microsoft has changed the default for new tenants to most restrictive." I'm guessing he's talking about the fact that the guest

Jazzy: Yeah. Yeah. The guest property adoption of what they can do.

Redouan: I didn't know that to be honest. Excellent. I mean that's good to know.

Jazzy: We've also got the trust other tenants liberty setting. So this is the cross tenant access setting we have in Entra ID for B2B collaboration and B2B direct connect. So in terms of that, if there is a, there is a tab here that I wanted to point out. So there's the organizational settings and the default settings. Those are the two important tabs you'll notice. And the default settings, they apply to all external Entra IDs when they are invited to your environment, whether you block them or allow access to certain apps. And that can be defined in the default settings, right? What resource are they allowed? Do we trust their MFA claim if they're coming from their own environment? Do we trust their compliant device states and things like that to even satisfy our CA? So if I have a CA that says require to guests to have conditional access for MFA for example, we can specify that default settings and say we trust the other environments have done their job. So they don't have to double set up MFA as well within your own tenant. And ultimately no matter what is set in default settings, if you have an organizational specific setting, that will apply, that will fall over the default settings, and they're more explicit in that way. And you can set those settings up to make sure that your communication with other inter-orgs is restricted in the way you want it to be restricted. And ultimately going back to, exactly, don't forget about this one. Don't forget about the external sharing and the limit external sharing by domain for SharePoint or OneDrive. Exactly what we mentioned a few minutes ago. Where we can trust where we can have SharePoint sites as a default not to allow any new and existing guests and have it to existing guests only.

Redouan: I am realizing again that when it comes to like guest management you have like five different places to go through within the Microsoft ecosystem. So the one we're looking at right now is in the SharePoint admin center, and then we have some tenant wide settings, and we have a dedicated guest section within the Entra portal. So yeah, nailing the guest management is so important, and doing it correctly once so you can just deploy that at scale if you'd like to, like especially as an MSP.

Jazzy: Yeah, control the settings within Entra ID, your cross tenant access settings, control those. Control your guest settings in terms of who can invite and who can't. And obviously in terms of the trust settings for cross tenant access as well. We need to make sure we've looked at all of those. And like Daniel said, don't forget the Teams. Teams.

Redouan: Yeah, I almost forgot about it, but I don't, I don't even want to talk about guest settings in Teams, because that

Jazzy: Yeah, let's not go into that. We only have two more minutes left. Do we have some more slides? What are we looking at?

Jazzy: Yeah, so I mean it's just making sure that what we've discussed today you make sure it stays true over time and across every tenant, right? So, in terms of having this in our environment is great. Having the policy switched on is absolutely great, but if it doesn't apply to anyone, if the users aren't assigned, that's a problem. And making sure that if things are changed, they're alerted upon, right? If there might be times where, help desk has changed something or we've got a co-managed IT environment and someone's changed something, use inforcer. We can help you manage all of these. We can help you deploy them. We can help you, give you baselines. We've got policies that you can make use of. You can make sure that the user assignment the group assignments remain the way they should be, matching your baseline, and that if anything ever trips we're alerted upon.

Redouan: Yeah, exactly. And please reach out to us with any Microsoft 365 questions because we love talking about it and diving into Microsoft Learn. I actually still enjoy it some days. Not every day though, but some days I do enjoy it.

Jazzy: Guys, it was awesome to have you all here. The chat's been amazing. You guys have been amazing. Thank you for all of you that came through. Hope, hopefully you nerded out like us and we really appreciate all of your times, taking the time to join us.

Redouan: What is the next webinar about? Because we, this is a series for everybody who's in the, in the webinar right now. So this is a series and the next

Jazzy: Oh, it's in the slide again. There we go. There I go again. It's in the slide again. So next webinar is actually about Defender for Office 365 where we'll dive into that. So, thank you so much everybody for joining. I mean, this was a great amount of people that joined the webinar. So, that's awesome.

Redouan: Thanks guys. Have a great time wherever you are and enjoy your weather. Hopefully, it's as bad and good as us, if you like it hot. But again, what's the weather now in the UK?

Jazzy: I'm at 33 degrees at the moment. I'm sweating everywhere. Seriously. Hopefully, it hasn't shown on my face, but I am sweating everywhere. I think it's like, definitely send the slides. A lot of people have asked to send the slides. We will absolutely do that guys.

Redouan: Yeah. Yeah. Yeah. Yeah. 100%. I think it's like 22 degrees or something like that here in South Africa. I mean, so it's way hotter in the UK right now. UK, come to the UK.

Jazzy: I'll see you next week.

Redouan: Yes, I will be there next week. Yeah. A lot of traveling on my side, man.

Jazzy: Awesome. Well, we'll go ahead and end the event. Have a great time and the slides will hopefully be emailed across to everyone that came through.

Redouan: Yes, we will email the slides. Thank you so much everyone. Bye-bye.