Forum Discussion

Harshal_Patil_3's avatar
Harshal_Patil_3
Icon for Nimbostratus rankNimbostratus
May 08, 2019

F5 took long time to authenticate user using Active directory.

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

  • 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

    • Anthony's avatar
      Anthony
      Icon for Nimbostratus rankNimbostratus

      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!

    • Leeroy's avatar
      Leeroy
      Icon for Nimbostratus rankNimbostratus

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

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

     

    Cheers,

     

    Kees

     

  • 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

  • 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.

     

  • 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.