Know Your Stack

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, 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 if it is night, they absolutely love uh uh these webinars, wanted to join during this time. Absolutely love it. Absolutely love it. Well, good to have you all. Um, thank you for for being part of our webinar, part one of our Know Your Stack series, a four-part webinar, uh where we'll talk about a few things, uh Microsoft world and and the things we love doing every day, each day. Um, I I think uh 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 uh people can see.

Red: I guess so. It's uh already 2 minutes past 4. So I'm guessing that most people have joined so far. Do we um do we have like a Q&A section or do we just use the chat within uh 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.

Red: Greetings from Switzerland. Greetings from South Africa. Actually, I'm in South Africa right now for some on-site engagements for Inforesters. 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 uh 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 I'm I'm based in Richmond, United Kingdom. It's almost 100° here. Uh not really, but that's what it feels like. I am melting slightly. Um, 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.

Red: 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 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 about us and and who we are. Um, welcome guys. I'm Jazzy. I'm part of the Microsoft 365 solutions architect team here. Um, I'm a Microsoft fanboy first of all. That's that's all I love. That's all I talk about. Even even with my misses. Uh somehow, someway I managed to bring Microsoft in the conversation. Um, I am also the official IT support for my parents, without a doubt. Anything that ever goes wrong it's it's a phone call straight to me. Uh somehow I I know everything about phones and TVs and the the fan that sometimes doesn't work and and swivels in the wrong direction, even though there is no right direction for a fan to realistically swivel. Um, and my whole IT career has been MSP. That's all I've ever done guys. I've only ever worked on MSP. Uh I've been uh heavily involved with with the Microsoft ecosystem, things like Intune, Entra, Exchange, a little bit of your virtual desktop here and there. Uh and and that's a little bit about me and and nice to have you all. We're 134 big right now on this webinar. So, thank you for joining. Uh I did create this slide like 10 minutes ago, so I didn't get—

Red: 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.

Red: I will, I will introduce myself as well. So, my name is uh Rayon Bulite. 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 they probably know where it is. Um, 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 um on the Microsoft ecosystem. So defend office, defend the cloud apps, all all of that, all of those shenanigans within Microsoft 365. We we configured it and we were really focused on it. And since uh, I want to say a month or two right now, I um I'm a solutions architect here at Inforcer. So uh 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 we're ready to to hopefully inspire some knowledge that that wasn't already there and and maybe we we learned some from from all the other experts in in the call as well. And happy, happy for all of your inputs and questions in the chat. So, feel free to go. Um, I am controlling the slides. So, Redon, whenever whenever you need me to go to the next one, you can tell me as well and and we'll do, we'll do this together. Um, FYI guys, none of this is rehearsed. We're doing it on the fly as we always do. Um, so we we we'll make it work as as we always do. Um, things will cover. So we'll cover some of the stack that you already own. Um, and talk about some of the foundation work that we can harden that sometimes gets missed in um, obviously conditional access, can't can't speak about ID without speaking about conditional access. Uh and some external and cross tenant collaboration that we may have missed about guest, um type of security and infrastructure that we have available uh inside Entra ID, and making sure that we we configure things and make sure they they stay enforced, right? Because configuring a policy, turning it on and not applying means, 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?

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

Jazzy: Awesome. Awesome. So, stack you already own guys. You you've you've paying for business premium. Hopefully, all of you are, um, and that includes Entra ID P1 uh that is included um with the licensing. And 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 uh P1. We've got the business premium licensing under 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 we find, we don't find things we're looking for within Entra ID, uh and that covers other workloads as well like Defender and antivirus and um Exchange email security gateway and things like that. And you, it starts stacking up, right? You start having more portals to cover, uh more, more work for the invoicing team to to ask for money for other products that you're covering uh and just more consoles ultimately.

Red: 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 I'm guessing that for a lot of people that this is making sense. Um, 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 uh they don't really know that it's already included within business premium actually, or or it might even be cheaper to move to business premium and then leave some of those tools, cuz nowadays Microsoft technologies, I mean uh you can check the Gartner quadrant um charts, right? I mean Microsoft is in in top of the charts. So I guess that the 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 if that makes sense.

Jazzy: Yeah, absolutely. No, absolutely does. You're spot on. And 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 uh because we we we know and we've been trained on it. Um, 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. Um, 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?

