Bug ID 703232: Escaping is not correct when ldapdn modifier is applied for a session variable

Last Modified: May 01, 2019

Bug Tracker

Affected Product:  See more info
BIG-IP APM(all modules)

Known Affected Versions:
11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3,,,,, 11.6.4, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3,,,,,,,, 12.1.4,, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0,,,,,,,,, 13.1.1,,,,,, 14.0.0,,,,, 14.1.0,,,,

Opened: Jan 23, 2018
Severity: 3-Major


As a result of this issue, you might notice the following symptoms: -- In some agents in an Access Policy, it's possible to use session variables to configure a field (for example LDAP Auth agent). -- Session variables may have modifiers applied (ldapdn ldapfilter or noconv). -- There are fields that requires DN to be configured e.g., user DN or search DN, in the LDAP AUth/QUery agent. Those fields have the ldapdn modifier applied by default. That means that if the search DN value is %{session.mydn}, the DN escaping mechanism will be applied to the session variable during substitution. -- The escaping does not work correctly for ldapdn modifier. -- Instead of escaping RDN value, it escapes the whole DN (including the equals character = between the name and the value, and the comma character , between RDNs).


Cannot pass the agent; the Access Policy fails.


-- A field that accepts DN value is configured using a session variable. -- AAA LDAP Server. -- LDAP Auth to authenticate users using userDN. -- User account name containing a restricted character that must be escaped (e.g., the equals character, =). -- Access Policy that contains LDAP Auth agent. -- Authenticate with the user DN.


To workaround the issue, apply modifier 'noconv' explicitly to the session variable. For example, if you have the variable %{session.mydn} configured in the 'search DN' field, use %{session.mydn:noconv} instead.

Fix Information


Behavior Change