APM Nested Groups, Session Limits, and Timeout Confusion
An enterprise runs BIG-IP APM 16.1 for 12,000 employees. The access policy is: Start → Logon Page → AD Auth (AAA server) → AD Query for group APP-USERS → SSO Credential Mapping (Kerberos) → Allow. The backend application is sensitive and the APM session limit is set to one active session per user. Three problems appear after an AD migration. First, 3,500 users who belong to APP-USERS only through the nested group APP-ALL are denied. Second, users who open the application on a laptop and a phone receive a Maximum active sessions exceeded error. Third, users report being sent back to the logon page after about 15 minutes even while actively working. The APM license allows 10,000 concurrent sessions, and peak usage is 8,500. The AD team confirms the nesting is intentional and will not flatten the groups. The security team will not accept anonymous access, and the application team wants to avoid changing the backend authentication model.
1. How would you diagnose and fix the nested-group denials?
Read the worked answer
APM's AD Query returns group membership according to its search configuration. By default it may evaluate direct membership, so a user who is a member of APP-ALL and not directly of APP-USERS will not match. First confirm in /var/log/apm and the access policy session variables which group values were returned for a denied user. Then either enable the nested-group or recursive search option in the AD Query, if the installed version supports it, or replace the AD Query with an LDAP query using the recursive matching rule (member:1.2.840.113556.1.4.1941:=CN=APP-USERS,OU=...,DC=...). The latter asks AD to walk the chain, so nesting is handled by the directory.
Test with one affected user and one unaffected user before rolling out. Also check that the AAA server's bind account can read the nested group objects and that the group cache has refreshed. Do not flatten the groups in AD; the AD team has said the nesting is intentional, and changing it would create a second source of truth.
2. What should you do about the one-session-per-user limit for users on multiple devices?
Read the worked answer
Treat the one-session limit as a security decision, not a convenience setting. If the application handles regulated data and the risk assessment supports one session, keep the limit and change the behavior from Deny to Replace so a new login terminates the oldest session instead of locking the user out. That preserves the one-session policy while avoiding the error. If the business requires laptop and phone access, raise the per-user limit to two or three and document the exception; also consider whether the second device is a managed device.
Use endpoint inspection or a device posture check to distinguish managed from unmanaged devices if that matters. Check the global session limit as well: the license allows 10,000 and peak is 8,500, so per-user changes will not exhaust the license immediately, but monitor concurrent sessions. Finally, make sure the error page tells users which session will be replaced, so the help desk does not get avoidable calls.
3. How do you determine which timeout is sending active users back to the logon page?
Read the worked answer
Distinguish the three APM timers. The access policy timeout limits how long a user can take to complete the policy; the inactive timeout ends a session after no activity; the maximum session timeout caps total session life regardless of activity. A 15-minute return to logon while the user is active suggests the inactive timeout is 900 seconds and the application is not generating traffic that APM counts as activity, or the maximum session timeout is 900 seconds. Check the access profile settings and the session variables for the actual values.
If the application uses long-polling or websockets, APM may not see activity; enable the appropriate timeout behavior or increase the inactive timeout. Do not simply raise the maximum session timeout for a sensitive application; instead, confirm which timer is firing. Use tmsh show apm session and the session report to see start time, last activity, and termination reason. Align the chosen values with the application's own session timeout so users are not logged out by the backend first.