DOTW: GlobalProtect VPN Client Mac OSX Secure Input

[jdelio]

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 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