On 03/25/2015 12:09 PM, Stanislav Láznička wrote: > 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.
I guess so. BTW, also check the latest Simo's note, user-based local time rules may be something that does not fully fit in the HBAC scheme and may be postponed or canceled. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
