Require passwordless sign-in

The time machine brings us back to December 17, 2020, where Microsoft wrote an article titled "A breakthrough year for passwordless technology."

In November 2019 at Microsoft Ignite, we shared that more than 100 million people were already using Microsoft’s passwordless sign-in each month. In May of 2020, just in time for World Password Day, that number had already grown to more than 150 million people, and the use of biometrics to access work accounts is now almost double what it was then. We’ve drawn strength from our customers’ determination this year and are set to make passwordless access a reality for all our customers in 2021.

Thinking back on where I am today on my personal path to include even more passwordless or password safe environments, it has not been easy! We can avoid requiring passwords for sign-ins with the most latest technologies at our disposal.

Disable password acceptance

To eliminate passwords completely, we must remove all surfaces and only accept passwordless sign-in to our cloud apps. This blog post will take the necessary steps to allow only passwordless sign-in to our applications. We'll put this to the test by accessing the Microsoft 365 portal. You will require:

• At least one Azure P1 license.
• A Phone with Authenticator app

Technology in use:

• Custom Authentication Strength
• Conditional Access policy (assigned to our test user)
• Temporary Access Pass (TAP)

Creating the user

When we go to portal.azure.com to create a fresh user, the first thing we see is, predictably, "password." For some reason, it is necessary to give a password when creating a new user. Ignore the field and let it auto-generate a password.

• Remember to assign licenses, in my case I am creating the user in a developer tenant so its the M365 E5 Developer license.

Custom Authentication Strength

Create a custom authentication strength that only accepts passwordless authentication. To create a custom authentication strength, follow the steps below. There is nothing dangerous about creating an new authentication strength. At step 5, you will see the methods chosen:

• FIDO2 Security Key
• Microsot Authenticator (Phone Sign-in)
• Temporary Access Pass (One time use and Multi-use)

Conditional Access policy

We now need to use our custom authentication strength in our conditional access policy that we created. My policy is assigned to my test user, and I select my custom authentication strength under "Grant" for all cloud apps. This will require my user to sign in without a password.

Temporary Access Pass (TAP)

When we sign in for the first time, our user does not know their password, so in order to make the first connection, we will need a temporary access pass, which is the only way for our user to login. Even if we are shown a password field, user will have no idea what to enter.

By clicking "Add," we can see the temporary access pass (just like an automatically generated password that only works for a limited time). One-time usage will only allow the user to use it once, which may pose issues during the onboarding phase.

Try it out

Let's try going to portal.office.com and signing in with our user name and temporary access pass.

The next screen will be "More Information Required," where the authenticator app will come into play.

• Remember to enable phone sign-in in the authenticator app. (You will need the TAP)

Sign-in logs

Lastly, let's see if our conditional access policy gives us a successful sign-in and that we complete our challenge.

Will password work?

Let's try to generate a password for my passwordless user and see if we can sign in; we need to make sure our policy is working properly. I have now reset the password for my test user and will attempt to sign in; however, I am prompted to generate a new password because I used one from a reset. When I try to sign in after changing my password, I get the following message:

• Feedback need to be worked on.

Strange behaviour

I removed my temporary access pass because we used it and our phone is registered for passwordless sign-in. For some reason, after attempting to login in with my (valid) password, things begin to behave strangely. I never get a successful password sign-in, but I can't switch to app-based sign-in unless I establish a TAP. After successfully signing in using my TAP, I may now use app-based sign-in, even after deleting my TAP.

An upcoming blog post will be about password surfaces!