Microsoft Self-Service Password Reset (SSPR) / GP VPN with User Authentication

[Brandon_Wertz]

Just wanted to share in case others run into this.  My company has recently started to use Microsoft's SSPR process which is embedded into the Windows 10/11 OS.

Specifics on how it works here:  Self-service password reset for Windows devices - Microsoft Entra ID | Microsoft Learn

This specific section is going to be an issue for GP VPN environments with always on VPN with user authentication enforcement for the VPN tunnel: 

"When users reset their password from the sign-in screen of a Windows 11 or 10 device, a low-privilege temporary account called defaultuser1 is created. This account is used to keep the password reset process secure.

The account itself has a randomly generated password, which is validated against an organizations password policy, doesn't show up for device sign-in, and is automatically removed after the user resets their password. Multiple defaultuser profiles may exist but can be safely ignored."

With this action the GP client sees this user account logging into the OS.  Since this user is a local machine user and isn't a known user to GP's auth profile the user tunnel on VPN will fail which means the VPN is disconnected with no way for the user to complete the SSPR process.

Right now we're exploring creating a secondary authentication profile (Creating this account as local to the firewall/PAN) for GP which will include this user somehow in the hopes that the SSPR process doesn't break the VPN connectivity.

When we get this figured out I'll post the technical solution.

[JayGolf]

Thanks @Brandon_Wertz , looking forward to your next post!

[KrisPamphilon]

Did you manage to get a working resolution, have just come across the same issue.

[Brandon_Wertz · Accepted solution]

---

@KrisPamphilon wrote:
Did you manage to get a working resolution, have just come across the same issue.

---

@KrisPamphilon sorry I missed your question.  Yes we did get this solved.  Although doing so in other customer configs/deployments might not be a viable option.  We ended up needing to allow the traffic to bypass the VPN / tunnel all together.

It's been a while so I'm not super sure on the specifics, and suggest conferring with TAC, but the SSPR MSFT domain (passwordreset.microsoftonline.com -- there might be others) needs to be allowed to bypass the VPN.  We accomplished this from the "enforcer" app/config described here:  https://docs.paloaltonetworks.com/globalprotect/5-1/globalprotect-app-new-features/new-features-rele... in step 2:

Of note, doing this presupposes having enforcer turned on, which might be a change to yours or another customer environment itself.  So step 1 could be you need to turn enforcer on with a second step being allowing IPs/domains to bypass VPN (which is described in step 2.)  This is what we did and it got SSPR working for us.