Ldap query from ltm

Now I'm searching how to pass (via irule) dynamicaly the sAMAccountName to the searchfilter. Do you have anything similar?

The value on the right side of the SearchFilter is going to be a dynamic variable. Example:

sAMAccountName=%{session.custom.foo}

What you assign to that custom session variable prior to the LDAP query, depends on when and where you're going to come by that information. So where is this value going to come from?

Hi kevin,

this value has to come from the irule that will pass it to the apm module :

I've configured an irule for catching (using a regex) the user information from the URI, create an apm session (ACCESS::session create) and passing the user information to the apm policy (as a dynamic variable).

I've tried to post this irule (as a preformatted code), but every-time I receive an error from the devecentral portal :-(

If I try with an invalid user, the apm policy will work and I receive the failure message from the apm. But if the user is the correct one (a member of the group defined on the ldap query), the apm policy works but I'm having a segmentation violation error on the APM . IN this situation the session remains in "pending" state...

F5 is telling me that this could be a bug :-(

Thanks for your support,

Mauro

First thing, if this is a web-based application, then you probably don't need the ACCESS::session create function. This is done automatically when the browser connects. What you should probably do instead is capture the username in the URI, assuming it's coming in the first request, from the ACCESS_SESSION_STARTED event. Something like this:

when ACCESS _SESSION _STARTED {
    set username [whatever function you use to extract value from URI]
    ACCESS::session data set session.custom.username $username
}

HI Kevin, Just tried it, but someting got wrong...as a test, Iried using a static value on the irule:

when ACCESS _SESSION _STARTED {
    set username "mauro"
    ACCESS::session data set session.custom.username $username
}

But I've received this error:

01070151:3: Rule [/Common/Ldap_no_session] error: /Common/Ldap_no_session:1: error: [unknown event (ACCESS)][when ACCESS _SESSION _STARTED {
set username "mauro"
ACCESS::session data set session.custom.username $username
}]

ops...it was my fault: that errors' appeared because I've inserted a space between ACCESS and session _SESSION ...

let me see...

HI Kevin,

both the irule and the apm now works, but now I'm having another issue:

different devices are coming differently: sometime with the User=domain\use (Android) , others with User=user and others (android and windows mobile) without the user (this is the big problem, the firt request is something like /Microsoft-Server-ActiveSync :-( )

This is a nightmare!

It certainly sounds like a nightmare for sure. You'll likely have to tackle these things the way they come. Your iRule will first need to detect how the username is formatted (ie. if it contains a backslash). The second problem is going to be more difficult to get around. So when does the mobile client send the username?

Hi Kevin,

the problem here is that different device are coming differently and we don't know if - for example - different android version will come ( and send username)differently. I need from my colleagues that are working to this project all the specifications and the type of devices before continuing: I can't change this irule every day checking what are coming from the logs...

Many thanks for your precious help,

Mauro

Hi Kevin,

any ideas on how to bypass the APM module for the first client's requests? As I've noticed, all the devices except the ipad start the session contacting the application with a URI /Microsoft-Server-ActiveSync (without user's information ), than the server asks for credentials and the device send the user information on the URI...

But my APM policy will accept/start the session only if the regex of the irule implemented match "User" on the URI....

Thank in advance for your help,

Mauro

You could inspect the requests in an HTTP_REQUEST event and disable the policy evaluation using the ACCESS::disable command. Not 100% sure of the logic here yet though. Does /Microsoft-Server-ActiveSync get called multiple times and/or is there anything unique about this first request other than missing user information?