This website uses cookies essential to its operation, for analytics, and for personalized content. By continuing to browse this site, you acknowledge the use of cookies.
For details on cookie usage on our site, read our Privacy Policy
For details on cookie usage on our site, read our Privacy Policy
About mtsujihara
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- LIVEcommunity
- About mtsujihara
04-29-2020
2Posts
0Likes
0Solutions
Apr 29, 2020Last Visited
User
Activity
User
Profile
Latest posts by mtsujihara
| Subject | Views | Posted |
|---|---|---|
| 3505 | 06-22-2017 02:26 PM | |
| 21860 | 06-16-2017 02:15 PM |
User Badges
Community Statistics
| Member Since | 11-11-2016 07:05 AM |
| Date Last Visited | 04-29-2020 08:40 PM |
| Posts | 2 |
06-22-2017
02:26 PM
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
... View more
06-16-2017
02:15 PM
A bit of background: We are an all-Google G Suite company. We do not have internal LDAP servers. Everyone auths to Google. We are using PA 3060s as our firewalls and VPN systems. We are getting ready to turn on SAML authentication for GlobalProtect. We are using Google as our IdP. I've gotten it working, but I want to make policy decisions based on the user group that we are returning in the SAML assertion. In Google, I have a user attribute with a "role" specified for each user, and then we are passing this back to the firewalls via a attribute mapping in our SAML App definition in Google. Within the SAML authentication profile in the firewalls, I have set the User Group attribute to "role", and when I connect to the portal through Burp Suite, I see a SAML "role" attribute being returned from Google and asserted to the firewalls. However, I have not found a way to use this "role" attribute in client IP pool assignments or in making policy decisions. I have tried making a local group that matches the "role" value, but that does not work. Has anyone done this, or have any insight on this? Regards, Mark
... View more
- Tags:
- globalprotect
- saml
Contact Me
| Online Status |
Offline
|
| Date Last Visited |
04-29-2020
08:40 PM
|
LEGAL NOTICES
Copyright 2007 - 2023 - Palo Alto Networks