Quick Win: Prompt your M365 guest users with terms of use (TOU)

We live and work in a time where collaboration across company borders is part of our day-to-day for most of us. This leads to a whole number of challenges regarding the management of “outside” identities in the tenant. Today I want to focus on a quick win that can help you get significantly more control with very little configuration. Let’s go!

What are terms of use?

Terms of use (TOU) describe an agreement that a user has to confirm and respect to use a service. In our case we want to use them to set up clear expectations of what kind of behavior is allowed for guests in our tenant and to communicate a set of rules (e.g. an NDA) if applicable.

Why should I care?

For the worst case scenario: A record of a guest user having agreed to the TOU will make your attorney’s job much easier in case they were to act against the agreement…

If you happen to be faced with significant resistance inside your company when trying to open up for working with guests (e.g., from an IT department that is afraid of losing control of their perimeter), this feature can help you significantly soften this argument. I’m not going to dive into Change Management too much at this point, but just this: The resistance you are facing is most likely coming from fear – help your colleagues feel safe and you’ll be surprised by how much you can do together!

What will be covered in this article?

We will create a Conditional Access policy to prompt all guest users with TOU and request confirmation from them. Scoping the policy to different business partners or adding TOUs in different languages is not covered to keep it at an entry level for now. This is intentionally not a deep dive but a quick glimpse at what is available.

What are the prerequisites?

  1. To start deploying this, you will need a TOU document in PDF format that you can show to guests. If you’re in a sufficiently large company and have your own legal department, it would be best to ask them – if not, you might need to ask around a bit.
  2. To use Conditional Access, your users need to be licensed with Business Premium or at least AAD P1.

How do I create the policy?

  1. Use this link or navigate to AAD Portal > Azure Active Directory > Security > Conditional Access > Terms of use.
  2. Select “+ New terms”.
AAD Portal showing the "Terms of use" section with the "New terms" button highlighted.
  1. Give your TOU a name (this will only be visible to administrators).
  2. Upload your TOU PDF file by selecting the folder button.
  3. Select a language from the dropdown.
  4. Give your document a display name (this will be visible to guests).
AAD Portal showing the "New terms of use" dialogue with fields "Name", "Document", "Language" and "Displayname" filled.
  1. Decide if users must expand the TOU to accept them. Do you want guests to be able to just click “accept” without reading the TOU?
  2. Decide if you require approval of the TOU once for every guest – regardless of the device they are coming from – or once for every device they use to access your data.
AAD Portal showing the "New terms of use" dialogue with the toggles for "Require users to expand the terms of use" and "Require users to consent on every device" shown.
  1. Next, choose the appropriate expiry settings – there’s three options:
  • Option 1: You can require your guests to confirm the TOU in a moving time-window always x days after the last confirmation.
    To do so, you would leave “Expire consents” off and enter an appropriate duration in the field below.
    (This is the option I’m using for this scenario.)
AAD Portal showing the "New terms of use" dialogue with the toggles for "Expire consents" set to "Off" and "Duration before re-acceptance required" set to 90.
Option 1: Expire consents every x days
  • Option 2: You can expire consent on a fixed schedule.
    To do so, you would set “Expire consents” to “On”, enter a start date and set “Frequency” to an appropriate value. “Duration before re-acceptance required” would be left empty in this scenario.
AAD Portal showing the "New terms of use" dialogue with the toggles for "Expire consents" set to "On", "Expire starting on" set to "03/31/2022" and "Frequency" set to "Quaterly". "Duration before re-acceptance required" is emtpty.
Option 2: Expire consents on a schedule
  • Option 3: You can actually combine the two previous options. This gets complicated quickly and I’ve yet to see a valid use-case for this, so I’ll not go into it here.
  1. In the “Conditional Access” section choose “Custom policy” – this will allow you to create the required policy right away.
