How to set different inactivity and Max session timeouts for the users in the different AD group

When using an ACCESS_POLICY_AGENT_EVENT, you'll want to check the [ACCESS::policy agent_id], which is the value that you set in the iRule Event object in the VPE. You'll also need to associate the iRule with your VS. The code you have now would run any time an iRule event from the VPE is used because it's not checking to make sure on that specific one should run.

So your iRule might look something like this (notice the agent_id check, and the value should be the same as the iRule Event one). The code is a little different than yours, but I copied the idea from an iRule I'm using.

when ACCESS_POLICY_AGENT_EVENT { 
     check for policy agent_id 
    if { [ACCESS::policy agent_id] eq "set_timeout_values" } {
        switch -glob [ACCESS::session data get "session.ad.last.attr.memberof"] {
            "*CN=Standard_SSL_Users*" {
                ACCESS::session data set session.inactivity_timeout 150 
                ACCESS::session data set session.max_session_timeout 200
                log local0.notice "Inactivity and Max timeout set" 
            }
        }
    }
}

Hope this helps.

Thanks for the quick reply , let me try this and come back ,.... if i have multiple AD-group/clients which needs different timeout settings , then the irule will look like this:-

when ACCESS_POLICY_AGENT_EVENT { 
if { [ACCESS::policy agent_id1] eq "set_timeout_values" } {
    switch -glob [ACCESS::session data get "session.ad.last.attr.memberof"] {
        "*CN=Standard_SSL_Users*" {
            ACCESS::session data set session.inactivity_timeout 150 
            ACCESS::session data set session.max_session_timeout 200
            log local0.notice "Inactivity and Max timeout set" 
        }

if { [ACCESS::policy agent_id2] eq "set_timeout_values" } {
    switch -glob [ACCESS::session data get "session.ad.last.attr.memberof"] {
        "*CN= SSL_Users2*" {
            ACCESS::session data set session.inactivity_timeout 600 
            ACCESS::session data set session.max_session_timeout 200
            log local0.notice "Inactivity and Max timeout set" 
        }

if { [ACCESS::policy agent_id3] eq "set_timeout_values" } {
    switch -glob [ACCESS::session data get "session.ad.last.attr.memberof"] {
        "*CN= SSL_Users3*" {
            ACCESS::session data set session.inactivity_timeout 600 
            ACCESS::session data set session.max_session_timeout 200
            log local0.notice "Inactivity and Max timeout set" 
        }   

    } } } } } } } 

You would do something like this, just adding other criteria to the switch statement.

when ACCESS_POLICY_AGENT_EVENT { 
     check for policy agent_id 
    if { [ACCESS::policy agent_id] eq "set_timeout_values" } {
        switch -glob [ACCESS::session data get "session.ad.last.attr.memberof"] {
            "*CN=Standard_SSL_Users*" {
                ACCESS::session data set session.inactivity_timeout 150 
                ACCESS::session data set session.max_session_timeout 200
                log local0.notice "Inactivity and Max timeout set (1)" 
            }
            "*CN=SSL_Users_2*" {
                ACCESS::session data set session.inactivity_timeout 200
                ACCESS::session data set session.max_session_timeout 300
                log local0.notice "Inactivity and Max timeout set (2)" 
            }
            "*CN=SSL_Users_3*" {
                ACCESS::session data set session.inactivity_timeout 300
                ACCESS::session data set session.max_session_timeout 400
                log local0.notice "Inactivity and Max timeout set (3)" 
            }
        }
    }
}

We generally recommend avoiding irules for simple situations like this where VPE rules can be used to have the same functionality. The main reasons are:

1. APMD/APD maintains a cache of user session variables to avoid calls to/from TMM's sessiondb where the variables are stored. These calls occur over a socket interface and are slower than APD/APMD using its cache directly. When you update session variables inside an irule during Access Policy evaluation, you are basically forcing a cache flush because APMD/APD can't know what "ACCESS::session data" you're using. "ACCESS::session data" operates on sessiondb directly, and not the sessvar cache.
2. APM has a function to import and export Access Profiles. These do NOT include external irules. So, if you implement part of your session logic in irules and part in Access Policy, then the whole policy is not included in import/export.

The Variable Assign already has predefined settings for max session timeout and idle timeout, so you can just use those. You can also add an "empty" action and define branch rules with whatever TCL you want. Instead of being executed by TMM, these are executed directly in APD/APMD and DO use the cache.

The other advantage is that the policy can be clearly visualized for reports to managers, execs, whatever. And it makes supporting the whole solution much easier.

We generally recommend avoiding irules for simple situations like this where VPE rules can be used to have the same functionality. The main reasons are:

1. APMD/APD maintains a cache of user session variables to avoid calls to/from TMM's sessiondb where the variables are stored. These calls occur over a socket interface and are slower than APD/APMD using its cache directly. When you update session variables inside an irule during Access Policy evaluation, you are basically forcing a cache flush because APMD/APD can't know what "ACCESS::session data" you're using. "ACCESS::session data" operates on sessiondb directly, and not the sessvar cache.
2. APM has a function to import and export Access Profiles. These do NOT include external irules. So, if you implement part of your session logic in irules and part in Access Policy, then the whole policy is not included in import/export.

The Variable Assign already has predefined settings for max session timeout and idle timeout, so you can just use those. You can also add an "empty" action and define branch rules with whatever TCL you want. Instead of being executed by TMM, these are executed directly in APD/APMD and DO use the cache.

The other advantage is that the policy can be clearly visualized for reports to managers, execs, whatever. And it makes supporting the whole solution much easier.