F5 APM retrieve AD groups and resend using HTTP POST parameter

Dear all,

I am looking at a particular situation where an internal web server needs to know what kind of AD membership groups are assigned to a user that tries to login. The authentication only takes place on the F5 APM and NOT on the internal server. The internal server only needs to verify AD group membership, but may not communicate to AD.

The idea is to:

  1. Create a login page using APM
  2. authenticate using username and password to AD
  3. Retrieve the AD group membership
  4. Include a POST parameter with these AD group membership information and send it to the internal webserver

Somebody already had a similar situation before?

Hi Marvin,

Is this to say the first request to the backend server must be a POST, and that POST must contain AD group membership?

Dan

Yes this is fairly simple. Use LTM+APM mode, and AD Query / AD Auth in your Access Policy. Set the “start uri” parameter to your backend app’s URI, and use forms-based SSO (server-initiated) to fill in the resultant session variables from your AD Query into your form parameter. The groups will be in the form of a pipe-delimited list of the group DNs that came back from the query.

Hi Lucas, Yes I was exactly thinking about that scenario, but wanted to verify the point 4. Do you have an example on how to configure the forms-based SSO? Should I use the form action to include the session variable with the AD groups? Where am I able to define the parameter used for this purpose?

Hi Dan, yes that is correct.

Ahh ok just like an hidden form great!! Thats why I love devcentral :-), thanks!!

Hi Lucas, I am working on this configuration, authentication works fine, also F5 APM receives AD group information. I configured SSO form profile similar to your example. In the APM log I see that policy result is allow, however I don´t see any HTTP POST being send by the SSO form funcionality.

I have properly applied the SSO profile to the Access policy. Do you have any idea how to find the cause?

The client has to issue a HTTP GET on the “Start URI” in order for that to fire. Turn the SSO to debug log level and you can see each client request.

Hi Lucas,

it reports no start uri match in the sso logfile, any ideas?

Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: constructor
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: webssoContext constructor ...
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: 16 headers received
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header *[:method][GET] (len=3)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header *[:uri][/] (len=1)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header *[:version][HTTP/1.1] (len=8)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header *[:custommeta][▒=▒] (len=438)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header *[Host][111.10.1.1] (len=14)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header *[session-key][*******] (len=32)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header *[Cookie][ASP.NET_SessionId=mgzhaumzl44da0gayedm2egl; TIN=269000; .MESSER_AUTH=E84589DDCCE5D2075B5AFFC8C65FA19A776CF7FC39F8A153BCDBD661EE5BD43A576F72211AE088806CF7E18A06DFEA785B4C5A4799EC060922E77EF05822321D214731B91197EB84947E84228D5ECA9F6D7F3FB2596BC68846022CCB966B638B; F5_ST=1z1z1z1482964918z604800; LastMRH_Session=8d5bc85a] (len=318)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header  [Referer][https://111.10.1.1/my.policy] (len=32)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header  [Accept][text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8] (len=74)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header  [Cache-Control][max-age=0] (len=9)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header  [username][test] (len=8)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header  [Accept-Language][pt-PT,pt;q=0.8,en-US;q=0.6,en;q=0.4,es;q=0.2] (len=44)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header  [Upgrade-Insecure-Requests][1] (len=1)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header  [User-Agent][Mozilla/5.0 (Linux; Android 5.0.1; ALE-L23 Build/HuaweiALE-L23) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.91 Mobile Safari/537.36] (len=143)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: http header  [Connection][keep-alive] (len=10)
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0044:7: 8d5bc85a: metadata len 438
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: init webssoConfig from data: 0x9aab654, len: 438
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: different sso config object received, name: /Common/SSO_ACR-movil, method: 2
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: ssoMethod: form-based usernameSource: session.sso.token.last.username passwordSource: session.sso.token.last.password startURI: /ACRResponsive/inicio formAction: /ACRResponsive/inicio/Login formUsername: Usuario.Nombre formPassword: Usuario.Clave formParams: {Usuario.Grupo=%(session.ad.last.attr.memberOf) } _successMatchType: 0_successMatchValue:
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: ctx: 0x9915930, CLIENT: TMEVT_REQUEST
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: ctx: 0x9915930, CLIENT: TMEVT_REQUEST_DONE
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: ctx: 0x9915930, CLIENT: TMEVT_SESSION_RESULT
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: ctx: 0x9915930, CLIENT: TMEVT_SESSION_RESULT
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: ctx: 0x9915930, CLIENT: TMEVT_SESSION_RESULT
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: httpURI: '/ACRResponsive/inicio/Login'
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0030:7: 8d5bc85a: checking start uri match, start uri: '/ACRResponsive/inicio', request: '/'
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0031:7: 8d5bc85a: no start uri match
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: ctx: 0x9916cc8, SERVER: TMEVT_REQUEST
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: ctx: 0x9916cc8, SERVER: TMEVT_RESPONSE
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: ctx: 0x9915930, CLIENT: TMEVT_RESPONSE
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: ctx: 0x9915930, CLIENT: TMEVT_RESPONSE_DONE
Dec 28 17:42:30 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: _ssoDisabled: false, _needAuth: false
Dec 28 17:42:46 BIGIP01-SI- debug websso.0[13730]: 014d0001:7: Expire thread: TGTMap:0 UCCmap:0
Dec 28 17:42:46 BIGIP01-SI- debug websso.1[13835]: 014d0001:7: Expire thread: TGTMap:0 UCCmap:0
Dec 28 17:42:47 BIGIP01-SI- debug websso.2[13917]: 014d0001:7: Expire thread: TGTMap:0 UCCmap:0
Dec 28 17:42:48 BIGIP01-SI- debug websso.3[14005]: 014d0001:7: Expire thread: TGTMap:0 UCCmap:0

I changed it to / and now it is sending the HTTP post, the only thing is that the groups are not being send, in wireshark apears Usuario.Grupo=%(session.ad.last.attr.memberOf).

It’s a curly brace like { , not a paren like ( , maybe that’s the mistake?

you are right :slight_smile:

Great! Thanks for reporting back. You can use that curly brace in a lot of different places in APM for session variable substitution. It’s pretty useful for different stuff.

Hi Lucas another question, there is still some tuning to do, like when the user logs off the session within the applciation it remains active on the F5 side.

How can I make sure that the F5 will close the session when the client logs off within the application?

Is it perhaps needed to change the portal type so it will show the F5 logoff button in the upper menu and the customer needs to logoff using the F5 logoff button. In LTM+APM mode I don’t see this menu bar.

Any ideas?

I guess this function Logout URI Include in the Access policy?