ldap through PA failing randomly

[bowings]

we're having a problem with logging into servers in our network that connect to an ldap server that is behind the Palo Alto firewall. The PA recognizes the sessions as ssl going over 636/tcp. Our rules allow these connections, and most of the time when we try to log in to a server that authenticates with the ldap server behind the firewall it works, but we have found that occasionally it doesn't work right away. that is, someone will try to log in to a server, and their ldap username is not found. usually a few minutes later ldap authentication will start working again. this behavior didn't happen when the ldap server was not behind the firewall, so it's presumed to be a firewall problem, though i haven't been able to find any indication of what it may be. i don't see any denies in the traffic or threat logs between the ldap server and machines that use it. our sysadmins believe that the sessions are being disconnected by the firewall, but the endpoints don't know about it.  most of the sessions between the ldap server and other servers that connect to it are about 30 seconds, and the default timeout of 1800 seconds for ssl has not been changed.

to be clear, this has nothing to do with the ldap authentication on the PA itself, or for ssl vpn (since we're not doing it).  it's an issue of servers in one zone talking to an ldap server in another zone.

i have captures set up for a few machines, hoping to find out what happens when they are unable to connect, but so far they've been working. has anyone run into a problem like this before?  any ideas on how to track it down?

thanks

- brandon

[ukhapre]

Hello Brandon,

Are you seeing any messages in syslog? Please check the same.

Please open a case with support so that we can look at pcaps.

Thanks

Palo Alto Networks Support Team

[bowings]

ukhapre - I haven't seen anything in the logs to indicate a problem, just normal session ends.  I'm capturing on a handful of IP addresses, but so far I haven't been able to associate any of them to this problem while they're being monitored.  I'm still kind of in the dark about what could be going on, and I'm not convinced the PA is the problem - since I'm not seeing anything unusual in the logs - but the behavior started when we moved the ldap server behind the PA.

We're going to be doing some more testing to see if the problem also occurs on another PA and ldap server, and so I should have some more information then.  I wanted to see if there are any known problems that could be affecting this service.  If you're not aware of anything, based on what I can tell you now, then I'll try to gather more information and get back to you.

thanks

- Brandon

[bowings]

I called in and Support implemented an application override that changed the timeout to 12 hours.  That seems to have cleared up the problem.  Thanks.

[friento]

Hi.. did you change the default session timeout to 12 hrs?

thanks

[bowings]

We didn't change the default session timeout, we just created a new application with a 12-hour timeout and used that to set up an application override.