AAD Portal showing the "New terms of use" dialogue with "Enforce with conditional access policy templates" set to "Custom policy".
  1. Select “Create” and off you go to the policy 🚀
    We will be setting up an absolutely minimalistic Conditional Access Policy here, since this is not the focus. Be aware that you can put a lot of thought and complexity into Conditional Access. To keep it simple for now, what we want to do: Require TOU from every guest, no matter what they sign into or where they are coming from.
  2. Set a name that tells your colleagues what the policy does.
Conditional Access Policy creation screen showing a new policy with the "Name" field filled.
  1. Select “Users or workload identities” under “Assignments”.
  2. Make sure to set the policy to apply to “Users and groups”.
  3. Under “Include” choose “Select users and groups”.
  4. Select “All guests and external users”.
Conditional Access Policy creation screen "Users and workload identities" section showing "What does this policy apply to?" set to "Users and groups", "Include" set to "Select users and groups" and a checkmark on "All guests and external users".
  1. Select “Cloud apps or actions” under “Assignments”.
  2. Make sure to set the policy to apply to “Cloud apps”
  3. Under “Include” choose “All cloud apps”.
Conditional Access Policy creation screen "Cloud apps or actions" section showing "Select what this policy applies to?" set to "Cloud apps" and "Include" set to "All cloud apps".
  1. Select “Grant” under “Access controls”.
  2. Make sure “Grant access” is selected in the panel.
  3. Check the box next to your newly created TOU.
  4. Confirm by clicking “Select”.
Conditional Access Policy creation screen "Grant" section showing "Grant Access" selected and a checkmark next to the newly created TOU "Guest User TOU".
  1. Decide if you want to leave the policy in Report-only mode for now or if you want to turn it on right away. I’d recommend leaving it in report-only and taking a look at the logs for the next few days to see who would have been prompted with the TOU if the policy were on – but if you like to live dangerously, I can’t stop you 😉
    (This whole “report-only and finding out who a policy applied to”-topic is out of scope for now, but let me know if you’re interested, I might write a short article on it in the future.)
  2. Click “Create”.
Conditional Access Policy creation screen showing "Enable policy" set to "Report-only".
  1. Confirm that your policy is there by navigating to the “Policies” and checking the list (twice).
"Policies" section in AAD portal showing the newly created policy in report-only mode.

What now?

  • Review the logs and decide if you need more finetuning before turning the policy on.
  • Consider adding different TOUs for different user groups – depending on what they do and access.
  • Consider adding additional languages to your TOU to cover your international guests.
  • Enjoy your worry-free collaboration.

What does it look like for the guests?

Good question! Let me show you:

  1. Let me access a team I’ve been invited to.
TOU Prompt showing the previously selected display name for the TOU. The Text of the TOU is collapsed and the buttons "Decline" and "Accept" are available.
  1. Oh no – I actually have to read the TOU! (just like we planned 😁)
Notification that the TOU need to be viewed before they can be accepted.
  1. Well, ok. Let me expand and read them, before I accept…
TOU Prompt showing the previously selected display name for the TOU. The Text of the TOU is expanded and the buttons "Decline" and "Accept" are available.
  1. I’m in!
  1. In 90 days, I will get the same prompt again and you can sleep tight knowing that you’ve successfully implemented TOU for all your guest users in just a few minutes of work.

How do I know who accepted and who declined?

  1. I’m not going to go into reporting right now, but if you navigate to your TOU, you can see the numbers of “Accepted” and “Declined” have updated.
AAD Portal showing the "Terms of use" section with an "Accepted" count of 1 on the previously created TOU.
  1. When you click on the number, it takes you to a list of all accepted/declined TOUs including users and timestamps.

Questions?

If anything is unclear or you are interested in one of the things I left out here, let me know. You might be just the motivation I need to write another article 😉

I’m going to be honest – comments on blogs are not really on my radar usually. I’d recommend trying Twitter: @considerITman

Leave a Reply

Your email address will not be published.