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

Last Modified: Oct 24, 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.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 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.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.0.1, 14.0.1.1, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.4, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1

Opened: Jan 23, 2018
Severity: 3-Major

Symptoms

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).

Impact

Cannot pass the agent; the Access Policy fails.

Conditions

-- 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.

Workaround

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

None

Behavior Change