Deploy Passwordless Devices for New Users

There’s a lot of great discussion going on these days about getting rid of passwords – because they’re unsafe, hard to remember, frequently reused, etc. In that spirit, I’ve been exploring just how to deploy passwordless devices. Think of a situation where you’re onboarding a new user to the company and you’re shipping a new device to them to set up and start working without ever stepping in to the office. Especially for remote workers, this may be the only scenario they ever follow.

In a somewhat modern scenario users would do the following: Autopilot their device with a temporary password, create a new longer password with numbers/special characters, set up Windows Hello with PIN & biometric unlock, and immediately forget that new password they just created (unless they wrote it down somewhere…). Windows Hello is convenient and easy to set up, which is great. But since it’s only local to the device, every time they need that long password they’ll either have to go find it somewhere or reset it. Maybe after they set up their laptop they go to set up their phone, and have already forgotten that new long password!

In a very traditional scenario, Windows Hello isn’t being used at all and the user will log in using that long password every day. Maybe they’ll even have to reset it every 90 days. This is flawed for several reasons – your users will start incrementing their passwords instead of actually making secure ones, and any form on MFA significantly decreases your risk of security incidents. Do you want your global admins logging into the Azure portal using pa$$word1 every day? Consider reading the Microsoft blog post on why Your Pa$$word doesn’t matter.

So how can we make that somewhat modern scenario, VERY modern? We need to enable passwordless sign-in using Microsoft Authenticator.

Microsoft Authenticator

The Microsoft Authenticator mobile app lets you use “phone sign-in”. This basically means that any Azure AD log in page you hit, you’ll receive a notification on your phone to complete the authentication – without ever typing in your password. And best of all – Windows 10 supports this during OOBE.

Let’s set this up from scratch for our new user. First, we’ll go to admin.microsoft.com > Add user:

Microsoft 365 admin center

In the name sections, put in the name of your new employee (for my test I’m using the name msftauth). For the password, uncheck Automatically create a password and uncheck Require this user to change their password when they first sign in.

Unchecked options

Now for the password itself, we’ll want to put in something strong (that we won’t be sharing with the end user). I’m using Bitwarden to generate a random password, and not saving it anywhere.

Strong randomized password

Click Next, and then complete the rest of the new user creation. I’m assigning an M365 license (which isn’t necessarily needed for passwordless, but you do need an Azure AD P1 license and Windows 10 license for Azure Active Directory Join, which is how this device will be deployed).

Now that your new user is created, we need to enable the passwordless options for them to actually sign in. Go to Azure Active Directory portal > Security > Authentication methods:

Azure Active Directory authentication methods

First, we’ll need to enable the Microsoft Authenticator sign-in method. Click on Microsoft Authenticator. In the new window select Yes for Enable. You can either target the method to all users or a selected user (in this case, I just selected our test account).

Adding user to Microsoft Authenticator policy

Optionally – if you click on the three dots and select Configure, there are three options you can select in the Authentication mode dropdown. If you leave this as Any, it gives your users the option of enabling both Passwordless sign-in and Push notifications for Multi-Factor Authentication (MFA). If you’re planning on having users hit MFA on their mobile device and you want them to use Microsoft Authenticator (instead of sms, call, software token, etc.) to complete the MFA requirement leave this as Any. For our user, we could set it just to Passwordless, because if they hit a Conditional Access policy that requires MFA, Windows Hello will be used to complete it.

Authentication mode

Click Save to finish enabling the Microsoft Authenticator policy.

We have one problem remaining – when our user goes to set up Phone sign-in, how do they sign-in the first time? It can’t just automatically redirect them to set up the Authenticator app, or anyone would be allowed to set up that user account as long as they know the correct email. This is where Temporary Access Pass comes into play.

In the same Authentication methods pane, click Temporary Access Pass (preview). Click Yes under the Enable slider, and click Save (as long as you are okay with the default options).

Enable temporary access pass

Now that the policy is enabled, we’ll have to create the actually temporary access pass when the user is ready to type in the credential. To do this, go to Azure Active Directory > Users > select user > Authentication methods.

User authentication methods

If you see a banner at the top that says “Try the new user authentication methods experience“, click that. On this pane, click +Add authentication method. In the dropdown, we can now select Temporary Access Pass (Preview), and we’ll have a password ready for them!

Create Temporary Access Pass

Normally I’d blur our the password for a screenshot, but seeing as this one stops working in 1 hour, let’s include it:

Temporary access password created

Here are our new user’s very modern workflow:

1. Call the IT Helpdesk for their temporary access pass.
2. Download Microsoft Authenticator on their mobile phone:

Microsoft Authenticator

3. Open the app and select Skip > Add account > Work or school account > Sign-in. (Sorry for the lack of pictures here, the Authenticator app prevents screenshots natively)
4. Log in using the temporary access pass.

Temporary Access Pass log in

5. The device will register with Azure AD.

Register Device

6. If the device doesn’t have a PIN, Authenticator will require one be set, and then Phone sign-in setup is completed!
7. They’ll turn on their new laptop. After entering their email, phone sign-in will automatically kick in:

First time Sign-in
Sign-in prompt
Notification on mobile device

8. Complete set up with Windows Hello

Windows Hello set up

And they’re done! No longer will they need to think about their password. Practically like being on vacation every day 🏖️

As a sidenote, I was also exploring one other way to deploy devices without a password – using a FIDO2 key during OOBE. I’ll be covering this in my next blog post, but it doesn’t really make sense for new users, because in order to set up the FIDO2 key they need to either use a different device or (counterintuitively) set up the device without a FIDO2 key.

You may also like...

6 Responses

  1. Hasse says:

    This flow does not work. Phone sign in in OOBE is fine but an autopilot device will reboot and present you with the normal windows login screen where youre back to using only password OR Security key to log in. You can enable Web sign in with intune, BUT Microsoft has stated over here https://techcommunity.microsoft.com/t5/azure-active-directory-identity/passwordless-authentication-is-now-generally-available/bc-p/2954523#M3812 that phone sign in at the windows login screen is history and will only work with a TAP, Temporary Access Pass. right now it does work but MS has stated that this will dissapear son again. then the whole passwordless flow will fail.

    • Janusz says:

      I’m not entirely sure I agree. Autopilot does not cause a device to reboot by default – it may happen because of updating rings or certain security settings, but it’s not a guarantee. If you don’t hit the reboot and you’re able to set up Windows Hello for Business, then this is a non-issue.

  2. Florian says:

    Great post!
    I did something similar for users without a phone. In this case we provide the user a security key.
    If interested check it out: https://scloud.work/de/passwordless-security-key-microsoft-365/

  3. wil says:

    Hi,

    I couldn’t get past OOBE with temporary password – thanks to this, I’ve added another user to authenticator – but, OOBE is still asking for a password.

    Is there any steps missing needed to enable authenticator/push during OOBE?

    Thanks

    • Janusz says:

      Is Authenticator set up with Phone Sign In enabled? You can click on the account in authenticator to double check. Without that it would be just used for MFA.

  1. July 14, 2021

    […] frequent references to a previous blog post I wrote specifically on deploying passwordless devices: Deploy Passwordless Devices for New Users – Device Advice. I split out the FIDO2 key section because for new users the experience can be fairly convoluted, […]

Leave a Reply

Your email address will not be published. Required fields are marked *