Two factor issues after upgrading to GlobalProtect 3.x

[as-mg]

Hi,

After doing an upgrade from GlobalProtect 2.3.4 to 3.0.1 we're having issues with users not being able to do two factor authentication in combination with SSO.

The software we're running is SecurEnvoy, which has been working fine up to the client update.

Firewalls are running PAN-OS 7.0.5-h2.

SecurEnvoy responds as it should, and sends the code to the user's phone, but from there the client times out and reverts to the automatic gateway.

Have anyone else encountered issues with the latest GlobalProtect? Are the new GlobalProtect client dependant on PAN-OS 7.1?

Agent log:
(T6200) 04/15/16 10:23:18:305 Info (2468): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_RECEIVING_RESPONSE, this=0000000002340100)
(T6200) 04/15/16 10:23:18:305 Info (2468): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_REQUEST_ERROR, this=0000000002340100)
(T6200) 04/15/16 10:23:18:305 Debug(2549): WINHTTP_CALLBACK_STATUS_REQUEST_ERROR, error=12152, result=1, dwCertificateError=0
(T6200) 04/15/16 10:23:18:414 Info (1573): get WINHTTP_CALLBACK_STATUS_REQUEST_ERROR while waitting for header, error=12152, ERROR_WINHTTP_INVALID_SERVER_RESPONSE!
(T6200) 04/15/16 10:23:18:414 Error(3595): winhttpObj, error! ipaddress REMOVED
bRetryWithoutCert is 0, bClientCertNeeded=0
(T6200) 04/15/16 10:23:18:414 Info (2468): PanWinhttpCallback(dwInternetStatus=WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING, this=0000000002340100)
(T6200) 04/15/16 10:23:18:414 Debug(2567): handle 0057c060 closed
(T6200) 04/15/16 10:23:18:414 Debug(2571): REUSE, request closed
(T6200) 04/15/16 10:23:18:414 Info ( 561): wait for closing callback success!
(T1396) 04/15/16 10:23:18:414 Debug( 516): Command = <request><type>https_request</type><result>NULL</result></request>
(T1396) 04/15/16 10:23:18:414 Debug( 62): OnReceive error=0
(T1396) 04/15/16 10:23:18:414 Debug( 62): OnReceive error=0
(T1396) 04/15/16 10:23:18:414 Debug( 950): status message received from the service:

Service log:
(T12176) 04/15/16 10:22:54:792 Debug( 319): PanGpHipMp.exe exit for checking misssing patches.
(T12176) 04/15/16 10:22:54:792 Debug( 387): CheckHipMissingPatchInOtherProcess(): exits.
(T12176) 04/15/16 10:22:54:792 Debug( 467): Hip missing patch checking duration is 34
(T10600) 04/15/16 10:22:58:134 Debug(2401): receive pan_msg_ping, 3
(T10600) 04/15/16 10:23:08:191 Debug(2401): receive pan_msg_ping, 3
(T10600) 04/15/16 10:23:18:258 Debug(2401): receive pan_msg_ping, 3
(T10600) 04/15/16 10:23:18:414 Debug(2559): HTTP_RPC, len=0, result is
(NULL)...
(T10600) 04/15/16 10:23:18:414 Error(2785): pszXmlConfig is NULL. 4278
(T10600) 04/15/16 10:23:18:414 Debug(2857): pszXmlConfig is NULL, m_bInvalidUserCredential is false.
(T10600) 04/15/16 10:23:18:414 Error(1650): Failed to retrieve info for gateway REMOVED
(T10600) 04/15/16 10:23:18:414 Debug(1803): close WinHttp close handle.
(T10600) 04/15/16 10:23:18:414 Debug(1657): tunnel to REMOVED is not created.
(T10600) 04/15/16 10:23:18:414 Debug(3721): Set state to Disconnected

[as-mg]

The temporary workaround is to have the users enter their username and password in the GlobalProtect agent, which seems to make everything work as it used to.

[as-mg · Accepted solution]

I do belive I have found how to resolve this issue in our case.

The autentication profile for RADIUS used a username modifier, which used to be %USERINPUT%@%USERDOMAIN%, and which was working just fine in GlobalProtect 2.3.4.

For GlobalProtect 3.0.1 %USERDOMAIN%\%USERINPUT% and using the NetBIOS name of our domain in the user domain field  seems to be the correct modifier in our case.