Red: 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 to move towards business premium.

Jazzy: Absolutely. So what do we get? We get Entra ID P1 in business premium. Uh we've got things that we can configure such as conditional access that we'll talk about uh in a minute. We've got SSPR in there, self-service password reset. We we even got password protection in there where we can um apply certain words that are refrain from being used as passwords, like a banned user password list. Um, 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 uh uh IP address or could be the customers uh offices of the world where they are. So we could, you know, block certain countries from being accessed into their Entra tenant environment and and just allow certain countries. And you've got proper security reporting that comes out of Entra. There's so many reports, especially with with workbooks as well, isn't there? Uh when you do the diagnostic settings and there's lots of reporting that can be pulled out, uh if I'm not wrong, with by standard in Entra ID you get 30 days of uh 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 um 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 to help us with MFA. So that approach there for us as well. Um, we do have an add-on, right? P2 um which can be purchased on top of your business premium, uh is part of some suites as well. I think uh 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 um and privileged identity management as well. So the just in time, just enough access protocol uh to make sure that we're covering that framework. So with PIM, you can elevate up to uh 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 uh roles to everyone. Give everyone GA, because that's what turns out to be happening.

Red: Um, it does still happen though. I mean, I've seen it. Unfortunately, it does.

Jazzy: Absolutely. I've seen it too. We 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 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 for people that don't know—

Red: 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.

Red: Yeah. I mean, we 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 uh license if we were to like properly configure the the uh the roles with uh with PIM. So, yeah.

Jazzy: Yeah. Yeah. And and making sure that every user gets that P2 license. Yeah. Not just the one to unlock it in the tenant, like like 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.

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

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

Red: Yeah. If I could even add to that, um 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 I'm pretty sure that the next slides we're going to discuss some more. By default users can actually register uh app registrations within within the tenant. So not sure why that is. That is really for like uh enterprise um 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 uh 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 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 uh all of them correctly. And the same goes for uh security groups. Sorry for taking over, Jazzy, by the way.

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

Red: 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 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 um the 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 you're spot on. I completely agree. So, in terms of the M365 groups, I still feel like there may be some uh 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 for security groups to be enabled? And exactly like you said, it's 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, 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 we'll we'll think about it, right? Um yeah, so there's someone in the chat, Martine, thank you, thank you for uh sending it. If a customer needs to do it themselves we give them, we give the user PIM with a role.

Red: 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 uh 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. Uh if there is any reason for that. Um but yeah, I think I think these default settings can definitely be changed, especially with default user role permissions. Um, and exactly, um with 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.

Red: Yeah. Yeah, we were talking about that. So, 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 please make note of that and uh don't forget that.

Jazzy: That was insanely funny, right? Because because we we were able to copy and paste the link from 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 it's safer to to have it, yes. But then use conditional access to properly control it if we can, um to to the Windows Service Management API and and PowerShell and Graph-based uh resources where we can completely block them, so non-admin users and only administrators can access that. Um, then we have the LinkedIn account connections as well. So that basically surfaces LinkedIn data. Uh if if that is set to yes uh inside Microsoft 365 environment, like Outlook cards and Teams cards you can see LinkedIn uh information, but from from what the privacy data I read, it also shares a lot of data to LinkedIn. Um, so like things about your meetings, things about your calendar. There's a lot of privacy data in there that that goes out to, 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? Um, although from from memory, I do remember that if this is set to yes, uh and you do try and connect it, you, the end user does get prompted, you're, 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. Um, 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 on the 88th day, that that resets, right? It goes back to the to the uh to the 90-day rolling window. Um, and realistically, we want to control that. We we we don't want someone to stay logged in at all times. Laptops can be left open, unlocked, um, as as Red did about a week ago. Uh, but anyway, um—

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

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

Red: Oh, that's a really good one. I've seen MSPs do a variety of things. So, I've seen some that will um scope it specifically to global admins as well and then give that like a 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 that that's usually why. Yeah. What I see, um I do see a question from Luke though. "Will the slide deck be available to us?" I don't see an issue with 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, so far we've covered uh some of the user settings which are available in in Entra ID. I believe they fall under users and then user settings. Uh, and then we had the uh, we 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.

