I changed the test user password and removed/swapped out the < and > characters and I was able to sign in right away without any issues using the 4.1 client.
This means PA has to resolve this before rolling the app out to the masses in order to prevent any such instance of this problem occuring with anyone using those characters in their passwords.
If you do roll this version out and some users are unable to connect, it may be related to special chars in their passwords.
Thanks again for everyone's input that lead me to this finding. I have a case open and I will update it and inform our SE of these findings.
I'm glad you narrowed it down to special characters in your case, I have a special character in my password but there also appears to be an issue with the password length. When typing in my password at the 20th or 21st character the input box doesn't allow any more input and the computer gives the angry chime that it's not accepting it. The last 10 or so characters of my password are not special or numeric. I think we have multiple issues going on.
Yeah sounds like it. Out of curiosity are you able to test the linux or OSX clients? the linux client is command line so there is no limit applied at that level it is worth a shot.
I would reccomend reaching out to your SE and let them know of the character limit on that field. I'm sure you arent the only one with a password of that length or longer just like I cannot be the only one with < or > in my password.
I have discovered an issue that only applies if you have Always-On enabled and enforcing a GlobalProtect connection for network access.
What happens is...
1. User logs into Windows.
2. GlobalProtect connects to Portal/Gateway.
3. GlobalProtect prompts for authentication.
4. If the user does not authenticate within 10-15 seconds of receiving the auth prompt, GlobalProtect will minimize(in the system tray) the auth prompt, and display the "Traffic Blocking Notification" message.
I have noticed that this only happens when you do a fresh logon into Windows. When switching between an "internal" and "external" network, the auth prompt is not effected. A fresh logon into Windows gives you a balloon type auth prompt next to the system tray. Switch between internal/external networks gives you a pop-up window for the auth prompt.
we are using pre-logon onlways on and our testers here have not seen that so far but we are using the windows SSO and cert for auth so the users dont get prompted for a GP logon. There are some timeout settings in the portal app config section that may be at play there?
I think what is happening here is certain characters in the password are breaking it (notice line 3 below) The password character that appears before the broken XML tag is a < and after that is a > so I bet if i change my password to remove the < and/or the > it will be the magic fix for me. BUT Since prior versions don't break with that character and PA does not specify we cannot use that character, I think maybe they should fix the app and change their code to properly escape special characters.
(T5104) 03/08/18 18:47:04:975 Info ( 438): msgtype = hello
(T5104) 03/08/18 18:47:04:976 Debug(1120): Send response to client for request hello
(T5104) 03/08/18 18:47:05:479 Error(1455): end tag </7BsoX> not found
(T5104) 03/08/18 18:47:05:479 Error(1488): end tag </saved-passwd> not found
(T5104) 03/08/18 18:47:05:479 Error(1488): end tag </request> not found
(T5104) 03/08/18 18:47:05:479 Info ( 410): Message is not valid XML. Message is <request><ty
(T5104) 03/08/18 18:47:05:479 Info ( 194): Error processing receive data from client
(T5104) 03/08/18 18:47:05:479 Info ( 200): close client socket
Okay, now that is just scary!
Why is the client sending the password to the server? In plaintext, to boot! Shouldn't the client be hashing the password and just sending the hash to the server? You know, how every other authentication system out there does things.
I was intrigued by the promise of a Linux client, but there's no way I'll be putting this anywhere near even a test system until that glaring flaw is fixed!
To be fair I do not think it is actually sending the password cleartext. On a successful login you can see the password is ************ in the logs however it is concerning that it is somehow getting into the logs before it is hashed and breaking the entire process. PA is aware of the issue and will hopefully have a fix soon.
Not really "Solved" but a work around for special characters. (Don't use < or > in your password). Also, don't have a password over 20 characters in length, or is it 22... ?
@CaviumKeith Well... of course that will work but try telling that to a handful of angry users that cannot get connected. If you have thousands of employees and enforce strong passwords you could end up with 10's or 100's of users impacted by this. I have not heard anything recently but I beleive they are working on a fix for this (I hope)
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!