Was stumpted on this one and had to get advice from Microsoft Support.
A single user couldn’t log in via Multi-Factor Authentication. SMS code would say it was sent, wouldn’t come through. Phone call also wouldn’t come through. Trying to set up another MFA method aka.ms/mfasetup would receive one of these errors:
You are blocked from performing this operation. Please contact your administrator for help.
We’re sorry, we ran into a problem. Please select “Next to try again.
There were zero search results for that first error word for word, which is never a good sign.
There’s several areas you can check for blocked users such as:
And of course, that’s where the user was listed. They’d had some suspicious activity (a MFA phone call they didn’t initiate) so chose the option to block future sign in attempts, as you’d hope. This also triggered an email alert to admins, and that link is where the user’s block is listed until released.
How to roll out Windows Hello for Business as optional
To roll out Windows Hello for Business optionally:
In Group Policy, enable the ‘Use Windows Hello for Business’ policy
Tick the option ‘Do not start Windows Hello provisioning after sign-in’
Users will then need to click the Windows Security icon to register
Applies To : Windows 10
When I first looked at Windows Hello for Business at launch, I was impressed by it but also concerned. Turning the option on would prompt all users or devices that had the policy on, strongly encouraging them to go through the Windows Hello for Business setup with their fingerprint/face recognition and PIN.
To roll out Windows Hello for Business, follow Microsoft’s documentation which is quite detailed due to the complexities of scenarios and requirements; such as Single-Sign On, MFA of some sort and Public Key Infrastructure.
It was a bit intrusive to have this almost forced registration process as a user might not be in a position to go through the setup and be trying to do something urgent first thing in the morning, but even more of a concern was the style of the userbase I support – anyone expects to be able to log onto any computer anywhere. Windows Hello for Business doesn’t follow the user around for good reason (you’re tying the things you have to a single device), so each new device will go through the prompts.
I also had concerns around desktop users who didn’t have any other method of authentication beyond the PIN, and the perception than a PIN is less secure than a password (again the PIN is tied to a single device, while the password can be used to log onto any device).
Thankfully, a new option turned in Group Policy under the ‘Use Windows Hello for Business’ policy, located under both the Computers and Users areas Policies > Administrative Templates > Windows Components > Windows Hello for Business. The tickbox ‘Do not start Windows Hello provisioning after sign-in’. (To be fair, this has now been there for a while and I just wasn’t aware):
This will instead provide a little warning in Windows Security under Account Protection, saying Windows Hello isn’t set up. It doesn’t pop up and alert this, but instead shows a yellow exclamation mark against the shield icon in the taskbar. A user can then click through this at their leisure and set up Windows Hello for Business.
To me, this is a great way of allowing all staff the chance to set it up when they’re ready to do so, and in a staggered fashion without really having to manage it. Each business is different of course, and some will prefer or require the heavy handed approach of Windows Hello for Business on all devices – but I’m glad this more relaxed option exists.
Something I stumbled across today – it appears that Microsoft has decided to abandon Baseline Protection Policies, and replace them with a single ‘on/off’ switch called ‘Security Defaults’
Baseline Protection policies (also called Baseline Policies, it seems both terms have been used) were in preview, and were a pre-canned set of policies based on Microsoft recommendations on standard security settings that should be in place – such as forcing any administrator account to use MFA at each sign in, and blocking legacy authentication.
Here’s what the Conditional Access page currently shows. There might be something wrong with the detection though, as I clearly have a Baseline Policy enabled:
It’s not difficult to recreate the Baseline policies, so I’d suggest migrating off of them now while they’re still functional – you don’t want to be left in a state where you didn’t realise MFA for admins was now not being forced.
The replacement Security Defaults option can be found by going to Azure Active Directory > Manage – Properties > Manage Security Defaults (it’s not in the Conditional Access area):
Before flipping this switch to ‘On’, you’ll need to have a really good read of the documentation. There’s a lot this option does, and may break many environments who aren’t ready for this – such as making sure you have no Legacy Authentication requirements, and that all users will register for MFA within 14 days or be blocked from sign-in until they register.
Although I can see this option being turned on by an uninformed administrator and causing some chaos, I like the idea of this. It means a new tenant can now have a single option to start with to implement several critical aspects to protect the tenant against attacks – right now there’s a lot you need to go through to lock it down, and especially for a small business who doesn’t have the time or resources to do this as well as a larger one, a single on/off switch solves a lot of security problems.
Security Defaults is also available to all customers on all tiers – Azure AD Free tier, which means those who have basic needs can now be protected in several ways they weren’t able to do via Conditional Access before.
Security Defaults isn’t listed as being in Preview as far as I can tell, so it may be an option that’s just rolled out and a ready to go. I am guessing there’ll be a bit of kickback around this being a single option that has no other configurable options in it, so we’ll have to wait and see if the product changes, or Microsoft’s vision of a security toggle stays as their goal.
I’ve already written a post on why Legacy Authentication (Basic) is bad, and Modern Authentication is good. At the time of writing, Authentication Policies were the way to go to block Legacy Authentication methods. Of course, things change and there’s now a better* option to look at – Conditional Access.
I’ve also covered Conditional Access before, and it’s really hard to fault the solution. There are now Baseline policies deployed by default (still in preview though) to Azure AD tenants with recommended best practices:
One of these is for blocking legacy authentication – but I’m not going to recommend you turn this on (at least for starters, it’s good at the end when you know you have full modern authentication support), as it’s a tenant wide setting that has no exceptions if you need to allow legacy authentication for an account (unlike Require MFA for admins, which does allow exceptions).
Instead, you can create your own policy that does the same. This means you can gradually roll it out, and put exceptions in place until you either work around them, or live with them. If you have a requirement for an account that requires legacy auth, then you need to consider how else you’ll protect that account – can you use other Conditional Access policies to restrict it to a certain region/locations, certain apps, platforms etc – lock it down as much as you can, and make sure the account has a long unique password.
The single important setting to block legacy auth via a Conditional Access Policy is blocking access to ‘Other clients’ via Client apps:
If an account has their access or signin blocked due to an Authentication Policy, it’s not logged. You can look at the user in Azure AD and check the sign-ins, but you won’t see anything. However, if it blocked via Conditional Access, you’ll have a nice log entry showing you it was blocked:
Side note: Although in this example I was logging in from Australia, I was trying to connect to Exchange Online via PowerShell. That seems to often be detected as being in the US, so be careful with region blocking.
The other reason is that Authentication Policies can take up to 4 (!) hours to apply, although it’s often more like an hour. That is a long time to wait, and you just have to keep waiting and trying until it works – except if you did it wrong, you won’t know and you’ll keep waiting. Or, if you need to unblock access while rolling out, it’s a long time to roll back.
Authentication Policies do have their place though, they give more granular control over what you want to block or not – say you know you want to block POP3 access company wide, but not IMAP – that’s possible in there, but not via Conditional Access.
Unless you have a good reason to use Authentication Policies, just use Conditional Access (and assuming you have Azure AD Premium P1 or P2 licensing to actually let you use Conditional Access, and if you are using Azure AD you should be on that licensing anyway). It’ll make your life easier!
I struggle to fit these issues into a short but descriptive headline sometimes :)
This issue is a little strange. If you didn’t know any better (like me), you’d expect the location of a user’s mailbox to have no impact whatsoever on the function of ‘Recent’ document history inside of Microsoft Excel and Word, but it actually does.
I found this out the hard way of course, when a couple of staff mentioned their recent lists had disappeared and it co-coincided with their Exchange on-prem to Exchange online migration.
The short of it is that the Office applications detect what sort of login you’re using – if it’s Active Directory (AD) or Azure Active Directory (AAD). When that state changes, it uses a different registry path for a few things, including those recent documents.
Without knowing for sure but based on my testing, it must be doing some check to see if the associated account’s mailbox is in Exchange Online or not – and if not, it considers it an AD account. It doesn’t matter if you already have the users in Azure AD, Single Sign on and all that other good stuff set up – the single change of changing the mailbox location to online triggered the change for me.
For an AD account, the history paths are saved in the registry here:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Word\User MRU\AD_1234567890 (the number on the end is some sort of unique GUID).
For an Exch account, it’s in this slightly different path:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Word\User MRU\ADAL_1234567890 (again, unique GUID at the end).
In case you were wondering, MRU stands for ‘Most Recently Used’. AD is to do with on-prem Active Directory, and ADAL is (according to that reddit post) Azure Active Directory Authentication Library.
Also note the example above is for Word, there’s corresponding paths for other Office applications such as Excel.
There’s two subkeys below this key, one for File MRU and the other Place MRU.
The good news on hitting this scenario is that the values can just be exported, the path changed and re-imported. To do this, via regedit find the registry key that has the values you want (probably the AD one) and right click > export.
Find the file you exported and use notepad to do a find and replace on all the entires for AD_1234567890 and replace to the new value (which you can find from just looking in the registry).
Now, re-import the registry file and you’ll have all the recent document paths restored.
This should only be a one time problem for migrations, and only for people who had a bunch of document paths saved in there and can’t find where they are easily.