No, you say? Well, “chop, chop” then, let’s get it done! ✌🙂🤞
A ‘Temporary Access Pass’ (or TAP) is a one-off, time-limited passcode that is generated for a specific user. It allows the user to sign in to configure their second factor security information in Azure AD e.g., Phone number, App notification, OTP code, Security questions etc.
Your Service Desk can assign TAPs for following situations:
• onboarding a remote user.
• when a phone is lost or stolen.
• some other problem is preventing a user from performing MFA during sign-in.
After a TAP has been enabled, the user will see a different sign in experience when they access https://aka.ms/mysecurityinfo:
Because a TAP has a configurable lifetime (after which it expires), it is considered a strong authentication method. It can be used to sign in to https://aka.ms/mysecurityinfo to configure authentication methods without having to perform an additional form of MFA. And the TAP is displayed once only to the person creating it. After clicking OK it is gone forever!
You can create a TAP from within a user’s properties blade in Azure AD, under ‘Authentication Methods’.
Awesome! The user can use the TAP to set up their MFA methods. Now there is no need to exclude users from your MFA policies or perform some other form of jiggery pokery to circumvent the “rather annoying” demand for information we’ve become used to 🤣.
…and that = enhancing productivity and your security posture!
🤟🙂🤟 Now let’s migrate to the new methods! 🤟🙂🤟
First up, navigate to Authentication Methods within the Password Reset blade in the Azure AD portal and note down the currently enabled methods. Don’t worry about Security Questions for now (they are not yet available in the new experience, but the settings are honoured if enabled).
Now navigate to the legacy (or free) Per-user MFA portal, click Service Settings, and note down the currently enabled authentication methods.
Great, now navigate to the new Authentication Methods blade (under Security => Authentication Methods in the portal). Under Policies, enable all the methods you noted down. Unless you have specific requirements, these can all be targeted at All Users – ultimately, it’s who you target your Conditional Access Policies at that will be required to take any action, for two reasons. 1. We haven’t started to migrate to these settings yet, and 2. The new methods by default are optional for enrolment rather than enforced (see Registration Campaign under the new Auth Method settings to prompt for enrolment).
A few notes re configuration:
1. The number matching on Authenticator push is now enforced as of March 2023.
2. Enable the map and location in the Authenticator settings for enhanced security.
3. Enable SMS sign-in for the Phone method. If a user wants to, or you have a specific area of the business that could benefit from it, users can enter their phone number instead of their username (when signing in using a browser). Azure AD sends a code to the phone which the user enters as the password to access Microsoft 365.
4. I recommend considering the FIDO Security Key and certificate options and how they might benefit your business.
And, of course while you are at it… enable Temporary Access Pass! Make sure to change the default settings if they do not suit you.
Great – the configuration is ready! Now from new Authentication Methods blade, select Manage Migration.
Select Migration in Progress and click Save. At this stage, the new methods are enabled but the old methods are as well. This is the time to do some testing to make sure nothing screwy goes down. You can move back to Pre-migration if required. Here I would suggest enrolling new users from scratch, performing a password reset, adding and removing methods etc. to verify you are seeing the expected experience.
Once you are happy things are working okay, go to both legacy portals as we did in step 1 & 2, but this time “un-tick” all the authentication methods and save the configurations. This is required to complete the migration. NOTE: As mentioned above, if you have Security Questions enabled for Password Reset, leave that ticked and it will remain as an available method.
Superbulous! Now you can change the migration setting to Migration Complete!!
Anyone who visits the legacy blades will not be able to change the configuration, and a banner is displayed advising of the change.
Not so tricky was it! But an important task to complete early rather than scrambling at the last minute when Microsoft deprecate the old policies on 30th September 2024.
Catch you Nek Tyme! Simon 🍻👍😊🤘🍻
