Ldap query from ltm

Hi Kevin,

ok, thanks.

Tomorrow I'll test/check what you've suggested. How can I test (locally on the APM/LTM, before starting to work with the irule) if the query will work as desired? If the query will work, the next step will be (as you've already suggested in previous messages) configuring the irule that will extract the user from the http request and pass the information to the apm module...I'm also wondering to simplify the scenario using this virtual appliance both for the query and the pool management. The frontend device (ASM) will only check for any signatures/anomaly and will pass all the requests to the VIP on the BE where I have both the APM and the LTM.

Mauro

Hi Kevin, as you've suggested, I've configured the access policy and the branch rule. Now, as I've written, I'd like to use the same appliance both as a LTM and APM module. Do I need the same irule that you've had previously suggested (that one that you've suggestd for an external LTM) or something more simple? Best regards, Mauro

Hi Kevinn,

I've upgraded to the 11.4 hf4 version (I've read that in this version "has the ability to apply an Access Policy on top of LTM") and all the configurations for the access policy and the LDAP server were implemented. If I try to access the VIP, the session could not be established, but I see that the BIG-IP is sending something to the LDAP server.

Now I'm wondering that only the irule for catching the users form the query is missing. The user (I've done e new log session for trace how these requests are coming) in a GET request, on the URI, something like: /Microsoft-Server-ActiveSync?User=Pippo&Device=App

I'm wondering that (using both APM and LTM on the same appliance and the 11.4 version) this irule will be something more simple...any suggestions for this irule?

thanks in advance for your precious support,

Mauro

Do I need the same irule that you've had previously suggested (that one that you've suggestd for an external LTM) or something more simple?

First, if you're doing APM on the load balancing appliance, the configuration is actually much simpler than I've described, and probably won't require much iRule code at all. Your APM access (visual) policy should, more or less, look like the following:

start - iRule event - LDAP Query - Allow

Where the iRule event is used to the extract any values necessary from the client request, the LDAP query (with an attached LDAP AAA) performs an LDAP query with the values provided, and then you either allow the traffic based on the success or failure of the LDAP query, or add additional conditions to the policy. The only iRule code you may need will be in pulling the necessary value(s) from the client request.

How can I test (locally on the APM/LTM, before starting to work with the irule) if the query will work as desired?

The easiest way to troubleshoot an APM access is to drop message boxes in the visual policy at different stages so that you can see where it's going, and potentially see session variables at different points. Add a message box where you want to see the path taken (ex. before and after the LDAP query). To see any session variables that may have been created, use the %{} syntax in the message box text fields. Exampele:

%{session.ldap.last.attr.userPrincipalName}

Hi Kevin,

My visual policy is something like this:

but the irule is assigned on the virtual server\resources menu. Do I have to assign it using the visual manager?

thanks , Mauro

but the irule is assigned on the virtual server\resources menu. Do I have to assign it using the visual manager?

It shouldn't matter where it is in the visual policy as long as the flow makes sense. It may be simpler at this point to back out and test the LDAP query by itself. If you can create a NEW access profile, please do so and follow these steps:

1. Create your LDAP AAA

2. Create your new access profile and open the visual policy editor

3. Add a Variable assignment agent as the first new item and create a custom session variable. Example:

   session.custom.user = expr { "bob.user" }
   

   Substitute the user with some name you know exists in the LDAP directory.

4. After the Variable assignment, create your LDAP Query agent.

   • AAA server - the LDAP AAA server you just created
   • SearchDN - the DN path where users can be found.

   • SearchFilter - this is the LDAP object you're looking for, based on the previously-created custom variable. Example:

     userPrincipalName=%{session.custom.user}
     

5. Go to the Branch tab of the LDAP Query agent.

   • Change the Name field to something like "Query passed"
   • Click the Change link
   • Click the x in the top right corner to delete the existing expression
   • Click the Add Expression button
   • Agent Sel should be "LDAP Query"
   • Condition should be "LDAP Query Passed"
   • Click the Add Expression button
   • Click Finished
   • Click Save

Set the ending block after the Query passed branch to Allow and test this access policy attached to a VIP. The idea here is that you've short circuited the process to focus on the LDAP query itself. If the query works with the static user value from the custom variable, you should be able to run an access policy report and see all of the LDAP values returned. You then just need to:

• Modify how the custom variable is set - presumably from HTTP request URI data
• Apply this same LDAP query configuration to your original access profile

Hi Kevin,

ok,thanks.

tomorrow I'll test it as you've suggested,

Mauro

Hi Kevin,

here I've tested the query using the variable assignment, but this test has failed.

I've checked the attributes on the LDAP server using an LDAP search program and the problem is that this users are on that grup as a members and with all the complete DN instead of the sAMAccountName . So, the sAMAccountName is the value of the user in that DB, but this isn't the attributes that I've to search with the query... Checking the apm logs, I've also found thi message:

modules/Authentication/Ldap/LdapAgent.cpp func: "getLdapUserInput()" line: 735 Msg: 60c9f1c8: LDAP Agent: getLdapUserInput(): unable to decrypt user password due to NULL ciphertext

Any ideas?

Thanks in advance,

Mauro

The NULL ciphertext message can be ignored. It has nothing to do with he LDAP query failing.

If you could successfully query the LDAP directory from some other application or command line tool, what would that query look like? One of the tools I use to troubleshoot LDAP queries is the LDAPSEARCH command. Here's an example:

ldapsearch -H ldap://10.70.0.1:389 -x -b cn=users,dc=mydomain,dc=com -D [email protected] -w [password] [search criteria ex. cn=bob]

Do a quick search online and/or read the LDAPSEARCH MAN page for more information on its use. Ultimately your APM LDAP query will work more or less the same as the search criteria in this command.

HI Kevin,

ok, thanks, the query (with the static Variable Assigned) finally has worked!

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

Best regards,

Mauro