Forum Discussion
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 knew...my problem is that the branch rule that I try doesn't work the way it should for a known good...
Branch rule: expr {[mcget {session.ad.session.ad.last.attr.variable1}] != "" || [mcget {session.ad.session.ad.last.attr.variable2}] != ""}
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?
- Lucas_ThompsonJan 26, 2023Employee
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.
- jamie_staplesMar 15, 2023Altocumulus
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?