cancel
Showing results for 
Search instead for 
Did you mean: 

F5 took long time to authenticate user using Active directory.

Harshal_Patil_3
Nimbostratus
Nimbostratus

Just integrated AD in F5 Load Balancers for users authentication when accessing F5 LB. All user can able to authenticate successfully on LB but all LB took a long time to authenticate the user.

 

All F5 are configured in VCMP in a physical appliance. We have also checked that the issue at LDAP server and Firewall between them, but could not found any issue there as other devices (even VM F5 LTM) able to login successfully within a short time. Kindly let me know your inputs on why F5 taking time to authenticate users.

 

10 REPLIES 10

Do you mean management login or APM AD authentication?

 

Harshal_Patil_3
Nimbostratus
Nimbostratus

Management login

 

On the CLI, when you perform a nslookup , does it return your LDAP servers and are all those LDAP servers reachable??

 

Cheers,

 

Kees

 

Harshal_Patil_3
Nimbostratus
Nimbostratus

Yes, As I mentioned already that user authenticates performed successfully but it took a long time to present GUI to the user. So would like to know where is the issue? it is in the GUI process or LDAP process.

 

Successfull but slow logon most of the times is a reachability issue. That's why I asked the question about the nslookup of the domain and the reachability of those servers.

 

What does the audit log tell you? (time between request and response of the ldap server).

 

It should tell:

 

May 9 13:59:30 bigip02 info httpd[31915]: 01070417:6: AUDIT - user root - RAW: pam_ldap initiating connection to TLS/SSL ldap server server.example.com on port 636. May 9 13:59:30 bigip02 info httpd[31915]: 01070417:6: AUDIT - user root - RAW: pam_ldap validating credentials for user 'user1' against TLS/SSL ldap server server.example.com on port 636. May 9 13:59:30 bigip02 info httpd[31915]: 01070417:6: AUDIT - user root - RAW: pam_ldap terminating connection to TLS/SSL ldap server server.example.com on port 636. May 9 13:59:30 bigip02 notice httpd[31915]: 01070417:5: AUDIT - user user1 - RAW: httpd(mod_auth_pam): user=user1(user1) partition=[All] level=Administrator tty=/usr/bin/tmsh host=10.10.10.10 attempts=1 start="Thu May 9 13:59:30 2019".

Kees

 

Daniel_Wolf_262
Nimbostratus
Nimbostratus

Hi Harshal,

 

try to narrow down the distinguished name of the search base (think it was called 'Remote Directory Tree') as much as possible. Otherwise the F5 will search the whole Active Directory domain for the CN of the user trying to authenticate. And this can take a long time or eventually just time out.

 

speachey
Altocumulus
Altocumulus

When we integrated AD LDAP authentication, we also saw delays logging in (several seconds). Despite specifying specific local "Host" LDAP servers, packet captures revealed traffic going to unexpected AD LDAP servers in our other datacenters. We found that globally disabling the use of LDAP referrals corrected the issue. See K17311: https://support.f5.com/csp/article/K17311

Glad I stumbled upon this post. I've been suffering with slow login response since integrating with a loadbalanced AD service, but adding REFERRALS no to the ldap.conf file has sorted it right out!

 

Thank you!

Ditto. Our logins were taking forever too. This fixed it right away.

alanjohnson7467
Altocumulus
Altocumulus

Thought I would add my findings for slow AD auth. I've been having issues with some of my lab LTMs and very slow remote auth via ldap and AD groups. After around 30 seconds auth will succeed, but this sometimes results in a timeout if you're connecting to the CLI. In my particular case the root cause was misconfigured DNS servers under device configuration. Fixing this resolved the slow auth.