I wanted to play with the Attack Simulator in the Office 365 Security & Compliance Admin Portal – but with the enabling MFA warning, none of the ‘Launch Attack’ buttons were available to use. I’ve already set up MFA via Conditional Access though, so why am I seeing this?
At a guess, I wondered if it was actually detecting if MFA was used to log in. It wasn’t because the request was coming from a trusted IP address, which I’d configured in my test tenant to make it a bit less painful.
My hunch was right, I signed in elsewhere, went through MFA and look, the buttons now work:
Bit of a misleading warning – your MFA rules might be completely fine, so try signing in with MFA first before going to the Simulate Attacks page.
If you’ve gone down the path of Azure Active Directory (Azure AD), then I dare say you’re not at the end. It’s a long but rewarding path, with new features constantly being added to enhance a critical service in the Microsoft offerings.
It’s also likely you didn’t start with Mutli-Factor Authentication (MFA) in place and ready to go. Maybe you did and well done! For the rest of us though, we slowly move into these systems while turning more options on.
Just enabling MFA with Conditional Access is great, but getting all users to actually register for MFA https://aka.ms/mfasetup can be a challenge. If you’re fortunate enough to have Azure AD Premium P2 licensing, you can use a MFA registration policy to do a nicely managed rollout and force people on. Those without P2 however, have an option that’s a bit hidden, not as well known and slightly scary:
Require users to register when signing in?
Under the question mark: Designates whether unregistered users are prompted to register their own authentication information when they sign in for the first time. If set to “No,” administrators must manually specify the necessary password reset authentication information in the properties for each user in this directory, or instruct users to go to the registration portal URL directly.
The description for this option is a bit misleading, it actually means that they’ll be prompted the NEXT time they log in, rather than the first time.
This option is found under Azure Active Directory > Password reset > Registration, and is off by default.
Turning this option on is a company wide setting and from my testing, worked pretty much immediately. As soon as someone who hadn’t signed up for MFA logged onto office.com, they were prompted to go through the MFA registration process. There’s no way to point this at certain users or test it, you just have that one little switch to turn it on for every single account in your tenant.
For someone who had signed up for MFA, they were asked to confirm the details entered previously.
I’d recommend letting your staff know before this option is toggled, but at least it can easily be turned off again if you run into any issues.
Update 2nd May:
After publishing this, Sean Flahie on Twitter mentioned his experience if Azure Self-Service Password Reset (SSPR) wasn’t enabled for users, and enabling the combined experience – both of which I have in place already. If you’re having any issues then please look into both of these.
I found that if SSPR is not enabled for ALL or if users aren't added to the scoped SSPR group, they do not get prompted for registration. This new combined experience is now in v2 of Preview called "enhanced". https://t.co/ntcVBdFxpb
There’s currently an issue with configuring Conditional Access via Azure Active Directory. There’s an open ticket with Microsoft Support, with no ETA at the time of writing.
The issue: When trying to configure a new policy for Conditional Access against an Azure Active Directory application, the ‘New’ page gets stuck loading. I’ve tested this on multiple browsers, tenants, internet connections, computers, and had Microsoft support confirm.
The path to doing this is from the Azure portal – Azure Active Directory > Enterprise Applications > choose your application > Conditional Access > New policy:
The Workaround: Thankfully it’s not a showstopper, as there’s another way to get to Conditional Access and it works fine. Instead of going via a specific app first, you can just go via Azure Active Directory > Conditional Access > New policy. Also Azure Active Directory > Enterprise Applications > Conditional Access > New policy works, it’s just an extra click to the same screen.
Points to take note of – if something’s broken, try accessing the same function from a different route of click-through links and it might work another way. Also, log these issues with Microsoft Support as overall the support is pretty good and often the issue won’t be anything to do with you. Test different scenarios wherever possible too, and also asking the question on Twitter can get some extra attention!
