Accept UPN when GlobalProtect is the default credential provider?

[Mister.iks]

PANOS 8.0.2
GlobalProtect 4.0.2
Client Windows 10 Enterprise x64

We currently use Microsoft DirectAccess for all our Windows clients
The Big plus of DirectAccess is that it works pre-logon and is completely seamless for the end-user, but it is Windows only, speed is not good and troubleshooting issues my be cumbersome.

Therefore we are looking into replacing DirectAccess with GlobalProtect.

A large part of the requirements is met with GP, but we also want to make it as seamless as DirectAccess currently is for our end-users is (read: Always on and no end-user action required at all)

As authentication method we are using the Pre-logon then On-Demand Connect Method and we want to use single sign-on (SSO)
Pre-logon then On-Demand works, but we are having some challenges with the SSO part.

Our users all logon on their Windows 10 laptop with their domain UPN (user@domain.com) which is the same as their primary mail address.

If we want SSO to work then the GlobalProtect client needs to be the default credential provider. Problem with this is that this logon method expects the user to logon with their pre-windows 2000 logon name (samaccountname) which uses the format DOMAIN\username.

This is a problem for us. Most users don't even know their pre-windows 2000 logon name and we don't think this legacy method is the way forward.

If we don't set the GlobalProtect client as the default credential provider then the user is able to login with his UPN, but when GP switches from Pre-logon to On-Demand then the GlobalProtect client pops up asking for credentials. This authentication does accept the user UPN. This authentication is then cached by the GP client so next logon is more seamless, but it will break again when the user changes his password.

Is it possible to let the GlobalProtect default credential provider accept the UPN instead of the pre-windows 2000 logon name ?

[Remo]

Hi @Mister.iks

I don't know if this is supported or what ever the official answer to this is. Maybe someone else here knows exactly or you always have the possibility to open a support case.

But there is also another way to solve such problems:

The key is: do not use PAN credential provider at all

Like I described here: https://live.paloaltonetworks.com/t5/General-Topics/Global-Protect-quot-Single-Sign-on-quot-with-Win...

Another way maybe is with Global Protect SAML login. But I cannot say something about this method. I still have this on my to do list ...

Regards,

Remo

[Mister.iks]

Hi Remo,

Thanks for your reply!

Last week when I was investigation this issue I also stubled accros your post and had hit the like button :).

I like the approch of only using the pre-logon method in combination with the user agent, but your question in the last sentence wasn't awnsered by anyone. 

Did you got some clarity around that?

[Remo]

You're right... there was a question 😛

I was thinking a lot about this possible problem. And so far I did not find a point that this configuration is less secure than using an authentication profile. You only have to make sure that the pre-logon user only has very limited access to the ressources needed at login time (AD, SCCM, Antivirus updates, ...).

If you have a specific group where you put all your vpn users into it: You can improve this, at least a little, when you only give this vpn usergroup full internal access and after this rule create a deny all rule. This way if someone has a company computer (or at least a certificate from your PKI) and valid credentials (of someone not belonging to this vpn usergroup) ALL traffic will be blocked. But in this, kind of worst case, situation you have the same problem when you use the traditional authentication profile method. In such situations there are internal processes needed that when a user got his computer stolen, he needs to call your support department as soon as possible to start the processes for revoking the computercertificate and for resetting the user password.

[mdumitriu]

FYI - this fix will be included in GP version 4.0.3

[Mister.iks]

Cool, thx for the update!

[Remo]

Thanks for the update. Are there any informations about when 4.0.3 will be available?