Its Sunday night. 9pm. I am teaching Microsoft 365 Fundamentals the next few days. I am speaking at Build the week after. So you know the score. Yes - that's right it's Jack Bauer time all over again. And so this week I'm gonna change tack (yet again) and return to talking about Azure AD: this time about authenticator notifications and lighting up two preview functionalities. The first is Number Matching which requires users to enter the number displayed on the sign-in screen, and Additional Context which adds the app the user is signing into as well as their IP location. Why are these important? Well, imagine a user who simply - without thought - approves an authenticator request when it pops up on their device. What if that approval isn't actually legit at all. What if it's a malicious actor who has phished the users credentials and knows that if they periodically enter the username and password, that there is a high probability the user will approve the request. By default authenticator doesn't ask you to take any further actions apart from approval or denial nor does it make you second guess that. It doesn't give you any information to say what app is being accessed or where they are signing in from. If I put my security hat on that's problematic especially when accessing apps such as Teams which could contain a lot of sensitive information. So two nice adds to the authentication experience. They make the user more mindful and this should - in theory at least - harden the security posture.
Last week, after I wrote the previous article on B2B Management Policy I had a nagging feeling that I wanted to write something more. It was in the back of my brain I just couldn't articulate it. Then during this week when I was teaching SC-900 and doing labs with Azure AD I remembered. Then, me being me I forgot it again. It's been that kind of week. But sitting in the restaurant today at Wagamama whilst eating a load of teriyaki soba it all came flooding back: it was a complimentary piece to B2B management on how we can restrict adding guests based upon external identities and leveraging Azure AD roles. Last week, we saw how you could out and out block specific domains, which meant that guests from those specific domains cannot be added. This week, we are going to see how you can stop Teams owners from adding guests unless they have a specific Azure AD role assigned called Guest Inviter. This has two real benefits. The first is that it stops Teams owners backdooring guests when you have implemented Entitlement Management because setting up EM doesn't suddenly strip Team owners of adding guests directly in the team itself via manage users. Secondly, because Team owners no longer have standing access to invite guests and you are basing that functionality upon assignment of an Azure AD role, you can now run it through PIM and this would go well with an access review. Now it would certainly be what you could call an EM light approach. The upside would be you no longer have to deal with catalogues or packages which removes a layer of complexity. The downside is that with EM you can package multiple Teams/Microsoft 365 groups/SharePoint site at a time: what follows wouldn't be able to do that. Still, it gives us another tool in the kitbag should we want. It also works from the perspective of not having to purely rely on having to use sensitivity labels to block guest access to specific teams, since Team owners won't be able to do that unless they have the assigned role - and then they could be used anyway. So in short, this facilitates EM through to its full conclusion or an alternative approach which isn't so rigid as EM, but still puts controls on users adding guests carte blanche.
called a B2B Management Policy. Now, why would we use this and how does it fit in with how we already manage guests? In terms of how we would use this, think of it as follows. When we enable guests in the TAC, we allow Teams owners to invite B2B users from any organisation. That's cool and frictionless - except thinking about zero trust, it means that we could be leaving ourselves open to insider risk and competitors being added to our Teams. Now, we could go down the route of using sensitivity labels - but we really want to simply block the competitors whole org and any of their users being added to ours as guests. We could go down the route of entitlement management - but this can be heavy and would involve actions on the part of users: besides; it could be bypassed anyway as EM doesn't lock the ability to add guests via Teams. No, we want something quick and frictionless and automatic: an all out block across the tenant. Well, we can do this in Azure AD. Now, to set expectation two things. Number one: this is simply another useful tool in the kit bag regarding management of guests: you would still use sensitivity labels and EM and this would simply layer over the top of that. Secondly, this isn't something that will all out block all sharing and communication with other domains: other things need to be added which will be referred to below. All good?