Teams Real Simple with Pictures: Adding Number Matching and Context to Authenticator Notifications via Azure Active Directory

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.

Teams Real Simple with Pictures: You want to block your own users being guests in other tenants? Well, now, you can with Cross Tenant Access Settings

This series on Teams has been running for a while now - about two and half years. And during that time I've returned periodically to the subject of guests. Enabling/Disabling Guest Access in the TAC, purging from Azure AD, Self Service Removal, Sensitivity Labels, Entitlement Management. In the last few months I have covered Terms of Use, B2B Management Policy to block guest invitations and regulating guests with PIM and RBAC. But the perennial question - the elephant in the room as it were - has always been this "I have the tools now to control adding guests to my tenant but how can I - as an administrator - prevent my own users from joining other tenants as guests" How can I control that? Block that? Up until this point we would typically say one of two things. One - it's the responsibility of the destination to control guest invitations even though typically we know from our own field experience that many orgs are always very active when it comes to guest management. Number two. It's by design - and if we simply turn off Guest access lock stock then we shoot ourselves in the foot collaboratively. But reaching for that security and compliance hat as I have so often done of late, there is legitimate reasons that we may want to stop our own users being guests in other tenants. What if a competitor invites one of our users into their tenant to collaborate on something they aren't supposed to? What is our users were spending most of their time as a guest in tenants that have nothing to do with our business? What if I as an admin want to limit certain users who are prone to accidental data leakage, or what if we just wanted to limit overall sprawl? So it should please administrators that we now have Cross Tenant Access Settings (CTAS) in preview which can do what we need. CTAS is defined as giving granular control over how external Azure AD organizations collaborate with you (inbound access) and how your users collaborate with external Azure AD organizations (outbound access). We'll focus on outbound access in this one. To note right off the bat, this is designed to work with other Azure AD organizations - if for example you are working with other organisations who are non-AAD or have personal domains you'll need to use Azure B2B Management. You'll need Global Admin or Security Admin roles to configure - and AAD P1 licencing if you want to go granular with users or groups.

Teams Real Simple with Pictures: Governing Guest Access via Azure AD Roles and PIM

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.

Teams Real Simple with Pictures: Using B2B Management Policy in Azure AD to block Guest invitations to specific domains

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?

Teams Real Simple with Pictures: Terms of Use with Conditional Access

Happy Christmas! I hope you have enjoyed the last few days - and whether it has been with family, friends, going shopping, eating out, going to church, taking exams or feet up binge watching movies and taking a real break from everything I really hope you have managed to spend it how you have wanted to after a full on 2021. You deserve it. Me? I'm spending most my with my family, but during the holidays I'm also taking some a bit of time to clear the decks for 2022 and refocus on several things which I've missed doing this year. One of those things is the Microsoft Tech Community. Tech was where I first started out doing community work back in late 2018. I did it compulsively right up until the beginning of 2021 and it's been a big part of my life the past few years. It's a place where I met a lot of my community friends: people like Adam Deltinger, Chris Webb, Juan Carlos Gonzalez Martin, Vasil Michev and Linus Cansby. Its a place where I got the opportunity to help people directly. It's also the place which led to many more opportunities including Teams Nation. Yet with everything else going on this year - work, events, exams, speaking on the circuit, you name it - it's been tough to allocate the time in order to really get back into it like I used to. So I needed to change things up in order to get back to the start, and having re-engaged the last few weeks I feel much happier and sharper. Now one of the questions I was asked was regarding Terms of Use. This is fortunate considering I am teaching Microsoft SCI Fundamentals next month and it's a component of that. Terms of Use is an Azure AD functionality but applies to many services including Microsoft Teams. Do you require employees or guests to accept your terms of use policy before getting access? Do you require employees or guests to accept your terms of use policy on a recurring schedule per your compliance policies? Do you require employees or guests to accept your terms of use policy as part of a conditional access policy? Once you use it, it seems strange that you wouldn't want this in place to ensure anyone who is accessing your environment is accepting your terms - especially as it's an Azure AD P1 functionality and available to small businesses as well as large