- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
04-28-2019 12:38 PM
05-01-2019 07:28 AM
Hi @Mick_Ball ,
Thanks for the information.
I have tested different scenarios in my LAB and found the following,
In a nutshell, plantect and ssl connection is having the timeout configured, but if PA start with TLS, it causes higher timeout and GP auth fails.
Not sure why TLS connectivity does wait for the default timeout.
04-29-2019 05:18 AM - edited 04-29-2019 05:22 AM
i'm not sure if you understand the failover correctly.
the authentication process will not try all servers in you ldap\server profile.
if device 1 does not respond it will not try that server again for the time you have set in "retry interval"
on your second attempt (if within the "retry interval") it will try server 2.
it will then continue to auth all users on server 2 until the "retry interval" expires.
you may be better off using an authentication sequence.
configure 2 server profiles, one for each server, configure 2 authentication profiles with one server profile in each.
configure an authentication sequence with both server profiles included and select this in your portal auth page.
also... where can you increase GP authentication timeout, i have not seen this.
04-29-2019 07:53 AM
Hi @Mick_Ball
Thanks for the response,
i was following the below kb, which says about the failover. i was having the similar problem and timer values were default in mine also. i configured retry inteval high just to avoid retying to the same server frequently.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClXnCA
In my case i am able to failover successfully when i disable ssl in LDAP server profile ( using gp application or by test authentication command in cli), i am able to see that PA tries to authenticate the user with second server after configured bind interval. But the moment i enable 'ssl/tls required' option in LDAP server profile, the timeout is increased, and it tooks around 30s to failover to next ldap server and authentication succeed in cli. but definitly it will cause auth timeout for GP users.
i am checking for a solution with enabling ssl/tls connectivity to ldap along with lesser failover time as normal plaintext connection. not even sure if it is a protocol limitation.
regarding gp timeout, i have seen below PA document
-------------
-------------
i even doesnt check if it is configurable, i even dont prefer to change it.
04-29-2019 09:07 AM
Portal Connection Timeout (sec)—The number of seconds (between 1 and 600) before a connection request to the portal times out due to no response from the portal.
i think this is not related to authentication but the ssl handshake to the portal itself, when this time expires the GP client attempts to find a cached version of the portal/gateway config.
I have tested failover using ssl/tls and it works if you use authentication sequence, have you tried this.
04-30-2019 01:25 AM
Hmmm... i have now reverted back to the auth profile that was timing out GlobalProtect.
it now works... i have no idea why, i must have jolted something...
ldap server profile hs 2 servers with ssl/tls-636
first server is not listening on 636, second server is.
timers are 4,4,30.
tries first server 2 times and then auths to second, all within 5-6 seconds, i have no idea what caused this to work as expected.
05-01-2019 07:28 AM
Hi @Mick_Ball ,
Thanks for the information.
I have tested different scenarios in my LAB and found the following,
In a nutshell, plantect and ssl connection is having the timeout configured, but if PA start with TLS, it causes higher timeout and GP auth fails.
Not sure why TLS connectivity does wait for the default timeout.
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!