Forum Discussion

Florian_Meister

Icon for Nimbostratus rank

Nimbostratus

Oct 11, 2013

auto escaping of variables used via %{xxx}

Hi,

I have a problem when using a session variable as "Search base" in a following LDAP query. I'm using the host-header to search only a specific sub-tree of my LDAP server. For that, I search an "application" tree in my LDAP-directory, where the mapping between host-header and search-base is stored.

When using the variable which was created by the first LDAP search for search-base of the 2nd LDAP search I got the following error message:

LDAP module: query with 'uid=axfme01' failed: No such object, dn: ou=ABX\2cou=Kunden\2cdc=abxsec\2cdc=com scope: 2 filter: uid=axfme01 (32)

so the variable got escaped which results in an error at the ldapsearch.

In the Irule before the search starts, I log the variable via syslog and there is no escaping done:

ACCESS::session data set session.custom.searchDnHostAccess "[ACCESS::session data get session.ldap.last.attr.ABXKSearchDN]"
log local0. "SearchDN: [ACCESS::session data get session.ldap.last.attr.ABXKSearchDN]"

Here is the relevant part of the log:

Oct 11 14:52:21 ras1zh info tmm6[10190]: Rule /Common/portal_ras_access-policy : entering portal_host_post ...
Oct 11 14:52:21 ras1zh info tmm6[10190]: Rule /Common/portal_ras_access-policy : SearchDN: ou=ABX,ou=Kunden,dc=abxsec,dc=com

I also tried to display a message-box instead of logging it, I thought maybe escaped characters get lost somewhere on the way in the log, but its the same.

my question:

why is the content of the variable escaped ? or if it's not, why will it be escaped when used as search-dn ? How can I work around this "feature" ?

best regards,

flo

application delivery

4 Replies

What_Lies_Bene1
Cirrostratus
Oct 11, 2013
I'm not sure it's the F5 doing the escaping. Where do you see that error message? It seems the commas must be escaped but not necessarily with \2c.
Florian_Meister
Nimbostratus
Oct 14, 2013
Many thanks, perfect answer! I'm looking forward to submit a support-case.

best regards,

florian

Florian_Meister

Icon for Nimbostratus rank

Nimbostratus

there is another very, very annoying issue concerning the use of %{} in APM elements:

it seems that if using elements like suggessted before

%{session.custom.dnpart0},%{session.custom.dnpart1},%{session.custom.dnpart2}

they get sorted for I don't know what reason ?!?

I want to split the DN and then sort it reverse, so that the most significant part is the element 0 - not the least significant. I want to use that for simply using only X elements of the DN, even if there were more specified. So I can use:

%{session.custom.dnpart2},%{session.custom.dnpart1},%{session.custom.dnpart0}

and simply not use other less significant parts of the DN for searching.

I tried that and had no idea why it was not working. The message was like:

Oct 15 10:52:16 ras1zh info tmm6[10190]: Rule /Common/portal_ras_access-policy : portal_logon_post: entering ...
Oct 15 10:52:16 ras1zh info tmm6[10190]: Rule /Common/portal_ras_access-policy : portal_logon_post: SearchDN: ou=ABX,ou=Kunden,dc=abxsec,dc=com
Oct 15 10:52:16 ras1zh info tmm6[10190]: Rule /Common/portal_ras_access-policy : portal_logon_post: length = 4
Oct 15 10:52:16 ras1zh info tmm6[10190]: Rule /Common/portal_ras_access-policy : portal_logon_post: entering loop ...
Oct 15 10:52:16 ras1zh info tmm6[10190]: Rule /Common/portal_ras_access-policy : portal_logon_post: session.custom.dnpart0: dc=com
Oct 15 10:52:16 ras1zh info tmm6[10190]: Rule /Common/portal_ras_access-policy : portal_logon_post: session.custom.dnpart1: dc=abxsec
Oct 15 10:52:16 ras1zh info tmm6[10190]: Rule /Common/portal_ras_access-policy : portal_logon_post: session.custom.dnpart2: ou=Kunden
Oct 15 10:52:16 ras1zh info tmm6[10190]: Rule /Common/portal_ras_access-policy : portal_logon_post: session.custom.dnpart3: ou=ABX
Oct 15 10:52:16 ras1zh info tmm6[10190]: Rule /Common/portal_ras_access-policy : portal_logon_post: leaving ...
Oct 15 10:52:16 ras1zh err apd[6742]: 01490110:3: dbd1d089: LDAP module: query with 'uid=axfme02' failed: No such object, dn: dc=com,dc=abxsec,ou=Kunden,ou=ABX scope: 2 filter: uid=axfme02  (32)

as you can see above, I log the elements of the DN. And normally it the search DN should be correct and not reversed. I thought there is a problem with syncing or something like that. I tried to put in the elements one by one in the search-dn field of the LDAP query, and there the variables are used correctly. I also tried to use no "comma" as seperator, instead I used "--" as a seperator. And was really astonished that it substituted the variables correctly.

I was on the right way. I used the following entry in the search DN field:

%{session.custom.dnpart2},%{session.custom.dnpart1},%{session.custom.dnpart0}--

and what happens ? It does not get sorted and would work if there were not this f.... "--" at the end:

Oct 15 10:54:09 ras1zh err apd[6742]: 01490110:3: 3fe6dc68: LDAP module: authentication with 'uid=axfme02' failed: No such object, base: ou=ABX,ou=Kunden,dc=abxsec,dc=com -- scope: 2 filter: uid=axfme02  (32)

I'm really disappointed. Why do F5 think that it needs to do such odd things with MY input ?? I don't want to somehow sort or escape my variables. I want them to be as they are.

Can somebody help here ??

best regards,

Florian

Florian_Meister
Nimbostratus
Oct 15, 2013
update: after further research I think it's something with the visual policy editor. After exporting the policy and having a look on it in plain-text, I saw that the corresponding objects have an old configuration.

I have double-checked everytime to apply the config after a policy-change, but somehow this object is not getting updated. I'll try to re-import the policy. Maybe that helps.

best regards,

flo