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

APM Access Policy - Pass LDAP or AD Query variable


Is it possible to query whether a user has a value for one or another variable then use that to pass or fail passage down the rest of the swimlane for access? (e.g.- expr {[mcget {}] != 0 || [mcget {}] != 0} where the two variables are numbers or a non-constant string, but do have a value...and are not "<not set>".

Is it also possible to have another path where the lack of a value for the expr {[mcget {}] == 0, can be sent to a uri or url?

Any assistance would be greatly appreciated!



Someone suggested this:

and that mostly works for me....but does the same logic still work if it's either of the variables that are true, i.e.

expr {[mcget {}] != "" || [mcget {}] != ""}


Yep "||" works like that. For most cases, you can use "tclsh" on the BIG-IP command line to test small snippets like this (it doesn't support things like "contains" or "mcget" though, you have to substitute in your values there), for example:





Can tclsh be used as APM AD Query in VPE?  It would use the logic like if this variable/attribue has a value or this other variable/attribute has a value, proceed down this path.

If it doesn't, what would?  An iRule?  And what would the iRule have to look like?

Sorry for so many questions...Thanks! 

I directly modified this ( to use || (or):


"You are using 'info exists' and 'mcget' incorrectly.

'mcget' will return the value of the APM session variable, so if the session variable for '' is 555-1234 you are passing this to 'info exists'. i.e. you are executing 'info exits 555-1234' but guessing no variable exists named 555-1234 (or what ever the value is)

I think if you call 'mcget' on a session variable that doesn't exist I think you get "" returned, so the following should do what you want (not tested as no quick access to APM currently):

if {[mcget {}] == ""} { set ad_attribute1_exists 0 } else { set ad_attribute1_exists 1 } if {[mcget {}] == ""} { set ad_attribute2_exists 0 } else { set ad_attribute2_exists 1 } expr { $ad_attribute1_exists == 1 && $ad_attribute2_exists == 1}

Or as a one liner:

expr { [mcget {}] != "" && [mcget {}] != ""}    "

Sorry for the confusion, no I was suggesting to use tclsh to check TCL syntax itself, such as how to use expr and combine logical operators and test precedence, such as how || and && relate, etc. tclsh is not used by the data plane in BIG-IP at all. BIG-IP has two TCL interpreters in the data-plane, one is built into TMM (used for irules and per-request policy evaluation) and one is built into APMD (used for per-session policy evaluation such as branch rules and variable assignments).

Basically in VPE in APM, you have two things in each policy-item: Agents and branch rules. The agent runs (AD query or whatever) then fills in the session variables for that agent. After the agent execution, the branch rules are evaluated one-by-one. If one of the branch rules evaluates to True, then it policy execution follows that branch to the next-item in the flowchart. If none of the branch rules evaluate to True, then policy execution follows the Fallback branch.

To see what session variables are set by the agent in the policy-item that you can use for "[mcget xxxxxx]", set the logging to Informational level in the "Access Policy" setting:


So the complex part is mostly just how to construct the TCL to put into the branch rules. VPE has a feature called "expression builder" that lets you construct many of these common ones easily. In the GUI this is called a "simple" expression. You can do something like this as a "this group or that group" kind of selection:


Clicking Finished results in a branch rule that looks like this:


You can then go and examine the actual TCL that the expression builder constructs by clicking "change", then "advanced":


Of course you'll need to modify the LDAP DN to match whatever your AD controller sends back from the query, either a full DN or a substring. You can see it uses "contains" so it can be a partial match too.






Thank you for your time and answer....that helps solidify what I thought I problem is that the branch rule that I try doesn't work the way it should for a known good...

Branch rule: expr {[mcget {}] != "" || [mcget {}] != ""}

For my test account there is a value for variable 1, but the debug logs say that it can't be found nor is it memcached.

What am I missing?

If you get a log that the variable is not found, then the AD Query agent must not have created it. The LDAP Search performed by AD Query includes a default attribute filter that you can adjust or remove. By default only these "Required Attributes" are returned by the search:


So if you need additional attributes than these, you can add them.

If the additional attributes ARE among the required attributes, and I am still getting the variable is not found, what do I do?

If I have removed some of the "required attributes", does that break something?  Do I always have to use the specific required attributes AND any additional attributes?

Community Manager
Community Manager

@Lucas_Thompson may be able to help with this one.