Temporary Access Pass - Hello For Business setup still needs password

Question

Temporary Access Pass - Hello For Business setup still needs password

GonWild 426

Hi,
Got TAP setup, and it works on enrolling a windows device(autopilot). But before setting up hello for business, I am presented with the windows login screen asking for the users password (which we are hoping to avoid to go passwordless). I cannot find any way around entering the password, to proceed.

Have checked the obvious stuff... TAP code or policy has multi use, user is in TAP policy...

The doc says WhfB is supposed to work with TAP
https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-temporary-access-pass

Any other ideas or how to troubleshoot?

3 answers

Your answer

Answer 1

GonWild 426

There's no such thing really. Autopilot is more of an umbrella term for a set of functionalities that enables provisioning of a Windows endpoint. As soon as Windows setup completes, MDM policy (from Intune in this case) will begin flowing to the device and begin being applied -- in normal Autopilot scenarios, this is indicated to the end-user by the ESP. This includes policies/profiles and app assignments which are shown and tracked on the ESP page. If any of these initiate a reboot, the user will be prompted for their credentials again because there's no way to securely cache a user's credentials. If you are not watching the process end-to-end, you can review the system's event logs and MDM diagnostic logs to determine if a reboot is happening during ESP due to an MDM/Intune policy or application assignment.

aha.. from the log; microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin:

The following URI has triggered a reboot: (./Device/Vendor/MSFT/Policy/Config/ExploitGuard/ExploitProtectionSettings)

I see we had some endpoint security policies, so I testet excluding the device from our exploitguard policy settings, wiped the device-->new login with TAP.... voila!
Enrollment now finishes without the reboot, WhfB setup pops up, all is good! thanks @Jason Sandys for helping to pinpoint this!

however, does this mean that the TAP/passwordless scenario is incompatible with any settings or policy that causes reboot during enrollment/ESP? (before WhfB setup)

Jason Sandys 31,406 Reputation points Microsoft Employee Moderator

2022-08-12T15:48:58.077+00:00

Awesome, glad to hear.

however, does this mean that the TAP/passwordless scenario is incompatible with any settings or policy that causes reboot during enrollment/ESP?

