Ldap query from ltm

Hi Kevin,

I've already tested t the ACCESS::disable command, but something on the logic seemed wrong.

This irule where inserted above the irule with the regex (2 irule on this VIP):

when HTTP_REQUEST {
  if {!([HTTP::uri] contains "User")}{
  log local0. "we are here"
  ACCESS::disable
  pool pool-activesync
  }
}

I've also tried without the pool but nothing has changed:

when HTTP_REQUEST {
  if {!([HTTP::uri] contains "User")}{
  log local0. "we are here"
  ACCESS::disable
  }
}

This request is something unique for the first request. The device call the activeserversync server (without passing the user), the server asks for the credentials and the device send them on the URI (at least the User info that we need for the regex on the 2nd irule )

Thank for you help,

Mauro

I think you only want to disable the policy if 1) the user data does not exist in the request, and 2) this is the first request (missing an APM session cookie). You also have to make sure the user can't bypass the access policy by never sending user data or an APM cookie.

Hi Kevin,

I'm wondering we're near to the solution: first of all, I've disabled all the apm rules and solved some routing problems that I had on the lab enviroment.

Now I have the first irule that bypass the APM with the ACCESS::disable command ; than the device continues the session passing the credentials to the 2nd irule that correctly catches the User info from the URI. Finally the session is estabilished ( I see all the sessions estabilished on the APM session menu) but doesn't work (timeout after a while).

But I'm wondering something is missing with the apm flow: we see some requests for the APM's flow URI /my.policy...maybe we're missing an ACL or something similar ....

any ideas? Thanks in advance,

Mauro

HI Kevin,

Have you had the chance to read my last update? Do you have an idea on what's happening regarding those "URI /my.policy" logs? Maybe something missing on the APM configuration??

Best regards,

Mauro

So if I recall, we're working on a use case where one client type doesn't send the credentials in the initial request. All others do. Let's talk about a possible program flow.

client makes request to /Microsoft-Server-ActiveSync and does not have an MRHSession token - disable the policy for this request only    

Client traffic is passed through to server where the server asks for authentication in the response

Client sends authentication, like all other clients. Collect the credentials and store in the access policy    

You're most likely seeing requests to /my.policy in the server logs because of when and how you're disabling the policy.

Hi Kevin, yes, but the strange behavior is that it seems that something doesn't work on the last step.

client makes request to /Microsoft-Server-ActiveSync and does not have an MRHSession token - disable the policy for this request only   

It seems the irule that has to do this function is working as expected, and as I see the client/server communication proceed .

Client traffic is passed through to server where the server asks for authentication in the response
Client sends authentication, like all other clients. Collect the credentials and store in the access policy    

It seems that all this queries are managed correctly and, if the user belongs to that group, I can see that the APM session is "estabilished". Before I saw all these session in "pending" state.

The strange behavior is that this "established" sessions don't work, the activesync process failed and I don't know why...

Thanks in advance for your help,

Mauro

Hi Kevin,

finally it seems I've solved this issue: all the problems with the "established" sessions that didn't work, were on the session cookie that doesn't work as expected on these mobile devices.

So, I've added (using the wizard) an access policy of the type "web application access management" (adding my LDAP query search object previously tested) search and the irule certified and signed by f5 named "_sys_APM_activesync".

This has solved all my problems!!

Thanks for all,

Mauro