Red: Uh, yeah. Yeah. Talking about the blades uh 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 um you see the same toggle here as well. So the security groups that we spoke about in the previous slide, which which is the exact same toggle here. Uh where we can set that to no, um 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?

Red: 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, why do it in one place?

Red: For the sharp people in the webinar, it 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 in in two different ways within the Entra admin center. And then after that comes the interesting one, Microsoft 365 groups. Like that 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 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 it it's 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 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 and they've uh 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, uh, can I be added to this group, or or 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.

Red: 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 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 uh discuss what we would actually migrate and then that, 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, so this would give you way more control over that, like Microsoft 365 um groups and the the process around it essentially. But you do have to think about it though. So, 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 uh 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 to own a group. That can obviously end up with a ticket to the help desk. Uh, 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. Um, but then again, you can also reduce your amount of tickets that get sent to the help desk by by switching that to yes, I suppose, right? Um, which which will let them create— let anyone create any resource that requires a 365 group on the back end. Um, I mean the 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. Um, then then I guess the middle ground could be uh giving some people access to to create 365 group, uh trusted members within an organization. Uh well, could be managers and who have all the other groups. Yeah. Give them a custom role.

Red: 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 uh allow the ability to create a M365 group and the person that creates it becomes the owner. Um, so you can give those roles out. Um, but then it it depends on on how we allow them to create the group ultimately as well, right? So if it's done via the the actual app itself, then great. When they spin it up, they hopefully with the custom role, they have the ability to create it. Um, and and we can move on that way. And and we we don't have a sprawl of a hundred different groups being spun up every every couple of weeks and help desk doesn't run out of ideas of who to add where, right?

Red: It's funny cuz we um 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 uh 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 uh 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, give some trusted people access. Keep this to no, uh hopefully less tickets and they have overview of what exists, uh and then at least you'll have less groups being spun up constantly. And and I like that, the middle ground is the best, best ground. Um, that that brings us to self-service group management, right? Um, we've got two settings that that they live in the same place. I believe they live in the group uh, the groups and and general page. I believe on the group settings, um where we can manage group memberships where owners can manage their own group memberships in the the My Groups portal. Uh and turning that off um 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.

Red: Um, 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. Um, I mean the appeal is is obviously if we do set that to yes, um owners can manage their own approval flows and they don't have to wait for an administrator. Uh but ultimately if we, if we set that to no, someone can from the help desk can actually review uh what that is doing, what that group is 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, um and it stays with with the help desk, stays with an administrator.

Red: 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 uh 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 that's called groups. And then within that blade, users can go ahead and um request access uh as membership to security groups, or create security groups, or or um uh they'd like to join them. [Reading chat] "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. Um, but yeah, so so the My Groups portal is what this is controlling, with within, within the exact blade that that red one just mentioned. Um, and we can have the ability to to also restrict them from uh viewing anything. So they only have read only access um when you're, when you're a group or a user admin. Um, and everything else is restricted from from the groups features, which, yeah, I mean, is is a setting that I still think is a, is a setting I'd probably configure to yes and leave it at that. Um, we want to be able to control as much as we can, but that also does end up sometimes meaning uh 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.

Red: Um, favorite topic of everyone. I just put it in the chat as an example. If you go to that, to that link, then the 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 uh 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: Um, favorite topic of everyone, right? Conditional access framework. We we we get a very high and granular security with with uh with business premium, and and we get Entra ID P1 and we can configure conditional access with that. Um, security defaults or conditional access, for me that answer is always going to be conditional access. Um, in terms of security defaults it's it's on by default. Uh it comes included I believe in in all aspects of things. Uh in terms of licensing, uh it's free of charge. Uh and it does three main things. It it provides MFA for everyone. Uh you have admin protection as well. Uh 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.

Red: To be honest, I am pretty sure that we did make a mistake in this slide because it says it enforces MFA. Um, 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 um 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 uh, of breach that security defaults will not force you to like provide uh 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 uh on the signals in the background, right? What 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 um we're making sure that depending on the action that the end user is taking, that that requires either the authentication strengths or, so MFA or or additional authentication method to be to be uh prompted for, uh and maybe even block access for certain things. Right? Coming back to our country of 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 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. Um, 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, 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 if security defaults are, are on.