Yes, but this isn't explicitly intentional or by design, just a result of a behavior (the CSP requiring a reboot) conflicting with a TAP during OOBE design assumption (that no reboots happen during the provisioning process). I unfortunately, don't have a workaround for this other than to perhaps apply the Exploit Guard setting after provisioning using a dynamic group (there's no easy way to do this really though to my knowledge). The best thing I can offer is to open a support case so that the behavior and end result here can be officially tracked. I'll see if I can pass on this thread to interested parties internally, but no guarantees there.
GonWild 426 Reputation points

2022-08-15T06:37:12.547+00:00

The best thing I can offer is to open a support case so that the behavior and end result here can be officially tracked. I'll see if I can pass on this thread to interested parties internally, but no guarantees there.

thanks! I will also take this to our MS partner, in case they can expedite it in some way.
Jaya Lakshmi Koduru 6 Reputation points Microsoft Employee

2022-09-07T19:14:33.47+00:00

Hello @GonWild , I just wanted to check in and see if you had any other questions or if you were able to resolve this issue?

If you have any other questions, please let me know.
Thank you for your time and patience throughout this issue.

----------

Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.

Answer 2

JimmySalian-2011 42,496

Hi,

I assuming the users have device registered in Azure AD and followed the registration process for MFA, however there are 2 points to consider as per the article one is for Azure AD joined devices and other is for Hybrid Azure AD.

Temporary Access Pass usage for setting up Windows Hello for Business varies based on the devices joined state, So what is the state of the device when you try to use for WHFB? If it is one of the above it will prompt for authentication.

On already Azure AD Joined devices, users must first authenticate with another method such as a password, smartcard or FIDO2 key, before using TAP to set up Windows Hello for Business.

On Hybrid Azure AD Joined devices, users must first authenticate with another method such as a password, smartcard or FIDO2 key, before using TAP to set up Windows Hello for Business.

It seems it is part of the design and workflow for WHFB setup.

GonWild 426 Reputation points

2022-08-09T19:01:10.7+00:00

Temporary Access Pass usage for setting up Windows Hello for Business varies based on the devices joined state, So what is the state of the device when you try to use for WHFB? If it is one of the above it will prompt for authentication.

Im testing on a not previously enrolled device. Autopilot and AAD join only. It's doing its job, but won't setup WhfB until after I type the users password.
JimmySalian-2011 42,496 Reputation points

2022-08-10T06:43:40.28+00:00

Do you get any error or can you please share your device event logs and Domain controller logs to capture the WHFB authentication process. Event ID 300 usually is logged if the process is success in the device event log.
GonWild 426 Reputation points

2022-08-10T08:29:28.49+00:00

I dont get any error, I just hit the login screen with username and password prompt. The device is AAD joined, no on prem domain controller involved here. I'm assuming there are no WhfB related logs on the device, as it wont be set up before i type the User Creds...which I don't want in this case.
JimmySalian-2011 42,496 Reputation points

2022-08-10T12:01:16.35+00:00

Hi GonWild,

As the device is AAD Joined and as per the Microsoft (check below) user will have to key in the password or authenticate before trying to use TAP.
I will suggest you check MFA of that specific user and if you are trying to test, remove the MFA for test purpose for that test user and try the TAP.

"On already Azure AD Joined devices, users must first authenticate with another method such as a password, smartcard or FIDO2 key, before using TAP to set up Windows Hello for Business."

Hope this helps.
GonWild 426 Reputation points

2022-08-10T12:33:26.97+00:00

Device is removed from AAD, and when the logon screen appears, I believe it is joined to AAD again through the autopilot process.

In that case, how does MS expect new users to authenitcate passwordless when setting up an autopilot device for the first time?

As the doc states:

During Azure AD Join setup, users can authenticate with a TAP (no password required) and setup Windows Hello for Business.

thanks for your comments, but I really think this doc is misleading - or we have done some other config errors with this.
JimmySalian-2011 42,496 Reputation points

2022-08-10T13:22:52.69+00:00

Can you confirm from another PC or Azure Powershell that the device is removed from the AAD by running this command.
Get-MsolDevice -RegisteredOwnerUpn "Username@Company portal .com" (Initial user configured with the UPN and the device ID) or check the lastlogontimestamp for the device
Get-MsolDevice -All -LogonTimeBefore 'August 10, 2022 12:00:00 AM'
Jason Sandys 31,406 Reputation points Microsoft Employee Moderator

2022-08-10T15:54:11.41+00:00

@JimmySalian-2011 , you're missing the point that this is all during Autopilot so there is no pre-existing state of the device or account/object in AAD.

@GonWild , are there any reboots that happen during your Autopilot provisioning process?
JimmySalian-2011 42,496 Reputation points

2022-08-10T20:28:09.51+00:00

@Jason Sandys please check the response from GonWild he mentioned that
"Device is removed from AAD, and when the logon screen appears, I believe it is joined to AAD again through the autopilot process."

Hence I requested that to check if there are pending removal of the object.
GonWild 426 Reputation points

2022-08-11T09:14:42.987+00:00

@JimmySalian-2011
I have 2 laptops at testing disposal, with the same behavior here. They are removed from Intune when doing a "wipe device" in Intune (discarding the enrollment state and user association), so I am able to test again on the same machines. Poweshell still find the object, and say they its AD-joined. This object is the autopilot object, which is needed for depolymentprofile assignment in the autopilot process. Just for testing this, I removed it from autopilot (no trace of the object in AAD, confirmed with PS) and did a new upload of the hash from windows setup. It made no difference.
GonWild 426 Reputation points

2022-08-11T09:15:35.91+00:00

@Jason Sandys
About reboots during autopilot:
I'm not completely sure where autopilot begins and when Intune sort of takes over. (I've not setup any pre-provisioning).
Username is entered at the "welcome to <company>" screen , and TAP shortly after.

