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.
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:
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.
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.
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:
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).
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.
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).
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.
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!
Normally I’d blur our the password for a screenshot, but seeing as this one stops working in 1 hour, let’s include it:
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:
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.
5. The device will register with Azure AD.
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:
8. Complete set up with Windows Hello
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.