Red: 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 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, before it happens. Um, and talking about some of the conditional access policies that should be as part of our of our standard or or minimum uh requirements. Um, we we put together a few, few CAs that are definitely going to be helpful. Um, which is, you know, MFA for internal users, MFA for B2B guests, and MFA for guests excluding B2B. Um, but I mean, identity front door of Microsoft 365. Um, someone, someone calls it the new perimeter, someone calls it the perimeter that always existed. Um, right. Um, in terms of it just having MFA process allows us to block more than 99% of account takeovers. Um, 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. Um, right, uh you can you can uh associate users to it. You can have your authentication methods that are applying to it. Uh and 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. Um, and the good news is that obviously ultimately this is an uh inforcer presentation, so we will talk about inforcer a little bit, not just Microsoft, uh but we do have these policies also available in our tier one blueprint baseline that you can review, the exact settings that we have, um and and and have it turned on and configured based, based on our recommendations and our uh best practices. Have you, have you seen the chat?

Red: 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.

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

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

Red: Uh, talking specifically about workbooks and and managing the the sign-in logs and reading those, I've actually encountered some MSPs that will uh either forget about the report only mode or don't really understand what the report only mode does. So um, 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 um the policies that we've discussed so far, security defaults do something around them. So um 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 uh second on the bottom, or the uh two policies on the bottom. Uh that's just not available in security defaults. I'm pretty sure it only does uh the legacy authentication one and device uh 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 uh when you have that P1 functionality of conditional access.

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

Red: 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 uh tell me like, we 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, that's really important to uh take note of when it comes to like um configuring new policies in general.

Jazzy: Yeah. Yeah. Agreed. Um, we have some questions in the chat though.

Red: 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, 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?

Red: Clearly not. Clearly I need air conditioning specifically just, just for this. Um, 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. Uh and and some, some other policies uh that we're hoping to to also have um included as part of your baselines is browser sessions for unmanaged devices. Uh the Intune enrollment, sign-in frequency and token protection as well. Uh coming back to specifically it being Windows, uh is is GA only and iOS and macOS are still, still in preview. Um, but we would love for you to have all of these baseline policies configured uh and make sure that there is good use being put to them and you're not relying on on just security defaults again, available as as part of our um policy stack, aren't they? In our blueprint baselines, a lot of these.

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

Jazzy: Yeah. And uh seeing the gaps with Entra ID workbooks, right? So within Entra ID the logs are stored there for 30 days. Uh you can configure diagnostic settings where you can send those out to log analytics workspace uh and and store the the data there and the logs there for as long as you decide on those log analytics workspace um resource. Uh you do need an Azure subscription for this. So it's not included in terms of business premium. Uh and it is done separately. Uh but we wanted to let you know that this does exist. Uh especially because it comes with built-in workbooks that you can access within Entra ID, monitoring and health, and 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.

Red: 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 the place, my 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 uh within 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.

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

Jazzy: Yeah, lots of good workbooks to choose from. You know, you've got the uh conditional access gap analyzer in there. You've got multifactor authentication gaps. And you know, no one wants to learn another language, right? We 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.

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

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

Red: I am struggling to learn English. I'm from the Netherlands, man. I mean, I'm, 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 or British English, and you, and you end up confusing your own accent sometimes. And 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, crap, 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 or making fun of it. Promise, my brain just does this automatically. Copy and paste. Um, now we've got, we've got internal users. We we've got conditional access to protect us from uh 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 I I I always feel like uh guests should stay out, but you know, we need to collaborate with with guests and we need to make sure that that we're working with them. So, we want to talk a little bit about the guests as well. So, uh the four main guest types that that I could think of in here was, was B2B collaboration guest. So uh any any Entra ID guest you sign in with or social identity you sign in with, uh and you share a resource with them, or or you manually invite them, they they can create their own guest account uh and it will show up as as a user type guest uh within your Entra ID environment. Um, the good news is that most of their own authentication and and guest account access is controlled within their own identity uh within their own tenant, but it does show up in your identity and the footprint is is there. Um, then we've got the B2B collaboration member, similar to B2B guest but the user type is member uh instead of guest realistically. Uh we've also got B2B direct connect that we can do. Uh and that's when two Entra organizations explicitly allow each other to have access to the shared uh channel in in Teams, uh where where they can sort of um be signed into their own home environment, home tenant directory, and still communicate on on channels that exist within a different Entra ID environment. So they're not switching uh directories at the top. Uh 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 or it's a multi— enterprise and it almost seems, uh seamlessly uh it works in in things like Teams and stuff where you can chat with each other. Um, we we we did used to set up MTOs, multi-tenant organizations, which is a slightly separate section uh that lives under Microsoft 365 admin center uh 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 uh lives in— it lives in the uh Microsoft 365 admin center. Um, and what 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 um it's 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 that is more about restricted to an object. They need to be able to see the groups they're a part of um 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 uh groups like Teams and uh the Microsoft 365 group there, at least they can enumerate that, right, they can look through the Microsoft 365 group um that they have access to. Um, what what would you think uh red one? I think I think restricted to an object is is probably what I'd go for on this slide.

