LDAP authentication failover

Reply
Highlighted
L4 Transporter

LDAP authentication failover

Hi Community,

I have 2 Domain controllers serving user information. I have configured these 2 under same LDAP server profile. I am using this profile in authentication profile for GP.
I configured 4s each for search and bind timeout under LDAP server profile.
I need the user should be authenticated with second server when first one is down(it is the default behavior)
It works fine when the LDAP connection is via plain text(didn't check SSL/TLS box under LDAP server profile). But when SSL/TLS is enabled, it takes toomuch time for authentication timeout to first server, by that time GP authentication timeout, and users are not able to authenticate. I don't prefer increasing timeout for GP authentication.

Please advice if there is a way to enable TLS/SSL along with smaller timeout , so that users will he authenticated with second server.

Accepted Solutions
Highlighted
L4 Transporter

Hi @MickBall ,

 

Thanks for the information.

I have tested different scenarios in my LAB and found the following,

  • with plaintext ldap, failover is happening with configured timeout.
  • With LDAPS (over port 636), failover is working fine - here PA will by default try with SSL
  • With SSL/TLS over any other port, firewall is trying with TLS by default and wait for timeout then try with SSL - which may be the cause the higher timeout.

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.

View solution in original post


All Replies
Highlighted
L7 Applicator

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.

 

Highlighted
L4 Transporter

Hi @MickBall 

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

-------------

  • 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. When your firewall is running Applications and Threats content versions earlier than 777-4484, the default is 30. Starting with content version 777-4484, the default is 5

-------------

i even doesnt check if it is configurable, i even dont prefer to change it.

 

Highlighted
L7 Applicator

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.

 

 

Highlighted
L7 Applicator

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.

Highlighted
L4 Transporter

Hi @MickBall ,

 

Thanks for the information.

I have tested different scenarios in my LAB and found the following,

  • with plaintext ldap, failover is happening with configured timeout.
  • With LDAPS (over port 636), failover is working fine - here PA will by default try with SSL
  • With SSL/TLS over any other port, firewall is trying with TLS by default and wait for timeout then try with SSL - which may be the cause the higher timeout.

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.

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

The Live Community thanks you for your participation!