Teams Real Simple with Pictures: Using Restricted Management Administrative Units in Microsoft Entra ID

This week I've been asked what I think about the rebranding of Azure AD to Microsoft Entra ID. Is it something which I would consider significant? Is it something I think occurred because, for example, some marketers in Redmond have nothing better to do? Let's consider that a moment. In recent years, Microsoft has executed multiple large-scale rebrands. Office 365 to Microsoft 365. Azure to Microsoft Azure. The Security stack aligned under Defender, whilst Compliance is amalgamated under Purview. So my thinking goes that the rebranding of Azure AD was only ever a matter of time; that it was only ever going to go one way given how Microsoft Entra became the brand for Microsoft's Identity services. If one thing, all these cases illustrate that Microsoft is not beholden to names or brands whether these are historical or popular, or where they've become embedded in the day-to-day language of the very organisations and communities that use them. And this was demonstrated again last week - with not so much fanfare - when they also announced that it was ditching it's default Calibri font in favour of the newly developed Aptos. But then Microsoft is a technology business after all. It's mantra is that change and innovation is constant. This leads onto point two. There are things that drive change and innovations other than technology. We as technologists can lose sight that Microsoft is first and foremost - when everything is stripped away - a sales-led techonology business. Sometimes we don't perceive or appreciate the value of changing it up, because it's not our role to give these products fresh impetus, or drive astronomical numbers in a given area, or reduce a products value and everything it does to a singlular name. I think the rebrand makes absolute sense given Microsoft's plans are for Security, Compliance and Identity. Consistency across the range. An easier conversation for commercial. A broader and more robust terminology which allows the addition of more products such as what we saw given the Security Service Edge (SSE). It may just be me but it feels more unified yet clear cut and distinct from other parts. I also think it's a savvy move to take Azure - the platform - out the name. But don't get me wrong here. Many of us are going to have to swallow pain, especially we who create or maintain content or teach. And yes - it's sad too in that it feels like an instituion is ending. But let's look forward with gusto. It's not the last one of these we'll be doing. Change is constant. This blog is on the new Restricted Management Administrative Units capability now in preview in Microsoft Entra ID. You can now designate specific users, security groups, or devices in your Microsoft Entra ID tenant that you want to protect from modification by tenant-level administrators. Obviously this has benefits in certain scenarios - typically larger orgs, where administration is based on geos. And we need to understand that at this preview stage this is based on Microsoft Entra ID actions such as modifying users and licences, not management of the services themselves. In Teams world, I am going to apply a use case of managing users with Teams Premium Licencing

Teams Real Simple with Pictures: Configuring Zero Hour Auto Purge (ZAP) for Teams through PowerShell now in Preview

Ok, first things first - congratulations to all the Microsoft MVP's who were renewed this week! It was awesome to see so many friends, and so many passionate community members earn the award after their incredible efforts last year. Blogging. Speaking. Feeding back to product teams. Sharing code. Running events. Staffing events. Writing books. Even social media. You name it. Jeff Teper - CVP of Microsoft SharePoint and Microsoft Teams often refers to them at events and on social as being part of 'The Best Community in Tech'. It's something I would have to agree upon having known many of them now for some time. So congrats again MVP's! And with that out the way for another year let's move onto the blog which is a shorter one this week, and a direct follow up from a recent blog on ZAP within the new Collaborative Security for Microsoft Teams. Now only last month I recommended sticking with the security presets given that since it came out in March there didn't appear to be a seperate ZAP policy for Teams and that the settings for Exchange Online and Teams appeared to be bound together. But in a recent message issued through the Message Centre this week, it was announced that Microsoft is 'adding new Teams Protection cmdlets to control ZAP for Teams'. Moreso, 'Going forward, please utilise the new cmdlets to control ZAP and quarantine policies for Microsoft Teams'. So the good news all up is that management starts becoming more granular, and you can have different ZAP policies for Exchange Online and Teams if and should you need them. On the other hand it's likely going to raise a few questions such as - if the policies are set in PowerShell moving forward will they then surface in the Microsoft 365 Defender Portal and the security presets? And if they are set in PowerShell, will changes in the Microsoft 365 Defender Portal overwrite? Whilst this blog is an awareness piece regarding the cmdlets and serves as an addendum to the previous blog given personal testing, I would actively encourage admins to go on and test further. Being in preview and with so much evolving so quickly it's fair to state that we don't ultimately know the destination or the final intended behaviours and user experience as it isn't confirmed beyond these cmdlets. Whilst I would wager that there will be a change in the GUI so that ZAP policies for Exchange Online and Teams are distinct and explicit, and that you will see the specific Teams Protection policies on quarantined items, and everything will fit flush within the presets, well you just never know, or when that's going to land. So let's look at something that has a load of caveats on, but at the same time will be central to how ZAP for Teams is managed moving forward.

Teams Real Simple with Pictures: Blocking Anonymous Users Read Access in a Meeting Chat