Red: I always went with the default option here. That, that's what I did. I mean, it was a good balance of of uh letting guests be like productive in an environment but not let them, let them access too much. So, the the 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 to share externally, they are also a guest in your own environment, right? That was a—

Red: Isn't that because SharePoint now switched to B2B collaboration like underwater, from from 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, you'd have issues with guest users not being able to to access files. So yeah, that has happened and I hope you got that right by now. Yeah, absolutely. Um, and and and yeah, absolutely. So there is, there is some, some settings within um uh the Entra ID that we can, we can also set up. So uh who can invite guests, right? By default, any user can invite someone. Um, we can restrict that to only users assigned to specific admin roles that can invite guest users. So there, there are guest invite settings that we can control as well. So we can make sure that the right people have access um uh in terms of who can invite guests. Uh and then we've also got the restrictions in collaboration. So which domains can we uh, are allowed to access uh and become as part of our invited guest users. So we can restrict it further and and actually have an approved white list of of who's allowed to jump into our, our environment. Uh, and we're really close to time, so I'm slightly jumping through, through these a little bit quickly. Um, 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 um your Entra ID tenant uh by themselves. There, there's no self-service signup. Um, to be really honest, uh, the self-service signup flow that you see here, you can set it to no. Uh 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?

Red: Something funny in the chat that uh 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 of what they can do.

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

Jazzy: Um, we've, we've also got the the trust other tenants liberty setting. So this is the cross tenant access setting we have in Entra ID uh for B2B collaboration and B2B direct connect. Um, so in terms of that, if there, there is a, there is a tab here that 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 uh when when they are invited to your environment, whether you block them or allow access to certain apps. Uh and 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 uh and things like that to even satisfy our CA? So if I have a CA that says require uh, uh 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. Uh and ultimately no matter what is set in default settings, if you have an organizational specific setting, that will apply, that will uh fall over uh the the default settings, and they're more explicit in that way. And you can set those settings up um to make sure that your communication with other inter-orgs is 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. Um, where we can trust uh, uh where we can have SharePoint sites as a default not to allow any new and existing guests and have it to existing guests only.

Red: 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 uh guest section within the Entra portal. So yeah, nailing the guest management is so so important, and doing, 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 uh in terms of who can invite and who can't. Um and and obviously in terms of the trust settings for for um cross tenant access as well. We need to make sure we, we've looked at all of those. Uh and like Daniel said, don't forget the Teams. Teams.

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

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

Jazzy: Yeah, so I mean it's it's just making sure that what we've discussed today uh you, you make sure it stays true over time and across every tenant, right? So, uh in terms of um having this in in our environment is great. Having, 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. Uh and and making sure that if things are changed, uh they're alerted upon, right? If there might be times where, uh 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 uh, the group assignments remain the way they should be, matching your baseline, and that if anything ever trips we're alerted upon.

Red: 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, 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, thank you for all of you that came through. Uh hope, hopefully you, you nerded out like us and we really appreciate all of your times, taking the time to join us.

Red: 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 uh, we'll dive into that. So, thank you so much everybody for joining. I mean, this was a great, great amount of people that joined the webinar. So, that, that's awesome.

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

Jazzy: I'm, I'm at 33 degrees at the moment. I'm sweating everywhere. Seriously. Hopefully— 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.

Red: 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 way hotter in in in the UK right now. UK— come, come to the UK.

Jazzy: I'll see you next week.

Red: 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.

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