For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Lucas_Thompson_'s avatar
Lucas_Thompson_
Historic F5 Account
Oct 28, 2015

The connection context for the APM -> HTTP for AAA purposes is actually done between APM/APMD (v11/v12) and the AAA server, rather than Client -> HTTP. So I'm pretty sure the persistence record queried and/or created during the HTTP AAA operation would not match the LTM Client -> HTTP context.

 

This is closely related to bug ID 429418. Fixing that would require a major and risky architecture change. I think you'll have to do one of the following:

 

  1. Somehow allow the AAA operation to take place against the randomized pool.
  2. Use the HTTP AAA to authenticate the user, then toss the established backend session ID cookie (you'll have to use javascript and/or irules to accomplish this, as the cookies received by HTTP AAA are automatically stored and transmitted back to the client) and again SSO to the chosen server to obtain a new session after the initial APM session is established.
  3. Customize the APM logon page to provide a reasonable ux instead of using HTTP AAA (use AD or something), then SSO to the backend.
  4. Don't use a pool for the APM access.
  • MDPF52_180608's avatar
    MDPF52_180608
    Icon for Nimbostratus rankNimbostratus
    Oct 29, 2015
    Thank you lthompson. Actually I have configured the HTTP Auth to point a Virtual Server that have the same pool associated as the VS that have the Access Policy. I have also tried to used the same cookie persistance profile but it seems not working. Now I have enabled the priority group activation as a workaround. Any suggestion would be appreciated. Thanks again, M.