GlobalProtect SSO and 3rd Party Credential Providers, What did you do?

[BrianRa]

Hello,

We recently installed Palo Alto firewalls (3000 series) and are currently working on our VPN configurations.

We have multiple 3rd party credential providers including drive encryption and Windows single sign on.  One of the selling points was the ability to have SSO VPN and full tunneling of the traffic on our laptops while off site.

We have been unable to make this work with any of the other credential providers installed on the laptops.  The available documentation suggests wrapping the PAN credentials using a registry edit but this breaks the Windows SSO and does not fix the PAN GP SSO.  To be fair a stock domain laptop running Windows 7 or 8 does work with PAN GP SSO.  Unfortunately that is not an option for us.

PAN OS versions: 7.0.11, 7.0.12, 7.0.13, 7.1.6, 7.1.7

GP Client versions: 3.1.13, 3.1.14, 3.1.15

Windows OS versions: 7, 8, 10

What have people been doing with multiple third party credential providers and using PAN GP SSOs?

Thanks

Brian

EDIT

Sorry I didn't provide the link support keeps giving me:

https://live.paloaltonetworks.com/t5/Featured-Articles/Tips-amp-Tricks-Single-Sign-on-SSO-for-Global...

We have tried this as mentioned above but it doesn't allow it to work.

/EDIT

[Remo]

Hi @BrianRa

Probably you already found a solution, but a possibility would be the way I am describing here: https://live.paloaltonetworks.com/t5/General-Topics/Global-Protect-quot-Single-Sign-on-quot-with-Win...
As written in the post I am not 100 percent sure about possible security problems, but you probably don' t have problems with 3rd party credential providers anymore.

Regards
Remo

[BrianRa]

Remo,

Thank you for the reply.  I will look into your write up.  We still have a ticket open with support on this subject as it is still not functioning.

Brian

[BrianRa]

Remo,

Thank you again for the reply.  This did not quite fit our environment.  We are using drive encryption that then logs into windows with SSO based on the credentials provided during the drive decryption.

Brian

[Remo]

Hi @BrianRa

Could you share some more details why it does not fit in your environment?

Your drive encryption software uses its own credential provider right? So you have set this credential provider as default credential provider at least in windows 10? In windows 8 it is (unfortunately) somewhere between diffcult and impossible to set a default credential provider. And windows 7 is completely different, there your only chance to set a "default" is to hide all others.

Or could you share how you did your tests and what the problems were? Another possibility is may be to user GlobalProtect with SAML, which then obvisously requires an SAML IdP or ADFS Server.

Regards,

Remo

[BrianRa]

Remo,

We have not played with SAML that I am aware of, I will ask.

We are running primarily Windows 7 in our environment.  We are in the process of getting Windows 10 to work with our drive encryption and WSUS/KBox distribution servers, we skipped over windows 8.  We have tried to force every credential provider option in Windows 7 including default but have only been successful in breaking the Windows login SSO.

Brian

[Remo]

This sounds to me still like your drive encryption software needs its own credential provider for SSO. In windows 7 you also have the ability to wrap the GP credential provider around another credential provider.

[mtsujihara]

Have you looked to see if you may need to go to a newer client revision?

At the bottom of the Tips and tricks document you linked, there is a Conclusions section wih the following info:

For Windows 8 and Windows 10

Because changes Microsoft had made to Windows login and the credential provider framework, users have to set GlobalProtect as the default sing-in option to ensure GlobalProtect SSO works as expected. Once set, Windows stores the sign-in option. Users don’t have to set this option each time they log in. With GlobalProtect 4.0 and later, you can use SetGPCPDefault to 1 force GlobalProtect to be the default credential provider.

They tend to change things pretty significantly between client versions.

In our case, we had to wait until GP 4.02 to use SAML to auth to Google G Suite.

Regards,

Mark

[BrianRa]

Remo,

Unfortunately when we tried that it did not fix the problem.  We tried wraping GP around all the credential providers the machines had in registry.

Mark,

We have not moved to PAN 8.0.x yet.  We are running on current 7.1.x but the newest GP version available for that is 3.1.6, we are running this.
Both Windows 10 and PAN 8.0.x will be implemented in the fututer but we are not ready for that yet.

Thanks
Brian