Technical Forum
Ask questions. Discover Answers.
cancel
Showing results for 
Search instead for 
Did you mean: 

APM LDAP by path

TimRiker
Cirrostratus
Cirrostratus

I'm trying to figure out a means to allow different LDAP query limits for different paths on the same server.

I can add the various ldap queries to a string datagroup indexed by hostname/path (as the virtual server will hopefully handle other servernames too) and insert them into a session.ldapsearch through use of a table/subtable. I tried just variables, but the iRule event ACCESS_POLICY_AGENT_EVENT does not appear to "see" variables created in other sections of the same iRule. This is further complicated when using http2 as request events can happen in different iRule context.

The issue is if I create an "LDAP Query" instance in the APM flow and use something like:

 

(cn=%{session.oauth.client.last.id_token.cn})

 

This works fine, but something like:

 

(&(cn=%{session.oauth.client.last.id_token.cn})(%{session.ldapsearch}))

 

Does NOT work as session.ldapsearch is RFC-4515 escaped as if it were a single entity instead of a formatted search.

How do people add different LDAP checks for differnt paths on a server using APM?

If this were just a single group membership, I think inserting the one "group name" needed for each host/path would be fairly straight forward.

I would hope that the requested url path would be found in session.server.landinguri but so far I'm testing things in the iRule using variants of [HTTP::host][HTTP::uri] for the lookups.

11 REPLIES 11

Lucas_Thompson
F5 Employee
F5 Employee

There is a BIG-IP sys db variable that controls this escaping behavior of APM session variables sent to an LDAP query function in APM: apm.ldap.autoescape

To change it from the CLI,

tmsh modify sys db apm.ldap.autoescape value disable
tmsh save sys db

 

That looks exactly like what I want, but unfortunately it does not seem to work.

Is there anything else I need to do? With this changed and saved, restarted tmm, failed over to another node, failed back, db entry is "disabled" as shown:

tmsh list sys db apm.ldap.autoescape one-line
sys db apm.ldap.autoescape { value "disable" }

And SearchFilter set to something like:

(&(cn=%{session.oauth.client.last.id_token.cn})(%{session.ldapsearch}))

I still get errors like:

2022-12-13T20:33:35.393-07:00 xxxx warning apmd[8859]: 01490233:4: /Common/access_xxxx:Common:895b427c: LDAP Module: Cannot find any object in search DN 'ou=people,o=org' matching filter '(&(cn=something)(field=\2a))'

when session.ldapsearch = "field=*"

Running BIG-IP 15.1.5.1

Shoot. Sorry I misunderstood the internal writeup on this. Instead of not escaping itself it looks like it expects *you* to escape it manually. Can you try setting it to "\66\69\65\6C\64\3D\2A"? That should be "field=*". 

You're going to have to double-escape them inside the iRule or policy agent config. TCL gets weird with escaping sometimes. The example I've got from bigip.conf where the variable is being set from a var-assign policy agent to "medusademo" to formulate a search filter is:

apm policy agent variable-assign /Common/ldaptest_act_variable_assign_ag {
    variables {
        {
            expression "expr { \"\\\\59\\\\87\\\\FB\\\\A6\\\\AB\\\\1E\\\\D7\\\\40\\\\BE\\\\F8\\\\C7\\\\66\\\\C7\\\\DE\\\\CD\\\\56\" }"
            varname session.objectguid.foo
        }
    }
}

apm policy agent aaa-ldap /Common/ldap_query_bar_act_ldap_query_ag {
    filter "objectGUID=%{session.objectguid.foo}"
    search-dn cn=users,dc=lab,dc=apm,dc=f5test,dc=local
    server /Common/ldapQATest4
    type query
}

 If it doesn't work at first, packet capture a plaintext LDAP query so you can see what it's sending on the wire, the escaping might not be exactly right.

I added this in my iRule.

ACCESS::session data set session.ldapsearch "\\66\\69\\65\\6C\\64\\3D\\2A"
catch {log local0. "sls=[ACCESS::session data get session.ldapsearch]"}

Output:

2022-12-14T11:20:24.600-07:00 <f5> info tmm1[12587]: Rule /Common/<vip> <ACCESS_POLICY_AGENT_EVENT>: sls=\66\69\65\6C\64\3D\2A

however, I get this:

2022-12-14T11:20:25.517-07:00 <f5> err apmd[5091]: 01490235:3: /Common/<access policy>:Common:6c31ab75: LDAP Module: Failed to make ldap_search in '<search dn>' with filter '(&(<user filter>)(\5c66\5c69\5c65\5c6C\5c64\5c3D\5c2A))' and scope '2'. Bad search filter.

The entries in <> are redacted. The "\5c66\5c69\5c65\5c6C\5c64\5c3D\5c2A" here is the search, which, as you can see, is still expanded from "\66\69\65\6C\64\3D\2A". So escaping it in the iRule and session variable, means it gets double-escaped in the ldap search.

I rebooted the F5 and failed it back to primary before running this test. The db entry is still set:

# tmsh list sys db apm.ldap.autoescape one-line
sys db apm.ldap.autoescape { value "disable" }

redacted details:

# tmsh list apm policy agent aaa-ldap /Common/<policy>_act_ldap_query_ag
apm policy agent aaa-ldap <policy>_act_ldap_query_ag {
    filter "(&(<id>=%{session.oauth.client.last.id_token.<idname>})(%{session.ldapsearch}))"
    search-dn <searchdn>
    server <ldap>
    show-extended-error true
    type query
}

 Thoughts?

Putting the entire search in via the irule and setting SearchFilter to %{session.ldapsearch} also gets escaped. Using this set:

ACCESS::session data set session.ldapsearch "(&(<id>=[ACCESS::session data get session.oauth.client.last.id_token.<id name>])(field=*))"
catch {log local0. "sls=[ACCESS::session data get session.ldapsearch]"}

Logs correctly:

2022-12-14T11:38:57.390-07:00 <f5> info tmm[12587]: Rule /Common/<rule> <ACCESS_POLICY_AGENT_EVENT>: sls=(&(<id>=<user id>)(field=*))

Redacted output:

2022-12-14T11:38:57.400-07:00 <f5> err apmd[5091]: 01490235:3: /Common/<policy>:Common:1bda35bc: LDAP Module: Failed to make ldap_search in '<searchdn>' with filter '\28&\28<id>=<user id>\29\28field=\2a\29\29' and scope '2'. Bad search filter.

If the F5 is not autoescaping, and the entity value has problematic characters in it like "()*|!&:~\" those would break ldap searches, and the user would need to esape those someplace.

Normally the F5 does RFC-4515 escape strings. This makes sense for entities, but NOT for search filters.

The db option makes sense, however setting it seems to have no effect for me.

Lucas_Thompson
F5 Employee
F5 Employee

OK, great, it sounds like you've found this setting doesn't fuction correctly in your version. Can you get a support case open so we can investigate further? The DB setting is definitely supposed to disable escaping altogether.

@Lucas_Thompson

Where is this db setting documented? It's hard to report "not working as documented" when I can't find any documentation.

TimRiker
Cirrostratus
Cirrostratus

I've opened support case 00332440 on Dec 19th which, so far, has not gotten any progress.

Hey @TimRiker - happy new year! Any update on this?

Thanks for checking in, @Leslie_Hubertus. Last reply from F5 on the open ticket was on Dec 30th.

I still have not found any documentation on apm.ldap.autoescape