DOTW: GlobalProtect VPN Client Mac OSX Secure Input

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.
L7 Applicator

 

This week's Discussion of the Week (DOTW) focuses on a LIVEcommunity discussion dealing with using MacOS X Secure Input and GlobalProtect.
This is a topic that has had a lot of views, but does not really have a solid answer as to what is the solution.
Well, good news! That is why I have decided to write something about this, in order to clear this up.

 

DOTW: GlobalProtect VPN Client Mac OS X Secure InputDOTW: GlobalProtect VPN Client Mac OS X Secure Input

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The discussion topic is titled, "GlobalProtect VPN Client Mac OSX Secure Input."

It can be accessed here:
https://live.paloaltonetworks.com/t5/general-topics/globalprotect-vpn-client-mac-osx-secure-input/m-...

 

Here's the Issue
The main issue with this whole scenario is on MacOS X, a user is trying to use "Keyboard Maestro" to run macros for software development and it needs secure input to be disabled to work properly.
But secure input is a service that is running by default, and it looks like GlobalProtect is requiring it to be on when GP starts.

Many cases have been opened about this issue and there has not been a solid answer until now.

 

Here's a Workaround
Please see the Solution below for more details on the versions, but prior to GP 5.1.3, the following steps were followed as a workaround:

1. Sign out of GlobalProtect (Settings > General > Sign out)
2. Run the following commands:
```
rm ~/Library/Preferences/com.paloaltonetworks.GlobalProtect.client.plist
rm ~/Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist
defaults delete com.paloaltonetworks.GlobalProtect.client
```
3. Reboot
4. Sign back into GlobalProtect and manually enter the portal


Here's the Solution
After GlobalProtect 5.1.3, this issue has been resolved and should not conflict any more, but here is more detail about the reasoning behind all of this.

Our Engineering team has researched this issue and discovered that it is not an GP issue but a MacOS issue.

 

GP uses system APIs for all password login fields. It does not have control over enabling or disabling Secure Input and it is handled by the system.

The same is mentioned on this Technical Note by Apple on Secure Input feature under "Note" section, as quoted below:
https://developer.apple.com/library/archive/technotes/tn2150/_index.html

"Note: Most Carbon and Cocoa applications use system supported API's for private information data entry. For example, Carbon applications implement dialogs or windows with text fields supported by either the kControlEditTextPasswordProc or the kControlEditUnicodeTextPasswordProc control for the entry of password data. A Cocoa application will implement an NSSecureTextField for such purpose. This Technical Note does not apply to applications using these API's as they work properly to secure keyboard events only when necessary."

 

When SAML authentication is configured, the GP app is opening an embedded browser from the OS (again this is via a system API call). Once the embedded browser is open, the SAML authentication page is loaded, where the user can input his/her credentials.

GP does not have any influence or control over the contents that get downloaded into the embedded browser; this is the content from SAML IdP. When a user clicks on the password field inside the embedded browser, the Secure Input will be claimed and when the focus is removed from the password field, Secure Input should be released. This is again not under the control of the GP app. If Secure Input is not being released, this is an issue outside of the GP app.

 

Again, it would appear that this is no longer an issue after the client uses GP 5.1.3 or higher, but I just want to show you what we have discovered.

 

I hope that this helps everyone with this question!

 

Thanks for taking time to read my blog.
If you enjoyed this, please hit the Like (thumbs up) button, and don't forget to subscribe to the LIVEcommunity Blog area.

 

As always, we welcome all comments and feedback in the comments section below.

 

Stay Secure,
Joe Delio
End of line

3 Comments
L0 Member

Upgraded to MacOS Monterey 12.1 recently and running GP Client v5.1.8-15 and this was a problem with BetterTouchTool v3.6+ Completed the workaround and rebooted and it appears GP now releases Secure Input as expected and BTT shortcuts/macros work again. 

 

UPDATE: Take that back. Issue persists. 

L7 Applicator

If you haven't already, it would be recommended to open a case with support to resolve the issue.

L0 Member

Upgraded to macOS Ventura 13.0 and while running GlobalProtect 6.1.0-58 this is still occurring.

  • 5494 Views
  • 3 comments
  • 3 Likes
Register or Sign-in
Labels
Top Liked Authors