PC reboots at the end of the step 'Device settings' on the enrollment status page. It won't continue on the "account setup" step until I type users creds (password). This is where I would expect TAP to be entered again, to setup WhfB ?
Jason Sandys 31,406 Reputation points Microsoft Employee Moderator

2022-08-11T17:56:22.7+00:00

I'm not completely sure where autopilot begins and when Intune sort of takes over.

There's no such thing really. Autopilot is more of an umbrella term for a set of functionalities that enables provisioning of a Windows endpoint. As soon as Windows setup completes, MDM policy (from Intune in this case) will begin flowing to the device and begin being applied -- in normal Autopilot scenarios, this is indicated to the end-user by the ESP. This includes policies/profiles and app assignments which are shown and tracked on the ESP page. If any of these initiate a reboot, the user will be prompted for their credentials again because there's no way to securely cache a user's credentials.

If you are not watching the process end-to-end, you can review the system's event logs and MDM diagnostic logs to determine if a reboot is happening during ESP due to an MDM/Intune policy or application assignment.
Jason Sandys 31,406 Reputation points Microsoft Employee Moderator

2022-08-11T17:59:54.963+00:00

@JimmySalian-2011 The whole point of Autopilot is that it provisions a new device (or reprovisions an existing one) meaning that it starts with a reset device in OOBE that has no domain join state whatsoever.

Answer 3

Mikkel Lund Knudsen 116

Hey @GonWild

Did you manage to find a solution here?

Just felt across this article - seems like Peter Klapwijk found a solution where he did use : EnableWebSignin here : https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-authentication#authentication-enablewebsignin

Looking forward to hear from you :)

GonWild 426 Reputation points

2022-11-14T21:43:24.243+00:00

sort of. See the comments. It doesnt support a reboot in the enrollment process. If you got some setting that triggers a reboot after TAP was supplied, creds are lost and it prompts for password to continue after booting. .. if it prompted for TAP again, I guess it would be ok...but its ask for pw.

In our case it was an Exploit guard setting causing the reboot, so removing that fixed it for us. However no fix in the sense that the behavior is still there.
Rahul Jindal [MVP] 10,911 Reputation points MVP

2022-11-14T22:26:34.08+00:00

Assign exploit guard policy to a user group and you are golden.
Mikkel Lund Knudsen 116 Reputation points

2022-11-15T18:14:49.613+00:00

Oh, I see - I don't think we got in in there - but yeah, reboots during ESP is ... tricky! :)
GonWild 426 Reputation points

2022-11-18T20:31:47.153+00:00

Hey, that actually worked... I found that the policy in question was assigned to a device group. Assigning it to a user group instead solved it! thanks!
Rahul Jindal [MVP] 10,911 Reputation points MVP

2022-11-18T22:25:38.14+00:00

Glad it worked. ESP is touchy and certainly doesn't like reboots.
Mikkel Lund Knudsen 116 Reputation points

2022-11-18T22:43:16.533+00:00

Can you elaborate - what exactly did you assign to a user group? :)
GonWild 426 Reputation points

2022-11-19T19:35:06.933+00:00

I assigned a user group (insted of device group) to the policy that was causing the reboot during ESP. Without the reboot, I will no longer be promted for traditional credentials before WhfB setup, which means we now can use TAP to go passwordless.
Subhajyoti Chakraborty 0 Reputation points

2023-05-06T07:27:36.8466667+00:00

We use pre-provisioned deployment and have the same problem in the user flow. Once the PC reboots in the ESP, the web sign-in credential provider option doesn’t show up. It only shows up after the user has reached the desktop and rebooted eventually. So it’s a hindrance for new joiners as they can’t use their temporary password and at the same can’t login using TAP+ Passwordless. Any ideas? Could this be due to one of the applications assigned to the users which may need a reboot.

EPP> Defender profiles are not assigned to devices.

Share via

Temporary Access Pass - Hello For Business setup still needs password

3 answers

Your answer