Two factor issues after upgrading to GlobalProtect 3.x

cancel
Showing results for 
Search instead for 
Did you mean: 

Two factor issues after upgrading to GlobalProtect 3.x

L3 Networker

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

1 ACCEPTED SOLUTION

Accepted Solutions

L3 Networker

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.

View solution in original post

2 REPLIES 2

L3 Networker

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.

L3 Networker

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.

View solution in original post

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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 LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!