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

Sending APM AD Query groups as a header


Hi I'm setting up an APM with Kerberos auth that also needs to authenticate group membership to the applications.  They application owners also need to see which groups the users are members of to know what type of permissions they're assigned.  Users could be in multiple groups.  I have the Kerbers auth and the AD query working but the irule sends all of the groups in the memberOf field as a header and in CN=group,DC=domain,DC=local format.  Can anyone help?

This is the irule i have

clientside {
HTTP::header replace GROUPS [ACCESS::session data get]}
HTTP::header replace USER [ACCESS::session data get]

Would something like this work?


clientside {
HTTP::header replace GROUPS {[split [string map [list {| CN=} \0] $s] \0 ] [ACCESS::session data get]}
HTTP::header replace USER [ACCESS::session data get]


Better play an test to make it work as I have not done this myself but you can also try


Other than that to make it more secure better use F5 Bearer SSO JWT sign in than HTTP header as F5 can provide the groups in the JWT token that is signed by an F5 Cert that the applications can also have.


The only thing is I'm not using the primary group.  I'm changing the branch rule to branch rule 1 CN=AD group i'm checking against for membership and permissions to the application.

Community Manager
Community Manager


@SteveD1979 - I have marked "Accept As Solution" on @Nikoolayy1 's response. It appears correct and doing so will help others better discover his solution.


If you think this is wrong, feel free to correct me here.
To unselect as solution go to the options dropdown in the reply and choose "Not The Solution"

F5 Employee
F5 Employee


Such piece of code should work (HTTP_REQUEST_RELEASE is valid, too) and, taking for granted the group membership piece of data does not violate HTTP RFC (syntax, size, ...), I'd suggest we try we removing the directive "clientside".

Otherwise, the perRequest policies come with the "HTTP Headers" agents that should do just that!

Community Manager
Community Manager

Hi @SteveD1979 did you have any feedback after this reply from @Scot_JC  ?

@buulam /

No i still don't have this working.  Sorry I had other projects going on.  This is my irule right now and it will send all of the member of in CN=, DN=, DN= format.  The header is just too long.  I'm trying to figure out a way to split it with an irule or if i have to create a custom variable in the VPE and call that.


HTTP::header replace USERID [ACCESS::session data get session.logon.last.username]
HTTP::header replace GROUPS [ACCESS::session data get]


Not sure if this is more in @Lucas_Thompson's wheelhouse, or @JRahm, or @Kai_Wilke, but tagging them all just in case. 

All of your tagged guys could have answered the question. So first come first served... 😉 

Cheers, Kai

iRule can do… 😉

Hi Steve,

you may run either a variable assignment or custom iRule event within your VPE Session Policy to build a tailordered group string matching your needs. You may:

  • Filter the groups by name, so that only important groups (e.g. a specific name prefix/suffix, baseDN) will be delegated to your back-end.
  • Truncate any fully qualified DN information
  • Combine memberOf and primary group into one string.
  • Remove any LDAP specific encodings from group names.
  • Convert HEX to URI encoding for groups containing non-ASCII characters.  

Note: The decission to use variable assignment or iRule events is based on the complexity of the processing. iRule events supporting a more flexible TCL syntax with lots of useful commands added by F5 (e.g. b64encode/URI::encode, findstr/substr, etc.) . Variable assignment expression are basically pure TCL language with limited and slightly more complex command sets.  

The idea of performing such processing within the VPE Session Policy is, that you perform this heavy lifting just once for a given user-session and then simply inject the pre-computed information on a per-request basis either via iRule code (e.g. ACCESS_ACL_ALLOWED), via VPE Per-Request Policy or via JWT-SSO (which @Nikoolayy1 has recommended) without CPU intensive processings.

Let me give you an example how I've used VPE expression in the past, to compute a tailordered group string:

VPE Variable Assignment:

Variable Name:


VPE Expression:

set memberOf [mcget {}];
set primarydn [mcget {}];
set primarymemberOf [mcget {}];
if { $memberOf ne "" } then {
	append in_groups $memberOf;
if { $primarydn ne "" } then {
	append in_groups "|${primarydn}|";
if { $primarymemberOf ne "" } then {
	append in_groups $primarymemberOf;
if { $in_groups ne "" } then {
	foreach group [split [string map [list "%" "%25" {\,} "%5C%2C" " || " "|" " ||" "|" "|| " "|" " | " "|" " |" "|" "| " "|" ] $in_groups] "|"] {
		lappend out_groups [string range $group [expr { [string first "=" $group] + 1 }] [expr { [string first "," $group] -1 }]];
	set out_groups [string map [list "%5C%2C" {\,} "%25" "%" ] [join [lsort -unique [lsearch -all -inline $out_groups "*?*"]] "|"]];
	return $out_groups;
} else {
	return "";

Note: Keep in mind that a Group CN isn't a unique value in an AD infrastructure. Best practises is that the CN should match the actual Pre-Win2000 Group Name (this value is unique) so that you could savely truncate the DN notation. But you never know how creative your AD admins are. You may clarify this before starting to truncate DN notations... 

Using VPE based iRule events (e.g. ACCESS_POLICY_AGENT_EVENT) gives you more flexibility. The sample above could be simplified using a couple F5 specific iRule commands and would also allow you to convert HEX encoded AD Groups containing special character sets (e.g. german umlaute) back to UTF while adding URI::encoding to it, so its would become safe to intert the string in an HTTP header.  

Let me know if you need further assitance...

Cheers, Kai

iRule can do… 😉