2023 has been one wild year. The divestiture and merger of the business I work for. It's subsequent rebrand. The last few weeks its been all about expansion and the rollout into Switzerland. I've been over in Ireland. I've been doing things out in the UAE. Now all of these things - all up - have gone well. Despite many long days and a few pressure cooker situations it's been generally excellent and a very exciting experience; one of those intense and fascinating periods where you need to bring your A game and step up to the challange of it. But for the first time since I have been in the Microsoft Tech Community - since around the start of 2018, the sheer load and the scale of realignment has meant I have struggled to get to the community. The blogs. The events. All the rest of it. I completely missed Build. I completely missed Commsverse. I simply couldn't get to them. And whilst I managed to squeeze out a bit on Collaborative Security in May; the new functionalities such as Attack Simulation, End User Reporting and ZAP, I've had people ask - where have you been? Are you ok? The answer is yes! I am happy that corp work is almost to a sustainable level, and that I can start to engage with the community again. And so I am going to pick up with a small, security related functionality in Teams meetings which I noticed has now appeared in the Teams Admin Centre (TAC) which is to block anonymous users read access in a Meeting Chat. More succinctly 'Microsoft Teams IT Admins will be able to block anonymous users from accessing the chat in internally hosted meetings by disabling their read access on top of the existing disabled write access'. In other words, anonymous users will have neither read or write meeting chat access meaning they won't see the chat. Why is this important? An anonymous user is a user who joins a meeting via a link. The user isn't logged in with their Microsoft account or their organization’s account. This could, literally be anyone who has received, or managed to get their hands on the link to the meeting who isn't strictly authorised to be there. And if we permit anonymous users - which some orgs need to do, then it is good that the chat can be controlled in such a manner that these users can't scrape/exfiltrate information - particularly sensitive information out the chat. All set?

Teams Real Simple with Pictures: Collaboration Security for Microsoft Teams – Zero-Hour Auto Purge (ZAP)

Over the last month we've gotten into it on two of the four components of Collaboration Security for Microsoft Teams which were announced back at Secure in March - Attack Simulation and End User Reporting. Both seem really solid adds. I personally think that both are worth the price of the P2 in order to bring this XDR functionality into Teams. So let's push on and investigate the third component - one which has been part of Exchange Online for some time which is Zero-Hour Auto Purge. Typically known by its acronym ZAP, in the context of Teams it 'protects end-users by analyzing messages post-delivery and automatically quarantines messages that contain malicious content to stop the actor from compromising the account'. So it is a retroactive automated protection feature which goes after malware, spam and phishing messages. Furthermore 'once a malicious message is identified, the entire Teams environment will be scanned for that same indicator of compromise and quarantine relevant messages at scale for more effective protection'. Sounds good. Sounds like it's going to be a real big help to admins who cannot be on hand - or are expected to be on hand - to continuouly monitor their users chats in Teams 24/7. So let's see ZAP in action. It is currently in preview like the other components and on by default if a P2 licence is assigned and CSTM is lit up via the shell. Of all the components within CSMT this is the one I see changing the least by the time GA comes around since it just works. But having tested the past few days there appears to be some hefty limitations at the time of writing - and ones that as Microsoft 365 admins we need to know upfront even though we know it's only at the preview stage. One. ZAP only works on private chat and private group chat currently. Channel conversations aren't supported today. Given that channel messages are housed in shared mailboxes within the Microsoft 365 group construct that's surprising. But hey, that exactly what happened with loop components so I am pretty sure that will arrive at some point. Two. On the testing I did this weekend it only seems to work for messages within the organisation currently. In other words, no federated chat support for messages sent and received to/from others outside the organisation. That's probably the biggest limitation here in terms of day to day use or the likelihood of something malicious getting in. Three. During testing I noticed it doesn't seem to cover meeting chat which is also important, especially if the org allows anonymous users to join meetings. Now, these could be blockers for many organisations. Or they may not be given these orgs could be adding CSMT in preview primarily for the other components. It'll be important to support all three moving forward, but looking past this the preview does a good job showing you how ZAP works if you have something to test it with.

Teams Real Simple with Pictures: Collaboration Security for Microsoft Teams – End User Reporting

My memory is a little hazy as I approach my 40th year on this earth next week, but it doesn't seem too long ago that Teams was added into Defender for Office 365. And when I think of the two together, I typically think about Safe Attachments and Safe Links, and their application via built-in security policies, or through custom policies within the Microsoft 365 Defender Portal. But now - after Microsoft Secure a few months back - we have seen the introduction of 'Collaboration Security for Microsoft Teams'. Sounds awesome. And I almost had to crack a smile whilst I was sitting there in that hotel room in Paris doing Secure since I actually worked on parts of it over recent months through inner ring testing without ever knowing what it was meant to be, or what the totality of it was. By definition CSMT is 'the full feature set that customers use to protect their email environments across prevention, detection, and response to Microsoft Teams'. In other words its bringing Teams fully into it's Extended Detection and Response (EDR) solution which is Microsoft 365 Defender, which correlates signals and alerts across others domains such as identities and endpoints. Why is this important? In the words of Microsoft 'Attacks like phishing and ransomware that for decades have primarily used email as an entry point, are now also targeting users on collaboration tools with growing frequency' which makes sense given that Teams is now used by over 300 million users worldwide - many of whom it is fair to say are not protected to the extent they could be. So who can use CSMT?, 'If you are a customer of Microsoft E5, Microsoft E5 Security, or Microsoft Defender for Office 365 (Here meaning Plan 2, not Plan 1) you can take advantage of [this set of new capabilities] immediately and improve the security of your Microsoft Teams'. Very exciting then. Now this blog post was in fact meant to come out a month ago and was meant to be the lead off to a whole CSMT series: but a bug in my Ring 4 test environment meant I had to do attack simulation first. C'est la vie. We are going to enable CSMT and report a suspicious message for our security admins.