Forum Discussion

smp_86112's avatar
smp_86112
Icon for Cirrostratus rankCirrostratus
Aug 18, 2009

Slow AD Auth LTM MGMT GUI

I have the management interfaces of a GTM and an LTM configured to use Active Directory authentication. Based on the admin GUI settings, both units are configured exactly the same. When I authenticate with the GTM, my AD credentials are accepted and I am immediately presented with the admin interface. However on the LTMs, there is a 1-minute delay before I am presented with the admin interface.

 

 

I took a tcpdump on the LTM during my auth attempt. I can see the LTM bind with an account I specify in the auth settings, and immediately get a successful response. Next I see the searchRequest for my account, and immediately I get a response. At this point, I see an (almost exactly) 60-second delay before a bindRequest is made with my ID. Once the request is made, the reponse is successful and I log in.

 

 

I do not see this 60-second delay between the LDAP search result and bindRequest with my ID on my GTM. The GTM and the LTMs are in the same network, both using the same DNS server, both configured to look at the same AD domain controller.

 

 

I took my trace without any capture filters, and have pared it down slowly to ensure I don't strip out anything important. I don't see any strange DNS responses or anything like that. Since the delay is exactly 60 seconds, this seems to be a config problem - like it's looking at some internal auth scheme before AD and timing out. But the config directive(s) must not be in an obvious place, since from what I can see the units are configured the same.

 

 

If you have any other places to look, I would appreciate your thoughts. Thanks.

 

 

management
monitoring

9 Replies

Sort By
  • The_Bhattman's avatar
    The_Bhattman
    Icon for Nimbostratus rankNimbostratus
    Aug 18, 2009
    Anytime I see a lag like this I would check to see if my LTM has DNS set up properly. I have never seen this on my LTM but i have heard from a few collegues that they had a problem similar to yours and it was due to the fact that DNS was not set up on the LTM.

     

     

    I hope this helps.

     

     

    Thanks,

     

    CB

     

     

     

  • smp_86112's avatar
    smp_86112
    Icon for Cirrostratus rankCirrostratus
    Aug 18, 2009
    Thanks. I have had this problem before, and it was in fact DNS-settings related. However this time my DNS is valid, and matches my other F5 (GTM) unit. So this time I think it's something else, or else it's some DNS setting which is not set through the GUI itself.
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Aug 19, 2009
    Which version are you running for the unit(s) that are having the problem?

     

     

    Aaron
  • smp_86112's avatar
    smp_86112
    Icon for Cirrostratus rankCirrostratus
    Aug 19, 2009
    Oh yeah, duh. LTMs are running 9.3.1HF6, and the GTM is running 9.3.1HF7. Also I just confirmed that logging into both units with SSH and AD credentials works fine. The only place I have trouble is with the LTMs' admin interface.
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Aug 19, 2009
    If there is an issue with the GUI, but the CLI works fine for the same user account and same remote auth configuration, I'd suggest it might be a bug. It would be helpful to have someone review the tcpdumps from a working and slow unit as well as the full remote auth configuration. You might try opening a case with F5 Support on this.

     

     

    Aaron
  • smp_86112's avatar
    smp_86112
    Icon for Cirrostratus rankCirrostratus
    Aug 19, 2009
    It is true there is an issue with the GUI and the CLI works fine for the same user account and the same remote auth configuration. However the GUI issue only applies to a single pair of LTMs, and not the other 5 LTM pairs and three GTMs which all share the same configuration. All the GTMs run 9.3.1HF7, and the LTMs run 9.3.1HF6. Only this single pair of LTMs has the problem, so I suspect it is more likely to be a config mistake somewhere. I will likely open a case - I was just hoping someone had experienced this before and attributed it to something besides DNS, because in this case, the DNS config looks the same to me.
  • smp_86112's avatar
    smp_86112
    Icon for Cirrostratus rankCirrostratus
    Aug 19, 2009
    I feel pretty dumb having to write this...but we suffered from this problem for months until today when I ... restarted httpd.

     

     

    Thanks for your input.
  • smp_86112's avatar
    smp_86112
    Icon for Cirrostratus rankCirrostratus
    Sep 03, 2009
    We suddenly had difficulties again logging in to our F5 equipment yesterday. This time it happened on all our F5 equipment located in our DMZs. It turns out, for some unknown reason, that the /etc/resolv.conf file on all our F5 equipment had the following directive:

     

     

    search localhost.com

     

     

    We did not add this intentionally, so I don't know how/when this was added. But localhost.com is a valid internet domain and apparently whoever hosts this domain is having trouble with their DNS servers - nslookup on localhost.com varies between timeouts, a valid address, and an address in the 10.x.x.x/8 private address space. By performing network traces, I could see that the F5 equipment was appending localhost.com to its attempts to resolve our Active Directory domain name in DNS. But since the localhost.com DNS server was having trouble, our login attempts were timing out.

     

     

    By commenting out the search directive in /etc/resolv.conf and restarting httpd, our logins recovered. Our internal F5 units were not affected because they can not resolve Internet names.

     

    Wow, we were lucky to figure this one out. This is another good thing to check if you are having AD auth problems.
  • Yehuda_Pinchas's avatar
    Yehuda_Pinchas
    Icon for Nimbostratus rankNimbostratus
    Feb 14, 2019

    Try to disable the option: "Check Member Attribute In Group" (Navigate to System >> Users >> Authentication) This resolve my similar issue.