Restrict access time by AD group

[Mdell150]

We want to setup an AD group and then limit that group to having connections from 8:00AM to 8:00PM. We are currently running version 13. 

[Rhonda Rowland1709152125]

So, assuming this is for Gateway and using advanced policy engine (so, an authentication vserver with advanced policies).

 

You can do this either during the post logon/authorization phase and set a default "deny" authorization unless the members of the group log on via specific hours.  If done, as authorization, they can log on but the authorization deny prevents access to resources. This is easy to setup and test and we just have to show you how the time-based expressions work.  All you have to do is assign the correct authorization time-based policy to the correct group.

 

If you want to do this during the authentication phase, you can. Again, I'm assuming we're working in advanced authentication policies to keep the scenarios simple.  It can be done in classic authentication too...but you would then have to migrate.  Doing this in authentication is more tricky because you have to evaluate logon groups first and then figure out if a time limit applies.

 

A quick advanced time-based expression example:

1) ADC system time is exposed via the SYS.TIME expressions.  I'm defaulting examples to the ADC's time normalized to GMT (though you could work in a timezone instead.

For this example, let's assume the "current" time is 1/18/2022 20:15 EST is 2:15 am GMT

SYS.TIME  returns adc system time as a number of sectons from origin date (in 1970)

SYS.TIME.HOURS returns current time as a integer from 0-23.  So 8:00 pm GMT (20:00) is returning 20.  

 

So to evaluate a time between 9-10 pm ADC US EST normalized to GMT would be 2-3 am GMT.   This was the time I tested until clock rolled over below. I would then use 3-4 am "for out of hours".

SYS.TIME.HOURS.BETWEEN(2,3)

Adjust for your ADC's timezone compared to GMT unless you wanted more complicated expressions.

 

Note an 8 am - 8 pm in GMT is straightforward, an 8 am to 8 pm EST normalized to GMT has to be split between the pm day before and the am day after numbers.  I'll show that in a second after the demos.

 

So, 8 am - 8 pm GMT would be  SYS.TIME.HOURS.BETWEEN(8,20)

But if you are working in US EST 8 am - 8 pm and converting to GMT 13 pm - 1 am, which you can't just write as SYS.TIME.HOURS.BETWEEN(13,1)

** NOTE I only did limited testing as I didn't want to spend time on clock changes, but watch that crossing pm to am boundary....

You'd likely have to write like this (but I'm not sure about the 11 pm - 12:am hour might be wrong. Not going to manipulate clocks to test:

Possibly this:  sys.TIME.HOURS.BETWEEN(13,0) || sys.TIME.HOURS.BETWEEN(0,3)

Might actually be this:  sys.TIME.HOURS.BETWEEN(13,23) || sys.TIME.HOURS.BETWEEN(0,3) || (sys.TIME.HOURS.EQ(23) && sys.TIME.MINUTES.BETWEEN(0,59))

(But I'm not testing this:  1:00 pm - 11:00 pm GMT || Mid - 3:00 am GMT || (11:01 - 11:50 pm GMT)

 

 

Example 1:  Authorization Example (snippet)

So, if used in the "authorization" example and assigned to group RestrictedUsers, they will only get an "ALLOW" right to override the default DENY if they connect during the 9-10 pm EST as GMT 2-3.  If this policy is only on one GROUP, other groups get normal non-time restricted authorization controls. 

 

Example policies:

add authorization policy autho_pol_allowall true ALLOW
add authorization policy autho_pol_allow_workinghours "sys.TIME.HOURS.BETWEEN(2,3)" ALLOW

bind aaa group RestrictedUsers -policy autho_pol_allow_workinghours -priority 100 -gotoPriorityExpression END
bind aaa group RegularUsers -policy autho_pol_allowall -priority 100 -gotoPriorityExpression END
## Note: Default session policy on vpn vserver has no default authorization set or defaults to DENY so only group members get authorized allow when conditions are met.

 

For Authentication its a little different:

 

Example 2: One VPN; time based authentication (via AAA); all users of this vpn affected same way.
If the only users connecting to the vpn vserver is the one group RestrictedUsers, then you can use the SYS.TIME.HOURS.BETWEEN(X,Y)  expression as the condition of the authentication policy. If in hours, you are allowed to attempt to authenticate.  If after hours it should be a failed authentication.

 

add vpn vserver vpn_vsrv_gateway SSL <VIP1> 443 -authnProfile authe_prof_authevsrv
add authentication vserver authe_vsrv_demo SSL <VIP2> 443

 

This is the US EST 9-10 pm normalized to 2-3 am GMT

add authentication Policy authe_pol_ldap_wsl -rule "sys.TIME.HOURS.BETWEEN(2,3)" -action authe_prof_ldap_wsl
bind authentication vserver authe_vsrv_demo -policy authe_pol_ldap_wsl -priority 100 -gotoPriorityExpression NEXT
 

# Bind ADV authentication policy to authentication vserver with time based expression...(affects all users on this one vpn vserver)

bind authentication vserver authe_vsrv_demo -policy authe_pol_ldap_wsl -priority 100 -gotoPriorityExpression NEXT
 

Results:

So if you log in during hours, the authentication attempt is permitted and regular authorization applies afterwards.

If you log in outside of hours, then the authentication fails (post login) with message:  No active policy during authentication

 

Example 3:  One VPN, and some users need to be denied authentication outside of hours and others are not.

So, the problem/complexity with this is that you have to allow an initial authentication prompt for a Group Extraction policy (username and no password), so we can then figure out which group you belong to. Then based on group membership you build an nfactor flow to see RestrictedUsers can only continue logon if between hours and members of NonRestrictedUsers can logon no matter what. I'm not mocking this one up but it would be similar to this nfactor example but with the time conditions and not the ldap/radius triggers:  https://support.citrix.com/article/CTX220793

 

 

But for simplicity, build a restricted vpn for restricted users to do this for authentication and separate them from others (aka Example 2) or do this at authorization per group aka Example 1. Example 3 is way more complex.

 

 

 

 

 

 

 

 

 

 

[Bit-101]

How about "Just In Time Access". In other words Temporary access each time for a user