Bug ID 663506: apmd crash during ldap cache initialization

Last Modified: Apr 28, 2025

Affected Product(s):
BIG-IP APM(all modules)

Known Affected Versions:
11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1

Fixed In:
13.1.0, 12.1.3

Opened: May 08, 2017

Severity: 2-Critical

Related Article: K30533350

Symptoms

apmd crashes.

Impact

BIG-IP cannot process user logon request, until apmd is restarted and LDAP cache is updated

Conditions

- LDAP module is in use in an access policy, - APM end-users are logging in, while administrator modifies AAA LDAP Server or LDAP Agent, - Cache update takes a while (too many groups in domain and/or slow network).

Workaround

The best practice is to update policy/AAA LDAP Server when BIG-IP is not under load. Then make one logon manually. apmd updates caches on first APM end-user's logon. Once caches update, all the further logons should happen much faster and should not cause any problems

Fix Information

APMD now handles the generation of LDAP Query / AD Query nested group cache correctly during high authentication load.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips