Forum Discussion

Brad_146558's avatar
Brad_146558
Icon for Nimbostratus rankNimbostratus
May 02, 2014

APM Connectivity Issue

Hi Everyone,

 

I'm troubleshooting an APM issue that, unfortunately I wasn't a part of. The short story is there was AD maintenance and all of the domain controllers that APM was configured to use. Sometime after APM stopped authenticating users correctly. A reboot seemed to resolve the issue but I'm wanting to find out for sure.

 

My two questions are:

 

Will APM ever stop attempting to reconnect to domain controllers if they were down for specific period?

 

Are there any logs that can show me the health or status of connectivity with back end authentication servers?

 

3 Replies

  • I guess it depends, but the AD AAA has a monitor built into it and should log any failures. I'd usually recommend something like an LDAP monitor if you're specifying a pool of AD servers. Otherwise you could remove the pool, apply just the domain name, and let the AD do it's own load balancing. I do sort of recall a bug in the 11.2/11.3 days where a failed monitor would blackhole an AD server for up to 10 minutes, but the previously mentioned workaround should prevent that altogether.

     

  • kunjan's avatar
    kunjan
    Icon for Nimbostratus rankNimbostratus

    If I may add, on the later versions there is a db key called apm.ad.kdclockout. Default value is 0.

    tmsh list sys db apm.ad.kdclockout

    The purpose is to control the behaviour of lockout of a KDC if the APM notices an outage to reach it.

    So if it is 0, every request it will try to reach the KDC even if the earlier request to KDC failed. So if a AD pool is configured a pool, this kdclockout value has to be zero. Else one pool member failure can bring the pool to be marked as down for the kdclockout duration.

    Again, if configured as direct, don't use value 0. If the first KDC is not reachable it won't go to a second KDC even if it's configured.

  • This ended up being a bug related to the version of BIG-IP that we were running.

     

    sol15117: https://support.f5.com/kb/en-us/solutions/public/15000/100/sol15117.html

     

    iHealth didn't immediately catch this, but it looks like it does now.