Managing Guest Access
A few weeks ago I decided to change the way I was working with a partner organisation. I wanted in particular to stop sharing files by email and dropbox and make use of sharepoint as I do with other partner organisations. I created a sharepoint site for us both to use on my Office 365 tenancy and added them as a guest to Azure AD and granted them access to the sharepoint site with the necessary privileges.
Computer Says “No”
I then shared with them the URI of the sharepoint site and asked them to try to access it. They dutifully went to the site and progressed through the authentication process but their sign-in wasn’t allowed:
Your sign-in was blocked
We’ve detected something unusual about this sign-in. For example, you might be signing in from a new location, device or app. Before you can continue, we need to verify your identity. Please contact your admin.
My initial reaction was – I wonder why they are being blocked… I thought that I had thought of everything.
One of the things I’m grateful for is that Azure AD keeps clear and easy to access sign-in logs that describe in detail why someone has been blocked – so the first thing I did was go to the sign-in logs. If you aren’t sure where these are or how to interrogate them do get in touch.
Anyway – when I got to the specific log record in question I was a little bewildered:
How can the authentication requirement be “Single-factor authentication” but the failure reason be “Cannot configure multi-factor authentication methods due to suspicious activity”? Don’t these two contradict each other? What suspicious activity? What was making MFA a requirement for guest accounts? Why wasn’t this blocking other guest accounts I had?
Incidentally – Error 53004 simply means the user needs to complete multi-factor authentication registration process before accessing the content.
I continued to look through the additional tabs to see if there was further pertinent information – the only useful tab was the “Conditional Access” tab that revealed that “Security defaults” was the policy that was being failed because of “MfaRegistration” which didn’t really tell me much more that the previous details.
Clicking the “Security defaults” link did however bring up a little more detail:
This shows that the policy blocked the guest’s access based on the “Access controls” and in particular the “Grant Controls” which were “not satisfied”. Conditional access in Azure AD is constructed by using assignments – who and what the policy applies to – and access controls – what measures they need to satisfy in order to gain access.
So access is blocked because I have security defaults enabled and two of the pre-configured settings for security defaults relate to MFA in this instance:
- · Requiring all users to register for Azure AD Multi-Factor Authentication.
- · Requiring users to perform multi-factor authentication when necessary.
I have security defaults enabled on my Azure AD because Microsoft requires partners to have it enabled. When security defaults are enabled you cannot have any active conditional access rules. I think personally that security defaults as they are currently implemented by Microsoft is a poor solution to the problem of partners not adequately protecting their Azure AD and M365 environments. But that’s a topic for another blog post.
MFA across Azure AD domains
So why can’t the user just register for MFA? There are two scenarios to work through here:
User account isn’t associated with a different Azure AD domain: You create for them a guest account based on their email address in Azure AD and provided you have adequate licenses covering the MFA requirement in your environment they could progress through the MFA registration process. This isn’t the problem I was encountering.
User account _is_ associated with a different Azure AD domain: You create for them a guest account based on their email address in Azure AD. When they attempt to login Azure AD identifies that it knows their domain is another Azure AD tenancy and uses pass-through-authentication (PTA) to gain approval for their access. But it cannot verify whether or not they have MFA enabled on that other domain. Consequently access will always be denied.
How to not require guests to register for MFA
The ideal way to resolve this problem would be to replace security defaults with conditional access rules and in the rule that requires MFA registration to add an exclusion that excludes all members of a guest user group. But for a Microsoft partner this isn’t possible as you cannot use conditional access rules as Microsoft mandate the use of Security Defaults.
However – if you are using Azure AD External Identities, Azure AD Premium P1, or Azure AD Premium P2, I think you can solve this problem in a different manner. A manner that allows security defaults to remain enabled.
In the Azure AD portal if you navigate to Security, and then Identity Protection, you will find a there are three policies:
The obvious one to choose is MFA registration policy – but for me this was assigned to “All users” but not set to enforce the policy. Security Defaults is what is ensuring enforcement here I believe not the MFA registration policy.
User risk policy allows you to include / exclude users who should be covered by the policy, set a risk level above which you want the control to apply to the included users, and specify a control. Put simply user risk looks at what activity a user engages in once they have gained access.
Sign-in risk policy allows you to include / exclude users who should be covered by the policy, set a risk level above which you want the control to apply to the included users, and specify a control. Put simply sign-in risk looks at the probability that the sign-in may not have been performed by the user – for example if it comes from a different country that usual.
I had a Sign-In risk policy configured that had a control of “Require multi-factor authentication” – so I modified the assignment in this policy to exclude a group I imaginatively named “Guest Users Excluded From Risk Policies”.
I then added the guest account to this group and asked the user to try again – this time they were granted access without an MFA requirement.
I should note here that removing a guest user from a requirement to use MFA may create a security hole that might need to be recorded in a security log somewhere. Or at the minimum some consideration needs to be given to what that user account can access in order to minimize the risk. You might even have a policy of only adding users to this group if they can prove they have implemented MFA on their Azure AD environment.
Isn’t that a bit of a kludge?
Yes. To me it does seem to be a very inelegant solution. To begin with I thought it was the Identity Protection policies I had configured that were causing the problem but they aren’t factoring at all in blocking the user but for some reason they are being considered when the security defaults MFA registration requirement is evaluated.
I’d be interested in hearing if anyone has found a different, more elegant way to solve this problem, or indeed any Microsoft partners who have managed to satisfy Microsoft using conditional access rules instead of enabling security defaults.
After all – the idea of sharing content with suppliers or customers on sharepoint is hardly unusual… but having security defaults enabled creates a massive obstacle if you happen to have sold that customer an Microsoft 365 environment.
Can we help?
If you are looking for some help with configuring Azure AD, external identities, identity protection or any of the elements I’ve discussed in this blog post please do get in touch.