[Freeipa-devel] Time-based account policies

[Stanislav Láznička]

On 03/25/2015 08:21 AM, Jan Cholasta wrote:
> Dne 24.3.2015 v 18:08 Stanislav Láznička napsal(a):
>> On 03/24/2015 08:53 AM, Jan Cholasta wrote:
>>> Dne 24.3.2015 v 08:40 Martin Kosek napsal(a):
>>>> On 03/24/2015 08:20 AM, Jakub Hrozek wrote:
>>>>> On Tue, Mar 24, 2015 at 08:07:53AM +0100, Martin Kosek wrote:
>>>>>> On 03/24/2015 07:16 AM, Jan Cholasta wrote:
>>>>>>> Dne 23.3.2015 v 20:17 Standa Láznička napsal(a):
>>>>>> ...
>>>>>>>>> Given the above, HBAC rules could contain (time, anchor), where
>>>>>>>>> anchor
>>>>>>>>> is "UTC", "user local time" or "host local time".
>>>>>>>> Truth is, it was not really clear to me from the last week's
>>>>>>>> discussion
>>>>>>>> whose "Local Time" to use - do we use host's or do we use
>>>>>>>> user's?  It
>>>>>>>> would make sense to me to use the user's local time. But then you
>>>>>>>> would
>>>>>>>> need to really store at least the timezone information with each
>>>>>>>> user
>>>>>>>> object. And that information should probably change with user 
>>>>>>>> moving
>>>>>>>> between different timezones. That's quite a pickle I am in right
>>>>>>>> here.
>>>>>>>
>>>>>>> IMO whether to use user or host local time depends on organization
>>>>>>> local
>>>>>>> policy, hence my suggestion to support both.
>>>>>>
>>>>>> I am bit confused, I would like to make sure we are on the same
>>>>>> page with
>>>>>> regards to Local Time. When the Local Time rule is created, anchor
>>>>>> will be set
>>>>>> to "Local Time". Then SSSD would simply use host's local time, in
>>>>>> whichever
>>>>>> time zone the HBAC host is.
>>>>>
>>>>> Yes, that was my understanding also.
>>>>>
>>>>>>
>>>>>> So this is the default host enforcement. For the user, you want to
>>>>>> let SSSD
>>>>>> check authenticated user's entry, to see if there is a timezone
>>>>>> information?
>>>>>> This would of course depend on the information being available. For
>>>>>> AD users,
>>>>>> you would need to set it in ID Views or similar.
>>>>>
>>>>> Yes, also in a previous e-mail, there was a suggestion to change
>>>>> timezones by admin when the user changes timezones -- I didn't like
>>>>> that
>>>>> part, it seems really error prone and tedious. *If* there was this
>>>>> choice, it should not be the default, rather the default should 
>>>>> also be
>>>>> host local time IMO.
>>>
>>> I don't think you can expect host-local time to be good enough for
>>> everyone.
>>>
>>>>
>>>> Host local time zone was the original case I expected. Enforcing
>>>> *user* local
>>>> time zone is where this discussion started. Honze proposed making
>>>> this an
>>>> option - leaving us to 3 different time modes:
>>>>
>>>> * UTC - stored as (time + olson time zone), enforcement is clear
>>>> * Host Local Time - stored as  (time + Host Local Time), 
>>>> enforcement by
>>>> /etc/localtime
>>>> * User Local Time - stored as  (time + User Local Time), enforcement
>>>> by ???
>>>>
>>>> So the rule may be:
>>>> * Employee Foo can access web service Bar only in his work hours
>>>
>>> Correct.
>>>
>>>>
>>>> IMO, it is realistic for an administrator to set the time zone
>>>> setting in the
>>>> employee entry. Of course, it gets tricky when the user starts moving
>>>> around
>>>> the globe...
>>>>
>>>
>>> It doesn't have to be the administrator, it can be automated by a 3rd
>>> party service:
>>>
>>>  1. Employee schedules bussiness trip in time management system
>>>  2. Manager approves the bussiness trip in the time management system
>>>  3. The time management system takes care of changing the employee's
>>> user object timezone when the bussiness trip starts and ends.
>>>
>> I have to say I am not very sure about this anymore. Although it would
>> be a great feature to have users' local time policies, it brings a lot
>> of traps on the way. The responsibility of keeping the LDAP database
>> consistent with reality is laid to a 3rd party application. If that
>> breaks or does not work well, this responsibility might be sometimes
>> transferred to admin. But if there's a lot of people traveling at a
>> time... I'm having mixed feelings about this.
>
> Timezones or not, there is always the responsibility of keeping LDAP 
> in sync with reality. I'm just saying there are possibilities besides 
> doing it manually.
>
> Anyway, I think both user-local and host-local time can also be 
> implemented based on group membership, without storing anything with 
> user and host object, with HBAC rules like this:
>
>   Rule name: allow_tz_europe_prague_users
>   Member groups: tz_europe_prague
>   Host category: all
>   Service category: all
>   Access time: (timeofday=0800-1600 dayofweek=Mon-Fri)
>   Time zone: Europe/Prague
>   Description: Allow users in Europe/Prague access during bussiness hours
>   Enabled: TRUE
>
>   Rule name: allow_tz_europe_prague_hosts
>   User category: all
>   Member hostgroups: tz_europe_prague
>   Service category: all
>   Access time: (timeofday=0800-1600 dayofweek=Mon-Fri)
>   Time zone: Europe/Prague
>   Description: Allow access to hosts in Europe/Prague during bussiness 
> hours
>   Enabled: TRUE
>
> I guess things might get complicated if you want to do limit access 
> based on both user and host local time, but I'm not sure if anyone 
> would actually want to do that.
>
This is great and it's how I would expect it would be performed. 
Although, I think it would still be good having host-local time rules 
enforced by the hosts' /etc/localtime. I'm not sure but I think that 
would still need to have the host's timezone stored for HBAC Test sake, 
is that right? That would be leading back to this solution as easiest, I 
guess.